Atomic Service Channels (ASCs)

• Atomic Service Channels (ASCs) are off-chain constructions that atomically bind service execution with payment settlement to prevent intermediate state leakage.
• They employ advanced cryptographic techniques such as zk-SNARKs, VSS, and TEE-assisted adaptor signatures to enforce fairness and secure state transitions.
• Empirical evaluations demonstrate that ASCs achieve high throughput, significantly lower on-chain costs, and minimal settlement latency compared to standard payment channels.

Atomic Service Channels (ASCs) are off-chain channel constructions that bind service exchange to balance settlement so that the composite interaction is atomic rather than decomposed into separable payment and delivery steps. In the current arXiv literature, the term is used in two closely related but non-identical senses. In Cross-Channel, an ASC between parties $\mathcal{S}$ and $\mathcal{R}$ spanning blockchains $\alpha$ and $\beta$ is a pair of off-chain state channels $\Omega^\alpha_0,\Omega^\beta_0$ for high-frequency cross-chain services such as payments, information exchanges, and barter trades. In A402, an ASC with respect to blockchain $\mathcal{L}$ is a tuple $(C,S,\Gamma)$ that integrates service execution into a payment channel for Machine-to-Machine commerce, with explicit exec-pay-deliver atomicity and optional private settlement through a TEE-based Liquidity Vault (Guo et al., 2022, Li et al., 1 Mar 2026).

1. Definitions and conceptual scope

Cross-Channel defines the atomicity goal as an all-or-nothing property over the paired channels: either $\mathcal{S}$ and $\mathcal{R}$ remain in their pre-service states, or they swap states atomically so that $\mathcal{S}$ obtains $\mathcal{R}$0-offered assets and $\mathcal{R}$1 obtains $\mathcal{R}$2-offered assets, with no intermediate leakage. Its notion of fairness is that neither party can learn or enjoy the exchanged object—cryptocurrency, encrypted data, or digital commodity—before the other party has irrevocably committed its own side. A402 formalizes an ASC as $\mathcal{R}$3, where $\mathcal{R}$4, $\mathcal{R}$5, and $\mathcal{R}$6. It exposes three interfaces: $\mathcal{R}$7

$\mathcal{R}$8

$\mathcal{R}$9

A402 also contrasts ASCs with a standard payment channel $\alpha$0, which tracks only $\alpha$1 and supports Open, Pay, and Close. In that formulation there is no notion of service execution or result delivery, and state transitions are purely asset-centric. The explicit consequence given is that such channels lack any binding between off-chain service execution and on-chain payment, leading to fairness violations such as free-riding or non-payment.

Dimension	Cross-Channel ASC	A402 ASC
Formal object	pair $\alpha$2	tuple $\alpha$3
Primary setting	cross-chain services across $\alpha$4	Web 3.0 payments bound to Web 2.0 services
Native operations	hierarchical off-chain service exchange and cross-chain settlement	$\alpha$5, $\alpha$6, $\alpha$7
Core enforcement	hierarchical settlement, general fair exchange, HTLC-style hash-timelock	TEE-assisted adaptor signatures, dispute window, TEE-based Liquidity Vault

These definitions place ASCs at the intersection of payment channels, fair exchange, and interoperability. This suggests that the term is not merely a synonym for a faster payment channel, but a label for protocols that make service semantics part of the channel state and settlement logic (Guo et al., 2022, Li et al., 1 Mar 2026).

2. Channel architecture and state semantics

The Cross-Channel construction is organized around a hierarchical channel structure designed to avoid the “Unsettled-Amount Congestion” problem, namely funds that are reserved but cannot be re-used until channel closure. Each channel $\alpha$8 carries a state

$\alpha$9

subject to the invariant

$\beta$0

where $\beta$1 is the on-chain deposit of $\beta$2. At layer $\beta$3, the ASC consists of the main channels $\beta$4. When a party needs to spend an unsettled receipt $\beta$5 of value $\beta$6 in $\beta$7, it negotiates a sub-channel $\beta$8 at layer $\beta$9 with another counterparty to re-use that $\Omega^\alpha_0,\Omega^\beta_0$0 off-chain. More generally, a layer-$\Omega^\alpha_0,\Omega^\beta_0$1 channel $\Omega^\alpha_0,\Omega^\beta_0$2 may spawn a layer-$\Omega^\alpha_0,\Omega^\beta_0$3 sub-channel $\Omega^\alpha_0,\Omega^\beta_0$4 to mobilize newly issued, unsettled receipts of its parent. If the network contains $\Omega^\alpha_0,\Omega^\beta_0$5 nodes and each pair shares a persistent channel at layer $\Omega^\alpha_0,\Omega^\beta_0$6, then exchanged receipts flow off-chain until closure, giving effectively $\Omega^\alpha_0,\Omega^\beta_0$7 parallel throughput.

