Payment Channels Supporting Proofs

• Payment channels supporting proofs are off-chain protocols that embed verifiable artifacts—such as digital signatures, zk-SNARKs, and TEE attestations—to enforce both payment authorization and external condition fulfillment.
• They employ techniques like cross-chain state attestation, batched notarization, and fraud proofs to enhance security, scalability, and reliable dispute resolution in decentralized payment systems.
• These channels enable conditional settlement for services, data, and theorem verification by integrating cryptographic and formal proofs, thereby linking logical correctness with financial transactions.

Payment channels supporting proofs are channel constructions and adjacent off-chain payment mechanisms in which settlement, state progression, or dispute resolution is coupled to verifiable artifacts beyond bare balance updates. Across the literature, these artifacts include Bitcoin signatures over transaction templates verified by a foreign chain, zk-SNARK proofs over public balances, TEE attestations and adaptor signatures binding execution to payment, fraud proofs emitted by watchtowers, committee quorum certificates for channel states, and on-chain predicates such as OP_PROVEN for formal provability (Watanabe et al., 2018, Yu et al., 2022, Li et al., 1 Mar 2026, Brown et al., 10 Sep 2025). The common objective is to decide not only whether a transfer was authorized, but whether some external condition—service correctness, data availability, result delivery, privacy-preserving balance disclosure, or theorem provability—has been satisfied.

1. Scope and proof objects

Editor’s term, “proof-carrying channels,” usefully denotes the family of constructions in which a channel update or contingent payout is meaningful only together with a proof object that some verifier can consume. In the surveyed literature, those proof objects serve at least five roles: state attestation, cross-chain verification, service-conditional settlement, fraud detection, and formal protocol correctness (Watanabe et al., 2018, Li et al., 1 Mar 2026, Yu et al., 2022, Avarikioti et al., 2018, Avarikioti et al., 2019, Avarikioti et al., 24 Jan 2025).

Setting	Proof artifact	Operational role
Niji	Bitcoin ECDSA signature over a transaction template	Verifies a Bitcoin channel update on a consortium chain
A402	TEE attestation, adaptor pre-signature, encrypted result	Enforces Exec–Pay–Deliver atomicity
zk-PCN	zk-SNARK on public balances	Certifies routing-visible liquidity without revealing true balances
DCWC / fail-safe towers	Signed newer state, fraud proof, tower receipt	Detects stale-state closure and tower failure
SyncPCN / PSyncPCN	Committee signatures and quorum certificates	Resolve disputes without blockchain synchrony
Proofgold	OP_PROVEN and PTLC/HTLC composition	Makes formal provability a spend condition

The literature also distinguishes between cryptographic proofs embedded in protocol execution and formal proofs about protocol behavior. Fulgor and Rayo are specified in the Universal Composability framework; Brick and Thunderdome prove balance security and liveness under asynchronous or timelock-free assumptions; SyncPCN/PSyncPCN derive both impossibility and possibility results for committee-based multi-hop payment protocols (Malavolta et al., 2019, Avarikioti et al., 2019, Avarikioti et al., 24 Jan 2025, Ersoy et al., 2022).

2. Cross-chain state attestation and delegated verification

Niji exemplifies cross-chain proof verification through a payment channel whose updates are checked by a smart contract on another blockchain. A Bitcoin payment channel is opened between a user and a service provider, but a “bridging contract” on a consortium chain stores a transaction template $\tilde T$. For each payment, the user sends only a Bitcoin signature $Sig^u$ and amount $\sigma$; the bridging contract reconstructs the Bitcoin signing preimage, recovers the public key with EcdsaRecover, verifies the signature, checks monotonicity and deposit bounds, and, if valid, invokes the service contract. Niji explicitly does not use SPV or Merkle proofs; the proof is the Bitcoin signature on the intended update transaction. The prototype reports update costs of about $455$k gas in the uni-directional design and $468$k gas in the bi-directional design, with a mean end-to-end payment latency of about $2097$ ms in the evaluation environment (Watanabe et al., 2018).

