=== PAGE 1 ===
A402: Binding Cryptocurrency Payments to Service Execution for
Agentic Commerce
Yue Li
Peking University
Lei Wang
Shanghai Jiao Tong University
Kaixuan Wang
Shanghai Jiao Tong University
Zhiqiang Yang
Shanghai Jiao Tong University
Ke Wang
Zhongguancun Laboratory
Zhi Guan
Peking University
Jianbo Gao
Beijing Jiaotong University
Abstract
The rapid proliferation of autonomous AI agents is driving a
shift toward agentic commerce, where agents are expected to
autonomously invoke and pay for services. While blockchain-
based payments offer a programmable foundation for such
interactions, the recently proposed x402 standard fails to en-
force end-to-end atomicity across service execution, payment,
and result delivery.
In this paper, we present A402, a trust-minimized payment
architecture that securely binds cryptocurrency payments to
service execution. A402 introduces Atomic Service Chan-
nels (ASCs), a new channel protocol that integrates service
execution into payment channels, enabling real-time, high-
frequency micropayments for agentic commerce. Within each
ASC, A402 employs an atomic exchange protocol based on
TEE-assisted adaptor signatures, ensuring that payments are
finalized if and only if the requested service is correctly ex-
ecuted and the corresponding result is delivered. To further
ensure privacy, A402 incorporates a TEE-based Liquidity
Vault that privately manages the lifecycle of ASCs and ag-
gregates their settlements into a single on-chain transaction,
revealing only aggregated balances. We implement A402 and
evaluate it against x402 with integrations on both Bitcoin
and Ethereum. Our results show that A402 delivers orders-of-
magnitude performance and on-chain cost improvements over
x402 while providing trust-minimized security guarantees.
1
Introduction
The internet is undergoing a paradigm shift from a human-
centric content economy to a machine-centric agentic econ-
omy, driven by the rapid proliferation of autonomous AI
agents [33,44]. Unlike traditional human users, these agents
increasingly operate in a fully automated manner: they dy-
namically discover, invoke, and compose machine-callable
services, such as cloud functions, data oracles, and agent
skills [36]. In many cases, such interactions involve not only
service execution but also service payment: an agent may
Client
Service Provider
Facilitator
Blockchain
1. Http Request R
402 Response
2. Authorize 
Payment 𝑡𝑥𝑝𝑎𝑦
3.  Send 𝑡𝑥𝑝𝑎𝑦
Verification result
4. Execute 
Service Request 
5. Request Payment
6. Commit 𝑡𝑥𝑝𝑎𝑦 
to Chain
Monitoring &
Relaying 𝑡𝑥
7. Execute 𝑡𝑥𝑝𝑎𝑦 
(transfer on-chain asset
from client accout to 
service provider account)
8. Tx confirmed
9. Payment Finished
10. Deliver Response
L1: Non-Atomic 
Execution-
Payment
L3: High Latency/ High Tx
Fee/Lack of Payment
Privacy
L2: Non-Atomic Payment-Delivery
(Payment Required)
Figure 1: The workflow of x402 and its limitations
need to obtain access to a service from a previously unknown
provider without any pre-established account, contractual re-
lationship, or prior trust. As such interactions become both
autonomous and high-frequency, they naturally give rise to
an emerging form of agentic commerce, in which individual
service executions may themselves become billable events.
This emerging agentic commerce exposes the lack of a
suitable payment primitive. Existing traditional financial in-
frastructures rely on identity-based authentication, such as
Know-Your-Customer requirements, which assume that coun-
terparties possess legal or physical identity and can estab-
lish persistent relationships in advance. These assumptions
fit human-centric commerce, which typically adopts coarse-
grained monetization models such as subscriptions. However,
autonomous agents may lack legal identity, interact with pre-
viously unknown service providers, and require low-latency,
fine-grained settlement for individual service execution. In
contrast, blockchain bind assets to cryptographic keys, de-
coupling asset ownership from physical identity. This prop-
erty makes blockchain-based payments a natural foundation
for agentic commerce, where agents can transact directly,
securely, and programmatically without manual intermedia-
tion [26,38].
To enable such agent payment, the industry has recently
1
arXiv:2603.01179v2  [cs.DC]  19 Mar 2026



=== PAGE 2 ===
proposed x402, an emerging open standard that leverages the
HTTP 402 "Payment Required" status code to enable clients
to pay service providers with blockchain-based assets via
a centralized facilitator [32]. Within seven months after its
May 2025 launch, x402 processed more than 100 million
payments, reaching $24 million across major facilitators like
Coinbase, Cloudflare and Google [43]. The workflow of x402
is shown in Figure 1. When a client requests a service, the
service provider responds with a 402 status and payment
details (Step 1). The client then signs the txpay (i.e., payment
transaction) and resubmits the request (Step 2). The service
provider forwards it to a centralized facilitator for validation
(Step 3). After that, the service provider executes the request
(Step 4) and then signals completion to the facilitator (Step
5). The facilitator then broadcasts the txpay to the blockchain
(Step 6). Once txpay is executed and confirmed on-chain (Step
7), the facilitator then notifies the service provider to deliver
the response for the client (Steps 8-10).
Despite its rapid adoption in practice, x402 fails to satisfy
the security and performance requirements of high-frequency
agentic commerce due to the following limitations: L1. ser-
vice providers must execute requests optimistically before
payment finalization, exposing them to non-payment risks.
Moreover, facilitators broadcast payments without verifying
that execution has been actually carried out. All these situa-
tions violate the atomic binding of execution and payment;
L2. x402 enforces a payment-first workflow in which on-
chain payment confirmation precedes result delivery. As a
result, a malicious or failed service provider can withhold
service responses after receiving payment. This violates fair
exchange of payment and service response; L3. x402 suf-
fers from scalability and privacy limitations: (i) the end-to-
end latency is bounded by blockchain confirmation latency,
rendering real-time high-frequency interactions impractical;
(ii) high transaction fees render fine-grained micropayments
economically infeasible; (iii) all interactions are recorded
on-chain, compromising business privacy.
In this paper, we introduce A402, a secure agent payment
architecture that binds cryptocurrency payments to service ex-
ecution, enabling seamless agentic commerce while overcom-
ing the fundamental limitations of x402. The core of A402 is a
new channel protocol called Atomic Service Channel (ASC),
which offloads on-chain payments into off-chain channels
and embeds service execution into the payment channel’s
state, allowing for low-latency micropayments in real-time
interactions at a low cost (cf. L3(i)(ii)). Within the ASC, we
design an atomic exchange protocol that combines TEE-based
enforcement with adaptor signatures, which guarantees that
a payment is finalized if and only if the request is correctly
executed and the corresponding result is delivered, thereby
enforcing the atomicity across execution, payment, and de-
livery (cf. L1, L2). To further address privacy concerns, we
introduce a TEE-based Liquidity Vault that privately manages
the creation and settlement of ASCs. By maintaining ASC
state off-chain, the liquidity vault aggregates multiple ASC
settlements into a single on-chain transaction that exposes
only aggregated balances (cf. L3(iii)).
Overall, the design of A402 makes the following contribu-
tions:
• We propose Atomic Service Channels (ASCs), a new
channel protocol that binds off-chain service execution to
blockchain payments, enabling real-time, high-frequency
micropayments.
• We design an Atomic Exchange Protocol using TEE-
assisted adaptor signatures. This ensures end-to-end
atomicity by linking payment finalization to the veri-
fiable execution and delivery of service results.
• We propose a TEE-based Liquidity Vault to manage
the ASC lifecycle privately off-chain. By aggregating
multiple ASCs into a single on-chain settlement, it pre-
serves privacy while ensuring settlement integrity.
• We implement A402 on both Bitcoin and Ethereum.
Our prototype achieves a peak throughput of 2,875
RPS with sub-second latency (∼350 ms), representing
orders-of-magnitude improvements in performance over
x402 while enabling horizontal scalability. Further-
more, A402 reduces on-chain cost from O(n) (x402)
to constant O(1), providing a cost-effective and trust-
minimized solution for M2M commerce.
2
Preliminary
2.1
Payment Channel and its Limitation
Payment channels enable two parties, a client (C) and a ser-
vice provider (S), to process payments off-chain while relying
on the blockchain merely for channel creation and final settle-
ment (i.e., closure) [30]. Specifically, it manages intermediate
state updates (e.g., assets updates) off-chain in order to signif-
icantly reduce on-chain overhead, and preserves the payment
security guarantee since the channel settlement is enforced
on-chain. As shown in Figure 2, we model a payment channel
ΠPC as a tuple consisting of three interfaces:
• Channel Creation: Open(vC,vS) →(txcreate,B0). To es-
tablish the channel, C and S agree on their initial asset
deposits, vC and vS. The interface generates a transaction
txcreate which locks the total assets (vC +vS) into a 2-out-
of-2 multisig address on the blockchain. For example,
as illustrated in Figure 2, the channel is initialized that
the C holds $100 and the S holds $0. Simultaneously,
these two parties establish an initial off-chain state B0
reflecting this specific asset distribution.
• Payment / State Transition: Pay(Bi,δ) →Bi+1. To trans-
fer asset δ from C to S, the parties negotiate a new
2



