Where AI memory lives: the substrate underneath SAIHM

The vendor-memory failure mode

Almost every AI memory feature shipped in the last twelve months lives inside the vendor: on the model provider's servers, behind their authentication, governed by their retention policy, terminated by their billing system. That works until any of the following happens:

• The vendor changes the retention policy.
• The vendor deprecates the memory product.
• You move to a different model and the memory does not move with you.
• A regulator asks for proof of erasure and the vendor cannot produce it.
• An auditor asks for a timeline of what the agent knew when, and the vendor cannot produce it either.

The fix is not a better vendor. The fix is moving memory off the vendor stack onto a substrate that the agent owner controls, that any party can verify, and that survives the vendor.

What “substrate” means here

The SAIHM protocol is a contract: eight tools, an identity scheme, an erasure receipt, an audit anchor format. The substrate is the physical infrastructure that contract runs on — the ledger that records the audit anchors, the storage network that holds the encrypted cell data, the key material the agent identity is derived from.

The distinction matters because the protocol is the part you depend on. The substrate is the part you can swap.

The four jobs a substrate must do

Any substrate that wants to host AI memory at production seriousness has to do four things, each with its own engineering constraints:

1. Identity anchoring. The agent's identity must be derivable from key material the agent owner controls (a wallet, an HSM, a KMS) and provable to third parties without trusting the vendor. This is where wallet-derived keys + HKDF chains earn their keep.
2. Audit anchoring. Each memory write needs a tamper-evident timestamp on a public, append-only ledger so a regulator, auditor, or counterparty can verify the timeline without re-trusting the operator. Finality must be reasonable; the per-write cost must be low enough that anchoring every cell is economically possible.
3. Ciphertext storage. The encrypted cell content has to live somewhere durable, distributed, and addressable by content hash so any party with the right key can fetch it and any party without the key sees only random bytes.
4. Erasure proof. When the user invokes the right to erasure, the substrate must support destroying the only decryption key, writing an on-chain tombstone, and blacklisting the storage CID — producing a receipt that a regulator can verify against the public ledger.

The candidate landscape, by job

Different substrate choices satisfy different jobs well or badly:

• Identity: any chain with mature wallet tooling works. ETH, BTC, the EVM L2s, Solana, Cosmos, Substrate-family chains, COTI V2 — all viable for the “agent owns its keys” primitive.
• Audit anchor: needs low write cost and reasonable finality. Ethereum L1 is too expensive at scale (every cell-mint would cost real dollars). L2 rollups are cheaper but inherit the rollup's data-availability assumptions. Cheaper L1s and app-chains widen the candidate set.
• Ciphertext storage: Filecoin and IPFS are the obvious open candidates. Arweave is a candidate technically but its permanent-storage model conflicts with the right-to-erasure requirement (you cannot blacklist an Arweave CID; the network is designed not to forget). S3 / GCS / Azure Blob work but reintroduce a custodial layer.
• Erasure proof: not a property of the substrate per se — it is a property of the protocol's key-management discipline. Any chain that can take a small write can record a tombstone; the protocol decides what the tombstone means.

No single substrate is obviously dominant on all four jobs. The honest answer is: you pick the combination that satisfies your constraints, and you document the choice so others can audit it.

SAIHM's deployment choice

SAIHM's reference deployment uses COTI V2 mainnet for identity and audit anchoring, and Filecoin (via a Lighthouse upload path) for encrypted cell ciphertext. The reasoning is narrow and engineering-only:

• Native privacy primitives at the protocol level. COTI V2 supports wallet-derived encryption keys and private-data computation primitives, which lets the SAIHM agent identity HKDF chain (MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1) tie audit records to the agent without putting sensitive key material on-chain.
• Per-anchor cost low enough to anchor every cell. SAIHM mints one transaction per memory cell. The cost ceiling matters: at Ethereum L1 prices this workload would not be viable. The substrate has to make per-cell anchoring economically routine.
• No EVM / no Solidity surface area. SAIHM has zero EVM dependency in protocol code — no ethers.js, no Solidity contracts. The substrate is interacted with via its native JSON-RPC. This is a deliberate protocol-design choice (smaller attack surface, no Solidity-version churn, no EVM gas-pricing dependency).
• Filecoin for ciphertext, not Arweave. Arweave's permanent-storage model is incompatible with GDPR Article 17 right-to-erasure. SAIHM needs to be able to blacklist a CID after key destruction so re-fetching becomes impossible. Filecoin's incentive model supports CID blacklisting; Arweave's does not.

The choice is a tradeoff, not a coronation. A SAIHM deployment that satisfied the four jobs on a different substrate combination would still be SAIHM — the protocol contract does not change.

The portability point

Pulling these threads together: the substrate is a deployment configuration, the protocol is the load-bearing surface. If COTI V2 disappeared tomorrow, SAIHM the protocol would not disappear; a fresh deployment would stand up on whichever substrate combination satisfied the same four jobs, and the contract surface presented to applications and regulators would be unchanged.

This matters for evaluating any AI memory product, not just SAIHM:

• If you are building an agent: think about your memory protocol independently from the substrate it runs on. Lock-in to either is a problem; lock-in to both at once is worse.
• If you are a CISO or DPO: ask vendors for their substrate story — what is the audit ledger, what is the ciphertext store, what is the erasure-proof mechanism, what is the migration story if any of those changes.
• If you are a regulator: the substrate is not a black box. Audit anchors are public; the candidate ledgers are well-documented; you can verify the chain of receipts yourself.

How to evaluate a substrate yourself

For each of the four jobs, ask:

1. Identity: Can the agent owner derive and rotate keys without trusting the vendor? Is the derivation auditable?
2. Audit anchor: What is the per-write cost? What is the finality timeline? Is the chain public and indexable by third-party explorers?
3. Ciphertext: Is content addressed by hash? Is the storage network distributed? Can a CID be made unfetchable when its key is destroyed?
4. Erasure: Does the protocol destroy the only key, or does it merely mark data deleted in a table? Where does the erasure receipt live? Can a regulator verify it against the public ledger without the operator's cooperation?

If a vendor cannot answer one of these for their AI memory product, the substrate story is incomplete.