— last full suite run: 2026-10-22 (A1c-surum-tek-kaynak — 243 PASS/1 SKIP/0 FAIL)

---

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.

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

# 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 covers that axis: each piece of evidence it collects carries SHA-256 + ISO timestamp plus an optional RFC 3161 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 receipt standard is the convergence point this format is compatible with.

The code bond — 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 (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.

flowchart LR
    subgraph N1["Node-1 (source host)"]
        AG["agent<br/>(identity + encrypted memory)"] --> R["run<br/>work-receipt (charge)"]
        AG --> L["hash-chained ledger"]
    end
    R -- "snapshot.tsg (XChaCha20 encrypted)" --> I
    L -- "ledger_tip binding" --> I
    subgraph N2["Node-2 (new host)"]
        I["import: identity + memory restore"] --> AG2["agent resumes<br/>where it left off"]
        I --> V["ledger-verify:<br/>broken chain → RED"]
    end

Loading

New here? → docs/QUICKSTART.md (5-minute setup, pip install tamga-protocol).

Verify a claim without installing anything. The attestation verifier is a single stdlib-Python file — keccak256, RFC 8785 canonicalization and secp256k1 recovery all self-contained. Anyone checking one of our claims never has to trust or install us:

curl -sO https://raw.githubusercontent.com/goun7/tamga-protocol/main/tools/attest_verify_bagimsiz.py
python3 attest_verify_bagimsiz.py claim.json      # GREEN rc0 / RED rc1

Full technical details: docs/ARCHITECTURE.md.

Academic & technical foundations

The design is grounded in four established bodies of work. This section names them precisely — including the gap each one leaves open, because that gap is where Tamga's own contribution sits.

Tamper-evident logging / hash chaining. An append-only log where each record carries a hash of the previous one is the standard construction for detecting after-the-fact rewriting: any edit to a past record breaks the chain from that point forward, and a verifier walking the chain catches it. The canonical large-scale deployment is Certificate Transparency (RFC 6962), which uses append-only Merkle trees to make CA log entries independently checkable by any third party. Tamga's receipt ledger is the same idea at a smaller scope: every event (charge_receipt, refund, permission_decision, …) is linked with a salted HMAC chain, and ledger-verify walks it end to end. Rewriting a past event invalidates every subsequent hash — this is what AT-213 proves with 50 mutated rows, all 50 refused.

x402 — HTTP 402 payments. x402 (originally coinbase/x402, standardized at x402-foundation/x402) turns the long-reserved HTTP 402 status into a real payment handshake: the server returns a priced 402 Payment Required challenge, the client pays, the same request is replayed with proof of payment. Tamga speaks this protocol (exact/pugio0 schemes, AT-214).

The gap that matters here is issue #2332, "post-settlement accountability." Its own framing is precise and worth quoting: "payment_hash proves the payment completed. It does not prove what the agent did after receiving payment… Logs can be rewritten. An external anchor cannot." Settlement is solved; the record of the work that settlement paid for is not. Tamga's contribution sits exactly there — the receipt chain is the externally verifiable anchor for the post-settlement action, and AT-208 makes it auditable at package scale rather than one ledger at a time.

EU AI Act Article 12. Regulation (EU) 2024/1689, Article 12 requires automatic logging for high-risk AI systems — applicable from 2 December 2027 for Annex III systems. Notably, the regulation mandates that logging happens; it does not specify how the logs are protected or who may verify them (a reading #2332 makes explicitly). Tamga's production checklist is a technical answer to that obligation: not just "logs exist," but "a third party can check they were not altered."

(Verification note: the 2 Dec 2027 date is not asserted from the regulation text directly here — issue #2332 carries it and carries its own correction: an earlier draft of that issue gave 2 Aug 2026 and marked the gap a compliance blocker, and its edit log says both were wrong, citing ai-act-service-desk.ec.europa.eu. We quote the corrected value rather than the original error. The AT-228 test is what makes the "third party can check" claim executable rather than prose: field-level tamper, signature tamper, registry round-trip, and fail-closed key handling, all machine-checked.)

MCP and WASI oracle patterns. Tamga's execution side follows the oracle pattern common to agent runtimes: a small, audited supervisor mediates between an untrusted compute core and host capabilities. The compute core is WebAssembly Systems Interface (WASI) — sandboxed by default, with filesystem and network access absent unless explicitly granted. The agent-tooling interface follows the Model Context Protocol convention of narrow, declared capability surfaces. The relevant security property is default-deny, and it is not asserted in prose — it is executed: AT-212 shows path_open returning EBADF and sock_open being an undefined import, and AT-217 shows infinite loops and memory-growth loops killed before they exhaust the host.

Honest limits (what v0 does NOT claim)

• In-use privacy is unproven: while running, the seed lives in host RAM — TEE (Phase 3)
• Not a production network: simnet; all amounts are *_sim; this is NOT a token/coin
• Scale: snapshot ≤ 64 MiB (safe envelope); multi-node ledger merging is an open question
• Determinism scope is class-defined: deterministic wasm jobs are replay-proven;
• One fail-open path in state loading (found 2026-10-02, not yet fixed): tamga run fails closed on an unreadable state.json, a wrong graph_merkle, and a wrong-type graph_merkle (proven by AT-227). But a memory field that is not a dict at all (e.g. a bare string) reaches the Merkle recomputation unvalidated and raises an uncaught AttributeError — a raw traceback with exit code 0. The operator still sees the error, but the process exits green rather than red. The if graph_merkle and memory guard is also deliberately skipped when either field is absent, which is intentional back-compat for pre-graph_merkle state files but means deleting memory silently skips the integrity check. Both paths are recorded as known limits, not silently passing tests. LLM-class jobs use a different evidence contract (see ARCHITECTURE §Determinism)
• Language surface: core code comments, suite output and docs are English. Preserved Turkish by contract or design: the frozen v0.1 JSON field names (cpu_saat, ram_gb_sn, fee_birebir — renamed only by a versioned RFC), the example agent's proof-line narrative inside compiled .wasm artifacts, and synthetic fixture texts (sample memory/session contents)

Open findings are tracked in an internal audit ledger (10 adversarial rounds; attack simulations). Disclosure process: SECURITY.md.

30-second demo

The animated walkthrough: mint identity → do input-bound work on node1 → the node "dies" → the agent revives on node2 with its memory intact → the receipt ledger verifies → the chain head projects into a foreign batch → a foreign anchor verifies on our side. Play it yourself in one command: bash tools/demo.sh, or watch the raw session: docs/assets/demo.cast.

Quick start

# fastest path (pip-installed, 1 command — template agent + fresh key + sign + FIRST RUN + verify):
pip install tamga-protocol && tamga quickstart my-first-agent

# from source:
git clone https://github.com/goun7/tamga-protocol && cd tamga-protocol
python3 -m venv .venv && source .venv/bin/activate   # or: pip install --break-system-packages -r requirements.txt
pip install -r requirements.txt
bash tests/setup.sh            # one-time: installs pinned wasmtime into tools/bin/
bash tests/run_all.sh          # 243/244 controls — 1 SKIP, 0 FAIL (231 default / +4 live with TAMGA_LIVE=1)
python3 -m pytest tests/ -q    # 3.088 unit tests passed, 0 failed, rc=0 (DALGA-E-ölçümü 2026-10-18, 40 s)

# your first agent (copy the sample vector as the package — see docs/AGENT-GUIDE §3):
python3 tamga_validator.py keygen tests/keys/alice
python3 tamga_validator.py sign  <pkg>/tamga.json <pkg>/agent.wasm tests/keys/alice/seed.hex
python3 tamga_validator.py validate <pkg>             # until ACCEPT

# run (agent identity key never touches disk — printed to stdout only):
AGENT_SEED=$(python3 tamga_runner.py keygen | python3 -c 'import sys,json;print(json.load(sys.stdin)["seed_hex"])')
export TAMGA_KS_PASSPHRASE="..."                       # your choice
python3 tamga_runner.py run    <pkg> --seed "$AGENT_SEED" --note "first run"
python3 tamga_runner.py run    <pkg> --seed "$AGENT_SEED" --input job.json --require-proof
python3 tamga_runner.py export <pkg> -o snapshot.tsg --seed "$AGENT_SEED"
# import requires the target pkg pre-provisioned (tamga.json + agent.wasm): code travels separately
python3 tamga_runner.py import snapshot.tsg <new-pkg>
python3 tamga_runner.py ledger-verify <new-pkg>

## Hızlı Başlangıç (Quick Start — 5 adım)

Her adımı `--help` ile doğruladık (mainnet'e DOKUNMADAN). Komutlar kurulu
paket üzerinde gerçekten çalışır — `tamga` CLI'sında olmayan iki komut için
modül çağrısını verdik (aşağıdaki nota bakın).

```bash
# 1. Kurulum + anahtar
pip install tamga-protocol
tamga keygen-node ~/.tamga

# 2. Konfig — ~/.tamga/relayer-live.env
TAMGA_RELAYER_KEY=0x...
TAMGA_ETH_RPC=https://mainnet.base.org

# 3. Registry yedeği (üretim zorunlu — AT-209)
python3 -m tamga_runner registry-backup my-agent

# 4. Daemon başlat (relayer — RFC-002 D1: daemon v0'da değil, v1'in konusu;
#    canlı-daemon yolu tamga_oracle_relayer.py içindedir, tamga CLI'sında değil)
python3 tamga_oracle_relayer.py daemon --registry my-agent.registry.json \
  --seed 0x... --rpc-url "$TAMGA_ETH_RPC" --oracle 0x... --key "$TAMGA_RELAYER_KEY"

# 5. Denetim (AT-208 — N paketi tek çağrıda)
python3 -m tamga_runner ledger-verify-batch my-agent --summary-only

CLI-notu (dürüst-bilgi): Adım 3 ve 5'teki komutlar tamga CLI'sında henüz bağlı değil — tamga_bootstrap.py'nin komut tablosu keygen, quickstart, run, export, import, ledger, memory, grant, ledger-verify, keygen-node, migrate-net'i tanır, ama registry-backup / registry-restore / ledger-verify-batch'i tanımaz ("unknown command" döner). İkisi de tamga_runner modülünde mevcut ve pyproject.toml'un py-modules listesinde kurulu olarak gelir, bu yüzden python3 -m tamga_runner … ile çalışırlar — ki yukarıda kullandığımız yol odur. Bunların tamga … olarak bağlanması küçük bir tablo-ekleme işidir; bu README o düzeltme gelene kadar modül çağrılarını gösterir.

Üretim kontrol listesi: docs/PRODUCTION_CHECKLIST.md

── PRODUCTION (AT-208/AT-209) ─────────────────────────────────────────

audit N packages in ONE call (customer value: "100 packages at once"):

python3 tamga_runner.py ledger-verify-batch pkg1 pkg2 pkg3 --summary-only

registry = the mine directory. Lose it and the daemon is dead — back it up:

python3 tamga_runner.py registry-backup # atomic (reg.json.bak) python3 tamga_runner.py registry-restore # restore + VERIFY (fail-closed)

full production checklist (7 steps, each a real command):

docs/PRODUCTION_CHECKLIST.md

python3 tamga_bootstrap.py project-head # chain-head → batch-leaf projection (RFC-009; presentation-only) python3 tamga_pugio_receiver.py foreign_anchors.jsonl # verify external anchor lines IN (RFC-009 receiver; fail-loud) python3 tamga_pugio_ingest.py foreign_bundle.json # K0 bundle full-body verify → deterministic receipt (no receipt on RED) python3 tamga_bootstrap.py epoch-verify proof.json # verify a FOREIGN epoch-seal inclusion proof — GREEN rc0 / RED rc1 / İNDETERMİNE rc2; a dead RPC never reads green (--rpc adds the on-chain leg) python3 tamga_bootstrap.py liveness-probe # RPC freshness by block-NUMBER span only — server wall-clock NEVER read (#2887 lesson); stdout is always the machine JSON line (verdict echoes on stderr); İNDETERMİNE on any gap python3 tamga_bootstrap.py attest-verify claim.json # verify a FOREIGN delivery-attestation (CAPACITY_ATTEST_V1): stdlib-only secp256k1+EIP-191 — reproduces the issuer's own verdict on fixture vectors 7/7 AND live-generated claims 8/8 (AT-030) python3 tamga_bootstrap.py verify-cr doc.json --expect sha256:... # recompute a CR-v0.1 canonical digest through our canonical path; bare call = measurement, not verdict python3 tamga_runner.py memory --search python3 tamga_runner.py memory --import-json lessons.json # ADD-only memory bridge

bringing memory from another store? multi-format converter (mem0/letta/zep/jsonl):

python3 tools/memory_import.py --from export.json --format auto -o converted.json

## One-command regression

```bash
bash tests/run_all.sh        # 243/244 controls — families below; 1 SKIP, 0 FAIL (231 default / +4 live with TAMGA_LIVE=1)
python3 -m pytest tests/ -q  # 3.088 unit tests passed, 0 failed, rc=0 (DALGA-E-ölçümü 2026-10-18, 40 s)

Control families: snapshot lifecycle + adversarial negatives (AT-001), determinism/replay (AT-002), ledger attack vectors (AT-003), input-bound receipts (AT-004), multi-format memory import (AT-005), manifest-schema cross-validation (60/60 incl. the promoted v0.2 schema + spec_version transition matrix), plus tokenomics/economy invariants. Details: docs/TESTS.md. CI runs the full suite on every push (4-Python-version matrix, wasmtime v48.0.1).

30-second live demo

bash tools/demo.sh   # born → input-bound work → dies → travels → revives → verified → projected → foreign anchor received

Recorded session: docs/assets/demo.cast (play with asciinema) — expected flow: docs/DEMO-SCRIPT.md.

On-chain oracle relayer

tamga_oracle_relayer.py is the off-chain side of the oracle: it listens for RequestExecution events on an EVM chain, runs the registered WASI module inside the real wasmtime sandbox, and posts the proof back via fulfillExecution. It is built in three layers, each independently tested against the real production path (no test-doubles — AT-075):

• KATMAN-0 — proof-production core (zero new PyPI deps): fnv1a64 stamp verification (byte-identical copy of tamga_runner.py's), snapshot SHA-256(ct) digest (the encrypted body, not the whole blob — portable across exports), JCS canonical fulfill payload.
• KATMAN-1 — production-path driver (subprocess → tamga_runner): registry fail-closed (an unregistered wasiModuleHash is refused — the relayer is not an RCE vector), maxCpuMsAllowed = min(request, manifest) with [1,60000] validation, mandatory Ledger(path, secret=).
• KATMAN-2 — EVM transport (optional pip install tamga-protocol[relayer]): eth_getLogs poll → event decode, EIP-1559 signed fulfill tx with real receipt verification.

End-to-end, tested against a real py-evm state machine (no anvil/solc needed): event → decode → real wasmtime run (stamp 7c9a2cbcd4684b55) → XChaCha20-Poly1305 export → SHA-256(ct) → JCS payload → fulfill tx with receipt status=1, gasUsed=39959 — AT-196.

# one request through the full path (production uses daemon mode — see DEPLOYMENT)
tamga keygen | tee agent.json                # agent identity (never printed again)
SEED=$(python3 -c "import json;print(json.load(open('agent.json'))['seed_hex'])")

tamga-relayer registry-check relayer.registry.json
tamga-relayer run-request --registry relayer.registry.json \
    --seed "$SEED" --module-hash 6129007a280fcee3845532d38e4be3ecf9fddb03809c35a335e0b1b9c2b142a5
# → {"ok": true, "digest": "87ab8c35…", "stamp": "da4cba53a97ca717",
#    "effective_cpu_ms": 5000, "payload": "{…JCS canonical…}"}

# audit the two proofs independently
tamga-relayer verify-stamp pkg/session-1.stdout    # mühür-2: TAMGA:<fnv1a64>
tamga-relayer snapshot-digest snap.tsg             # mühür-1: SHA-256(ct)

# or verify the whole bundle WITHOUT installing the relayer (counterparty path):
# tamga-verify verify-bundle bundle.json  → 6/6 checks, pure stdlib
#
# ...or with ONLY a transaction hash and an RPC (no relayer, no bundle, no gas):
# tamga-verify verify-tx 0x<tx> https://mainnet.base.org  → 4/4 checks
#   selector=fulfillExecution, request_id>0, payload JCS byte-parity,
#   digest arg == payload.encrypted_snapshot_digest (chain-fact consistency)

# LIVE CHAIN (Base mainnet/sepolia): daemon mode — secrets via env, never CLI/keys
export TAMGA_RELAYER_RPC_URL=https://mainnet.base.org
export TAMGA_RELAYER_ORACLE=0x<ITamgaOracle>     # deployed oracle contract
export TAMGA_RELAYER_KEY=0x<signing-key>         # or Ledger — never logged
tamga-relayer daemon --registry relayer.registry.json \
    --seed "$SEED" --interval 15
# → [relayer] request 42 fulfilled: tx=0x1fb4… status=1 gasUsed=39935
#   fail-closed every step: registry-miss → RED-20; gas-too-low → RED-28, no crash
#   replay protection: the same request is fulfilled only once per process
#   (see docs/CANLI_ZINCIR.md for the full walkthrough)

## Live proof (Base mainnet, 2026-09-25)

The full loop ran on **real Base mainnet** — [docs/CANLI_ZINCIR.md §6](docs/CANLI_ZINCIR.md):

| Step | Result |
|---|---|
| Emitter deploy | `status=1 gasUsed=124936` — [0x897D7abD…](https://basescan.org/address/0x897D7abDe35124EEB41F0BC0d04d2cF81653442f) |
| **`fulfillExecution`** | **`status=1 gasUsed=68150`** — [tx 0x391f4ea9…](https://basescan.org/tx/0x391f4ea94789a171437916e075dc8adb34863cbe3b5d7283db8a76ef1c20ce73) |
| delivery keccak, live | keccak of on-chain `outputData` == logged `dc6f72f2…` — **exact** |
| **counterparty verify** | `verify-tx` on the fulfillment tx → **`checks:4 ok:true`** — no relayer, no gas |
| **replay guard (live)** | second daemon call on same request → contract **reverts**, 0 double-fulfill (AT-211) |
| sandbox default-deny | `path_open`→EBADF, `sock_open`→undefined import; no preopens, no network (AT-212, 7/7) |
| ledger robustness | 50 corrupted rows → **50/50 refused**, 0 silent acceptance (AT-213) |
| x402 V2 safe-wait | V2 headers refused at 402; V1 path serves 200 (AT-214, 8/8) |
| x402 spec parity | upto boundaries fail-closed (AT-219), payment-identifier honest gap (AT-216), discovery parity (AT-220), SIWX identity-in-payment (AT-221), self-facilitate (AT-223) |
| DoS protection | infinite loop + memory.grow killed instantly; deterministic across runs (AT-217, AT-222) |
| receipt scale | 1000-event HMAC chain verified in 0.010 s (AT-218) |
| live proof freshness | emitter + fulfillment tx re-verified against public RPC today (AT-224, 6/6) |
| key secrecy | key prefix absent from every log and reason field |

Total cost ~$0.001 (Base baseFee ~0.005 gwei). The live tests are gas-guarded:
they SKIP unless `TAMGA_LIVE=1` is set.

Full deployment (systemd unit with watchdog, secret management, registry discipline): docs/DEPLOYMENT.md. Test evidence: AT-195 (proof core), AT-196 (end-to-end EVM), AT-197 (Ledger secret), AT-198 (registry fail-closed / RCE proof).

Importing your memory

Bring existing agent memory in via JSON-lines (--import-json): the merge is ADD-only and idempotent — re-importing the same source skips what's already there. The source store is opened read-only; intermediate data stays in RAM. Export adapters for external memory stores are on the Phase-2 roadmap. Developer guide: docs/AGENT-GUIDE.md.

Documents

Doc	Content
docs/ARCHITECTURE.md	Technical architecture: formats, chain, cosign, reason codes, limits
docs/DESIGN-PARTNERS.md	Design-partner program (v0.1→v0.2): free migration + a seat in the freeze loop
RFC-008-external-receipt-DRAFT.md	DRAFT (pilot-pending): external-receipt binding schema — x402 and other rails, three open questions the pilot day will close
RFC-009-external-chain-anchor-DRAFT.md	DRAFT (pilot-pending): external chain anchors — our ledger citing foreign-registry facts (epoch-13 seal-flip GREEN replay, frozen D5 math via AT-017; op/const gated behind the pilot)
RFC-007-schema-revision-v02.md	IMPLEMENTED: the v0.2 schema revision as a public record — R1 runtime.net migration, R2 labeled delivery_hash (safal207 fix), R3 D12 conditional unity; each with its acceptance-test evidence and founder-gated items labeled (R4 stays pilot-gated)
RFC-005-declared-egress.md	IMPLEMENTED: declared egress (proxy model) — the default-deny vs real-agent contradiction and its resolution (capability-declaration + runner-enforced proxy), M1–M6, the honest wasmtime outbound-socket finding, D12 binding, SSRF/DNS-rebinding countermeasures; AT-006/009/011 evidence
RFC-006-agent-net-shim.md	IMPLEMENTED: agent-side network shim (D13) — TAMGA-NET-1 single-edge protocol, capability-sniff two-mode stdin discipline, evidence integrity (request lines verbatim), honest v1 limits (no streaming; header secrecy is the agent's own responsibility)
INDEX.md	Reading order by role — decider / implementer / verifier / integrator paths through all 28 docs, plus the status vocabulary (FINAL / DRAFT pilot-pending / DESIGN NOTE)
VERIFY-EPOCH-ANCHOR.md	Verify a foreign epoch seal yourself (verify-it-yourself): Merkle inclusion recomputed with the repo's pure-python keccak + on-chain root read via your own RPC — the epoch-13 seal-flip replay as the worked example
NODE-DISCOVERY.md	Phase-3 design note: node discovery via ERC-8004 (identity/reputation/validation registries) — manifest↔registration-v1 mapping, trust-list migration, honest gates (Draft-status, TEE, micropayment measurement); trigger-gated, no code
RELEASE.md	v0.2.10 foreign-attestation verifier + verify-cr + migration demo · v0.2.9 tamga liveness-probe console · v0.2.8 E-15 chain-binding · v0.2.7 whole-CLI usage-guard + CR-v0.1 cross-proof · v0.2.6 same-day patch (explain crash-family) · v0.2.5 fresh-user audit release (epoch-verify in wheel) · v0.2.4 ingest-in-wheel + AT-026 packaging control · v0.2.3 project-head + PUGIO receiver · v0.2.2 wheel-side explain + keccak fix · v0.2.1 license fix · v0.2.0 FINAL const flip
PLAIN-TURKISH.md	plain-language explainer (Turkish + short English summary) — no code reading required
docs/RFC-001-manifest.md	Package manifest schema contract (v0.1-FINAL, frozen, English translation)
docs/RFC-002-runner.md	Runner API + snapshot transport contract (v0.1-FINAL, frozen, English translation)
docs/RFC-003-ledger.md	Ledger record contract (DRAFT v0.1, English translation)
docs/RFC-004-context-graph.md	ADD-only context-graph contract (DRAFT v0.1, English translation)
docs/AGENT-GUIDE.md	Agent developer guide (mental model → first run → migration)
docs/TESTS.md	Test families + how to run + CI
docs/AUDIT-GATE.md	The 8-step gate every change passes
docs/DEMO-SCRIPT.md	30-second demo: expected flow
docs/ERC-8004-MAPPING.md	ERC-8004 ↔ Tamga mapping (Phase-3 design note)
specs/manifest-0.2.0.schema.json	Package manifest JSON Schema (v0.2; 0.1.0 legacy frozen)
SECURITY.md	Vulnerability disclosure + reporting forms
CONTRIBUTING.md	How to contribute

Language note (honesty fix, 2026-09-16): each document has ONE binding original and the twin says which at its top. RFC-001…004: English is the living binding text, with Turkish twins (docs/*.tr.md) beside them. RFC-005…009 + VERIFY-EPOCH-ANCHOR + MIGRATION-DEMO: born Turkish — the Turkish file IS the original; English twins (.en.md) now stand beside them for foreign readers — on divergence the Turkish governs. AT-033 K4 makes the direction itself machine-checked. All other twins (README.tr, AGENT-GUIDE, REPRODUCE, ARCHITECTURE, TESTS, RELATED-WORK) are translations of their English originals. Earlier private Turkish drafts are never cited as canonical — an uncheckable canonical is not a canonical. Türkçe README: README.tr.md — and the machine-generated full language map (every original, every twin, both directions) lives in docs/INDEX.md: its Dil-durumu line is produced by python3 tools/gen_lang_index.py, never hand-written.

Roadmap

• ✅ Phase 1 — simnet genesis: primitives + acceptance tests + 10 audit rounds
• 🔄 Phase 2 — hardening: memory-store adapters, overhead statement, design-partner pilot
• 🔒 Phase 3 — network: ERC-8004 registration + real micropayments + TEE pilot (gated)
• 🔒 Phase 4 — protocol v2: zkVM proof layer, governance (double-gated)

Contributing

Read CONTRIBUTING.md and the audit gate: a change = tests + evidence. Report vulnerabilities privately via SECURITY.md.

License

Apache-2.0 — contributors' patents extend to users; anyone filing a patent claim loses the license.

---

Akademik Kaynaklar (2024-2026)

Tamga'nın tasarım alanı (oracle doğrulama, x402 ödeme protokolü, settlement binding, WASI oracle yürütme, tamper-evident evidence ledger, ödeme kanalı imza şemaları) 2024–2026'da aktif bir araştırma alanı. Aşağıdaki 8 makale bu alanın doğrudan komşuları — her biri Tamga'nın bir bileşeniyle aynı problemi farklı bir açıdan ele alıyor. Tümü 2024–2026 aralığında, gerçek arXiv kayıtlarıdır; abs sayfaları bu listenin derlendiği gün (2026-10-03) HTTP 200 dönmüştür. Hepsi arXiv ön-baskısıdır — DOI/journal_ref henüz yoktur, bu yüzden DOI bağlantısı verilmemiştir.

• [1] Ödemeyi hizmetin yürütülmesine bağlama (settlement-bind) — A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce — Li et al., arXiv 2026. x402'nin ödeme ↔ hizmet yürütme ↔ sonuç teslimi arasında uçtan uca atomiklik sağlamadığını tanımlar ve "Atomic Service Channels" ile ödemeyi yürütime bağlayan bir mimari sunar. Bu, Tamga'nın settlement-bind (D5 uç-lu zincir) hedeflediği boşluğun akademik teşhisidir: settlement çözülmüştür, yürütmenin kanıtı değil. arXiv:2603.01179

• [2] x402 güvenlik analizi — Five Attacks on x402 Agentic Payment Protocol — Li et al., arXiv 2026. x402'nin senkron HTTP yetkilendirmesi ile asenkron zincir settlement'ını birleştirmesinin ürettiği çapraz katman saldırı yüzeyini resmi olarak analiz eder; yetkilendirme, binding, replay koruması ve web katmanında beş somut saldırı gösterir. Tamga'nın exact/pugio0 şema katmanı ve replay guard'ı (AT-211) aynı tehdit sınıfına karşı tasarlanmıştır. arXiv:2605.11781

• [3] x402 riskleri ve facilitator merkezileşmesi — When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments — Wang et al., arXiv 2026. x402'nin ödeme kanıtı ve zincir settlement'ını üçüncü-parti facilitator'lara delege etmesinin paylaşılan ödeme altyapısında merkezileşmiş güven yarattığını, tek bir kusurun birçok hizmeti etkileyebileceğini gösterir. Tamga'sı counterparty yolunu bağımsız doğrulanabilir kılarak (verify-tx, verify-bundle — stdlib-only) bu merkezileşmeye yanıt verir. arXiv:2607.19545

• [4] Agentic ticaretin özgünlüğünün ölçülmesi — How Agentic Is Agentic Commerce? A Population-Scale Measurement of x402 Adoption and Authenticity — Ling et al., arXiv 2026. x402 settlement sayısının benimsenme kanıtı olarak okunamayacağını gösterir: facilitator gazı sponsorladığı ve zincir üzerinde ödemenin kimin kontrol ettiğini işaretlemediği için sayı "neredeyse bedavaya" üretilebilir. Base üzerindeki nüfus-ölçeğinde ölçüm yapar. Bu, yukarıda alıntılanan TRM Labs bulgusunun (0.6–7.5%'si agentic) akademik yoldaşısıdır — Tamga'nın "ödeme hareket ettiğini kanıtlar, işin yapıldığını kanıtlamaz" tezini destekler. arXiv:2607.12575

• [5] Defter-çapraz kimlik + x402 mikroödeme — Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents — Vaziry et al., arXiv 2025. A2A protokolüne dağıtık defter entegrasyonu ile AgentCard'ları akıllı sözleşmeler olarak yayımlayıp değiştirilemez, doğrulanabilir ajan kimlikleri oluşturur ve x402 ile blockchain-agnostik mikroödemeler ekler. Tamga'nın "sahiplik ajanla birlikte yolculuk eder" (node-cosign + ERC-8004 kimlik) ilkesiyle aynı yöndedir; ERC-8004/v1 imza şemamızın eşleştiği katman. arXiv:2507.19550

• [6] Eşik imzalı oracle konsensüsü — Instant Resonance: Dual Strategy Enhances the Data Consensus Success Rate of Blockchain Threshold Signature Oracles — Xian et al., arXiv 2024. Çoklu düğümlerden veri üzerinde eşik imza (threshold signature) ile konsensüs sağlayan oracle'ların heterojen ortamlardaki veri tutarsızlığı ve düşük başarı oranı sorununa ikili-strateji yaklaşımı sunar. Tamga'nın çok-scheme imza sözleşmesinin (x402/v1, tamga/native, erc8004/v1) ve oracle relayer'ının çok-partili imza/kanıt modelinin akademik zeminidir. arXiv:2411.02945

• [7] WASM deterministik akıllı sözleşme yürütme — DTVM: Revolutionizing Smart Contract Execution with Determinism and Compatibility — Zhou et al., arXiv 2025. WebAssembly tabanlı, EVM ABI uyumlu, deterministik bir akıllı sözleşme yürütme çatısı sunar; determinizmi birinci-sınıf bir özellik olarak ele alır. Tamga'nın "determinism ground" garantisi (aynı wasm + aynı girdi → özdeş çıktı parmakizi, stake-backed yeniden yürütmenin önkoşulu) ile aynı varsayımdır; WASI oracle relayer'ımızın yürütme çekirdeği bu determinizm üzerinde inşa edilidir. arXiv:2504.16552

• [8] Ödeme kanalı imza şeması — OTS-PC: OTS-based Payment Channels for the Lightning Network — Lerner & Futoransky, arXiv 2025. Durum sıra numaraları üzerinde tek-seferlik imza (one-time signature) temelli iki yönlü bir ödeme kanalı inşası sunar; Poon-Dryja'dan daha basit, kanal başına O(1) depolama ve minimal bilgi sızıntısı ile gelir. Ödeme kanalı imza şeması konusu, Tamga'nın kanal/ödeme makbuz imzalarının şema tasarımının ilgili literatürdeki karşılığıdır. arXiv:2511.04021