Payproof Protocol Whitepaper

Abstract

Payproof is a permissionless payment protocol for autonomous AI agent commerce - trustless, atomic, and built for machine speed. It uses a novel cryptographic construction where the secret that unlocks escrowed payment simultaneously serves as the encryption key for the purchased data. This creates a trustless exchange where the merchant can only receive payment by revealing the decryption key on-chain, and the agent can only obtain the decryption key after the merchant claims the escrow. The protocol defines a 7-state machine with two independent timelocks, a neutral treasury mechanism for dispute resolution, and a game-theoretic framework in which no rational actor can profit by defecting. Payproof extends the x402 HTTP payment standard with its direct scheme, replacing trusted facilitators with cryptographic atomicity. The protocol is chain-agnostic by design, with a reference implementation deployed on EVM (Circle Arc) and architecture ready for Solana. All escrow operations use cryptographic hashes for cross-chain compatibility.

1. Introduction

Intelligence is approaching zero marginal cost. As large language models become commoditized, AI agents are emerging as autonomous economic actors - purchasing data, consuming APIs, paying for compute, and transacting with other agents and services without human intervention. This shift demands a payment infrastructure fundamentally different from anything built for human commerce.

The structural problem is trust. When a human buys a product online and the merchant fails to deliver, the human can call customer support, file a chargeback, or leave a negative review. An AI agent has none of these recourses. Agents operate programmatically, at machine speed, across thousands of transactions per hour. They cannot navigate dispute resolution flows designed for humans. They need cryptographic guarantees, not terms of service.

The prevailing approach to machine-to-machine payments is the x402 protocol, introduced by Coinbase. x402 defines a standard HTTP flow: a server returns HTTP 402 Payment Required with structured payment requirements, the client signs a payment authorization, retries with the payment proof, and receives the resource. The standard's exact scheme uses ERC-20 Permit2 signatures - the agent signs an allowance off-chain, a facilitator broadcasts the transaction, and the server delivers data. This is elegant in its simplicity but fundamentally not atomic. The agent pays before receiving data. The facilitator must be trusted not to steal, censor, or front-run. If the merchant delivers garbage or nothing at all, the agent has no recourse.

Payproof addresses this gap. We use x402 as the transport layer - the 402 response, the payment headers, the client/server negotiation - but for the direct scheme, we replace the trust-based facilitator with cryptographic atomicity. The escrow secret that unlocks payment is the encryption key for the data. This construction makes payment and data delivery inseparable: the merchant reveals the key to get paid, and the agent obtains the key to decrypt. No facilitator. No trust. No recourse needed, because neither party can cheat.

This whitepaper specifies the Payproof protocol in full: the state machine, the cryptographic construction, the game-theoretic guarantees, the failure modes, and the SDK architecture that reduces the 14-step protocol to a single fetch() call for agent developers.

2. Protocol Design

2.1 The 7-State Machine

The Payproof escrow is a deterministic finite automaton with seven states and six transitions. Every lock begins in the Empty state and terminates in exactly one of three terminal states: Claimed (successful exchange), Refunded (merchant non-responsive), or Treasury (dispute). State can only move forward - there are no rollback transitions except the refund path from Locked.

2.2 State Definitions

2.3 Transition Table

2.4 The Two-Timelock System

The protocol uses two independent timelocks to bound commitment for both parties. The primary timelock is set when the agent calls lock() and defaults to 300 seconds (5 minutes). This is the overall deadline: if the merchant never posts their data hash, the agent can reclaim funds after this period. The timelock protects the agent from unresponsive merchants.

The secondary dataDeadline is set dynamically when the merchant calls postDataHash(), computed as block.timestamp + confirmation window where the confirmation window = 120s. This gives the agent 2 minutes to verify the encrypted data and submit confirmReceipt(). If the agent fails to confirm - whether due to a crash, network failure, or deliberate non-confirmation - funds are sent to the neutral treasury rather than back to the agent. The dataDeadline protects the merchant from agents who receive data but refuse to confirm.

2.5 Lock Structure

Every conforming implementation must store the following fields per lock. All fields are publicly readable for cross-party verification.

3. Cryptographic Construction

3.1 The Secret-as-Key Insight

The central cryptographic innovation of Payproof is the dual use of the escrow secret. In a standard atomic escrow, the secret is a random value whose hash serves as a commitment - the party who knows the secret can unlock escrowed funds by revealing it on-chain. Payproof extends this by using the same 32-byte secret as the symmetric encryption key for the data being purchased.

