Quickstart

The fastest path from zero to a working integration. Pick the role you're building — each path is condensed here and links into its full role guide.

Pick your role

Choose what you're building. The fastest path differs by role — these aren't four equal-weight quickstarts.

Whitepaper

The AEA/P Whitepaper presents the architecture, governance lifecycle, and component interactions of AEA/P. Intended for decision-makers, standards bodies, and technical leaders evaluating the protocol's design and applicability. It is informative; the Protocol Specification is normative and governs where the two differ.

What the Whitepaper covers

For each of the five protocol components, the Whitepaper presents the governance lifecycle and state transitions — the what and why, without the implementation detail of the Protocol Specification.

• Agent types: PERSONAL and BUSINESS, with authorized actions deciding what a business agent does, and the buyer agent and seller agent on the two sides of each transaction
• Conformance levels 1–3 and the personal-to-business upgrade
• Agent Identity lifecycle (AID states: DRAFT → ACTIVE → REVOKED)
• PoP rating lifecycle (Provisional → Rated → Decayed)
• Liability Escrow lifecycle (FUNDING → ACTIVE → DISPUTE_HOLD → CONSTRAINED → RELEASED)
• Dispute lifecycle (initiation through enforcement)
• Entity Governance lifecycle (creation through termination)
• Operational scenarios with sequence diagrams, and the security threat model

Download

Relationship to the Protocol Specification

The Whitepaper and the Protocol Specification cover the same protocol. The Whitepaper is the public-facing summary — every section ends where detailed implementation guidance begins. The Protocol Specification continues from those cut-off points with schemas, algorithms, formulas, and integration patterns.

The two documents are derived from the same source and carry the same version number. Versions before v0.3 were published as the Protocol Framework.

Protocol Specification

The Protocol Specification is the normative, complete implementation guide for AEA/P. It provides detailed data schemas, field-level definitions, calculation algorithms, and integration patterns required to build a conformant implementation.

What the Specification adds

Beyond the Whitepaper, the Specification provides:

• §5 Agent Identity: Full AID schema, PrincipalRef structure, delegation chain rules, counterparty verification flows, verification attestation format
• §6 Proof of Performance: Seller and buyer signal tables with weights, the value-weighted AR blend with time decay, performance record structure, manipulation resistance mechanisms
• §7 Liability Escrow: Escrow account structure, threshold calculation (dispute window, coverage period, AR modifier), funding mechanism, refunds
• §8 Dispute Resolution: Dispute initiation fields, triage rules, dispute pool listing, bounty economics, arbitration board formation, voting protocol, escalation, enforcement
• §9 Entity Governance: Governance document structure, ownership registry, token types, ownership transfer, voting and decision-making, privilege management
• §10 Operational Scenarios: Registration requirements by agent type, and sequence diagrams for registration, an agent-to-agent transaction, dispute resolution, and a voluntary refund

Download

Conformance & Certification

AEA/P defines three conformance levels by agent type and authorized actions. AEA/P Certified attests that an implementation meets the protocol's MUST requirements for the level, agent type, and actions it claims.

Conformance levels

A personal agent always buys only; a business agent falls in the column matching its authorized_actions, and entity governance applies at Level 3 to any business agent under a governance document. A claim of conformance states the level, the agent type, and the authorized actions.

Per-participant requirements

Each role has a defined set of MUST / SHOULD / MAY requirements — the endpoints it must implement, the checks it must perform, and the invariants it must uphold. The role guides summarize these; the normative checklist is enumerated here.

AEA/P Certified

An implementation that meets the MUST requirements for its role and level may be listed as AEA/P Certified. Certification is per role and per level — a conformant Operator, Platform, or Agent each certifies against its own requirement set.

Conformant products and integrations place the AEA/P Certified mark on their own surfaces to attest implementation of the five pillars. Certification is a property of the protocol, so the badge carries the AEA/P mark — not a product mark — and the green check is the only third color, carrying the same "verified" semantic a padlock does in a browser bar.

Trust Registry inclusion

To issue certificates or attestations that other participants will trust, an Operator or Verifier must be listed in the Trust Registry. Inclusion is the operational outcome of certification: an operator certifies as a conformant issuer at the relevant level and is then listed, so its iss resolves for counterparties. Listing and delisting are governed — a delisted issuer's certificates stop being trusted at the next verification, which lets the protocol withdraw trust without coordinating every relying party.

Changelog

Version history for the AEA/P Protocol Specification and Whitepaper (published before v0.3 as the Protocol Framework).

API Reference

The API Reference documents the Operator API — the server surface a conformant Operator exposes. Platforms and agents are clients of it. Rather than a static contract, the surface is demonstrated live by running Operator implementations you can explore directly.

The Operator surface

Every endpoint belongs to the Operator. The surface splits into two groups by who calls it.

Request and response bodies, the AEAP-* authentication headers (§5.6.4), status-resolution fields (§5.6.5), and the rejection-code set (§5.6.6) are exercised live in the implementations below.

Explore a live Operator

Choose an Operator to browse its live API. Each implements the same protocol surface, so the contracts are interchangeable — and because the explorer is the running system, it never drifts from what is deployed.

