RunProof Protocol

RunProof is not just a receipt format — it’s a protocol for verifiable agent execution that composes from simple receipts to complex proof graphs.

💡

Current status: RunProof starts with atomic run receipts and is designed to expand into a broader proof protocol for workflows, state, governance, and settlement. Today, the strongest implemented surface is run receipt generation and verification. The higher protocol layers define the roadmap for composable proofs.

Protocol Layers

┌─────────────────────────────────────────────────────┐
│                 RUNPROOF PROTOCOL                   │
├─────────────────────────────────────────────────────┤
│ Layer 7: Agent Lifecycle    (always-on agents)     │
│ Layer 6: External Anchoring (blockchain/notary)    │
│ Layer 5: Policy Binding     (governance)           │
│ Layer 4: State Proofs       (transitions)          │
│ Layer 3: Proof Graphs       (DAG composition)      │
│ Layer 2: Signatures         (attestation)          │
│ Layer 1: Receipts           (atomic proofs)        │
└─────────────────────────────────────────────────────┘

Layer Availability

Layer	Status	Notes
Layer 1: Receipts	✅ Available	execution-proof + full-run-proof
Layer 2: Signatures	✅ Available	Ed25519 runtime signatures
Layer 3: Proof Graphs	🔶 In Progress	Lineage fields defined, composition rules in v1.3
Layer 4: State Proofs	📋 Planned	Schema reserved
Layer 5: Policy Binding	📋 Planned	ACC integration
Layer 6: External Anchoring	📋 Planned	Blockchain/notary anchors
Layer 7: Agent Lifecycle	📋 Planned	Always-on agent support

v1.2 stabilizes Layers 1-2. Higher layers follow the roadmap.

Layer 1: Receipts

The atomic primitive. A single execution receipt containing:

Hash-chained event sequence
Root hash commitment
Input/output/environment hashes
Execution metadata

{
  "run_id": "run-abc123",
  "proof_type": "receipt",
  "root_hash": "sha256:7b2042b7fd1ed84e...",
  "events": [...],
  "status": "completed"
}

Layer 2: Signatures

Ed25519 attestation proving who generated the proof:

{
  "signatures": [
    {
      "signer_id": "runtime:81cee45e9ab518db",
      "algorithm": "ed25519",
      "signature": "base64:...",
      "signed_at": "2026-03-17T00:00:00Z"
    }
  ]
}

Verification: Anyone with the public key can verify.

Layer 3: Proof Graphs

Receipts compose into DAGs representing complex workflows:

     Orchestrator (root)
        /    |    \
       ▼     ▼     ▼
   Research Writer Review
       |           ▲
       ▼           │
    Retry ─────────┘ (approval)

Relationship Types:

delegation — Parent spawned child
retry — Same task, new attempt
branch — Parallel execution
approval — Human gate passed
dependency — Waited for result
merge — Branches joined

Layer 4: State Proofs

Prove state transitions across runs:

State A ──RunProof──▶ State B ──RunProof──▶ State C

State Types:

memory — Agent memory/context
session — Conversation state
workflow — Multi-run workflow state
agent — Agent definition changes

Layer 5: Policy Binding

Link runs to governing policies:

{
  "policy_bindings": [
    {
      "policy_type": "acc_token",
      "policy_id": "acc_7f8a9b2c...",
      "policy_hash": "sha256:...",
      "binding_status": "applied"
    }
  ]
}

Binding Status:

applied — Policy was in effect
violated — Policy was violated
bypassed — Override with audit trail

Layer 6: External Anchoring

Anchor proofs to external systems for immutable settlement:

RunProof
    ↓
Anchor Request
    ↓
┌─────────────────────┐
│ Bitcoin / Ethereum  │
│ Notary Service      │
│ Timestamping Auth   │
└─────────────────────┘
    ↓
Confirmation (tx_id, block, timestamp)

Anchor Types:

bitcoin — OP_RETURN or merkle tree
ethereum — Event log or state
solana — Memo program
notary — Legal notary service
timestamping_authority — RFC 3161

Layer 7: Agent Lifecycle

Support for always-on agents with persistent ledgers:

registered → active ↔ paused → retired → archived

Features:

Heartbeat tracking
Ledger binding
Run/entry statistics
Staleness detection

Protocol Guarantees

Guarantee	How
Completeness	Hash chain breaks if events missing
Ordering	Sequential hashing enforces order
Integrity	Root hash changes if anything modified
Attribution	Signatures prove who attested
Provenance	Proof graphs trace lineage
Settlement	External anchors provide finality

Next Steps

API Reference — Full endpoint documentation
Verification — How to verify proofs
SDK Reference — Client libraries

How Verification Works Python SDK