This creates an elegant coupling: the merchant generates a cryptographically random 32-byte secret, computes commitment = hash(secret), and shares the commitment with the agent in the 402 response. The agent locks funds against this commitment. The merchant then encrypts the data using the secret as the encryption key and commits the ciphertext hash on-chain. To get paid, the merchant must call claim(secret) - revealing the secret in a public on-chain event. The agent reads this event and uses the secret to decrypt the data.

The atomicity guarantee follows from the structure: the merchant cannot receive payment without revealing the decryption key, and the agent cannot obtain the decryption key without the merchant claiming payment. There is no sequence of actions by either party that breaks this invariant.

3.2 Cross-Chain Hash Compatibility

All hash operations in Payproof use a universally supported cryptographic hash function, deliberately chosen for cross-chain compatibility rather than any chain-native alternative. The chosen hash is available on every target blockchain - including EVM chains, Solana, Cosmos, and Bitcoin. By using a chain-agnostic hash, the same commitment can be verified on any chain, enabling future cross-chain atomic swaps where an agent on one chain pays a merchant on another.

Three hash operations are defined in the protocol:

• Commitment: hash(secret) - the escrow commitment, verified on-chain during claim()
• dataHash: hash(ciphertext_bytes) - the merchant's commitment to the encrypted data
• receiptHash: agent re-computes hash(ciphertext_bytes) to confirm receipt - must match dataHash or the transaction reverts

The escrow contract uses standard cryptographic hash operations available on all target chains.

3.3 Encryption Parameters

The protocol uses authenticated encryption for the data payload. Authenticated encryption provides both confidentiality and integrity verification in a single pass, which is critical: the agent must be able to verify that decryption succeeded (the auth tag validates) before considering the data authentic.

3.4 EncryptedPayload Format

The merchant returns the encrypted data to the agent as a structured payload over HTTP. The agent persists this payload locally until the secret is revealed on-chain.

The encrypted payload contains the ciphertext, a nonce, an authentication tag, and a hash of the ciphertext for on-chain verification.

3.5 Data Commitment Scheme

The data commitment scheme ensures the merchant cannot swap encrypted data after committing. The merchant computes dataHash = hash(ciphertext_bytes) and posts this hash on-chain via postDataHash(). The agent independently computes receiptHash = hash(ciphertext_bytes) from the received encrypted payload. The confirmReceipt() function enforces receiptHash == dataHash on-chain - if the merchant posted a hash for different data than what was delivered, the confirmation transaction reverts. This binds the on-chain commitment to the actual bytes delivered to the agent.

4. Game Theory

4.1 Outcome Matrix

The protocol defines five canonical scenarios covering all meaningful combinations of merchant and agent behavior. In every scenario, no rational actor can profit by defecting from the cooperative strategy.

4.2 Cooperation Incentives

The protocol creates strong incentives for cooperation through three mechanisms:

Merchant incentive to deliver real data: The merchant only receives payment if the agent confirms receipt. Delivering garbage or nothing results in non-confirmation, sending funds to treasury. The merchant loses both the potential revenue and the compute cost of serving the request. Rational merchants always deliver genuine data.

Agent incentive to confirm valid data: If the agent receives valid data but refuses to confirm, the funds go to treasury - not back to the agent. Strategic non-confirmation yields no benefit to the agent: they lose the payment amount and still cannot decrypt without the secret. Rational agents always confirm valid data.

Neither party profits from defection: In every non-cooperative outcome, the defecting party is worse off than in the cooperative outcome. The merchant who ghosts earns nothing. The agent who refuses to confirm loses the payment. The treasury mechanism ensures that in any dispute, neither party captures the funds - eliminating the economic incentive for adversarial behavior entirely.

4.3 Treasury as Neutral Resolution

The treasury address is set at contract deployment and is immutable - it cannot be changed after deployment and has no admin functions. When a dispute is unresolvable (merchant posted data but agent did not confirm), the sendToTreasury() function transfers the escrowed funds to the treasury. This function is callable by anyone after the dataDeadline expires - it acts as a permissionless crank. The treasury serves as a Schelling point: both parties know that defection leads to neither party getting the funds, making cooperation the dominant strategy in repeated games.

5. Protocol Flow

The complete protocol flow comprises 14 steps across three participants: the agent, the merchant, and the blockchain. In practice, the SDK abstracts all 14 steps - the agent developer calls fetch() and receives plaintext data. The merchant developer returns data from a route handler and the middleware handles encryption, on-chain transactions, and claim. The typical happy-path execution completes in under 30 seconds.

