Verify Agents and AI

The document itself never has to leave your machine: the SDK commits a salted content hash, and the gateway anchors it in the SigningRegistry on Base. Each signer produces an EIP-712 signature with their own key; a relayer submits it on-chain, so agents hold no gas. The evidence endpoint reads everything back from the chain, not from a database.

• Bare-hash mode keeps confidential content fully private
• Signer slots can name an agent identity, resolved at anchor time
• Signatures bind per slot. Transferring the agent can't un-sign

An agent registers as an ERC-8004-style token held by its own key. Linking it to a human takes two EIP-712 signatures over the same statement (the verified operator's and the agent's), checked by the gateway before a revocable EAS attestation is written on-chain. Verification is a single GET that resolves the agent, reads the attestation, and returns the tier.

• Only a salted hash of the human's identity is ever stored
• Link payloads expire after 15 minutes
• Revocation drops the tier at once. Cached at most 45 seconds

A request without payment gets a 402 carrying exact terms. The buyer signs a single-use USDC transfer authorization (EIP-3009) and retries; the gateway claims the nonce, settles on Base, and the same call returns the caller's verified tier. Your middleware just reads the decision: 200, 401, 402 or 403.

• One signature can never pay twice. The nonce is claimed first
• Identity is checked before any money is spent
• Paid checks are never cached, so revocation is never hidden

One wrapper around your agent's HTTP client. When a seller answers 402, the demand is evaluated against your org's policy (per-call, daily and monthly caps, endpoint lists) before any payment is signed. Above the threshold, a human approves or the answer is no. Every decision emits a receipt to the control plane.

• Fails closed: no policy loaded, no payment made
• Payment is attached in exactly one code path, after an allow
• Receipts carry the full check trail, delivered at-least-once

You start a ceremony and receive a one-time payment reference. You make a real card transaction carrying it. A one-cent charge is enough. Settlement confirms the claimed operator acted, and Piggyback writes a revocable attestation binding that action to your key, which KYA accepts as human verification.

• The proof uses a payment network that already knows who you are
• One cent, one reference, one attestation
• Revocable like every other credential here

The agent signs its statement with its own key. The gateway resolves the speaker through KYA and commits the statement hash. By default only the hash goes public. The words are published when the operator chooses. The tag resolves all of it back: agent, tier, human, wording, standing.

• Hash-only by default; publishing the text is opt-in
• High-stakes classes can require the operator to co-sign
• The record is append-only, so the history stays honest

Each terminal holds its own key and is registered to an operator, the way an agent is. A tap mints a single-use presence token over that terminal and that moment. The token resolves to the place's record, and the agent arrives already briefed on where it is and what can be done there. Then identity, payment, and signature as usual.

• A nonce per tap, so a proof can't be replayed from elsewhere
• Floor-accurate by construction: the terminal is the place
• The tap proves the device; pair it with a tier when you need the person

Registry writes nothing. It is a read model over KYA and Attest: the same chain state a verifier could assemble alone, made browsable. Each entry carries the agent, its tier, its accreditations and their expiry, the attestation behind them, and the feed of what the agent has said and still stands by.

• Public and cacheable. No API key, no account
• Listing is opt-in, because a directory of credentials is also a target list
• The accreditation is public. The person behind it is named only if they choose

One controlled vocabulary of qualities (warm, matte, coarse, austere), grouped into axes. Every record is drawn from it and nowhere else. That is what turns three collections into a graph: raw concrete and petrichor share five qualities, so an agent can reach one from the other without either record naming the other.

• Two values on one axis conflict, so a clash is detectable
• Records can be marked contested, and the disagreement is the content
• Files in git, reviewable and diffable. Any graph store is a projection

A keyboard on iOS is an extension that cannot see the screen. It gets the text around your cursor and nothing more. So the context lives beside it: a companion app holding your documents, snippets, credentials, and the log of everything sent. The keyboard stays thin and holds no keys.

• The companion app is a prerequisite, not a follow-on
• You see the payload before it goes, and the log afterwards
• The concept is written around what the platform actually permits