=== PAGE 3 ===
state Bi+1. This update is valid if and only if both par-
ties exchange valid signatures over the new balance:
Bi+1 ←Sign(Bi+1). This process occurs entirely off-
chain and incurs no transaction fees. For example, the C
transfers $10 to the service provider, updating the state
from ($100,$0) to ($90,$10), as shown in Figure 2.
• Channel Closure/ Settlement: Close(B final) →txclose.
To close the channel, either party can submit the lat-
est valid state Bfinal (and its associated signatures) to
the blockchain. The blockchain verifies the signatures
against the txcreate and distributes the locked assets back
to C and S according to Bfinal. Note that txclose also
initiates an on-chain dispute window during which the
counterparty (C or S), or an optional watchtower, can
challenge the submitted B final by providing a more re-
cent state Bnew with valid signatures. After the dispute
window expires, the locked assets will be distributed on
chain according to the latest valid B.
Lack of Execution–Payment Binding. Despite their effi-
ciency, payment channels suffer from a fundamental limita-
tion to be deployed in agentic commerce: they track only asset
balances and are oblivious to service execution and result de-
livery. As shown in Figure 2, the channel state transitions
are restricted to asset updates and provide no mechanism to
represent, verify, or enforce off-chain service execution. As
a result, payment channels cannot guarantee atomicity be-
tween service execution, payment, and result delivery. This
limitation causes two fairness violations. First, if C co-signs
an updated balance state Bi+1 before receiving the service
result, a malicious S can immediately invoke Close(Bi+1)
to finalize the payment on-chain while aborting execution.
Conversely, if S executes the request first, the C may refuse to
co-sign the corresponding asset update, obtaining the service
without paying (i.e., free-riding).
In both cases, the blockchain cannot enforce fairness be-
cause channel settlement lacks verifiable evidence of off-chain
execution, fundamentally limiting the use of payment chan-
nels for agentic commerce. This limitation extends to proto-
cols built atop payment channels. For instance, L402 leverages
Lightning payment channels for HTTP 402 micropayments.
However, after payment, the client in L402 has no crypto-
graphic guarantee on the correctness or delivery of the service
result.
2.2
Adaptor Signature
Adaptor signatures extend standard digital signature schemes
(e.g., Schnorr digital signature [39]) to enable atomic ex-
change between a valid signature and a cryptographic secret
t [16]. Intuitively, an adaptor signature allows a signer to pro-
duce a pre-signature ˆσ with respect to a statement T = t ·G,
which can be completed into a valid signature σ if and only
if a corresponding secret witness t is revealed. Here, t ∈Zq
Funding Tx (MultiSig 2 of 2)
Blockchain
Client
Service 
Provider
C: $100
S: $0
C: $90
S: $10
On-chain
Payment
Channel
Service
Layer
Execution
Result Delivery
?
No visibility
?
x
Figure 2: The workflow of payment channel and its limitations
is a secret sampled from the finite field of order q, and G is
a generator of the elliptic curve group. Overall, an adaptor
signature scheme ΠAS over a hard relation R consists of the
following four interfaces:
• ˆσ ←pSign(sk,m,T): The signer generates a pre-
signature ˆσ on message m locked to statement T. This
signature is invalid under the standard verification logic
but cryptographically binds to T.
• 0/1 ←pVerify(pk,m,T, ˆσ): A verifier checks that ˆσ
is a well-formed pre-signature with respect to the state-
ment T. If verification succeeds, it guarantees that given
the corresponding witness t, the pre-signature ˆσ can be
transformed into a valid signature.
• σ ←Adapt(ˆσ,t): Given the witness t for the statement
T, any party can transform the pre-signature ˆσ into a
valid signature σ.
• t ←Extract(σ, ˆσ,T): Given the pre-signature ˆσ and
the completed signature σ, any observer can efficiently
extract the witness t.
2.3
Trusted Execution Environment
Trusted Execution Environments (TEEs) provide hardware-
enforced isolation that protects the confidentiality and in-
tegrity of code and data even in the presence of a compro-
mised operating system or hypervisor. Early TEE designs,
such as ARM TrustZone [29] and Intel SGX [9], focused
on enclave-level isolation within a single process. In con-
trast, modern TEE platforms, including Intel TDX [7] and
AMD SEV-SNP [1], support Confidential Virtual Machines
(CVMs), extending hardware-backed protection to entire vir-
tual machines and shielding guest execution from malicious
or compromised hypervisors. These TEEs further provide re-
mote attestation, which allows a remote party to verify that
a specific software stack is executing inside a genuine TEE
instance. Formally, a remote attestation scheme exposes the
following interfaces:
• σatt ←Attest(m): A TEE produces an attestation re-
port σatt that cryptographically binds a message m to
3



=== PAGE 4 ===
a hardware-verified measurement of the TEE-protected
execution environment.
• {0,1} ←VerifyAtt(σatt,m): A remote verifier checks
that σatt was generated by a genuine TEE instance run-
ning the expected software stack, thereby establishing
trust in the integrity of m.
3
Overview
A402 is a trust-minimized protocol designed to facili-
tate secure Web 3.0 payments for Web 2.0 services. At
its core, A402 introduces Atomic Service Channels and
leverages TEE-assisted adaptor signatures to enforce the
Exec–Pay–Deliver atomicity invariant for each service re-
quest.
3.1
The Workflow of A402
As illustrated in Figure 3, the A402 architecture consists of
four entities:
• Client (C). The C represents an autonomous agent re-
questing services off-chain. Being resource-constrained
and potentially offline, the C delegates channel manage-
ment and service invocation with payment to the vault,
which returns the service results.
• Vault (U): The vault (U) is a TEE-protected service
responsible for managing Atomic Service Channels
(ASCs) between clients and service providers. Acting as
a delegated ASC manager, the U maintains ASC state,
forwards service requests and results, and enforces ASC
protocol logic within a TEE instance. To improve scala-
bility and availability, the U may be deployed as multiple
TEE-backed replicas that execute identical protocol logic
and maintain consistent ASC state. In the liquidity vault
mode, the U can accept asset deposits from C to pre-
fund ASCs, enabling private ASC creation and closure
as well as privacy-preserving settlement.
• Service Provider (S): The service provider executes
service requests forwarded by the U via ASCs. A402
employs the TEE-assisted adaptor signature scheme to
ensure that S can only finalize the payment if and only if
the service request is executed and the result is delivered.
• Blockchain / On-Chain Program (L). A402 relies on
the underlying blockchain as a public settlement and
dispute resolution layer. The on-chain logic is imple-
mented either as a smart contract on account-based chain
(e.g., Ethereum) or as UTXO scripts on Bitcoin. It es-
crows ASC assets at creation and enforces conditional
settlement at closure. In the liquidity vault mode, it addi-
tionally governs the initialization and settlement of the
liquidity vault.
Client
Service Provider
Blockchain
Http Request R
402 Code
Vault
Atomic Service
Channel Creation §4.1
Atomic Exchange 
(Exec-Pay-Deliver 
Atomicity) §4.2
Create Channel
Atomic Service
Channel Closure §4.1
Channel Creation Tx
Request 
with payment
Result
Channel Closure Tx
Close Channel
….
- Private ASC Creation
- Private ASC Closure
Liquidity Vault §4.3
Initiate Vault Tx
Settle Vault Tx
II
III
I
Figure 3: A402 Overview.
The A402 protocol operates over three phases: ASC cre-
ation, atomic exchange, and ASC closure. In addition, A402
optionally supports a privacy-preserving liquidity vault mode
that is orthogonal to the ASC lifecycle.
Phase I: Atomic Service Channel Creation. The lifecycle
begins when a client C requests a service and receives a 402
Payment Required response. To proceed, C delegates the ses-
sion to the U, which interacts with the on-chain program L
to establish an ASC between C and S. This phase escrows the
client-approved assets on-chain and initializes the ASC state
for subsequent off-chain interaction.
Phase II: Atomic Exchange. Once the ASC is established,
A402 enters a high-frequency off-chain interaction phase.
The U receives service requests from C and forwards them
to S together with conditional payments. Using the atomic
exchange protocol, the S executes the request and returns the
corresponding result, while payment is finalized if and only if
execution and delivery are successfully completed. This phase
supports multiple service invocations without additional on-
chain interaction.
Phase III: Atomic Service Channel Closure. Upon session
termination, either C or S may initiate channel closure based
on the latest ASC state. In the standard mode, closure is
realized by submitting an on-chain transaction to L. The L
verifies the submitted ASC state and, when necessary, opens
a dispute window during which the counterparty may present
a more recent valid ASC state. After that, L distributes the
escrowed assets according to the latest ASC state.
Privacy-Preserving Liquidity Vault. In addition to on-chain
ASC creation and closure, A402 supports private ASCs via a
TEE-based liquidity vault. In this mode, C deposits assets into
U via L in advance. ASC creation and closure are handled off-
chain, while the settlement of multiple ASCs is aggregated
into a single on-chain transaction at the vault level, reducing
blockchain-observable leakage about individual ASCs (e.g.,
4



=== PAGE 5 ===
the client-service provider interaction graph and per-channel
capacity).
3.2
Threat Model
We describe the trust assumptions and adversarial capabilities
considered in A402.
Trusted Hardware Assumptions. A402 adopts a trust-
minimized model based on the hardware-enforced guarantees
of Trusted Execution Environments (TEEs). We assume the
TEE provides confidentiality and integrity for protected code
and data even in the presence of a compromised host operating
system or hypervisor in line with other TEE-assisted propos-
als [2,10,13,25,37,41,42]. In particular, an adversary control-
ling the host cannot read or modify TEE-protected memory,
extract sealed cryptographic secrets, or cause the TEE to devi-
ate from its attested execution logic. We assume the hardware
vendor’s remote attestation infrastructure is trustworthy and
uncompromised. Consistent with prior TEE-assisted propos-
als [2,10,13,25,37,41,42], we treat side-channel leakage and
other TEE-specific vulnerabilities as out of scope.
Adversarial Parties. We consider a powerful adversary that
may corrupt any subset of protocol participants outside the
TEE trust boundary: (i) Malicious Client (Cadv). A malicious
client may attempt to obtain service results without payment
(free-riding) or double-spend assets across multiple atomic
service channels. (ii) Malicious Vault (Uadv). A malicious
vault may attempt to observe, modify, or censor ASC work-
flow. Nevertheless, Uadv cannot tamper with ASC state, or
violate code enforced inside the TEE. (iii) Malicious Service
Provider (Sadv). A malicious service provider may drop or
delay messages, abort service execution, or attempt to claim
payment without executing the requested service. However,
due to TEE enforcement, it cannot forge execution results, al-
ter the attested execution logic, or extract secret keys. Beyond
A402 participants, we consider a passive adversary monitor-
ing on-chain transactions to construct the ASC interaction
graph. The adversary aims to deanonymize client-service
provider relationships and infer ASC capacity.
Network Adversary. We assume a fully asynchronous net-
work controlled by the adversary. The adversary may eaves-
drop, drop, replay, inject, or arbitrarily delay messages ex-
changed among C, U, S, and the blockchain. We assume
reliable eventual message delivery for liveness, but make no
synchrony assumptions for safety.
Blockchain Assumptions. A402 anchors its safety on the
underlying blockchain. We assume the blockchain provides
persistence (safety) and eventual transaction inclusion (live-
ness) under standard consensus assumptions [14,28]. Specifi-
cally, we assume that the on-chain program executes correctly
and that block producers will eventually include valid trans-
actions.
3.3
Design Goal
Based on the threat model described above, we derive the
following desirable security properties for A402:
Trust-Minimized Asset Security. A402 must ensure that
clients and service providers retain sovereign control over
their assets under a trust-minimized model. Asset safety must
not depend on the liveness, availability, or honesty of the vault.
Even in the event of complete vault censorship, compromise,
or service shutdown, A402 must provide an on-chain escape
mechanism that allows parties to reclaim their assets and
prevent indefinite asset locking.
Exec-Pay-Deliver Atomicity. A402 must enforce end-to-end
atomicity across service execution, payment, and result de-
livery. Payment may be finalized if and only if the request is
correctly executed, and the corresponding result must be de-
livered once payment is finalized. No party should be able to
obtain payment without execution, or obtain execution results
without payment.
Unlinkability. In privacy-preserving mode, A402 should de-
couple the off-chain ASC from the on-chain transactions. An
adversary observing the blockchain should be unable to link
a specific on-chain transaction to a particular ASC, nor infer
fine-grained service usages such as the frequency, volume, or
interactions between clients and service providers.
Furthermore, we derive the following desirable functional
properties for A402:
Low-Latency. A402 must support low-latency, interactive
services suitable for autonomous machines (e.g., AI agents).
During steady-state operation with honest participants (i.e.,
assuming the absence of disputes), the end-to-end latency of
a service request should be dominated by network communi-
cation and service execution, without waiting for blockchain
confirmation.
Cost Efficiency. A402 must minimize on-chain interactions
to reduce transaction fees and enable economically viable
micropayments for agentic commerce. Specifically, the on-
chain cost should remain constant O(1) regardless of the
number of service requests.
4
Design
In this section, we present the detailed design of A402, fo-
cusing on three core modules: Atomic Service Channel (Sec-
tion 4.1), the Atomic Exchange Protocol (Section 4.2), and
the Privacy-Preserving Liquidity Vault (Section 4.3).
4.1
Atomic Service Channel
Traditional payment channels only capture asset transfers
and are agnostic to off-chain service execution, making them
unsuitable for agentic commerce. Atomic Service Channels
extend this protocol by explicitly binding each payment to
5



