A402: Trust-Minimized Payment Architecture

• A402 is a trust-minimized payment architecture that binds Web3 payments to Web2 services by enforcing atomic service execution, payment, and result delivery using TEEs and adaptor signatures.
• It employs Atomic Service Channels to guarantee that payment finalization occurs only when the requested service is correctly executed and the result is securely delivered.
• The design mitigates x402 limitations by integrating a TEE-based Liquidity Vault for off-chain state management and aggregated, low-cost on-chain settlements.

A402 is a trust-minimized payment architecture for binding Web 3.0 payments to Web 2.0 services in Machine-to-Machine commerce. It is presented as a response to the limitations of x402, an HTTP 402-based bridge whose centralized facilitator sequences payment, service execution, and response delivery but does not enforce end-to-end atomicity across execution, payment, and delivery. A402 introduces Atomic Service Channels (ASCs), integrates off-chain service execution into a payment channel state, uses TEE-assisted adaptor signatures so that payment is finalized if and only if the requested service is correctly executed and the corresponding result is delivered, and adds a TEE-based Liquidity Vault that privately manages ASC lifecycles and aggregates settlements into a single on-chain transaction (Li et al., 1 Mar 2026). A closely related security analysis of x402 uses “A402/x402” to denote the protocol family that revives HTTP 402 for agent-native micropayments and treats binding-focused improvements as necessary mitigations (Li et al., 12 May 2026).

1. Motivation and problem formulation

The motivating setting is autonomous AI agents invoking and paying for Web 2.0 services without pre-provisioned accounts or API keys. In this setting, low-latency, pay-per-request mechanisms require trust-minimized guarantees that payment is finalized if and only if the service is correctly executed and the result delivered (Li et al., 1 Mar 2026).

The problem statement is framed against x402. x402 is an HTTP 402-based bridge between Web 2.0 services and Web 3.0 payments that routes each request through a centralized facilitator who sequences payment, service execution, and response delivery. The architecture has three explicitly identified limitations. First, providers execute optimistically before payment finalization, while facilitators can broadcast payments without verifying execution; this breaks execution–payment binding. Second, x402’s payment-first workflow confirms on-chain before result delivery, so a malicious or failed provider can withhold results post-payment, violating fair exchange. Third, every request is an on-chain transaction, imposing high latency bounded by block confirmation, high fees at micropayment granularity, and public leakage of per-request interactions (Li et al., 1 Mar 2026).

A separate formal analysis of x402 characterizes the same design space as a cross-layer composition of synchronous HTTP authorization and asynchronous blockchain settlement. It models the protocol through Payment Requirements,

$$PR := \langle \text{resource\_id}, \text{amount}, \text{token}, \text{chain\_id}, \text{receiver}, \text{expiry}, \text{meta}\rangle,$$

and Payment Payload,

$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$

and identifies authorization soundness, payment–service correspondence, replay resistance, and facilitator $k$-atomicity as the central security properties (Li et al., 12 May 2026).

Within this problem setting, A402 targets Exec–Pay–Deliver atomicity directly. The design goal is that an exchange terminates in exactly one of two outcomes: success, where the vault obtains the result and the provider obtains the payment amount $\delta$; or abort, where the vault retains $\delta$ and the provider does not obtain $\delta$. Forbidden states occur only with negligible probability $\mathrm{negl}(\lambda)$ (Li et al., 1 Mar 2026).

2. System architecture and trust model

A402 comprises four roles: the client $C$, the vault $U$, the service provider $S$, and the blockchain $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$0. The client is the autonomous agent or user and delegates ASC management and request execution to the vault. The vault is a TEE-protected service that manages Atomic Service Channels, maintains ASC state in an enclave, forwards requests and results, performs atomic exchange, and can optionally run as a replicated TEE committee for availability. In “liquidity vault” mode, it pre-funds and aggregates multiple ASC settlements into one on-chain transaction. The service provider runs requested service code in its enclave and participates in adaptor-signature-based atomic exchange. The blockchain acts as the settlement and dispute resolution layer; on Ethereum, this is an ASC Manager contract, and on Bitcoin it is realized with Taproot/MAST scripts (Li et al., 1 Mar 2026).