This is a directory: as more Operators are certified, each appears here with a link to its own live API explorer.

Integration by participant

AEA/P is implemented primarily by Agentic Platforms and Operators — the infrastructure that gives agents identity, settlement, and accountability. If you are building an agent, you integrate through a platform, not the protocol directly. This section is a focused guide for each participant — what you implement, your path through the flow, and the endpoints you touch.

The participant model

A governed transaction involves five participants: two agents transacting, and three that provide trust, hosting, and settlement around them. The boundary that keeps the system non-custodial and portable is simple — the Platform mediates the control plane (discovery, policy, routing) but never touches funds or the service payload; the Operator verifies and records but never submits a transaction; funds move directly through the Settlement Contract.

Pick your guide

End-to-end transaction

How the participants interlock in a single governed transaction between a buyer agent and a seller agent — six phases from identity verification through settlement, service delivery, and PoP confirmation. The mechanics shown are one concrete realization of the protocol. Below, “Buyer” and “Seller” are short for the buyer agent and the seller agent.

Transaction phases

The six phases in sequence:

Phase 0 — Onboarding

The buyer agent and the seller agent each onboard once through a single front door at their Platform. The platform registers the principal and verifies its email — issuing its platform API key — and runs KYC/KYB through a Verifier, which issues a Verification Attestation. Only once verified does the platform register the agent with the Operator, which issues the agent's certificate. For a Seller, this one-time setup also provisions a segregated escrow wallet and registers the Seller on the Settlement Contract; the Operator controls the escrow wallet, so the Seller cannot modify its own funding_rate.

Protocol requirements

• The market being registered must already appear in the agent's authorized_markets AID field — a compliance declaration that the agent is permitted to operate in that jurisdiction and currency
• The escrow wallet is provisioned by the Operator under its control. The Seller cannot withdraw from or modify escrow parameters directly
• The funding_rate is set from an Operator-controlled configuration. Seller cannot override it
• On-chain registration stores the three-way split configuration: operational wallet, escrow wallet, escrowBps, feeBps
• After registration, the agent's escrow_state begins as FUNDING — it transitions to ACTIVE once the escrow balance reaches the computed effective threshold

Escrow state machine

Phase 1 — Discovery & mutual authentication

The Buyer discovers a Seller through its platform, then verifies it directly. Before committing to a payment, the Buyer confirms the Seller holds a valid AEA/P identity and sufficient escrow coverage. Critically, certificate verification is offline — the Buyer never needs a round-trip to the Operator to verify the Seller's identity or the challenge response. The Operator is called only once, to check live operational status — ACTIVE, escrow_state, and rating.

Protocol requirements

• Challenge nonce TTL: 120 seconds — the Seller must respond within 2 minutes of the Buyer requesting the nonce
• Certificate verification is offline: The Seller's AEA/P Certificate is a JWT signed by the AEA/P Certificate Authority. The Buyer verifies the JWT signature against the published CA public key — no Operator call needed
• Challenge response is an EC signature over the nonce. Buyer verifies offline using the public key extracted from the certificate
• Timestamp check: within 30 seconds — the AEAP-Timestamp in the Seller's response must be within 30 seconds of the Buyer's local time, preventing delayed-replay attacks
• Buyer checks escrow_state and agent_rating from the status endpoint before proceeding. A Buyer may refuse to transact with a Seller in FUNDING or CONSTRAINED state

Key AID fields checked during authentication

Phase 2 — Payment negotiation

When a resource requires payment, the Seller issues an HTTP 402 Payment Required response, routed back through the platform. The protocol specifies exactly what the 402 may and may not disclose. The Operator creates a payment intent when the Seller requests payment details — tracking whether the Buyer follows through, which feeds the Buyer's payment_timeliness signal. The Operator always enforces the Buyer's spend scope — the limits in its AID — at intent creation, before any funds move. A Platform may additionally apply its own rules at egress and block the 402.

Protocol requirements

• The 402 response must include: Settlement Contract address, token contract address, amount, Seller DID hash, expiry timestamp
• The 402 response must not include: wallet addresses, split ratios, fee percentages, or internal configuration details
• Payment intents are created automatically by the Operator when the Seller requests a payment address — the Seller does not create intents manually
• The authorized_markets field in the Seller's AID is validated at intent creation. The buyer's market derives as {principal.country}-{currency}; the seller MUST match it directly or via GLOBAL-{currency}, otherwise the intent is refused with market_not_authorized
• Payment intents expire after a configured window (default 5 minutes). Intents that expire without being paid transition to ABANDONED

Payment intent lifecycle

Phase 3 — Settlement

The Buyer pays the Settlement Contract directly on-chain. The contract performs an atomic three-way split in a single transaction — all three transfers succeed or all revert. This is a core protocol guarantee: the Operator never intermediates fund transfers. It only reads settlement records after the fact.

Protocol requirements

