Core Lightning, Greenlight & Enterprise Lightning copy guide
One package, three products: the open-source Core Lightning implementation, Greenlight, and the Enterprise Lightning managed offering.
- Greenlight removed as a public brand; lives on as internal tooling. Any open-source page depends on Christian.
- Interim lock: "Blockstream Enterprise Lightning." Payments rejected, services avoided; "lightning" stays because customers search it.
- Core Lightning gets an honest refresh: address is-it-dying inquiries; competitor chart adds LDK or goes.
- Early customers: smaller exchanges and payment providers.
Golden rules
Get these right and most copy takes care of itself.
- Core Lightning, never c-lightning. "CLN" after first reference; the old name only in explicit history.
- Three products, three names: CLN (open-source implementation), Greenlight (hosted nodes), Blockstream Enterprise Lightning (managed).
- Developer voice for CLN, operator voice for Enterprise Lightning; never marketing language in dev content.
- Never sole-credit Blockstream for Core Lightning; contributions are collaborative, credit the community.
- Greenlight is not custodial: it provisions nodes; the developer keeps key control.
- Never attack competitors by name; public comparisons stay factual, dated, and legal-scanned.
Who you're writing for
Meet the reader before touching the rules.
Write for developers by default: they know Bitcoin, so name protocols directly (HTLC, BOLT), skip fundamentals, prefer a named byline.
Match the reader segment in CLN docs: node operators, LSPs, plugin devs, and enterprises each get a section; write to one per piece.
For Enterprise Lightning, write to operators not devs: early buyers are smaller exchanges and payment providers; no persona exists yet.
Names
The product names and exactly how to write them.
Write "Core Lightning," never c-lightning: old name only in explicit historical context; use "CLN" (never cln) after first reference.
Use no article: "Core Lightning is one of the major implementations," never "the Core Lightning."
Lowercase the components: "lightningd" (daemon) and "lightning-cli" (hyphenated CLI), never capitalized.
Spell "Greenlight" one word, capital G: never Green Light or GreenLight; never conflate with the retired "Blockstream Green" app.
Name the managed offering "Blockstream Enterprise Lightning": interim rebrand lock; keep "lightning" because customers search it.
Order multi-product lists consumer first, infrastructure (Liquid, Core Lightning, Satellite) second, enterprise third.
Say this, not that
The usage dictionary. When in doubt, search it.
| Topic | Write | Never write | Why |
|---|---|---|---|
| Greenlight | Greenlight (one word, capital G) | Green Light · GreenLight | never conflate with the retired Green app |
| Swap arrows | the ↔ arrow for bidirectional swaps | ↔ in mere layer lists | "Lightning and Liquid rails" takes no arrow |
| The asset on Lightning | Lightning bitcoin (lowercase b for the asset) | Lightning BTC | capital B only for the concept |
| The implementation | Core Lightning · CLN after first reference | Core-Lightning · cln · "the Core Lightning" | no article, ever |
| The network name | Lightning Network | Lightning network | |
| Protocol shorthand | HTLC · BOLT · gossip · routing, in dev content | protocol names in inline code | |
| Greenlight custody | the developer retains key control | custodial, about Greenlight | it provisions nodes only |
| Third-party infra | Swap fee · Network fee | Boltz or any provider brand in UI | generic protocol terms are fine |
| The old name | Core Lightning | c-lightning · C-lightning · C-Lightning | retired; historical context only |
| Runes | Runes: CLN's token-based RPC auth | macaroons (that is LND) | delegatable permissions |
| The category | Lightning-as-a-Service (Greenlight) | the positioning space; 200K+ nodes |
Voice & tone
How the copy sounds, and where the register switches.
Write CLN in developer voice: technical, implementation-first; never marketing language, omit versions, or promise unshipped features.
Switch register by surface: API docs code-forward, release notes changelog-style, blog authoritative, @Core_LN approachable.
Write releases as a maintainer: explain the why; no "We're excited to announce" or PR lists; playful headers (Reckless Mode) allowed.
Open releases with the ritual: "Core Lightning vYY.MM: Codename" title, commit stats, namer credited, every contributor by handle.
Voice Enterprise Lightning formal: operator and buyer register, not developer-casual; @Core_LN stays casual and credits contributors.
Format for developers: inline code for terms and commands, pre blocks for CLI and JSON, "(v25.12+)" version tags, quantify performance.
Link discipline: GitHub is the source of truth; docs.corelightning.org for docs; external blog links carry ?ref=blog.blockstream.com.
Positioning
What to lead with, what to always pair, what never to claim.
These points are an amalgamation of what has been learned so far, from product docs, launches, and reviewer feedback. They are not definitive or authoritative positioning from anyone. Product marketing still needs to clearly define positioning for this product, which will happen in a follow-up.
Lead with production-grade infrastructure: frame CLN for developers and businesses; send consumer Lightning to Jade and the app.
Frame CLN by its differentiators: modularity, privacy defaults, first dual-funded channels, in production on mainnet since early 2018.
Always name the plugin architecture: it sets CLN apart from other implementations; omitting it is a documented mistake.
Never claim sole ownership of Core Lightning: contributions were collaborative; credit the community, not Blockstream alone.
Address the "is Core Lightning dying?" question: the rebrand calls for an honest refresh; add LDK to the competitor chart or drop it.
Never attack competitors by name: the CLN/LND/Eclair table stays internal; any public version stays factual, dated, and legal-scanned.
Greenlight (managed nodes, your keys, no walled gardens): hold public use until PM confirms status; being pulled to internal tooling.
Claims
What a page or post may cite. Confirm, correct, or kill each row; an unconfirmed claim does not ship.
| Claim | As of | Status |
|---|---|---|
| Core Lightning in production on mainnet since early 2018 | current docs | approved |
| First implementation with dual-funded channels | current docs | approved |
| Greenlight: 200,000+ nodes, 20x growth in 2024 | Q4 2024 | confirm or kill |
Open questions
Unresolved tensions for review. Don't resolve these in copy; flag them.
- Enterprise Lightning undocumented: blockstream-enterprise.md and personas-enterprise.md omit Lightning; only copy is the Greenlight Enterprise pricing tier in core-lightning.md.
- x-core-ln.md has "[NEEDS INPUT]" placeholders for structural patterns, formatting conventions, and posting schedule; the @Core_LN guide is incomplete.
- Lightning Charge conflict: brand docs treat it as active sub-brand, but maintained Products/core-lightning.md (2026-03-14) never mentions it. Needs keep/retire call.
- Release boilerplate says implementation "in C"; Products/core-lightning.md says "C and Rust". Codename conflict too: v25.02 is "Blockchain Naysayer" vs "Onion Packet Filler Accreditation".
- Greenlight "200,000+ nodes, 20x growth in 2024" sourced to Q4 2024 update, repeated undated in positioning.md; re-verify before reuse.
- No Lightning-specific competitor-copy rules; the LND/Eclair table carries no usage guidance, only generic project-wide competitor rules apply.
- Greenlight contradiction: survey messaging positions Greenlight as a public product (managed nodes, 200K+ nodes), but the rebrand pulls it to internal tooling ("any open-source page depends on Christian"). Public Greenlight copy is on hold pending a PM decision.
Notepad
Scribble anything: loose thoughts, questions, things that don't fit a pin or a highlight. Saves automatically with the review feedback.