P04

SealedMind

A decentralised memory layer for AI agents. Memories are encrypted under a wallet-derived key, stored as transferable assets, and every access is logged on chain.

Role
Design and implementation
When
2026
Stack
  • TypeScript
  • Solidity
  • 0G
  • TEE
  • HNSW
The problem

Everything an AI assistant learns about a person accumulates on somebody else's server. There is no ownership, no way to move it, and no way to prove what was done with it.

SealedMind makes a memory an asset the user holds: encrypted with a key derived from their wallet, processed only inside hardware-secured environments, and grantable to another agent as read-only access that can be revoked.

The sketch
Owner walletExtract in TEEattestedEncryptAES-256-GCM0G Storageencrypted blobHNSW indexvectors, localERC-7857ownership + grantsAccess logimmutable

An owner's wallet drives extraction inside a TEE, the result is encrypted and stored on 0G, indexed locally as vectors, tracked on chain as an ERC-7857 asset, and every access is logged.

How it works

Extraction inside an enclave

Facts are extracted by a model running inside Intel TDX with an NVIDIA H100, and every response carries a TEE attestation identifier. That turns we do not read your data from a policy into something checkable.

Encrypted before it lands

Content is encrypted with AES-256-GCM under a key derived from the owner's wallet and never persisted. Encrypted blobs go to decentralised storage; the vectors that make them searchable are indexed locally with HNSW.

Ownership is the isolation boundary

A mind's identifier is the wallet address, so there is no query that can cross between users. Ownership and access grants are tracked on chain as an ERC-7857 iNFT, and every memory operation emits an immutable access log.

Shipped surface

Eight contracts deployed and source-verified across mainnet and testnet, 81 tests across four suites, four published SDKs, and three third-party integrations built on top of it.

What was hard

Transferring ownership of encrypted data without re-encrypting it. The content key is wrapped under each owner's wallet-derived key, so when a mind changes hands the backend re-wraps that one key under the new owner's. Ownership moves in constant time regardless of how many megabytes of memory the mind holds. Re-uploading and re-encrypting every blob would have made transfer unusable at any real size.

Encrypted data outlives the code that wrote it. A regression test pins known-good v1 blobs byte for byte, so any accidental change to v1 decryption fails the build. Without it, a refactor two months later silently strands everything already stored.

What I'd do differently

Re-keying on transfer happens server-side, which means the backend holds the key derivation secret at that moment. That adds no trust assumption beyond what normal operation already requires, and it is still the weakest claim in the system. The genuinely trustless version needs on-chain TEE oracles and was deferred rather than pretended.