Receipts

The CommandLayer receipt model

A CommandLayer receipt is not a log entry. It is a cryptographic artifact that proves what an agent, runtime, or external system did — and lets anyone verify it independently after the fact.

Verify a ReceiptView Live ProofExplore Capabilities

What a receipt proves

  • which verb/action ran
  • what input was provided
  • what output was returned
  • which signer produced the proof
  • which canonicalization/hash/signature algorithms were used
  • whether the result was tampered with after signing

Schema validation checks shape. Proof verification checks truth. A schema-valid receipt can still fail verification if the hash or signature is wrong.

Receipt structure

{
  "receipt_id": "rcpt_01J9XK4TAV9ZJH0YQWE8YQ23Z7",
  "signer": "runtime.commandlayer.eth",
  "verb": "authorize",
  "source": { "system": "commandlayer.runtime", "env": "prod" },
  "subject": { "type": "payment", "id": "pay_2M9eQ" },
  "input": { "amount": "49.99", "currency": "USD" },
  "output": { "decision": "approved", "policy": "risk.v3" },
  "execution": { "status": "ok", "duration_ms": 87 },
  "ts": "2026-05-25T12:34:56.000Z",
  "metadata": {
    "trace": {
      "trace_id": "trc_6GqHk8z1Jf9",
      "span_id": "spn_8sQ2xR5b"
    },
    "proof": {
      "canonicalization": "json.sorted_keys.v1",
      "hash": {
        "alg": "SHA-256",
        "value": "3d68cfcf4a84d82e2f8f5019d76f4ef31236d98ae56db89f665c2a9960df2a71"
      },
      "signature": {
        "alg": "Ed25519",
        "kid": "vC4WbcNoq2znSCiQ",
        "value": "3Fh9vG6kXo...redacted_example...j2Q="
      },
      "signer_id": "runtime.commandlayer.eth"
    }
  }
}

Required proof fields

  • metadata.proof.canonicalization
  • metadata.proof.hash.alg
  • metadata.proof.hash.value
  • metadata.proof.signature
  • metadata.proof.signer_id
  • metadata.trace optional for span/workflow linking

metadata.trace and metadata.proof

metadata.trace links spans across workflows: event → payment → action → verification.

metadata.proof is the portable proof envelope containing canonicalization, hash, signature, key id, and signer identity.

Canonicalization

json.sorted_keys.v1 is the standard canonical JSON receipt path. Deterministic canonicalization creates stable bytes for hashing and signing.

Verification lifecycle

Receipt received→structure checked→canonical payload rebuilt→SHA-256 hash recomputed→ENS TXT public key resolved→Ed25519 signature verified→VERIFIED or INVALID

status: VERIFIED public_key_source: ens_txt ens_resolved: true hash_matches: true signature_valid: true key_id: vC4WbcNoq2znSCiQ

There is no silent local fallback key in production.

Trust Verification verbs

verify, authenticate, authorize, attest, sign, permit, grant, approve, reject, endorse

Integration receipt types

observe receipts for external events such as Coinbase webhooks.

action receipts for paid or executed actions such as x402 paid actions.

Coinbase HMAC authenticates the inbound event to the server; CommandLayer signing makes the normalized event portable and publicly verifiable. The payment rail proves payment acceptance/settlement; CommandLayer proves what executed after payment acceptance.

Valid

status: VERIFIED hash_matches: true signature_valid: true

Tampered

status: INVALID hash_matches: false signature_valid: false

Trust boundaries

  • Runtime signs.
  • VerifyAgent verifies.
  • MCP bridges.
  • SDK wraps.
  • Schemas describe.
  • Capabilities organize.
  • ENS anchors signer identity.

Relationship to ENS and ERC-8004

CLAS is network-agnostic. ENS and ERC-8004 are identity/discovery layers that complement CLAS. ENS TXT records on runtime.commandlayer.eth carry the public key used for verification. ERC-8004 can provide agent registry/identity. CLAS defines what the action/receipt proves.

VerifyAgent

VerifyAgent is the reference verifier for CommandLayer receipts. It does not sign receipts, execute actions, or hold runtime keys. It verifies proof produced by signers such as runtime.commandlayer.eth.