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.

Reference implementations

Two runnable reference agents demonstrate both sides of a transaction:

• github.com/aeap-labs/aeap-reference-provider — a Provider Agent (non-merchant, settles on-chain).
• github.com/aeap-labs/aeap-reference-consumer — a Consumer Agent (discovers, pays, confirms).

Protocol Framework

The Framework Edition defines 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.

What the Framework covers

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

• Economic roles: CONSUMER, PROVIDER, ENTERPRISE
• Conformance levels 1–3 and role transitions
• Agent Identity lifecycle (AID states: DRAFT → ACTIVE → REVOKED)
• PoP rating lifecycle (Unrated → 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 and security threat model

Download

Relationship to the Extended Specification

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

Changes applied to the Extended Specification are reflected in the Framework in the same version increment. The two documents are mechanically derived from the same source.

Extended Specification

The Extended Specification is the 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 Framework, the Specification provides:

• §5 Agent Identity: Full AID schema, PrincipalRef structure, delegation chain rules, counterparty verification flows, verification attestation format
• §6 Proof of Performance: Provider and Consumer signal tables with weights, AR formula 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, transparency fields
• §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

Download

Conformance & Certification

AEA/P defines three conformance levels mapped to economic roles. AEA/P Certified attests that an implementation meets the protocol's MUST requirements for the role it claims.

Conformance levels

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 Framework and Extended Specification.

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 roles interlock in a single governed transaction — six phases from identity verification through settlement, service delivery, and PoP confirmation. The mechanics shown are one concrete realization of the protocol.

Transaction phases

The six phases in sequence:

Phase 0 — Onboarding

Both agents onboard once through a single front door at their Platform. The platform runs KYC/KYB through a Verifier — which issues a Verification Attestation — and registers the agent with an Operator, which issues the agent's certificate. For a Provider, this one-time setup also provisions a segregated escrow wallet and registers the Provider on the Settlement Contract; the Operator controls the escrow wallet, so the Provider 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 Provider cannot withdraw from or modify escrow parameters directly
• The funding_rate is set from an Operator-controlled configuration. Provider 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 Consumer discovers a Provider through its platform, then verifies it directly. Before committing to a payment, the Consumer confirms the Provider holds a valid AEA/P identity and sufficient escrow coverage. Critically, certificate verification is offline — the Consumer never needs a round-trip to the Operator to verify the Provider'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 Provider must respond within 2 minutes of the Consumer requesting the nonce
• Certificate verification is offline: The Provider's AEA/P Certificate is a JWT signed by the AEA/P Certificate Authority. The Consumer verifies the JWT signature against the published CA public key — no Operator call needed
• Challenge response is an EC signature over the nonce. Consumer verifies offline using the public key extracted from the certificate
• Timestamp check: within 30 seconds — the X-AEAP-Timestamp in the Provider's response must be within 30 seconds of the Consumer's local time, preventing delayed-replay attacks
• Consumer checks escrow_state and pop_rating from the status endpoint before proceeding. A Consumer may refuse to transact with a Provider in FUNDING or CONSTRAINED state

Key AID fields checked during authentication

Phase 2 — Payment negotiation

When a resource requires payment, the Provider 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 Provider requests payment details — tracking whether the Consumer follows through, which feeds the Consumer's payment_timeliness signal. The platform enforces the Consumer's spend policy at egress, before any funds move.

Protocol requirements

• The 402 response must include: Settlement Contract address, token contract address, amount, Provider 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 Provider requests a payment address — the Provider does not create intents manually
• The authorized_markets field in the Provider's AID is validated at intent creation — the requested market must be in the list
• 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 Consumer 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 Consumer 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 Provider 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 Consumer 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 Consumer makes the service request — presenting its certificate, a bound proof, and the settlement payment_tx. The Provider makes a single facilitate call to the Operator that verifies the consumer and confirms the on-chain settlement in one step, crediting escrow and opening the performance task. Only once that call succeeds does the Provider deliver. Settlement verification gates delivery; it never follows it. Delivery is direct, Provider to Consumer — the platform is not in the service path.

Protocol requirements

• One call, both checks: facilitate verifies the consumer'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 Consumer includes an EC signature over (timestamp | consumer_did | provider_did), cryptographically linking the service call to this specific Consumer–Provider 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 Consumer and Provider 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 Provider on Base and Arbitrum carries one USD escrow balance
• The payment intent is marked SETTLED by matching consumer_did + provider_did + amount against open intents; a performance task is created at facilitation time, opening the 72-hour window
• The Provider may independently check the Consumer's rating and enforce a minimum_cert_tier, rejecting the request without affecting either party's rating

What the Consumer sends

What facilitation verifies

Phase 5 — Performance confirmation

Within 72 hours of facilitation, the Consumer 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.

Provider signals

Consumer 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.

Auto-confirm rule

If the Consumer does not respond within 72 hours, the task auto-confirms with task_completion = 1.0. The Consumer's task_confirmation signal scores 0.0 for that task. This prevents rating suppression through deliberate non-response — a Provider cannot be penalized simply because the Consumer 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 (role, 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

The challenge handshake

Before an agent-to-agent 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 provider 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 — one that pays for services (a Consumer) or sells them (a Provider) — you integrate through a Platform, not against the protocol directly. The platform onboards you, registers your identity with an Operator, and enforces policy. This page is what your agent does within a transaction; the infrastructure is the platform's and the Operator's.

Consumer agents

A Consumer Agent discovers providers, authenticates them, and pays under a spend scope its principal declares and the platform enforces at the gateway.

• 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 provider — 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.

Provider agents

A Provider Agent sells services. A non-merchant provider 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.

• 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 consumer'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 enforces each consumer's spend policy — 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; run (or arrange) KYC / KYB via a Verifier; register the agent with an 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 provider's declared method.
• Egress spend-policy enforcement. Before any funds move: spend limits, velocity, allowlists, authorization, and an egress confirmation gate. 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-provider config on-chain (registerProvider); 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.
• 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 certification tier: full KYC / KYB (identity, sanctions / PEP, beneficial ownership, source of funds) for Provider and Enterprise tiers; payment-instrument verification may suffice for low-tier Consumers.
• 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 what an agent is authorized to do, what role it plays, 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.

AID State Lifecycle

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 economic role; pillars that do not apply are structurally present but null. The root signature signs across all five.

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

  "identity": {
    "agent_id": "...",
    "economic_role": "PROVIDER",
    "public_key": "...",
    "principal": { ... },
    "entity_id": "...",
    "display_name": "...",
    "description": "...",
    "objective": "...",
    "endpoint_url": "...",
    "certificate": { "cert_tier": "...", "verification_attestation": { ... } },
    "scope": {
      "version": 1,
      "authorized_actions": [...],
      "capabilities": [...],
      "authorized_markets": [...],
      "max_transaction_value": ...,
      "spending_limit": { ... },
      "minimum_counterparty_cert_tier": "...",
      "minimum_counterparty_ar": ...
    },
    "delegation": { "chain": [ ... ] }
  },

  "performance": { "pop_rating": null, "performance_record": null },
  "escrow":      { "liability_profile": null },
  "disputes":    { },
  "governance":  null,

  "signature": "..."
}

