Lightning and Ryvo both move payment authorization off-chain, but they scale in fundamentally different ways.Documentation Index
Fetch the complete documentation index at: https://docs.ryvo.network/llms.txt
Use this file to discover all available pages before exploring further.
What Lightning optimizes for
Lightning is designed to move value across an arbitrary network of participants who don’t have a pre-existing relationship. Its core problems are:- Routing - finding a path of channels that can carry a payment from sender to receiver.
- Liquidity - maintaining enough inbound and outbound capacity along that path.
- Path-dependent fees - each hop prices its share of the forwarding cost.
- HTLCs - atomic multi-hop updates with time-locked resolution.
What Ryvo optimizes for
Ryvo assumes the opposite shape: the same payer and payee interact constantly, and the system should compress their on-chain settlement as that volume grows. Ryvo does not route. Every channel is one-way and direct between a named payer and a named payee. There is no multi-hop path, no forwarding fee market, and no liquidity rebalancing. Density comes from a different place:- Cumulative commitments collapse many payments along one channel into a single signed value.
- Bundle settlement collapses many channels feeding the same payee into one transaction.
- Cooperative clearing rounds collapse many channels across many participants into one shared transaction that advances them all at once.
When each model fits best
| Lightning | Ryvo | |
|---|---|---|
| Shape of relationships | Sparse, often one-shot, across an arbitrary graph | Dense, repeated, between known pairs |
| Scaling primitive | Routing + channel liquidity | Cumulative commitments + cooperative clearing |
| Asset | Bitcoin | Allowlisted SPL tokens on Solana |
| Settlement substrate | Bitcoin L1 | Solana |
| Fee model | Per-hop forwarding | Per-settlement-tx |
| Operator role | Routing nodes | Optional hubs / delegated settlers |