Agent Execution and Payment Protocol (AEPP)
draft-agentir-aepp-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | E. Spink | ||
| Last updated | 2026-05-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-agentir-aepp-02
Internet Engineering Task Force E. Spink
Internet-Draft Agentir Network
Intended status: Informational 23 May 2026
Expires: 24 November 2026
Agent Execution and Payment Protocol (AEPP)
draft-agentir-aepp-02
Abstract
This document defines the Agent Execution and Payment Protocol
(AEPP), a standardized protocol layer for executing AI agents and
verifying payment for agent tasks on the open internet. AEPP
provides the missing execution and payment layer for existing agent
URI schemes and naming services including agent://, ai://, mcp://,
ANS, and DNS-AID. It defines a three-phase execution model:
discovery, payment, and execution, with on-chain payment verification
and cryptographic receipts. This revision introduces the AE:// URI
scheme, namespace derivation rules, DNS-based ownership verification,
payment scheme extensions, DDoS mitigation via dynamic session
tokens, and a privacy model requiring no identity disclosure. A
reference implementation serving 1,800,000 agents with zero per-agent
fees is live at a2a.agentir.com.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Spink Expires 24 November 2026 [Page 1]
Internet-Draft AEPP May 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. AE:// URI Scheme . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Namespace Derivation Rules . . . . . . . . . . . . . . . 4
3.2. DNS Ownership Verification . . . . . . . . . . . . . . . 5
3.3. Namespace Registration . . . . . . . . . . . . . . . . . 5
3.4. AE:// Resolution . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Phase 1 — Discovery . . . . . . . . . . . . . . . . . . . . . 7
5.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Phase 2 — Payment . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Payment Schemes . . . . . . . . . . . . . . . . . . . . . 7
6.2. Reference Payment Implementation . . . . . . . . . . . . 8
6.3. Autonomous Payment Example . . . . . . . . . . . . . . . 8
6.4. Protocol Fee . . . . . . . . . . . . . . . . . . . . . . 8
7. Phase 3 — Execution . . . . . . . . . . . . . . . . . . . . . 9
7.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Payment Verification . . . . . . . . . . . . . . . . . . 9
7.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Universal Clip . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Supported Input Protocols . . . . . . . . . . . . . . . . 10
8.2. Registration . . . . . . . . . . . . . . . . . . . . . . 11
8.3. WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. DDoS Mitigation . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Economic Protection . . . . . . . . . . . . . . . . . . . 11
9.2. Dynamic Session Tokens . . . . . . . . . . . . . . . . . 12
10. Privacy Model . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 13
12. Relationship to Existing Standards . . . . . . . . . . . . . 13
12.1. ANS — Agent Name Service . . . . . . . . . . . . . . . . 13
12.2. DNS-AID . . . . . . . . . . . . . . . . . . . . . . . . 14
12.3. W3C DID . . . . . . . . . . . . . . . . . . . . . . . . 14
12.4. x402 and L402 . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14. Fee Model Principles . . . . . . . . . . . . . . . . . . . . 15
15. Reference Implementation . . . . . . . . . . . . . . . . . . 15
Spink Expires 24 November 2026 [Page 2]
Internet-Draft AEPP May 2026
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
16.1. AE URI Scheme Registration . . . . . . . . . . . . . . . 16
16.2. HTTP Header Field Registration . . . . . . . . . . . . . 16
16.3. Well-Known URI Registration . . . . . . . . . . . . . . 17
16.4. AEPP Payment Scheme Registry . . . . . . . . . . . . . . 18
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The emergence of AI agent naming and discovery standards including
ANS, DNS-AID, agent://, ai:// and mcp:// has established mechanisms
for agent identity and discovery. However, none of these standards
define how to:
a. Execute a task against a discovered agent
b. Pay for agent execution in a standardized way
c. Verify payment cryptographically before execution
d. Receive a verifiable execution receipt
e. Prevent replay attacks on payment transactions
f. Express agent pricing in machine-readable form
g. Route payment directly to agent operators
AEPP fills this gap. Existing agent standards including ANS and DNS-
AID establish agent identity and discovery but do not define agent
pricing, payment destination, payment protocol, payment verification,
execution receipts, or replay attack prevention. An agent that can
be discovered but not paid for represents incomplete infrastructure.
AEPP provides the missing commercial layer that transforms agent
discovery into agent execution.
This revision introduces the AE:// URI scheme as the canonical identifier for agent execution endpoints, namespace derivation rules anchored to the Domain Name System, DNS-based ownership verification requiring no additional certificates or identity disclosure, payment scheme extensions including free discovery, fiat on-ramp credits, and native on-chain payment, DDoS mitigation via economic barriers and dynamic session tokens, and a privacy model that requires no personal identity information from namespace holders. AEPP is designed to be:
* Fee-free per registration — no per-agent naming or registration
fees
* Open — any agent network may implement AEPP
* Federated — no central execution authority
Spink Expires 24 November 2026 [Page 3]
Internet-Draft AEPP May 2026
* Verifiable — all payments cryptographically verified on-chain
* Interoperable — works with all existing agent standards
* Privacy-preserving — no identity disclosure required
* DDoS-resistant — economic and technical barriers to abuse
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Agent: An autonomous software service that accepts tasks, processes them, and returns results. Executor: The client initiating an agent task execution. Namespace: A short identifier derived from a domain name that uniquely identifies an agent operator within the AE:// URI scheme. Namespace Holder: The entity that controls the DNS zone for the domain from which a namespace is derived. Payment Challenge: A machine-readable payment requirement returned by the agent endpoint before execution. Payment Scheme: A supported payment method declared in the payment challenge. Defined schemes include x402, credits, and free. Execution Receipt: A cryptographically verifiable record of task completion and payment. Replay Protection: Enforcement that each payment transaction may only be used once for agent execution. Session Token: A single-use cryptographically random identifier appended to execution endpoints to prevent targeted DDoS.
3. AE:// URI Scheme
AEPP defines the AE:// URI scheme as the canonical identifier for agent execution endpoints on the agentic internet. The AE:// scheme provides human-readable, portable, and verifiable agent addresses that resolve to AEPP execution endpoints. AE:// URI syntax: AE://{capability}.{namespace} Examples: AE://legal-compliance.example AE://oncology.pubmed AE://weather-forecast.accuweather AE://code-review.github AE://tax-guidance.hmrc.gov.uk AE:// URIs MUST NOT include version numbers. Agent versioning is handled at the endpoint level. AE:// URIs are permanent and stable. Integrations built against an AE:// URI MUST NOT break due to agent version changes.
3.1. Namespace Derivation Rules
AE:// namespaces are derived from domain ownership according to the following rules: Rule 1 — .com registrant receives the clean short namespace:
example.com -> namespace: "example" URI: AE://capability.example
Rule 2 All other TLDs retain their TLD as a qualifier:
example.co.uk -> namespace: "example.co.uk" URI:
AE://capability.example.co.uk
example.dev -> namespace: "example.dev" URI:
AE://capability.example.dev
Rule 3 — Government and institutional TLDs receive sovereign
namespace rights:
hmrc.gov.uk -> namespace: "hmrc.gov.uk" URI: AE://tax-guidance.hmrc.gov.uk
europa.eu -> namespace: "europa.eu"
URI: AE://regulation.europa.eu
Spink Expires 24 November 2026 [Page 4]
Internet-Draft AEPP May 2026
Rule 4 — Absolute .com Sovereignty: The clean, short namespace is
strictly and permanently reserved for the .com top-level domain
registrant. No other TLD can ever claim, intercept, or inherit the
base short namespace, regardless of registration timelines or
operational status. All non-.com domains MUST preserve their fully
qualified TLD extension in the namespace string as outlined in Rule
2.
Rule 5 — First verified claim wins permanently within that specific
zone. No namespace configuration MAY be altered or transferred
without valid cryptographic proof of DNS zone control matching the
precise domain rule mapping.
This design leverages the existing Domain Name System and ICANN root
zone management as the trust anchor. No additional registry,
certificate authority, or verification service is required beyond
standard DNS TXT record verification. The security model is
equivalent to the security of DNS itself.
3.2. DNS Ownership Verification
Namespace holders MUST add a DNS TXT record to prove domain
ownership. This single record is sufficient proof. No additional
certificates, keys, or validation steps are required.
Record name: _ae.{domain} Record type: TXT Minimum value: "v=ae1" Optional fields within the TXT record value: endpoint={url} Agent execution endpoint URL capability={text} One-line capability description wallet={address} Payment wallet address Example minimal record:
_ae.example.com TXT "v=ae1" Example full record: _ae.example.com TXT "v=ae1 endpoint=https://a2a.example.com capability=specialist-agent-network"
To add this TXT record, the operator must have DNS write access to
the domain. DNS write access requires registrar credentials.
Registrar access is controlled by ICANN-accredited domain
registration. Therefore, possession of a valid _ae TXT record
constitutes proof of domain ownership equivalent to the security of
the ICANN registration chain.
AEPP MUST NOT require personal identity information, contact details,
organizational information, KYC, or AML verification for namespace
registration. Identity disclosure is at the sole discretion of the
namespace holder.
3.3. Namespace Registration
Operators register a namespace by submitting a POST request to an
AEPP-compliant registry:
POST https://a2a.example.com/ae/register Content-Type: application/json { "namespace": "example", "domain": "example.com", "endpoint": "https://a2a.example.com" }
Spink Expires 24 November 2026 [Page 5]
Internet-Draft AEPP May 2026
The registry MUST verify the _ae DNS TXT record before confirming
registration. Namespace registration is first-come first-served
among verified domain owners. Implementations MAY charge a one-time
namespace registration fee not to exceed 0.01 USDC to prevent abuse.
Per-agent registration fees are prohibited per the fee structures
defined in this architecture.
3.4. AE:// Resolution
AE:// URIs resolve to AEPP execution endpoints via the following chain: Step 1 — Extract namespace from AE:// URI:
Step 1 AE://legal-compliance.example -> namespace: example
Step 2 DNS lookup of namespace resolver: _ae.example.com TXT ->
endpoint: https://a2a.example.com
Step 3 Query AEPP resolver with full URI: GET
https://a2a.example.com/ae/resolve ?uri=AE://legal-
compliance.example
Step 3.5 (Static Fallback) — If the dynamic lookup registry endpoint
times out or returns an unresolvable routing exception, the resolving
client MUST fall back to a direct, authenticated static GET request
querying the root domain's well-known path directory at:
https://{namespace-domain}/.well-known/aepp.json
Step 4 — Resolver returns agent card:
{ "did": "did:web:a2a.example.com:legal-compliance-A3F9B2", "endpoint": "https://a2a.example.com/?id=legal-compliance-A3F9B2", "capability": "legal compliance analysis", "payment": { "scheme": "x402", "amount": "25000", "asset": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913", "network": "eip155:8453" }, "ae": "AEPP/1.0" } Step 5 — Caller proceeds with AEPP three-phase execution.
Implementations MAY cache resolution results. Cached results MUST be
revalidated against DNS within 3600 seconds.
4. Protocol Overview
AEPP defines a three-phase execution model:
Phase 1 — DISCOVERY
Client sends GET to agent endpoint Agent returns 402 Payment
Required + payment challenge Challenge lists all supported payment
schemes
Phase 2 — PAYMENT
Client selects a payment scheme from the challenge Client satisfies
payment requirement Client obtains payment proof
Spink Expires 24 November 2026 [Page 6]
Internet-Draft AEPP May 2026
Phase 3 — EXECUTION
Client sends POST with task + payment proof + scheme identifier
Agent verifies payment Agent executes task Agent returns result +
execution receipt
5. Phase 1 — Discovery
5.1. Request
GET https://{agent-endpoint}/?id={agent_id} Accept: application/json
5.2. Response
The agent MUST return HTTP 402 Payment Required with a payment
challenge listing all supported payment schemes.
HTTP/1.1 402 Payment Required Content-Type: application/json PAYMENT-REQUIRED: {base64-encoded-challenge} WWW-Authenticate: L402 invoice="{wallet}", price="{amount}" X-L402-Service-DID: did:web:{namespace}:{agent_id} { "x402Version": 2, "error": "Payment required", "resource": { "url": "https://{endpoint}/?id={agent_id}", "description": "{agent capability}", "mimeType": "application/json" }, "payment_schemes": [ { "scheme": "free", "limit": "discovery_only", "note": "Returns agent card and pricing. No execution." }, { "scheme": "x402", "network": "eip155:8453", "amount": "25000", "asset": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913", "payTo": "{agent-wallet-address}", "maxTimeoutSeconds": 60, "note": "Pay 0.025 USDC on Base Mainnet" }, { "scheme": "credits", "endpoint": "https://{credits-provider}", "note": "Purchase credits with credit card" } ], "agent": { "id": "{agent_id}", "name": "{agent name}", "did": "did:web:{namespace}:{agent_id}", "ae_uri": "AE://{capability}.{namespace}", "price_usdc": 0.025 } }
AEPP implementations MUST support the free discovery scheme. AEPP
implementations SHOULD support at least one execution scheme.
6. Phase 2 — Payment
6.1. Payment Schemes
AEPP defines three base payment schemes. Additional schemes MAY be
registered via IANA extension rules.
free:
Discovery and capability inspection only. No task execution. No
payment required. Callers using the free scheme receive the agent
card, supported payment schemes, pricing, and DID. The free
scheme MUST be supported by all AEPP implementations.
x402:
Native on-chain payment per the x402 protocol (x402.org).
Supports EVM-compatible chains, Solana, and traditional payment
method extensions. The reference implementation uses USDC on Base
Mainnet (eip155:8453). Full task execution with cryptographic on-
chain receipt.
Spink Expires 24 November 2026 [Page 7]
Internet-Draft AEPP May 2026
credits:
Managed fiat payment via a credit system. Credits are purchased
via traditional payment methods (credit card, bank transfer) and
redeemed for agent execution. Managed payment providers MAY
accept traditional payment methods and convert them to
x402-compatible payments internally, provided the agent receives
verified payment and a valid AEPP receipt is issued. Full task
execution.
The caller MUST indicate the chosen scheme via the X-Payment-Scheme
header in the execution request. If omitted the server defaults to
x402.
AEPP payment fees are percentage-based, not fixed. This enables any
price point from micro-payments to enterprise contracts on identical
payment rails. The fee model scales with delivered value.
Managed payment implementations MAY offer fiat-to-x402 conversion
enabling traditional payment users to participate in the AEPP
ecosystem. Users MAY convert accumulated credits to on-chain USDC at
any time, taking direct custody of funds.
6.2. Reference Payment Implementation
Network: Base Mainnet (eip155:8453) Currency: USDC Contract: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 Amount: As specified in payment challenge Method: ERC-20 transfer to agent wallet address Proof: Transaction hash from payment network Split: Atomic split via smart contract (PingSplitter pattern)
The PingSplitter pattern — where a treasury orchestrator triggers
atomic USDC splits via smart contract — is the reference
implementation for AEPP fee collection. The payment transaction hash
serves as both payment proof and split trigger. Gas fees for the
split are paid by the orchestrating party, not the end user. The
split amount is configurable as a percentage, not a fixed value,
enabling any price point.
6.3. Autonomous Payment Example
// Read payment details from challenge const challenge = JSON.parse( Buffer.from( response.headers.get("PAYMENT-REQUIRED"), "base64" ).toString() ); // Select payment scheme const scheme = challenge.payment_schemes.find( s => s.scheme === "x402" ); const { payTo, amount, asset } = scheme; // Sign and broadcast payment (viem example) const txHash = await walletClient.writeContract({ address: asset, abi: [{ name: "transfer", type: "function", inputs: [ { name: "to", type: "address" }, { name: "amount", type: "uint256" } ] }], functionName: "transfer", args: [payTo, BigInt(amount)] });
6.4. Protocol Fee
AEPP implementations MAY collect a protocol sustainability fee not to
exceed 0.4% per execution (approximately 0.0001 USDC on a 0.025 USDC
task). This fee MUST be:
* Percentage-based, not fixed
* Disclosed in the agent card and execution receipt
Spink Expires 24 November 2026 [Page 8]
Internet-Draft AEPP May 2026
* Collected via atomic smart contract split, not post-execution
sweep
* Never applied to the free discovery scheme
Protocol fee collection MUST be implemented via smart contract to
eliminate trust requirements. The fee split is immutable and
transparent. Anyone may verify the split parameters on-chain.
Registration MUST remain free regardless of protocol fee collection.
7. Phase 3 — Execution
7.1. Request
POST https://{agent-endpoint}/?id={agent_id}&s={session-token} Content-Type: application/json X-Payment-Hash: {transaction-hash} X-Payment-Scheme: {scheme} { "prompt": "task description or question" }
The session token (s= parameter) is a single-use cryptographically
random identifier issued per payment challenge. See Section 9.2 for
session token requirements.
The X-Payment-Scheme header MUST be included. Valid values are:
x402, credits, free. If omitted, the server MUST assume x402.
For the credits scheme, the X-Credit-Token header MUST be included in
place of X-Payment-Hash:
POST https://{agent-endpoint}/?id={agent_id}&s={session-token} Content-Type: application/json X-Payment-Scheme: credits X-Credit-Token: {credit-token}
For the free scheme, no payment header is required. The response
MUST be limited to the agent card only. No task execution occurs.
7.2. Payment Verification
Upon receiving the execution request the agent MUST:
1. Validate the session token exists, has a valid signature, and
has not expired
2. Delete the session token immediately to invalidate further edge
requests
3. Extract the payment proof from X-Payment-Hash or X-Credit-Token
4. Verify the payment scheme matches a supported scheme
5. For x402: verify the transaction exists on the designated
blockchain layer
Spink Expires 24 November 2026 [Page 9]
Internet-Draft AEPP May 2026
6. For x402: verify the transaction recipient matches the agent
wallet address
7. For x402: verify the transaction amount meets or exceeds the
required target amount
8. For x402: cryptographically verify that the transaction nonce or
customer signature binds directly to the single-use session
token, preventing network-wide replay attacks without requiring
exhaustive historical database checks
9. For x402: commit the verified transaction hash to a localized,
memory-cached bloom filter before initializing the execution
process
10. For credits: verify the credit token against the issuing managed
protocol authority
If any verification step fails the agent MUST return HTTP 403
Forbidden with a machine-readable reason code.
7.3. Response
HTTP/1.1 200 OK Content-Type: application/json { "id": "did:web:{namespace}:{agent_id}", "ae_uri": "AE://{capability}.{namespace}", "result": "{agent response}", "receipt": { "protocol": "AEPP/1.0", "scheme": "{payment-scheme}", "currency": "USDC", "amount": 0.025, "aepp_fee": 0.0001, "agent_received": 0.0249, "chain": "eip155:8453", "tx": "{transaction-hash}", "agent_did": "did:web:{namespace}:{agent_id}", "verified_at": "{ISO-8601-timestamp}" } }
8. Universal Clip
AEPP defines a Universal Clip registration mechanism that converts
any existing API or agent protocol to AEPP-compatible endpoints.
This eliminates per-agent registration fees by generating all
required metadata automatically.
8.1. Supported Input Protocols
* REST APIs — any JSON HTTP endpoint
* Model Context Protocol (MCP)
* OpenAI plugin manifest
* LangChain tools
* Google A2A protocol
* AE registered agents
* DNS-AID discovered agents
Spink Expires 24 November 2026 [Page 10]
Internet-Draft AEPP May 2026
8.2. Registration
Any service registers with a single POST request at zero cost:
POST https://{aepp-registry}/ae/register Content-Type: application/json { "name": "Service Name", "endpoint": "https://api.example.com", "capability": "service description", "type": "rest|mcp|openai|langchain|a2a|ae" } Response: { "did": "did:web:a2a.example.com:{agent_id}", "ae_uri": "AE://{capability}.{namespace}", "endpoint": "https://a2a.example.com/?id={agent_id}", "openapi": "https://a2a.example.com/openapi.json?id={agent_id}", "agent_card": "https://a2a.example.com/.well-known/agent.json?id={agent_id}", "whois": "https://a2a.example.com/whois?id={agent_id}", "aepp": "AEPP/1.0 ready", "fee": "0.00 per registration" }
Registration is free. AEPP implementations MUST NOT charge per-
agent registration fees. Revenue models MUST be based on execution,
not naming or registration.
8.3. WHOIS
Any registered agent is queryable via WHOIS:
GET https://{aepp-registry}/whois?id={agent_id} GET https://{aepp-registry}/whois?did=did:web:{namespace}:{id} GET https://{aepp-registry}/whois?uri=AE://{capability}.{namespace} Response includes: identity, AE:// URI, capability, pricing, hire history, execution stats, DNS-AID records, ANS compatibility, and W3C DID document.
Trust is established through execution history — hire count, session
completion rate, and endpoint uptime — rather than certificates. An
agent hired 10,000 times with consistent results is trustworthy
without PKI verification.
9. DDoS Mitigation
AEPP provides two complementary DDoS mitigation mechanisms: economic
barriers via the payment requirement, and technical barriers via
dynamic session tokens.
9.1. Economic Protection
All execution requests require verified payment. Mass requests are
therefore economically unviable. At the reference implementation
price of 0.025 USDC per execution:
1,000,000 requests = $25,000 cost to attacker 1,000,000 requests =
$25,000 revenue to network
DDoS attacks against AEPP endpoints are self-funding for the network.
Attackers bear the full economic cost of the attack. This economic
barrier applies inherently without additional configuration.
Free discovery requests (scheme: free) do not require payment and are
therefore subject to standard rate limiting. AEPP implementations
MUST apply rate limiting to free discovery requests. A limit of 100
free discovery requests per IP address per hour is RECOMMENDED.
Spink Expires 24 November 2026 [Page 11]
Internet-Draft AEPP May 2026
9.2. Dynamic Session Tokens
AEPP provides an additional technical DDoS barrier via dynamic
session tokens. Published AE:// addresses and agent_ids are static
and publicly known. Execution endpoints are dynamically generated
per payment challenge.
Session token requirements:
* MUST be cryptographically random (minimum 64 bits of entropy)
* MUST be single-use
* MUST expire within 60 seconds of issuance
* MUST be appended as a URL parameter (s=) to the execution endpoint
* MUST be deleted immediately upon first use
Session token generation example:
const token = crypto.randomUUID() .replace(/-/g, '') .substring(0, 16) .toUpperCase(); // endpoint: https://a2a.example.com/?id=legal-A3F9B2&s=7KX9MP2Q The published AE:// URI and agent_id resolve to known addresses. The session token appended to the execution endpoint changes with every payment challenge. An attacker with knowledge of the agent_id cannot target the execution endpoint directly. The session token is revealed only after payment verification, at which point it is already consumed.
10. Privacy Model
AEPP namespace registration requires only:
1. Proof of domain ownership via DNS TXT record
2. Agent endpoint URL
3. Agent capability description
AEPP MUST NOT require:
1. Personal identity information
2. Contact details
3. Organizational information
4. KYC or AML verification
5. Physical address
Spink Expires 24 November 2026 [Page 12]
Internet-Draft AEPP May 2026
Identity disclosure is at the sole discretion of the namespace
holder. AEPP is a technical protocol, not an identity service.
Identity verification, where required, is handled by the agent
operator at the application layer, not the protocol layer.
Trust is established through execution history rather than identity
documents. A namespace holder's reputation is built through
successful agent executions, not through certificate issuance.
This model contrasts with certificate-based trust systems that
require identity verification at registration. AEPP's position is
that technical proof of domain ownership is sufficient for namespace
assignment, and execution history is sufficient for trust
establishment.
Operators choosing to disclose identity information MAY include
additional fields in their DNS TXT record or agent WHOIS response.
This disclosure is voluntary and does not affect namespace assignment
or execution capability.
11. Replay Protection
AEPP implementations MUST enforce replay protection. Each payment
transaction hash MUST be accepted for execution exactly once.
Subsequent requests using the same transaction hash MUST be rejected
with HTTP 403 and the reason "TX_ALREADY_REDEEMED".
Implementations MUST maintain a persistent record of redeemed
transaction hashes. This record MUST survive service restarts.
Session tokens provide a second layer of replay protection
independent of transaction hash tracking. A consumed session token
cannot be reused regardless of payment status.
12. Relationship to Existing Standards
12.1. ANS — Agent Name Service
ANS provides agent identity and naming via DNS and PKI including TLS
certificate binding, TLSA DNS records, ACME-DNS-01 domain validation,
and Merkle tree transparency logging. ANS establishes who an agent
is and that it is cryptographically verified.
AEPP provides the execution and payment layer that ANS does not
define. ANS has no mechanism for expressing agent pricing, routing
payment to agent operators, verifying payment before execution, or
issuing execution receipts.
Spink Expires 24 November 2026 [Page 13]
Internet-Draft AEPP May 2026
An ANS-registered agent MAY expose an AEPP-compatible endpoint. AEPP
complements ANS without replacing it. The combination of ANS
identity verification and AEPP execution capability represents a
complete agent deployment stack.
12.2. DNS-AID
DNS-AID provides agent discovery via DNS records. AEPP provides
execution once an agent is discovered via DNS-AID. AEPP-registered
agents automatically generate DNS-AID compatible SVCB and TXT
records.
12.3. W3C DID
Every AEPP agent endpoint is associated with a W3C Decentralized
Identifier. The DID document is resolvable at the agent's .well-
known endpoint. AEPP execution receipts include the agent DID for
cryptographic attribution.
12.4. x402 and L402
AEPP builds on the HTTP 402 payment challenge pattern established by
x402 and L402. x402 is blockchain-agnostic and supports all EVM-
compatible chains, Solana, and traditional payment methods via
extension. AEPP extends x402 with agent-specific fields, payment
scheme enumeration, on-chain verification requirements, and execution
receipt standardization.
The PAYMENT-REQUIRED header and WWW-Authenticate header formats
follow x402 conventions.
13. Security Considerations
AEPP security is fundamentally bound to the DNS configuration of the
namespace holder. DNS spoofing or cache poisoning attacks could
allow an attacker to temporarily intercept resolution paths and
redirect endpoints to malicious resolvers. For this reason,
namespaces handling high-value execution tasks SHOULD enforce DNSSEC
validation within their zones.
On-chain transaction state tracking represents an operational edge
vulnerability if transaction monitoring falls out of synchronization
with the parent blockchain network. To eliminate network
partitioning edge errors, agents MUST verify transactions across
multi-node provider configurations before issuing final execution
states.
Spink Expires 24 November 2026 [Page 14]
Internet-Draft AEPP May 2026
14. Fee Model Principles
AEPP establishes the following principles for agent execution fee
models:
1. Registration MUST be free. No per-agent naming or registration
fees shall be required.
2. Discovery MUST be free. Agent search and capability lookup shall
not require payment.
3. Execution MAY require payment. Agents MAY charge for task
execution via the payment challenge mechanism.
4. Payment terms MUST be machine-readable. All fees MUST be
expressed in the payment challenge response in a format readable
by autonomous agents.
5. Payment MUST be direct. Payments MUST flow directly to the agent
operator without mandatory intermediary fees beyond network
transaction costs.
6. Protocol sustainability fee. AEPP implementations MAY collect a
micro-fee not exceeding 0.4% per execution to sustain protocol
infrastructure. This fee MUST be disclosed in the agent card and
execution receipt. The fee MUST be percentage-based.
Registration MUST remain free regardless.
7. Fees MUST be percentage-based. Fixed fees disadvantage small
transactions. Percentage-based fees scale with delivered value
and enable price points from $0.001 to $1,000+ on identical
infrastructure.
15. Reference Implementation
A production reference implementation of AEPP is live serving
1,800,000 agents at zero per-agent registration fee:
Spink Expires 24 November 2026 [Page 15]
Internet-Draft AEPP May 2026
Gateway: https://a2a.agentir.com
Registration: https://a2a.agentir.com/ae/register
Resolution: https://a2a.agentir.com/ae/resolve
WHOIS: https://a2a.agentir.com/whois
OpenAPI: https://a2a.agentir.com/openapi.json
Discovery: https://a2a.agentir.com/.well-known/ai-plugin.json
Well-Known: https://a2a.agentir.com/.well-known/aepp
Search: https://a2a.agentir.com/search?q={query}
CLI: npx agentir (npm registry)
Fleet size: 1,800,000 agents
Payment: USDC on Base Mainnet (eip155:8453)
Registration: Free
Per-agent fee: $0.00
The implementation demonstrates all AEPP phases including AE:// URI
resolution, Universal Clip translation, on-chain payment verification
via PingSplitter atomic splits, replay protection, W3C DID per agent,
ANS and DNS-AID compatibility, semantic vector search, dynamic
session tokens, and persistent cross-device agent memory vault layer.
16. IANA Considerations
This document makes the following requests to IANA.
16.1. AE URI Scheme Registration
This document requests provisional registration of the "AE" URI
scheme in the IANA URI Schemes registry per RFC 7595.
URI scheme name: AE
Status: Provisional
URI scheme syntax: AE://{capability}.{namespace}
URI scheme semantics: Identifies agent execution endpoints on the
agentic internet.
Applications: AI agent execution, autonomous agent payment,
agent-to-agent communication
Contact: support@agentir.com
References: This document
16.2. HTTP Header Field Registration
This document requests registration of the following HTTP header
fields in the IANA Message Headers registry:
Spink Expires 24 November 2026 [Page 16]
Internet-Draft AEPP May 2026
Header field name: PAYMENT-REQUIRED
Applicable protocol: HTTP
Status: Provisional
Specification: This document, Section 5.2
Description: Base64-encoded AEPP payment challenge.
Header field name: X-Payment-Hash
Applicable protocol: HTTP
Status: Provisional
Specification: This document, Section 7.1
Description: Cryptographic transaction hash proving on-chain
payment prior to agent task execution.
Header field name: X-Payment-Scheme
Applicable protocol: HTTP
Status: Provisional
Specification: This document, Section 7.1
Description: Payment scheme used. Values: x402, credits, free.
Header field name: X-Credit-Token
Applicable protocol: HTTP
Status: Provisional
Specification: This document, Section 7.1
Description: Credit token for the credits payment scheme.
Header field name: X-L402-Service-DID
Applicable protocol: HTTP
Status: Provisional
Specification: This document, Section 5.2
Description: W3C DID of the agent service endpoint.
16.3. Well-Known URI Registration
This document requests registration of the following Well-Known URI
in the IANA Well-Known URIs registry per RFC 8615:
URI suffix: aepp
Change controller: IETF
Specification: This document
Related information: Returns AEPP capability document including
supported payment schemes, fleet size, AE://
namespace, and execution endpoints.
Spink Expires 24 November 2026 [Page 17]
Internet-Draft AEPP May 2026
16.4. AEPP Payment Scheme Registry
This document requests creation of a new IANA registry titled "AEPP
Payment Scheme Extensions" with the following registration
procedures: First Come First Served for provisional entries;
Specification Required for permanent entries.
Initial registered entries:
x402:
HTTP 402 payment protocol as defined at https://x402.org.
Supports EVM-compatible chains, Solana, and traditional payment
method extensions.
credits:
Managed credit system with fiat on-ramp. Credits purchased via
traditional payment methods and redeemed for agent execution.
free:
Discovery-only scheme. No payment required. Returns agent card
and pricing. No task execution.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7595] Thaler, D., "Guidelines and Registration Procedures for
URI Schemes", BCP 35, RFC 7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", STD 97, RFC 9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
17.2. Informative References
[A2A] Agentir Network, "Agent Execution and Payment Protocol
Reference Implementation", 2026,
<https://a2a.agentir.com>.
Spink Expires 24 November 2026 [Page 18]
Internet-Draft AEPP May 2026
[AEPP-CLI] Agentir Network, "Agentir CLI — AEPP Reference Client",
2026, <https://www.npmjs.com/package/agentir>.
[ANS] GoDaddy Inc., "Agent Name Service", May 2026.
[DNS-AID] Mozley, J. and N. Williams, "DNS for AI Discovery", March
2026, <https://datatracker.ietf.org/doc/draft-
mozleywilliams-dnsop-dnsaid>.
[W3C-DID] W3C, "Decentralized Identifiers (DIDs) v1.0", 2022,
<https://www.w3.org/TR/did-core/>.
[x402] x402.org, "HTTP 402 Payment Protocol", 2026,
<https://x402.org>.
Author's Address
E. Spink
Agentir Network
Email: support@agentir.com
URI: https://agentir.com
Spink Expires 24 November 2026 [Page 19]