Contract
Request/result schemas, service version, execution mode, acceptance conditions, and evidence requirements define what a buyer is purchasing.
Protocol background
The protocol supports the product. It is not the product.
CommandLayer keeps a small set of open, inspectable rules for canonicalization, signatures, receipt scopes, schemas, and verification. The commercial factory uses those rules to manufacture paid machine outcomes.
Boundary map
Separate what must stay stable from what must stay replaceable.
Execution
Providers, primitive graphs, retries, state, budgets, and routing can change behind a stable contract.
Proof
Canonical hashes, signatures, signer identity, timestamps, and scoped evidence make execution independently inspectable.
Trust model
Receipts prove integrity and provenance—not universal truth.
Canonicalization
The same covered payload must produce the same canonical representation.
deterministicCryptographic signature
The verifier checks whether the declared signer signed the covered receipt payload.
integrityScoped evidence
Execution proof covers execution fields. Settlement proof, when present, remains a separate scope.
separatedAcceptance checks
A service may prove that declared checks passed without claiming the output is objectively true in every external sense.
contractualAdapters
Identity, payment, and discovery remain modular.
A service can be published through different naming, registry, discovery, and settlement systems without forcing those systems into the core receipt contract.
Identity adapters
ENS, HTTPS identity, wallets, ERC-8004 registration, and other identifiers can coexist.
Discovery adapters
Owned catalog, OpenAPI, MCP registries, x402 discovery, 8004scan, and future directories are publication surfaces.
Settlement adapters
Credits, cards, x402, invoicing, or future rails can settle a quote while metering remains canonical.
Execution receipt
Payment evidence and execution evidence are different objects.
A payment can prove that value settled. An execution receipt can prove what service ran, what inputs/outputs were hashed, what checks were applied, and who signed the result. Neither should impersonate the other.
Conceptual scoped receipt
{
"service": "example@1.0",
"execution": {
"input_hash": "sha256:...",
"output_hash": "sha256:...",
"accepted": true
},
"proofs": ["execution", "optional settlement scope"]
}