Download trust report (PDF)↓

Compliance posture

Etch's SOC 2 Type I attestation targets Aug 2026. The controls that matter for Type I are already implemented and evidence is logged. Type II attestation follows after four quarters of Type I operation. DPA available on request: security@etch.systems.

Framework mapping

Every Article and control ID cited below is addressed by a specific mechanism in the shipped product today. The "covered by" column names the mechanism so a compliance officer can trace every claim to code.

Cryptographic primitives

• Event hash: SHA-256 (FIPS 180-4). Every event canonicalized to JSON, then hashed. Chain is a linked list of these hashes.
• Epoch signature (classical): Ed25519 (FIPS 186-5). Signs the epoch envelope. Verifiable with pinned public keys.
• Epoch signature (post-quantum): SLH-DSA-SHA2-128f (FIPS 205). Hash-based signature scheme. Hybrid with Ed25519 so verification survives a hypothetical break of classical elliptic-curve cryptography.
• Merkle tree: RFC 6962. Certificate-Transparency-shaped tree with 0x00 leaf + 0x01 node domain separators.
• External anchor signature: ECDSA-P256. Per-project key used only for external witnesses (Sigstore Rekor + Bitcoin OpenTimestamps). Separate from the audit-chain hybrid.

External anchors

Every closed epoch is anchored to two independent public logs. Neither log is operated by Etch. Rewriting a signed epoch would require the log operator to publish evidence of the rewrite, which immediately breaks the anchor comparison.

• Sigstore Rekor. Public append-only log run by the Linux Foundation. Confirmation within hours. Look up any entry: https://rekor.sigstore.dev/api/v1/log/entries/<uuid>
• Bitcoin OpenTimestamps. Public timestamping protocol using Bitcoin block headers. Confirmation within 6-12 hours. Auditors verify offline with ots verify <proof>.

Trust assets

Etch's guarantees are code-testable and cryptographically anchored, not marketing claims. This page links every document and mechanism an engineer, compliance officer, or investor needs to evaluate Etch's substrate end-to-end. Every claim below is verifiable, commands and file paths included.

1. Dogfooding report

Etch runs on Etch. Every push to the etch repo fires a GitHub webhook that records into Etch's own authenticated audit chain, plus every AI-coding tool call during Etch's own development. The report covers 62 hours of active production usage across two build sprints and a SWE-bench Verified benchmark run.

• 152,064 total events recorded across 462 distinct sessions
• 19,006 signed epochs closed with 100% transparency-log integrity
• 0 data-loss events, 0 dead-letter rows across the reporting window
• 440/440 tests passing
• Every failure is itself recorded in the authenticated audit chain

Read the full report→

2. Adversarial suite

For every concrete attack an adversary might attempt, a code-testable property that Etch relies on to defeat it, and a test that proves the defense holds. 13 tests, all passing.

• Rewrite a past event's content (naive + sophisticated variants)
• Delete an entry from the middle
• Insert a forged entry
• Reorder or duplicate entries
• Forge a new genesis
• Rewind, plus the honest limit and its external defense
• Strip the signature envelope
• Canonicalization attacks (JSON key reorder, whitespace padding)
• Concatenate two valid chains

Every claim is anchored in a test. Reproduce with:

git clone https://github.com/SaravananJaichandar/etch
cd etch
PYTHONPATH=src python3 -m pytest tests/test_adversarial.py -v
# expected: 13 passed

Read the analysis→

3. Compliance mapping

For a compliance or legal reviewer: how Etch's cryptographic guarantees map to specific clauses in four named frameworks.

• EU AI Act (Regulation 2024/1689). Articles 12, 15, 26-27, 72, 79
• SEC 17a-4: the 2022 audit-trail-alternative path
• NIST AI RMF 1.0. Govern / Map / Measure / Manage
• FIPS 186-5 (Ed25519), FIPS 205 (SLH-DSA), FIPS 180-4 (SHA-256)

Includes the "what compliance officers should ask us" Q&A section answering every question we've been asked to date.

Read the mapping→

4. Public-key pinning + signed dump manifest

Any auditor, at any time, can independently verify Etch's authenticated audit chain without operator cooperation. Two public endpoints:

# Get the public keys (pin their fingerprints on your side)
curl https://etch.systems/projects/world-model-mcp/audit-log/public-keys

# Download the signed dump manifest
curl https://etch.systems/projects/world-model-mcp/audit-log/dump/manifest

Both endpoints are open (no auth needed) because independence from the operator is the point. The public keys are also on the OSS layer, the signature envelope embeds Ed25519 fingerprints, so an auditor can pin what they see today and detect any future key rotation.

Threat model, briefly