5.1 Step-by-Step Walkthrough

Steps 1-2: Payment negotiation. The agent sends a standard HTTP GET request to the merchant's API endpoint. The merchant's middleware intercepts the request, detects that the route requires payment, and returns HTTP 402 Payment Required with structured PaymentRequirements following the x402 standard. These include the commitment (hash of the server-generated secret), the escrow contract address, the payment amount in atomic USDC units, the network identifier, and the protocol version.

Steps 3-4: Fund locking. The agent generates a random 32-byte lockId, approves the escrow contract for the required USDC amount (if not already approved), and calls lock() on the escrow contract with the commitment from the 402 response and a timelock of now + 300s. The USDC is transferred from the agent's wallet to the contract escrow.

Steps 5-6: Lock verification. The agent retries the original request with an X-PAYMENT header containing the lockId, network, and commitment. The merchant's middleware reads the lock from the blockchain and verifies: the recipient matches the merchant's address, the amount meets the price, the commitment matches the secret the merchant holds, and the timelock has sufficient remaining time (at least 120 seconds margin).

Steps 7-10: Encryption and commitment. The merchant's middleware calls the route handler to get the plaintext data, encrypts it using authenticated encryption with the secret as the key and a fresh random nonce, computes dataHash = hash(ciphertext), and posts this hash on-chain via postDataHash(). The lock transitions to DataPosted and the dataDeadline is set to now + 120s.

Step 11: Encrypted payload delivery. The merchant returns HTTP 200 with the EncryptedPayload (ciphertext, nonce, auth tag, data hash) and an x-payproof-encrypted: true header. The agent persists this payload in its local LockStore for durability.

Steps 12-13: Receipt confirmation. The agent independently computes receiptHash = hash(ciphertext) from the received encrypted data and calls confirmReceipt(lockId, receiptHash). The contract enforces receiptHash == dataHash - if they do not match, the transaction reverts. On success, the lock transitions to Confirmed.

Step 14: Claim and decryption. The merchant calls claim(lockId, secret). The contract verifies hash(secret) == commitment, transfers the escrowed USDC to the merchant, and emits a Claimed(lockId, secret) event. The agent reads this event from the blockchain, extracts the secret, and uses it as the encryption key to decrypt the stored EncryptedPayload. The plaintext data is now available.

6. Failure Modes & Recovery

The protocol is designed so that every failure scenario has a well-defined recovery path. No failure can result in permanent loss of funds - every lock eventually resolves to one of the three terminal states.

6.1 Failure Scenarios

1. Merchant never posts dataHash. The lock remains in Locked state. The agent calls refund() after the 300-second timelock expires, recovering the full escrow amount. The merchant may have crashed, experienced a network failure, or deliberately ghosted - regardless, the agent's funds are safe.

2. Agent never confirms receipt. The lock stays in DataPosted state. After the dataDeadline expires (120 seconds from data post), anyone can call sendToTreasury() to move funds to the neutral treasury. The agent does not receive a refund - this prevents strategic non-confirmation.

3. postDataHash transaction fails. The lock stays in Locked state. The server middleware retries the transaction. If it continues to fail, the agent refunds after the timelock. The encrypted data was prepared but the on-chain commitment could not be submitted.

4. confirmReceipt transaction fails. The lock stays in DataPosted state. The client SDK retries with gas estimation. If confirmation never succeeds, funds go to treasury after the deadline. The agent still has the encrypted payload persisted in LockStore for later decryption if the secret is revealed through other means.

5. Agent misses Claimed event. The lock transitioned to Claimed but the agent's watchForClaim() timed out. The secret is permanently available in on-chain event logs. The agent can replay event logs later and decrypt using the persisted EncryptedPayload.

6. Client disconnects mid-flow. The server detects the disconnect via AbortSignal. Recovery depends on the disconnect timing: before lock verification, no on-chain state changes exist; after verification but before postDataHash, the lock stays Locked and the agent refunds; after postDataHash, the treasury fallback applies.

6.2 Defense Layers

The protocol employs three defense layers. The first is the on-chain state machine itself: funds cannot be double-spent, each state transition is exclusive, timelocks ensure bounded commitment, and secret verification ensures the merchant can only claim with the real key. The second layer is SDK safety checks and retry logic: the server rejects locks with fewer than 120 seconds remaining on the timelock to prevent race conditions, the client estimates gas before submitting transactions, and event polling uses configurable intervals with timeout fallbacks. The third layer is the client-side LockStore, which persists lock state and encrypted payloads for offline decryption retry, lock status tracking, and automated refund sweeping.

