clas.execution.receipt.v1

Scoped execution and settlement receipts

Private settlement, public accountability. CommandLayer receipts can prove what an agent executed while separately proving that a payment rail, payer, or settlement authority attested settlement without exposing private payment data.

Execution and settlement are independently attested.
The ENS capability name is the durable proof identity.
Payment addresses can rotate, hide, or settle privately.

What it is

clas.execution.receipt.v1 is the scoped receipt schema for one receipt that can carry two attestations over the same receipt_id: an execution proof signed by the agent/runtime and a settlement proof signed by the rail, payer, or settlement authority.

  • One receipt: one public proof artifact and one durable identifier.
  • Two attestations: execution and settlement each cover only their own fields.
  • Same receipt_id: ties the execution and settlement statements without collapsing trust boundaries.

Why proofs are separate

The agent knows what it executed; it does not authoritatively know final private settlement state. Keeping proof scopes separate prevents an agent signature from being misread as a payment guarantee.

  • The agent signs execution only.
  • The rail, payer, or settlement authority signs settlement only.
  • The public receipt commits to private settlement data without revealing it.

Settlement authority

Settlement proof belongs to the system that can attest payment acceptance, settlement, or payer authorization. That may be a payment rail, payer wallet, checkout service, or internal settlement authority. The signer is accountable for the settlement claim and covers only receipt_id and settlement.

Opaque references and commitments

payment_ref must be opaque so a public receipt does not leak a raw transaction hash, wallet graph, processor id, or private invoice linkage. payee_commitment is a sha256: hash commitment that lets a verifier later check disclosed payee data without publishing the payee address up front.

Example scoped receipt

{
  "schema": "clas.execution.receipt.v1",
  "receipt_id": "rcpt_scoped_01JZ8Q7EXAMPLE",
  "verb": "clas.agent.execute",
  "agent": "research-agent.example.eth",
  "action": { "name": "summarize", "input_hash": "sha256:4d8c...9a1e" },
  "settlement": {
    "status": "settled",
    "payment_ref": "settle_ref_8VqT9n_private",
    "amount": "2.50",
    "currency": "USDC",
    "payee_commitment": "sha256:7ad3...c091"
  },
  "proofs": [
    {
      "type": "execution",
      "covers": ["receipt_id", "verb", "agent", "action"]
    },
    {
      "type": "settlement",
      "covers": ["receipt_id", "settlement"]
    }
  ]
}

Selective disclosure

The public receipt contains opaque references and commitments. A verifier that is authorized to see private payment details receives a disclosure package with the original payee data, private settlement metadata, and nonce/salt. VerifyAgent or another verifier hashes the disclosed data and compares it to the public sha256: commitment while checking the settlement attestation signature.

VerifyAgent display

VerifyAgent displays separate proof cards: Execution proof for the agent/runtime signature and Settlement proof for the rail/payer/settlement authority signature. A receipt can be execution-only, execution plus settlement, or invalid when a signer tries to cover fields outside its scope.

Open demo Verify paste flow

Privacy warning

  • Do not publish settlement.stealth_address.
  • Do not publish a raw 0x... payment transaction hash as payment_ref.
  • Use an opaque settlement reference.
  • Use a sha256: payee commitment.
  • Private payment linkage is verified through selective disclosure, not by exposing payment addresses or raw transaction hashes in public receipts.