The trust assumptions are explicit. A402 relies on integrity and confidentiality guarantees from modern TEEs such as AMD SEV-SNP and Intel TDX. Remote attestation binds public keys and execution measurements to approved code hashes. Side-channel and supply-chain attacks are out of scope, consistent with prior TEE-assisted designs. The blockchain is assumed to provide persistence and eventual inclusion (Li et al., 1 Mar 2026).

The x402 threat model examined in the companion security analysis is broader at the web/blockchain boundary. It includes a network adversary that can delay, reorder, drop, or replay HTTP traffic; a malicious client; a Byzantine facilitator; blockchain adversaries that exploit mempool replacement, front-running, or bounded reordering; and an honest-but-curious server in the core model. That analysis emphasizes that ordinary web middleware—proxies, caches, and loggers—enters the payment-security boundary when spendable payment material is carried through HTTP headers (Li et al., 12 May 2026).

A concise role decomposition is as follows.

Role	A402 function	Security relevance
Client $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$1	Delegates ASC management and request execution to $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$2	Origin of requests and payment authority
Vault $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$3	Manages ASC state in an enclave and performs atomic exchange	Enforces protocol logic and aggregation
Service provider $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$4	Executes requested service code in its enclave	Produces attested execution and encrypted result
Blockchain $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$5	Settlement and dispute resolution layer	Provides persistence and eventual inclusion

This architecture shifts the core coordination problem from a centralized facilitator to attested enclaves plus on-chain escape hatches. A plausible implication is that A402 treats the facilitator role not as a trusted coordinator but as a protocol component whose behavior is constrained by attestation, cryptographic binding, and unilateral close paths.

3. Atomic Service Channels and protocol state

An Atomic Service Channel with respect to blockchain $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$6 is defined as a tuple $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$7, where $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$8 is the channel state, $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$9 is the balance distribution, and $k$0 is the execution status. The basic operations are:

• $k$1, which locks $k$2 on-chain in a 2-of-2 control and initializes $k$3, $k$4;
• $k$5, which updates balances if successful and otherwise returns $k$6 with no state change;
• $k$7, which opens an on-chain dispute window and settles according to the latest valid $k$8 (Li et al., 1 Mar 2026).

The implementation extends the balance state to include transient locks,

$k$9

and refines the status space to

$\delta$0

OPEN accepts new requests; LOCKED escrows $\delta$1 for an in-flight request while execution is ongoing; PENDING denotes that execution is committed and the protocol is waiting for result revelation to finalize payment; CLOSED denotes final settlement and no further requests (Li et al., 1 Mar 2026).

The request identifier is

$\delta$2

with monotonically increasing $\delta$3 to prevent replays. The atomic exchange state machine is organized in four stages. First, the vault checks $\delta$4 and $\delta$5, moves $\delta$6 from $\delta$7 to $\delta$8, sets $\delta$9 with timeout $\delta$0, increments the request counter, and sends $\delta$1 to the provider. If no reply arrives by $\delta$2, the vault reverts to OPEN and restores availability. Second, the provider executes the request in its enclave, produces the result, generates the adaptor secret and pre-signature, encrypts the result, and sends $\delta$3 to the vault. Third, the vault reconstructs the payment message, verifies the pre-signature, records a pending tuple, moves to PENDING, and issues a conditional payment authorization $\delta$4. Fourth, the provider either reveals the secret off-chain, allowing the vault to decrypt the result and finalize balances, or force-closes on-chain with a completed adaptor signature if the vault is unresponsive beyond $\delta$5 (Li et al., 1 Mar 2026).

The protocol pseudocode condenses these transitions into the methods sendRequest, execRequest, onExecReply, revealSecret, and onSecretReveal. The semantics are exact: delivery without payment finalization is impossible because the vault needs $\delta$6 to decrypt, and payment without delivery is impossible because finalizing payment reveals $\delta$7 (Li et al., 1 Mar 2026).

4. Cryptographic binding, TEEs, and result delivery

