Lightning Overview

SCL on Lightning brings OroBit's contract layer to the Bitcoin Lightning Network: instant, low-fee payments and instant SCL asset transfers, with the same non-custodial guarantees as the rest of the stack. Assets are bound to Lightning channels, move over ordinary Lightning payments routed through existing channels and infrastructure, and settle back to Bitcoin when a channel closes.

The architecture in one picture

Three components cooperate:

  • The browser signer: a WebAssembly signer that runs entirely in your browser. It derives your on-chain wallet keys and per-channel Lightning keys from one seed and signs everything locally. Keys never leave your device.
  • The Lightning hub: OroBit-operated infrastructure that manages Lightning peer connectivity, channel state, chain data, and per-channel asset accounting. The hub can ask your signer to sign; it can never sign for you.
  • The SCL node: validates and settles the contract side against Bitcoin, including asset deployments, mints, transfers, channel bindings, and channel settlement.

The signer and hub speak an authenticated WebSocket protocol: your browser proves ownership of its node key with a challenge-response handshake, then the hub streams signing requests (channel funding, commitments, revocations) to the browser for approval. This keeps the wallet fully non-custodial while the hub does the always-online work Lightning requires.

Under the hood, the Lightning machinery is built on LDK, extended with an asset-aware fork of rust-lightning that carries SCL asset context through the channel funding and payment paths.

Asset-bound channels

SCL assets are bound to a Lightning channel at open time. The channel funding transaction is built from the opener's token-bound UTXOs, and the asset binding is registered on the SCL node against the channel's funding outpoint. Binding to outpoints rather than addresses is deliberate: it inherits Bitcoin's double-spend safety and is what makes channels (which are outpoints) and HTLCs (outpoint-level constructs) natural carriers for assets.

The moment the binding lands, the hub seeds a per-channel asset allocation: the opener owns the full bound amount, the counterparty owns zero. From then on, the allocation is the authoritative record of who owns how much inside the channel. Every mutation is sequence-numbered, co-signed by both parties, and durably persisted, so the split survives restarts and is provable at settlement time. The invariant opener + peer = total holds at every step.

Asset payments over Lightning

Asset transfers over Lightning are live. Assets move inside ordinary Lightning payments, routed through existing channels and existing network infrastructure. No bespoke routing nodes and no parallel network: the carrier is a standard BOLT11 payment, so any path that can route the payment can carry the transfer.

The mechanics:

  1. The recipient creates a standard BOLT11 invoice and registers the asset terms (contract ID and token amount) against the invoice's payment hash.
  2. The payer pays the invoice like any Lightning payment. Intermediate hops route it normally; they need no knowledge of the asset layer.
  3. When the payment settles, the channel's asset allocation is updated atomically with the HTLC preimage release. The asset transfer and the payment are keyed to the same payment hash: one settles exactly when the other does.

Because ownership inside the channel is tracked by the co-signed allocation table, asset balances move instantly and off-chain, with nothing touching Bitcoin until the channel closes.

Asset settlement at channel close

Settlement of channel-bound assets back to Bitcoin is automated and live, for cooperative and force closes alike:

  • A close watcher monitors every registered funding outpoint. Each detected close is persisted as a durable settlement intent before any settlement is forwarded, so a crash or restart can never drop a settlement.
  • Settlement is confirmation-gated: the intent is acted on only once the closing transaction has the required Bitcoin confirmations (3 by default), and the close is re-verified as still confirmed at that point. A reorg rolls the intent back; re-detection recreates it if a replacement close confirms.
  • The final split maps each party's asset allocation onto the closing outputs that pay them, carrying the co-signed allocation state into the on-chain settlement. Channels opened before allocation tracking fall back to a proportional split of the closing outputs.
  • The settlement call on the SCL node is idempotent, so replaying an unfinished intent after a restart is safe: it settles exactly once.

What works today

  • Non-custodial wallet: on-chain send and receive with browser-held keys.
  • Lightning channels: open and close channels, cooperatively or by force.
  • Lightning payments: create and pay BOLT11 invoices, routed over the Lightning Network. Live on Bitcoin mainnet.
  • SCL contract operations: deploy, mint, and transfer assets from the same wallet, anchored on Bitcoin.
  • Asset-bound channels: bind an SCL asset to a channel's funding outpoint at open, with co-signed allocation tracking.
  • Asset payments over Lightning: instant asset transfers inside standard Lightning payments, routed through existing channels and infrastructure.
  • Asset settlement at channel close: automated, confirmation-gated, and crash-safe, for cooperative and force closes.

SCL on Lightning is under active development and the surface evolves quickly. The capabilities above are live; expect the tooling around them to keep improving.

Learn more