Storage architecture
SAIHM persists encrypted memory cells on decentralized storage networks chosen for one property above all: compatibility with cryptographic erasure. This page describes the architecture at the category level — what each layer does, and why.
Most SAIHM users do not need to read this page. The protocol’s storage layer is operated on your behalf. This page exists for readers who want to understand the layer beneath.
How your cells are stored
Encryption happens with a key derived from your wallet identity, on your device, before a cell ever leaves it. From that point on, every storage layer sees ciphertext only.
Encrypted cells persist on operator-selectable decentralized storage networks. SAIHM is provider-agnostic at this layer: the protocol pins no single provider and no specific region, and the choice of network and operator within it is an operational decision made by whichever party runs the SAIHM node serving you. SAIHM does not run its own storage nodes and does not endorse a specific provider.
The protocol deliberately avoids projecting dependency on any single storage network. What matters at the protocol layer is not which network holds a cell, but that the network holding it respects content-addressed, erasure-compatible semantics.
Why erasability decides the substrate
Cells are subject to GDPR Art. 17 / CCPA cryptographic erasure (see /trust#erasure). When you say “forget that”, SAIHM destroys the per-cell data-encryption key; the ciphertext that remains on the storage network is mathematically unreadable thereafter.
This is why user cells are never written to a permanence-oriented (immutable) network. An immutable substrate’s defining property — that nothing written can ever be removed — is the wrong property for user memory, where erasure on demand is the requirement. SAIHM restricts any immutable substrate to protocol-level anchors that are meant to be permanent: governance votes and proposals, chain-registry mutations, activation events, and similar records where rewriting history is itself the threat model. No user content is ever written there.
Audit-ledger durability
Hash-chained, ML-DSA-signed audit-ledger entries may be mirrored across more than one decentralized network for durability at the Enterprise and Enterprise Fast tiers. Memory cells are never part of the audit-ledger mirror — it holds audit-trail records, not memory content. This is a deliberate scope boundary at the protocol layer; the choice of mirror network is operator-side and not user-facing.
Content addressing
Cells are referenced by content-addressed identifiers, which give tamper-evident retrieval semantics: the identifier is derived from the content, so a cell cannot be silently substituted. No private user data is routed through public retrieval gateways — those are used only for public artefacts (for example, the published /.well-known/security.txt mirror).
SAIHM’s position
SAIHM does not endorse a specific provider for any storage layer. Each layer is selected for the property it must have — erasability for cells, immutability for permanent anchors, durability for the audit mirror, content-addressing for retrieval — and the operator running your node makes the specific provider choice. The protocol does not depend on, or disclose dependency on, any single network.
Get started with SAIHM
Most users do not need to read this page — SAIHM’s storage layer is operated for you. This page exists for those who want to understand the layer beneath.