Skip to main content

Core Concepts

This section covers the fundamental concepts that underpin Lightning Enable as a settlement layer.

Settlement vs Payment​

A payment implies a human transaction: invoices, receipts, reconciliation, dispute resolution.

A settlement is a primitive: value transferred, proof returned, state updated. No interpretation required.

Lightning Enable operates at the settlement layer. The business logic that interprets settlements as payments, subscriptions, or access grants lives in your application.

The Request-Settlement Model​

Traditional payment flows:

Request → Queue → Batch → Process → Confirm → Settle
(hours to days)

Settlement flows:

Request → Settle → Response
(milliseconds)

Settlement happens synchronously with the request. When your code returns, settlement is final.

Cryptographic Proof​

Every settlement produces a preimage - a 32-byte value that proves settlement occurred. The SHA-256 hash of the preimage matches the payment hash embedded in the Lightning invoice.

invoice contains: payment_hash
settlement returns: preimage
verification: SHA256(preimage) == payment_hash

This proof is cryptographically unforgeable. Either settlement happened and you have the preimage, or it did not.

API Middleware Architecture​

Lightning Enable never holds funds. OpenNode facilitates custody and settlement, executing the actual value transfer on Lightning Network.

Your App → Lightning Enable → OpenNode → Lightning Network
           (API middleware)   (custody)   (settlement)

We are infrastructure. OpenNode is the custodian. Lightning Network is the settlement rail.

Invoice Lifecycle​

  1. Created - Invoice generated, awaiting settlement
  2. Processing - Settlement detected, confirming
  3. Settled - Settlement complete, preimage available
  4. Expired - Invoice timeout, no settlement

Invoices are ephemeral. Create them on demand, let them expire if unused.

Further Reading​