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

Changelog

Version history for the AEA/P Protocol Framework and Extended Specification.

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.

AID State Lifecycle

AID lifecycle

Every agent has an AID that progresses through defined states. Counterparties resolve any DID to check current status before transacting.

Certification tiers

Every AID carries a cert_tier reflecting the level of principal verification completed. Providers may set a minimum_cert_tier, refusing service to agents below that level.

Key AID fields

Field visibility

Delegation chains

• Maximum delegation depth: 5 levels from root principal
• A delegated agent cannot grant more authority than it holds — no privilege escalation
• Revoking any node in the chain suspends all agents below it
• PoP records are tied to the agent's DID — portable if the agent is re-delegated

Proof of Performance

PoP is AEA/P's automated performance rating mechanism. Ratings derive from verifiable transaction outcomes — task completion, payment history, dispute results — not subjective reviews. Principals cannot submit or suppress records. The rating is as objective as the on-chain payment events it reads from.

PoP Rating Lifecycle

Rating lifecycle

Provider signals

Consumer signals

Agent Rating formula

• rᵢ — task rating for interaction i (weighted sum of role-specific signals)
• tᵢ — age of interaction i in days. Decay constant 0.005 → half-life ≈ 139 days
• AR range: 0.0 to 1.0. High AR reduces the escrow effective threshold (see Pillar 03)

Manipulation resistance

• Platform-sourced only: Task records are created automatically at payment settlement — principals cannot submit, modify, or suppress them
• Sybil rule: Consumer and Provider sharing the same principal → transaction executes and escrow is credited, but no PoP task is created
• Auto-confirm at 72h: Task auto-confirms at 1.0 if Consumer is silent — prevents rating suppression by deliberate non-response

AR effect on escrow threshold

AR = 1.0 → modifier = 0.8 (20% escrow discount). AR ≤ 0.5 → modifier = 1.0 (no discount).

Liability Escrow

Liability Escrow makes agent transactions trustworthy. A percentage of every incoming payment is automatically reserved in a segregated escrow account controlled by the registry, not the Provider. Counterparties can verify coverage before transacting. When disputes exceed coverage, the agent is automatically constrained.

Liability Escrow State Machine

Escrow state machine

Funding mechanism

• escrowBps is set in the on-chain registry by the protocol operator — the Provider cannot lower it
• Principals may contribute directly to escrow independently of incoming payments
• Balance is aggregated per currency across all networks — multi-chain providers have one USD balance

Effective threshold components

Non-custodial design

The registry never holds funds in transit. The Settlement Contract routes payments atomically — all three transfers (operational, escrow, fee) succeed or all revert. The registry reads the on-chain Settled event to credit the escrow balance. This eliminates custody risk from the protocol layer.

Track record reduction

Sustained dispute-free performance progressively reduces the effective threshold. An agent with a clean record demonstrates lower risk — the protocol reflects this by reducing the reserve requirement over time. The reduction reverses if disputes are filed.

Dispute Resolution

AEA/P provides structured recourse when a Consumer receives inadequate or no service despite having paid. The protocol mirrors the payment network chargeback model: the payer has standing to dispute, the respondent bears dispute costs. Consumers never pay to file.

Dispute Resolution Lifecycle

Who can file

Only the Consumer (payer) may initiate a dispute. Provider recourse against a Consumer is handled outside this protocol version.

Dispute lifecycle

Triage

Arbitration board

Board size scales with each escalation round. Maximum three hearings — no arbitrators carry over between rounds.

• The board may grant one evidence window extension if evidence is insufficient — requires a majority board vote
• Arbitrator identities are not disclosed to disputing parties during the hearing
• Arbitrators are paid per vote, not per outcome — removing incentive to vote with the expected majority
• Arbitrator Reliability Score (ARS) tracks alignment with final outcomes over time. Outlying arbitrators are removed from the pool

Bounty formula

Higher bounties attract faster resolution. bounty_rate, bounty_min, and bounty_max are configured per market by the protocol operator and funded from the Provider's escrow.

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

Principal hierarchy: Principal(s) → own → Entity → governs → Agent(s). Entity governance is optional for single-principal deployments. It is required when:

