SMSH stands for Sealed Message-State Hash. It's the cryptographic seal that ties every Tre’gent receipt to the exact reasoning state the agent was in when it acted. A receipt tells you what the agent did. SMSH tells you what the agent knew when it did it. You need both to actually audit an action. Either one by itself isn't enough.
An LLM doesn't remember anything between calls. Whatever the agent was reasoning over in the moment, like instructions, retrieved context, earlier turns in the conversation, tool outputs, or policy rules, only existed inside that one inference window. The second the call finishes, all of that is gone. SMSH grabs a cryptographic fingerprint of that window before it disappears, and locks it to the receipt that records what the agent did next.
Without SMSH, a receipt can only say "the agent did X at time T." With SMSH, the receipt can also say "this action came from reasoning state smsh:…, and anyone holding the original data can check that hash matches, byte for byte." You can no longer pull the action apart from the reasoning that led to it.
The system prompt, the user/principal instruction, and any tool-use directives present at execution time. Hashed in canonical order.
RAG hits, vector lookups (SVU surface), prior turn history, tool outputs returned into the window. Bound by content hash.
The SHOD policy snapshot checked at the moment of the action. This covers the allowlist, daily cap, recipient cap, price window, trust tier, and anomaly state.
The agent identity, the principal/HAHS handle, and the delegation chain in effect when the inference resolved.
SMSH always gives the same result for the same inputs. Any verifier who runs the same data through it gets the same hash. First the data gets put into one standard order, then it gets hashed.
Every Tre’gent receipt carries the SMSH value in a top-level smsh field. If you rebuild the hash from the published source data, it has to match that field byte for byte. If it doesn't match, the offline verifier rejects the receipt.
SMSH is specified in four tiers. Each one covers a different audit need, and each one is designed to plug straight into the AFIR signing pipeline. Maturity varies by tier; see the status column below.
This is one SHA-256 hash over the state record, put in standard order first. On the transaction harness this ships today as a signed sample artifact, byte-stable and checkable offline against the published rule for standard order and the issuer's Ed25519 key. It is not yet a live production endpoint.
| Hash | SHA-256 over canonical-sorted JSON |
|---|---|
| Encoding | base64url, no padding |
| Receipt field | smsh (top-level) |
| Status | Specification; signed sample on the transaction harness (step 08). The live accumulator surface today is /v1/accumulator/{domain}/inclusion. |
| Verifier | Tre’gent offline verifier · verify_receipt.py |
Sometimes an action's authority traces back through several earlier steps. When that happens, SMSH-Quorum requires at least K out of N of those earlier SMSH values to carry valid signatures before it honors the new receipt. Tre’gent checks this rule as part of tracing an action's ancestry. It's used for delegated authority chains and for actions that need agreement from multiple agents.
| Predicate | K-of-N over ancestor SMSH signatures |
|---|---|
| Default | K = 2, N = 3 (configurable per principal) |
| Receipt field | smsh_quorum (when invoked) |
| Status | Specification; shown as predicate claim A on the Tre’gent demonstrator |
State changes between turns all the time. A tool output revises a fact, a policy snapshot updates, a piece of context gets swapped out. SMSH-Δ locks each one of those changes to the SMSH that came right before it. That builds a chain of signed changes that nobody can quietly edit later without breaking the chain. The record of how the reasoning changed over time is backed by math, not just a story someone tells you.
| Construction | delta = canonical(diff(state_prev, state_next)) |
|---|---|
| Anchor | SHA-256(prev_smsh ‖ delta_bytes) |
| Receipt field | smsh_delta_chain (when invoked) |
| Status | Specification; shown as anchoring claim B on the Tre’gent demonstrator |
For sensitive inspection files, ViewKey material, and evidence that only specific auditors should see, SMSH-PQ wraps the standard SMSH in a post-quantum sealed envelope, using ML-KEM-768 for key exchange. The original SMSH binding stays exactly as it was. The PQ layer just adds more protection on top. It's signed twice: once with ML-DSA-65 (NIST FIPS 204, the government's post-quantum signature standard) over the same digest, and once with Ed25519 so older systems can still check it. AFIR uses this on every receipt that holds regulated evidence with a long retention window.
| Envelope | ML-KEM-768 (NIST FIPS 203) key encapsulation |
|---|---|
| Signature posture | ML-DSA-65 (NIST FIPS 204) primary, Ed25519 for legacy compatibility |
| Use case | Long-retention regulated evidence, sealed inspection payloads, AFIR receipts |
| Status | Pilot, see the Hive-PQ page. Full ML-KEM/Kyber-class integration has not shipped yet. |
This is the top-tier specification. SMSH-MAX wraps standard SMSH in SMSH-PQ signing, adds the SMSH-Δ change chain, and can add a separately selected and specified on-chain Merkle anchor. USDC payment on Base is separate from evidence anchoring. Standard receipts remain signed off-chain and verifiable offline.
| Construction | SMSH-PQ envelope + SMSH-Δ chain + on-chain Merkle anchor |
|---|---|
| Anchor | Optional and separately specified; Base payment does not itself anchor evidence |
| Signature posture | ML-DSA-65 primary, Ed25519 compat, full delta chain |
| Use case | Financial settlement, FINRA WORM, EU AI Act high-risk, SR 11-7 model risk, multi-year retention |
| Status | Specification. Depends on SMSH-PQ, which is in pilot; the on-chain Merkle anchor is not independently verified here. |
A Tre’gent receipt is the signed record of one agent action. It names the actor, the action, the amount, the time, the counterparty, the policy checks it passed (SHOD), and the SMSH of the reasoning state that authorized it. Verification has to match exactly, byte for byte. The offline verifier (verify_receipt.py) puts the receipt back in standard order, rebuilds the SMSH from the published source data, and only then checks the Ed25519 signature. If anything in the receipt or the source data has shifted even slightly, verification fails.
You can't rebuild an audit trail from logs after the fact. Logs can be edited. Pipelines change over time. Context windows don't stick around. By the time a regulator asks "why did the agent do this," the reasoning state behind that action is already gone. SMSH fixes that by hashing the state into the receipt before the action even finishes. The proof exists from the very first moment. It's not a story someone reconstructs later.
For regulated buyers in financial settlement, healthcare, legal, and government, this is the difference between "the agent did it" and "the agent did it under this exact policy, with this exact context, signed and checkable by anyone offline." That difference is what Hive sells.