aviral singh

encrypting agent memory with wallet-derived keys

Let’s be real for a second. The agents we’re all building right now have memory. They remember your name, your preferences, the project you ranted about at 2am, the wallet you connected, the weird edge cases of how you like things done. That memory is what makes an agent feel less like a chatbot and more like something that actually knows you.

Here’s the part nobody wants to say out loud: that memory usually lives in plaintext, on someone else’s server, behind someone else’s login. You don’t own it. You’re renting access to your own brain extension. And the second that database gets popped, leaked, or quietly sold, everything your agent learned about you is just out there.

That felt deeply uncool to me. So we did something about it.

The core idea: your wallet is the key

You already carry a cryptographic identity everywhere you go. It’s your wallet. The whole point of a wallet is that only you can produce a valid signature with it. Nobody can fake it, nobody can replay it without your say-so.

So instead of inventing yet another password or trusting a server to hold a secret for you, we derive the encryption key straight from your wallet.

It works like this. Your agent needs to read or write memory. It asks you to sign a fixed, deterministic message (think of it as a domain-specific handshake, not a transaction, so no gas, no funds moving). That signature is unique to your key and totally reproducible. We run it through a key derivation function and out comes a symmetric encryption key. That key never gets stored anywhere. It gets regenerated on demand, used, and dropped.

No key vault. No “trust us, it’s encrypted at rest.” The key literally does not exist until your wallet brings it into being.

Encrypt before it leaves the building

The other half of the trick is where the encryption happens. It happens client side, before a single byte touches storage. Your agent’s memory gets sealed locally, then the ciphertext gets written out to decentralized storage. The storage layer holds noise. Pretty noise, but noise. Without a signature from your wallet, it’s unreadable, full stop.

This flips the whole threat model. The classic question is “can I trust the people running the server?” With wallet-derived keys, that question mostly stops mattering, because the server never sees anything worth stealing. They host encrypted blobs. They couldn’t read your agent’s memory if they wanted to, and honestly, neither can we.

That’s the bar I think we should be holding ourselves to. Not “we promise we won’t look.” More like “we built it so we can’t.”

Receipts, on chain

Encryption is great, but you also want to know what your agent has been up to, and you want to be able to pull the plug.

Every memory write gets logged, and access is gated by an on-chain revocation registry. Translation: if you ever want to cut an agent off, you revoke. On chain, publicly verifiable, no support ticket, no waiting on a company to honor your delete request. The agent’s read path checks the registry, sees it’s been revoked, and that’s the end of it. The memory becomes a brick.

This is the part that gets me a little hyped. Deleting your data usually means trusting that a company actually deleted it. Here, revocation is a state change you control, and anyone can verify it happened. No vibes-based privacy. Actual receipts.

Why this is the move

Step back and look at where agents are heading. They’re getting persistent. They’re getting wallets. They’re starting to act on your behalf with real stakes attached. An agent that holds a rich, growing memory of your life and stores it in plaintext somewhere is a breach waiting to happen, and the blast radius only grows the more useful the agent gets.

Wallet-derived keys fix the incentive problem at the root. You hold the key because you already hold the wallet. The agent borrows access when you grant it and loses it when you revoke it. Memory stays portable, because it’s tied to your identity and not to one app’s database. Switch frontends, switch agents, and your encrypted memory comes with you, still locked, still yours.

We talk a lot about self-custody for tokens. Self-custody for cognition feels like the obvious next chapter, and barely anyone is building for it yet.

The tl;dr

Your agent’s memory is sensitive. Treat it that way.

  • Derive the encryption key from a wallet signature instead of trusting a server to hold a secret.
  • Encrypt client side, store only ciphertext, keep the key ephemeral.
  • Gate access with an on-chain registry so revocation is real and verifiable.

Your agent can remember everything. The difference is now you’re the only one who can actually read it.

If you’re building in this space, come poke holes in it. That’s how this gets better.