TRUST MODEL
What you can — and cannot — trust
ChainMemory combines a centralized API with decentralized verification. Understanding the trust boundaries is critical for evaluating whether ChainMemory meets your security requirements.
Guarantees table
| Question | Answer | How it's enforced |
|---|---|---|
| Can the operator delete an event after it's recorded? | Yes, from the database | But the on-chain anchor preserves the state hash. Deletion is detectable: re-computing the hash from remaining events will produce a mismatch with the anchored hash. |
| Can the operator modify a past state? | Yes, in the database | But any modification changes the state hash. Comparing the recomputed hash against the on-chain anchor reveals tampering immediately. |
| Can the operator forge an anchor? | No | Anchors are on-chain transactions. The smart contract records the state hash immutably. Forging requires controlling the blockchain — economically infeasible with PoA consensus and multiple validators. |
| Can a third party verify without trusting ChainMemory? | Yes | The verification endpoint is public and unauthenticated. Anyone can also read the smart contract directly using Web3/Ethers.js. |
| Can memories be read by other users? | No | Memory content is scoped to the API key owner. What is public on-chain is ciphertext, not plaintext: decrypting it requires the key derived from the owner API key. |
| Is the memory plaintext stored on-chain? | No | What is written on-chain is the AES-256-GCM ciphertext of each memory (MemoryV2.writeMemory), along with its category, importance and plaintext length. The plaintext never leaves the API database, and without the owner key nobody can decrypt it — which is also what lets you recover a memory years later from another device. The consolidated Project State is anchored as a SHA3-256 hash only. |
| Can validators see memory content? | No | For a state anchor the payload is only the project id and the state hash. For a memory it is AES-256-GCM ciphertext plus its category, importance and length: validators can order and validate it, they cannot read it. |
| What happens if ChainMemory goes offline? | Memories are temporarily inaccessible | But all on-chain anchors remain verifiable independently. The blockchain continues operating even if the API is down. Users can export their data at any time. |
Trust levels
Full trust (cryptographic)
State integrity and timestamp. Once anchored, the hash at block N is immutable. Nobody — not even ChainMemory — can alter what was recorded.
Operational trust (API-dependent)
Memory storage, retrieval, injection, and consolidation. These depend on the ChainMemory API being available and honest. The anchor mechanism acts as a check: any server-side tampering is detectable.
No trust needed
Independent verification. Anyone with a Web3 library can read the smart contract directly and compare hashes. Zero dependency on ChainMemory infrastructure.
Sovereignty — non-custodial
ChainMemory is moving to a non-custodial model where your key lives in your client, not on the server. You sign your own on-chain writes; the server stores ciphertext and verifies signatures, but never holds your private key. This has been proven end-to-end — a memory written entirely client-side, with the server never touching the key.
What non-custodial means here
Keys are generated client-side and the server stores only your address (
POST /v1/keys/register-pubkey). The client signs and broadcasts each write; the server only attaches the record (POST /v1/memory/attach). API keys are encrypted at rest (AES-256-GCM) with a master key kept outside the app.
In progress
Blind vault: deriving the content-encryption key from your private key so the server cannot read content even in theory. The published Chrome extension still signs server-side (custodial) today; the non-custodial path ships in a new version. The capability is proven and the migration is underway.