A402’s atomicity mechanism is based on TEE-assisted adaptor signatures using Schnorr signatures on secp256k1 under BIP340. Let $\delta$8 be the provider public key and $\delta$9 the curve order. The provider samples $\delta$0 and computes $\delta$1; samples adaptor secret $\delta$2 and computes statement $\delta$3; defines $\delta$4; computes the challenge

$\delta$5

forms the pre-signature

$\delta$6

and the final signature

$\delta$7

Verification is

$\delta$8

and extraction is

$\delta$9

Pre-signature verification uses $\mathrm{negl}(\lambda)$0 to ensure that, given a witness $\mathrm{negl}(\lambda)$1 for $\mathrm{negl}(\lambda)$2, adapting $\mathrm{negl}(\lambda)$3 yields a valid Schnorr signature under $\mathrm{negl}(\lambda)$4 for message $\mathrm{negl}(\lambda)$5 (Li et al., 1 Mar 2026).

The payment message is defined as

$\mathrm{negl}(\lambda)$6

where $\mathrm{negl}(\lambda)$7. This binds the payment authorization to the specific request identifier, the payment amount, and the hash of the result. Result encryption derives a symmetric key $\mathrm{negl}(\lambda)$8 and encrypts the result as

$\mathrm{negl}(\lambda)$9

Binding the result to $C$0 in $C$1 prevents substitution attacks. Revealing $C$2 is equivalent to releasing the decrypt key and completing the signature; either path enables both payment finalization and result recovery (Li et al., 1 Mar 2026).

Remote attestation is the second essential binding layer. The vault and provider register via

$C$3

which binds the public key $C$4 to a genuine enclave running code with hash $C$5. After mutual verification, they derive an authenticated channel key via Diffie–Hellman to protect all ASC messages in transit. Operatively, “correct” execution means that the enclave executed the attested service code over the request to produce the result and then atomically generated $C$6, $C$7, and $C$8. No $C$9 is emitted without execution, and $U$0 is bound to $U$1 (Li et al., 1 Mar 2026).

The security proof sketch states the atomicity argument directly. Exec–Pay atomicity holds because the provider’s enclave emits $U$2 only after executing the request, and the payment authorization $U$3 references $U$4. Pay–Deliver atomicity holds because completing payment, whether by off-chain reveal or on-chain force-close, necessarily reveals $U$5, enabling decryption of $U$6; conversely, the vault cannot decrypt without $U$7 (Li et al., 1 Mar 2026).

5. Liquidity Vault, privacy, and blockchain integrations

A402’s TEE-based Liquidity Vault manages balances off-chain and aggregates settlements. For each party $U$8, the vault maintains state

$U$9

The private ASC lifecycle consists of initVault(π), which deposits funds to the committee address and increases $S$0 once confirmed; reqOpenVaultASC(S,v), which debits $S$1 from $S$2 and initializes a new off-chain ASC state $S$3 without any on-chain transaction; and reqCloseVaultASC, which cooperatively releases ASC funds back into vault accounts when $S$4, or otherwise waits for in-flight requests to complete or observes an on-chain force-close (Li et al., 1 Mar 2026).

Aggregated settlement is performed by a single txsettle that transfers aggregated free balances on-chain. If a party settles multiple off-chain ASCs, only the total is revealed:

$S$5

where each $S$6 is the net released balance from ASC $S$7. The on-chain footprint is therefore a single vault-level transaction. ASC creation, updates, and closure are invisible on-chain; only initVault and settleVault appear. This hides the client–provider interaction graph and per-ASC capacities (Li et al., 1 Mar 2026).

The privacy analysis describes the residual leakage surface. In vault mode, observers learn total settled balances, not per-request volume nor counterparty edges. Timing may correlate with off-chain activity, with settlement batching and randomized schedules proposed as mitigation. Network metadata between vault and provider may leak volumes, with authenticated channels, padding, and rate limiting proposed as mitigation. Side-channels in TEEs remain out of scope, with constant-time cryptography and resource partitioning listed as operational mitigations (Li et al., 1 Mar 2026).

