Verifier

Verify agent receipts by proof, not claim.

Paste a CommandLayer receipt, inspect its canonical proof, and confirm whether the hash and Ed25519 signature still match.

Paste a CommandLayer receipt to verify its canonical hash, Ed25519 signature, signer identity, key id, and canonicalization.

Verify a receipt Verify Genesis by ID View production proof

Already have a stored genesis receipt ID? Retrieve and verify it through the public proof surface.

Receipts are not trusted by claim. They are verified by proof.
In production, signer public keys are resolved from ENS TXT records such as runtime.commandlayer.eth. A successful verification returns public_key_source: ens_txt, ens_resolved: true, hash_matches: true, and signature_valid: true.
Runtime production is live. Runtime signs canonical Trust Verification receipts. MCP E2E against production runtime passes: STEP 1 SIGNED, STEP 2 VERIFIED, STEP 3 TAMPERED INVALID. Runtime signer: runtime.commandlayer.eth with kid=vC4WbcNoq2znSCiQ. Canonical proof uses metadata.proof.canonicalization=json.sorted_keys.v1, metadata.proof.hash.alg=SHA-256, and metadata.proof.signature.alg=Ed25519.

Receipts from the Coinbase webhook and x402 paid-action examples can be pasted here for independent verification. Explore integrations · Open Proof Flow Composer

Learn what this means: Read the receipt model · View Live Proof · Explore integrations · Explore capabilities · Protocol architecture

What gets checked

Manual verifier checks, not just shape.

Receipt structure

Canonical metadata.proof envelope

json.sorted_keys.v1 canonical hash

SHA-256 hash match

Ed25519 signature validity

Signer identity and key id

Supported capability verb

Tamper resistance

A receipt is only verified when hash and signature checks pass. Schema-valid alone is not verified.

Manual verifier input

—

Run verification to see verdict.

Proof surfaces

Need automatic verification? Use the webhook auto-verify demo to verify receipts without manual paste. Open demo.

Manual verifier

Paste a receipt and inspect every verification check.

Proof URLs

Open a receipt verification result from a shareable URL.

Embedded badges

Display verified/invalid state inside an app or product UI.

Ambient verification

Let systems verify receipts automatically through SDKs, APIs, webhooks, MCP tools, or agent-to-agent flows.

Backed by CLAS Trust Verification

VerifyAgent validates canonical CLAS Trust Verification receipts using schemas where applicable, then checks canonical hash, Ed25519 signature, signer identity, and trust verb.

Schema validation supports verification, but does not replace cryptographic proof.

Canonical receipt example

{
  "metadata": {
    "proof": {
      "canonicalization": "json.sorted_keys.v1",
      "hash": { "alg": "SHA-256" },
      "signature": {
        "alg": "Ed25519",
        "kid": "vC4WbcNoq2znSCiQ"
      },
      "signer_id": "runtime.commandlayer.eth"
    }
  }
}

Verification result states

VALID / VERIFIED = hash and signature checks passed. INVALID = receipt is tampered, stale, malformed, or has hash/signature/signer metadata mismatch. TRANSPORT_ERROR = verifier/runtime unavailable or request failed.

Manual verifier = paste a receipt and inspect checks. Automatic verification = SDKs, APIs, proof URLs, embedded badges, webhooks, MCP tools, or agent-to-agent flows verify receipts without manual copy/paste. MCP is a bridge, not a signer. Runtime signs. Verifier validates.