A402 uses a narrower but more explicit state machine. During atomic exchange, the state variable maintained by $\Omega^\alpha_0,\Omega^\beta_0$8 and $\Omega^\alpha_0,\Omega^\beta_0$9 is

$\mathcal{L}$0

where $\mathcal{L}$1 is a version counter and $\mathcal{L}$2 during channel operation. The creation phase begins when $\mathcal{L}$3 calls $\mathcal{L}$4. The delegated manager $\mathcal{L}$5 initializes its TEE committee per policy $\mathcal{L}$6, checks that no existing $\mathcal{L}$7 exists, and ensures a secure channel $\mathcal{L}$8 with $\mathcal{L}$9. It then runs $(C,S,\Gamma)$0, submits $(C,S,\Gamma)$1 to $(C,S,\Gamma)$2, and awaits confirmation. On-chain, $(C,S,\Gamma)$3 locks $(C,S,\Gamma)$4 funds in a 2-of-2 or smart-contract address; locally, $(C,S,\Gamma)$5 and $(C,S,\Gamma)$6 record $(C,S,\Gamma)$7 in state $(C,S,\Gamma)$8.

The architectural difference is direct. Cross-Channel generalizes balance mobility by recursively nesting sub-channels, whereas A402 serializes service execution inside one channel by enforcing the state trajectory $(C,S,\Gamma)$9, thereby ensuring exactly one request in flight (Guo et al., 2022, Li et al., 1 Mar 2026).

3. Atomic exchange and fair-service enforcement

Cross-Channel’s general fair exchange protocol $\mathcal{S}$0 is built from zk-SNARK and Pedersen $\mathcal{S}$1-VSS. In setup, the parties build an arithmetic circuit $\mathcal{S}$2 that, on private inputs $\mathcal{S}$3, verifies three conditions: $\mathcal{S}$4 encrypts under key $\mathcal{S}$5 to ciphertext $\mathcal{S}$6; $\mathcal{S}$7 shares into $\mathcal{S}$8 via $\mathcal{S}$9-VSS; and the hash-locks $\mathcal{R}$0 match public values. Then $\mathcal{R}$1. In the share phase, each party runs Pedersen $\mathcal{R}$2-VSS.Share on the secret key $\mathcal{R}$3, commits $\mathcal{R}$4, uploads $\mathcal{R}$5 on-chain, selects $\mathcal{R}$6 random miners, and encrypts and signs shares to them; miners verify commitments and may appeal on-chain if a share is invalid. In the exchange phase, the sender computes $\mathcal{R}$7 and

$\mathcal{R}$8

and the parties swap $\mathcal{R}$9, after which each runs $\mathcal{S}$0. In the recover phase, both send on-chain $\mathcal{S}$1 requests, VSS recipients submit $\mathcal{S}$2, the contract verifies $\mathcal{S}$3, and once at least $\mathcal{S}$4 valid shares are collected, the requester reconstructs $\mathcal{S}$5 by Lagrange interpolation and decrypts.

Cross-chain settlement in Cross-Channel then uses an HTLC-style hash-timelock on final channel balances. Parties lock final states under hash $\mathcal{S}$6 with time-outs $\mathcal{S}$7, and the “lock”, “update”, and “refund” steps mirror classic HTLC. The fairness guarantee in $\mathcal{S}$8 rests on

$\mathcal{S}$9

where $\mathcal{R}$00 is the maximum number of Byzantine miners. The stated consequence is twofold: no $\mathcal{R}$01-colluding adversaries can reconstruct $\mathcal{R}$02, and at least $\mathcal{R}$03 honest nodes can always supply shares for correct recovery.

A402 replaces zk-SNARK/VSS fair exchange with an atomic exchange protocol based on TEE-assisted adaptor signatures. After $\mathcal{R}$04 locks $\mathcal{R}$05 by moving balance from $\mathcal{R}$06 to $\mathcal{R}$07 and setting $\mathcal{R}$08, $\mathcal{R}$09 executes the request inside a TEE, samples $\mathcal{R}$10, sets $\mathcal{R}$11, encrypts the result as $\mathcal{R}$12, computes $\mathcal{R}$13 and $\mathcal{R}$14, and generates the adaptor pre-signature $\mathcal{R}$15. The manager verifies $\mathcal{R}$16, issues the conditional payment signature $\mathcal{R}$17, and moves the state to $\mathcal{R}$18. The provider then either reveals $\mathcal{R}$19 off-chain or performs on-chain fallback by computing $\mathcal{R}$20 and calling $\mathcal{R}$21. On secret reveal, $\mathcal{R}$22 decrypts $\mathcal{R}$23, adjusts balances, returns the channel to $\mathcal{R}$24, and delivers the result to $\mathcal{R}$25.

A402 states the end-to-end property as exec-pay-deliver atomicity. Its formal definition is