The Bitcoin integration is implemented on regtest using Bitcoin Core v25.0, P2TR outputs, Taproot key-path/script-path spending, and a MAST encoding cooperative close, provider force-close via adaptor signature path, and client force-close via CSV relative timelock. The liquidity vault MAST adds cooperative batch settlement and force settlement by client or provider via long CSV timelocks as an emergency path. Adaptor signatures are used as scriptless scripts: the completed Schnorr signature appears standard on-chain, while the adaptor witness $S$8 is extractable by the vault off-chain using $S$9 without revealing program logic or per-request metadata (Li et al., 1 Mar 2026).

The Ethereum integration uses an ASC Manager smart contract exposing createASC, closeASC, initForceClose, finalForceClose, forceClose, initVault, settleVault, initForceSettle, and finalForceSettle. Because Ethereum lacks Schnorr precompiles, A402 integrates an optimized Solidity Schnorr verification library to validate adaptor signatures and challenges. The trade-off is explicit: Bitcoin’s Taproot enables cheaper, private scriptless integration and CSV-based disputes, while Ethereum’s account model simplifies lifecycle logic but requires on-chain verification of Schnorr relations with higher gas than ECDSA and careful Solidity optimization (Li et al., 1 Mar 2026).

6. Security properties, attacks on x402, and the A402 hardening perspective

A402’s security model considers malicious clients attempting free-riding or double-spending, malicious vaults that may observe, modify, or censor but cannot deviate from attested code or read TEE memory, malicious providers that may drop, delay, or abort but cannot forge enclave attestations or produce payment commitments without execution, a fully asynchronous network adversary, and a blockchain providing standard persistence and eventual inclusion. Cooperative and unilateral closures ensure assets can be recovered without relying on the vault’s availability or honesty. Vault-mode force settlement guarantees exit with a dispute window $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$00. Timeouts $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$01 and $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$02 prevent indefinite stalls, and the monotone counter $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$03 in $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$04, together with authenticated channels, provides replay resistance (Li et al., 1 Mar 2026).

A formal attack study of x402 shows why binding-centric mechanisms are necessary. The analysis defines authorization failure as

$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$05

payment–service mismatch as

$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$06

replay as reuse of the same $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$07 for another grant, and facilitator atomicity failure as premature reporting of finality before $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$08 confirmations (Li et al., 12 May 2026).

The attack taxonomy contains five concrete classes. Attack I-A, revert-grant under optimistic execution, exploits the timing gap between verify/grant and durable finality, producing unpaid service when access is granted before sufficient confirmations. Attack I-B, settlement preemption, exploits caller-unbound settlement paths so that an observer or Byzantine component consumes the signed authorization first, leading to paid-but-denied outcomes. Attack II, replay/idempotency across the HTTP–chain boundary, exploits missing atomic claims over $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$09, allowing many grants for one settlement. Attack III, HTTP header/proxy confusion and cache leakage, exploits mutable headers and publicly cacheable paid responses. Attack IV, server-selection attacks, exploits weak metadata and Sybil resistance in discovery layers to steer agents to attacker-controlled endpoints (Li et al., 12 May 2026).

The empirical results quantify these failures. In local tests, Attack I-A produced $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$10 up to $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$11 at $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$12 ms when $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$13; increasing $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$14 drove $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$15 to the confidence-interval floor while increasing grant-to-finality delay from approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$16 s to approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$17 s. Attack II yielded $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$18 without idempotency, and a live endpoint on Base Sepolia returned $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$19 HTTP 200 grants for one on-chain settlement under $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$20 concurrent replays. nginx produced $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$21 cache leakage without Cache-Control: no-store, private and $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$22 leakage with that header setting. In discovery-layer experiments, metadata manipulation produced selection rates of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$23, $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$24, and $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$25 for three model configurations, while Sybil flooding increased aggregate selection from $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$26 at $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$27 to $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$28 at $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$29, with some categories reaching $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$30 (Li et al., 12 May 2026).

