Skip to main content
Experimental TechnologyLightning Channels on Arkade are experimental and under active development. The examples and scripts presented here are for research and proof-of-concept use only. Do not deploy in production environments.

Lightning Channel Example

Reference implementation of Lightning Channels on Arkade by Vincenzo Palazzo
 Arkade can serve as a channel factory for Lightning Network channels. The Arkade Server participates in channel lifecycle operations (funding, renewing, resizing, closing) but never touches payment traffic. HTLCs route over standard Lightning rails between Alice and Bob. This use case builds on the Dryja-Poon contract channel construction.

​
Design principles

The Server coordinates liquidity. It does not intermediate payments. Channel funding can happen immediately via preconfirmation. Users who find the preconfirmation trust assumption acceptable (typical for smaller channels or trusted counterparties) can begin using channels right away. Users requiring Bitcoin finality wait for the next signing session that creates a Batch. Arkade compresses many previously preconfirmed operations from the Virtual Mempool DAG into a single onchain settlement. Channel opens, closes, and resizes all collapse into a single onchain footprint regardless of how many channel operations the DAG contains. Once a channel exists, Alice and Bob operate it as a standard Lightning channel. Commitment transactions, revocation, and HTLC forwarding follow BOLT specifications. The Server is not involved. The Server re-enters the picture only when the channel’s underlying VTXO approaches Batch expiry or when the parties want to resize, close, or migrate the channel.

​
Channel lifecycle

​
Funding

Alice and Bob submit an Arkade transaction producing a VTXO with the funding output script. With preconfirmation, the channel is usable immediately. They exchange initial commitment transactions following standard channel establishment.

​
Normal operation

The channel operates as standard Lightning. Alice and Bob exchange commitment transactions, rotate revocation secrets, and forward HTLCs. The Server has no role. Latency and trust properties match vanilla Lightning.

​
Renewal

VTXOs expire at Batch expiry. Before expiry, the channel must migrate into a new Batch output. The simple path: either party submits an Arkade transaction attaching the channel VTXO to a new output. This is non-interactive between channel participants. No quiescence required for basic renewal.
For users requiring Bitcoin finality throughout the renewal process. This flow assumes one channel party is an LSP (typical for mobile clients).
  1. User and LSP quiesce the channel (pause HTLC forwarding).
  2. They request a new VTXO in the upcoming Batch with identical capacity allocation.
  3. The Batch settles onchain.
  4. User and LSP create commitment transactions spending the new funding output with the same balance distribution.
  5. They sign a forfeit transaction on the old VTXO, revoking the old channel state.
  6. User and LSP unquiesce and resume operation on the new VTXO.
The forfeit mechanism ensures the old and new VTXOs cannot both be spent, preventing double-spend exposure for the Server.

​
Resize

Resize follows the renewal pattern with a modified balance allocation. If Alice wants more inbound capacity, the new VTXO reflects that. If Bob wants to withdraw funds, the new VTXO is smaller and Bob receives a separate VTXO for the withdrawn amount.

​
Cooperative close

Alice and Bob sign a settlement transaction spending the channel VTXO directly to their respective destinations. Each party can send an Arkade transaction to their own address, eventually obtaining Bitcoin finality with onchain settlement.

​
Force close

If one channel party becomes uncooperative, the other party cooperates with the Server to execute a force close. The party broadcasts their latest commitment transaction, and resolution proceeds via standard Lightning semantics (to_local delay, HTLC resolution). Unilateral exit (waiting for the Ark CSV timeout to bypass the Server) is the fallback of last resort when the Server disappears.

​
VTXO expiry and HTLC coordination

This is the critical constraint. If an HTLC’s CLTV timeout extends past the VTXO’s Batch expiry, the VTXO becomes unilaterally spendable before the HTLC resolves. This creates a race condition. Rule: Never accept an HTLC whose CLTV timeout exceeds (Batch expiry minus safety margin). 
HTLC CLTV expiry < Batch expiry - safety margin
This constraint tightens as the VTXO approaches expiry. A channel with 12 hours remaining cannot accept HTLCs with 24-hour timeouts. This is why timely renewal matters.

​
Commitment transaction structure

Each commitment transaction contains:
OutputScriptPurpose
to_localRevocation + CSVBroadcaster’s balance
to_remoteImmediateCounterparty’s balance
HTLCsHashlock + timelockPending payments
All outputs use the dual-path Taproot structure. The Ark timeout path exists only as fallback if the Server becomes unavailable.

​
Implementation Notes

The script adaptation pattern: for every Lightning script, create two Taproot leaves. The first leaf is the unmodified Lightning script. The second leaf is the same script with an additional CSV check matching the Batch expiry. This applies to: funding output, commitment to_local, commitment to_remote, offered HTLC, received HTLC, anchor outputs (if used). The funding transaction is created via Arkade. All other transactions (Lightning commitments, HTLC-success, HTLC-timeout, penalty) are created and signed by Alice and Bob alone, following standard Lightning flows.

​
Further Reading

Dryja-Poon Contract

Raw opcodes for channel primitives

Lightning Swaps

Bridge Arkade VTXOs to external Lightning

Virtual Mempool

DAG architecture for offchain execution

Batch Expiry

VTXO lifecycle and timeout mechanisms