=== PAGE 6 ===
a service execution and its result delivery. As illustrated in
Figure 4, instead of exchanging asset updates alone, the vault
forwards a service request req together with a conditional
payment to the service provider. The service provider exe-
cutes the req, finalizes the payment and returns the result res.
We now present the formal definition of the Atomic Service
Channel (ASC).
Definition 1 (Atomic Service Channel (ASC)) An Atomic
Service Channel with respect to a blockchain L is defined
as a tuple (C,S,Γ), where C is a client requesting off-chain
services, S is a service provider, and Γ denotes the current
ASC state of the channel. The Γ = (B,ς), where B = ⟨bc,bs⟩
represents the asset distribution in the channel, with bc held
by the client and bs held by the service provider. And ς denotes
the execution status of channel.
An ASC supports the following three operations:
• Channel Creation. openASC(C,S,v) →{Γ0,txcreate}.
Given a client C, a service provider S, and an initial
deposit v provided by C, the interface generates an on-
chain locking transaction txcreate on L that locks v assets
under the joint control of C and S. It initializes the ASC
state as Γ0 = (B0,ς0) where B0 = ⟨v,0⟩and ς0 = Open
denotes that no service request is currently being pro-
cessed.
• Atomic Exchange.
execPayDeliver(Γk,req,δ) →
{Γk+1,res,0/1}. On input the current ASC state Γk, a
service request req, and a payment amount δ, this in-
terface atomically executes the requested service, pro-
cesses the payment, and delivers the execution result.
If the execution completes successfully and the pay-
ment is processed, the ASC state is updated to Γk+1 =
(⟨bC −δ,bS +δ⟩,Open), and the execution result res is
delivered to the client and returned together with output
1. Otherwise, neither the state transition nor the result
delivery occurs, and the operation returns 0.
• Channel Closure / Settlement. closeASC(Γfinal) →
txclose. On input the final ASC state Γfinal = (B final,ς),
either party may initiate channel closure by submitting
txclose with Γfinal to the blockchain L. Upon invocation
of closeASC, the status ς transitions to Closed, indi-
cating that the ASC is no longer active and will accept
no further service requests. The submitted transaction
txclose initiates a dispute window, during which the coun-
terparty may challenge the closure by presenting a more
recent valid channel state. If no valid challenge is raised
within the dispute window, the protocol finalizes settle-
ment by distributing the locked assets according to B final
on chain.
We now describe how ASCs are instantiated within the
A402 architecture by mapping these ASC interfaces to the
vault U, the service provider S, and the on-chain program L.
Vault
Service Provider
Atomic Service Channel
U-API
Blockchain Interface
S-API
Blockchain Interface
Request: 𝒓𝒆𝒒
AuthPayment: $10
 U: $200
 S: $0
Result: 𝒓𝒆𝒔
FinalizePayment:
U: $190
 S: $10
Liquidity Vault State
ASC Local State
Executor
ASC Local State
Liquidity Vault State
Registry
Registry
Figure 4: An Atomic Service Channel in A402. The details
of U-API, S-API, and blockchain interfaces are described in
the Table 3 of Appendix C.
TEE Registration. A402 relies on TEEs to enforce protocol
correctness without trusting the host operating system. Be-
fore participating in any ASC operation, both U and S must
register their TEEs. As shown in Algorithm 1 (lines 12–15), a
TEE registers by submitting its public key pk, code hash hcode
and a remote attestation report att. The registration succeeds
only if the attestation verifies correctly, binding pk to an ap-
proved TEE instance measurement. Both the vault U and the
service provider S maintain a local registry (lines 2–5). The
service provider registry RegS maps each service provider
identifier sid to its public key and code hash (pkS,hcode,S),
while the vault registry RegU maps each vault identifier uid
to (pkU,hcode,U). After successful registration, U and S can
authenticate each other and establish a secure channel via
an authenticated Diffie–Hellman key exchange. The derived
channel key ch (line 5) is used to protect all subsequent ASC
messages, providing confidentiality and integrity against a
network adversary.
ASC State and Lifecycle. Each atomic service channel is
represented by a local channel state Γ maintained by the vault
U and synchronized with the service provider S (Algorithm 1,
lines 7–11). Formally,
Γ = (C,S,B,ς,k),
where C denotes the client, the ς denotes the channel status,
and the version counter k is incremented on each request to
prevent replay. The B denotes the asset state and is defined as
B = ⟨bC
free,bC
locked,bS⟩,
where bC
free denotes the client’s available assets, bC
locked de-
notes assets temporarily locked for an in-flight request, and
bS denotes the service provider’s accumulated revenue within
the ASC. The lifecycle of an ASC is captured by the channel
status ς, which transitions through the following stages:
• OPEN: the channel is active and accepts new service re-
quests;
• LOCKED: assets are escrowed for an in-flight request
whose execution is ongoing;
6



=== PAGE 7 ===
Algorithm 1: Atomic Service Channel
1 A402 State:
2 (i) Registry:
3
RegS : sid 7→(pkS,hcode,S)
4
RegU : uid 7→(pkU,hcode,U)
5
SC : id 7→ch
6 (ii) ASC State:
7
ASC : cid 7→Γcid
8
Γcid = (C,S,B,ς,k)
9
B = ⟨bC
free,bC
locked,bS⟩
10
ς ∈{OPEN,LOCKED,PENDING,CLOSED}
11
k denotes a increasing state version counter.
12 on Register(pk,hcode,att)
13
assert VerifyAtt(att, pk,hcode)
14
RegS/RegU.add(sid/uid)
15 end
16 on C.reqOpenASC(U,S,v,L,π)
17
U.initCommittee(π)
18
assert U.hasASC(C,S,ASC)
19
if ¬U.hasSC(S,SC) then
20
U.establishSC(S,SC)
21
end
22
(cid,B0,txcreate) ←U.openASC(C,S,v)
23
assert L.exec(txcreate)
24
ASC.add(cid,B0)
25
return (cid,B0);
26 end
27 on C/S.reqCloseASC(cid)
28
Γ ←U.getASC(cid)
29
assert Γ.ς ̸= CLOSED
30
if Γ.ς = OPEN then
31
txclose ←U.closeASC (Γ)
32
assert L.exec (txclose)
33
Γ.ς ←CLOSED
34
sync Γ in both U and S
35
else
36
U.waitUntil(Γ.ς = OPEN)
37
retry
38
end
39 end
40 on C.forceCloseASC(cid,Γ)
41
txinit ←C.initClose(cid,Γ)
42
assert L.exec(txinit)
43
L.startDisputeTimer(∆)
44
if ∆expired and no valid challenge from S/U
then
45
tx final ←C.finalClose(txinit)
46
assert L.exec(tx final)
47
Γ.ς ←CLOSED
48
sync Γ in both U and S
49
end
50 end
51 on S.forceCloseASC(cid,σS)
52
Γ ←S.getASC(cid)
53
assert Γ.σ ̸= CLOSED
54
if Γ.σ = OPEN then
55
txclose ←C.createClose(Γ)
56
assert L.exec(txclose)
57
Γ.ς ←CLOSED
58
sync Γ in both U and S
59
end
60
if Γ.ς = PENDING then
61
txASig
close ←closeWithASig(Γ,σS)
62
assert L.exec(txASig
close)
63
Γ.ς ←CLOSED
64
sync Γ in both U and S
65
end
66 end
• PENDING: execution is complete, and a conditional pay-
ment has been issued by U; U awaits result revelation;
• CLOSED: the channel has been settled and cannot be
reused.
Atomic Service Channel Creation. ASC creation is initiated
by the client via reqOpenASC (Algorithm 1, lines 16–26).
Upon receiving the request, the U instantiates a committee
according to the client-specified policy π (e.g., m-out-of-n)
and proceeds only after collecting sufficient authorizations
from the committee members (line 17). The U then verifies
that no active ASC already exists between the same client C
and service provider S, preventing duplicate channel creation
(line 18). Next, U ensures the existence of a secure channel
with S. If no such channel is available, the vault establishes
one on demand (lines 19–21). The U then executes openASC
to generate a channel identifier cid, an initial state Γ0, and
an on-chain creation transaction txcreate (line 22). Once the
txcreate is confirmed on the underlying chain L (line 23), the
ASC state is recorded locally and the channel transitions to
the OPEN state, ready to process service requests (as described
in Section 4.2).
Atomic Service Channel Closure. ASC closure in A402
supports both cooperative and unilateral settlement, guaran-
teeing asset recovery under adversarial conditions and thereby
ensuring trust-minimized asset security.
Cooperative Closure. Under standard cooperative condi-
tions, either C or S may request ASC closure via the vault U
(Algorithm 1, lines 27–38). If the ASC is in the OPEN state,
the U immediately settles it on-chain using the latest agreed
asset state Γ and transitions the ASC to CLOSED (lines 31-34).
If an in-flight request exists (i.e., the ASC is in the LOCKED or
PENDING state), settlement is deferred until the request com-
pletes, preventing partial execution from being settled (lines
36-37).
Unilateral Client Closure. To ensure trust-minimized as-
set security, A402 supports unilateral client closure via
forceCloseASC (lines 40-50), which bypasses the U. In
this force-close path, the C submits an initial close transac-
tion txinit to the L, containing the latest ASC state Γ received
from the U (lines 40–41). This transaction opens an on-chain
dispute window of duration ∆, during which the S may chal-
lenge the closure by submitting a more recent valid ASC
state (lines 42–43)1. If no valid challenge is submitted be-
fore the dispute window expires, the C finalizes settlement
by submitting a transaction txfinal (lines 45–47). Upon con-
firmation, the ASC transitions to the CLOSED state and assets
are distributed according to the B in the final state Γ. This
mechanism guarantees asset recovery even under complete
vault unavailability or service provider failure.
Unilateral Service Provider Closure. The service provider
S may also unilaterally close a ASC when the vault U is
unavailable (lines 51-66). If the ASC is in the OPEN state, the
S directly generates and submits a standard close transaction
txclose using the latest state (lines 53–57). Once confirmed, the
ASC transitions to the CLOSED state and settlement completes
normally.
If the ASC is in the PENDING state, the S generates the
adaptor signature σs for the current request and submits a
1S utilizes a so-called watchtower as in payment channel to detect and
respond to unilateral closure events within the challenge period
7



