Protocol Architecture

CommandLayer is the receipt layer for external events, paid machine actions, and agent execution.

CommandLayer defines how agent actions, external events, and paid machine workflows are described, signed, transported, and verified — without making MCP, SDKs, or transport layers the trust root. Agents don’t make claims — they produce proof.

View live proof Verify a receipt

Architecture stack

What each layer does — and what it does not do.

Schema and contract

CLAS

Defines action and receipt contracts. Canonical schema source for verb request/receipt shapes.

Action surface

Capabilities

Organize the verb/action surface available to builders. Trust Verification is live; other families may be draft or planned.

Crypto primitives

runtime-core

Canonicalization, hashing, signing, and verification primitives.

Signing runtime

runtime

Executes actions and signs canonical receipts in production.

Reference verifier

VerifyAgent

Checks hash, signature, signer identity, key id, and canonicalization.

Transport integration

MCP Bridge

Integration plumbing for MCP clients. It does not sign and does not hold runtime keys.

Developer integration

agent-sdk

Developer wrapper for emitting receipts from agent actions. Not the trust root.

Identity anchor

ENS

Anchors signer identity through runtime.commandlayer.eth TXT records.

Trust boundaries

Trust boundary: responsibilities by layer

  • Runtime signs.
  • VerifyAgent verifies.
  • MCP bridges.
  • SDK wraps.
  • Schemas describe.
  • Capabilities organize.
  • ENS anchors identity.
  • Apps consume verified results.
  • Coinbase HMAC authenticates webhook delivery to the receiving server.
  • x402/payment rails prove payment acceptance or settlement.
  • CommandLayer proves the normalized event/action receipt.
  • ENS anchors signer identity.
  • VerifyAgent verifies hash, signature, signer, key id, and canonicalization.

Verification lifecycle

From event/action input to verifiable receipt output.

  1. Action/event received.
  2. Normalized into CLAS receipt.
  3. Canonical payload rebuilt using json.sorted_keys.v1.
  4. SHA-256 hash computed.
  5. Receipt signed with Ed25519.
  6. Signer public key resolved from ENS TXT.
  7. Verifier checks hash/signature/signer/kid/canonicalization.
  8. VERIFIED or INVALID.

Successful production verification fields

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

How external systems connect

External systems authenticate events or payments to the receiving server using their own mechanism. CommandLayer signs the normalized result as a portable receipt. Public verifiability begins after CommandLayer signs.

Coinbase Payments Webhook

  • endpoint: /api/examples/coinbase-webhook
  • server-side HMAC verification
  • normalized observe receipt
  • signed by runtime.commandlayer.eth
  • verified through /api/verify
  • Coinbase HMAC is private server authentication, not public proof by itself

x402 Paid Action

  • endpoint: /api/examples/x402-paid-action
  • demo_accepted_envelope mode by default
  • provider_verified mode when X402_PROVIDER_VERIFICATION_URL is configured
  • payment rail proves payment acceptance/settlement
  • CommandLayer proves execution/receipt

Relationship to ENS and ERC-8004

CLAS is network-agnostic. ENS and ERC-8004 are identity/discovery layers that can complement CLAS. ENS TXT records anchor the runtime signer key. ERC-8004 can provide agent registry and identity. CLAS defines what the action/receipt proves.

Where to go next

Explore Capabilities

See live and planned verb families.

Read Receipts

Inspect the artifact model and fields.

View Live Proof

Observe production verification behavior.

Explore Integrations

Map external systems to receipt outputs.

Build with SDK

Emit receipts from your agent workflows.

Verify a Receipt

Run verifier checks against payloads.