a402

proposed

A402 (Atomic Service Channels)

by Li et al. (academic research)verified 2026-09-02

At a glance

Layer
execution
Category
onchain
Rails
Ethereum, Bitcoin
Settlement
Off-chain Atomic Service Channels, aggregated and settled on-chain via a TEE-based liquidity vault.
Reversible
No
Human in loop
none
D2C fit
weak
B2B fit
moderate
Spec
https://arxiv.org/abs/2603.01179

A research-stage payment architecture (arXiv, Mar 2026) that binds crypto payments to verifiable service execution for machine-to-machine commerce. It is positioned explicitly as addressing x402's lack of end-to-end atomicity across execution, payment, and delivery.

How it works

A402 is a trust-minimized payment architecture proposed to fix a specific gap the authors identify in x402: x402 sequences payment, service execution, and response delivery through a facilitator but does not enforce end-to-end atomicity across the three.

  • Atomic Service Channels (ASCs). A402 extends payment channels so that each payment is explicitly bound to a service request and its result delivery, offloading on-chain payments into off-chain channels for real-time, high-frequency micropayments.
  • Exec–Pay–Deliver invariant. Within an ASC, an atomic exchange protocol built on TEE-assisted adaptor signatures guarantees a payment is finalized if and only if the request is correctly executed and the result is delivered.
  • TEE Liquidity Vault. A trusted-execution-environment vault privately manages ASC lifecycles and aggregates many settlements into a single on-chain transaction that reveals only aggregated balances.

The authors report an implementation evaluated against x402 on both Bitcoin and Ethereum, claiming order-of-magnitude performance and on-chain-cost improvements. This entry is marked proposed: it is a published research design, not a production deployment, and its claims should be read as the paper's rather than as settled ecosystem fact.

Tradeoffs

  • Research-stage: a published architecture with a prototype, not a production system with real deployments.
  • Security guarantees depend on trusted execution environments (TEEs) and remote attestation — a hardware-trust assumption x402 does not require.
  • Meaningfully more complex than a plain HTTP-402 flow, trading simplicity for atomicity and privacy.
  • Reported performance and cost advantages are the authors' own measurements and are not yet independently corroborated at scale.

Security & limitations

  • The Exec–Pay–Deliver guarantee rests on TEE integrity; a TEE compromise or attestation failure undermines the atomicity claim.
  • Correctness of the adaptor-signature construction is load-bearing for the atomic exchange.
  • As with any channel protocol, force-close and dispute paths must be sound to prevent fund lock-up or theft.

See sources below. Documented for commentary and identification only.

Fits together with

  • x402 — x402 Payment Protocol

Deployments using a402

No deployments recorded yet.

Sources

  1. [1]A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce— arXiv (Li et al.), 2026-03
  2. [2]A402 (DOI)— arXiv, 2026-03