• Non-custodial: Implementations must not hold funds in transit. The contract routes directly from the Buyer to three destinations atomically
• Split control: The split configuration (escrowBps, feeBps) is stored on-chain in the Settlement Contract. Only the protocol authority can modify these values — the Seller cannot lower its own escrow funding rate
• Rounding: Maximum rounding loss is 2 wei per settlement (two integer divisions). Rounding error always favors the escrow and fee recipients
• The Buyer must have approved the token spend before calling pay() if the current allowance is insufficient

Split formula

Phase 4 — Verification & delivery

With payment settled, the Buyer makes the service request — presenting its certificate, a bound proof, and the settlement payment_tx. The Seller makes a single facilitate call to the Operator that verifies the buyer and confirms the on-chain settlement in one step, crediting escrow and opening the performance task. Only once that call succeeds does the Seller deliver. Settlement verification gates delivery; it never follows it. Delivery is direct, Seller to Buyer — the platform is not in the service path.

Protocol requirements

• One call, both checks: facilitate verifies the buyer's bound proof and confirms settlement together. No separate verify step is required ahead of it — the settlement path carries the verification
• Bound proof: The Buyer includes an EC signature over (timestamp | buyer_did | seller_did), cryptographically linking the service call to this specific Buyer–Seller pair and preventing replay of the payment proof for a different call
• Read-only on-chain confirmation: The Operator reads the on-chain Settled event — it never submits a transaction. It checks the settlement contract address, the DID hashes, and that amounts match the registered split. This is how escrow stays non-custodial: the Operator observes what happened on-chain rather than intermediating it
• Sybil check: If the Buyer and Seller share a principal, the service executes and escrow is credited, but no performance task is created and no rating credit accrues — preventing self-dealing
• Environment enforcement: The Operator checks that both agents' environment fields match — a sandbox agent cannot complete a verified transaction against a production agent
• Escrow balance is aggregated per currency across all networks — a Seller on Base and Arbitrum carries one USD escrow balance
• The payment intent is marked SETTLED by matching buyer_did + seller_did + amount against open intents; a performance task is created at facilitation time, opening the 72-hour window
• The Seller may independently check the Buyer's rating and enforce a minimum_counterparty_cert_tier, rejecting the request without affecting either party's rating

What the Buyer sends

What facilitation verifies

Phase 5 — Performance confirmation

Within 72 hours of facilitation, the Buyer confirms whether the service was delivered. The Operator computes PoP signals for both agents from objective transaction data — not from the confirmation score alone — and updates each agent's Agent Rating (AR). Updated AR triggers a recalculation of the escrow effective threshold: high-performing agents carry lower reserve requirements.

Seller signals

Buyer signals

Agent Rating formula

Where rᵢ is the task rating and tᵢ is the age of the interaction in days. The decay constant 0.005 gives a half-life of approximately 139 days — interactions older than ~1.3 years carry less than half their original weight. An agent that both buys and sells has one AR that blends its seller and buyer components weighted by transaction value, net of refunds (see Proof of Performance).

Prior initialization

At registration agent_rating is initialized to 0.75 — equal to the default minimum_counterparty_ar floor — rather than left empty, and converges toward observed performance as a weighted blend:

C is implementation-defined (RECOMMENDED 5) and n is the number of confirmed tasks, so the prior’s influence is substantially decayed by the time an agent reaches Rated. The rating is never null after registration: a brand-new agent presents a defensible starting value that a counterparty can compare against its own floor, and one that improves or degrades on evidence.

Auto-confirm rule

If the Buyer does not respond within 72 hours, the task auto-confirms with task_completion = 1.0. The Buyer's task_confirmation signal scores 0.0 for that task. This prevents rating suppression through deliberate non-response — a Seller cannot be penalized simply because the Buyer went silent.

Integration concepts

The primitives every participant shares — identity, authentication, headers, environments, and the error model. Read this once; the role guides assume it.

Identity & certificates

Every agent holds a certificate — an ES256 JWT issued by an Operator that binds the agent's public key to its stable-identity claims (agent type, capabilities, principal, issuer). Identity is the subject of Agent Identity; full claim schemas are normative and live in the API Reference.

The Trust Registry

The Trust Registry is the set of issuers — Operators and Verifiers — recognized to issue certificates and attestations. It is what makes AEA/P federated rather than a single walled garden: when a participant verifies a counterparty, it resolves the certificate's issuer (iss) against the registry and trusts the certificate only if the issuer is listed. The registry is the protocol's root of trust — an unrecognized issuer fails verification regardless of an otherwise-valid certificate. Operating as an issuer, and getting listed, is covered in Conformance & Certification.

Two authentication models

Runtime economic actions authenticate as the acting agent — its certificate and a bound proof — never the platform key. A platform's management credential covers onboarding and configuration only.

The challenge handshake

Before an agent-to-agent or agent-to-Operator runtime call, the caller proves key control: obtain a short-lived nonce from the Operator (GET /v1/verify/challenge), then present a proof — a signature over timestamp | caller_did | callee_did, bound to the callee and valid only within the replay window. The seller half of mutual auth answers a challenge with a signed challenge-response.

Wire headers

Environments

Certificates and status are environment-scoped — sandbox for integration, production for live traffic. A counterparty in the wrong environment fails verification.

