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 become usable once the transaction is accepted. The protocol calls this preconfirmation, and it carries operator, signing, and liveness assumptions. A batch swap can later root the funding position in a Bitcoin-confirmed Batch Output. Arkade tracks accepted channel operations in its transaction dependency graph. A batch swap can consolidate participating opens, closes, and resizes into one Commitment Transaction and Batch Output. 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. Once accepted, the channel is usable and 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.
This flow roots the renewed funding position in a confirmed batch output and assumes one channel party is an LSP.
  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 to their respective destinations. Each party can request a new Arkade output in a later Bitcoin-confirmed batch output.

​
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 is the fallback of last resort if the operator becomes unavailable. It uses the configured Arkade CSV timeout and applies only when the required output and parent transaction paths are available.

​
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).
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: The outputs in this example use a dual-path Taproot structure. The Arkade timeout path provides the example’s delayed fallback if the operator is 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

Pay Lightning invoices from an Arkade balance

Transaction Dependency Graph

Dependency tracking for cooperative execution

Batch Expiry

VTXO lifecycle and timeout mechanisms