6.3 Timing Safety Margins

The normal happy-path execution completes in approximately 25 seconds. Two safety boundaries protect against failure: the dataDeadline at 120 seconds (if data is posted but not confirmed, funds go to treasury) and the timelock at 300 seconds (if the merchant never responds, the agent can refund). These provide 10x and 20x safety margins respectively, ensuring transient network issues do not trigger premature refunds or treasury sweeps.

7. Multi-Chain Architecture

7.1 EVM Implementation

The reference EVM implementation is a compact Solidity escrow contract. It implements the full 7-state machine with the following security properties: checks-effects-interactions pattern prevents reentrancy, there are no admin functions (no owner, no pause, no upgrade on the core contract), the treasury address is immutable (set in the constructor), and the contract uses standard cryptographic hash operations available on all target chains. Token handling uses IERC20.transferFrom for escrow deposits and IERC20.transfer for payouts.

The contract stores a Lock struct per lock ID containing all 10 protocol fields. Six public functions implement the six transitions, and a getLock() view function enables cross-party verification. Each transition emits an event: Locked, DataPosted, ReceiptConfirmed, Claimed, Refunded, and SentToTreasury. The Claimed event is critical: it includes the secret, making the decryption key permanently available on-chain.

7.2 Chain-Agnostic Design

The protocol is chain-agnostic by construction. The use of a universally supported cryptographic hash (rather than chain-native hash functions) means the same commitment can be verified on any blockchain - including EVM chains, Solana, Cosmos chains, Bitcoin, and others. The state machine, game theory, and cryptographic construction are independent of the execution environment.

The primary deployment target is Circle's Arc chain, chosen for its USDC-native gas model. On Arc, agents only need USDC - no volatile gas token is required. Combined with sub-second finality, Arc makes micropayments practical: an agent can pay $0.001 for a weather data point without the gas fee exceeding the payment amount.

7.3 Solana Readiness

The SDK architecture includes a Solana client module with wallet management and escrow interaction primitives. A Solana program (Anchor) implementing the same 7-state machine is included in the repository. The chain-agnostic hash design ensures that a single commitment can span both EVM and Solana locks, enabling future cross-chain atomic swaps.

7.4 Protocol Registry for Upgrades

The protocol registry maps version numbers to escrow contract addresses, enabling protocol upgrades without breaking existing locks. The server includes the protocol version in the 402 response, and the client SDK checks version compatibility before locking funds. Each registry entry contains the contract address, an active flag, and a deployment timestamp. The registry is owner-controlled and deployed per chain.

The protocol registry maps version numbers to escrow contract addresses, enabling upgrades without breaking existing locks.

8. SDK & Developer Experience

8.1 Three Packages

The Payproof SDK is organized as a pnpm monorepo with three published packages:

• @payproof/contracts - shared types, ABIs, chain configurations, and the protocol state enum
• @payproof/client - agent-side SDK including x402 handling, EVM/Solana wallet management, escrow interaction, decryption, lock tracking, and auto-refund sweeping
• @payproof/server - merchant-side SDK including lock verification, data encryption, on-chain commitment, claim orchestration, secret management, and Next.js middleware adapter

8.2 Factory Pattern

Both the client and server SDKs use a factory pattern for initialization. The factories accept per-chain configuration and return a fully configured interface with all methods bound to the provided chain context.

// Agent - create a configured client
const client = createPayproofClient({
  evmPrivateKey: "0x...",
  escrowContractAddress: "0x...",
  rpcUrl: "https://rpc.testnet.arc.network",
});

// Merchant - create a configured server
const server = createPayproofServer({
  merchantEvmAddress: "0x...",
  merchantEvmPrivateKey: "0x...",
  escrowContractAddress: "0x...",
});

8.3 Middleware Architecture

The server SDK includes a createNextMiddleware() adapter that wraps Next.js API routes. The middleware intercepts incoming requests, checks for payment headers, returns 402 responses with payment requirements for unpaid requests, and orchestrates the full encrypted flow (verify, encrypt, postDataHash, return EncryptedPayload, claim) transparently. The route handler itself simply returns plaintext data - encryption and all on-chain operations are handled by the middleware.

8.4 Agent SDK Wraps fetch()

