§04 — Segment Dossier
Lightning / L2 infrastructure
A field guide to the Bitcoin movement layer: the products, liquidity operators, APIs, payment processors, settlement paths, and protocol primitives that turn Lightning from a network into operating infrastructure.
Segment dossier
How Lightning & L2 actually works. Structural dynamics, key flows, where Lunar Rails fits.
No dossier written for Lightning & L2 yet. This is the qualitative truth about how this segment actually works: structural dynamics, key flows, chokepoints, dominant business models, and where Lunar Rails fits. Curator-authored, evidence-backed.
Segment thesis
Lightning is the movement layer, but the segment is really a dependency map.
The page should teach us how value moves through apps, wallets, LSPs, payment processors, routing operators, settlement tools, and protocol infrastructure. The useful question is not whether an entity is a lead. It is what role it plays in the system, who it depends on, what it reveals about the market, and where Lunar Rails could become the trusted service layer.
Tracked
0
Warm / active
0
Strategic 4+
0
Needs layer
0
Needs one-liner
0
Unverified
0
Ecosystem roles
Organize Lightning by function in the system. A company can be a product, dependency, benchmark, distribution path, or technical substrate before it is anything like a sales account.
Consumer and merchant front doors
0Where users, merchants, creators, and marketplaces touch Lightning. These products expose the real UX and reconciliation problems, but often depend on someone else for liquidity, custody, fiat/stablecoin bridges, and compliance boundaries.
Which flows are actually painful enough to require a Banking House layer behind the product?
Liquidity and routing operators
0The channel-capital layer: inbound liquidity, rebalancing, routing, LSP services, node operations, and risk controls. This is where Lightning becomes financial infrastructure instead of only payments UX.
Who supplies capital, who controls nodes, who eats routing risk, and what reporting makes the activity credible?
Payment processors and service APIs
0B2B processors, checkout APIs, hosted nodes, payout endpoints, and partner-facing services. These entities can be clients, competitors, or distribution partners depending on whether they need Lunar behind the scenes.
Are they selling the full stack themselves, or do they need a trusted service hub behind the customer relationship?
Settlement, swaps, and L2 experiments
0Private settlement, cross-layer swaps, Taproot Assets, stablecoin-on-Bitcoin experiments, and market-maker paths. These are high-learning surfaces that need technical diligence before they become GTM language.
What is actually settled, where is custody/control held, and which counterparty or protocol risk enters the system?
Protocol and developer substrate
0Implementations, SDKs, monitoring, node tooling, and developer primitives. They explain what is possible, but the segment page should translate them into business dependencies.
Which primitives are mature enough for Lunar to rely on, integrate, benchmark, or deliberately avoid?
Cooperation patterns
The segment gets useful when Atlas shows the handoffs: who owns the customer, who supplies liquidity, who controls settlement, and which provider is hidden behind another provider.
Wallets / apps -> LSPs / node operators
Wallets and apps borrow liquidity credibility
Consumer-facing products can own the customer while another operator supplies inbound liquidity, routing operations, swaps, or uptime. Atlas should show when the product is the front door and when the infrastructure partner is the real dependency.
Merchants -> processors -> custody / fiat / treasury ops
Payment processors sit between merchants and treasury
OpenNode/Flash-style accounts may look like payments companies, but the deeper need may be settlement, accounting, fiat/stablecoin conversion, or post-payment treasury management.
Miners / marketplaces -> payout rails -> liquidity providers
Marketplaces turn payouts into infrastructure demand
NiceHash-style flows are not just merchant payments. They mix hashrate markets, user balances, pool/proxy control, split payouts, API reliability, and treasury operations.
Treasuries -> routing capital -> custody / disclosure controls
Treasury capital wants yield language but needs risk proof
B HODL-style threads are useful because they force the question: can routed Lightning capital be explained with custody posture, role separation, reporting, and compliance boundaries?
Infrastructure mechanics
These are the mechanics the dossier should keep visible underneath every entity profile.
Channel capital
Where liquidity is committed, who funds it, how it rebalances, and whether capital use looks like operations, yield, or credit.
Control and custody
Who controls nodes, keys, balances, settlement paths, and customer funds. This is the line between software integration and regulated financial service.
Routing and counterparty risk
Where failures, stuck liquidity, route quality, uptime, market-maker exposure, or partner dependency can break the flow.
Conversion and accounting
Where BTC, fiat, stablecoins, invoices, payout records, and treasury reports stop matching cleanly enough for institutions.
API surface
Which services can be routed through an API partner while Lunar stays the trusted banking-house layer behind the interface.
Entity field guide
Mini dossiers for the accounts that currently teach us the most about the segment. This is not a pipeline view; it is the working intelligence layer.
B HODL
UK-listed Bitcoin treasury company exploring Lightning routing, LSP activity, and risk-reduced capital deployment.
What it teaches
Lightning yield language only works if custody, control, disclosure, and role separation are legible.
Unknown
Who owns risk and what reporting would make routed capital institutionally acceptable?
Flowrate
Lightning liquidity orchestration path around managed routing nodes, rebalancing, and multi-LSP capital deployment.
What it teaches
The segment depends on specialist operators that can make channel capital usable for products.
Unknown
What parts of the stack are proven enough for Lunar to rely on or route through?
KaleidoSwap
Cross-layer swap and liquidity path for self-custodied market-maker infrastructure across Bitcoin L2 surfaces.
What it teaches
The L2 opportunity is partly about connecting liquidity venues without breaking custody assumptions.
Unknown
Which counterparty, bridge, and market-maker risks enter the flow?
LX
Private Bitcoin settlement and OTC infrastructure thread that needs technical, custody, and regulatory diligence.
What it teaches
Some L2 conversations are diligence surfaces before they are customer or partner opportunities.
Unknown
What is actually settled, who controls it, and where does compliance land?
NiceHash
Hashrate marketplace and mining/payments bridge where payouts, pool/proxy control, and API hub routing overlap.
What it teaches
Payout rails can connect Lightning to mining, marketplaces, custody, and service-hub distribution.
Unknown
Which payout/accounting pain belongs to NiceHash and which belongs to its users?
OpenNode
Lightning payments benchmark for merchant acceptance, payouts, APIs, and the gap between payment rails and Banking House operations.
What it teaches
Payment processors show where acceptance ends and treasury/accounting/service needs begin.
Unknown
Is the relevant pain merchant acceptance, settlement, conversion, reporting, or partner depth?
Flash
Bitcoin payments and treasury workflow product-discovery account around stablecoin support, fiat partner APIs, and miner accounting.
What it teaches
Payments conversations often reveal adjacent treasury, stablecoin, fiat API, and accounting needs.
Unknown
Which workflow breaks badly enough that Lunar should own the next service layer?
Market movement
What the last month is teaching us.
- 01Lightning is becoming less about simple merchant acceptance and more about operational movement: payouts, liquidity, routing, settlement, and API-backed services.
- 02The strongest Lunar pattern is not replacing every specialist. It is becoming the trusted hub that can route custody, treasury, movement, and capital questions through vetted partners.
- 03Payment companies are not automatically good prospects. The page needs to reveal whether their pain is merchant adoption, payout rails, fiat/stablecoin conversion, reporting, custody, or partner quality.
- 04Lightning capital experiments are interesting only when role separation, risk disclosure, custody posture, and reporting are clear enough to survive diligence.
Lunar Rails fit map
Not a lead tracker. This is where the segment dossier explains which Banking House service surfaces may matter if the ecosystem keeps moving in this direction.
Movement
Payments, payouts, private settlement, and operational transfer flows where reliability and trusted routing matter more than protocol novelty.
Treasury
Post-payment balance management, BTC/stable/fiat conversion, reporting, and institutional controls after Lightning receives or pays value.
Custody and control
Key custody, node control, role separation, auditability, and service boundaries around routed funds.
Capital
Routing liquidity, channel capital, marketplace balances, and treasury capital experiments that need diligence before commercial language.
API service hub
Partner-facing API paths where Lunar can sit behind another brand and connect Banking House services without stealing the relationship.
Intelligence gaps
A good segment page should make our ignorance visible. These questions should drive call notes, source reviews, and dossier updates.
- 01Who actually owns liquidity risk in each product or partnership?
- 02Which entities control the customer relationship versus the infrastructure dependency?
- 03Where do payouts, merchant settlement, and treasury workflows overlap?
- 04Which LSPs or routing operators are mature enough for Lunar to benchmark or partner with?
- 05Which flows require fiat/stablecoin bridges, and which are Bitcoin-only operational movement?
- 06Where would Kevin/BD need a right-person intro instead of another ecosystem conversation?
Raw stack coverage
This is the underlying catalog coverage. It stays useful as a curation layer, but it should support the dossier rather than define the page.
Apps
0
Wallets
0
Liquidity service providers
0
Infrastructure
0
Protocol
0
No principals in the Lightning catalog yet.
Provider concentration
Who already serves the lightning segment, by service category. Each row is a (provider × capability) pair ranked by how many catalog principals in the segment use it.
No providers recorded for this segment yet.
Add provider relationships from the editor or via Fathom calls mentioning who an entity uses for custody, liquidity, payments, etc. They’ll surface here automatically.
Lightning & L2 · 0 principals tracked