Bitcoin developer Adam Gibson has published Lichen, an experimental design for withdrawing bitcoin from an external payment ledger without relying on a hub to cooperate. His October 11 technical proposal describes an approach that works within existing Bitcoin consensus rules.
TL;DR: Lichen explores a narrower trust assumption for withdrawals. It remains an unaudited prototype, with collateral limits and separate assumptions about the ledger recording users’ balances.
Making a withdrawal enforceable has a limited scope
The proposal connects a hub-issued balance to a user-specific Bitcoin contract. In a dispute, a cryptographic proof and an interactive verification process are intended to let the user enforce an eligible withdrawal even if the hub stops cooperating.
Gibson describes a combination of RISC Zero proofs and BitVMX verification. These components serve different stages of the design: establishing a claimed computation and resolving a challenge through transactions that Bitcoin can enforce. The announcement presents local testing, not a completed public deployment.
The distinction between the ledger and the exit is central. A system can improve a user’s ability to leave while still depending on assumptions about which ledger state is valid. An enforceable withdrawal mechanism therefore cannot, by itself, establish every property expected from a payment network.
That separation is useful when assessing claims about a Bitcoin layer 2. Questions about transaction ordering, censorship, availability and withdrawals can have different answers within the same design. Grouping them into a single label obscures where a participant still depends on another party.
Collateral capacity puts a ceiling on the protection
The project repository makes the experimental status explicit. Its code has not been audited, was generated largely with an LLM, and is presented for local regtest demonstrations rather than use with real funds.
The documentation also describes an individual capacity limit. A user’s enforceable claim is bounded by the Bitcoin committed to the relevant contract. A displayed balance above that amount would leave excess value dependent on credit, even if the interface continues to show a larger total.
This is an economic constraint as much as a technical one. If a payment raises a balance beyond available collateral, software cannot create the missing bitcoin merely by proving that the ledger recorded the payment. Capacity management must remain consistent with the obligations users expect the system to honour.
For reviewers, the next useful evidence would include independent examination of the implementation, reproducible dispute tests and a clearer account of costs under adverse conditions. A successful demonstration can establish that one execution path works; it cannot establish that all competing or malicious paths have been handled.
Lichen’s contribution is a concrete proposal that can be inspected and challenged. The questions now concern the boundaries of its security assumptions and whether the implementation matches them. Nothing in the published material establishes a production service, an audited custody arrangement or a finished alternative to existing Bitcoin payment systems.
Written by the News Desk and edited by Samuel Rae.
