Tokenised deposits in Lightning channels: bank money, settled on Bitcoin

Lightning made it practical to move value without waiting for every payment to settle on-chain. Banks, though, price everything in their own currencies. The question is how a bank's tokenised deposit can move with a Lightning payment without turning every routing node into a processor for that bank's money.

SQRL answers it with asset channels. The bank issues the deposit token on its own subnet. SQRL binds it to a Lightning channel, updates the balance in co-signed channel state as payments move, and carries the final position back to Bitcoin.

Start with an authorised asset

The first decision is the asset, not the invoice. A production corridor needs a specific contract ID for the deposit token, with its committed bytecode, ABI version and permitted operations, and a named authority behind the units: the issuing bank.

That contract ID follows the asset through every later record. It tells the channel which asset is bound, tells the SQRL virtual machine which rules to run and gives the bank's operations team a fixed reference when it replays the history.

Bind the asset to a channel

When a channel opens, SQRL binds the asset record to the channel's Bitcoin funding outpoint, the specific output that creates the channel. The first allocation follows four rules:

• the opener holds the full bound amount;
• the peer starts at zero;
• the two balances always add up to the channel total; and
• every accepted update advances the sequence number and carries both signatures.

If a bank binds 10,000 units, the opening allocation is 10,000 / 0. After a 250-unit payment it is 9,750 / 250. The total never changes; only ownership inside the channel does. SQRL rejects any update that creates units, loses units or builds on stale state, and any node can replay the same inputs to the same result.

Link the payment and the balance

The receiving bank creates a standard BOLT11 invoice and registers the asset terms (contract ID and amount) against its payment hash. The paying bank sends an ordinary Lightning payment. Routing nodes forward it like any other payment; they never run the contract or hold the deposit balance.

The link happens at the two endpoints. The Lightning payment and the asset update share one payment hash, and the endpoints advance the co-signed allocation when the payment completes. Lightning stays the transfer rail. The contract stays the rulebook.

Carry the final position back to Bitcoin

When a channel closes, SQRL watches the funding outpoint, records a settlement intent and waits for the required confirmation depth before settling the final allocation. If a reorganisation removes the close, the intent rolls back and follows the new chain. Settlement is idempotent, so a restarted service never applies the same final position twice.

What the bank can inspect

Every corridor should ship with a trace another team can follow: the deposit token's contract ID and ABI version, the bytecode commitment on Bitcoin, the channel funding outpoint, the invoice and payment hash, each allocation with its signatures, the settlement event and the closing reference. A routing failure, a rejected balance update and a confirmation event each leave different evidence, in a different layer.

The same path works for any authorised asset on SQRL, including dollar stablecoins. Tokenised deposits come first because the bank is the issuer, the customer and the party that keeps its own balances.