$\mathcal{R}$26

The accompanying argument is that the TEE enforces execution before $\mathcal{R}$27, while the adaptor signature ensures that payment finalization reveals $\mathcal{R}$28, which is the decryption key for the result (Guo et al., 2022, Li et al., 1 Mar 2026).

4. Closure, settlement, and liquidity aggregation

Cross-Channel closes by running the same close routine simultaneously in $\mathcal{R}$29 and $\mathcal{R}$30. After CloseRequest messages from all parties, the smart contract $\mathcal{R}$31 sets the state to $\mathcal{R}$32, starts a timer $\mathcal{R}$33, and broadcasts a CloseEvent. While $\mathcal{R}$34 has not expired, each party uploads $\mathcal{R}$35, its computed final balance vector at its channel level, together with the set $\mathcal{R}$36 of sub-channel receipts it opened. On expiry, $\mathcal{R}$37 verifies each channel layer by layer from level $\mathcal{R}$38 to level $\mathcal{R}$39. If $\mathcal{R}$40 or signatures are invalid, then $\mathcal{R}$41 and all its descendants are marked $\mathcal{R}$42; otherwise the contract sets on-chain balances per $\mathcal{R}$43. Any failure at layer $\mathcal{R}$44 invalidates that layer and all higher layers. Every successful layer deposits its final state; failed ones revert to parent balances.

A402 separates cooperative closure, unilateral client closure, unilateral provider closure, and vault settlement. In the cooperative path, $\mathcal{R}$45 or $\mathcal{R}$46 requests closure, $\mathcal{R}$47 runs $\mathcal{R}$48, $\mathcal{R}$49 executes $\mathcal{R}$50, and the state becomes $\mathcal{R}$51. In unilateral client closure, $\mathcal{R}$52 starts an on-chain procedure with dispute window $\mathcal{R}$53; if no challenge is raised, $\mathcal{R}$54 finalizes closure and the state becomes $\mathcal{R}$55. In unilateral provider closure, $\mathcal{R}$56 acts differently depending on channel state: if $\mathcal{R}$57, the result is cooperative-style close; if $\mathcal{R}$58, the on-chain close with adaptor signature reveals $\mathcal{R}$59 on-chain, allowing $\mathcal{R}$60 to extract it and decrypt the result before final closure.

The TEE-based Liquidity Vault extends A402 from per-channel settlement to private balance aggregation. Each participant $\mathcal{R}$61 has off-chain vault state $\mathcal{R}$62. After $\mathcal{R}$63 submits $\mathcal{R}$64 to $\mathcal{R}$65, the vault committee records the deposit by increasing $\mathcal{R}$66. Opening a private ASC from vault balances requires no on-chain transaction: the vault debits $\mathcal{R}$67, generates $\mathcal{R}$68, and creates $\mathcal{R}$69 off-chain. Closure credits balances back when $\mathcal{R}$70. Settlement later aggregates the free balance into a single on-chain transaction

$\mathcal{R}$71

after which $\mathcal{R}$72. The exposed on-chain quantity is only the aggregate

$\mathcal{R}$73

in one $\mathcal{R}$74 (Guo et al., 2022, Li et al., 1 Mar 2026).

5. Security model, dispute handling, and interpretive issues

Cross-Channel assumes that $\mathcal{R}$75 and $\mathcal{R}$76 may be arbitrarily malicious and that miners run a BFT chain tolerating $\mathcal{R}$77 Byzantine nodes. The fairness of $\mathcal{R}$78 is attributed to zk-SNARK soundness and zero-knowledge together with the $\mathcal{R}$79-VSS thresholds, so that there is no information leak and proofs are unforgeable. Invalid share appeals are stated to abort safely even under asynchronous delays. Atomicity of cross-chain settlement is guaranteed by the HTLC timers $\mathcal{R}$80. To mitigate asynchrony, an extra timer $\mathcal{R}$81 allows any honest miner who learns $\mathcal{R}$82 after timeout to complete the settlement and claim a small on-chain reward. Latency avoidance is achieved because payments, data swaps, and sub-channel openings occur off-chain, while on-chain interaction is limited to channel open and close, key-share appeals, and final HTLC locks and updates.

A402 frames its guarantees as trust-minimized asset security, exec-pay-deliver atomicity, and unlinkability in vault mode. Regardless of $\mathcal{R}$83 or $\mathcal{R}$84 availability or honesty, $\mathcal{R}$85 and $\mathcal{R}$86 can unilaterally force on-chain settlement via $\mathcal{R}$87 or $\mathcal{R}$88, and assets are never locked indefinitely because of the challenge windows. Its primitive set explicitly includes adaptor signatures $\mathcal{R}$89, collision-resistant hash $\mathcal{R}$90, symmetric encryption $\mathcal{R}$91, and TEE remote attestation $\mathcal{R}$92. In vault mode, on-chain observers see vault initialization and settlement, but not individual ASC creation and closure, so the observer cannot link $\mathcal{R}$93 or the client-service graph for individual ASCs.

