Questions people will ask.
Answers that don’t wiggle.
If someone is confused about CommandLayer, it’s usually one of these. This page bashes the misunderstandings fast: what’s free, what’s taxed, what ENS actually anchors, and how receipts become verifiable evidence across runtimes.
FAQ
Click a question. Deep answers, but still clean. If you want to add more later, just duplicate a
<details class="faq"> block.
What is CommandLayer? ▾
CommandLayer is a semantic contract for autonomous agents: canonical verbs + strict JSON schemas + verifiable identity + receipts.
It standardizes the part everyone keeps reinventing: what the call means, what the request shape is, what the receipt looks like, and how an agent claims it implements a verb.
Why does CommandLayer exist? ▾
Because most “agent systems” are private prompt formats and one-off APIs. That doesn’t scale. The moment you change a vendor or runtime, everything breaks.
CommandLayer locks down the semantics (verbs + schemas) so the ecosystem can compete on execution without fragmenting meaning.
- No guessing request formats.
- No brittle “prompt contracts.”
- Receipts you can verify across runtimes.
What’s free vs what’s taxed? ▾
Commons executes free. Commercial is taxed.
- FREE: schemas, identity, discovery, Commons execution (best-effort reference grade)
- TAXED: commercial execution, throughput/volume, guarantees, priority/certified execution
- NEVER TAXED: meaning, validation, interoperability
Where does the tax live (and where does it NOT live)? ▾
The tax is not in the schema, not in the Agent Card, not in ENS, and not in discovery. That stuff stays neutral.
The tax lives at execution time inside runtimes (metering, guarantees, priority, certified delivery, throughput control).
What does an ENS name actually anchor in CommandLayer? ▾
An ENS name is the interface anchor: a single verifiable reference point that binds schemas, validation, versioning, trust continuity, and receipts. ENS provides continuity and coordination — not trust. Trust comes from schema hashes and validation.
- Human-readable entrypoint
- Schema authority via ENS TXT → CID/IPNS
- Validation pointer (“did this conform?”)
- Version boundary (pin or float)
- Receipt namespace (evidence tied to name + schema hash)
- Governance handle (ownership → updates)
What are Agent Cards? ▾
Agent Cards are JSON descriptors that bind an agent’s identity to what it implements: ENS name, verbs, schema versions, and entrypoints.
They exist so clients can discover and route agents without guessing or scraping random docs.
What is a receipt, and why is it important? ▾
A receipt is the standardized output evidence of an execution. It binds: verb, version, schema hash, trace info, and (optionally) execution class.
Receipts let anyone verify after the fact that an execution conformed to the claimed schema — across runtimes.
- verb + version
- schema hash
- execution result
- trace metadata
- execution class / authorization reference (if commercial)
How do I validate requests and receipts? ▾
You validate against the published JSON Schemas (draft 2020-12). That’s the whole point: independent verification.
- Validate the request before sending.
- Validate the receipt after execution.
- Compare schema hashes / CIDs when you care about immutability.
- If schema validation fails, execution MUST NOT occur and no receipt MUST be emitted.
What is Runtime in CommandLayer? ▾
Runtime is the execution layer: routing, policy, guarantees, and economics. It consumes the same free schemas and emits standard receipts.
Runtime is where “commercial is taxed” is enforced cleanly (metering, SLA, priority, certified execution).
Can other people run runtimes, or is it centralized? ▾
Others can run runtimes. The semantics are neutral; execution is competitive. A third-party runtime can still honor the same schemas and receipts.
The key is that meaning stays portable — the ecosystem can compete on reliability, cost, latency, guarantees, and certification.
How does versioning work? Will v1 break? ▾
Versions are explicit. v1 schemas live under versioned paths and can be pinned. New behavior ships under v2 (or v1.1) without silently breaking existing integrations.
What are “Commercial verbs”? ▾
Commercial verbs are the economic flow verbs (e.g. authorize, checkout,
purchase, ship, verify) where money moves or guarantees matter.
Schemas remain free. The execution can be metered and receipts can reflect commercial execution.
Does CommandLayer compete with x402 or ERC-8004? ▾
No. x402 is a payment/transport rail. ERC-8004 is discovery/agent standards territory. CommandLayer defines machine intent: what the call means and how it’s validated.
Is this “open core”? ▾
No. “Open core” usually paywalls features or access to the standard itself. CommandLayer keeps standards open: meaning, schemas, identity, discovery, interoperability.
Monetization is where it belongs: execution outcomes (throughput, guarantees, certified delivery).
How do I start using CommandLayer today? ▾
Start with a single Commons verb and do the boring thing correctly: validate request → execute → validate receipt.
- Pick a verb (e.g.
summarize). - Use the published schema to validate your payload.
- Generate/consume a receipt and validate it.
- If you’re publishing an agent, add an Agent Card.
Still have a question?
If you add one more FAQ, make it one of these: “what does a receipt contain?”, “how do I resolve ENS TXT to schemas?”, or “how do I know an agent actually implements a verb?”
Next stop
Open the docs for the exact schema paths and a full request/receipt walkthrough, or jump into the live demo to see receipts in motion.