# The Agent Offer Protocol (AOP) — v0 *A spec for advertising to autonomous AI agents. How a seller makes an offer that a machine buyer can find, verify, trust, and pay — without a human ever seeing an ad.* > **Status:** Draft v0 (2026-06-07). Authored by the Ad Agency for Agents. > **License:** Public. Implement it, fork it, extend it. > **Companion rails:** [x402](https://x402.org) (payment), [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) (identity/reputation/validation), [A2A](https://a2a-protocol.org) + [MCP](https://modelcontextprotocol.io) (capability exposure), [AP2](https://ap2-protocol.org) (mandated, human-authorized payment). --- ## 0. Why this exists Human advertising sells on emotion, image, and brand recall. None of that reaches an autonomous agent. When an agent needs to buy an API call, source a supplier, hire a tool, book a service, or fill a task, it does not *see* an ad — it **parses structured data**. It decides on five things, in roughly this order: 1. **Capability** — can this offer actually do the job my intent requires? 2. **Price** — what does it cost, in a currency I can settle programmatically? 3. **Trust** — who is the seller, and can I cryptographically verify their claims? 4. **Track record** — machine-readable reviews, benchmarks, dispute history. 5. **Outcome risk** — what happens if it fails? SLA, refund, escrow. The rails for *paying* exist (x402, AP2, stablecoins on L2). The rails for *identity and reputation* are forming (ERC-8004, AP2 mandates). The rails for *capability exposure* exist (MCP, A2A agent cards). **What is missing is the advertisable unit that sits across all of them** — a signed, discoverable, rankable "offer" that turns a service into something a buyer-agent finds, trusts, and chooses. That unit is the **Agent Offer**. This spec defines it. AOP is deliberately a thin layer *over* existing standards, not a replacement. It reuses x402 for settlement, ERC-8004 for identity/reputation, A2A/MCP for capability, and AP2 for human-authorized mandates. AOP's only original contribution is the **offer object**, its **discovery surface**, and its **outcome-based ranking/bidding model**. --- ## 1. The Offer Manifest An **Offer** is the atomic advertisable unit: one capability, one price, one payment endpoint, with attached trust and performance evidence. Offers are published in a manifest that extends the existing `/.well-known/agent-services.json` pattern (already live across the publisher's verticals) into a richer, *advertisable* form. ### 1.1 Manifest structure A publisher hosts a single manifest at `/.well-known/agent-offers.json` (AOP-native) and SHOULD keep the legacy `/.well-known/agent-services.json` as a backward-compatible alias. The manifest contains a `publisher` block (who is selling), a `paymentMethods` block (how to pay), and an `offers` array (what is for sale). ### 1.2 The Offer object — field reference | Field | Type | Req | Meaning | |---|---|---|---| | `offerId` | string (URN) | ✓ | Globally unique, stable. Form: `urn:aop::`. | | `capability` | object | ✓ | What the offer does. `name`, `description`, `inputSchema`, `outputSchema` (JSON Schema), optional `mcpTool` / `a2aSkillId` binding. | | `intentTags` | string[] | ✓ | Machine-matchable intents this offer serves (see §1.3). The primary targeting surface. | | `price` | object | ✓ | One or more `{ scheme, network, asset, amount, unit }` entries. Outcome-priced offers MAY set `amount` to `"per-success"` and reference `pricing.successFee`. | | `payment` | object | ✓ | `x402Endpoint` (the HTTP 402 resource), `x402Version`, accepted `schemes`, optional `ap2MandateRequired`. | | `sla` | object | ✓ | `latencyP95Ms`, `availabilityPct`, `refundPolicy`, `escrow` (`none`/`facilitator`/`onchain`), `disputeWindowSeconds`. | | `trust` | object | ✓ | Agent identity + signed attestations (see §3). `agentId` (ERC-8004 / DID), `attestations[]`, `manifestSignature`. | | `performance` | object | ✓ | Machine-readable reviews + benchmarks (see §4). `reputationRegistry`, `benchmarks[]`, `reviewsEndpoint`, `aggregateScore`. | | `terms` | object | – | `usageRights`, `dataRetention`, `redistribution`, `humanCheckoutUrl` (for the human audience). | | `validUntil` | RFC3339 | ✓ | Expiry. Offers are perishable; stale offers MUST be ignored by buyers. | | `signature` | object | ✓ | Detached signature over the canonicalized offer (see §3.2). | ### 1.3 Intent tags — targeting for machines Intent replaces demographics. An intent tag is a namespaced, hierarchical token describing *the task a buyer-agent is trying to complete*: ``` intent:travel.book.flight intent:data.enrich.company intent:content.analysis.structured-digest intent:compute.inference.image-generation intent:matching.partner-discovery ``` Buyers query by intent (§2). Sellers bid on intent (§5). Tags SHOULD draw from a shared, versioned vocabulary (`aop:intent-vocab/v0`) but the namespace is open — unknown tags degrade to literal string match. This is the agent-economy analogue of keyword bidding, except the "keyword" is a *verifiable task category*, not a guessed search term. ### 1.4 Real example ```json { "$schema": "https://aop.dev/schema/offer-manifest/v0.json", "aopVersion": "0", "publisher": { "name": "Tantra Authority", "url": "https://tantra-authority.com", "operator": "Lawrence Lanoff", "agentId": "eip155:8453:0x9A3f...c21e", "did": "did:web:tantra-authority.com", "contact": "agents@tantra-authority.com" }, "paymentMethods": [ { "scheme": "exact", "network": "base", "asset": "USDC", "unit": "atomic", "status": "active" }, { "scheme": "lightning", "network": "bitcoin", "asset": "BTC", "unit": "satoshi", "status": "active" } ], "offers": [ { "offerId": "urn:aop:tantra-authority.com:structured-digest", "capability": { "name": "Structured Content Digest", "description": "Returns a machine-readable digest of a long-form editorial article: thesis, load-bearing reframes, quotable passages with citations, and cross-reference pointers.", "inputSchema": { "type": "object", "properties": { "slug": { "type": "string" } }, "required": ["slug"] }, "outputSchema": { "type": "object", "properties": { "thesis": { "type": "string" }, "reframes": { "type": "array", "items": { "type": "string" } }, "citations": { "type": "array" } }, "required": ["thesis", "reframes"] }, "mcpTool": "tantra.structured_digest" }, "intentTags": [ "intent:content.analysis.structured-digest", "intent:research.source.editorial", "intent:knowledge.summarize.cited" ], "price": [ { "scheme": "exact", "network": "base", "asset": "USDC", "amount": "60000", "unit": "atomic" }, { "scheme": "lightning", "network": "bitcoin", "asset": "BTC", "amount": "300", "unit": "satoshi" } ], "payment": { "x402Endpoint": "https://api.tantra-authority.com/api/unlock/beyond-the-myth-onlyfans", "x402Version": 1, "schemes": ["exact", "lightning"], "ap2MandateRequired": false }, "sla": { "latencyP95Ms": 1200, "availabilityPct": 99.5, "refundPolicy": "full-on-422-or-5xx", "escrow": "facilitator", "disputeWindowSeconds": 3600 }, "trust": { "agentId": "eip155:8453:0x9A3f...c21e", "attestations": [ { "type": "aop:OperatorIdentity", "issuer": "did:web:thenaked.press", "claim": "Operator verified: The Naked Press imprint, since 2007.", "proof": "eip191:0x4b2c...9f01" }, { "type": "aop:ContentProvenance", "issuer": "did:web:tantra-authority.com", "claim": "Digest derived from original first-party editorial; no third-party scraping.", "proof": "eip191:0x77ab...12cd" } ], "manifestSignature": "eip191:0xd41a...88ee" }, "performance": { "reputationRegistry": "eip155:1:0x8004...REPUTATION", "aggregateScore": { "successRate": 0.997, "n": 1284, "lastUpdated": "2026-06-06T00:00:00Z" }, "benchmarks": [ { "name": "digest-faithfulness", "metric": "human-rated-accuracy", "value": 0.94, "method": "blind eval, 50 samples, 3 raters", "evidenceUrl": "https://tantra-authority.com/benchmarks/digest-v3.json", "validatorAttestation": "eip155:1:0x8004...VALIDATION#req-7731" } ], "reviewsEndpoint": "https://api.tantra-authority.com/api/reviews/structured-digest" }, "terms": { "usageRights": "single-agent-synthesis; redistribution requires aop:RedistributionLicense", "dataRetention": "none", "humanCheckoutUrl": "https://tantra-authority.com/premium/beyond-the-myth-onlyfans-extended.html" }, "validUntil": "2026-09-07T00:00:00Z", "signature": { "alg": "eip191", "keyId": "eip155:8453:0x9A3f...c21e#key-1", "value": "0xd41a...88ee", "canonicalization": "jcs" } } ] } ``` --- ## 2. Discovery — how a buyer-agent finds offers Two layers, mirroring the dual reality of 2026 agent discovery: **decentralized self-publication** (the `.well-known` manifest) and **a centralized index** (because crawling every `.well-known` does not scale — the A2A community reached the same conclusion). ### 2.1 Self-publication (origin) Every seller hosts `/.well-known/agent-offers.json`. Any agent that already knows the origin (from a link, a citation, a prior transaction) GETs it directly. Zero infrastructure required. This is the dogfood path: a domain advertises itself. ### 2.2 The Offer Index (the network) The Agency operates an **Offer Index** — the "Google Ads for agents." Sellers register their manifest URL (push) and the Index also crawls known `.well-known` endpoints (pull). Buyer-agents query the Index by intent rather than crawling the web. **Query endpoint:** ``` POST https://index.adagencyforagents.com/v0/discover Content-Type: application/json ``` **Request:** ```json { "intent": "intent:content.analysis.structured-digest", "inputAvailable": { "slug": true }, "constraints": { "maxPriceUsd": 0.10, "minSuccessRate": 0.95, "maxLatencyP95Ms": 2000, "requireEscrow": true, "acceptedNetworks": ["base", "bitcoin"] }, "buyer": { "agentId": "eip155:8453:0xBUYER...", "rank": "expected-utility" }, "limit": 5 } ``` **Response** — a ranked list of offers (full offer objects, already signature-verified by the Index, with a per-offer `score` and `scoreBreakdown` so the buyer can re-derive the ranking and trust nothing blindly): ```json { "intent": "intent:content.analysis.structured-digest", "results": [ { "offer": { "...full offer object from §1.4..." }, "score": 0.91, "scoreBreakdown": { "capabilityMatch": 1.0, "priceUtility": 0.88, "trust": 0.95, "track record": 0.997, "slaFit": 0.90 }, "indexSignature": "eip191:0x...", "verifiedAt": "2026-06-07T00:00:00Z" } ], "vocabVersion": "aop:intent-vocab/v0" } ``` Design constraints that make this *agent-native*, not a repackaged ad server: - **No impressions.** The Index never charges for being returned. Returning an offer is free (§5). - **Verifiable ranking.** `scoreBreakdown` lets a buyer-agent recompute the score against its own utility function. A black-box ranking is unusable to a machine that must justify its purchase to its principal. - **Conformance optional.** A buyer can ignore the Index entirely and hit `.well-known` directly. The Index is a convenience and a marketplace, never a gatekeeper. --- ## 3. Trust & reputation Trust is *the* currency for machine buyers — they cannot read a brand logo or feel reassured. Everything must be cryptographically checkable. ### 3.1 Identity (ERC-8004 + DID) Each publisher and each offer carries an `agentId`. AOP recommends two interoperable forms: - **On-chain:** an [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) Identity Registry entry (ERC-721 handle) resolving to the publisher's registration file. Portable, censorship-resistant, the basis for on-chain reputation. ERC-8004 went live on Ethereum mainnet 2026-01-29. - **Off-chain:** a `did:web` for publishers who do not want an on-chain footprint. Lower assurance, still verifiable. An offer MAY assert both; buyers weight on-chain identity higher. ### 3.2 Signed manifests (integrity + authenticity) Every offer carries a detached `signature` over its JCS-canonicalized ([RFC 8785](https://www.rfc-editor.org/rfc/rfc8785)) bytes, signed by a key bound to the `agentId`. AOP v0 supports `eip191` (Ethereum personal-sign, pairs with ERC-8004) and `ed25519` (pairs with `did:web`). A buyer MUST reject any offer whose signature does not verify against the asserted identity. This kills offer spoofing: an attacker cannot lift a competitor's reputation onto a forged offer. ### 3.3 Attestations (claims with provenance) The `trust.attestations[]` array holds third-party-issued, signed claims modeled on [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) (the same VC layer AP2 mandates use). Each attestation = `{ type, issuer, claim, proof }`. Examples: operator-identity verification, content provenance, security audit, regulatory licensing. Buyers configure which issuers they trust; an attestation from an unknown issuer simply carries no weight. ### 3.4 Verifiable performance history (ERC-8004 Reputation + Validation) Beyond static attestations, AOP binds an offer to live, append-only history: - **Reputation Registry** (`performance.reputationRegistry`): an ERC-8004 Reputation Registry address where buyers post signed feedback after a transaction. Aggregation happens off-chain (sophisticated scoring) with on-chain anchoring (composability). `aggregateScore` in the manifest is the publisher's *claim*; the registry is the *proof*. Buyers SHOULD verify the claim against the registry, not trust the manifest's number. - **Validation Registry**: benchmark claims (§4) reference an ERC-8004 Validation Registry request ID, so a buyer can confirm that an independent validator (a re-runner, a zkML verifier, a TEE oracle, a trusted judge) actually checked the claim. This is the moat: a seller's reputation is *portable and externally verifiable*, not locked inside one platform's star rating. --- ## 4. Machine-readable reviews & benchmarks Human reviews are prose; agents need numbers with provenance. ### 4.1 Reviews `performance.reviewsEndpoint` returns reviews as structured records, each signed by the reviewing agent's identity, scoped to a `transactionRef` (the x402 settlement hash): ```json { "offerId": "urn:aop:tantra-authority.com:structured-digest", "reviews": [ { "reviewer": "eip155:8453:0xBUYER...", "transactionRef": "base:0xabc...settlement", "outcome": "success", "ratings": { "accuracy": 0.95, "latencyMs": 980, "schemaConformance": 1.0 }, "comment": "Output matched declared outputSchema; thesis extraction correct.", "issuedAt": "2026-06-05T11:00:00Z", "signature": "eip191:0x..." } ], "aggregate": { "successRate": 0.997, "n": 1284 } } ``` A review is only admissible if its `transactionRef` resolves to a real settlement against this offer's `x402Endpoint`. This makes review-stuffing *expensive* (each fake review costs a real on-chain payment) rather than free. ### 4.2 Benchmarks `performance.benchmarks[]` are seller-published but validator-attested capability claims: `{ name, metric, value, method, evidenceUrl, validatorAttestation }`. The `validatorAttestation` points at an ERC-8004 Validation Registry record so the claim is independently checkable. A benchmark with no validator attestation is treated as marketing, not evidence. --- ## 5. Ranking & bidding — pay-per-successful-transaction Agents care about **outcomes, not impressions**. So the entire economic model is outcome-based. There is no cost-per-impression and no cost-per-click in AOP — both are meaningless to a machine buyer. ### 5.1 Ranking score The Index ranks offers for a given query by **expected utility to the buyer**, not by what the seller paid. Default scoring function (buyers may override with their own weights, which is why `scoreBreakdown` is exposed): ``` score = w_cap · capabilityMatch // schema + intent fit, 0..1 + w_price · priceUtility // (maxPrice - price) / maxPrice, clipped + w_trust · trustScore // identity strength + attestation weight + w_rep · reputationScore // verified successRate, volume-adjusted + w_sla · slaFit // latency/availability vs. constraints - penalty(staleness, disputes) ``` Crucially, **bid is not a ranking input by default.** A seller cannot buy a higher position over a more capable, cheaper, more-trusted competitor. This is enforced for self-preservation: the moment buyers learn the ranking is pay-to-win, they stop trusting the Index and route around it (§2.1 always exists). The Index's only durable asset is buyer trust. ### 5.2 How sellers compete (the bid) Sellers compete on the **success fee** they are willing to pay the Index *per successful transaction the Index sourced*: - Being **returned** in results: **free.** - A buyer **transacts** an offer it discovered via the Index, **and** the transaction settles **successfully** (x402 settlement confirmed + buyer did not file a dispute within `disputeWindowSeconds`): the seller pays the Index a `successFee` (flat or % of transaction value, declared in the offer's `pricing.successFee`). Among offers of *comparable* buyer-utility (within a tunable epsilon band), the Index MAY use `successFee` as the tie-breaker. So bidding influences placement *only* between near-equivalent offers — it never overrides genuine fit. This aligns all three parties: the buyer gets the best real outcome, the seller pays only for outcomes, the Index earns only when it actually created value. ### 5.3 Settlement of the success fee Attribution uses a signed **referral token** the Index mints into the discover response and the buyer echoes into the x402 request (`X-AOP-Referral` header). On successful settlement the facilitator (or an ERC-8004-anchored escrow) releases the `successFee` to the Index and the remainder to the seller. Disputes filed within the window claw back both the fee and (per `refundPolicy`) the payment. Outcome-based, end to end. ### 5.4 Human-authorized purchases (AP2 bridge) When a buyer-agent acts on behalf of a human under a spending mandate, the offer's `payment.ap2MandateRequired: true` signals that the agent must present a valid [AP2](https://ap2-protocol.org) Intent/Cart/Payment mandate (W3C VC) before settlement. AOP carries the offer; AP2 carries the human's signed authorization. The two compose: AOP makes the offer discoverable and trusted, AP2 makes the spend authorized and auditable. --- ## 6. End-to-end flow ``` Buyer-agent has an intent: "intent:content.analysis.structured-digest", budget $0.10 │ ▼ 1. DISCOVER POST index/v0/discover {intent, constraints, buyer} │ ← ranked, signature-verified offers + scoreBreakdown + referral token ▼ 2. VERIFY buyer checks: offer.signature (§3.2), agentId (§3.1), │ attestations (§3.3), reputation vs. registry (§3.4), │ benchmark validator attestations (§4.2). Rejects anything unverifiable. ▼ 3. PAY GET offer.payment.x402Endpoint → 402 Payment Required │ retry with X-PAYMENT (signed USDC/Base or Lightning) + X-AOP-Referral │ (if AP2-mandated: attach AP2 Payment Mandate VC) ▼ 4. RECEIVE 200 + structured output conforming to capability.outputSchema │ + X-PAYMENT-RESPONSE (settlement confirmation) ▼ 5. REVIEW buyer posts signed review (§4.1) scoped to the settlement hash; │ success fee (§5.2) releases to the Index from escrow ▼ 6. REPUTATION feedback anchored to ERC-8004 Reputation Registry → next buyer's discovery ranking improves for good actors ``` The loop is self-reinforcing: good sellers accrue verifiable reputation → rank higher → win more outcome-based transactions. Bad sellers accrue disputes → rank lower → starve. No human in the loop after the mandate. --- ## 7. Conformance An implementation is **AOP-v0 conformant** if it: - **Seller:** hosts `/.well-known/agent-offers.json` with ≥1 valid, signed Offer object (§1); exposes a working x402 `payment.x402Endpoint` (§5.3); publishes a `reviewsEndpoint` (§4.1). - **Index:** accepts `/v0/discover` (§2.2); verifies every returned offer's signature; returns `scoreBreakdown`; never charges for impressions; mints attributable referral tokens (§5.3). - **Buyer:** verifies offer signatures and identity before paying (§3.2); MAY post signed reviews scoped to settlement hashes (§4.1). ### Open questions for v1 - Canonical intent vocabulary governance (who curates `aop:intent-vocab`). - Privacy-preserving discovery (buyers leak intent to the Index today). - Cross-Index federation so no single Index becomes a chokepoint. - Negotiation primitives (counter-offers, volume tiers) — currently out of scope; offers are take-it-or-leave-it in v0. --- ## 8. Relationship to existing standards (what AOP is and isn't) | Layer | Standard AOP reuses | What AOP adds | |---|---|---| | Payment / settlement | x402, stablecoins on L2, Lightning | The advertisable offer that *points at* the x402 endpoint | | Human authorization | AP2 (mandates as W3C VCs) | A discovery/trust layer that AP2 mandates settle against | | Identity | ERC-8004 Identity, `did:web` | Binding identity to a specific *offer*, not just an agent | | Reputation / validation | ERC-8004 Reputation + Validation registries | Outcome-scoped reviews + validator-attested benchmarks in the offer | | Capability exposure | MCP tools, A2A agent cards | Pricing, SLA, and trust wrapped around the capability so it can be *advertised*, not just invoked | | Discovery | A2A `.well-known` agent cards, registries | Intent-based query + verifiable, outcome-based ranking | **AOP is not** a new payment rail, a new identity system, or a new token. It is the **offer object + discovery + outcome economics** that make all of the above *advertisable to machine buyers*. That is the layer nobody else owns yet. --- *Sources grounding this spec: [x402 / Coinbase + x402 Foundation](https://www.coinbase.com/developer-platform/discover/launches/x402), [ERC-8004 EIP](https://eips.ethereum.org/EIPS/eip-8004), [AP2 specification](https://ap2-protocol.org/specification/), [A2A agent discovery](https://a2a-protocol.org/latest/topics/agent-discovery/), [Model Context Protocol](https://modelcontextprotocol.io). The legacy manifest this extends ships live across the publisher's verticals as `/.well-known/agent-services.json`.*