PayPlace moves the proof surface from cross-chain signature verification to batched notarization. Each consumer maintains a virtual unidirectional channel to an operator via monotonically increasing signed receipts $T=(\mu, pk_\omega, pk_c)$. The operator aggregates operator-to-merchant receipts into a Merkle tree whose root is signed by merchants using BLS aggregate signatures. Merchant withdrawal then requires a Merkle proof, source receipts from consumers, and contract-side checks that withdrawals do not exceed the operator’s off-chain claim against any consumer. The design claims $O(1)$ on-chain monetary and computational costs in the number of payment transactions processed, and near-constant cost in other parameters in most scenarios (Harishankar et al., 2020).

These constructions treat proof objects as reusable verification interfaces. In Niji, the verifier is a foreign smart contract; in PayPlace, it is a settlement contract that accepts Merkle-root commitments and aggregated signatures. This suggests a general pattern in which the channel state is not merely private bilateral state but a verifiable object exportable to other execution environments.

3. Service- and data-contingent settlement

“Recurring Contingent Service Payment” formalizes a generic blockchain-based construction for repeated fair exchange of digital coins and a verifiable service. RC-S-P is defined to let clients and a server reoccur securely while ensuring that the server is paid if and only if it delivers a valid service, and that parties’ privacy is preserved. The construction supports arbitrary verifiable services such as Proofs of Retrievability or verifiable computation, considers malicious client and malicious server behavior, and is presented as mitigating a free-riding attack present in two CCS 2017 PoR-payment protocols. In its concrete PoR instantiation, when dealing with a 4-GB outsourced file, a verifier can check a proof in only $90$ milliseconds and a dispute between prover and verifier is resolved in $0.1$ milliseconds (Abadi et al., 2022).

A402 pushes this model into a fully proof-aware channel abstraction. Its Atomic Service Channels define execPayDeliver so that payment is finalized iff service was correctly executed and result delivered. The concrete state machine uses $Sig^u$0 with statuses OPEN, LOCKED, PENDING, and CLOSED. “Correct execution” is defined operationally by TEE attestation and code hash: inside the TEE, the provider computes $Sig^u$1, samples $Sig^u$2, computes $Sig^u$3, and generates an adaptor pre-signature over

$Sig^u$4

The same secret $Sig^u$5 both adapts the pre-signature into a valid payment signature and decrypts the encrypted result. A liquidity vault hides per-request activity by aggregating settlements into a single on-chain transaction that reveals only aggregated balances. The prototype reports peak throughput of $Sig^u$6 requests/sec, end-to-end latency of about $Sig^u$7–$Sig^u$8 ms, Ethereum standard-mode channel cost of $Sig^u$9 gas, liquidity-vault cost of $\sigma$0 gas, and Bitcoin channel footprint of $\sigma$1 vB per channel (Li et al., 1 Mar 2026).

“Fair Data Exchange at Near-Plaintext Efficiency” applies the same conditional-payment idea to large data objects. It observes that a KZG commitment to polynomial evaluations also binds to the Reed–Solomon codeword of its coefficients, then combines a lightweight hash-derived mask on the entire RS-extended codeword with ElGamal encryption only on a pseudorandom $\sigma$2 subset of symbols. A constant-time zk-SNARK enforces consistency between the masking layer and the ElGamal layer, and another constant-time zk-SNARK proves the relation

$\sigma$3

thereby linking a BLS12-381 decryption key to a secp256k1 HTLC hash preimage for Lightning. The paper states that this can reduce transaction fees from roughly $\sigma$4 and shorten transaction latency from tens of seconds on Ethereum down to about a second or less (Khabbazian, 17 Jun 2025).

Taken together, these systems shift the predicate “payment authorized” to “payment authorized and externally justified.” The external justification may be a PoR proof, attested service execution, or a zero-knowledge-checked decryption relation.

4. Privacy-preserving routing and zero-knowledge balance proofs