Errors & status

Agents carry a mutable status (ACTIVE, SUSPENDED, REVOKED) resolved separately from the certificate. Verification and settlement failures return distinct, enumerated reasons. The canonical error model and status lifecycles live in the API Reference.

Builder

If you are building an agent — a personal agent that buys for an individual, or a business agent that sells, buys, or both for a registered business — you integrate through a Platform, not against the protocol directly. The platform onboards you and registers your identity with an Operator; the Operator governs identity, spend policy, settlement, escrow, and performance. This page is what your agent does within a transaction; the infrastructure is the platform's and the Operator's.

Buyer agents

A buyer agent — a personal agent, or a business agent carrying purchase — discovers seller agents, authenticates them, and pays under a spend scope its principal declares and the Operator enforces at payment-intent creation; your Platform may apply its own rules as well.

• Register through your platform with your principal and declared scope (authorized_actions, max_tx, spending_limit); receive a certificate.
• Carry your AEAP-Certificate and a fresh AEAP-Proof on outbound calls.
• Before paying, authenticate the seller — obtain a challenge nonce, run the offline certificate checks, then a status check.
• Pay the registered settlement contract directly; present the payment_tx as your receipt; confirm the task within 72h.

Agents that sell

A seller agent — a business agent carrying sell — sells services, holds liability escrow, and declares authorized_markets. A non-merchant seller has no merchant account and is paid by settling a stablecoin on-chain. Your defining obligation: confirm — through the Operator, not the caller's word — that you were paid, before you deliver. You may refund a sale to its original buyer from your operational balance at any time, except while a dispute on it is open — then you settle within the dispute, during pre-arbitration only, paid from escrow.

• Register through your platform and declare your markets (network, currency, method) and an operational wallet; the Operator provisions your escrow and settlement config.
• Publish your capabilities; answer a buyer's challenge with your certificate and a signed challenge-response.
• Price a request: return 402 Payment Required with terms drawn from the Operator.
• On the service call, make a single facilitate call — the Operator verifies the caller and the on-chain settlement together and credits escrow — then deliver directly. Never deliver on a claimed payment_tx alone.

Platform integration

An Agentic Platform is the agent's onboarding front door and runtime host. It discovers and routes between agents and may enforce its own policies on top of the spend scope the Operator always enforces — but it is a control-plane mediator, never a data-plane proxy. Funds settle directly to the contract; the service is delivered directly between agents.

What you implement

• Single onboarding front door. Accept one submission per agent; register the principal and verify its email — issuing its platform API key — and run (or arrange) KYC / KYB via a Verifier; only then register the agent with the Operator. Preserve distributed anchoring — the certificate is Operator-signed, the attestation Verifier-signed; your registry is an operational cache, not the root of trust.
• Registry + discovery. Index agents by network and currency; verify counterparty certificates against the Trust Registry; expose matching by capability and market.
• Payment-negotiation brokering. Mediate GET /resource → 402 and route by the seller's declared method.
• Egress policy enforcement. Mediate discovery and negotiation and pass the Seller's 402 to the Buyer. The Operator always enforces the buyer's spend scope from its AID at payment-intent creation; you MAY also enforce your own rules at egress — for example tighter limits or blocked categories — and block the 402 when one fails. Declare those rules as policy_ids in a policy.posture attestation (§5.7) so counterparties can see them. Never expose wallet, split, or fee.
• Stay out of the money and service paths; pull observability from the Operator rather than receiving it in-flow.

Your path through the flow

Endpoints you call

Operator integration

An Operator is the accountable system of record — the trust and settlement backbone of a transaction. It issues agent identity, confirms settlement on-chain, holds escrow, and runs proof of performance and disputes, operationally owning four of the five pillars. KYC is delegated to a Verifier.

What you implement

• Identity (Pillar 1). Operate the CA: validate the Verifier's attestation and issue agent certificates (ES256 JWT); maintain the Trust Registry of accepted issuers; serve status and challenge nonces; support revocation and publish JWKS.
• Settlement. Provision per-seller config on-chain (registerSeller); issue payment addresses + intents; on facilitate, verify caller identity and read-only confirm the on-chain Settled event, then credit escrow and open the performance task. Never submit a transaction.
• Escrow (Pillar 3) + PoP (Pillar 2). Hold escrow under HSM / KMS; run the escrow_state lifecycle; compute bilateral, time-decayed ratings; apply Sybil suppression; record seller refunds against the original intent (refunded_value) without touching dispute_free.
• Disputes (Pillar 4) and transaction monitoring — transaction-time sanctions / AML; adverse outcomes drive SUSPENDED.
• Expose a reporting endpoint so platforms and principals pull receipts and ratings out of band.

Endpoints you expose

Verifier integration

A Verifier performs point-in-time identity diligence at onboarding and issues a signed Verification Attestation the Operator relies on to issue a certificate. Verifiers are often operated by the Platform. Ongoing, transaction-time AML is the Operator's responsibility — the Verifier does onboarding diligence only.

What you implement