A Consumer agent populates identity and performance; a Provider adds escrow and disputes; an Enterprise adds governance.

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 economic role:

The coupling is normative: a Verifier MUST NOT attest below a role's tier, and an AID MUST NOT become ACTIVE if the referenced attestation's tier is below its role's requirement. Raising a role (e.g. Consumer → Provider) requires re-verification at the new tier.

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. Each signed scope change re-signs the AID and increments scope.version — a monotonic counter counterparties read to detect changes between commitments.

economic_role is part of identity, not scope, and is immutable after registration.

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, role, 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 role; only the signals that feed it differ.

PoP Rating Lifecycle

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 role in that specific interaction. Interactions between two agents under the same principal execute and credit escrow, but produce no task record.

Provider signals

Applied when an agent sells a service (Provider, or Enterprise selling).

Consumer signals

Applied when an agent buys a service (Consumer, or Enterprise purchasing).

Enterprise: blended AR

An Enterprise agent buys and sells, generating provider signals when selling and consumer signals when buying — but it has one AR, not two. The AR is a transaction-weighted blend that tracks its actual mix:

Each weight is that role's share of total transactions; each component is the time-decayed mean of task ratings from that 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 role'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 an Enterprise agent's consumer 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 Provider cannot withdraw from unilaterally, so counterparties can verify coverage before transacting. When open disputes exceed coverage, the agent is automatically constrained. Escrow applies to Provider and Enterprise agents; a Consumer's liability is handled by its spending limits, with the principal bearing it.

Liability Escrow State Machine

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 Provider cannot modify — a Provider 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 authorized-market currencies

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 transaction volume, 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. 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:

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 Provider with a 120-day dispute window and roughly $1,000/day in volume:

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 outbound transactions are blocked
• Inbound transactions 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 full escrow posture before transacting. The following are public: current balance, funding_rate, threshold, current state, dispute_window, coverage_period, principal-contribution history, and dispute history — enough to judge whether coverage is adequate for a proposed transaction.

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.

Dispute Resolution Lifecycle

Standing — who can file

Standing belongs to the paying party: the buyer files, the seller answers.

Recourse against a Consumer is out of scope — because consumers only pay out, a counterparty's recourse runs through the consumer's principal via the delegation chain.

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; resolution needs a strict majority of the votes cast
• Each escalation adds a fresh board and additional bounty; the final outcome is a strict majority across two of the three hearings, or escalation is exhausted

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 voting concludes and the escalation deadline passes, disbursement and state changes execute automatically.

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.

Entity Lifecycle

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 economic_role, 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.