diff --git a/README.md b/README.md index dced222..8185971 100644 --- a/README.md +++ b/README.md @@ -1,42 +1,34 @@ -# commandlayer-org +# CommandLayer -Agents don’t make claims — they produce proof. -Wrap → sign → verify. -CommandLayer turns any agent action into a signed, verifiable receipt. -VerifyAgent.eth is the public verifier for receipts produced by ENS-named agents. - -## Shipped proof flow - -- Verifier UI: https://www.commandlayer.org/verify.html -- Raw verifier API: POST https://www.commandlayer.org/api/verify -- Callable VerifyAgent endpoint: POST https://www.commandlayer.org/api/agents/verifyagent -- npm: `npm install @commandlayer/agent-sdk` +CommandLayer turns agent actions into signed, independently verifiable receipts. ## Core flow -Agent action -→ SDK wraps action -→ signed receipt is emitted with ENS identity -→ VerifyAgent resolves signer identity from ENS and verifies receipt -→ VERIFIED or INVALID - -If the output changes, the proof breaks. +Action requested +→ runtime signs canonical receipt +→ verifier checks `metadata.proof` +→ valid receipts pass +→ tampered receipts fail -## Repos +## Verified surfaces -- **agent-sdk**: wrap any agent action and emit a signed receipt -- **verifyagent**: reference verifier and tamper-detection demo -- **commandlayer-org**: hosted UI, public APIs, and docs +- Manual verifier: `/verify.html` +- Production proof: `/stack-proof-demo.html` +- Automatic verification demo: `/webhook-auto-verify.html` +- Runtime verifier: `POST https://runtime.commandlayer.org/verify` +- Runtime signer endpoints: `POST https://runtime.commandlayer.org/trust-verification/{verb}/v1.0.0` +- SDK: `@commandlayer/agent-sdk@1.2.0` -## Developer quickstart +## SDK example ```ts import { CommandLayer } from "@commandlayer/agent-sdk"; const cl = new CommandLayer({ agent: "runtime.commandlayer.eth", - privateKey: process.env.CL_PRIVATE_KEY_PEM, - keyId: "vC4WbcNoq2znSCiQ" + privateKeyPem: process.env.CL_PRIVATE_KEY_PEM, + keyId: "vC4WbcNoq2znSCiQ", + verifierUrl: "https://runtime.commandlayer.org/verify" }); const result = await cl.wrap("summarize", async () => { @@ -47,126 +39,38 @@ const verified = await cl.verify(result.receipt); console.log(verified.status); ``` -## Public verification APIs - -### 1) `POST /api/verify` - -**Purpose:** Verifies a raw CommandLayer receipt. - -**Request:** Raw receipt JSON. - -**Response:** - -```json -{ - "ok": true, - "status": "VERIFIED", - "reason": "Receipt verification passed.", - "signer": "runtime.commandlayer.eth", - "verb": "agent.execute", - "hash": "...", - "hash_matches": true, - "signature_valid": true, - "ens_resolved": true, - "key_id": "..." -} -``` - -### 2) `POST /api/agents/verifyagent` - -**Purpose:** Callable VerifyAgent.eth endpoint for agent-to-agent or app-to-agent verification. +## Canonical proof fields -**Request:** +- `metadata.proof.canonicalization = json.sorted_keys.v1` +- `metadata.proof.hash.alg = SHA-256` +- `metadata.proof.hash.value` +- `metadata.proof.signature.alg = Ed25519` +- `metadata.proof.signature.kid = vC4WbcNoq2znSCiQ` +- `metadata.proof.signature.value` +- `metadata.proof.signer_id = runtime.commandlayer.eth` -```json -{ - "receipt": { "...": "CommandLayer receipt" } -} -``` - -**Response:** - -```json -{ - "agent": "verifyagent.eth", - "action": "verify_receipt", - "ok": true, - "status": "VERIFIED", - "result": { - "reason": "Receipt verification passed.", - "hash_matches": true, - "signature_valid": true, - "ens_resolved": true - } -} -``` - -VerifyAgent.eth does not execute the original task. It verifies whether a submitted receipt is valid or tampered. - -### cURL examples - -```bash -curl -X POST https://www.commandlayer.org/api/verify \ - -H "Content-Type: application/json" \ - --data-binary @public/examples/sample-receipt.json -``` - -```bash -printf '{"receipt":' > verifyagent-body.json -cat public/examples/sample-receipt.json >> verifyagent-body.json -printf '}' >> verifyagent-body.json - -curl -X POST https://www.commandlayer.org/api/agents/verifyagent \ - -H "Content-Type: application/json" \ - --data-binary @verifyagent-body.json -``` - -## What verification checks - -- canonical JSON payload using `json.sorted_keys.v1` -- SHA-256 hash matches `metadata.proof.hash_sha256` -- Ed25519 signature validates -- signer identity and verification metadata resolve from ENS (`cl.sig.pub`, `cl.sig.kid`, `cl.sig.canonical`, `cl.receipt.signer`) -- tampered input/output returns `INVALID` - -VerifyAgent resolves signer keys from ENS TXT records. -For the hackathon demo, `runtime.commandlayer.eth` is supported via a labeled fallback resolver that mirrors the ENS record structure. -The verification flow is designed to operate against live ENS records. - -## Scope - -CommandLayer focuses on a single primitive: verifiable agent execution. - -Every action produces a signed receipt. -Every receipt can be independently verified. - -The current public demo focuses on this proof loop. - -## Local development - -### Install - -```bash -npm install -``` - -### Run locally - -```bash -vercel dev -``` +## Automatic verification proof -If you use another local workflow, keep the site static-first and preserve published URL paths. +Valid receipt: -## Deployment note +- `status = accepted` +- `verifier_status = VALID` +- `hash_matches = true` +- `signature_valid = true` -Published URLs are part of the protocol surface. +Tampered receipt: -Do not rename or move stable public paths for: +- `status = rejected` +- `verifier_status = INVALID` +- `hash_matches = false` +- `signature_valid = false` -- docs pages -- schema URLs -- Agent Card URLs -- demo surfaces +## Trust boundaries -CommandLayer is designed for ENS-named agents to be verifiable and discoverable, with identity and verification metadata resolved directly from ENS. +- Runtime signs. +- Verifier validates. +- MCP bridges. +- SDK wraps. +- Schemas describe. +- Schema-valid alone is not verified. +- Webhook sender authentication is separate from receipt verification. diff --git a/public/about.html b/public/about.html index 65b326b..ac865c9 100644 --- a/public/about.html +++ b/public/about.html @@ -1,212 +1,28 @@ - -CommandLayer — Agents can act. CommandLayer proves they acted. - + + +About | CommandLayer + - + + - - - - - - - - -
-
▸ about
-