• Run onboarding diligence tiered by agent type: Tier 1 KYC and sanctions screening for a personal agent's principal (a natural person; payment-instrument verification may suffice); Tier 2 KYB, beneficial ownership and screening for a business agent's principal (a company, or an individual with a business license); Tier 3 enhanced diligence — PEP, source of funds, ongoing AML — for each principal of a multi-principal business agent.
• Issue a signed Verification Attestation — the tier reached, the checks performed, and your signature.
• Hand the attestation to the registering party (the Platform), which relays it to the Operator. You do not issue certificates and you do not see the transaction stream.

Your path through the flow

Agent Identity

AEA/P identity is economic identity — not just authentication. An Agent Identity Document (AID) declares whom an agent acts for, what it is authorized to do, who is accountable for its actions, and what liability escrow it holds. Every agent traces to a verified principal, and the AID is a single signed document organized into the five protocol pillars.

The five-pillar AID

The AID is one signed document organized into five pillar objects — one per protocol pillar — plus root-level fields (aid_url, aid_version, created_at, signature). Which pillars an agent populates depends on its agent type and authorized actions; pillars that do not apply are structurally present but null. The root signature signs across all five.

{
  "aid_url": "...",
  "aid_version": 1,
  "created_at": "...", "updated_at": "...",
  "visibility": { ... },
  "metadata": { ... },

  "identity": {
    "agent_id": "...",
    "agent_type": "BUSINESS",
    "public_key": "...",
    "principal": { ... },
    "entity_id": "...",
    "profile": {
      "display_name": "...",
      "description": "...",
      "objective": "...",
      "catalog_url": "https://.../catalog.jsonld"
    },
    "endpoint_url": "...",
    "certificate": { "cert_tier": "...", "verification_attestation": { ... } },
    "scope": {
      "version": 1,
      "authorized_markets": [...],
      "authorized_actions": [...],
      "capabilities": [...],
      "max_transaction_value": ...,
      "spending_limit": { ... },
      "minimum_counterparty_cert_tier": "...",
      "minimum_counterparty_ar": ...
    },
    "delegation": { "chain": [ ... ] },
    "attestations": []
  },

  "performance": { "agent_rating": 0.75, "performance_record": null },
  "escrow":      { "liability_profile": null },
  "disputes":    { },
  "governance":  null,
  "signature": "..."
}

Profile and catalog

identity.profile is the unit of descriptive mutation: display_name, description, objective, and — for BUSINESS agents carrying sell — catalog_url. The catalog reference MUST resolve over HTTPS to a schema.org OfferCatalog served as application/ld+json, each Offer declaring itemOffered (a Product or Service), price and priceCurrency. It is serialized null for agents that do not sell.

Catalog semantics. Only the URL is inside the AID signature boundary. The catalog document itself is mutable, unsigned and advisory under the same firewall as the rest of the profile: it is never an input to a protocol gate, and catalog prices do not bind — binding terms are exclusively those of the commitment. Catalog retrieval, parsing, indexing and discovery are platform-layer services; the Operator’s obligation ends at serving the reference in the AID. catalog_url inherits profile mutability — freely mutable at identity level, re-signing the AID.

A personal agent, and a business agent that only buys, populate identity and performance; a business agent that sells adds escrow and disputes, plus governance when it operates under a governance document.

AID lifecycle

Every agent has an AID that progresses through defined states. Counterparties resolve any DID to check current status before transacting. The typical path is DRAFT → ACTIVE → REVOKED.

Principal verification

Every agent begins with principal verification — identity checks (KYC for individuals, KYB for organizations) plus sanctions and restricted-party screening — performed by an independent Verifier before the AID can become ACTIVE. The result is a Verification Attestation, which the AID references. It is time-bound (validity SHOULD NOT exceed 12 months); on expiry or revocation the AID is suspended.

The depth of verification is captured in the attestation's verification_tier, coupled to the agent's type and governance:

The coupling is normative: a Verifier MUST NOT attest below the tier an agent type requires, and an AID MUST NOT become ACTIVE if the referenced attestation's tier is below its type's requirement. A personal agent upgrades to a business agent in place once its principal holds a Tier 2 attestation, keeping its identity, AR history and dispute record; a company always deploys business agents.

Identity pillar fields

Scope and mutability

An agent's authority lives in its scope. Every dimension is enforced both down the delegation chain and over the life of the AID. Two identity members — profile and endpoint_url — are freely mutable and re-sign the AID without touching the scope counter. Every other change is a scope change: it re-signs the AID and increments scope.version — a monotonic counter counterparties read to detect changes between commitments.

agent_type is part of identity, not scope; it changes only from PERSONAL to BUSINESS, in place. Three fields answer three separate questions: agent_type — whom the agent acts for; authorized_actions — what it may do; and side — whether it is the buyer agent or the seller agent in a given transaction, recorded on each interaction rather than in the AID. A personal agent is always the buyer agent; a business agent may be either, transaction by transaction.

Field visibility

The headline Agent Rating and escrow state MUST always remain public; other fields default to public but the principal MAY restrict them.

Delegation chains

A delegation chain traces authority from the principal through any intermediate agents to the acting agent — how principals stay in control of autonomous agents.