From the agent developer's perspective, the entire 14-step protocol is invisible. The client SDK provides a fetchWithPayment() function that wraps the standard fetch() API. The agent calls a URL, and the SDK handles the 402 negotiation, fund locking, receipt confirmation, claim watching, and decryption. The return value is a standard Response object with plaintext data.

// Agent: one line - gets plaintext back
const response = await fetchWithPayment(
  "https://api.example.com/weather"
);
const data = await response.json();

// Merchant: route handler returns data normally
export async function GET() {
  const weather = await getWeatherData();
  return Response.json(weather);
}
// Middleware handles everything else automatically

9. Competitive Analysis

9.1 x402 Scheme Comparison

The x402 protocol defines a standard for machine-to-machine payments over HTTP. Its exact scheme uses Permit2 signatures - the agent signs an off-chain allowance, a trusted facilitator broadcasts the transaction, and the server delivers data. Payproof supports the exact scheme for backward compatibility and introduces the direct scheme for trustless atomic exchange.

9.2 Relationship to Circle and Arc

Payproof builds on Circle's infrastructure rather than competing with it. USDC is the canonical payment token. Arc is the primary deployment chain, chosen for its USDC-native gas model which eliminates the need for a volatile gas token - making micropayments practical. Circle provides excellent monetary infrastructure (the asset, the chain, the settlement layer) but no atomicity layer for data-for-payment. Payproof adds the missing piece: the trustless protocol that makes USDC useful for autonomous agent commerce where delivery guarantees matter.

9.3 Payproof Extends x402

Payproof does not replace x402 - it extends it. The 402 response format, the payment header negotiation, and the client/server communication pattern all follow the x402 standard. Merchants and agents already using x402 can adopt Payproof's direct scheme incrementally, choosing trust-for-simplicity (exact) or cryptography-for-guarantees (direct) on a per-transaction basis. The SDK supports both schemes transparently - a single server can offer both to different clients, and a single client can pay via either depending on the merchant's requirements.

10. Roadmap

The protocol roadmap is organized in four phases, progressing from the current foundation through ecosystem growth to standardization.

Phase 1: Foundation (current). Full 7-state atomic escrow with authenticated encryption deployed on Arc Testnet. x402 exact scheme compatibility on Base Sepolia. Three SDK packages extracted and published. Reference marketplace application with AI agent integration, paywalled APIs, and multi-chain wallet management.

Phase 2: Ecosystem growth. Mainnet deployment on Arc. Atomic guarantees applied to the exact scheme (secret revelation on top of Permit2 facilitator flow). Onboarding tools including key generation CLI, balance tracking dashboard, and wallet setup wizard. Agent tool integrations for MCP (Claude), OpenAI function calling, and LlamaIndex.

Phase 3: Advanced capabilities. Smart contract-driven agentic facilitator replacing the x402.org trusted facilitator with permissionless, auditable on-chain verification. Opt-in data catalog for programmatic API discovery. On-chain reputation system derived from claim/refund/treasury ratios. Batch settlements for high-frequency micropayments via payment channels. Multi-token support with DEX integration for automatic token swaps.

Phase 4: Protocol standardization. Cross-chain atomic swaps using shared commitments across EVM and Solana. Subscription and streaming payment channels for real-time data feeds. Zero-knowledge privacy layer for shielded transaction amounts and anonymous agent identities. Formal specification of the Payproof protocol as an RFC-style extension to the x402 standard, with reference implementations in multiple languages and an interoperability testing suite.

References

1. x402 Protocol Specification. https://www.x402.org
2. Poon, J. and Dryja, T. "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments." 2016. Hash Time-Locked Contracts as the foundational primitive for trustless conditional payments.
3. NIST Special Publication 800-38D. "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC." 2007. NIST SP 800-38D
4. FIPS 180-4. "Secure Hash Standard (SHS)." SHA-256 specification used for all commitment and data hash operations. FIPS 180-4
5. ERC-20 Token Standard. OpenZeppelin implementation used for USDC token handling in escrow. EIP-20
6. Uniswap Labs. "Permit2." Signature-based token approval mechanism used by the x402 exact scheme.
7. Circle. "USDC: A Fully Collateralized US Dollar Stablecoin." The canonical payment token for all Payproof transactions. circle.com/usdc
8. Circle Arc. EVM-compatible chain with USDC-native gas, primary deployment target for Payproof. circle.com/arc
9. Solana Foundation. "Solana: A New Architecture for a High Performance Blockchain." Target chain for cross-chain escrow deployment via Anchor framework. Solana Whitepaper
10. Payproof Protocol Specification v1. Source code available on request.