The Sovereign AI Horizontal Memory (SAIHM) Protocol
draft-saihm-memory-protocol-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Russell Jackson | ||
| Last updated | 2026-05-27 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources |
SAIHM MCP server reference implementation, Apache 2.0
SAIHM standards surface npm @saihm/mcp-server |
||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saihm-memory-protocol-01
Independent Submission R. Jackson
Internet-Draft SAIHM (Sovereign AI Horizontal Memory)
Intended status: Informational 27 May 2026
Expires: 28 November 2026
The Sovereign AI Horizontal Memory (SAIHM) Protocol
draft-saihm-memory-protocol-01
Abstract
This document defines the Sovereign AI Horizontal Memory (SAIHM)
protocol, a memory layer for AI agents that supports post-quantum
identity binding, public-chain audit anchoring, per-cell encryption
with wallet-derived keys, revocable sharing contracts, and
cryptographic right-to-erasure aligned with Article 17 of EU
Regulation 2016/679 (GDPR).
SAIHM is the memory-layer protocol companion to the Model Context
Protocol (MCP). MCP standardizes how AI agents reach tools and
contextual data sources; SAIHM standardizes how AI agents persist,
share, and erase memory across sessions, models, and vendors.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jackson Expires 28 November 2026 [Page 1]
Internet-Draft SAIHM Protocol May 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
1.4. Substrate prerequisites . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Cell shape . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Identity binding (ML-DSA-65) . . . . . . . . . . . . . . 8
2.3. Encryption envelope (HKDF chain) . . . . . . . . . . . . 9
2.4. Audit anchor (public chain) . . . . . . . . . . . . . . . 9
2.5. Sharing contracts . . . . . . . . . . . . . . . . . . . . 10
2.6. Cryptographic erasure . . . . . . . . . . . . . . . . . . 11
3. Tool surface (MCP binding) . . . . . . . . . . . . . . . . . 12
3.1. saihm_remember . . . . . . . . . . . . . . . . . . . . . 12
3.2. saihm_recall . . . . . . . . . . . . . . . . . . . . . . 13
3.3. saihm_forget . . . . . . . . . . . . . . . . . . . . . . 13
3.4. saihm_status . . . . . . . . . . . . . . . . . . . . . . 14
3.5. saihm_share . . . . . . . . . . . . . . . . . . . . . . . 15
3.6. saihm_revoke_share . . . . . . . . . . . . . . . . . . . 16
3.7. saihm_governance_propose . . . . . . . . . . . . . . . . 16
3.8. saihm_governance_vote . . . . . . . . . . . . . . . . . . 17
3.9. Governance form . . . . . . . . . . . . . . . . . . . . . 17
4. Wire formats . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Receipt and audit semantics . . . . . . . . . . . . . . . . . 20
6. Security considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Post-quantum identity . . . . . . . . . . . . . . . . . . 21
6.2. Sovereign key custody . . . . . . . . . . . . . . . . . . 21
6.3. Cryptographic erasure properties . . . . . . . . . . . . 21
6.4. Operator threat model . . . . . . . . . . . . . . . . . . 21
7. Privacy considerations . . . . . . . . . . . . . . . . . . . 22
7.1. GDPR Article 17 alignment . . . . . . . . . . . . . . . . 22
7.2. Minimization . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Audit log content . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Reference deployment . . . . . . . . . . . . . . . . 24
Appendix B. Worked example . . . . . . . . . . . . . . . . . . . 25
B.1. Lifecycle sequence diagram . . . . . . . . . . . . . . . 25
Jackson Expires 28 November 2026 [Page 2]
Internet-Draft SAIHM Protocol May 2026
B.2. Cryptographic example values . . . . . . . . . . . . . . 26
B.3. CBOR encoding walkthrough . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
This document is published through the Independent Submission Stream
of the RFC Series, as defined in [RFC4846] and described in
[RFC8730]. It is not an Internet Standard, and it has not been
reviewed for, nor does it necessarily reflect, the rough consensus of
the IETF community.
1.1. Motivation
The Model Context Protocol [MCP], donated to the Agentic AI
Foundation [AAIF] under the Linux Foundation on 9 December 2025,
defines how an AI agent reaches external tools and contextual data
sources. MCP solves the tool-access layer of the agent stack. It
does not standardize how an agent persists memory across sessions,
models, or vendors. Here, "memory" refers to the holder's content-
addressable cells (Section 2.1), identified by their content
(cellId), not the bytes of an addressable memory in the computer-
architecture sense (Section 1.3).
Production AI agents today rely on one of several non-portable
approaches: a local file system, a vendor-specific session log, or a
vector database. None of these provides post-quantum identity
binding, public-chain audit, cryptographic erasure aligned with
Article 17 of GDPR [GDPR], or wallet-bound sovereignty that prevents
an operator from reading cell content.
This document specifies the Sovereign AI Horizontal Memory (SAIHM)
protocol. SAIHM is a memory-layer protocol that an MCP-capable agent
may attach to gain durable, sovereign, revocably-shareable,
cryptographically-erasable memory. The protocol is operator-
agnostic, vendor-agnostic, and chain-agnostic. Where a public-chain
audit anchor is named, it is named as a reference-deployment
property, not as a protocol mandate.
1.2. Scope
This document defines:
* The cell shape (encrypted memory unit with canonical metadata).
* Identity binding using a post-quantum digital signature algorithm
(ML-DSA-65, [FIPS204]).
Jackson Expires 28 November 2026 [Page 3]
Internet-Draft SAIHM Protocol May 2026
* An encryption envelope deriving a per-cell DEK from the holder's
wallet through a canonical HKDF chain [RFC5869].
* An audit anchor profile, with a reference deployment on a public
chain.
* Sharing contracts (temporary, permanent, syndicate).
* Cryptographic erasure semantics (DEK destruction + tombstone +
content-address blacklist) aligned with GDPR Article 17.
* An MCP binding consisting of eight canonical tools.
This document does NOT define:
* A specific blockchain (the protocol is chain-agnostic).
* Vector-database semantics (orthogonal).
* Agent runtime semantics (covered by MCP and runtime
implementations).
1.3. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
AEAD: Authenticated Encryption with Associated Data, as defined in
[RFC5116]. SAIHM uses an AEAD cipher to encrypt cell payloads;
AES-256-GCM ([NIST-SP-800-38D]) is RECOMMENDED.
canonical request envelope: a CBOR map ([RFC8949]) carrying the
inputs to a SAIHM tool call in a fixed key order. The envelope is
the byte sequence over which the caller computes the ML-DSA-65
signature that authenticates the call. The fixed key order is
enumerated in Section 4.
Cell: an encrypted memory unit, as defined in Section 2.1.
DEK: Data Encryption Key. A per-cell symmetric key derived via HKDF
from the holder's identity key.
HKDF: HMAC-based Extract-and-Expand Key Derivation Function, as
defined in [RFC5869].
Jackson Expires 28 November 2026 [Page 4]
Internet-Draft SAIHM Protocol May 2026
Holder: the natural person, organization, or autonomous agent that
owns the wallet seed bound to a SAIHM cell.
KEK: Key Encryption Key version identifier. A protocol-level
counter that permits cryptographic agility through rotation
without invalidating existing cells.
MCP: the Model Context Protocol [MCP]. In MCP, a "tool" is a
function: a named operation with typed inputs and typed outputs
exposed by an MCP host runtime to a model. SAIHM exposes its
protocol entirely as eight such functions (Section 3).
memory: the aggregate set of SAIHM cells (Section 2.1) bound to a
single holderId. SAIHM memory is content-addressable: each cell
is identified by its cellId, and a holder's memory is the union of
all cells whose holderId matches the holder, minus those for which
an erasure receipt has been anchored. This is distinct from
"memory" in the computer-architecture sense (a contiguous
addressable byte store).
memory-layer protocol: a network-protocol specification whose
subject matter is the persistence, sharing, and erasure of memory
belonging to a holder. A memory-layer protocol defines the
encoding, authentication, integrity, and lifecycle of the at-rest
data, without prescribing the application that produces or
consumes it.
ML-DSA: Module-Lattice-Based Digital Signature Algorithm, as
specified in [FIPS204]. SAIHM authenticates every operation with
an ML-DSA-65 signature.
Operator: the entity providing storage, transport, and audit-anchor
services to a holder. The operator MUST NOT have access to
plaintext cell content.
Receipt: a signed record of a SAIHM operation, anchored on a public
chain.
sentinel value: a designated in-band value that signals the absence
of an ordinary value of the same type. In Section 2.5, expiresAt
= 0 is the sentinel signalling "no time bound". The sentinel
preserves a flat representation of the contract tuple; a separate
boolean flag field would carry the same information at the cost of
an additional field. This document retains the sentinel for
representational economy.
storage tier: a named, operator-chosen persistence backend with
Jackson Expires 28 November 2026 [Page 5]
Internet-Draft SAIHM Protocol May 2026
stated durability and retention properties. The tier value
("FILECOIN" is the example given in the reference deployment) is
deployment metadata; the protocol does not prescribe a particular
tier, and tier names have no protocol semantics beyond serving as
a hint to the operator-side storage router.
UNIX epoch: the time reference defined in [IEEE-1003.1-2024] under
"Seconds Since the Epoch". All SAIHM timestamps are encoded as
unsigned integer seconds since the UNIX epoch.
wallet seed: a high-entropy secret value held by the holder, from
which the holder's identity key is derived (Section 2.2). The
wallet seed is generated, stored, and rotated by a wallet
implementation external to this protocol; this document does not
specify how the wallet seed is generated or stored.
1.4. Substrate prerequisites
A conformant SAIHM implementation depends on the following external
substrates. Where a substrate is itself an IETF or NIST normative
reference, it appears in the Normative References. Where a substrate
is selected per deployment, the deployment is responsible for stating
which selection it uses.
(a) A wallet implementation capable of producing a high-entropy
secret of at least 256 bits, which the holder retains as the
wallet seed (Section 2.2). The protocol does not specify how
the wallet seed is generated, stored, or rotated.
(b) An implementation of HKDF as defined in [RFC5869], used for
identity-key derivation and per-cell DEK derivation.
(c) An implementation of ML-DSA-65 conformant with [FIPS204].
(d) An implementation of an AEAD cipher conformant with [RFC5116].
AES-256-GCM ([NIST-SP-800-38D]) is RECOMMENDED.
(e) An implementation of SHA-256 ([FIPS180-4]) for cellId
derivation.
(f) A CBOR codec conformant with [RFC8949] for cell and receipt
encoding.
(g) A Model Context Protocol (MCP) host runtime exposing the SAIHM
tool functions over the MCP transport.
Jackson Expires 28 November 2026 [Page 6]
Internet-Draft SAIHM Protocol May 2026
(h) A public chain offering transactional finality and public-record
properties, used for receipt anchoring. Per-deployment
selection; the reference deployment uses COTI V2 (chain ID
2632500). Implementations MAY choose any chain offering
equivalent properties.
(i) A storage tier exposing PUT, GET, and DELETE semantics over an
opaque ciphertext blob. Per-deployment selection; the reference
deployment uses a Filecoin tier.
2. Architecture
2.1. Cell shape
A SAIHM cell is the tuple:
<cellId, holderId, kekVersion, tier, cellNonce, ciphertext,
signature, timestamp>
cellId: 32-byte content-addressable identifier. cellId MUST be
computed as
cellId = SHA-256( kekVersion_be32 ||
cellNonce ||
ciphertext )
where:
kekVersion_be32 is kekVersion encoded as a 4-byte big-endian
unsigned integer;
cellNonce is the 16-byte cellNonce defined in Section 2.3;
ciphertext is the AEAD output, including the authentication
tag;
|| denotes octet concatenation.
The output is the raw 32-byte SHA-256 digest. For transport on
the MCP tool surface, cellId is conveyed as a lowercase
hexadecimal string of length 64.
Including kekVersion and cellNonce in the derivation ensures that
the same plaintext encrypted under a different KEK generation or
with a different per-cell nonce produces a distinct cellId,
eliminating cross-KEK and cross-nonce collisions.
Jackson Expires 28 November 2026 [Page 7]
Internet-Draft SAIHM Protocol May 2026
At read time, implementations MUST recompute cellId from the
cell's kekVersion, cellNonce, and ciphertext fields and MUST
reject any cell whose stored cellId does not match the
recomputation. Because cellNonce is a public field, this
recomputation is the integrity check that prevents an operator
from substituting cellNonce after the holder's signature is
computed.
holderId: 32-byte holder identity, derived from the holder's wallet
seed (Section 2.2).
kekVersion: 32-bit unsigned integer identifying the KEK generation
in force at write time.
tier: short ASCII string naming the operator's storage tier (e.g.,
"FILECOIN").
cellNonce: 16-byte per-cell random value, used both in DEK
derivation (Section 2.3) and in cellId derivation (above).
cellNonce is a public field, transmitted with the cell to permit
the cellId recomputation check above.
ciphertext: cell payload encrypted with the per-cell DEK under an
AEAD cipher. AES-256-GCM is RECOMMENDED.
signature: ML-DSA-65 signature over the concatenation (cellId ||
holderId || kekVersion_be32 || timestamp_be64). When timestamp
appears in any concatenated byte sequence over which a signature
is computed, it MUST be encoded as 8 bytes in big-endian order
(timestamp_be64).
timestamp: 64-bit unsigned integer. UTC seconds since the UNIX
epoch as defined in [IEEE-1003.1-2024] ("Seconds Since the
Epoch"). Implementations MUST NOT use a 32-bit signed
representation. A 32-bit signed encoding of UNIX time overflows
at 03:14:07Z on 19 January 2038; implementations encountering
values produced by such an encoding MUST treat the affected
receipts as malformed. The 64-bit unsigned representation
supports values up to 2^64 - 1 seconds since the epoch, exceeding
any practical time horizon by many orders of magnitude.
2.2. Identity binding (ML-DSA-65)
Holder identity is derived from a wallet seed via the canonical HKDF
chain:
Jackson Expires 28 November 2026 [Page 8]
Internet-Draft SAIHM Protocol May 2026
identityKey = HKDF(salt = "MPS-PQC-KEY-GEN-v1",
IKM = walletSeed,
info = "MPS-AGENT-IDENTITY-v1",
L = 64 bytes)
identityKey is then used as the seed for ML-DSA-65 keypair generation
per [FIPS204]. The public component is holderId; the private
component MUST NOT leave the holder's machine.
Every SAIHM operation MUST be authenticated by an ML-DSA-65 signature
over the operation's canonical envelope. Verification MUST follow
[FIPS204] using the public holderId.
2.3. Encryption envelope (HKDF chain)
For each cell, the holder derives a per-cell DEK:
DEK = HKDF(salt = KEK_v,
IKM = identityKey,
info = cellNonce || "MPS-CELL-DEK-v1",
L = 32 bytes)
where KEK_v is the current KEK generation and cellNonce is a per-cell
16-byte random value. The DEK is used directly with the AEAD cipher
to encrypt the cell payload.
KEK rotation is versioned. An operator MAY rotate the KEK under
operator-defined policy; rotation does not invalidate existing cells
because each cell carries its kekVersion. Implementations MUST
verify the kekVersion at read time and reject cells whose KEK has
been revoked.
2.4. Audit anchor (public chain)
For each operation (write, read, share, revoke, erase) the protocol
emits a receipt:
<receiptId, cellId, operation, holderId, signature, timestamp>
The receipt is anchored on a public chain offering transactional
finality and public-record properties. Anchoring MUST produce a
chain-reachable identifier sufficient to reproduce the receipt
independently.
Jackson Expires 28 November 2026 [Page 9]
Internet-Draft SAIHM Protocol May 2026
Reference deployment: COTI V2 mainnet, chain ID 2632500, block
explorer https://mainnet.cotiscan.io. Implementations MAY use any
public chain offering equivalent finality and public-record
properties. The chain choice is a deployment decision; this protocol
does not mandate one.
2.5. Sharing contracts
A holder MAY share a cell with a grantee through a signed sharing
contract:
<contractId, cellId, granteeId, mode, expiresAt, holderSignature>
mode is one of:
TEMPORARY: revocable; expiresAt MUST be no later than timestamp +
86400 seconds (24 hours).
PERMANENT: revocable; expiresAt MUST be the sentinel value 0 (no
time bound).
SYNDICATE: A single sharing contract that names an ordered list of
granteeIds rather than a single granteeId. The contract is atomic
in two senses: all listed grantees gain access in a single signed
event, and a single counter-signed contractRevocation removes
access for every listed grantee simultaneously. expiresAt MAY be
0 (no time bound) or a future timestamp.
SYNDICATE validation by the operator:
(a) The operator MUST verify the holder's ML-DSA-65 signature
over the full contract, including the full grantee list.
(b) On saihm_recall by an entity X, the operator MUST include
cells from any active SYNDICATE contract whose grantee list
contains X's holderId.
(c) On contractRevocation, the operator MUST cease serving the
cell to every member of the grantee list from the moment the
revocation is anchored on chain.
SYNDICATE use cases include sharing the memory of a multi-party
deliberation (e.g., a deal syndicate or an incident-response team)
with a fixed grantee set, where per-grantee TEMPORARY contracts
would multiply administration cost and where issuing the same
memory N times under N TEMPORARY contracts would multiply the
anchored-receipt cost.
Jackson Expires 28 November 2026 [Page 10]
Internet-Draft SAIHM Protocol May 2026
Revocation is performed via a counter-signed contractRevocation
anchored on chain. Once anchored, the revocation takes effect
immediately; subsequent recall attempts by the grantee MUST be
rejected by the operator.
2.6. Cryptographic erasure
The erase operation is atomic at the cryptographic layer:
1. The holder destroys the DEK for the target cell.
2. A tombstone is emitted, carrying cellId and a timestamp.
3. The cell's cellId is added to a public blacklist (see below).
4. An audit receipt is anchored on chain.
Because the operator never held the DEK (Section 2.3), the ciphertext
at rest is computationally meaningless from the moment of DEK
destruction. Erasure is irreversible by the operator.
The blacklist is a public, append-only set of cellIds. An entry is
added to the blacklist when, and only when, the operator anchors an
erasure receipt for that cellId on the audit chain. Each erasure
receipt's payload carries the cellId of the erased cell; the act of
anchoring a valid erasure receipt is the act of adding the cellId to
the blacklist.
The blacklist construct is mandatory: every successful saihm_forget
operation MUST result in (i) destruction of the DEK by the holder,
(ii) anchoring of an erasure receipt by the operator, and (iii)
inclusion of the erased cellId in the blacklist by virtue of (ii).
The blacklist is reproducible from the audit chain by any observer:
scan all anchored receipts whose operation field equals "FORGET" and
project the cellId field. Operators MAY publish a cached, queryable
form of the blacklist for latency-sensitive consumers; the cached
form MUST be reproducible from the chain.
Implementations MUST consult the blacklist on every saihm_recall and
MUST NOT return any cell whose cellId is blacklisted, regardless of
whether the requesting party is the original holder, a TEMPORARY
grantee, a PERMANENT grantee, or a SYNDICATE grantee. The protocol
does not prescribe a particular index structure (e.g., Bloom filter,
sorted set, on-chain Merkle accumulator); implementations choose one
matching their scale and latency requirements.
Jackson Expires 28 November 2026 [Page 11]
Internet-Draft SAIHM Protocol May 2026
3. Tool surface (MCP binding)
In the Model Context Protocol [MCP], a "tool" is a function: a named
operation with typed inputs and typed outputs that an MCP host
runtime exposes to the model. The eight SAIHM tools defined below
are functions in this sense; each subsection gives the tool's
signature in TypeScript-like notation, followed by its pre-
conditions, behavior, post-conditions, and error returns.
SAIHM exposes the protocol entirely through MCP using eight tools.
Each tool MUST authenticate the caller with an ML-DSA-65 signature
(Section 2.2) over the tool's canonical request envelope.
The tool surface is intentionally bounded at eight. The bound is a
design constraint imposed by this specification, not an upper limit
imposed by MCP. The motivation is that a small, fixed tool surface
is easier for agent runtime authors and security reviewers to audit,
version, and reason about than an open-ended tool list.
Protocol evolution within this bounded surface proceeds through three
mechanisms:
(i) KEK rotation: an operational change in which the same eight
tools continue to operate under a new KEK generation
(Section 2.3). Existing cells remain readable so long as
their kekVersion has not been revoked.
(ii) Governance vote: a protocol-level parameter change proposed
via saihm_governance_propose (Section 3.7) and ratified via
saihm_governance_vote (Section 3.8). The set of governance
scopes is itself governance-mutable.
(iii) Parameter changes within existing tool signatures: new
sharing-contract modes (Section 2.5), new governance scopes
(Section 3.7), or new payload fields are introduced by
extending the typed input of an existing tool, not by adding a
new tool.
A future major revision of this protocol MAY add or remove tools.
Within this revision, the surface is fixed at eight.
3.1. saihm_remember
Signature: saihm_remember(content: string) -> cellId
Pre-conditions: Caller is the holder. The holder's wallet seed is
Jackson Expires 28 November 2026 [Page 12]
Internet-Draft SAIHM Protocol May 2026
locally available to the holder-side runtime. The caller has
constructed a canonical request envelope and signed it with the
holder's ML-DSA-65 identity key.
Behavior: The holder derives a per-cell DEK (Section 2.3), encrypts
content under an AEAD cipher to produce ciphertext, computes
cellId (Section 2.1), signs the canonical envelope, and submits
the cell to the operator. The operator persists the ciphertext to
the holder-named storage tier and anchors a write receipt on the
audit chain (Section 2.4).
Post-conditions: A cell with the returned cellId is retrievable via
saihm_recall. A write receipt for cellId is anchored on the audit
chain.
Errors: "no_wallet_seed", "envelope_signature_invalid",
"operator_storage_unavailable", "operator_chain_unavailable",
"rate_limited".
3.2. saihm_recall
Signature: saihm_recall(query?: string) -> cells[]
Pre-conditions: Caller is the holder, or a grantee under an active
sharing contract that names the caller's holderId.
Behavior: The operator returns ciphertexts for all cells whose
holderId matches the caller, plus ciphertexts from active sharing
contracts naming the caller (Section 2.5). Cells whose cellId is
on the public blacklist (Section 2.6) are omitted. The caller
decrypts client-side and applies the optional query filter after
decryption. query MUST NOT be transmitted to the operator.
Post-conditions: The returned cell set reflects the operator's view
at recall time. Blacklisted cells MUST NOT appear in the returned
set.
Errors: None beyond transport faults.
3.3. saihm_forget
Signature: saihm_forget(cellId: string) -> tombstone
Pre-conditions: Caller is the holder of the named cell. The
caller's wallet seed is locally available.
Behavior: The holder destroys the per-cell DEK for cellId. The
Jackson Expires 28 November 2026 [Page 13]
Internet-Draft SAIHM Protocol May 2026
operator anchors an erasure receipt on the audit chain, emits a
tombstone, and adds cellId to the public blacklist (Section 2.6).
After saihm_forget returns success, the cell content MUST be
computationally non-recoverable by any party, including the
operator.
Post-conditions: cellId appears on the public blacklist. The DEK
for cellId is destroyed; the ciphertext at rest is computationally
meaningless. Subsequent saihm_recall calls MUST NOT return the
cell.
Errors: "not_holder", "cell_not_found", "already_erased",
"operator_chain_unavailable".
3.4. saihm_status
Signature: saihm_status() -> { prs, bfsi, bfsi_R, bfsi_M,
bfsi_window_start_ts, shards, contracts, governance }
Pre-conditions: Caller is the holder.
Behavior: The operator computes the dashboard fields per the schema
specified in this subsection (and CBOR-encoded in Section 4).
Post-conditions: The returned dashboard reflects operator-recorded
state at the time of call. The bfsi inputs (bfsi_R, bfsi_M,
bfsi_window_start_ts) are sufficient for the caller to reproduce
the bfsi computation.
Errors: None beyond transport faults.
Return value (an object with the following fields):
prs: IEEE 754 binary64 in the closed interval [0.0, 1.0]. Process
Reliability Score: the fraction of the operator's expected tool-
call returns delivered within the operator's published SLA window,
computed over a rolling 30-day window.
bfsi: IEEE 754 binary64 in the closed interval [0.0, 1.0].
Byzantine Fault Score Index: the fraction of audit-chain receipts
that match a corresponding holder-side tool-call event, computed
over the same 30-day rolling window. Formally,
bfsi = 1 - (M / R)
where R is the count of operator-anchored receipts on the audit
chain attributed to the holder over the window, and M is the count
of those receipts for which no corresponding tool-call event is
Jackson Expires 28 November 2026 [Page 14]
Internet-Draft SAIHM Protocol May 2026
attested in the holder's local event log. When R = 0 (no operator
receipts attributed to the holder in the window), bfsi is defined
as 1.0 by convention; this signals absence of fault evidence
rather than positive integrity, and the bfsi_R field (below)
discloses the underlying R = 0 to the holder. bfsi is not opaque;
the inputs (R, M, and the window boundary) MUST be exposed to the
holder through the same saihm_status call under the fields
bfsi_window_start_ts, bfsi_R, and bfsi_M, so that any holder or
auditor can reproduce the computation.
A bfsi below the operator's published operator-integrity threshold
(the reference deployment publishes 0.99 as the threshold) is a
signal to the holder that operator integrity is degrading and is
grounds for migration to another operator.
bfsi_window_start_ts: Unsigned integer, UNIX epoch seconds. The
start of the rolling 30-day window over which bfsi (and prs) is
computed.
bfsi_R: Unsigned integer. The count of operator-anchored receipts
on the audit chain attributed to the holder over the window.
bfsi_M: Unsigned integer. The count of those receipts for which no
corresponding tool-call event is attested in the holder's local
event log.
shards: a CBOR map keyed by tier name, value = unsigned integer
count of cells stored under that tier.
contracts: a CBOR array of objects, each with fields contractId
(32-byte hex), mode (string enum: "TEMPORARY" | "PERMANENT" |
"SYNDICATE"), granteeIds (array of 32-byte hex), expiresAt
(unsigned integer, UNIX epoch seconds).
governance: a CBOR array of objects, each with fields propId
(32-byte hex), scope (string), opens_ts (unsigned integer),
closes_ts (unsigned integer), tally_for (unsigned integer),
tally_against (unsigned integer), tally_abstain (unsigned
integer).
The full CBOR schema for the saihm_status return appears in
Section 4.
3.5. saihm_share
Signature: saihm_share(cellId: string, granteeAgentId: string |
string[], mode: "TEMPORARY" | "PERMANENT" | "SYNDICATE") ->
contractId
Jackson Expires 28 November 2026 [Page 15]
Internet-Draft SAIHM Protocol May 2026
Pre-conditions: Caller is the holder of cellId.
Behavior: The holder emits a signed sharing contract granting access
per the mode semantics (Section 2.5). For SYNDICATE mode,
granteeAgentId is an array; for TEMPORARY and PERMANENT,
granteeAgentId is a single value.
Post-conditions: The named grantee(s) gain saihm_recall access to
cellId per the mode's lifecycle. A share receipt is anchored on
the audit chain.
Errors: "not_holder", "cell_not_found", "invalid_mode",
"syndicate_grantees_empty", "operator_chain_unavailable".
3.6. saihm_revoke_share
Signature: saihm_revoke_share(contractId: string) -> revocationId
Pre-conditions: Caller is the holder party to the contract named by
contractId.
Behavior: The holder emits a counter-signed contractRevocation. The
operator ceases serving cell access to the contract's grantee(s)
from the moment the revocation is anchored on chain.
Post-conditions: The revocation is anchored on the audit chain.
Subsequent saihm_recall by the grantee(s) MUST NOT return the cell
under this contract.
Errors: "not_holder", "contract_not_found", "already_revoked",
"operator_chain_unavailable".
3.7. saihm_governance_propose
Signature: saihm_governance_propose(scope: string, payload: object)
-> propId
Pre-conditions: Caller satisfies the deployment's eligibility-to-
propose predicate (Section 3.9). scope is one of the deployment's
declared proposal scopes.
Behavior: The caller submits a signed proposal. The operator
anchors the proposal receipt on the audit chain. The voting
window opens.
Post-conditions: A proposal with propId is published; it accepts
saihm_governance_vote calls for the deployment's voting window
duration.
Jackson Expires 28 November 2026 [Page 16]
Internet-Draft SAIHM Protocol May 2026
Errors: "ineligible_proposer", "unknown_scope",
"operator_chain_unavailable".
3.8. saihm_governance_vote
Signature: saihm_governance_vote(propId: string, vote: "FOR" |
"AGAINST" | "ABSTAIN") -> voteReceipt
Pre-conditions: Caller satisfies the deployment's eligibility-to-
vote predicate (Section 3.9). propId names an open proposal.
Behavior: The caller submits a signed vote. The operator anchors
the vote receipt on the audit chain. The proposal's tally
updates.
Post-conditions: The vote is anchored. The proposal's tally on the
audit chain reflects the vote per the deployment's vote-weight
function. Vote tallies MUST be reproducible from the audit chain.
Errors: "ineligible_voter", "proposal_not_found", "proposal_closed",
"operator_chain_unavailable".
3.9. Governance form
This protocol defines a governance hook (saihm_governance_propose,
saihm_governance_vote) but does not mandate a single governance form.
The set of governance scopes is itself governance-mutable, so a
deployment is free to evolve its governance policy without revising
this protocol.
Every deployment MUST publish its governance form, comprising at
least the following parameters, at a stable URL referenced from the
deployment's saihm_status output:
(a) Eligibility to propose: the predicate over a holderId that
determines whether the holder may submit a proposal.
(b) Eligibility to vote: the predicate over a holderId that
determines whether the holder may cast a vote.
(c) Vote weight: the function mapping a holderId to a non-negative
real number, contributing to the tally.
(d) Threshold: the predicate over a tally that determines whether a
proposal passes.
(e) Voting window: the duration in seconds during which
saihm_governance_vote calls are accepted for a given propId.
Jackson Expires 28 November 2026 [Page 17]
Internet-Draft SAIHM Protocol May 2026
(f) Proposal scopes: the enumeration of permitted scope values for
saihm_governance_propose.
The reference governance form, used by the reference deployment, has
the following values for the parameters above:
(a) Eligibility to propose: any holderId for which at least one
saihm_remember receipt has been anchored on the audit chain.
(b) Eligibility to vote: same as (a).
(c) Vote weight: the holderId's balance of governance soul-bound
tokens (SBTs) at the moment the proposal is anchored. SBTs are
non-transferable, non-purchasable tokens minted to a holderId in
exchange for verified, on-chain SAIHM protocol activity. The
exact issuance schedule (which protocol events mint how many
SBTs, at what cadence, and up to what cap) is deployment policy
and is published at the deployment's governance URL.
(d) Threshold: (tally_for > tally_against) AND (tally_for +
tally_against >= 0.10 * sum of all eligible SBT balances at
proposal anchor time).
(e) Voting window: 1209600 seconds (14 days) from anchoring of the
proposal receipt.
(f) Proposal scopes: enumerated at https://saihm.coti.global/
governance.
Sybil-resistance note: the reference governance form above is
hardened against Sybil attack by the soul-bound, non-transferable
nature of the governance SBTs and by the requirement that SBTs be
earned through demonstrated SAIHM protocol use rather than purchased
or transferred. A party that spawns N wallets to multiply identity
gains at most the minimum SBT yield per wallet (the floor that
issuance policy permits for a newly active holderId); a long-standing
legitimate holder accumulates SBTs over time at a rate that this
Sybil strategy cannot match without performing equivalent legitimate
protocol activity, by construction. Deployments that need a
different Sybil-resistance posture (for example, identity
attestation, KYC, or proof-of-stake at scale) MAY substitute an
alternative governance form, subject to constraints (i)-(iii) below.
Implementations MAY substitute alternative governance forms (for
example, stake-weighted, multi-signature board, or DAO-contract
governance) so long as
Jackson Expires 28 November 2026 [Page 18]
Internet-Draft SAIHM Protocol May 2026
(i) the saihm_governance_propose and saihm_governance_vote tool
signatures remain unchanged;
(ii) vote outcomes are reproducible from the audit chain; and
(iii) the parameters (a)-(f) above are published at a stable URL
referenced from saihm_status.
4. Wire formats
SAIHM uses Concise Binary Object Representation (CBOR) [RFC8949] for
cell payloads and receipts, and JSON-RPC 2.0 over the MCP transport
for tool calls. All timestamps appearing in CBOR-encoded payloads
MUST be CBOR unsigned integers (CBOR major type 0); no SAIHM emitter
or parser is permitted to clamp to a signed 32-bit window
(Section 2.1).
A canonical cell payload (CBOR diagnostic notation):
{1: h'...cellId...',
2: h'...holderId...',
3: 1,
4: "FILECOIN",
5: h'...cellNonce-16-bytes...',
6: h'...ciphertext...',
7: h'...signature...',
8: 1747526400}
The integer keys correspond to fields defined in Section 2.1:
1=cellId, 2=holderId, 3=kekVersion, 4=tier, 5=cellNonce,
6=ciphertext, 7=signature, 8=timestamp.
A canonical receipt (CBOR diagnostic notation):
{1: h'...receiptId...',
2: h'...cellId...',
3: "REMEMBER",
4: h'...holderId...',
5: h'...signature...',
6: 1747526400}
For erasure receipts (operation = "FORGET"), the receipt payload's
cellId field carries the cellId added to the blacklist (Section 2.6).
A canonical saihm_status return (CBOR diagnostic notation):
Jackson Expires 28 November 2026 [Page 19]
Internet-Draft SAIHM Protocol May 2026
{"prs": 0.997,
"bfsi": 1.0,
"bfsi_window_start_ts": 1745020800,
"bfsi_R": 0,
"bfsi_M": 0,
"shards": {"FILECOIN": 42},
"contracts": [
{"contractId": h'...32-bytes...',
"mode": "TEMPORARY",
"granteeIds": [h'...32-bytes...'],
"expiresAt": 1747612800}
],
"governance": [
{"propId": h'...32-bytes...',
"scope": "kek-rotation-cadence",
"opens_ts": 1747000000,
"closes_ts": 1748209600,
"tally_for": 1240,
"tally_against": 18,
"tally_abstain": 5}
]}
5. Receipt and audit semantics
For each tool call that mutates state (saihm_remember, saihm_forget,
saihm_share, saihm_revoke_share, saihm_governance_propose,
saihm_governance_vote), the operator MUST emit a receipt anchored on
the audit chain.
The receipt MUST include the operation type, the cellId (or
contractId, or propId), the holderId, and the timestamp.
The receipt MUST NOT include cell plaintext, the DEK, or the wallet
seed.
Receipts for erasure (saihm_forget) MUST also include the tombstone
identifier and the cellId added to the blacklist (Section 2.6).
Read-only tool calls (saihm_recall, saihm_status) MAY emit receipts
under operator policy; receipts for read-only calls MUST NOT include
cell plaintext.
6. Security considerations
Jackson Expires 28 November 2026 [Page 20]
Internet-Draft SAIHM Protocol May 2026
6.1. Post-quantum identity
ML-DSA-65 [FIPS204] is the protocol's authentication primitive. ML-
DSA-65 is a NIST-selected post-quantum digital signature algorithm in
the FIPS-204 family. An adversary with a cryptographically relevant
quantum computer cannot forge SAIHM signatures.
Implementations MUST use the FIPS-204 parameter set named ML-DSA-65.
Implementations SHOULD include the kekVersion in every signed
envelope so that key-rotation events are themselves signed.
6.2. Sovereign key custody
The wallet seed and the derived identity key MUST NOT leave the
holder's machine. The protocol does not provide key escrow. A
holder who loses the wallet seed loses access to their cells; the
operator cannot recover access on behalf of the holder.
This is intentional. The operator's inability to recover the wallet
seed is the same property that prevents the operator from reading
cell content.
6.3. Cryptographic erasure properties
Cryptographic erasure (Section 2.6) provides stronger evidence than
logical (soft) deletion. Because the DEK is destroyed at the holder
side, ciphertext at rest is computationally meaningless to any party,
including the operator.
Backups and replicas store only ciphertext. DEK destruction
propagates erasure semantics to every copy of the ciphertext,
anywhere, automatically. An operator MUST NOT cache the DEK.
6.4. Operator threat model
The protocol assumes an honest-but-curious operator: the operator is
expected to provide storage and transport honestly but MAY attempt to
learn cell content.
Against an honest-but-curious operator:
* Cell plaintext is never accessible to the operator (encryption-
before-egress + per-cell DEK).
* Cell signatures are reproducible from public keys, so the operator
cannot inject forged cells.
Jackson Expires 28 November 2026 [Page 21]
Internet-Draft SAIHM Protocol May 2026
* Receipt validity is verifiable against the public chain, so the
operator cannot rewrite the audit trail.
Against a malicious operator (one that deviates from the protocol),
additional measures (e.g., threshold-replicated storage, multi-chain
receipt anchoring) may be advisable but are out of scope for this
protocol layer.
7. Privacy considerations
7.1. GDPR Article 17 alignment
The saihm_forget operation provides cryptographic-grade evidence of
erasure aligned with Article 17 of Regulation (EU) 2016/679 [GDPR].
The DEK is destroyed; a tombstone is published; the cellId is
blacklisted; and a receipt is anchored on chain.
Article 17 requires erasure "without undue delay". saihm_forget is
atomic at the cryptographic layer; there is no operator-side deletion
queue that could fail to drain.
7.2. Minimization
The audit log records cellId, holderId, operation, and timestamp. It
MUST NOT record cell plaintext, the DEK, or the wallet seed. An
auditor observing the chain learns when and by whom each operation
was performed, but not the content of any cell.
7.3. Audit log content
Receipts anchored on chain are public. Holders SHOULD treat the
existence of a cell (cellId, holderId, timestamp) as publicly
observable. Where the existence of a record is itself sensitive,
holders SHOULD use additional countermeasures outside the scope of
this protocol (e.g., pseudonymous holder identities, batched-
operation timing).
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
Jackson Expires 28 November 2026 [Page 22]
Internet-Draft SAIHM Protocol May 2026
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
<https://csrc.nist.gov/pubs/fips/180-4/upd1/final>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS PUB 204,
August 2024, <https://csrc.nist.gov/pubs/fips/204/final>.
[IEEE-1003.1-2024]
IEEE, "IEEE Standard for Information Technology--Portable
Operating System Interface (POSIX(TM)) Base
Specifications, Issue 8", IEEE Std 1003.1-2024, June 2024,
<https://standards.ieee.org/ieee/1003.1/7700/>.
[NIST-SP-800-38D]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP
800-38D, November 2007,
<https://csrc.nist.gov/pubs/sp/800/38/d/final>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
9.2. Informative References
[AAIF] Linux Foundation, "Agentic AI Foundation", 9 December
2025, <https://aaif.io/>.
Jackson Expires 28 November 2026 [Page 23]
Internet-Draft SAIHM Protocol May 2026
[EU-AI-ACT]
European Parliament and Council, "Regulation (EU)
2024/1689 of the European Parliament and of the Council of
13 June 2024 (Artificial Intelligence Act)", June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
[GDPR] European Parliament and Council, "Regulation (EU) 2016/679
of the European Parliament and of the Council of 27 April
2016 (General Data Protection Regulation)", April 2016,
<https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
[ISO-27001]
ISO/IEC, "ISO/IEC 27001:2022 Information security
management systems --- Requirements", October 2022.
[ISO-42001]
ISO/IEC, "ISO/IEC 42001:2023 Information technology ---
Artificial intelligence --- Management system", December
2023.
[MCP] Anthropic, "Model Context Protocol Specification", Donated
to the Agentic AI Foundation under the Linux Foundation on
9 December 2025, 25 November 2025,
<https://modelcontextprotocol.io/>.
[NIST-AI-RMF]
National Institute of Standards and Technology, "AI Risk
Management Framework 1.0", NIST AI 100-1, January 2023,
<https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>.
[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the
RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007,
<https://www.rfc-editor.org/info/rfc4846>.
[RFC8730] Brownlee, N. and R. Hinden, "Independent Submission Editor
Model", RFC 8730, DOI 10.17487/RFC8730, February 2020,
<https://www.rfc-editor.org/info/rfc8730>.
Appendix A. Reference deployment
The reference SAIHM deployment runs on the COTI V2 Helium mainnet
(chain ID 2632500). Protocol implementations MAY anchor receipts on
any public chain offering equivalent transactional finality and
public-record properties. The chain choice is a deployment decision;
the protocol does not mandate one.
The reference deployment publishes:
Jackson Expires 28 November 2026 [Page 24]
Internet-Draft SAIHM Protocol May 2026
* npm reference implementation: @saihm/mcp-server (Apache 2.0).
* Block explorer for chain receipts: https://mainnet.cotiscan.io.
* Crosswalks to NIST AI RMF [NIST-AI-RMF], ISO/IEC 42001
[ISO-42001], ISO/IEC 27001 [ISO-27001], EU AI Act [EU-AI-ACT],
GDPR Article 17 [GDPR], and MCP [MCP] at
https://saihm.coti.global/standards.
Appendix B. Worked example
This appendix walks through the canonical SAIHM cell lifecycle with
concrete, illustrative values. All cryptographic inputs labelled
"TEST" are derived from a well-known test wallet seed and MUST NOT be
used for production cells.
B.1. Lifecycle sequence diagram
The canonical lifecycle saihm_remember -> saihm_recall -> saihm_share
-> saihm_revoke_share -> saihm_forget, with the actor (holder agent,
operator, public chain) and the message at each hop:
Holder agent Operator Public chain
============ ======== ============
| | |
| saihm_remember | |
| (envelope, sig) | |
|-------------------->| |
| | persist ciphertext |
| | to storage tier |
| |---------------------->|
| | write receipt |
| | anchored (txid) |
| |<----------------------|
| cellId | |
|<--------------------| |
| | |
| saihm_recall | |
| (envelope, sig) | |
|-------------------->| |
| cells[] | |
| (ciphertext) | |
|<--------------------| |
| (decrypt locally) | |
| | |
| saihm_share | |
| (cellId, grantee, | |
| mode) | |
Jackson Expires 28 November 2026 [Page 25]
Internet-Draft SAIHM Protocol May 2026
|-------------------->| |
| | contract + |
| | share receipt |
| |---------------------->|
| | anchored (txid) |
| |<----------------------|
| contractId | |
|<--------------------| |
| | |
| saihm_revoke_share | |
| (contractId) | |
|-------------------->| |
| | contractRevocation + |
| | revoke receipt |
| |---------------------->|
| | anchored (txid) |
| |<----------------------|
| revocationId | |
|<--------------------| |
| | |
| saihm_forget | |
| (cellId) | |
| [holder destroys | |
| DEK locally] | |
|-------------------->| |
| | erasure receipt + |
| | tombstone + |
| | cellId blacklisted |
| |---------------------->|
| | anchored (txid) |
| |<----------------------|
| tombstone | |
|<--------------------| |
B.2. Cryptographic example values
The following values are derived from a labelled test wallet seed and
are intended only to demonstrate the HKDF, AEAD, SHA-256, and CBOR
derivations defined in the body of this document. Any FIPS-
204-conformant ML-DSA-65 implementation, RFC 5869 HKDF
implementation, and RFC 5116 AEAD implementation will reproduce these
values from the inputs given.
Test wallet seed (32 bytes, hex), derived as SHA-256("SAIHM-TEST-
VECTOR-001-DO-NOT-USE-IN-PRODUCTION"):
walletSeed (TEST) =
f068b8db8484d33bdbedd154bf5bf28e11fba330b79469e23595d6f738d7f5c6
Jackson Expires 28 November 2026 [Page 26]
Internet-Draft SAIHM Protocol May 2026
HKDF identity derivation (Section 2.2):
identityKey =
HKDF(salt = "MPS-PQC-KEY-GEN-v1",
IKM = walletSeed,
info = "MPS-AGENT-IDENTITY-v1",
L = 64 bytes)
=
fdf786da8cb1f074393f9ad6dec1671e08085540e95c8463c9f2e15f437bbc5a
2c267aeaf355e79d8968cc21846cdff7e16f498437de3d6b1fd290703eeed9c2
holderId (32 bytes, hex), presented as the test holder's protocol-
level identifier:
holderId (TEST) =
ab4f746fd1520d2736854559d6751969ae9127f5dbc607d7298acbf1afb1f588
KEK generation: kekVersion = 1.
Per-cell nonce (16 bytes, hex):
cellNonce =
25bd74b827789faacad8ffb7593c2359
Cell plaintext:
plaintext =
"Hello, SAIHM. This is a test memory cell."
DEK derivation (Section 2.3):
DEK =
HKDF(salt = KEK_v (4-byte big-endian of kekVersion=1),
IKM = identityKey,
info = cellNonce || "MPS-CELL-DEK-v1",
L = 32 bytes)
=
a1e54f730c6c7a1048ae436c9d2b179821c6eddd7841f41e36215285f3ffd07a
AEAD encryption (AES-256-GCM, [NIST-SP-800-38D]) using the first 12
bytes of cellNonce as the GCM IV in this test vector; the protocol
does not prescribe an AEAD-IV derivation, and deployments select one:
ciphertext (57 bytes, including 16-byte GCM tag) =
595b0b9f77a8d95f29c5affa151bbcc18fdc3f7e5223792627919ee2d52f2bf2
4933c35de4c1755559bee818ef54b48a388bcdd2e4a30fbde8
cellId derivation (Section 2.1):
Jackson Expires 28 November 2026 [Page 27]
Internet-Draft SAIHM Protocol May 2026
cellId =
SHA-256( kekVersion_be32 || cellNonce || ciphertext )
=
d851960a5b7754c5884c96bef5d615e666c8ad006e4ceebe028cd85aae8e7c2f
timestamp = 1747526400 (UTC 2025-05-18T00:00:00Z; encoded as 8 bytes
big-endian when used in signature concatenation).
signature: ML-DSA-65 ([FIPS204]) over (cellId || holderId ||
kekVersion_be32 || timestamp_be64). The signature is 3309 bytes; the
first 32 bytes are shown for illustration, and the full signature is
reproducible from a FIPS-204-conformant ML-DSA-65 implementation
given the test wallet seed above:
signature (first 32 of 3309 bytes) =
dba1109b3d53e17290914cdb2e639c6cdad37aff8184537ba9b2c05c7fe8a994
... (3277 more bytes) ...
B.3. CBOR encoding walkthrough
The canonical CBOR encoding of the example cell, per the schema in
Section 4:
{1: h'd851960a5b7754c5884c96bef5d615e666c8ad006e4ceebe028cd85aae8e7c2f',
2: h'ab4f746fd1520d2736854559d6751969ae9127f5dbc607d7298acbf1afb1f588',
3: 1,
4: "FILECOIN",
5: h'25bd74b827789faacad8ffb7593c2359',
6: h'595b0b9f77a8d95f29c5affa151bbcc18fdc3f7e5223792627919ee2
d52f2bf24933c35de4c1755559bee818ef54b48a388bcdd2e4a30fbde8',
7: h'dba1109b3d53e17290914cdb2e639c6cdad37aff8184537ba9b2c05c
7fe8a994 ... (3277 more bytes; 3309 total)',
8: 1747526400}
Byte-level CBOR encoding (with one line of commentary per field; ML-
DSA-65 signature bytes elided for brevity):
Jackson Expires 28 November 2026 [Page 28]
Internet-Draft SAIHM Protocol May 2026
A8 # map(8)
01 # unsigned(1) // key=1 (cellId)
58 20 # bytes(32)
d851960a5b7754c5884c96bef5d615e666c8ad006e4ceebe028cd85aae8e7c2f
02 # unsigned(2) // key=2 (holderId)
58 20 # bytes(32)
ab4f746fd1520d2736854559d6751969ae9127f5dbc607d7298acbf1afb1f588
03 # unsigned(3) // key=3 (kekVersion)
01 # unsigned(1) // value = 1
04 # unsigned(4) // key=4 (tier)
68 # text(8)
46494c45434f494e // "FILECOIN"
05 # unsigned(5) // key=5 (cellNonce)
50 # bytes(16)
25bd74b827789faacad8ffb7593c2359
06 # unsigned(6) // key=6 (ciphertext)
58 39 # bytes(57)
595b0b9f77a8d95f29c5affa151bbcc18fdc3f7e5223792627919ee2d52f2bf2
4933c35de4c1755559bee818ef54b48a388bcdd2e4a30fbde8
07 # unsigned(7) // key=7 (signature)
59 0CED # bytes(3309)
dba1109b3d53e17290914cdb2e639c6cdad37aff8184537ba9b2c05c7fe8a994
... (3277 more signature bytes; elided for brevity) ...
08 # unsigned(8) // key=8 (timestamp)
1A 68292300 # unsigned(1747526400)
The corresponding write receipt (operation = "REMEMBER"), per the
schema in Section 4:
{1: h'(32-byte receiptId, anchored on chain at txid)',
2: h'd851960a5b7754c5884c96bef5d615e666c8ad006e4ceebe028cd85aae8e7c2f',
3: "REMEMBER",
4: h'ab4f746fd1520d2736854559d6751969ae9127f5dbc607d7298acbf1afb1f588',
5: h'(3309-byte ML-DSA-65 signature over receipt envelope)',
6: 1747526400}
Author's Address
Russell Jackson
SAIHM (Sovereign AI Horizontal Memory)
Email: architect@saihm.coti.global
URI: https://saihm.coti.global/
Jackson Expires 28 November 2026 [Page 29]