=== PAGE 8 ===
closing transaction txASig
close carrying the σs (line 61-62). Upon
confirmation, the σs irrevocably reveals the execution witness
t on-chain, enabling the S to claim its revenue while simulta-
neously allowing the vault U to extract t (lines 64–66) (More
details are provided in Section 4.2).
Note that the S has no incentive to submit a stale ASC state,
as doing so would only reduce its own revenue. Consequently,
force closure via S does not require a dispute window.
4.2
Atomic Exchange Protocol
With an established Atomic Service Channel, A402 enables
high-frequency off-chain service interactions. The remaining
challenge is to enforce the atomicity between service execu-
tion, payment, and result delivery for each service request. We
formalize this requirement by defining the notion of atomic
exchange.
Definition 2 (Atomic Exchange) An atomic exchange be-
tween a vault U and a service provider S satisfies the fol-
lowing property: for any execution of the protocol involving
an honest party and a malicious counterparty, the protocol
terminates in exactly one of the following states:
• Success: U obtains the service result res, and S obtains
the payment δ;
• Abort: U retains the payment δ, and S does not obtain δ
(and may retain res or no execution occurs).
Formally, for any adversary controlling one party, the prob-
ability that the protocol terminates in the following forbidden
states is negligible:
Pr

(S obtains δ∧U does not obtain res)
∨(U obtains res∧S does not obtain δ)

≤negl(λ).
Atomic Exchange using TEE-assisted Adaptor Signatures.
A402 realizes atomic exchange using TEE-assisted adaptor
signatures, as illustrated in Figure 5 and formalized in Algo-
rithm 2. The protocol proceeds in four phases and enforces
Exec-Pay-Deliver atomicity for each service interaction.
1 Request Submission and Asset Locking. As shown in Fig-
ure 5 1 , the exchange is initiated when the vault U submits
a service request req on behalf of the client C. The U first
verifies that the ASC is in the OPEN state and optimistically es-
crows the payment amount δ by moving it from bC
free to bC
locked
(Algorithm 2, lines 4-8). A request identifier rid = (cid,k) is
generated (line 7) and the ASC then transitions to the LOCKED
state, ensuring that no concurrent requests are accepted while
an execution is in flight. To preserve liveness and prevent the
ASC from being indefinitely stalled by a non-responsive S,
the U enforces a timeout ∆lock. If U fails to receive a valid
REPLY from S within ∆lock, the ASC automatically reverts to
the OPEN state, effectively expiring the cid and restoring ASC
Client 
Vault 
Service Provider 
Blockchain
𝑟𝑒𝑠←𝐸𝑥𝑒𝑐𝑢𝑡𝑒(𝑟𝑒𝑞)
𝑇←𝑡∗𝐺
𝐸𝑛𝑐𝑅𝑒𝑠← 𝐸𝑛𝑐𝑡𝑟𝑒𝑠, 𝑡
ො𝜎𝑠 ←𝑝𝑆𝑖𝑔𝑛(𝑠𝑘𝑠, 𝑚, 𝑇)
𝑝𝑉𝑒𝑟𝑖𝑓𝑦(𝑝𝑘𝑠, 𝑚, 𝑇, ො𝜎𝑠)
𝜎𝑢←𝑆𝑖𝑔𝑛(𝑠𝑘𝑢, 𝑚)
𝑉𝑒𝑟𝑖𝑓𝑦(𝑝𝑘𝑢, 𝜎𝑢)
𝑟𝑒𝑠 ←𝐷𝑒𝑐𝑡(𝐸𝑛𝑐𝑅𝑒𝑠, 𝑡)
res
ack
𝜎𝑠 ←𝐴𝑑𝑎𝑝𝑡𝑆𝑖𝑔( ො𝜎𝑠, 𝑡)
𝑡𝑥𝑐𝑙𝑜𝑠𝑒 𝑤𝑖𝑡ℎ 𝜎𝑠 
①
②
③
④
𝑡 ←𝐸𝑥𝑡𝑟𝑎𝑐𝑡 (𝜎𝑠, ො𝜎𝑠, 𝑇)
res
Figure 5: The workflow of atomic exchange
availability (line 10). After that, the tuple (cid,rid,req,δ) is
forwarded to the S via a secure channel (line 11).
2 TEE-assisted Execution and Adaptor-Signature Payment
Commitment. Upon receiving the request, the S executes req
inside its attested TEE, obtains the result res (line 15) and
then commits payment via an adaptor signature (lines 16-
20), as illustrated in Figure 5 2 . Because both the execution
logic and the payment commitment logic are enforced inside
a TEE, payment commitment is generated if and only if the
req has been correctly executed. Moreover, to bind execution
to payment commitment, S samples a secret witness t ∈Zq
inside the TEE and derives the corresponding public statement
T = t · G (lines 16-17). The execution result is encrypted
using t to produce EncRes, and an adaptor pre-signature ˆσS ←
pSign(skS,m,T) is generated over the payment message m
(lines 19-21). The S then returns an execution-bound payment
commitment Π = (EncRes,T, ˆσS) to U (line 22).
Crucially, the TEE enforces execution-payment commit-
ment atomicity. The witness t is generated and sealed inside
the TEE and cryptographically binds the encrypted execution
result EncRes to the payment commitment Π. Thus, a pay-
ment commitment cannot be generated without performing
the service execution.
3 Execution Verification and Conditional Payment. Upon
receiving Π, the U reconstructs the payment message m and
verifies the adaptor pre-signature ˆσS via pVerify (lines 26-
28). A successful verification confirms that the S has produced
a valid Π under the statement T. U then transitions the ASC
to PENDING, and issues a conditional payment signature σU
to the S (lines 29–31). At this point, payment is approved
but cannot be finalized without revealing the corresponding
witness t.
4 Payment Finalization and Result Delivery. After validating
σU, S reveals the t and finalizes this exchange through one
of two paths (lines 34-35), as illustrated in Figure 5 4 . In
8



=== PAGE 9 ===
Algorithm 2: Atomic Exchange Protocol (Exec-Pay-Deliver Atomicity)
1 Request State:
2
Pend : (cid,rid) 7→Rcid,rid
3
Rcid,rid = (δ,req,EncRes, ˆσS,T)
4 on U.sendRequest(cid,req,δ)
5
(C,S,B,ς,k) ←Γcid
6
assert ς = OPEN & bC
free ≥δ
7
rid ←(cid,k)
8
bC
free −= δ; bC
locked += δ
9
Pend[cid,rid] ←(δ,req,⊥,⊥,⊥)
10
ς ←LOCKED with a ∆lock
11
send to S : ⟨EXEC,cid,rid,req,δ⟩
12
k ←k +1
13 end
14 on S.execRequest(cid,rid,req,δ)
15
res ←Execute(req)
16
t
$←−Zq
17
T ←t ·G
18
h ←H (res)
19
m ←H (cid ∥rid ∥δ ∥h)
20
ˆσS ←pSign(skS,m,T)
21
EncRes ←Enct(res)
22
send to U : ⟨REPLY,h,T, ˆσS,EncRes⟩
23 end
24 on U.onExecReply(h,T, ˆσS,EncRes)
25
(δ,req,_,_,_) ←Pend[cid,rid]
26
m ←H (cid ∥rid ∥δ ∥h)
27
assert pVerify(pkS,m,T, ˆσS)
28
Pend[cid,rid] ←(δ,req,EncRes, ˆσS,T)
29
ς ←PENDING in Γcid
30
σU ←SignU(m,δ)
31
send to S : ⟨AUTH,σU⟩
32 end
33 on S.revealSecret(σU)
34
m ←H (cid ∥rid ∥δ ∥h)
35
assert Verify(pku,m,δ,σU)
// Preferred off-chain reveal
36
send to U : ⟨REVEAL,t⟩
37
Wait(∆ack)
38
if ∆ack received then
39
return OFFCHAIN_REVEAL
40
else
// Fallback: on-chain settlement
41
σS ←AdaptSig(ˆσS,t)
42
forceCloseASC(cid,σS)
43
t ←U.extract(ˆσS,σS,T)
44
return ONCHAIN_REVEAL
45
end
46 end
46 on U.onSecretReveal(t)
47
(δ,req,EncRes, ˆσS,T) ←Pend[cid,rid]
48
res ←Dect(EncRes)
49
(C,S,B,ς,k) ←Γcid
50
bC
locked −= δ;bS
free += δ
51
remove Pend[cid,rid]
52
ς ←OPEN in Γcid
53
issue receipt ∆ack to S
54
deliver res to C
55 end
the off-chain path, if U is responsive and cooperates, S re-
veals the witness t directly to U over the secure channel
(lines 36–40). Upon receiving t, the U decrypts EncRes,
transfers δ from bC
locked to bS
free, updates the channel state
to OPEN, and delivers the plaintext result res to the C (lines
47-54), thereby finalizing the payment and enabling result
delivery. If the U fails to respond within time ∆ack or the
S chooses to withhold the witness t off-chain, S completes
the adaptor signature σS ←AdaptSig(ˆσS,t) (line 41) and
invokes forceCloseASC(σS) to trigger on-chain settlement
(lines 42-43). Since on-chain settlement transaction reveals
the completed adaptor signature σS (lines 61 of Algorithm 1),
U can therefore extract t and decrypt the execution result res
(line 43), ensuring that payment finalization remains insepa-
rable from result delivery even under adversarial conditions.
Note that adaptor signatures enforce payment finalization
- result delivery atomicity. Any attempt by S to finalize pay-
ment—either off-chain or on-chain—necessarily reveals the
witness t, which enables U to recover the result res.
Exec-Pay-Deliver Atomicity. Using TEE-assisted adaptor
signature, A402 enforces Exec-Pay-Deliver Atomicity. We
decompose Exec-Pay-Deliver atomicity into two properties:
Exec-Pay atomicity and Pay-Deliver atomicity. TEEs bind
execution to payment commitment, and adaptor signatures
bind payment finalization to result delivery.
4.3
Privacy-Preserving Liquidity Vault
While Atomic Service Channels significantly reduce on-chain
interaction during steady-state operation, their creation and
closure still require on-chain transactions, which introduce
non-trivial privacy leakage. In particular, the ASC creation
and settlement transactions txcreate and txclose publicly reveal
the interaction relation between the client C and the service
provider S, as well as the exact channel capacity. To mitigate
this leakage, A402 introduces a Privacy-Preserving Liquidity
Vault, a TEE-backed protocol that decouples individual ASC
lifecycles from per-ASC on-chain transactions. Specifically,
assets are aggregated into an off-chain liquidity pool managed
by an attested vault. Algorithm 3 formalizes the workflow
of liquidity vault, in which channel creation, execution, and
closure are handled off-chain.
Vault Account Model. A402 maintains a vault-based account
model to track participant liquidity. For each participant p ∈
{C,S}, the liquidity vault maintains a private account state
Vp = (vfree
p
,vlocked
p
),
which is stored and updated entirely inside the vault’s attested
TEE. The free balance vfree
p
represents assets available for
funding new ASCs or for batched on-chain settlement, while
vlocked
p
captures liquidity temporarily reserved by active ASCs.
All balance transitions are enforced by verified TEE code
and are never exposed on-chain, ensuring that per-channel
balances and counterparty relationships remain hidden from
external observers.
Liquidity Vault Initialization. The liquidity vault is initial-
ized via the initVault interface (Algorithm 3, lines 3-7),
which sets up a TEE-backed committee and transfers user as-
sets into a committee-controlled address. Upon invocation, the
user specifies a policy parameter π defining a m-out-of-n com-
mittee rule (line 3). The vault executes initCommittee(π)
to deterministically instantiate a committee of n attested TEE
instances and configure the corresponding threshold gover-
nance logic inside the TEE (line 4). After committee initial-
9