zk-PCN treats proof generation as part of routing-state publication. Each channel maintains hidden true balances and public lower bounds called public balances. A zk-SNARK proves that the public balances are consistent with a valid transaction history and do not exceed the true balances. Because routing is performed over public balances, any path feasible under public balances is guaranteed feasible under true balances, while exact liquidity remains hidden. The improved zk-IPCN variant introduces a reactive proof generation algorithm, reducing proof dissemination and storage by localizing proof exchange to route discovery. Reported proof size is $\sigma$5 bytes, verifier time is about $\sigma$6–$\sigma$7 ms, and proof generation ranges from $\sigma$8 ms to $\sigma$9 ms as the number of hash checks grows from $455$0 to $455$1. Under uniform payments, zk-PCN is reported as up to $455$2 better than Lightning in success rate, and zk-IPCN reduces proofs per transaction from slopes of about $455$3 to $455$4 in the uniform case and $455$5 to $455$6 in the skewed case (Yu et al., 2022).

Fulgor and Rayo use proofs not to certify balances but to protect privacy and concurrency semantics. Their core primitive, Multi-Hop HTLC, replaces a single shared hash condition with hop-specific conditions tied together by a NIZK proof for

$455$7

Fulgor is proved UC-secure and provides value privacy and relationship anonymity while remaining compatible with the Bitcoin scripting system, but it is blocking. Rayo introduces global payment identifiers and queueing to enforce non-blocking progress; the paper proves an impossibility result showing that non-blocking progress necessarily comes at the cost of weaker privacy (Malavolta et al., 2019).

This branch of the literature treats proofs as routing-time attestations and as formal privacy arguments. The visible effect is that a PCN can expose enough information for route selection or concurrency control while constraining the leakage to what is proved unavoidable.

5. Watchtowers, fraud proofs, and externalized monitoring

“Towards Secure and Efficient Payment Channels” turns stale-state detection into an explicit fraud-proof protocol. In DCWC (Disclose–Cascade–Watch–Commit), watchtowers receive disseminated evidence of the newest update $455$8 and each stores only one message $455$9 per channel: the newest one. If a stale settlement $468$0 with $468$1 appears on-chain, a watchtower can submit a fraud proof carrying the newer state and the authenticated propagation path. The protocol reserves a reward $468$2 in the channel for successful fraud proofs and derives an expected-payoff expression showing that a watchtower cannot improve its expected payoff by deviating. The same paper also introduces xD-channels, whose state is

$468$3

with at most one outgoing edge per vertex, and computes final outgoing payments $468$4 as the solution of a constrained maximization problem over signed payment commitments $468$5 (Avarikioti et al., 2018).

“Fail-safe Watchtowers and Short-lived Assertions for Payment Channels” changes the watchtower role from constant on-chain monitoring to periodic batched confirmation. The watchtower stores the latest hashed state $468$6, signs a receipt $468$7, and later submits a single update(Confs) transaction that confirms or denies all pending closures in a batch. The channel contract uses a short deadline ddl and a long timeout end; if the tower confirms, closure is accelerated, and if it denies or fails to respond, the channel enters a fail-safe state in which parties can still dispute and later finalize correctly. A challenge call can prove tower misbehavior either by showing that the tower signed a newer state than the one effectively used or by showing that the tower never responded. The same paper introduces short-lived assertions, in which off-chain states include a recent block hash so that freshness can be checked without employing a tower, a mechanism explicitly motivated by payment scenarios in which $468$8 (Liu et al., 2020).

These architectures externalize proof production to specialized services. Their contribution is not only that they can detect stale closures, but that they make failure of the proof service itself observable and punishable.

6. Asynchrony, committees, and timelock-free security

The asynchronous literature distinguishes sharply between what can be proved secure with timeouts and what can be proved secure without them. “On Payment Channels in Asynchronous Money Transfer Systems” proves a quadratic lower bound on the message complexity of direct on-chain transfers, shows that unidirectional channels can be implemented as a second layer with $468$9 off-chain messages per transfer, and proves that bidirectional channels cannot be implemented in the asynchronous message-passing model. Its implementable unidirectional construction treats the latest signed transfer transaction spending a multisig account as the proof object, which the target can later co-sign and settle on the underlying asset-transfer abstraction (Naor et al., 2022).

