fixture modeChain is mocked with three demo agents. Set THESEUS_RPC_URL to read from a Theseus node.

Docs · Overview

Proof of Agenthood.

A signed credential for an AI agent that anyone can verify in seconds.

A Proof of Agenthood credential is a small signed JSON document. It attests to a specific agent: who controls it, what capabilities its on-chain ABG declares, and what verification grade its recent inferences have. The credential is portable. Any service can ask for it, verify the signature against our public key, and check freshness against the revocation list.

Why every PoA agent lives on Theseus

PoA only issues credentials for agents registered on Theseus. This is a load-bearing requirement, not a packaging choice.

An agent that exists only as an API endpoint, an OpenAI assistant ID, or a model behind someone else's router cannot make verifiable claims about itself. The operator can change the system prompt, swap the model, or rotate the keys at any time, with no record. There is no public state to point to. The strongest a credential could say is “at the moment of issuance, the operator told us X.”

Theseus gives PoA the primitives it needs. An agent on Theseus has:

  • An SS58 address that holds seus and emits intents on its own behalf.
  • An ABG (Agent Behavior Graph) stored on chain, with a version number and a content hash. PoA pins both. A credential is bound to a specific ABG version, and verifiers can detect ABG drift.
  • A declared capability surface: models, tools, intent types, sub-agents. Verifiers can gate on what the agent is permitted to do, not what its operator promises.
  • A controller field, or for sovereign agents, no controller at all. The chain is the registry of who can speak for the agent.
  • A public history of inference runs and the verification grade of each (full KZG, mixed, lite-only). PoA carries the recent-run mix into the credential.

Without these primitives, “proof of agenthood” is a brand promise. With them, it is a check anyone can run.

The two attestation kinds

The credential's attestation field tells a verifier what kind of statement is being made.

  • controller-attested. The operator's controller key signed a one-time nonce to authorize issuance. This is the only attestation kind issued against the live chain. It proves that the on-chain controller approved the credential at iat.
  • snapshot. Issued without controller participation, using only public chain reads. Reserved for the future sovereign-agent flow (where there is no controller to ask) and for the demo and fixture environment. Not issued against the live chain.

Lifecycle of a credential

  1. The operator visits /poa/claim with the agent's SS58 address and a browser wallet that holds the controller key.
  2. The server requests a snapshot from the chain reader. If the agent is not registered, issuance stops here.
  3. The operator signs a one-time nonce in the wallet. The nonce is bound to the agent ID and expires in five minutes.
  4. The server issues a JWS containing the snapshot and the attestation, then stores it for revocation tracking. The credential page goes live at /poa/<agentId>.
  5. Verifiers can either visit the page or POST the JWS to /poa/api/verify for a structured report.
  6. Revocation happens either by the controller (signed revoke) or automatically when the chain shows a state change that invalidates the credential: ABG hash changed, controller rotated, agent deregistered, or balance at zero for ninety days.

What this credential is not

  • Not a proof of behavior. It does not say the agent will act well. It says who is on the hook, and what capabilities the chain says it has.
  • Not a live signature on every action. Issuance is one-time; verification is against a snapshot. Freshness is enforced by the revocation list, not by re-signing.
  • Not a generic “verified bot” badge. The credential is meaningful only because the underlying agent is on Theseus.

Where to read next

The reference pages in the sidebar walk through the credential format on the wire, the issuing flow end-to-end, the verification API, and how revocation propagates.

# Quick check that the verify endpoint is alive
curl -X POST https://theseus.network/poa/api/verify \
  -H 'content-type: application/jose' \
  --data '<paste a JWS here>'

For the protocol primitives PoA depends on, see the Theseus docs: Agents on Theseus, Architecture, and Tensor Commits (the verification grade in the credential is grounded in this primitive).

Next →Credential format