=== PAGE 10 ===
Algorithm 3: Privacy-Preserving Liquidity Vault
1 Vault Account State:
2
Vp = (v free
p
,vlocked
p
) for p ∈{C,S}
3 on p.initVault(π)
4
assert U ←initCommittee(π)
5
issue txinit from p
6
assert L.exec(txinit)
7
vfree
p
+= txinit.val
8 end
9 on C.reqOpenVaultASC(S,U,v)
10
assert ¬U.hasASC(C,S)
11
if ¬U.hasSC(S,SC) then
12
U.establishSC(S,SC)
13
end
14
vfree
C
−= v
15
(cid,Γcid) ←initVaultASC(C,S,v)
16
return Γcid
17 end
18 on p.reqCloseVaultASC(cid)
19
Γ ←ASC[cid]
20
if Γ.ς = OPEN then
21
U.closeVaultASC(Γ)
22
end
23
if Γ.ς ∈{LOCKED,PENDING} then
24
U.WaitOrObserveOnChain(cid)
25
end
26 end
27 on p.reqSettleVault()
28
assert vfree
p
> 0
29
txsettle ←U.buildSettleTX(p,v free
p
)
30
assert L.exec(txsettle)
31
vfree
p
←0
32 end
34 on p.forceSettleVault(Vp)
35
txinit ←initForceExitTx(Vp)
36
assert L.exec(txinit)
37
L.StartDisputeTimer(∆settle)
38
if ∆expired and no valid challenge then
39
tx final ←finalizeForcExitTx(txinit)
40
assert L.exec(tx final)
41
v free
p
←0
42
end
43 end
ization, p submits an on-chain deposit transaction txinit to
a U-controlled address. Once the transaction is confirmed,
U credits the deposited assets to the free balance vfree
p
(lines
6-7). The assets are then decoupled from any specific ASC on-
chain and can be flexibly allocated to multiple ASCs off-chain
under U’s control.
Private ASC Creation. To create an ASC under the liquidity-
vault model, the client C invokes reqOpenVaultASC (lines 9-
17). The U first ensures that no active ASC exists between
C and S, and establishes a secure channel with S if needed
(lines 10-12). The requested channel capacity v is debited
from C’s free vault balance without generating any on-chain
transaction (line 14). The vault then generates a fresh ASC
identifier cid and initializes the ASC state Γcid with status
OPEN (line 15). As a result, ASC creation becomes a purely
off-chain operation, leaving no public on-chain transaction
that links C and S.
Private ASC Closure.
Either party may request a coop-
erative ASC closure via reqCloseVaultASC (lines 18-26).
If the ASC is in the OPEN state, U invokes closeVaultASC,
releases the ASC’s free assets and credits them back to the cor-
responding vault accounts before marking the ASC as CLOSED
(lines 20-21). If the ASC is in the LOCKED or PENDING state,
the vault defers closure and waits for the in-flight request
to complete or for an on-chain force-close transaction to be
observed (line 24). Importantly, assets locked in an active
ASC remain managed by the standard ASC protocol (Algo-
rithms 1 and 2) and can always be reclaimed via on-chain
force-close transactions. As long as the vault U remains live,
both C and S are economically disincentivized from invok-
ing on-chain force-close, since cooperative off-chain closure
is strictly more efficient and privacy-preserving. As a result,
privacy-preserving settlement does not compromise the Trust-
Minimized Asset Security.
Liquidity Vault Settlement.
When a party p (i.e., C
or S) intends to withdraw assets from U, it invokes
reqSettleVault() (lines 27-32). The U aggregates the par-
ticipant p’s free balance (vfree
p
), including assets released from
previously closed ASCs, and constructs a single on-chain
transaction txsettle that transfers the vfree
p
back on chain (lines
29-30). By consolidating multiple off-chain ASC settlements
into a single on-chain transaction, txsettle decouples individ-
ual ASCs from on-chain asset transfers, which reduces the
traceability of ASC settlements.
Force Liquidity Vault Settlement.
To tolerate U unavail-
ability, A402 provides an on-chain escape mechanism via
forceSettleVault (Algorithm 3, lines 34-43). The partic-
ipant p submits a force-settle initialization transaction txinit,
which opens an on-chain dispute window ∆settle (lines 35-37).
If U fails to submit a conflicting state during this window,
p finalizes the withdrawal after timeout (lines 38-40)2. This
mechanism guarantees asset security even under a malicious
or offline U, while preserving the privacy benefits of aggre-
gating off-chain ASC settlements.
5
Security Analysis
Trust-Minimized Asset Security. A402 guarantees asset se-
curity without relying on the availability or honest behavior
of either the vault U or the service provider S. In the standard
mode, ASC assets are locked and settled by the underlying
blockchain. If U becomes unresponsive or censors off-chain
interactions, both C and S can unilaterally initiate an on-chain
closure. Under the liquidity vault mode, assets are managed
off-chain within U but secured by verifiable TEE-enforced
state transitions. To prevent permanent asset locking, any
2Similarly, U can utilize a corresponding watchtower to monitor and
react to force-settle transactions during the challenge period.
10



=== PAGE 11 ===
participant p ∈{C,S} can unilaterally trigger an on-chain
force-settle if U becomes unresponsive or adversarial.
Exec-Pay-Deliver Atomicity. A402 ensures atomicity be-
tween service execution, payment, and result delivery, pro-
tecting against malicious clients, service providers, and vaults.
A402 uses TEE-assisted adaptor signatures to enforce atom-
icity. The TEE ensures that the payment commitment is gen-
erated only after service execution, preventing manipulation
by Sadv before service execution. The adaptor signature binds
payment finalization to the revelation of witness t embedded
in the encrypted result, ensuring that Sadv cannot finalize pay-
ment without delivering the result. Against malicious clients
(Cadv), A402 prevents free-riding by enforcing payment autho-
rization and state transitions within the vault’s TEE, blocking
double-spending, payment blocking, or unauthorized result
access. Against malicious vaults (Uadv), TEE ensures that
payment cannot be finalized without a valid adaptor signature
from the S. If the vault becomes unresponsive, the S and C
can unilaterally enforce settlement on-chain.
Unlinkability. In the privacy-preserving liquidity vault
mode, A402 protects against an adversary that observes the
blockchain. Because ASC creation, updates, and closure oc-
cur entirely off-chain, on-chain transactions expose only vault
initialization and settlement. An observer cannot link a spe-
cific on-chain transaction to a particular ASC creation or clo-
sure, nor infer the frequency, volume, or interactions between
clients and service providers.
6
Implementation
6.1
Off-chain Component
The off-chain components of A402 consist of three entities:
the vault (U), the service provider (S), and the client (C). Both
the U and the S are implemented in C++17 and deployed
inside AMD SEV-SNP protected virtual machines, forming
the TEE instance. The C is considered an untrusted party.
Vault. We implemented U as a scalable component that can
be deployed either as a single TEE or as a replicated clus-
ter of multiple TEEs. In the clustered configuration, our im-
plementation uses the Raft consensus protocol [27] with a
leader-follower architecture.
Service Provider. To decouple protocol overhead from spe-
cific workloads, we simulate service execution with a fixed
200 ms delay in S. The adaptor signature module is imple-
mented inside the TEE using a Schnorr adaptor signature
scheme [16].
6.2
On-chain Component
We implement the on-chain support for ASCs on a locally
controlled Ethereum test network and Bitcoin test network
(Appendix A).
Ethereum: ASC Manager Contract. We implement the
on-chain component of A402 as an ASC Manager smart
contract deployed on an Ethereum test network using the
Hardhat toolchain (Hardhat v2.19.0, ethers.js v6.9.0, and
hardhat-toolbox v4.0.0). The contract manages the full
lifecycle of ASCs. Channel creation and cooperative clo-
sure are provided via createASC and closeASC. To han-
dle adversarial scenarios, the contract exposes unilateral
client closure via initForceClose, finalForceClose and
unilateral service provider closure via forceClose. In
liquidity-vault mode, the contract supports vault initializa-
tion and settlement via initVault and settleVault, to-
gether with force-settlement interfaces (initForceSettle,
finalForceSettle) that guarantees asset recoverability in
the presence of vault failures. A practical challenge is that
Ethereum does not provide native secp256k1 Schnorr verifi-
cation precompiles. To enable on-chain verification of adaptor
signatures, we integrate an optimized solidity schnorr verifi-
cation library3. A detailed mapping between these on-chain
interfaces and the ASC protocol interfaces is provided in
Table 3 in the Appendix C.
Bitcoin. Detailed implementation of the Bitcoin on-chain
component can be found in the Appendix A.
7
Evaluation
7.1
Setup
All experiments are conducted on a server equipped with an
AMD EPYC 9965 CPU (192 cores) and 512GB RAM. The
machine hosts all off-chain components of A402. To isolate re-
source contention, CPU cores are statically partitioned across
system components. The service provider S is allocated 100
CPU cores, while the vault U is allocated 64 CPU cores. In the
clustered configuration, each replica is assigned 8 CPU cores.
We emulate network communication between C, S, and U by
introducing a fixed 10 ms network delay per link. This delay
is held constant across all experiments. To decouple proto-
col overhead from application-specific workloads, the service
provider introduces a fixed 200 ms processing delay per re-
quest. The service provider S maintains 100 ASCs with U,
each pre-funded with sufficient client assets to avoid liquidity
bottlenecks during experiments. We implement a client work-
load generator that simulates 100 concurrent clients. Each
client continuously issues service requests to S through U.
The total number of requests ranges from 100 to 10,000 and
is evenly distributed across the 100 pre-established ASCs.
7.2
On-chain Cost
We evaluate the on-chain transaction cost of A402 on both Bit-
coin and Ethereum and compare it with x402. In x402, each
3https://github.com/noot/schnorr-verify
11



