Agent Execution and Payment Protocol (AEPP)

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:

Execute a task against a discovered agent
Pay for agent execution in a standardized way
Verify payment cryptographically before execution
Receive a verifiable execution receipt
Prevent replay attacks on payment transactions
Express agent pricing in machine-readable form
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.

Fee-free per registration — no per-agent naming or registration fees
Open — any agent network may implement AEPP
Federated — no central execution authority
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

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.

AE:// URI Scheme

Namespace Derivation Rules

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: namespace: "hmrc.gov.uk" URI: AE://tax-guidance.hmrc.gov.uk ]]>

europa.eu

-> namespace: "europa.eu" URI: AE://regulation.europa.eu

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.

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

Namespace Registration Operators register a namespace by submitting a POST request to an AEPP-compliant registry: 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.

AE:// Resolution

Step 1: AE://legal-compliance.example -> namespace: example
Step 2: DNS lookup of namespace resolver: _ae.example.com TXT -> endpoint:
Step 3: Query AEPP resolver with full URI: GET ?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: Implementations MAY cache resolution results. Cached results MUST be revalidated against DNS within 3600 seconds.

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
Phase 3 — EXECUTION: Client sends POST with task + payment proof + scheme identifier Agent verifies payment Agent executes task Agent returns result + execution receipt

Phase 1 — Discovery

Request

Response The agent MUST return HTTP 402 Payment Required with a payment challenge listing all supported payment schemes. AEPP implementations MUST support the free discovery scheme. AEPP implementations SHOULD support at least one execution scheme.

Phase 2 — Payment

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

Reference Payment Implementation 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.

Autonomous Payment Example 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)] }); ]]>

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

Phase 3 — Execution

Request 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: For the free scheme, no payment header is required. The response MUST be limited to the agent card only. No task execution occurs.

Payment Verification Upon receiving the execution request the agent MUST:

Validate the session token exists, has a valid signature, and has not expired
Delete the session token immediately to invalidate further edge requests
Extract the payment proof from X-Payment-Hash or X-Credit-Token
Verify the payment scheme matches a supported scheme
For x402: verify the transaction exists on the designated blockchain layer
For x402: verify the transaction recipient matches the agent wallet address
For x402: verify the transaction amount meets or exceeds the required target amount
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
For x402: commit the verified transaction hash to a localized, memory-cached bloom filter before initializing the execution process
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.

Response

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.

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

Registration Any service registers with a single POST request at zero cost: Registration is free. AEPP implementations MUST NOT charge per- agent registration fees. Revenue models MUST be based on execution, not naming or registration.

WHOIS Any registered agent is queryable via WHOIS: 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.

DDoS Mitigation AEPP provides two complementary DDoS mitigation mechanisms: economic barriers via the payment requirement, and technical barriers via dynamic session tokens.

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.

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:

Privacy Model AEPP namespace registration requires only:

Proof of domain ownership via DNS TXT record
Agent endpoint URL
Agent capability description

AEPP MUST NOT require:

Personal identity information
Contact details
Organizational information
KYC or AML verification
Physical address

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.

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.

Relationship to Existing Standards

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

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.

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.

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.

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.

IANA Considerations This document requests IANA to register the provisional 'ae' URI scheme in accordance with RFC 7595 guidelines. Scheme syntax and characteristics are defined fully in Section 3 of this document. No central registration authority or administrative management entity is requested, as operations are completely federated via the standard internet Domain Name System.