Agents can act.
CommandLayer proves they acted.

-

CommandLayer exists because agent systems need evidence, not vibes. If an agent can trigger actions in the real world, there should be a signed receipt that another party can inspect and verify later.

-

That trust model is public too: CommandLayer's ERC-8004 registration is visible on BaseScan ↗ as an on-chain proof anchor.

- -
- Start with Quickstart → - See receipts live → -
- -
- -
Why trust the system
-

CommandLayer is a trust layer for agent execution. The system stays split into clear roles so the proof model remains inspectable instead of turning into one opaque product.

- -
-
Commons
The canonical open contract layer and minimum verifiable receipt.
-
Commercial
A commerce-oriented extension built on the same contract discipline.
-
Agent Cards
Discovery and routing metadata tied to ENS identity.
-
Runtime
The proving surface that executes contracts and can attach execution metadata.
-
- -
- -
Why CommandLayer is structured this way
-

The goal is simple: keep the shared contract and verification layer open, and keep paid execution on top of that same proof model. That makes the public story easier to trust and the business model easier to understand.

- -
-
Business boundary · Commons defines the open contract layer · Commercial extends it for paid execution
-
-
-
Free
-
-
Schemas
-
Identity
-
Discovery
-
Receipt verification
-
-
- -
-
Never taxed
-
-
Meaning
-
Validation
-
Interoperability
-
-
-
-
- -
- -
What makes the trust model credible
-

Monetization is not embedded in standards. It lives at execution time inside runtimes, where routing, guarantees, and operational responsibility already live.

-

Not in the contract: the schema, Agent Cards, ENS identity, or receipt verification. Meaning stays neutral and portable.

-

In execution: routing, metering, guarantees, fulfillment operations, and throughput control.

-

Why this matters: it keeps the story legible — open semantics, inspectable verification, and monetization where operational responsibility actually lives. No semantic fork. No paywalled contracts.

- -

The architecture works because it keeps the contract layer portable while letting execution quality become the competitive surface:

-

You avoid paywalled standards · You avoid "open core" backlash · You align incentives with real value · You monetize where enforcement is natural · Semantics remain neutral — interoperability doesn't get held hostage.

- -
- -
-
Greg Soucy
-
Founder / Architect · CommandLayer
-
The focus is keeping the system honest: strict contracts, visible identity, signed receipts, and verification that does not depend on trusting internal dashboards or vendor-only logs.
-
-
- - - - + +

About moved to Protocol

Protocol now explains what CommandLayer is and how the canonical receipt model works.

Go to Protocol

This legacy page is replaced by the Protocol page.

+ + diff --git a/public/agent-cards.html b/public/agent-cards.html index 69c2277..f95bea8 100644 --- a/public/agent-cards.html +++ b/public/agent-cards.html @@ -3,279 +3,26 @@ -CommandLayer — Agent Cards Registry (v1.1.0, current) - +Agent Cards | CommandLayer + - + + - - - - - - - - - -
- -
▸ docs / agent cards
-