A recurring misunderstanding addressed directly by the literature is the identification of ASCs with ordinary payment channels. A402 rejects that equivalence by defining the absence of service execution and result delivery as the central limitation of $\mathcal{R}$94. Cross-Channel broadens the exchange object beyond coins to encrypted data and digital commodities, while preserving on-chain recourse. This suggests that the defining feature of an ASC is not simply off-chain balance movement, but an enforceable coupling between service execution, counter-performance, and final settlement (Guo et al., 2022, Li et al., 1 Mar 2026).

6. Empirical evaluation and practical significance

Cross-Channel was deployed on two 100-node Ethereum testnets (PoW) across 50 AliCloud VMs, simulating up to $\mathcal{R}$95 transactions per chain. Reported gas consumption at Gwei price $\mathcal{R}$96 is approximately $\mathcal{R}$97 k gas for Open, approximately $\mathcal{R}$98 k gas for Upload (key shares), approximately $\mathcal{R}$99 k gas for Close (hierarchical settlement), $\alpha$00–$\alpha$01 k gas for Lock/Update, and approximately $\alpha$02 k gas for Update-EIE (with key recovery). For $\alpha$03 cross-chain exchanges, the paper reports that Cross-Channel uses approximately $\alpha$04 M gas total, while a naïve HTLC uses $\alpha$05 M $\alpha$06 and MAD-HTLC uses $\alpha$07 M $\alpha$08. Transaction confirmation latency for open, lock, update, and close remains $\alpha$09–$\alpha$10 s even at $\alpha$11 nodes. Throughput scales linearly in $\alpha$12 channels: with $\alpha$13 channels, approximately $\alpha$14 nodes $\alpha$15 per channel, the system sustained $\alpha$16 receipts/s in pure coin exchange and $\alpha$17 Tr/s in encrypted-info exchange. Off-chain cryptographic overhead is also quantified: zk-SNARK proving time is sub-second even for $\alpha$18-block messages, proof size is approximately $\alpha$19 kB, verification is approximately ms, and VSS.Share, Verify, and Recover are all msec-level at $\alpha$20 up to $\alpha$21.

A402 reports both Ethereum and Bitcoin integrations and evaluates them against x402. On Ethereum, the ASC Manager contract exposes createASC, closeASC, initForceClose, finalForceClose, forceClose, initVault, settleVault, initForceSettle, and finalForceSettle. Standard ASC mode costs $\alpha$22 gas for createASC and $\alpha$23 gas for closeASC, for a total of $\alpha$24 gas ($\alpha$25). The x402 baseline is $\alpha$26 gas, stated as $\alpha$27 per request. On Bitcoin, using Taproot (P2TR) with MAST, createASC costs $\alpha$28 vB ($\alpha$29), and total channel cost is $\alpha$30 vB ($\alpha$31) and $\alpha$32 costs $\alpha$33 vB ($\alpha$34) per request, which the paper characterizes as linear $\alpha$35.

For off-chain performance, A402 reports a peak throughput of $\alpha$36 RPS at $\alpha$37 concurrent requests and average latency rising from $\alpha$38 ms to $\alpha$39 ms as load scales from $\alpha$40 to $\alpha$41. It compares this with on-chain baselines of approximately $\alpha$42 TPS for Ethereum and approximately $\alpha$43 TPS for Bitcoin, yielding approximately $\alpha$44 and approximately $\alpha$45 higher throughput respectively, and contrasts sub-second ASC latency with seconds-to-minutes on mainnets, including approximately $\alpha$46 s for Solana, approximately $\alpha$47 min for Ethereum, and approximately $\alpha$48 min for Bitcoin. At $\alpha$49 requests on Ethereum, the reported costs are $\alpha$50 gas $\alpha$51 for vault A402, and $\alpha$52 gas $\alpha$53 for A402 versus $\alpha$54 vB $\alpha$55 for x402, for a $\alpha$56 reduction. Appendix results further state that adding more vault replicas scales capacity linearly while per-request latency remains stable because it is dominated by service execution and network delay.

Taken together, the empirical record distinguishes two operating regimes. Cross-Channel emphasizes high-frequency and large-scale cross-chain services with amortized on-chain cost across many off-chain operations, while A402 emphasizes real-time micropayments for Web 3.0/Web 2.0 service composition with private settlement aggregation. A plausible implication is that the ASC label now covers at least two protocol lineages: one centered on cross-chain fair exchange with hierarchical settlement, and one centered on service-integrated payment channels with TEE-assisted execution and vault-based balance privacy (Guo et al., 2022, Li et al., 1 Mar 2026).