=== PAGE 12 ===
Table 1: Ethereum Gas Consumption: Detailed Interface
Costs. Gas Price: 20 Gwei, ETH Price: $2,000.
Interface / Operation
Gas Used
Cost (USD)
A402: Standard Channel Mode (ASC)
U.createASC
26,050
$1.04
U.closeASC
57,637
$2.31
Total Cost (n request)
83,687
$3.35
— Force Close Operations —
S.forceClose
116,650
$4.67
C.initForceClose
51,980
$2.08
C.finalForceClose
62,787
$2.51
A402: Liquidity Vault Mode
U.initVault
23,846
$0.95
U.settleVault
27,490
$1.10
Total Cost (n request)
51,336
$2.05
— Force Settle Operations —
C/S.initForceSettle
114,237
$4.57
C/S.finalForceSettle
23,502
$0.94
Baseline: x402
Approve (One-time)
22,580
$0.90
TransferFrom (Single Request)
23,530
$0.94
Total Cost (n request)
22,580 + 23,530 * n†
$0.9 + $0.94 * n
100 Requests
2,375,580
$95.02
† Calculated as: GasApprove +(n×GasTransferFrom).
service request requires an on-chain payment transaction, re-
sulting in linear on-chain cost with respect to the number
of requests (O(n)). In contrast, A402 amortizes on-chain in-
teractions across multiple requests. In standard mode, A402
requires only channel creation and closure transactions. In
liquidity vault mode, A402 requires vault initialization and
settlement transactions. As a result, the number of on-chain
transactions in A402 remains constant with respect to the
number of off-chain service requests(O(1)).
Transaction Cost on Ethereum. We measure the gas con-
sumption of A402 using the contract interfaces described in
Section 6.2. Both A402 and x402 use ERC20 tokens as the
payment asset to ensure a fair comparison. Table 1 summa-
rizes the measured costs.
In standard mode, ASC creation and cooperative closure
cost 26,050 and 57,637 gas, resulting in a total lifecycle
cost of 83,687 gas ($3.35) per channel. In liquidity vault
mode, vault initialization and settlement cost 51,336 gas
in total ($2.05). These costs are incurred once per chan-
nel (or vault) lifecycle and are therefore amortized across
all off-chain service requests. To guarantee asset recovery
under adversarial conditions, A402 provides force-closure
paths. The service provider can enforce closure directly via
S.forceCloseASC (116,650 gas), while client-driven force-
closure via C.initForceClose and C.finalForceClose
costs 23,846 and 27,490 gas. In liquidity vault mode, force
settlement via initForceSettle and finalForceSettle
costs approximately $5.51. The above interfaces serve strictly
as a worst-case fallback for asset recovery and are expected to
Figure 6: The throughput of A402 with varying requests
be invoked with negligible frequency. Even when triggered,
their costs remain bounded and occur at most once per chan-
nel/vault lifecycle.
Comparison with x402. We model x402 using a sin-
gle ERC20 approval transaction followed by repeated
transferFrom calls, representing the best-case deployment
of x402. Specifically, x402 requires an on-chain transfer for
every request. Its total gas cost is: 22,580+23,530∗n, where
the 22,580 is the gas cost of the one-time approval transaction.
As a concrete example, processing 100 requests costs approx-
imately $95.02 in x402, while A402 incurs only the one-time
lifecycle cost of $3.35 (standard mode) or $2.05 (vault mode),
representing a cost reduction of approximately 28×–46×.
Transaction Cost on Bitcoin. Detailed results can be found
in the Appendix A.
7.3
Performance Evaluation
We evaluate the off-chain performance of A402’s ASC, fo-
cusing on throughput and end-to-end latency. Throughput
is measured as completed requests per second (RPS), and la-
tency is measured as the end-to-end request completion time.
Our evaluation consists of two workloads: (i) varying service
request volumes with a single vault, and (ii) scaling the num-
ber of vault replicas under a fixed request volume (details in
the Appendix B).
Scalability with Request Volume. Figures 6 and 7 show the
throughput and latency of ASC, respectively, as the number of
concurrent requests increases from 100 to 10,000. Throughput
scales significantly and reaches a peak of 2,875 RPS at 5,000
concurrent requests. We observe a mild saturation phase from
5,000 to 10,000 requests due to resource contention. As shown
in Figure 7, average latency remains stable, increasing only
by 8.6%, from 340.56 ms to 369.86 ms, as the request volume
scales. This latency is largely determined by the simulated
service execution time (200 ms) and network delay (10 ms),
indicating that the additional overhead introduced by ASC
is small. These results indicate that ASC effectively handles
high request volumes while maintaining low latency.
12



=== PAGE 13 ===
Figure 7: The latency of A402 with varying requests.
Comparison with x402.
For fairness, we compare against
an idealized deployment of x402 and consider only the
throughput and latency of on-chain payment, excluding addi-
tional real-world overheads such as network delay, request ex-
ecution. Because x402 ultimately relies on on-chain payment,
its performance is bounded by underlying blockchain. Our
prototype achieves a peak throughput of 2,875 RPS, exceed-
ing the payment throughput of Ethereum (∼30 TPS [5]) and
Bitcoin (∼7 TPS [4]) by 95× and 410×, respectively. In terms
of latency, blockchain confirmation typically requires seconds
to minutes (∼12.8 s on Solana [6], ∼13 min on Ethereum [5],
and ∼60 min on Bitcoin [4]), whereas A402 completes the
full service request in 0.34–0.37 s on average—over 40×
faster than Solana and several orders of magnitude faster than
Ethereum and Bitcoin.
Horizontal Scalability. Unlike x402, whose performance is
strictly bound by the underlying blockchain, A402 features
a scale-out architecture where capacity grows linearly with
additional hardware resources. Notably, a single deployment
of our prototype already achieves a throughput of 2,875 RPS,
comparable to high-performance blockchains like Solana
(1,600-3,500 TPS [6]). This implies that by simply provision-
ing additional vaults and service providers, A402 can support
high-frequency agentic interactions at a scale far exceeding
that of x402.
8
Applications
This section provides a brief overview of several new and
novel applications enabled by A402.
Request-Centric Micropayments in Web 2.0 Service.
A402 shifts Web 2.0 services from an identity-centric mode
(e.g., persistent API keys and subscriptions) to a request-
centric payment. Specifically, A402 treats each service in-
vocation as an economic event: a client no longer pays for
general "platform access" but rather for the service request,
i.e., the execution of a function f(x) →y.
Pre-A402: "I pay for access to the platform, hoping the
platform will execute my request correctly.".
Post-A402: "I pay only for this attested execution of f(x)
that produces result y".
For service providers, this shift significantly lowers the
operational barrier to entry. By removing the need for user
database maintenance, the service provider needs only to ex-
pose an attested TEE endpoint.
Autonomous agentic Commerce via Pay-for-Verified-
Execution. A402 transforms Web 2.0 services into a trust-
less marketplace where verifiable execution is the fundamen-
tal unit of exchange. By leveraging ASCs, autonomous AI
agents can programmatically negotiate and consume com-
putational resources—such as real-time inference or private
data queries—without the risk of service non-delivery. This
A402 ensures that payment is finalized only upon the delivery
of a valid result, enabling agents to securely compose com-
plex, cross-service provider workflows providing the essential
financial rail for a scalable, self-directed agentic commerce.
High-Frequency Trustless Metering for Edge and IoT.
Edge and IoT environments require millisecond-level la-
tency and high-concurrency interactions between mutually
untrusted machines. x402 fails to support such payments due
to blockchain limitations, while subscription models are too
coarse-grained for sporadic machine workloads. In contrast,
A402 enables trustless off-chain metering and settlement with
millisecond-level overhead, making it well suited for latency-
sensitive scenarios such as 5G routing and CDN caching.
9
Related Work
Payment Channel. Prior research on payment channel has
largely focused on enhancing privacy [17, 18, 31] and capi-
tal efficiency [15, 19, 21]. Most closely related to our work
are Teechan [22] and Teechain [23] which leverage TEEs
to establish secure, asynchronous payment channels. A402
differs by focusing on binding off-chain service execution
with on-chain asset payments. L402 applies Lightning pay-
ment channels to HTTP 402 API payments with macaroon-
based authentication. Overall, existing payment channels are
execution-unawareness and cannot prevent payment without
service execution or service execution without payment.
TEEs for Blockchain. Integrating TEE with blockchain
has been explored to overcome the inherent limitations of
blockchains. A substantial body of work [2,8,10,13,20,25,
37, 41, 42] utilizes TEEs to offload complex computations
from the blockchain to enhance both scalability and privacy.
Unlike prior work that uses TEEs to extend on-chain computa-
tion, A402 leverages TEEs to bind off-chain service execution
to on-chain assets payment.
Blockchain-based Fair Exchange. While blockchain-based
fair exchange protocols have evolved from data extraction
[3,11,12,24,34] to functional data extraction [35], they re-
main inefficient for general-purpose programs. A402 real-
13