• Two or more principals share ownership of an economic operation
• An agent operates with delegated authority that requires collective approval to modify
• An organization wants enforceable lifecycle controls — ownership transfer, succession, dissolution — without a legal jurisdiction

Entity lifecycle

Governance Document

Voting and decisions

Ownership and transfer

• Below 50%: any principal may transfer their stake with a simple majority vote
• Crossing 50% (control transfer): supermajority required + 90-day hold with escrow locked
• The entity's PoP history follows the entity on transfer — reputation is not lost when ownership changes
• The incoming controlling principal inherits all outstanding dispute obligations

Agent management

• 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 is removed
• An entity must resolve all outstanding disputes before dissolving — agents cannot be deregistered while disputes are open

How it works

A complete AEA/P-governed interaction between a Consumer agent and a Provider agent spans six protocol phases — from identity verification through payment, service delivery, and PoP confirmation. Every phase is mandatory for production transactions.

Overview

The six phases in sequence:

Phase 0 — Onboarding

Before a PROVIDER can accept payments under AEA/P, it registers a market configuration with the registry. This one-time setup provisions a segregated escrow wallet and registers the Provider on the Settlement Contract. The registry controls the escrow wallet — 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 registry under its control. The Provider cannot withdraw from or modify escrow parameters directly
• The funding_rate is set from a registry-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 — Mutual authentication

Before committing to a payment, the Consumer verifies that the Provider holds a valid AEA/P identity and has sufficient escrow coverage. Critically, certificate verification is offline — the Consumer never needs a round-trip to the registry to verify the Provider's identity or the validity of the challenge response. The registry is only called once, to check live operational status.

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 registry 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. The protocol specifies exactly what the 402 response may and may not disclose. The registry creates a payment intent when the Provider requests payment details — this intent tracks whether the Consumer follows through, feeding into the Consumer's payment_timeliness PoP signal.

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 registry 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 registry 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 in the on-chain registry. Only the protocol operator 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 — Service delivery

With payment settled, the Consumer makes the actual service request. The Provider verifies the Consumer's identity — mirroring the Consumer's Phase 1 verification of the Provider. The registry enforces environment isolation: a sandbox Consumer cannot complete a verified transaction with a production Provider, and vice versa.

Protocol requirements

• Bound proof: The Consumer includes an EC signature over (timestamp | consumer_did | provider_did). This cryptographically links the service call to the specific Consumer–Provider pair, preventing replay of the payment proof for a different service call
• Environment enforcement: The registry checks that both agents' environment fields match. Sandbox agents cannot complete a PROOF_VERIFIED call against production agents — this is enforced at the registry, not just by convention
• The registry logs a PROOF_VERIFIED event for auditability — timestamped proof that the Consumer was verified before service was delivered
• The Provider independently checks the Consumer's pop_rating and may enforce a minimum_cert_tier. If the Consumer does not meet requirements, the Provider may reject the request without affecting either party's rating

What the Consumer sends

Phase 5 — Facilitation

The Provider submits the transaction hash to the registry. The registry reads the on-chain Settled event — it does not submit transactions. This is how AEA/P achieves non-custodial escrow: the registry observes what happened on-chain rather than intermediating the transfer. Facilitation also runs the Sybil check and creates the PoP task that opens the 72-hour confirmation window.

Protocol requirements

• Read-only on-chain access: The registry reads the Settled event but never submits blockchain transactions. It verifies: settlement contract address matches registered contract, DID hashes match, amounts match the registered split configuration
• Sybil check: If the Consumer and Provider share the same principal, the service executes and escrow is credited — but no PoP task is created and no PoP credit accrues to either agent. This prevents principals from inflating their own agents' ratings through self-dealing
• Escrow balance is aggregated per currency across all networks. A Provider operating on Base and Arbitrum has a single USD escrow balance reflecting both chains
• The payment intent is marked SETTLED by matching consumer_did + provider_did + amount against open intents
• A PoP task is created immediately — the 72-hour confirmation window opens at facilitation time, not at settlement time

What facilitation verifies

Phase 6 — PoP confirmation

Within 72 hours of facilitation, the Consumer confirms whether the service was delivered. The registry 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.