Off-Chain Payment Protocols on LEE

Logos
1

This post is a follow-up on Block context in LEE: a design exploration.

This document identifies requirements for time-information exposure in LEE programs to support off-chain payment protocol implementations.

Off-chain protocols need timelocks to enforce temporal ordering of on-chain settlement actions. Without timelocks, depositors cannot guarantee refund access if a counterparty disappears, and honest parties cannot be given time to respond to fraudulent settlement attempts.

The specific time primitives available in the execution environment determine which protocol constructions are feasible. This document evaluates three candidate protocols against two possible LEE time-exposure designs.

Candidate Protocols

We consider three off-chain payment constructions, ordered by complexity.

Spilman unidirectional channels

User funds a channel and makes incremental off-chain payments to a provider. Money flows in one direction only. Provider must close with the latest user-signed state before channel expiry. User can get a full refund after the expiry. No dispute mechanism needed: each state update strictly increases the provider’s balance. The provider has no incentive to close with any but the latest state. The user can only close with refund after channel expiry because the user lacks the provider’s signature for intermediary state updates.

Lightning bidirectional channels

Payments flow in both directions. Old states can benefit a cheating party, requiring a penalty mechanism: the broadcaster’s funds are delayed, giving the counterparty time to detect and punish breach. Lightning serves here primarily as a reference point. Its full construction (HTLCs, multi-hop routing, penalty revocation) is more complex than our use case requires. Practically, we are mostly interested in 1-1 payment protocols for service provision without routing.

Payment streams

Continuous fund transfer at a defined rate (e.g., 10 tokens per hour). The provider’s accrued amount is calculated on-chain at claim time. No signed state updates or dispute mechanism needed. Suits subscription-like services (e.g., Waku Store).

Timelocks in Each Protocol

Tx-level vs script-level in Bitcoin

Bitcoin has four timelock primitives along two axes: absolute vs relative, transaction-level vs script-level.

Absolute Relative
Tx-level nLocktime nSequence (BIP 68)
Script-level OP_CHECKLOCKTIMEVERIFY (BIP 65) OP_CHECKSEQUENCEVERIFY (BIP 112)

A tx-level timelock is set by the transaction creator. It is a voluntary self-constraint: the spender chooses the value.

A script-level timelock is embedded in the output script. It is a mandatory constraint on any future spender. The opcode checks that the spending transaction’s corresponding tx-level field meets a required threshold.

The two levels work in tandem. CLTV checks nLocktime >= script_value; consensus enforces current_height >= nLocktime. Combined: current_height >= script_value. The same pattern applies for CSV and nSequence.

The key point for Bitcoin: to enforce a time condition on a spender, a script-level timelock is required. A tx-level timelock alone is voluntary and can be bypassed.

Spilman channels

Spilman channels use one absolute timelock for the refund path.

In the original construction (pre-CLTV), the refund is a pre-signed transaction with nLocktime = T (tx-level only). Bob co-signs the refund during setup, locking in the nLocktime value. Alice cannot create a different refund because she lacks Bob’s signature for the 2-of-2 multisig.

The CLTV-improved construction (BIP 65) moves the timelock into the funding output script. The script has two spending paths: a normal path requiring both signatures (no timelock), and a refund path requiring only Alice’s signature but gated by OP_CHECKLOCKTIMEVERIFY. This eliminates the pre-signed refund transaction: Alice no longer needs Bob’s cooperation to construct the refund, because the script itself grants her a unilateral refund path after the expiry. She can build the refund transaction at any time, referencing the actual confirmed funding txid.

Lightning channels

Lightning uses both absolute and relative script-level timelocks.

CLTV (absolute, script-level) enforces HTLC timeout deadlines. This is necessary for multi-hop payments to ensure that each intermediary learns the preimage before their own HTLC expires. A 1-1 channel without routing has no HTLCs and no CLTV.

CSV (relative, script-level) enforces the revocation delay on all outputs returning funds to the commitment broadcaster. The broadcaster’s to_local output and all HTLC second-stage transaction outputs are locked behind a to_self_delay CSV. If the broadcaster published a revoked (outdated) commitment, the counterparty can sweep the broadcaster’s funds immediately using the revocation key, before the CSV delay expires.

Relative timelocks are necessary because:

(a) commitment transactions can be broadcast at any time, so the delay must start from confirmation, not a fixed block height;

(b) the delay must apply to one spending path (the broadcaster’s delayed claim) but not another (the counterparty’s immediate revocation path).

Payment streams

Streams require access to current time for computing accrued amounts: accrued = (current_time - start_time) * rate.

This is not a timelock in the traditional sense. It is a continuous time-dependent computation. No relative or absolute timelocks are needed. No dispute mechanism is needed. The only requirement is that the program can read a consensus-supplied current timestamp and perform arithmetic on it.

LEE as L1 for off-chain payments

Why script-level merges with tx-level