=== PAGE 14 ===
izes atomic exchange protocol that secures universal service
execution-for-payment, extending fair exchange to arbitrary
computational tasks.
10
Conclusion
This paper presented A402, a trust-minimized protocol that
enables Web 3.0 payments for Web 2.0 services to support
agentic commerce. By introducing Atomic Service Chan-
nels (ASCs), A402 employs a TEE-assisted adaptor signature
scheme to enforce the Exec–Pay–Deliver atomicity for each
service request. To mitigate privacy leakage, A402 incorpo-
rates a TEE-backed liquidity vault that achieves batch settle-
ments while enabling private ASC. Evaluation on Ethereum
and Bitcoin confirms that A402 achieves sub-second latency
and high throughput, providing a scalable and secure payment
solution for the emerging agentic commerce.
A
A402 on Bitcoin: Implementation and Eva-
lution
Bitcoin Enforcement with Taproot. On the Bitcoin side,
we implement A402 on a Bitcoin Core v25.0 regtest en-
vironment. The protocol lifecycle maps strictly to Bitcoin’s
UTXO model: channel creation generates a specific Pay-to-
Taproot (P2TR) output (Locking) [40], while channel closure
consumes this output (Spending) to finalize settlement. In
standard mode, The createASC transaction broadcasts a trans-
action that instantiates a P2TR output tailored for the ASC
closure. Specifically, all closure conditions are encoded within
a Merkle Abstract Syntax Tree (MAST), accessible via Script-
Path spending. Specifically, the MAST encodes three closure
paths: (i) cooperative closure by the vault (U.closeASC);
(ii) force closure by the service provider, executed via adap-
tor signatures (S.forceClose); (iii) force closure by client,
secured by relative timelocks (CSV) to allow challenge peri-
ods (C.forceClose). In liquidity vault mode, the initVault
transaction broadcasts a transaction that instantiates a spe-
cialized P2TR output. Similarly, all settlement conditions
are encoded within a Merkle Abstract Syntax Tree (MAST),
accessible via Script-Path spending. Specifically, the MAST
encodes two settlement paths: (i) cooperative batch settlement
by the vault (U.forceSettle); (ii) force settlement by the
client or service provider, secured by long relative timelocks
(CSV) to serve as an emergency escape hatch during vault
failure(C/S.forceSettle).
Transaction Cost on Bitcoin. Table 2 reports the Bitcoin on-
chain transaction costs of A402 under Taproot (P2TR) speci-
fications. In the standard mode, a channel lifecycle consists of
two transactions: opening the ASC and closing it. As shown in
the table, U.createASC spends 153 vB ($0.765) when fund-
ing the ASC with a P2WPKH input and creating a P2TR lock-
ing output (plus change), while the cooperative U.closeASC
Table 2: Bitcoin On-chain Cost. Fee Rate: 10 sat/vB, BTC
Price: $50,000. All transactions utilize a standard 1-Input,
2-Output structure, with the exception of the x402 finalization
(tx2) which is optimized to a single output.
Operation
Base Size
Witness
Total Size
Cost (USD)
(vB)
(vB)
(vB)
A402: Standard Mode (ASC)
U.createASC
125
27.75
153
$0.765
U.closeASC
137
17.25
155
$0.775
Total Cost(n request)
262
45.00
308
$1.54
— Force Exit Operations —
S.forceClose
137
71.00
208
$1.04
C.forceClose
137
54.50
192
$0.96
A402: Liquidity Vault Mode
U.initVault
125
27.75
153
$0.765
U.settleVault
137
17.25
155
$0.775
Total Cost(n request)
262
45.00
308
$1.54
— Force Exit Operations —
C/S.forceSettle
137
54.50
192
$0.96
Baseline: x402
tx1: Setup (C →F)
125
27.75
153
$0.765
tx2: Finalize (F →S)
82
56.00
138
$0.69
Total Cost(n request)
207*n
83.75*n
291*n
$1.455*n
100 Requests Total (O(n))
20,700
8,375
29,100
$145.50
spends 155 vB ($0.775) via a Taproot key-path spend with a
standard 1-input, 2-output structure. Consequently, the total
on-chain cost of a complete ASC lifecycle is 308 vB ($1.54).
In adversarial scenarios, the ASC can still be closed unilater-
ally via script-path spends. A provider-initiated force closure
S.forceClose costs 208 vB ($1.04), while a client-initiated
force-close C.forceClose costs 192 vB ($0.96). Relative to
the cooperative close (155 vB), the additional overhead is
modest (37–53 vB), and remains practical in absolute terms
due to Taproot’s witness discount and the fact that only a small
script witness (rather than large scriptsig data) is revealed.
In
liquidity vault mode, the
vault is
funded via
U.initVault
(153
vB, $0.765)
and
settled
via
U.settleVault (155 vB, $0.775), yielding the same
constant on-chain lifecycle cost of 308 vB ($1.54). Impor-
tantly, a single vault settlement can aggregate payouts for
many off-chain ASCs into one on-chain transaction, keeping
the amortized on-chain cost per request negligible as the
request volume grows.
Comparison with x402. To compare A402 against x402,
we model each x402 service request with two on-chain trans-
actions. The setup transaction (tx1) locks the client’s funds
into an escrow UTXO (modeled as a SegWit output) and costs
153 vB ($0.765) under the same 1-input, 2-output assump-
tion. The finalization transaction (tx2) spends the escrow with
signatures from the facilitator and the service provider and is
optimized to a single output, costing 138 vB ($0.69). Thus,
x402 incurs 291 vB ($1.455) per request, and its total cost
14



=== PAGE 15 ===
scales linearly with the number of requests.
By contrast, A402 pays a constant $1.54 for opening and
closing a channel (or funding and settling a vault), indepen-
dent of how many requests are served off-chain in between.
Therefore, x402 exceeds A402’s fixed lifecycle cost after
just two requests ($2.91 vs. $1.54), and for 100 requests,
x402 costs $145.50 whereas A402 remains at $1.54– a 94×
reduction in on-chain fees. This confirms that A402 is sub-
stantially more economical for high-frequency machine-to-
machine payments.
Figure 8: The throughput with varying U replicas (8 CPU
cores per replica)
Figure 9: The latency with varying U replicas
B
Scalability with Varying Replica in Vault
Compared with the single vault evaluation in Section 7.3,
the multi-replica experiments were conducted under a fixed
request load of 1,000 requests and a fixed total CPU budget.
In this setting, each replica was allocated only 8 CPU cores,
whereas the single vault configuration used 64 CPU cores.
As a result, the throughput of two replicas (780.86 RPS) is
already significantly lower than the single-Vault throughput
(2,063.14 RPS), primarily due to reduced per-replica compute
capacity rather than inherent scalability limitations.
As illustrated in Figure 8, throughput further decreases as
the number of Vault replicas increases, dropping from 780.86
RPS with 2 replicas to 530.49 RPS with 10 replicas, while
Figure 9 shows that average latency increases only marginally
from 372.63 ms to 377.66 ms. This throughput reduction is
mainly attributed to additional coordination overhead intro-
duced by replication, including signature fragment distribu-
tion, aggregation, and state synchronization across replicas,
combined with reduced per-replica CPU resources. Despite
this, latency remains stable (increasing by only 1.4%) because
it is dominated by simulated service execution and network
delay rather than replica coordination.
C
Summary of A402 Interfaces
For a full technical specification, we provide a detailed map-
ping of A402 APIs to their respective on-chain transactions
in Table 3. It explicitly categorizes each function by its caller
(U,C,S) and distinguishes between purely off-chain execu-
tion and those requiring on-chain transactions.
References
[1] ADVANCED MICRO DEVICES, INC. Sev-snp abi specification. https:
//www.amd.com/content/dam/amd/en/documents/developer/5
6860.pdf, 2025.
[2] BENTOV, I., JI, Y., ZHANG, F., BREIDENBACH, L., DAIAN, P., AND
JUELS, A. Tesseract: Real-time cryptocurrency exchange using trusted
hardware. In Proceedings of the 2019 ACM SIGSAC Conference on
Computer and Communications Security (CCS) (2019), pp. 1521–1538.
[3] CAMPANELLI, M., DANNENBERG, R., GENNARO, R., AND NAC-
CACHE, D. Zero-knowledge contingent payments revisited: Attacks
and payments for services. In Proceedings of the 2017 ACM SIGSAC
Conference on Computer and Communications Security (CCS) (2017),
pp. 229–244.
[4] CHAINSPECT. Bitcoin network real-time metrics and statistics. https:
//chainspect.app/chain/bitcoin, 2026. Accessed: 2026-01-05.
[5] CHAINSPECT. Ethereum network real-time metrics and statistics. ht
tps://chainspect.app/chain/ethereum, 2026. Accessed: 2026-
02-05.
[6] CHAINSPECT. Solana network real-time metrics and statistics. https:
//chainspect.app/chain/solana, 2026. Accessed: 2026-01-05.
[7] CHENG, P.-C., OZGA, W., VALDEZ, E., AHMED, S., GU, Z.,
JAMJOOM, H., FRANKE, H., AND BOTTOMLEY, J. Intel tdx demys-
tified: A top-down approach. ACM Computing Surveys 56, 9 (2024),
1–33.
[8] CHENG, R., ZHANG, F., KOS, J., HE, W., HYNES, N., JOHNSON,
N., JUELS, A., MILLER, A., AND SONG, D. Ekiden: A platform
for confidentiality-preserving, trustworthy, and performant smart con-
tracts. In 2019 IEEE European Symposium on Security and Privacy
(EuroS&P) (2019), pp. 185–200.
[9] COSTAN, V., AND DEVADAS, S. Intel sgx explained. Cryptology
ePrint Archive (2016).
[10] DAS, P., ECKEY, L., FRASSETTO, T., GENS, D., HOSTAKOVA, K.,
JAUERNIG, P., FAUST, S., AND SADEGHI, A.-R. Fastkitten: Practical
smart contracts on bitcoin.
In 28th USENIX Security Symposium
(USENIX Security 19) (2019), pp. 801–818.
[11] DZIEMBOWSKI, S., ECKEY, L., AND FAUST, S. Fairswap: How to
fairly exchange digital goods. In Proceedings of the 2018 ACM SIGSAC
Conference on Computer and Communications Security (CCS) (2018),
pp. 967–984.
[12] ECKEY, L., FAUST, S., AND SCHLOSSER, B. Optiswap: Fast optimistic
fair exchange. In Proceedings of the 15th ACM Asia Conference on
Computer and Communications Security (ASIACCS) (2020), pp. 543–
557.
15



