[](https://pypi.org/project/tamga-protocol/)
[](https://github.com/goun7/tamga-protocol/actions/workflows/ci.yml)
[](#one-command-regression)
[](LICENSE)
[](#roadmap)
[](docs/REPRODUCE.md) — last full suite run: 2026-09-17 (58/58 slow)
---
## Why does this exist?
The agent ecosystem has three layers — and none of them fills the gap between them:
| Layer | Who's building it | What's missing |
|---|---|---|
| Memory | Mem0 · Letta · Zep | **Portability** — locked to the vendor, keys on their side |
| Trust | ERC-8004 (Ethereum) | **State** — the agent dies, its memory evaporates |
| Payments | x402 | **Proof** — no verifiable evidence that "the work actually happened" |
Tamga lives in that gap: **encrypted, portable, tamper-evident agent state.**
Not a competitor — a complement. See [docs/ERC-8004-MAPPING.md](docs/ERC-8004-MAPPING.md).
### The gap is measured, not assumed
This is not a hypothetical. Blockchain-intelligence firm TRM Labs audited $52.7M of x402
settlements and found that **only 0.6–7.5% was plausibly agentic** — roughly
**$5,000–$11,000 per month** of real agent spend against the headline number. Their
structural finding names the gap directly:
> *"A settled transaction proves that value moved — it does not prove a model made a
> purchasing decision. A script, a cron job, a load test, a self-payment loop or a human
> clicking a button all drive the same HTTP 402 sequence and leave an identical record."*
Three independent audits reached the same conclusion. Their recommendation — accurate
registration plus counterparty reputation an agent can check on its own — is exactly the
layer Tamga implements. Payment rails move value; **Tamga binds the work to the claim.**
## 30-second summary
```bash
# 1. The agent runs (WASI 0.3 component, default-deny sandbox)
python3 tamga_runner.py run pkg/ --seed $SEED --input job.json --require-proof
# 2. The machine dies — identity+memory+ledger travel in ONE encrypted snapshot
python3 tamga_runner.py export pkg/ -o snapshot.tsg --seed $SEED
# 3. On a new node, the agent RESUMES where it left off
python3 tamga_runner.py import snapshot.tsg new-pkg/
# 4. "This work actually happened" — the hash-chained receipts verify
python3 tamga_runner.py ledger-verify new-pkg/ # ok: true
```
## Core guarantees
- 🔐 **At-rest privacy, proven for the snapshot** — the agent seed and snapshot body
never touch disk in plaintext (XChaCha20-Poly1305 + scrypt); the suite greps the
encrypted snapshot body for plaintext — **0 hits** (node-side `state.json` keeps
memory text in plaintext by design — confidentiality at rest is the snapshot's job)
- ⛓️ **Tamper-evident accounting** — hash-chained ledger; truncate/splice forgery → RED
- 🪪 **Ownership travels with the agent** — node-cosign: the node seals work-receipts
with its own certificate; a revocation list invalidates the decommissioned node
- ⌨️ **Input-bound work receipts** — `--input` binds `input_sha256` into the receipt;
the agent can be asked to stamp its output (`--require-proof`) and the runner
verifies the stamp before signing the receipt
- 🔁 **Determinism ground** — same wasm + same input → identical output fingerprint
(the precondition for stake-backed re-execution)
- 🚫 **Offline & default-deny** — the runtime has no network, no filesystem, no host env;
wasmtime v48 on ratified WASI 0.3 components
**The time axis — BrandStrike:** this suite proves *what* an agent did and that
it was not altered afterwards, but a hash-chain alone does not anchor *when*.
[BrandStrike](https://github.com/goun7/brandstrike) covers that axis: each
piece of evidence it collects carries SHA-256 + ISO timestamp plus an optional
[RFC 3161](https://datatracker.ietf.org/doc/html/rfc3161) TSA token that a
third party can verify independently. Together the two projects cover the
integrity axis (JCS hash-chain here) and the time axis (TSA there). The
open [AERF](https://github.com/aerf-spec/aerf) receipt standard is the
convergence point this format is compatible with.
**The code bond** — [`tools/brandstrike_tsa.py`](tools/brandstrike_tsa.py) makes
that pairing executable rather than documentary. It is an RFC 3161
query/response validator that ties a TSA token to this project's own hash-chain:
- **query side** — builds a `TimeStampReq` whose `messageImprint` is
`sha256(chain_tip)`, so a token answers for an exact ledger state;
- **response side** — parses `PKIStatusInfo` + CMS `SignedData` + `TSTInfo`
(policy, imprint, serial, `genTime`, nonce) with a hand-rolled DER codec, and
verifies the CMS signature (EdDSA/RFC 8419 via PyNaCl; RSA/ECDSA via the
optional `cryptography` package, reported INDETERMINE when absent);
- **the bond** — verification only passes when the token's imprint equals
`sha256` of the ledger tip recomputed with the runner's own chain rule
(`h = sha256(prev ‖ jcs(record))`), the nonce echoes the request's, and the
chain itself is intact. A token minted over a decoy digest, replayed with the
wrong nonce, signed by another key, or paired with a broken chain is RED.
The bond is tested from both directions: [`tests/test_brandstrike_tsa.py`](tests/test_brandstrike_tsa.py)
(31 unit tests) pins the codec and each attack path, and acceptance control
**AT-229** (`tests/at229_brandstrike_tsa_dikis.sh`) proves `chain_tip` is
byte-identical to `tamga_runner._ledger_head` on a runner-produced ledger, then
mints a genuinely signed token over that tip and drives the full GREEN/RED
matrix. Zero new dependencies — the tool adds nothing beyond the declared
PyNaCl + jsonschema and the project's own `tamga_canon`.
*Honest limit:* the runtime has no network by design, so the tool verifies and
binds tokens rather than contacting a live TSA — the acceptance control mints
its test token with a locally generated key, which is a stand-in for a trusted
TSA, not a real timestamp authority.
```mermaid
flowchart LR
subgraph N1["Node-1 (source host)"]
AG["agent