Lichen's bitcoin layer 2: exits without the issuer

Developer Adam Gibson has published a paper and proof-of-concept code for Lichen, a bitcoin layer 2 run by a single issuer that users can leave without that issuer's help. Bitcoin Optech described the design in Newsletter #428, dated 2026-10-23. This article looks at how the exit works, where the trust moves, and which risks Gibson says are still open.

The change in one paragraph

Most systems with one issuer ask users to trust that issuer to give their money back. Lichen tries to remove that particular promise. An issuer, which Gibson calls the hub, creates tokens that each user can swap back for bitcoin at a one-to-one rate, and a server called the sequencer keeps the token ledger. If the hub will not pay a user out, the user can force the payout onchain through a dispute that the bitcoin blockchain itself settles. According to Bitcoin Optech, the idea was shared on the Bitcoin-Dev mailing list together with proof-of-concept code.

What is layer 2, and where Lichen fits

A layer 2 is a system built on top of a base blockchain. Users move value between each other off the main chain, which is faster and cheaper, and only touch the base chain to enter or leave. The key question for any layer 2 is what happens on the way out: can a user get back to the base chain alone, or only with someone's permission?

Lichen answers that question for a model with one issuer. It builds on an earlier design called LN-GAP, which Bitcoin Optech covered in Newsletter #427. LN-GAP relied on an attestation committee with an honest majority. Lichen drops that committee and settles disagreements fully onchain instead.

Under the hood: deposits, tokens and the exit

Each user locks bitcoin in their own output, controlled by a 2-of-2 arrangement with the hub. A 2-of-2 output needs signatures from both parties to spend, a simple form of multisig. In return the user is credited with an equal token balance on the offchain ledger and can pay other users there without touching the chain.

A user can only withdraw from their own output. That creates a problem when someone receives tokens from others. To fix it, the hub adds some of its own bitcoin to each user's output, up to an agreed cap. Bitcoin Optech compares this to inbound liquidity in the Lightning Network. Tokens received above the cap can be redeemed only if the hub agrees.

• Cooperative exit: the user returns tokens and the hub signs a settlement that pays the user from their output.
• Hub refuses or goes silent: the user creates a Groth16 proof, a compact cryptographic proof, showing the sequencer signed a ledger state that records the returned tokens.
• Onchain claim: Bitcoin Script cannot check such a proof, so the user instead posts an onchain assertion that a known, fixed verifier program would approve the proof.
• Challenge: if the hub disputes the claim, presigned BitVMX transactions narrow the fight down to one execution step, small enough for Script to check.
• Reserves: both sides lock a reserve and the loser of a dispute forfeits it, which is meant to discourage false claims and refusals.

The design trade-off: trust moves, it does not vanish

The interesting part of Lichen is where it puts the remaining trust. Users no longer rely on the hub to hand back bitcoin. They do still rely on the sequencer to keep the ledger honest. The dispute game can prove what the sequencer signed. It cannot prove that the sequencer signed the right thing.

Gibson says this openly. A sequencer that drops a returned batch of tokens from the ledger, or approves a ledger state that was never legitimately produced, can still leave either the user or the hub out of pocket. In other words, the onchain dispute protects against a dishonest issuer, not against a dishonest ledger keeper. There is also a cost side. Every dispute step that lands onchain uses block space and fees, and both parties must tie up reserves. The cap on hub liquidity is a further limit: a user who receives a lot of tokens is back to trusting the hub for the part above the cap.

Who is affected

For now this is a research proposal and not a live product. If the idea is developed, it would matter most to firms that want to issue bitcoin-backed tokens and to users who would hold them. For an issuer, the design means committing its own bitcoin to user outputs and accepting that it can lose a reserve in a dispute. For users, it offers a way out that does not depend on the issuer's goodwill, within the cap. Anyone who ever used a system like this could lose money, through a ledger fault or a lost dispute.

Status and next steps

Lichen exists as a paper and proof-of-concept code, as Bitcoin Optech reported. Gibson lists validity proofs and a committee of several sequencers as future work. Both target the gap he acknowledges: the need to trust a single sequencer. Until those pieces exist, the design reduces trust in the issuer but leaves trust in the ledger operator in place.

Sources

• Bitcoin Optech, 23 Oct 2026

AI wrote this summary from the primary documents and reports cited above. It went live automatically after checks that figures match those sources and nothing is copied; there was no human review. It explains a protocol or rule change and is not investment advice.