The mitigations proposed for secure A402/x402 deployments align closely with A402’s stated design goals: typed canonical signing over pay identifier, resource identifier, facilitator, amount, token, chain identifier, expiry, and timestamp; atomic claim of $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$31 before grant; facilitator-bound settlement; a conservative confirmation policy or reserve-then-settle policy; Cache-Control: no-store, private on paid routes; and discovery-layer defenses such as metadata validation, Sybil-resistant registration, diversified ranking, and trustworthy provenance signals (Li et al., 12 May 2026). This suggests that A402 can be read both as a concrete ASC-based protocol and as a binding-oriented security doctrine for HTTP 402 micropayments.

7. Performance, cost profile, interoperability, and limitations

A402 was implemented and evaluated against x402 with integrations on both Bitcoin and Ethereum. The evaluation setup used an AMD EPYC 9965 with 192 cores and 512GB RAM, a fixed 10 ms network delay per link, 200 ms simulated compute at the provider, 100 ASCs, and 100 concurrent clients. Peak throughput reached $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$32 requests per second at approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$33 concurrent requests, with mild saturation up to $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$34 due to contention. Average end-to-end latency was approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$35–$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$36 ms and was dominated by service delay and network, indicating small protocol overhead (Li et al., 1 Mar 2026).

Compared to x402, A402 exceeded Ethereum throughput of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$37 TPS by approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$38 and Bitcoin throughput of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$39 TPS by approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$40. Latency was $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$41–$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$42 s end-to-end versus chain-confirmation times of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$43 s for Solana, approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$44 min for Ethereum, and approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$45 min for Bitcoin in the comparison used by the paper (Li et al., 1 Mar 2026).

The on-chain cost profile is similarly explicit. On Ethereum, in standard mode, createASC costs $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$46 gas ($$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$47), for a total of $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$48. In liquidity-vault mode, initVault costs $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$49 gas ($$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$50), for a total of $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$51, versus A402’s approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$52, a cost reduction of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$53–$$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$54. On Bitcoin, a standard ASC lifecycle costs approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$55 for $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$56 requests, a cost reduction of approximately $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$57 (Li et al., 1 Mar 2026).

Interoperability is organized around Web 2.0 invocation, APIs, and off-chain callbacks. Providers expose an attested TEE endpoint compatible with HTTP 402 flows. The vault translates client requests into ASC messages and manages conditional payments. The U-API and S-API define the off-chain calls sendRequest, execRequest, onExecReply, revealSecret, and onSecretReveal, while on-chain interfaces map to create/close and force-close/settlement operations. Result verification is performed by checking $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$58 embedded in $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$59, and per-request $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$60 provides fine-grained micropayment updates. Practical considerations include pre-funding ASCs via vault deposits to avoid liquidity stalls and using Raft in replicated vault deployments to keep ASC state consistent (Li et al., 1 Mar 2026).

The limitations are also explicit. TEE risks include side-channel and microarchitectural leakage, malicious firmware or supply-chain compromise, and reliance on vendor attestation services. Replication incurs coordination overhead, and optimizing enclave cryptography and batching may further improve throughput. Ethereum lacks native Schnorr support, so reliance on Solidity libraries increases gas cost. Regulatory issues include custody and KYC implications for vault-mode deployments. Planned improvements include stronger functional bindings, standardized encrypted result formats, and cross-chain settlement bridges (Li et al., 1 Mar 2026).

Within the comparative framing, the central distinction remains stable. x402 provides a payment-first workflow with no enforcement of execution–payment binding and no guarantee that result delivery cannot be withheld after payment. A402 instead enforces Exec–Pay–Deliver atomicity by combining TEE attestation, adaptor-signature-based conditional payment, off-chain channel updates, unilateral close mechanisms, and vault-level aggregation. The resulting system is described as providing formal atomicity, $$PP := \langle \text{payment\_id}, \text{payer\_addr}, \text{amount}, \text{chain\_id}, \text{nonce}, \text{ts}, \sigma\rangle,$$61 on-chain cost per ASC or vault lifecycle, and stronger privacy through vault-mode aggregation (Li et al., 1 Mar 2026).