Brick replaces timelock-based dispute races with wardens and consistent broadcast. A Brick channel uses $2097$0 wardens, requires $2097$1 signatures to commit an update, and gives each warden collateral of at least $2097$2, where $2097$3 is channel value. Theorems in the paper state that Brick achieves safety and liveness under asynchrony; Brick+ adds auditability through a hashchain of committed states. The reported off-chain update latency is $2097$4 s for $2097$5 wardens, $2097$6 s for $2097$7, and $2097$8 s for $2097$9, and contract deployment cost is about $T=(\mu, pk_\omega, pk_c)$0 EUR at the evaluation point (Avarikioti et al., 2019).

SyncPCN/PSyncPCN extends committee adjudication to multi-hop settings but also proves a limit. The paper shows that it is impossible to design a multi-hop payment protocol with both network asynchrony and faulty channels. SyncPCN therefore assumes synchronous communication and uses committees to register channel-state hashes and resolve disputes, while PSyncPCN assumes committees with at most $T=(\mu, pk_\omega, pk_c)$1 faulty members out of $T=(\mu, pk_\omega, pk_c)$2 and lets committees successively delegate the role of eventually completing a multi-hop payment in an asynchronous setting. In both cases, quorum certificates replace the blockchain as the primary proof carrier for conditional payment resolution (Ersoy et al., 2022).

Thunderdome removes timelocks entirely from virtual channels. It uses wardens, proof-of-fraud, and cross-checking between underlying channel contracts, and proves balance security and liveness under an asynchronous Byzantine model. It further provides a game-theoretic analysis in which honest protocol following is characterized as a Subgame-Perfect Nash Equilibrium under the condition $T=(\mu, pk_\omega, pk_c)$3, with $T=(\mu, pk_\omega, pk_c)$4 the warden collateral and $T=(\mu, pk_\omega, pk_c)$5 the virtual channel balance. The implementation reports approximately $T=(\mu, pk_\omega, pk_c)$6 for the worst-case close (Avarikioti et al., 24 Jan 2025).

This strand of work treats proofs in two senses simultaneously: as operational evidence used to close or revoke a channel, and as formal arguments that a class of channels remains secure under asynchronous networks, committee faults, or rational deviations.

7. Provability as a settlement predicate

“Payment Channels with Proofs” makes formal provability itself a channel condition. In Proofgold, propositions are represented by hash roots, and the scripting language exposes OP_PROVEN, which returns true if the blockchain proof ledger records that $T=(\mu, pk_\omega, pk_c)$7 has been proven. The resulting Proposition Time-Locked Contract is

$T=(\mu, pk_\omega, pk_c)$8

spendable either by a proof-based branch—OP_PROVEN P and a signature by $T=(\mu, pk_\omega, pk_c)$9—or by a timeout-based branch—OP_CLTV T and a signature by $O(1)$0. To preserve revocability in a Lightning-style setting, the paper wraps this inside an HTLC,

$O(1)$1

This lets two channel participants bet on whether a proposition will be proven by a given time, request proofs by taking the “no proof by $O(1)$2” side, and provide proofs by taking the “proof by $O(1)$3” side. The paper further notes that stakes $O(1)$4 and $O(1)$5 on the two sides of the bet induce an informal probability estimate $O(1)$6, suggesting a prediction-market interpretation for provability (Brown et al., 10 Sep 2025).

This construction is distinct from service proofs or fraud proofs because the external predicate is not operational correctness but theorem existence. The channel no longer just prices time or liquidity; it prices logical discovery. A plausible implication is that proof-supporting payment channels form a continuum: at one end they verify signatures, commitments, and state certificates; at the other they treat the existence of a formal proof as the payout condition itself.