In Bitcoin, scripts and transactions are authored by different parties at different times. The output creator writes the script; the spender creates the transaction. Script-level timelocks bridge this gap by forcing the spender’s tx-level values to meet the script’s requirements.

In LEE, programs serve the role of Bitcoin Script. A program defines rules for interacting with its accounts. When a transaction invokes a program, the program decides whether to accept the operation; the caller cannot bypass program logic.

The distinction between “voluntary tx-level” and “mandatory script-level” dissolves. In LEE, if the program checks a time condition, that condition is mandatory. The remaining question is: what time information does the program have access to?

Two options for time exposure

Option A – Validity window. Every transaction carries valid_from and valid_until. The sequencer accepts a transaction only if valid_from <= current_height < valid_until. Programs can read these fields from the transaction message but cannot query the current block height directly.

Option B – In-program timestamp. Programs can read the current block height via a system account (analogous to Solana’s Clock sysvar). Programs can use this value in arbitrary comparisons and computations.

Option B strictly subsumes Option A in capability.

LEE Implementation of Candidate Protocols

Spilman channels

The refund path requires an absolute timelock: “user can reclaim funds after block T.”

Under Option A, the program checks valid_from >= channel.expiry. The sequencer guarantees current_height >= valid_from. Combined: current_height >= channel.expiry. This two-layer pattern is structurally identical to Bitcoin’s CLTV:

LEE (Option A) Bitcoin CLTV
Tx creator sets valid_from Tx creator sets nLocktime
Sequencer enforces valid_from <= current_height Consensus enforces nLocktime <= current_height
Program checks valid_from >= expiry Script checks nLocktime >= cltv_value

A user who sets valid_from = 0 to bypass the timelock will have the transaction accepted by the sequencer but rejected by the program.

Under Option B, the program checks current_height >= channel.expiry directly.

Spilman channels are feasible under both options.

Lightning channels

The revocation delay requires a relative timelock: “D blocks must pass since the commitment was confirmed.”

Under Option A, this is not feasible. The program must record the block height at which the commitment was confirmed. Since the program cannot query the current block height, it would use the confirmation transaction’s valid_from as a proxy. However, the submitter controls valid_from and can set it to 0, making the recorded timestamp artificially low and defeating the delay.

Under Option B, the program stores event_height = current_height when the commitment is confirmed, then enforces current_height >= event_height + delay for the broadcaster’s claim. The revocation path has no delay check. Since event_height comes from the consensus-supplied block height, it cannot be gamed.

Lightning channels require Option B.

For the 1-1 unidirectional use case, Lightning’s full construction is unnecessary. However, any protocol with a dispute window (e.g., user requests withdrawal, provider disputes within a window) needs a relative timelock, also requiring Option B.

Payment streams

Accrual computation requires the current time: accrued = (current_height - stream_start) * rate.

Under Option A, this is not feasible. Using valid_from as a proxy for current time is insecure: the caller controls valid_from and can choose any value in [0, current_height]. A provider could inflate accrual by setting valid_from close to current_height; a user closing the stream could deflate accrual by setting valid_from = stream_start.

Under Option B, the program reads the consensus-supplied block height. The computation is deterministic and non-gameable.

Payment streams require Option B.

Summary table

Protocol Time primitive needed Option A (validity window) Option B (timestamp)
Spilman channels Absolute timelock Sufficient Sufficient
Lightning channels Relative timelock Not sufficient Sufficient
Payment streams Time-dependent computation Not sufficient Sufficient

Additional LEE requirements beyond time access:

  • program-controlled fund custody (program-owned accounts holding tokens);
  • caller authentication (program can verify which account signed the transaction);
  • signature verification within programs (channels only).

In channel protocols, the provider closes by presenting a user-signed message that asserts a balance split. The program must verify this signature; otherwise the provider could fabricate a message claiming a higher amount. Streams do not need this: the claimable amount is computed by the program itself, so no party supplies an amount that could be fabricated.

Summary

Off-chain payment protocols need time-based enforcement for two reasons: protecting depositors from counterparty disappearance (refund deadlines), and giving honest parties time to respond to fraud (dispute windows).

The feasibility of specific protocol constructions on LEE depends on how programs access time information. Option A (validity window only) enables absolute timelocks via a two-layer enforcement pattern analogous to Bitcoin’s CLTV. This supports Spilman unidirectional channels.
Option B (in-program timestamp access) additionally enables relative timelocks and continuous time computation. This enables bidirectional channels with dispute mechanics and payment streams.

For the user-provider payment use case targeting Logos services, Spilman channels (Option A) represent the minimum viable protocol. Streams and dispute-based channels both require Option B.

Option A is a lighter primitive that delivers a functional payment protocol (Spilman) without waiting for richer time exposure in LEE. Option B unlocks the full range of constructions but adds complexity to the execution environment. The choice depends on implementation priorities and whether other LEE applications beyond payments also need in-program time arithmetic or find validity windows sufficient.

References

1 Like