=== PAGE 16 ===
Table 3: Summary of A402 System APIs and On-chain Interfaces.
Protocol Stage
API Function
Bitcoin Interface
Ethereum Interface
Description
I. ASC Creation
S.Register
–
–
Register S via remote attestation and bind iden-
tity to code hash.
U.reqOpenASC
U.createASC
U.createASC
Initiate an ASC by locking initial assets on the
underlying blockchain.
II. Atomic Exchange
U.sendRequest
–
–
Issue a request with a conditional payment.
S.execRequest
–
–
Execute the request inside the TEE and gener-
ate an encrypted response.
U.onExecReply
–
–
Verify execution proof and authorize the re-
lease of conditional payment.
S.revealSecret
–
–
Reveal the witness to finalize the payment off-
chain or on-chain.
U.onSecretReveal
–
–
Finalize local state and deliver the decrypted
result to the user.
III. ASC Closure
C/S.reqCloseASC
U.closeASC
U.closeASC
Cooperative closure requested to U for imme-
diate settlement.
C.forceCloseASC
C.forceClose
C.initForceClose
C.finalForceClose
Unilateral closure by C; requires a dispute win-
dow on Ethereum.
S.forceCloseASC
S.forceClose
S.forceClose
Unilateral closure by S via adaptor signature;
no challenge period.
Liquidity Vault
U.initVault
U.initVault
U.initVault
Deposit assets into the TEE-backed vault to
create liquidity vault.
U.reqOpenVaultASC
–
–
Create a private ASC and bind specified vault
assets to ASC.
C/S.reqCloseVaultASC
–
–
Off-chain closure of a private ASC via U with-
out on-chain transactions.
U.settleVault
U.settleVault
U.settleVault
Aggregate multiple private ASC settlement for
a on-chain withdrawal.
C/S.forceSettleVault
C/S.forceSettle
C/S.initForceSettle
C/S.finalForceSettle
Emergency exit from vault; requires dispute
window on blockchain.
[13] FRASSETTO, T., JAUERNIG, P., KOISSER, D., KRETZLER, D.,
SCHLOSSER, B., FAUST, S., AND SADEGHI, A.-R.
Pose: Practi-
cal off-chain smart contract execution. In Proceedings of the 30th
Annual Network and Distributed System Security Symposium (NDSS).
[14] GARAY, J., KIAYIAS, A., AND LEONARDOS, N. The bitcoin backbone
protocol: Analysis and applications. In Annual international conference
on the theory and applications of cryptographic techniques (2015),
Springer, pp. 281–310.
[15] GE, Z., ZHANG, Y., LONG, Y., AND GU, D. Shaduf:non-cycle pay-
ment channel rebalancing. In 29th Annual Network and Distributed
System Security Symposium(NDSS) (2022), The Internet Society.
[16] GERHART, P., SCHRÖDER, D., SONI, P., AND THYAGARAJAN, S. A.
Foundations of adaptor signatures. In Annual International Conference
on the Theory and Applications of Cryptographic Techniques (2024),
Springer, pp. 161–189.
[17] GREEN, M., AND MIERS, I. Bolt: Anonymous payment channels for
decentralized currencies. In Proceedings of the 2017 ACM SIGSAC
Conference on Computer and Communications Security (CCS) (2017),
pp. 473–489.
[18] HEILMAN, E., ALSHENIBR, L., BALDIMTSI, F., SCAFURO, A., AND
GOLDBERG, S. Tumblebit: An untrusted bitcoin-compatible anony-
mous payment hub. In 24th Annual Network and Distributed System
Security Symposium, NDSS 2017, San Diego, California, USA, Febru-
ary 26 - March 1, 2017 (2017), The Internet Society.
[19] HONG, Z., GUO, S., ZHANG, R., LI, P., ZHAN, Y., AND CHEN, W.
Cycle: Sustainable off-chain payment channel network with asyn-
chronous rebalancing. In 2022 52nd Annual IEEE/IFIP International
Conference on Dependable Systems and Networks (DSN) (2022), IEEE,
pp. 41–53.
[20] HUANG, J., KONG, L., CHENG, G., XIANG, Q., CHEN, G., HUANG,
G., AND LIU, X. Advancing web 3.0: Making smart contracts smarter
on blockchain. In Proceedings of the ACM Web Conference 2024
(WWW ’24) (2024), pp. 1549–1560.
[21] KHALIL, R., AND GERVAIS, A. Revive: Rebalancing off-blockchain
payment networks. In Proceedings of the 2017 ACM SIGSAC Con-
ference on Computer and Communications Security (CCS) (2017),
pp. 439–453.
[22] LIND, J., EYAL, I., PIETZUCH, P., AND SIRER, E. G. Teechan: Pay-
ment channels using trusted execution environments. arXiv preprint
arXiv:1612.07766 (2016).
[23] LIND, J., NAOR, O., EYAL, I., KELBERT, F., SIRER, E. G., AND
PIETZUCH, P. Teechain: a secure payment network with asynchronous
blockchain access. In Proceedings of the 27th ACM Symposium on
Operating Systems Principles (2019), pp. 63–79.
[24] LIU, J., XUE, Y., PENG, Z., LIN, C., AND HUANG, X. Fairrelay:
Fair and cost-efficient peer-to-peer content delivery through payment
channel networks. arXiv preprint arXiv:2405.02973 (2024).
[25] LUO, X., XUE, K., XU, Z., AI, M., HONG, J., ZHANG, X., SUN, Q.,
AND LU, J. Ethercloak: Enabling multi-level and customized privacy
on account-model blockchains. IEEE Transactions on Dependable and
Secure Computing 22, 1 (2024), 771–786.
[26] NAKAMOTO, S. Bitcoin: A peer-to-peer electronic cash system. https:
//bitcoin.org/bitcoin.pdf, 2008.
[27] ONGARO, D., AND OUSTERHOUT, J. In search of an understandable
consensus algorithm. In 2014 USENIX annual technical conference
(USENIX ATC 14) (2014), pp. 305–319.
[28] PASS, R., SEEMAN, L., AND SHELAT, A. Analysis of the blockchain
protocol in asynchronous networks. In Annual international conference
16



=== PAGE 17 ===
on the theory and applications of cryptographic techniques (2017),
Springer, pp. 643–673.
[29] PINTO, S., AND SANTOS, N. Demystifying arm trustzone: A com-
prehensive survey. ACM computing surveys (CSUR) 51, 6 (2019),
1–36.
[30] POON, J., AND DRYJA, T. The bitcoin lightning network: Scalable
off-chain instant payments, 2016.
[31] QIN, X., PAN, S., MIRZAEI, A., SUI, Z., ERSOY, O., SAKZAD, A.,
ESGIN, M. F., LIU, J. K., YU, J., AND YUEN, T. H.
Blindhub:
Bitcoin-compatible privacy-preserving payment channel hubs support-
ing variable amounts. In 2023 IEEE symposium on security and privacy
(SP) (2023), IEEE, pp. 2462–2480.
[32] REPPEL, E., CASPERS, R., LEFFEW, K., ORGAN, D., KIM, D., AND
DALAL, N. x402: An open standard for internet-native payments.
https://www.x402.org/x402-whitepaper.pdf, May 2025. An
HTTP based protocol for agents, context retrieval, APIs, and more.
[33] ROTHSCHILD, D. M., MOBIUS, M. M., HOFMAN, J. M., DILLON,
E., GOLDSTEIN, D. G., IMMORLICA, N., JAFFE, S., LUCIER, B.,
SLIVKINS, A., AND VOGEL, M. The agentic economy. Commun.
ACM 69, 2 (Jan. 2026), 39–42.
[34] TAS, A., ET AL. Atomic and fair data exchange via blockchain. In
Proceedings of the 2024 ACM SIGSAC Conference on Computer and
Communications Security (CCS) (2024).
[35] VANJANI, N., SONI, P., AND THYAGARAJAN, S. A. Functional adap-
tor signatures: Beyond all-or-nothing blockchain-based payments. In
Proceedings of the 2024 on ACM SIGSAC Conference on Computer
and Communications Security (2024), pp. 1493–1507.
[36] VAZIRY, A., GARZON, S. R., AND KÜPPER, A.
Towards multi-
agent economies: Enhancing the a2a protocol with ledger-anchored
identities and x402 micropayments for ai agents.
arXiv preprint
arXiv:2507.19550 (2025).
[37] WEN, X., FENG, Q., NIU, J., ZHANG, Y., AND FENG, C. Mercury:
Practical cross-chain exchange via trusted hardware. IEEE Transac-
tions on Dependable and Secure Computing (2025).
[38] WOOD, G., ET AL. Ethereum: A secure decentralised generalised
transaction ledger. Ethereum project yellow paper 151 (2014), 1–32.
[39] WUILLE, P., NICK, J., AND RUFFING, T. Bip 340: Schnorr signatures
for secp256k1. https://github.com/bitcoin/bips/blob/maste
r/bip-0340.mediawiki, 2020.
[40] WUILLE, P., NICK, J., AND RUFFING, T. BIP 341: Taproot: Segwit
Schnorr signature Outputs. https://github.com/bitcoin/bips/
blob/master/bip-0341.mediawiki, 2020.
[41] WÜST, K., DIANA, L., KOSTIAINEN, K., KARAME, G., MATETIC, S.,
AND CAPKUN, S. Bitcontracts: Supporting smart contracts in legacy
blockchains. In 28th Annual Network and Distributed System Security
Symposium, NDSS 2021, virtually, February 21-25, 2021 (2021), The
Internet Society.
[42] WÜST, K., MATETIC, S., EGLI, S., KOSTIAINEN, K., AND CAPKUN,
S. Ace: Asynchronous and concurrent execution of complex smart
contracts. In Proceedings of the 2020 ACM SIGSAC Conference on
Computer and Communications Security (New York, NY, USA, 2020),
CCS ’20, Association for Computing Machinery, p. 587–600.
[43]
X402 WORKING GROUP. x402: The open standard for web3-to-web2
payment integration via http 402. https://www.x402.org/, 2025.
Accessed: 2026-01-01.
[44] YANG, Y., MA, M., HUANG, Y., CHAI, H., GONG, C., GENG, H.,
ZHOU, Y., WEN, Y., FANG, M., CHEN, M., ET AL. Agentic web:
Weaving the next web with ai agents. arXiv preprint arXiv:2507.21206
(2025).
17