Spilman Channel Example
Reference implementation of a virtual Spilman Channel within Arkade
Channel Lifecycle
- Setup: Alice locks funds so that either Bob can take an ever-increasing amount immediately (by holding the latest state transaction), or Alice can take everything back after a timeout (refund path).
- Offchain Updates: Every payment is a new transaction that is signed by Alice and that pays more to Bob than the previous one. The transaction is not published to the Arkade server, but sent to Bob.
- Closing the Channel
- Cooperative Close: Bob can close the channel by adding his signature to the presigned transaction he received from Alice together with the corresponding checkpoint data.
- Refund Path: If Bob is unresponsive, Alice waits for the CLTV/CSV timelock to expire and reclaims her funds via the refund path.
Spending Paths
A virtual Spilman Channel is composed of a Taproot tree with four key spending paths:| Path | Script Type | Participants | Description |
|---|---|---|---|
updateScript | MultiSig | Alice + Bob + Server | Used for cooperative offchain updates |
refundScript | CLTV MultiSig | Alice + Server | Allows refund after an absolute locktime |
unilateralUpdateScript | CSV MultiSig | Alice + Bob | Enables unilateral channel closure after a short delay |
unilateralRefundScript | CSV SingleSig | Alice | Fallback refund path after a longer delay |
The timelocks are ordered such that:
unilateralUpdateDelay < unilateralRefundDelay. This ensures that updates are always possible before refunds, meaning: Bob can always close with the latest valid state before Alice’s refund becomes valid.Example Implementations
The following code snippets are an excerpt from the ts-sdk repo (spilman.js):Constructing a virtual Spilman Channel with Tapscript Conditions
Constructing a virtual Spilman Channel with Tapscript Conditions
This snippet sets up a virtual Spilman payment channel between Alice, Bob, and a coordinating server. It defines the Tapscript-based spending conditions, covering cooperative updates, time-locked refunds, and unilateral exits, using multisig and timelocked scripts that together form the channel’s lifecycle logic.
Offchain Channel State Updates and Signatures
Offchain Channel State Updates and Signatures
This snippet simulates off-chain channel updates between Alice and Bob.
Alice first sends 1000 sats, both sign the transaction, then she updates the state by sending 500 more sats, resulting in a new co-signed off-chain transaction reflecting the updated balance.
Integration with Arkade
On Arkade, these channel contracts are expressed as VTXOs. The Arkade server participates in cooperative branches only, facilitating batching and checkpoint finalization, but it cannot unilaterally spend or steal funds. Key properties:- Private: Updates remain offchain.
- Cheap: No onchain footprint until settlement.
- Safe: Script-level guarantees enforced by timelocks.
- Compositional: Can be nested or linked to higher-level Arkade contracts.