From c77d3dc31a662824bde6104f48b53c0311f5e8aa Mon Sep 17 00:00:00 2001 From: Greg Soucy Date: Sat, 13 Jun 2026 18:29:48 -0400 Subject: [PATCH] Publish scoped execution settlement docs --- public/docs.html | 6 +- public/docs/scoped-execution-settlement.html | 54 ++++++++++++++ public/execution-receipt-demo.html | 77 ++++++++++++++++++++ public/receipts.html | 8 +- public/sdk-records.html | 4 +- 5 files changed, 142 insertions(+), 7 deletions(-) create mode 100644 public/docs/scoped-execution-settlement.html create mode 100644 public/execution-receipt-demo.html diff --git a/public/docs.html b/public/docs.html index 278fd7e..03fc180 100644 --- a/public/docs.html +++ b/public/docs.html @@ -48,7 +48,7 @@ @@ -68,6 +68,7 @@

Start building

Wrap Your Agent

Use the SDK to wrap actions and emit canonical receipts.

SDK Records

Install the SDK and emit canonical action records and receipts.

 +

Execution Receipt Demo

Compare execution-only, private settlement, and invalid scoped receipt examples.

API Reference

Inspect endpoints, payloads, and validation behavior.
@@ -78,6 +79,7 @@

Understand the protocol

Protocol

Core architecture, CLAS model, and trust boundaries.

Capabilities

Understand the CLAS action surface and capability families.

Receipts

See canonical receipt structure and verifier expectations.

 +

Scoped Execution + Settlement

Learn clas.execution.receipt.v1: one receipt, two attestations, and private settlement commitments.

Live Proof

Walk through proof flow and tamper-invalid verification outcomes.

Genesis Receipt Verification

Retrieve and cryptographically verify a stored genesis receipt by receipt ID.

 @@ -120,6 +122,6 @@

Legacy and discovery docs

- + diff --git a/public/docs/scoped-execution-settlement.html b/public/docs/scoped-execution-settlement.html new file mode 100644 index 0000000..98e746d --- /dev/null +++ b/public/docs/scoped-execution-settlement.html @@ -0,0 +1,54 @@ + + + + + +Scoped Execution + Settlement Receipts | CommandLayer Docs + + + + + + + + + + +
+
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.
+

Schema publication

The runtime schema name is clas.execution.receipt.v1. Public schema sync for /schemas/execution/execution.receipt.schema.json is not wired in this site yet, so schema publication needs a follow-up sync. Until then, treat this page and the demo as public documentation for the receipt model.

+
+ + + diff --git a/public/execution-receipt-demo.html b/public/execution-receipt-demo.html new file mode 100644 index 0000000..9cdc878 --- /dev/null +++ b/public/execution-receipt-demo.html @@ -0,0 +1,77 @@ + + + + + +Execution Receipt Demo | CommandLayer + + + + + + + + + + +
+

Execution receipt demo

Private settlement, public accountability. These examples show how clas.execution.receipt.v1 scopes signatures so execution and settlement are independently attested.

Verify in VerifyAgent paste flow Read docs

+

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

+
Valid execution-only

Agent signs execution

The agent/runtime signs only execution fields. No settlement claim is present.

{
+  "schema": "clas.execution.receipt.v1",
+  "receipt_id": "rcpt_exec_only_01JZ8Q7",
+  "verb": "clas.agent.execute",
+  "agent": "research-agent.example.eth",
+  "action": { "name": "summarize", "input_hash": "sha256:8f12...a441" },
+  "proofs": [
+    {
+      "type": "execution",
+      "signer": "research-agent.example.eth",
+      "covers": ["receipt_id", "verb", "agent", "action"]
+    }
+  ]
+}
Valid private settlement

Rail signs settlement

The same receipt has execution proof from the agent and settlement proof from the rail/payer. Public data stays opaque.

{
+  "schema": "clas.execution.receipt.v1",
+  "receipt_id": "rcpt_private_settle_01JZ8Q8",
+  "verb": "clas.agent.execute",
+  "agent": "research-agent.example.eth",
+  "action": { "name": "summarize", "input_hash": "sha256:8f12...a441" },
+  "settlement": {
+    "status": "settled",
+    "payment_ref": "settle_ref_G7m_private",
+    "payee_commitment": "sha256:c0ff...e129"
+  },
+  "proofs": [
+    {
+      "type": "execution",
+      "covers": ["receipt_id", "verb", "agent", "action"]
+    },
+    {
+      "type": "settlement",
+      "covers": ["receipt_id", "settlement"]
+    }
+  ]
+}
Invalid scope

Agent covers settlement

This is invalid because an agent execution signer attempts to cover settlement. Settlement must be attested by the rail, payer, or settlement authority.

{
+  "schema": "clas.execution.receipt.v1",
+  "receipt_id": "rcpt_invalid_agent_settle",
+  "verb": "clas.agent.execute",
+  "agent": "research-agent.example.eth",
+  "settlement": {
+    "status": "settled",
+    "payment_ref": "0xabcd...raw_tx_hash"
+  },
+  "proofs": [
+    {
+      "type": "execution",
+      "signer": "research-agent.example.eth",
+      "covers": ["receipt_id", "verb", "agent", "action", "settlement"]
+    }
+  ]
+}
+
Privacy checklist

Before publishing a receipt

  • Do not publish settlement.stealth_address.
  • Do not publish a raw 0x... payment transaction hash as payment_ref.
  • Use an opaque settlement reference and a sha256: payee commitment.
  • Verify private payment linkage through selective disclosure.
+
+ + + diff --git a/public/receipts.html b/public/receipts.html index a0168c3..6b05ca7 100644 --- a/public/receipts.html +++ b/public/receipts.html @@ -38,12 +38,14 @@
-
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
+
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 CapabilitiesScoped Settlement Docs
+ +

Scoped execution + private settlement

Private settlement, public accountability. clas.execution.receipt.v1 supports one receipt with two independently scoped attestations over the same receipt_id: execution signed by the agent/runtime and settlement signed by the rail, payer, or settlement authority.

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

Read scoped receipt docs Open demo

Genesis receipts

After a claimed agent’s public cards are pinned, CommandLayer can issue a signed genesis receipt. Genesis is chain index 0: the verifiable origin point for future receipt-linked history.

receipt_type: genesis chain_index: 0 previous_receipt_hash: null @@ -95,6 +97,6 @@ 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.

- + diff --git a/public/sdk-records.html b/public/sdk-records.html index 20fdc6e..a4a3703 100644 --- a/public/sdk-records.html +++ b/public/sdk-records.html @@ -39,7 +39,7 @@
@@ -134,6 +134,6 @@ })();
- +