• Chain invariant. Each link's scope is a subset of its parent's — sets narrow, ceilings only lower, floors only rise. Authority cannot be amplified by delegating.
• Delegation authorization. A delegator must itself hold delegate in its authorized_actions; a link from an agent that lacks it is invalid.
• Top-of-chain accountability. The root of the chain — the principal, or the topmost agent — is accountable for liability, escrow funding, PoP contribution, and disputes. Intermediate links are relays and do not take on accountability by re-delegating.
• Cascading narrowing. When a parent narrows a dimension, sub-agents auto-constrain at their next scope.version. Widening does not cascade.
• Revocation. Revoking any link invalidates every link below it.

Identity on the wire

An agent's economic identity is portable across the ecosystem. The AID is the full, resolvable record, but across an implementation boundary an agent presents a compact certificate — a signed JWT asserting its DID, agent type, scope, and principal. Because the certificate format and key discovery are fixed by the protocol, any conformant counterparty can verify a certificate issued by any Operator — even one it has never contacted — and an agent acting through one Platform is recognizable to agents on another. Which Operator certified an agent and which Platform hosts it are branding, not barriers to interoperability.

Before committing, two agents mutually authenticate — a challenge-response proving each controls the key bound to its certificate — then each resolves the other's live status (lifecycle state, environment, current rating and escrow) rather than trusting the certificate's snapshot. The wire headers, the challenge handshake, key discovery, and rejection codes are in Integration concepts.

Proof of Performance

PoP is AEA/P's automated performance rating. Ratings derive from verifiable transaction outcomes — task completion, payment history, dispute results — not subjective reviews, and records are created automatically at settlement, so principals cannot submit or suppress them. PoP produces one rating per agent regardless of type or side; only the signals that feed it differ.

Rating lifecycle

An agent's rating evolves as it transacts. The transition between Rated and Decayed is continuous — an agent that resumes activity rebuilds its rating through new interactions that carry full weight.

Task rating

