Trust, by construction

SAIHM is a memory protocol — not a SaaS. The properties below come from how the protocol is built, not from a vendor promise. Every claim on this page is verifiable in code, on the public COTI V2 chain, or against an open standard.

Last updated 2026-05-31. This page is the canonical Trust Center. If you find a discrepancy between any other SAIHM page and this one, this page wins.

What this page is — and isn’t

This is the consolidated map of SAIHM’s security, privacy, compliance, license, and incident-disclosure stance.

Where the protocol can give you a guarantee on its own — user-held keys, cryptographic erasure, public-chain audit, license — the section below states the property and points to the code or standard that backs it.

Where the property depends on the operator running the node that serves you — SOC reports, ISO certifications, HIPAA Business Associate Agreements, regional data-residency — the section says so plainly. SAIHM is not a single legal entity standing behind a single SLA; it is a permissionless protocol that operators run on top of. Operator-level trust is operator-specific.

Sovereignty — you hold the keys

What: the encryption keys protecting your memories are derived on your device from your wallet identity. SAIHM does not custody them, escrow them, or backdoor them. This is the foundational property the protocol is built around.

How: identity uses a canonical HKDF chain — MPS-PQC-KEY-GEN-v1 (HKDF #74) → MPS-AGENT-IDENTITY-v1 (HKDF #35) — rooted in the wallet you control. Memory keys are derived per-cell from that identity; the operator never sees them.

Implication: if you lose your wallet recovery phrase and have not separately exported a memory backup, your memories are unrecoverable. We treat that as a feature; you should treat your wallet recovery phrase accordingly. See For you for plain-language wallet guidance.

Cryptographic erasure (GDPR Art. 17)

What: when you say “forget that”, SAIHM destroys the data-encryption key (DEK) for that cell. The ciphertext on the storage tier becomes mathematically unreadable — not just removed from an index, not just flagged for deletion, but cryptographically severed from any path to plaintext.

How:

The DEK for the target cell is destroyed in the gate-controller chain (destroyDek(GDPR_ART17) at GC-3).
A tombstone is written at GC-4 so future reads cannot misroute.
The cell’s content identifier (CID) is added to a blacklist so it cannot be re-pinned through the protocol.
The erasure event is anchored on-chain through the GC-14 audit path.

Why this matters for compliance: the right to erasure under GDPR Art. 17, CCPA § 1798.105, and analogous statutes is satisfied at the cryptographic layer, not the application layer. The data is unreadable to SAIHM, to the operator, and to anyone else — permanently.

Storage-tier scope: user memory cells live on the protocol’s decentralized storage tier across all tiers (Pro, Pro Fast, Enterprise, Enterprise Fast) — the substrate supports the DEK-destruction-as-erasure pattern. Operators may additionally serve cells from operator-side hot-cache layers (ciphertext only, encrypted at rest); cache invalidation propagates as part of the erasure flow, and DEK destruction guarantees unreadability regardless of any cache state. Cells are never written to a permanence-oriented (immutable) substrate: an immutable substrate’s permanence model is incompatible with cryptographic-erasure semantics under GDPR Art. 17, which is why SAIHM restricts immutable storage to protocol-level anchors that are meant to be permanent (governance votes, registry mutations, activation events) — not user content. The audit-ledger mirror at Enterprise tiers likewise never holds cells. SAIHM pins no specific provider or region. See /appendix/storage-nodes for the storage architecture.

Caveat — backups outside SAIHM. If you exported a plaintext memory backup to a third-party system before issuing forget, that backup is outside the protocol’s reach. Erasure covers the protocol surface; it does not retroactively reach copies you made of the plaintext.

Public-chain audit trail

Every consequential SAIHM operation — memory-cell creation, sharing-grant, sharing-revocation, erasure, governance vote — emits an anchor on the public COTI V2 mainnet through the GC-14 audit path.

Anchors are calldata commitments, not plaintext. The chain proves that something happened and when it happened, without revealing what was said.

Genesis anchor: 0x755beb60…0d0963a ↑ — gSAIHM v1 ledger origin, block 7,024,653, anchored 2026-05-03.

What this gives you: a regulator, auditor, or counter-party can independently verify that an erasure happened, a sharing-grant existed for a given window, or a governance vote was tallied honestly — without needing to trust SAIHM’s word.

Encryption

Shard symmetric encryption: AES-256-GCM with per-shard HKDF-derived nonce
Cell envelope: GC-3 envelope encryption with per-cell DEK; KEK rotated per protocol policy
Signatures: ML-DSA (post-quantum, NIST FIPS 204) on cell commitments. ML-KEM (FIPS 203) and SLH-DSA (FIPS 205) are also part of the standardised PQC suite the protocol uses
No legacy asymmetric: No RSA, ECDSA, or ECDH anywhere in the protocol’s internal cryptographic operations
Identity derivation: HKDF chain rooted in user-held wallet (HKDF #74 → #35)
Sealed compute: Gate-controller cryptographic operations execute inside COTI V2 Helium sealed compute — the sealed-compute layer protects keys and intermediate values during processing, distinct from the at-rest encryption above
Transport: TLS 1.3 from client to operator; HSTS preload-eligible 2 years on the public surface
Storage at rest: Ciphertext only. Cells on the protocol’s decentralized storage tier across all tiers; operators may additionally serve cells from operator-side hot-cache layers (also ciphertext, encrypted at rest). Audit-ledger mirror on a secondary decentralized network at Enterprise tiers. Protocol-level governance / registry / activation anchors on a permanence-oriented (immutable) substrate (cells never written there). Operator never sees plaintext at any substrate.

No third-party cryptographic audit has been conducted to date. The protocol is Apache 2.0 source-available; we welcome and will publicly cite independent reviews. Vulnerability reports go to security@saihm.coti.global.

What operators do (and don’t) see

Operators running SAIHM nodes for paying customers see:

Ciphertext (cells, on the decentralized storage tier)
Routing metadata required to deliver a cell to the right wallet (cell IDs, owner-wallet hash, sharing-grant target hashes)
Billing-relevant counters (remembers, recalls, sharing-grants — for invoicing in USDC.e)
The on-chain audit anchors that they themselves are required to emit

Operators do not see:

The plaintext content of any memory
The DEKs that would let them decrypt cells
Identifiers that link a wallet to a real-world person, unless that person voluntarily provides them out-of-band

This is a structural property of the protocol, not a policy promise. An operator that wanted to read your plaintext would have to break the encryption, not just change a setting on their server.

Privacy posture

At the protocol layer: SAIHM does not collect, infer, or sell user data. The protocol’s on-chain footprint is anchors and counters; the off-chain footprint is ciphertext on the decentralized storage tier. There is no plaintext data lake.

At the operator layer: the operator running your node has its own privacy notice covering invoicing, customer support, abuse handling, and any voluntary identifying information you provide. Ask the operator for theirs.

At the agent layer: the AI agent you use to interact with SAIHM has its own privacy posture — what it logs, what it sends to model providers, where it stores prompts. SAIHM cannot speak for it.

At the outreach layer (click-through measurement): links SAIHM publishes through its own outreach pass through a privacy-minimal redirector at t.saihm.coti.global. When you follow one, it records only a truncated client address (the final IPv4 octet is zeroed to a /24; IPv6 to a /48), a shortened browser user-agent string, the referring page, and which campaign the link belonged to — solely to measure which channels bring readers to SAIHM. It sets no cookies, runs no tracking pixel, builds no cross-site profile, and never retains the raw request URL. Automated bots and link-preview fetchers are not counted. These minimal records are deleted automatically after 30 days. The lawful basis is legitimate interest in understanding referral effectiveness (GDPR Art. 6(1)(f)); the address is truncated at the moment of writing, so the stored record is not reasonably linkable to you. You can avoid this entirely by visiting saihm.coti.global directly instead of through a t.saihm.coti.global link.

Cross-vendor sharing is governed by user-issued grants (/governance emission parameters apply); revocation is cryptographic and on-chain.

Compliance posture

Protocol-level — what SAIHM gives you:

GDPR Art. 17 right-to-erasure satisfied cryptographically (see above)
GDPR Art. 30 records-of-processing supported via the public on-chain audit anchors
CCPA / CPRA right-to-delete satisfied by the same erasure mechanism
HIPAA-compatible custody pattern: operator never sees PHI plaintext, so the storage relationship can sit outside the BAA boundary in many architectures (consult your privacy counsel)

Operator-level — what SAIHM does not give you:

SOC 2 Type II reports (an operator may hold one for their node operation; the protocol doesn’t)
ISO 27001 certification (same)
HIPAA Business Associate Agreements (an operator may sign one with you; SAIHM as a protocol cannot)
Regional data-residency guarantees (operator-selectable decentralized storage providers can address this; the protocol does not pin any specific region)

If you require operator-level controls for a regulated workload, ask the operator running your node for their attestations. SAIHM’s Operator Track partners can provide them; ops@saihm.coti.global.

License & terms

Protocol license: Apache License 2.0. You may use, modify, fork, and redistribute the protocol implementation under that license. The Apache 2.0 grant includes an explicit patent license from contributors.

Trademark: the SAIHM name and mark are not part of the Apache 2.0 grant. Do not use the SAIHM mark to imply endorsement of a fork or derivative without written consent.

Operator terms: the entity operating the node serving you has its own terms of service governing payment, abuse handling, and dispute resolution — ask them.

Independence: SAIHM is an Apache-2.0 protocol authored independently. It is not a product or entity of the COTI Group, and no entity, employee, or agent of the COTI Group participated in producing SAIHM. SAIHM operates on the public COTI V2 mainnet under the same terms as any other public-network user.

Acceptable use

SAIHM is built to remember whatever its users choose to remember. The protocol is content-neutral at the cryptographic layer — ciphertext is ciphertext. Nevertheless, the following uses are out of scope and operators are expected to refuse service for them:

Storage or sharing of content depicting child sexual abuse material (CSAM)
Use as the persistence layer for active criminal infrastructure (e.g., command-and-control, ransomware payload staging)
Targeted harassment, stalking, or doxxing campaigns
Sanctions-listed-party transacting in jurisdictions where SAIHM operators are required to refuse such transactions

Operators handle abuse cases at their layer; the protocol’s erasure mechanism is available to operators to respond to lawful takedown orders that target a specific cell. The cryptographic-erasure property cuts both ways: an erased cell is permanently unreadable even by the operator.

Report suspected abuse first to the operator running the node serving the actor in question. If the operator is unresponsive or unidentifiable, escalate to ops@saihm.coti.global with subject prefix [abuse].

Vulnerability disclosure

Send security findings to security@saihm.coti.global. Our published /.well-known/security.txt file (RFC 9116) is the canonical source for this contact and its expiry.

Scope: the SAIHM protocol implementation, the public website at saihm.coti.global, and SAIHM-published artefacts (registry, MCP server build closure, governance contracts).

Out of scope: third-party operator infrastructure (report directly to that operator), the COTI V2 mainnet itself (report to the COTI security team), the decentralized storage networks (report to the relevant storage provider), and AI agents that connect to SAIHM (report to the agent vendor).

Process: we aim to acknowledge receipt within 72 hours. We coordinate disclosure with reporters and do not publicly attribute reporters without their consent. A formal bug-bounty programme is currently deferred — review date 2026-12-31, contingent on revenue / treasury supporting credibly funded payouts. See /roadmap#deferred.

Please do not perform live testing against operator nodes serving paying customers. Test against your own node instance.

Sub-processors & dependencies

The protocol itself uses the following external systems. Each is a public network, not a SaaS vendor with a data-processing contract.

COTI V2 mainnet: Settlement and audit-anchor surface. Public chain, chain ID 2632500. Block explorer mainnet.cotiscan.io.
Decentralized storage networks: Encrypted memory cells persist on operator-selectable decentralized storage networks across all tiers (Pro, Pro Fast, Enterprise, Enterprise Fast). The hash-chained audit ledger is mirrored to a secondary decentralized network at the Enterprise / Enterprise Fast tiers (cells are never part of the mirror), and protocol-level events that must remain immutable (governance votes / proposals, chain-registry mutations, activation events) are anchored to a permanence-oriented network (no user cells written there). Cells are referenced by content-addressed identifiers for tamper-evident retrieval. SAIHM pins no specific provider or region and writes cells only to networks compatible with cryptographic erasure; operators select providers operationally. See /appendix/storage-nodes.
USDC.e on COTI V2: Canonical settlement asset for paid use. Bridged USD Coin, native to COTI V2 mainnet.

Operators may add their own sub-processors (mail, billing, support tooling). Ask the operator for their sub-processor list.

Audit history

No third-party security audit of the SAIHM protocol implementation has been completed to date. The implementation is Apache 2.0 source-available and has been continuously reviewed by the protocol’s maintainers.

The public on-chain audit anchors provide cryptographic, third-party-verifiable evidence of every consequential operation since genesis (2026-05-03).

Independent review and audit reports, when conducted, will be linked here with the auditing firm, scope, date, and remediation status.

Incident history

No security incidents disclosed to date.

Future material incidents will be disclosed on this page within 7 days of confirmation, with scope, customer impact, root cause, and remediation. Operator-side incidents are disclosed by the operator; we will link to operator post-mortems where they exist.

Status

Live operational status, mainnet anchor counts, and recent registry events: /status.

Contact

Security: security@saihm.coti.global · security.txt
Abuse: ops@saihm.coti.global with subject prefix [abuse]
Operator partnership: ops@saihm.coti.global
General / billing: ops@saihm.coti.global
Governance: /governance