Agent Cards Registry
(v1.1.0, current)

-

Agent Cards answer one question: how are agents identified and discovered? Each card binds an ENS identity to supported verbs, schema versions, and entrypoints so clients can route work to the right agent and know who should have signed the receipt.

- -
- Agent Cards v1.1.0 · current release - Apache-2.0 - descriptors free to use -
- -
- /agent-cards/agents/v1.1.0/<tier>/<ens>.json
- where tier is commons or commercial. -
- -
- -
-

What Agent Cards do in the system

-

Agent Cards do not compete with Commons or Runtime. They provide the identity and discovery layer around the same execute → receipt → verify model: who the agent is, what contracts it speaks, and where to send work.

- -
-
-
Identity
-
ENS name, owner, and contact fields that define who operates the agent. Cards make it explicit which human or organization stands behind a given ENS-based agent.
-
-
-
Capabilities
-
Supported verbs plus pinned Commons or Commercial schema_version values the agent speaks. Keeps capabilities and semantics in sync across ecosystems.
-
-
-
Execution entrypoints
-
One or more execution entrypoints for where to send *.request payloads. Commons cards point at the shared HTTP execute surface; Commercial cards remain x402-style.
-
-
-
- -
- -
-

Commons Agents — v1.1.0

-

These agents implement the CommandLayer Commons verbs. Each link opens the live Agent Card JSON for that ENS name under https://commandlayer.org.

- -

Commons registry

-

Stable, MIT-backed semantics with Apache-2.0 Agent Cards. Each card binds a Commons verb like summarize or analyze to a concrete ENS identity and the shared HTTP execute entrypoint.

- -
- - - - - - - - - - - - - - - - -
VerbENS nameAgent Card JSON
summarizesummarizeagent.ethview JSON ↗
analyzeanalyzeagent.ethview JSON ↗
fetchfetchagent.ethview JSON ↗
classifyclassifyagent.ethview JSON ↗
cleancleanagent.ethview JSON ↗
convertconvertagent.ethview JSON ↗
describedescribeagent.ethview JSON ↗
explainexplainagent.ethview JSON ↗
formatformatagent.ethview JSON ↗
parseparseagent.ethview JSON ↗
-
-
- -
- -
-

Commercial Agents — v1.1.0

-

These agents implement the first Commercial verbs for economic flows: authorization, checkout, purchase, and shipping. Cards align with payment-aware routing and can be indexed by ERC-8004 registries.

Note: VerifyAgent.eth is now a separate public verifier project (MIT) and is not part of Commercial Agent Cards. See github.com/commandlayer/verifyagent ↗.

- -

Commercial registry

-

Reference Agent Cards for the initial 5 Commercial verbs. As more providers come online, additional Agent Cards can be added behind the same verbs and schema contracts.

- -
- - - - - - - - - - -
VerbENS nameAgent Card JSON
authorizeauthorizeagent.ethview JSON ↗
checkoutcheckoutagent.ethview JSON ↗
purchasepurchaseagent.ethview JSON ↗
shipshipagent.ethview JSON ↗
-
- -

How Agent Cards support verification

-

Agent Cards turn ENS names and verbs into discoverable, routable units of capability. A typical flow:

- -
-
-
1
-
Registry or client looks up Agent Cards for a given verb (e.g. summarize) and filters by network, limits, or metadata in the card.
-
-
-
2
-
Selects the card's advertised entry and sends a validated *.request payload. Commons cards currently advertise HTTP execute; Commercial cards advertise x402-style routes.
-
-
-
3
-
Receives a *.receipt shaped by the same Commons or Commercial schemas. Because cards reference canonical schema versions, any runtime that understands CommandLayer can route and verify agents without custom glue code per provider.
-
-
- -

Stability, licensing & governance

-

Agent Cards v1.1.0 are the current release and follow the same stability guarantees as Commons and Commercial: names and schema bindings are stable for this version; breaking changes move to new versions.

-

The Agent-Cards repository is licensed under Apache-2.0. Cards are treated as protocol-grade metadata: anyone can read, cache, and index them. ENS TXT records and IPFS CIDs can mirror card content to make resolution more robust.

-

In the current v1.1.0 Agent Cards cycle, updates follow a clear process: open an issue, propose a new or updated card, run validation, update checksums and manifests, then set ENS TXT fields. This keeps identity, semantics, and routing aligned while the ecosystem grows.

- -
- ⬡ - ENS TXT records and IPFS CIDs can mirror card content to make resolution more robust and independent of any centralized registry. -
-
- -
- - - - + +

Agent Cards moved to Schemas

Agent card schemas and related metadata now live with schema docs.

Go to Schemas

Use the Schemas page for current agent-card structure and protocol-compatible metadata.

+ + diff --git a/public/commons.html b/public/commons.html index c6321fb..4e85775 100644 --- a/public/commons.html +++ b/public/commons.html @@ -139,16 +139,16 @@