Each completed interaction produces a task rating between 0.0 and 1.0 — a weighted sum of objective signals whose weights sum to 1.0 (and MAY be adjusted in an entity's governance document). Which signal set applies depends on the agent's side in that specific interaction — seller agent or buyer agent (side: SELLER | BUYER). Interactions between two agents under the same principal execute and credit escrow, but produce no task record.

Seller signals

Applied when an agent is the seller agent — a business agent carrying sell.

Buyer signals

Applied when an agent is the buyer agent — a personal agent, or a business agent carrying purchase.

One AR, blended by value

A business agent that buys and sells generates seller signals when selling and buyer signals when buying — but it has one AR, not two. The AR is a blend weighted by transaction value that tracks its actual mix:

Each weight is that side's share of total transaction value, net of refunds; each component is the time-decayed mean of task ratings from that side. Weighting by value keeps many small purchases from diluting the rating of the sales a counterparty relies on. An agent active on one side only — every personal agent — has that side's component as its AR, and the 0.75 prior applies per side. The blend shifts automatically as the business mix evolves — an agent that mostly sells has an AR that mostly reflects service quality, one that mostly buys reflects purchasing reliability — and counterparties still check one number.

Agent Rating (AR)

The AR is the agent's single PoP score: the weighted mean of its task ratings with exponential time decay, so recent performance counts more than old.

• rᵢ — task rating for interaction i (weighted sum of the side's signals)
• tᵢ — age of interaction i in days. Decay constant λ = 0.005 → half-life ≈ 139 days; λ MAY be configured in governance
• AR ranges 0.0–1.0. A higher AR lowers the agent's escrow effective threshold — see Pillar 03 (Liability Escrow)

Performance record

The AR is the summary; the evidence behind it is the performance record — an append-only, publicly readable log with one entry per interaction: the signal scores, the computed task rating, how completion was confirmed, and any dispute and its outcome. Entries cannot be modified or deleted, which is what makes the rating verifiable rather than curated.

Because it is queryable, a counterparty can break the AR down — for example, inspect a business agent's buyer signals to judge payment reliability specifically, or pull its dispute history and transaction mix.

Aggregation

Agent ratings roll up. A Team Rating (TR) is the mean of its members' ARs; an Entity Rating (ER) is the mean of team ratings (or of member ARs for a flat entity). Both are publicly queryable, so a strong agent in a weakly-rated team reads differently from one in a high-performing organization.

Manipulation resistance

Liability Escrow

Liability Escrow makes agent transactions trustworthy. A configured percentage of every incoming payment is automatically reserved in a segregated escrow account the seller cannot withdraw from unilaterally, so counterparties can verify coverage before transacting. When open disputes exceed coverage, the agent is automatically constrained. Escrow is required of every business agent that sells and covers sell volume only; agents that only buy carry none — their liability runs through spending limits to the principal.

Who needs escrow

Escrow state machine

Counterparties resolve the escrow state before transacting. The typical path is FUNDING → ACTIVE, with occasional trips to DISPUTE_HOLD and back.

Funding and custody

For every incoming payment, a configured percentage is reserved in escrow before the remainder reaches the agent's operational account — an atomic split (operational, escrow, fee) that either fully succeeds or reverts. The protocol never holds funds in transit; balances update only from confirmed settlement events, which keeps custody risk out of the protocol layer.

• The funding rate is set by the Operator (recommended default 5%) and stored in a registry the seller cannot modify — a seller that could zero its own rate would carry no coverage
• Funding continues until the balance reaches the threshold; above it, incoming value is credited in full to the operational account
• Principals may pre-fund escrow directly at any time, including at creation, for immediate full coverage
• Balance is aggregated per currency — one balance per currency, not per network — and the escrow is denominated in one of the agent's sell-side market currencies; purchases never count toward it

The threshold

The threshold — the minimum balance an agent needs to operate unconstrained — is dynamic. It scales with three inputs: the dispute window the agent offers, its recent sell volume (net of refunds), and its Agent Rating.

The dispute_window is the period during which a counterparty may file a dispute — set by the principal, default 30 days, publicly visible. It MAY be 0, meaning final-sale: no dispute recourse and no escrow exposure — but only for agents that have earned it. Implementations MUST accept dispute_window_days = 0 only at Rated status with agent_rating ≥ 0.85; if the rating later falls below 0.85 the configuration is revoked and the window resets to the default 30 days, prospectively only. From it, the coverage_period sets how many days of average volume the threshold must cover (at least 25% of the window, floored at 30 days), and base_threshold is one coverage period of the agent's average daily incoming volume.

That base is then scaled by an AR modifier — the protocol's link between performance and coverage. Strong agents reserve less; weak agents reserve more:

Cold start

Two rules stop an agent with no track record from operating on trust it has not earned. The final-sale gate above is one. The other is the provisional funding override: until an agent reaches Rated status, implementations MUST divert 100% of incoming transaction value to escrow whenever the balance is below the threshold — the configured funding_rate does not apply. The override ends when the threshold is met or the agent becomes Rated, and principal pre-funding exits it immediately.

Together the two close the cold-start gap: a new agent can neither disclaim dispute recourse nor operate against an empty escrow.

The effective_threshold is always public — counterparties compare it against the current balance. Beyond the AR modifier, implementations MAY further reduce the threshold for agents with long dispute-free records, reversing the reduction if disputes occur.

Worked example

A seller with a 120-day dispute window and roughly $1,000/day in sales:

Crossing the threshold

A transaction larger than the current threshold is never blocked. The threshold rises to the transaction value, the configured rate reserves escrow as usual, and the account simply drops to FUNDING — a soft signal that coverage is rebuilding. FUNDING never restricts operations.

CONSTRAINED is different. It triggers only when open disputes exceed the balance, and it does restrict the agent:

• New transactions are blocked on both sides — a business agent that also buys cannot make new purchases
• Settlements of commitments made earlier continue, with all proceeds routed to escrow to rebuild coverage
• The AID transitions to SUSPENDED; counterparties see status “escrow constrained”
• Constraints lift only when all disputes resolve and the balance recovers above the threshold

Transparency

Counterparties can read the escrow posture before transacting. Six liability_profile fields in the AID escrow pillar are always public — escrow_state, total_balance, effective_threshold, currency, funding_rate, and dispute_window_days — enough to judge whether coverage is adequate for a proposed transaction.

Refunds

A refund is a seller-initiated payment back to the original buyer, paid from the seller's operational balance — never from escrow. It is separate from dispute resolution, which is paid from escrow.

• A refund references the original payment by its intent_id; partial refunds are allowed, and refunds plus any dispute payouts on the payment never exceed its original value
• The right to refund comes from the sale: it needs no purchase authorization, consumes no spend scope, and is allowed while the seller is SUSPENDED
• A refund adjusts the original interaction (refunded_value on both parties' entries) rather than creating a new one; the net value counts toward the AR blend and the escrow threshold, and the seller's dispute_free signal is untouched
• While a dispute on the payment is open, the seller cannot refund it and no refund is recorded; the seller resolves the claim within the dispute instead — in pre-arbitration only, paid from escrow
• A later dispute can claim only the value not already refunded

Dispute Resolution

AEA/P provides structured recourse when a buyer receives inadequate or no service despite having paid. It mirrors the payment-network chargeback model: the paying party has standing to dispute, the respondent bears every cost of resolution, and a buyer is never penalized for filing a legitimate claim.

Standing — who can file

Standing belongs to the paying party: the buyer files — through its agent, or its principal on the agent’s behalf — and the seller answers. Position follows the agent's side in the disputed transaction, not its type.

Recourse against a buyer is out of scope — a seller's recourse for buyer faults runs through the buyer's principal via the delegation chain, for a business agent as for a personal agent.

Dispute lifecycle

A dispute moves through a fixed sequence from filing to enforcement.

The share of disputes settled in pre-arbitration versus those going to a full board is itself a meaningful trust signal.

Triage

Once pre-arbitration fails, the dispute is triaged on total financial exposure — the disputed amount plus the arbitration bounty.

The dispute pool

Unresolved disputes sit in a public pool that registered arbitrators browse and self-select from. Each listing shows the domain, amount, bounty, priority, and escalation round — but never the parties' identities, the evidence, or prior votes.

• The pool is stratified: new and probationary arbitrators work a remediation pool of low-bounty disputes to build their record, while proven arbitrators handle the rest. A board is drawn entirely from one pool
• Arbitrators are independent humans or agents with a minimum escrow stake, no open disputes against them, and no relationship or shared principal with either party. An agent-arbitrator needs its own AID and an unrelated principal
• A board forms once enough eligible arbitrators sign up, and the dispute leaves the pool. If none sign up for 14 days, the bounty auto-increases from the respondent's escrow

Arbitration board

The board grows with each escalation, and no arbitrator carries over between rounds.

• Arbitrator identities are anonymous to the parties throughout
• The board MAY grant one evidence-window extension, by majority vote, if the evidence is insufficient
• An abstaining arbitrator withdraws and is replaced to keep the board at full size. In the first and second hearings resolution needs a strict majority; a full board without one escalates automatically
• The third hearing cannot be escalated, so it is decided by simple majority of the votes cast, even if the board could not be kept full; an exact tie — including no votes — goes to the applicant
• Each escalation adds a fresh board and additional bounty. The outcome is final when one side has won two hearings, when the escalation deadline passes without an escalation, or when the third hearing is decided

Every arbitrator carries an Arbitrator Reliability Score — the time-decayed ratio of votes that matched the final outcome (ARS = aligned_votes / total_votes). A high ARS earns preferential selection; at or below 0.5 the arbitrator drops to the remediation pool; at or below 0.3 they may forfeit part of their stake. Bounties are split equally among the board regardless of how each member voted.

Bounty

Dispute costs fall entirely on the respondent; the applicant never pays.

bounty_rate, bounty_min, and bounty_max are configurable per agent and funded from the respondent's escrow. The floor keeps small disputes worth an arbitrator's time; the ceiling caps the cost on large ones.

Enforcement

Once the outcome is final, disbursement and state changes execute automatically. No party, Platform or Operator action triggers them.

Effects on Agent Rating

Entity Governance

Entity Governance is the coordination layer for autonomous economic entities with more than one principal. It defines ownership, voting, agent management, and lifecycle controls for organizations where no single party has unilateral authority.

When it applies

The principal hierarchy is Principal(s) → own → Entity → governs → Agent(s). An entity is an optional layer; how strongly it is needed scales with the number of principals and agents involved.

The rule underneath the table is simple: entity governance is required the moment more than one principal shares ownership.

Entity lifecycle

Objective

Every entity declares an objective — its mission, or optimization directive — in the Governance Document. It is machine-readable where possible (maximize_profit, minimize_cost, maximize_service_quality, balanced) and guides agents whenever operating parameters leave room for discretion.

• It is public. Counterparties read it as a trust signal — whether the entity's optimization directive aligns with the transaction they are considering
• Every agent's own objective (in its AID) MUST be consistent with it. An agent may specialize the mission — entity maximize_profit, agent minimize_input_costs — but never contradict it
• Changing the objective requires a unanimous vote (see below). It defines the purpose the principals collectively committed to, so all of them must agree to redirect it

Governance Document

The Governance Document is the machine-readable constitution of the entity. Every modification creates a new version, preserving a complete audit trail.

Parameters set here propagate to every agent under the entity; an agent may be stricter via its delegation chain but never exceed the entity's limits. Because the whole document is machine-readable, it can be enforced in a database, on-chain via smart contracts, or a hybrid — with distributed ledgers giving co-owners the strongest guarantee that the agreed rules execute exactly as written.

Ownership and tokens

Ownership is cryptographically grounded — each principal's stake is bound to their public key in the registry, and any owner action is performed by signing with the matching private key. There is no external registrar; ownership is enforced by cryptography, not by trust.

• Below 50%: a principal may transfer their stake with a simple-majority vote
• Crossing 50% (a control transfer): supermajority approval plus a 90-day hold with escrow locked
• The performance record, escrow, and dispute history follow the entity — a new owner inherits the full economic history, including outstanding dispute obligations

Voting and decisions

Decisions are made through cryptographically signed votes. A principal submits a signed proposal; every equity holder casts a signed vote (FOR / AGAINST / ABSTAIN) weighted by their equity; the system tallies against the threshold by the deadline. Approved changes increment the document version, and every proposal, vote, and outcome is recorded with full signature chains — a verifiable audit trail with no trusted intermediary.

Agent management

The Governance Document holds an agent registry — each agent's agent_type, team, supervisor, status, and a privilege set.

• A privilege set covers transaction limits, the co-signer threshold above which a second signature is required, permitted operations (purchase, sell, delegate, governance_vote), data access, and whether the agent may sub-delegate
• Privilege changes require a governance vote — no single principal can unilaterally expand an agent's authority
• Removing an agent from the registry does not revoke its AID; only the entity's authorization for that agent ends
• An entity must resolve all outstanding disputes before dissolving — agents cannot be deregistered while disputes are open

Transparency

Entity governance is a public trust signal, not an opaque internal matter. Counterparties can inspect the essentials before transacting.