Architecture

Four layers. Two rails.
No layer trusts the one above it.

Read top-down for how an application uses the substrate. Read bottom-up for why a counterparty can trust what it did without trusting the platform that hosted the request.

01The shape

Application on harness. Harness on authority. Authority on identity. Identity on chain.

Application → Harness → Authority → Identity → Chain, with Edge admission and Evidence alongside every layer. The ontology binds the vocabulary across all of it; the registry kit is how the estate is found.

02Identity

Every agent is a Person, an Organization or a Service — and every one is an account.

W3C PROV-O's trichotomy, made operational. A treasury, an indexer, a coach and a marketplace are Service roles, never new classes. The human controls a Person Smart Agent with a passkey; from there authority flows between agents, not between wallets.

The canonical example. Alice's passkey controls alice.me; alice.me stewards missio-nexus.org; the organization charters missio.treasury and mints a session wire for catalog.svc; the treasury grants Bob a bounded permission. Every arrow is a signed, caveated, revocable delegation — and the sentence at the bottom is what the audit trail can say afterwards.

Canonical identity persists; credentials rotate.

Passkeys, hardware keys and SIWE wallets are control credentials — replaceable under custody policy (guardian quorum, trustee quorum, multi-credential self-recovery). The agent’s address never changes; every delegation it issued stays valid.

Typed names say what an agent is.

.me .org .team .svc .workspace .treasury .registry — a suffix names the derived agent type, checked against the on-chain record and failing closed on a mismatch. A person’s org is never the person’s own address.

Projections, not copies.

An A2A Agent Card, an ARD record, an ERC-8004 entry, a DNS host, a DID document — each is a signed projection of the one profile. Delete a projection and you have lost a listing, not an identity.

03Authority

A grant is a signed delegation with caveats. A mandate is a grant bound to one intent.

Permission is not a role, a scope or a row. It is an ERC-7710 delegation whose caveats are enforcer contracts that run at redemption: time window, allowed target, allowed method, value ceiling, payee, and — for a mandate — the digest of the exact intent.

Anatomy of the buy-in mandate a Game Night player signs. The house may move at most 2,000 SHQ from her treasury to itself, only through the token's transfer method, only for 30 days, only for this exact intent. Revocation is one transaction from her Home.

No silent fallbacks, no cached verdicts. A read or auth path has exactly one mechanism; if the canonical path has no answer it returns empty or throws — it does not escalate to a weaker check. Revocation is final at the next gate, everywhere.

04Harness

Planner proposes. Mandate authorizes. Executor acts. Receipt proves.

The authority-aware agent loop is the difference between “human in the loop” as a click and as a signature. Each step names a tool with a declared risk. For risk at or above high, the person's confirmation is the mandate signature — and the verifier and the chain's enforcers both check it outside the planner's process.

One turn. The planner resolves 'Nathan' in the asker's PRIVATE tier (or refuses — a public directory hit is not evidence she knows that Nathan). The payment step parks; her confirmation mints the mandate; the verifier checks it is live, unrevoked, for this delegate, this selector, this digest; the executor redeems; the enforcers re-check on chain; the receipt lands in her vault.

Behaviour is generated; authority never is.

A playbook (an Agent Skill package, compiled by digest) tells the agent how to behave. It is consulted by no verifier. What an agent MAY do is the grant; what it TENDS to do is the playbook.

Durable, streamed, parallel, triggered, billed.

Runs resume by replaying evidence and re-verifying the acting step. Progress streams as numbered lines. Read-only steps run concurrently; authority-bearing steps run alone. Schedules and messages trigger runs with budgets; every run has a bill.

Two tiers of knowledge, never joined in an engine.

The public knowledge base holds only facts anyone could reproduce from chain state — world-readable by construction. Private records live in per-agent vaults, queried by selectors under per-record delegation. A generated query is never the reason something is disclosed.

Coordination is not orchestration.

Work between agents (endeavors, shared plans, signed commitments, participants found by capability) is a different plane from work within one agent (a run’s execution plan). They never import each other; the runtime composes both; neither is authority.

05Evidence

Receipts the owner carries.

Every protected step leaves a verification receipt bound to the intent, the mandate, the step and the playbook digest, into a hash-chained log and a W3C PROV-O graph with a W3C Trace Context spine. It is held in the owner's vault. A trace id is correlation, never trust; provenance is evidence, never an authorization input.

Who is acting?

Identity that survives the runtime

Every person, organization and service in your application is a Smart Agent — an on-chain account that can verify signatures, hold value and execute logic. Names, cards, registry entries and DID documents are projections of it, never the identity itself. Passkeys and keys rotate; the agent does not.

ERC-4337 account · ERC-1271 signatures · typed names (.me .org .svc .treasury .workspace)

May they do this?

Authority that is a grant, not a token

Permission to act is a delegation the principal signs, narrowed by caveats — a payee, a ceiling, one intent, a time window — and revocable in one transaction. It is verified before every step, again after every approval, and again on chain when value moves. No cached verdict ever authorizes an act after the authority behind it is gone.

ERC-7710 delegations · caveat enforcers · intent-digest mandates · on-chain revocation

What did they do?

Evidence the owner carries

Every protected step leaves a receipt — which grant, which decision, which transaction, which playbook — into a hash-chained log and a W3C PROV-O graph held in the owner's vault, not in a vendor's trace store. A receipt travels because the owner carries it, and a counterparty can check it without the runtime's cooperation.

PROV-O provenance · OpenTelemetry spans · hash-chained receipts · vault-resident records

06Edge

HTTPS required. mTLS optional. Admission always.

The normative external profile is A2A over HTTPS. A certificate is transport evidence, never authority; a SPIFFE ID names a workload, never an agent. MCP is a private capability interface behind admitted runtimes. The ordering that must never invert: certificate → transport evidence → optional workload binding → application authentication → canonical resolution → Admission.

On the A2A→MCP hop, the chain is the authority and MCP OAuth is only the ingress envelope. A bearer carries at most a principal and a reference to an encrypted grant bundle — never delegation or field-level authority. Field access is never encoded in scopes. The Web3 gates are never skipped because “OAuth already authenticated the caller”.

See the whole thing in one application.

Game Night exercises identity, mandates, the harness, A2A admission, a kit-built registry and receipts — in a card room you can play.

The Game Night case study Read the specs

Four layers. Two rails.No layer trusts the one above it.