Etch assumes the operator (that's us) might themselves be malicious. Every attack in the adversarial suite is one an insider with full root on our storage could attempt. Etch's guarantee is that tampering leaves a trace, an external verifier can detect it without our cooperation. Etch does NOT guarantee preventing tampering (that's impossible when we have the disk). It guarantees detection.

5. Shadow Mode, model-upgrade validation

Prove a model upgrade doesn't silently change what your agent decides on production traffic. EtchShadowClient wraps two model configurations, calls both on every request (or a sampled fraction), and records per-attribute divergence.

Read the docs→

6. Incident Replay, reconstruct any past moment

Given a flagged event, walk backwards through the session to see every input the agent saw and every tool it called. Download a signed forensic bundle for offline audit, verifiable against pinned public keys, no operator cooperation required.

Read the docs→

7. Signed monthly statements

For every project, Etch renders a signed audit statement for any past month. Three surface forms all derive from one canonical, hybrid-signed payload:

• HTML at /statement/{project_id}/{YYYY-MM}. Self-contained, print-friendly, browser Print-to-PDF works out of the box.
• Signed JSON at /statement/{project_id}/{YYYY-MM}.json. Includes the Ed25519 + SLH-DSA envelope. Verifies offline against the operator's pinned public keys.
• PDF at /statement/{project_id}/{YYYY-MM}.pdf. Server-side rendered via WeasyPrint; the file a CFO or auditor drops into a compliance folder.

The three formats commit to identical numbers. Every statement carries a chain-integrity check for the period, the Merkle roots of the first and last epochs it covers, and the same signature envelope used on the transparency-log head.

8. Coach-Player benchmark on SWE-bench Verified (CX.1)

The first head-to-head reproducible benchmark of an agent with vs. without Etch as the notary layer for prior decisions. This is a pilot at n=20, not a statistical claim. The flagship 100-task study (CX.2) is pre-registered below.

Setup

• Test corpus: 20 tasks from SWE-bench Verified, deterministically selected from the pinned parquet (django and sympy, hardest-difficulty-first).
• Baseline arm: agent alone. No memory retrieval, no coach.
• Treatment arm: agent plus Coach-Player pattern. Precedent lookup and reasoning-path verification against Etch's signed chain.
• Scoring: official swebench.harness.run_evaluation Docker harness. Real repo checkout, real environment, real test run per task. No simulation.
• Reproducibility pins:
  • Parquet SHA-256: a45b1fe4e2f0c8390b2b2938ac83e92ed5979000856808f3679c07812e9e6dcd
  • Corpus SHA-256: 984d74865250055c63e6a2fc86551ad11d7deb23ee81ea64744afa5773276c5c

Result

The specific task that changed

sympy__sympy-12489 is a combinatorics.Permutation subclassing bug in SymPy. The baseline patch applied cleanly and regressed nothing (8 of 8 unrelated tests still passed), but did not fix the target test (test_Permutation_subclassing). The bug requires replacing hardcoded class references with cls across a chain of internal helper calls. This is exactly the class of subtle inheritance error where prior precedent is decisive. Treatment resolved it.

19 tasks passed in both arms. 0 regressions. Coach-Player did not break any task the baseline resolved.

Honest limits of this run

• n=20 is a pilot. A single flip on 20 pairs is a signal, not a significance test.
• The 20-task subset is narrower than the full SWE-bench Verified distribution (2 of 12 repos represented).
• The statistical claim lives in CX.2 (100 tasks, 5 repos, frozen and pre-registered, below).

Reproduce

git clone https://github.com/SaravananJaichandar/coding-agent-memory-benchmark
cd coding-agent-memory-benchmark/scripts
python3 select_subset.py    # writes subset_50.json (SHA above)
python3 score.py --predictions baseline_predictions.json                  --run-id v0.9-baseline --model-name etch-v0.9-baseline                  --out baseline_results.jsonl
python3 score.py --predictions treatment_predictions.json                  --run-id v0.9-treatment --model-name etch-v0.9-treatment                  --out treatment_results.jsonl

What's next: CX.2 pre-registered

The 100-task flagship benchmark is frozen and pre-registered before the run:

• Corpus: 100 tasks, 5 repos of 20 hardest-difficulty each (django, sympy, matplotlib, scikit-learn, sphinx-doc).
• Pre-registration hash (subset_100.json SHA-256): 3d5befbe5a8783f6f2c02579376141f855265ac8a7b678b0fa72edbec59fa931
• Parquet SHA-256: a45b1fe4e2f0c8390b2b2938ac83e92ed5979000856808f3679c07812e9e6dcd (same dataset snapshot as CX.1, so CX.1 results are a strict subset).

Full results and paper materials will land here on completion.

Ready to try it?

Sign up for a pilot→   10-minute quickstart→