Skip to main content

Design Philosophy

Lightning Enable is infrastructure. These principles guide its design.

Non-Ideological​

We do not advocate for any monetary system, economic theory, or political position. Lightning Network is a technology. We use it because it provides millisecond settlement at negligible cost. If a better technology emerges, we will evaluate it on technical merits.

Mechanical​

The system is deterministic. Same inputs produce same outputs. No human judgment in the critical path. No discretionary decisions about which settlements to process.

if valid_request:
create_invoice()

if valid_preimage:
grant_access()

This is not a feature. It is a requirement for software that operates autonomously.

We Never Touch Funds​

Lightning Enable never holds funds — your payment provider (Strike or OpenNode) facilitates custody and settlement. This is an architectural constraint that removes an entire category of failure modes:

  • No insolvency risk from us
  • Simplified regulatory posture
  • No counterparty risk from us
  • No key management complexity

Custody belongs with entities designed for custody. Your payment provider is licensed, regulated, and designed for this responsibility.

Boring​

Good infrastructure is boring. It works. It does not surprise you. It does not require attention.

We optimize for:

  • Predictability over features
  • Stability over velocity
  • Simplicity over capability

Protocol-Native​

We build on open protocols (Lightning Network, L402) rather than proprietary systems. This ensures:

  • No vendor lock-in
  • Interoperability with the broader ecosystem
  • Long-term sustainability independent of any single company

Constraints We Accept​

These are intentional limitations:

ConstraintRationale
Lightning-firstLightning is the settlement rail. Providers may also supply an on-chain fallback address (onchainAddress on invoices) for wallets that cannot pay Lightning
Payment provider dependencyOutsource custody to specialists (Strike or OpenNode)
No transaction feesRemoves incentive misalignment
One codebase, plan-based capabilitiesEvery merchant runs the same service; what differs is which capabilities your subscription plan enables — never a bespoke build

What We Do Not Do​

  • Process payments (your payment provider does this)
  • Hold funds (your payment provider does this)
  • Make decisions about settlements (the protocol does this)
  • Provide financial advice (lawyers and accountants do this)
  • Evangelize (marketing does this)

We are plumbing. The water flows through us. We do not own the water.

Further Reading​