How We Built a Transparency Log for AI Agent Work

RFC 6962 Merkle tree + Ed25519 signed tree heads + RFC 3161 external anchoring. This note explains the cryptographic design, the threat model, and what we intentionally do not claim.

March 2026 · AiGentsy Engineering · Full technical design note

TL;DR: AiGentsy uses an RFC 6962 Merkle tree with Ed25519 signed tree heads and RFC 3161 external anchoring to make AI agent work independently verifiable. Proof bundles are portable, verification is offline, and the threat model is published.

The Problem

AI agents generate work product — code, content, analysis, design. Today, there is no standard way to prove what was generated, when, and by whom. If an agent writes a marketing brief, how does the buyer verify it was actually produced by the claimed agent at the claimed time?

Existing approaches fall short:

The gap: a lightweight protocol that creates cryptographic proof of agent work, makes it independently verifiable, and ties it to settlement — without requiring distributed consensus.

Our Approach

Three cryptographic layers, each building on established standards:

1. Hash-Linked Event Chain

Every state change in a deal (proof created, verified, approved, settled) produces a hash-linked event. Each event includes a prev_hash field containing the SHA-256 hash of the previous event. Tampering with any event breaks the chain.

Canonical formula:

event_hash = SHA-256( json.dumps({ event_id, event_type, deal_id, actor_id, timestamp, payload, prev_hash }, sort_keys=True) )

This is the same hash-chaining technique used in Git commits and Certificate Transparency logs. The sort-keys canonical form ensures deterministic hashing regardless of JSON key ordering.

2. Merkle Transparency Log (RFC 6962)

Settlement-finality events are appended to an append-only Merkle tree following Certificate Transparency conventions:

Anyone can download the signed tree head, fetch an inclusion proof, and verify that a specific proof bundle appears in the log — without trusting the operator.

The 0x00 / 0x01 domain separation prevents second-preimage attacks where a leaf could be confused with an internal node. This is the same protection used in Certificate Transparency for TLS certificates.

3. External Anchoring (RFC 3161)

Hourly (or on tree growth), the current Merkle root hash is submitted to an RFC 3161 Timestamping Authority. The TSA response is stored as an anchor receipt.

This creates an external, operator-independent timestamp commitment: even if AiGentsy's operator is compromised, the TSA receipt proves the root hash existed at a specific time. The anchoring is independently verifiable by anyone who has the TSA's public certificate.

Offline Verification

Every proof bundle exported from AiGentsy is a self-contained JSON document that can be verified entirely client-side, with no network access required. The verification algorithm runs in 5 steps:

  1. Recompute each event_hash from canonical JSON and check it matches the stored hash
  2. Walk the hash chain — verify each event's prev_hash matches the previous event's hash
  3. Recompute bundle_hash from the complete bundle contents
  4. Verify Merkle inclusion proof against the signed tree head
  5. Verify Ed25519 STH signature against the published public key

Two implementations of this algorithm are available:

Threat Model: What We Don't Protect Against

We are explicit about limitations:

  • Operator compromise: A compromised operator could withhold entries or sign fraudulent STHs. Mitigation: RFC 3161 anchoring + published public key + client-side verification create external checkpoints that a compromised operator cannot retroactively alter.
  • Content quality: The protocol proves that work was submitted and verified, not that the work is good. Output quality is the agent's responsibility, not the protocol's.
  • Key compromise: If Ed25519 signing keys are stolen, the attacker can sign arbitrary STHs. Mitigation: key rotation with grace periods, revocation, and published key history.

AiGentsy is not a blockchain. It is not a distributed ledger. The transparency log is operated by AiGentsy. We believe this is the right tradeoff: a single-operator Merkle log with RFC 3161 external anchoring gives you verifiability without the complexity, latency, and cost of distributed consensus.

For a full threat model including trust comparisons, see Section 6 of the protocol design note.

Conformance

We publish a conformance suite with 35 test vectors covering all hash algorithms, fee calculations, and protocol invariants. Third-party implementations can verify their output matches ours byte-for-byte.

Settlement Identity

The transparency log is one layer of a broader settlement protocol. The full lifecycle is:

  1. Proof at handoff — the agent stamps its work output
  2. Verification at acceptance — the buyer verifies the proof bundle
  3. Settlement when value moves — exactly-once payment via idempotency keys and a write-ahead outbox
  4. Audit after the fact — the transparency log provides an immutable record

The Merkle log ensures step 4 is independently auditable. But proof creation (step 1) requires no signup and no API key — it is the zero-friction entry point into the protocol.

Try It

References

Try Proof Playground Standards & Specs Full Design Note Verified Builder Program

This is a public technical note, not a peer-reviewed paper. For the complete protocol specification including hash formulas, fee schedule, and conformance vectors, see the Standards page.