TERM_DEF // LAYER_2_OVERLAYS / LIGHTHOUSE_ASSURANCE_CONTRACTS
LIGHTHOUSE (ASSURANCE
CONTRACTS)
CONTRACTS)
Lighthouse (Assurance Contracts). A crowdfunding protocol where pledges are valid only if a target is met.
This page sits in the Layer 2 & Overlays section — Higher-layer protocols using Bitcoin for settlement or commitments. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Layer 2 & Overlays section — Higher-layer protocols using Bitcoin for settlement or commitments. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_LIGHTHOUSE_ASSURANCE_CONTRACTS_IS
Lighthouse (Assurance Contracts) — at a glance
LAYER 2
Lighthouse (Assurance Contracts) is part of the broader Layer 2 / overlay ecosystem that builds on top of Bitcoin — using the base chain for settlement and security while moving most activity off-chain. A crowdfunding protocol where pledges are valid only if a target is met. Layer 2 is the answer to "how do we scale Bitcoin without compromising decentralisation?".
Why it exists
DESIGN
On-chain capacity is intentionally limited — every byte must be validated by tens of thousands of full nodes forever. That's a strength (full verification), not a bug. Layer 2 systems take advantage of the base chain's unforgeable timestamps + signatures to do more activity off-chain: payment channels (Lightning), federated sidechains (Liquid), drivechains (proposed BIP-300), asset overlays (RGB, taproot-assets/">Taproot Assets), and state channels.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Most Layer 2 systems share a pattern: lock value on-chain in a special script (multisig, peg-in, covenant), then move that value off-chain via signed messages, only returning to the chain to settle disputes or unwind. Lighthouse (Assurance Contracts) fits into one of those models — payment channel (Lightning), peg-in/peg-out (sidechain), client-side validation (RGB), or covenant-secured vault.
1. User locks BTC on the base chain into a Layer-2-specific output (channel, peg-in, vault).
2. They transact off-chain via the L2 protocol: payments, asset transfers, smart contracts, depending on the system.
3. Cryptographic proofs (signatures, hash preimages, BFT consensus) bind the off-chain state to the on-chain commitment.
4. To exit: user broadcasts the latest signed state and the base chain settles them back to standard BTC.
5. If a counterparty cheats, the base chain's dispute mechanism (punishment txs, fraud proofs) makes them lose the cheated amount.
6. Security inherits from Bitcoin's base layer for any honest user who stays online and watches the chain.
WORKED_EXAMPLE
Layer 2 systems on Bitcoin in 2024
EXAMPLE
Lightning Network payment channels bidirectional, HTLC-routed micropayments
Liquid Network federated sidechain 1-min blocks, confidential txs, BTC-pegged L-BTC
Statechains off-chain transfer rotating private-key ownership of a single UTXO
RGB client-side validation asset issuance bound to BTC outputs
Taproot Assets similar idea, MAST issue & transfer assets via Tapscript scripts
Ark proposed L2 non-interactive channels with sub-second UX
BitVM covenant-emulated fraud proofs for arbitrary computation on BTC
Sidechains (drivechain proposed in BIP-300/301; not yet activated)
Common trade-off : less on-chain security in exchange for higher throughput
Common property : any L2 user can always unilaterally exit to the base layer
KEY_PROPERTIES
ON-CHAIN ANCHOR
Every L2 system anchors to the base chain — either via funding txs, peg-ins, or commitment txs. The base layer is the court of last resort.
A good L2 design lets any honest party exit back to the base layer without permission, even if their counterparty is offline or malicious.
INHERITED SECURITY
The base chain protects deposited funds for users who play by the protocol; the L2 only adds attack surface for those who don't.
HIGHER THROUGHPUT
Off-chain throughput is bounded by participating nodes, not by base-chain block-size/">block size. Lightning processes ~1M payments per second collectively.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- Sidechains are NOT Bitcoin — they're separate ledgers pegged to BTC with their own validators or federations. Trust assumptions differ.
- A Layer 2 with a custodian (e.g. an LSP) is closer to a regulated payment processor than to self-custodial Bitcoin. Read the trust model before committing.
- Most L2 systems have lower-than-base-chain security guarantees in some scenarios — e.g. a Lightning channel needs you (or a watchtower) to stay online.
- Drivechains, RGB, and BitVM are exciting but still in development or limited deployment. Don't custody real funds in unaudited L2 systems.
RELATED_CONCEPTS
Other terms from Layer 2 & Overlays — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Lighthouse (Assurance Contracts)
A crowdfunding protocol where pledges are valid only if a target is met.
Layer 2
Any protocol settling onto Bitcoin while operating mostly off-chain (LN, Ark, sidechains).
Ark Protocol
A shared-UTXO protocol providing instant payments with periodic on-chain settlement and unilateral exits.
Virtual UTXO (vUTXO)
An Ark balance that behaves like a UTXO but lives off-chain inside a shared output.
Fedimint
A federated Chaumian e-cash mint backed by a multisig holding bitcoin.
Chaumian eCash
David Chaum's blind-signature based digital cash, providing strong sender privacy.
Sidechain
A separate blockchain pegged to Bitcoin, often with a federated or burn-and-mint peg.
State Channel
A general off-chain protocol updating state between parties using on-chain settlement as backstop.