• Off-chain payments move payment activity away from a blockchain’s base layer, reducing the need to record every individual transaction on-chain.
• Different off-chain approaches make different trade-offs. Custodial payments, sidechains, rollups, and payment channels differ significantly in how they achieve scalability and where their security comes from.
• Payment channels let participants commit funds on-chain once and transact repeatedly off-chain, using the blockchain primarily for opening, closing, and enforcing the channel.
• Payment channel networks connect individual channels, allowing payments to be routed between users who do not share a direct connection.
• Fiber Network applies the payment-channel model to CKB, enabling high-frequency, multi-asset payments, embedded asset swaps, and interoperability with the Bitcoin Lightning Network.

Blockchains are excellent settlement systems. They allow participants who do not trust one another to agree on who owns what without relying on a central intermediary.

But that security comes with a cost.

Every on-chain payment must enter the blockchain’s global consensus process, compete for limited blockspace, and ultimately become part of a ledger replicated across the network. That model works well when strong settlement guarantees matter more than speed or cost. It becomes much less efficient when payments are tiny, frequent, or continuous.

Imagine recording every API request, every second of EV charging, or every fraction-of-a-cent machine payment as a separate transaction on a public blockchain. Even a relatively fast blockchain eventually runs into the same basic problem: requiring the entire network to process every payment is an expensive way to handle activity that may only concern two parties.

Off-chain payments take that activity out of the global consensus loop.

Instead of committing every payment individually to the base blockchain, participants transact through another system and use the blockchain only where its security is actually needed—for settlement, enforcement, dispute resolution, or moving funds into and out of the system.

The important distinction is that “off-chain” is an umbrella term, not a single architecture. An exchange updating balances in its private database is off-chain. So is a rollup executing transactions outside Ethereum. So is a Lightning payment passing through a network of payment channels.

They achieve greater scalability in very different ways, and they inherit very different trust assumptions.

This guide explains how those approaches work, where their security comes from, and why payment channel networks are particularly well suited to high-frequency, low-value, real-time payments.

An off-chain payment is a payment that does not require every individual transaction to be recorded directly on a blockchain’s base layer.

With an on-chain payment, the transaction is broadcast to the network, included in a block, and verified through the blockchain’s consensus process. With an off-chain payment, some or all of that activity happens elsewhere.

That “elsewhere” can take very different forms. A centralized exchange can update balances in its private database, a rollup can execute transactions outside the base chain and later post data or proofs back to it, and a payment channel can let two participants exchange signed balance updates privately and use the blockchain only when the channel is opened, closed, or disputed.

What these systems have in common is that they reduce the amount of activity the base blockchain must process directly.

What they do not have in common is how they secure funds.

Some off-chain systems require users to trust an intermediary, while others remain non-custodial and rely on cryptography and blockchain-enforced rules. Some periodically post transaction data back to the base chain, while others may keep individual payments entirely off-chain.

So “off-chain” really describes where transactions are processed, not the security model behind them.

The basic trade-off is straightforward: on-chain payments use the blockchain’s consensus process for every transaction, while off-chain systems avoid doing so for every individual payment.

Factor	On-chain payments	Off-chain payments
Where payment activity happens	Directly on the blockchain’s base layer.	Outside the base layer, through a secondary protocol or centralized system.
Blockchain involvement	Every transaction must be submitted to and processed by the blockchain.	Depends on the design. The blockchain may be used for deposits and withdrawals, periodic settlement, channel opening and closing, or dispute resolution.
Speed	Limited by block production, confirmation requirements, and network congestion.	Often much faster because individual payments do not need to wait for base-layer confirmation.
Cost	Each transaction generally incurs a blockchain network fee.	Usually lowers the blockchain cost per payment, although routing fees, service fees, proving costs, or other charges may still apply.
Scalability	Constrained by the throughput and blockspace of the base blockchain.	Can support much higher transaction volumes by moving repeated activity away from the base layer.
Security and trust	Directly secured by the blockchain’s consensus rules.	Varies by architecture: it may depend on a custodian, another validator set, cryptographic proofs, or blockchain-enforceable contracts.
On-chain footprint	Every payment becomes part of the blockchain’s transaction history.	Individual payments may never appear on-chain, or may be represented indirectly through aggregated data, proofs, or final settlement transactions.

Moving payments away from a blockchain’s base layer can be done in several fundamentally different ways.

The most useful way to compare them is not simply by asking how fast or cheap they are, but what makes a payment trustworthy once the base chain is no longer processing every transaction directly.

In some systems, you trust a company. In others, you trust another blockchain. Rollups rely on the base chain to verify or challenge batches of transactions. Payment channels rely on contracts that let participants enforce the latest valid balance on-chain if necessary.

These differences produce four major approaches.

1. Custodial Off-Chain Payments

The simplest form of off-chain payment is a transfer inside a custodial platform.

Binance Pay is a useful example. It allows Binance users to send cryptocurrency to one another using a QR code, payment link, email address, phone number, or Binance ID. The recipient receives the funds in their Binance account almost immediately, and most peer-to-peer transfers carry no fee.

But if Alice sends Bob $100 worth of USDT through Binance Pay, Binance does not need to broadcast a USDT transaction to the blockchain.

Both Alice and Bob already hold their funds with Binance. The platform can therefore process the payment internally: Alice’s account balance decreases by $100 and Bob’s increases by $100. Binance remains the custodian of the underlying assets; what changes is its internal record of how much belongs to each user.

This is fundamentally different from Alice sending USDT from her own wallet to Bob’s. In that case, the transfer must be submitted to the relevant blockchain and confirmed by the network.

Advantages: This model is extremely efficient. Payments between users of the same platform can be effectively instant and avoid blockchain network fees altogether. Users also do not have to think about block confirmations, gas fees, routing, or liquidity management.

Trade-offs: The efficiency comes from replacing blockchain enforcement with trust in the custodian. Binance controls the assets and maintains the authoritative record of user balances. Users must therefore trust it to remain solvent, secure the funds, maintain accurate records, and honor withdrawals.

In other words, custodial payments achieve excellent speed and scalability by taking both the transaction and control of the funds off-chain.

2. Sidechains

A sidechain moves activity away from the base chain by giving users another blockchain to transact on.

The sidechain has its own blocks, consensus rules, and validator or miner set. Assets can be transferred between the base chain and sidechain through a bridge, after which transactions take place according to the sidechain’s rules.

Importantly, these transactions are not literally “off-chain”: they are on-chain transactions on a different blockchain. What has moved off the base layer is the workload.

Advantages: Sidechains can be designed for higher throughput, lower fees, faster blocks, or functionality the base chain does not support. Developers also have substantial freedom to change the execution environment and network rules.

Trade-offs: A sidechain does not automatically inherit the security of the blockchain it connects to. Users must trust the sidechain’s own consensus system as well as the mechanism or the bridge used to move assets between the two networks.

This makes sidechains better understood as parallel blockchains used to scale activity, rather than extensions whose security comes directly from the base chain.

3. Rollups

Rollups take a different approach. Instead of asking the base chain to execute every transaction individually, they execute transactions in a separate environment, combine many of them into batches, and use the base chain to verify and settle the resulting state.

There are two main designs.

Optimistic rollups assume proposed state updates are valid unless someone successfully challenges them during a dispute period.

ZK rollups generate cryptographic validity proofs showing that the new state follows correctly from the previous one.

In both cases, much of the computation happens away from Layer 1 while the base chain remains responsible for enforcing the rollup’s state commitments and security rules.

Advantages: Rollups can substantially increase throughput while retaining much stronger ties to the security of the base chain than sidechains. They can also support general-purpose applications where many users interact with shared state, including decentralized exchanges, lending markets, games, and other decentralized applications.

Trade-offs: Rollups still consume base-layer resources. Batches, state commitments, proofs, and/or transaction data must ultimately be submitted to Layer 1, so the cost of using the base chain is reduced and shared across many transactions rather than eliminated entirely.

They also introduce additional infrastructure and complexity. ZK rollups require proof generation and verification, while optimistic rollups typically impose a challenge period before a native withdrawal to the base chain can be considered final.

Rollups are therefore particularly useful when the goal is to scale a programmable blockchain environment, rather than optimize exclusively for payments.

4. Payment Channels

Payment channels take a more specialized approach.

Instead of repeatedly submitting transactions to a blockchain (or batching them periodically) two participants commit funds to an on-chain contract and then transact directly with one another by exchanging signed updates to their shared balance.

Suppose Alice and Bob open a channel containing $100. If Alice pays Bob $1, they do not broadcast a blockchain transaction. They simply create a new valid channel state saying Alice now owns $99 and Bob owns $1.

If Alice pays Bob again, they replace it with another state.

They can continue doing this repeatedly without asking the blockchain to process each payment. When they eventually close the channel, the latest valid balance can be settled on-chain.

The blockchain therefore moves from being the processor of every payment to the enforcer of the agreement.

Advantages: Once a channel is funded, individual payments do not require blockspace or base-layer confirmation. Payments can complete with very low latency, base-layer fees can be amortized across large numbers of transactions, and individual channel updates do not need to be published to the entire network. Participants also retain control over their funds: if cooperation breaks down, the channel protocol provides a way to enforce the valid state through the underlying blockchain.

Trade-offs: Payment channels exchange blockchain throughput constraints for liquidity constraints. Funds must be committed to channels in advance, and that liquidity is directional. This means that, if a channel holds $1,000 but only $100 is currently on Alice’s side, Alice can send at most $100 to Bob. The remaining $900 is on Bob’s side and can only support payments in the opposite direction. This is why a channel can have plenty of total capacity but still be unable to route a particular payment.

A direct channel also connects only its participants. Scaling the model beyond pairs requires payment channel networks, which route payments across multiple connected channels and introduce additional challenges around pathfinding, liquidity management, reliability, and routing fees.

Unlike rollups, payment channels are not intended to reproduce a general-purpose shared execution environment. They are specialized infrastructure for moving value repeatedly and efficiently.

Approach	What replaces direct base-layer processing?	Best suited to	Main trade-off
Custodial payments	A company’s internal ledger	Transfers within a platform	Users must trust the custodian with their funds
Sidechains	Another blockchain and its consensus system	Applications that need different rules or greater throughput	Separate security assumptions and bridge risk
Rollups	Off-L1 execution with state anchored and verified on the base chain	General-purpose applications and shared state	L1 data costs, additional complexity, and—in some designs—withdrawal delays
Payment channels	Signed state updates backed by an enforceable on-chain contract	High-frequency, low-value, latency-sensitive payments	Locked liquidity, routing, and channel management

None of these approaches is universally “best.” They optimize for different problems.

For general-purpose applications with many users interacting with shared state, rollups are often a natural fit. If users are willing to trust a platform, a custodial ledger offers exceptional simplicity.

But if the problem is specifically moving value frequently, cheaply, and with very low latency while preserving self-custody, payment channels have a particularly useful architecture.

A payment channel is highly efficient when the same two parties transact repeatedly. But opening a separate channel with everyone you might ever want to pay would defeat much of the purpose.

Payment channel networks solve this by connecting individual channels into a larger routing network.

If Alice has a channel with Bob, and Bob has one with Carol, Alice can pay Carol through Bob without opening a new channel with Carol. Extend this across thousands of connected channels and users can send payments across the network as long as a route with sufficient liquidity exists. Lightning and Fiber both use this multi-hop model.

For payments specifically—as distinct from general-purpose computation—this architecture offers several important advantages.

An on-chain payment must wait for the blockchain to include and confirm a transaction. A channel payment does not.

Instead, the participants exchange cryptographically signed updates to the channel state. In a multi-hop payment, those updates propagate across the channels along the selected route. No new block needs to be produced for the individual payment to complete.

The blockchain remains in the background as the enforcement layer: if participants disagree or a channel needs to close, the valid channel state can ultimately be enforced on-chain.

This distinction is important. The payment can complete off-chain in seconds or less even though the channel itself may not settle back to the blockchain until much later.

Payment channels also change the economics of repeated payments.

Opening a channel requires an on-chain transaction, and eventually closing it may require another. But the potentially thousands—or millions—of payments made while that channel is open do not each require their own base-layer transaction.

The more the channel is reused, the more those initial blockchain costs are amortized across its payments.

That does not mean channel payments are necessarily free. A direct payment between two channel partners may have no routing fee, while a payment routed through other nodes will generally pay those nodes for forwarding it and providing liquidity. Lightning and Fiber both allow intermediate nodes to charge routing fees.

The important difference is that the blockchain does not impose a separate network fee on every payment. This makes payment channels particularly attractive for frequent, low-value transfers where repeatedly paying for blockspace would be uneconomical.

Payment channel networks can provide the speed of an off-chain system without requiring users to hand custody of their funds to a central operator.

Funds committed to a channel are controlled according to rules enforced by the underlying blockchain. During the life of the channel, the participants exchange signed states describing how those funds should be divided. If one party stops cooperating, the other does not need its permission—or the permission of a network operator—to close the channel and enforce the valid balance on-chain.

This is the fundamental difference from something like Binance Pay.

Both systems avoid putting every payment on a blockchain. But with Binance Pay, Binance maintains the authoritative ledger and controls the underlying assets. With a non-custodial payment channel, the participants retain the cryptographic ability to enforce their claims to the funds through the base chain.

There is still an operational responsibility: channel participants must be able to respond if a counterparty attempts to settle an outdated state, either themselves or through mechanisms such as watchtowers. But they do not need to entrust custody of their funds to a payment company.

Payment channels also reduce the amount of financial activity exposed on a public blockchain.

If Alice and Bob make 10,000 payments through the same channel, those individual balance updates do not need to appear as 10,000 public blockchain transactions. The blockchain primarily sees the transactions that establish and eventually settle the channel.

Payment channel networks can add another layer of privacy through onion routing. In Lightning and Fiber, routing instructions are encrypted in layers so that an intermediate node generally learns only where the payment came from immediately before it and where it needs to send it next—not the complete route.

This should not be confused with perfect anonymity. Individual routing nodes still learn information about the payments they forward, and additional information may be inferred from network topology, timing, endpoints, or colluding participants.

The advantage is more fundamental: individual payments are not globally broadcast and permanently recorded for everyone to inspect.

Taken together, these properties make payment channel networks particularly well suited to payments that are frequent, small, or latency-sensitive. They move routine payment activity out of global consensus while keeping the blockchain available for the job it does best: enforcing ownership and resolving disputes.

For a deeper dive into the mechanics of how these networks operate, read the Ultimate Guide to Payment Channels and Payment Channel Networks.

The basic idea behind a payment channel network is simple: lock value on-chain, move payments off-chain, and route them through a network of interconnected channels.

But the capabilities of a payment channel network also depend on the blockchain underneath it.

The Lightning Network and Fiber Network provide a useful comparison. Both use the same broad architecture—payment channels, multi-hop routing, and cryptographically secured conditional payments—but they are built on base layers with very different capabilities.

The Lightning Network is a payment channel network built on Bitcoin.

Two participants can commit bitcoin to a jointly controlled on-chain funding output and then update the distribution of those funds off-chain. When users do not share a direct channel, Lightning routes payments through channels belonging to other participants.

Multi-hop payments are secured using Hashed Timelock Contracts (HTLCs). In simplified terms, each hop agrees to forward the payment only if the same cryptographic secret is revealed before a deadline. This links the transfers together so an intermediary cannot simply take the incoming payment without fulfilling its corresponding outgoing payment.

Lightning has demonstrated that a decentralized payment channel network can move Bitcoin without requiring an on-chain transaction for every payment. But operating such a network introduces challenges that do not exist with a simple blockchain transfer.

The most important is liquidity management.

Channel liquidity is directional. If Alice and Bob share a channel containing 1 BTC, but the entire balance currently sits on Alice’s side, Alice can send up to 1 BTC to Bob—but Bob cannot send anything back until some balance has moved to his side.

The same constraint applies across the network. For a payment to succeed, every channel along the selected route must have enough liquidity available in the correct direction.

This is particularly important for receiving payments. If a new Lightning user opens and fully funds a channel themselves, they initially have outbound liquidity but no inbound liquidity through that channel. Someone else must eventually commit or move bitcoin toward their side before they can receive it. Lightning Labs describes acquiring and maintaining inbound liquidity as an important operational requirement for merchants and routing nodes.

Lightning has developed an ecosystem of tools for handling these constraints, including channel rebalancing, submarine swaps, and liquidity marketplaces. But liquidity remains something participants must actively manage.

There is also a broader architectural constraint: Bitcoin itself natively accounts for one asset, BTC, and deliberately offers a relatively constrained scripting environment.

That does not mean Lightning can never support other assets. Protocols such as Taproot Assets can bring issued assets into Lightning-compatible channels and route them through the network. But those capabilities are added through additional protocol layers rather than being native properties of Bitcoin itself.

Fiber Network applies the payment-channel model to CKB, a programmable UTXO-based blockchain with a RISC-V VM, CKB-VM.

At the basic level, the mechanics are familiar. Participants commit assets to channels, exchange signed state updates off-chain, and route payments through intermediate nodes when they do not share a direct channel. CKB acts as the settlement and enforcement layer if a channel is closed or disputed.

The difference is that CKB’s programmability allows Fiber to extend the payment-channel model beyond payments denominated only in the base asset.

Multi-Asset Payments

Fiber is designed to support channels denominated in different assets, including CKB and User Defined Tokens (UDTs), such as stablecoins and other assets represented on CKB.

A Fiber invoice can specify the particular UDT being requested, and payments can then be routed through channels that support that asset.

This makes Fiber a multi-asset payment network: different parts of the network can provide liquidity for different assets rather than requiring every payment to be denominated in CKB.

Fiber’s documentation also describes support for stablecoins, RGB++ assets associated with Bitcoin, and CKB-issued UDTs.

Programmable Channel Logic

The second difference comes from CKB’s scripting model.

Fiber’s channel contracts are implemented using CKB Scripts, meaning the logic governing channel settlement and other conditions can take advantage of CKB’s programmable transaction model rather than being limited entirely by a fixed set of base-layer payment primitives.

This gives Fiber more room to extend the types of financial interactions that can be built around payment channels, including conditional payments and asset swaps.

Payments and Asset Swaps

Because Fiber can support liquidity across multiple assets, the network can do more than simply route a payment denominated in one asset from sender to recipient.

It is also designed to support asset swaps.

Imagine Alice holds CKB but wants to make a payment ultimately denominated in a stablecoin. A routing or liquidity provider that has access to channels for both assets can facilitate the conversion as part of the payment flow.

Rather than requiring Alice to first visit an exchange, swap CKB for the stablecoin, and then initiate a separate payment, the exchange of assets can become part of the payment process itself.

The crucial property is atomicity: the two sides of the exchange are cryptographically linked so that either the intended exchange completes or the conditional transfers fail and the funds remain with their original owners.

Fiber therefore aims to combine two functions that are traditionally separate: moving value and exchanging the form that value takes.

Lightning Interoperability

Fiber is also designed to interoperate with the Lightning Network rather than operate as an isolated payment system.

A Cross-Chain Hub can operate across Fiber and Lightning and connect a payment on one network with a corresponding payment on the other. Fiber’s current tooling includes cross-chain constructs specifically for payments between the two networks.

Suppose Alice has assets on Fiber but wants to pay Bob, who accepts BTC over Lightning.

The hub can accept the incoming Fiber-side payment and make the corresponding Lightning payment to Bob. The two transfers are linked through the same cryptographic condition: revealing the secret required to complete one side provides the information needed to complete the other.

The hub therefore provides liquidity and connectivity rather than custody. It cannot successfully claim the incoming conditional payment while simply refusing to complete the outgoing one; if the conditions are not satisfied before their time limits expire, the transfers unwind instead. Fiber’s hold-invoice design uses this shared-preimage mechanism for atomic swaps and cross-network payments.

The result is a broader vision of a payment channel network.

Lightning demonstrates how Bitcoin can be transformed into a fast, routed payment system without putting every payment on-chain. Fiber starts with the same basic mechanism but uses CKB’s programmability and asset model to extend it toward multi-asset payments, embedded swaps, and interoperability between payment networks.

The real advantage of payment channels appears when payments become frequent, small, or time-sensitive.

Traditional payment systems generally bundle economic activity into larger transactions. A subscription might be charged once a month. Cloud usage might accumulate until an invoice is issued. A blockchain application might wait until enough value has accumulated to justify an on-chain transaction.

There is a reason for this: every payment has overhead.

Card networks charge fixed and percentage-based fees. Bank transfers involve intermediaries and settlement processes. On-chain blockchain payments consume blockspace and require network fees. When the payment itself is worth only a fraction of a cent, that overhead can exceed the value being transferred.

Payment channels change this equation. Once liquidity is committed to a channel, repeated payments can happen without creating a new blockchain transaction each time. That makes much smaller and more frequent transfers economically practical.

Micropayments allow users to pay tiny amounts for individual units of digital value rather than purchasing them in larger bundles.

A reader might pay a fraction of a cent to unlock an article. An application might pay for a single database query. An AI agent might pay for one model inference or one API request.

The important point is not any particular price threshold. It is that the payment can become smaller than would economically make sense on conventional payment rails or directly on-chain.

Instead of bundling thousands of interactions into one subscription or invoice, each interaction can potentially become its own economic transaction.

If individual payments are cheap enough, they can also happen repeatedly over very short intervals.

Consider an electric vehicle connected to a charging station. Instead of authorizing a large payment upfront and reconciling the actual electricity consumed afterward, the vehicle could make a sequence of small payments as energy is delivered.

The same model could apply to compute, bandwidth, storage, or other metered resources.

These do not necessarily need to be literal payment “streams” in which money flows continuously. In practice, they can be a rapid series of discrete microtransactions that closely tracks consumption.

This creates a different payment model: value can move alongside the service being delivered rather than being reconciled long afterward.

Most digital services today aggregate usage because charging for every individual action would be inefficient.

A cloud provider might therefore bill monthly. An API provider may sell bundles of credits. A software product may charge a flat subscription regardless of how much the customer actually uses.

Low-cost off-chain payments make much finer-grained billing possible.

Instead of paying $20 per month for access, a user could pay only when a service is consumed: per request, per megabyte, per second of compute, or per unit of some other measurable resource.

This does not mean subscriptions disappear. It means services gain another option: billing can more closely match actual consumption.

This becomes especially important when the payer is no longer a human.

Software agents, connected devices, and autonomous machines can consume resources far more frequently than humans make purchases. An AI agent might query several data providers, purchase inference from a model, rent compute for a task, and pay another service for the result—all without a person approving each transaction individually.

Traditional payment infrastructure was largely designed around humans initiating relatively infrequent purchases. Machine-to-machine commerce can require something different: payments that are programmable, automatic, global, and economical even at very small values.

Payment channels are well suited to this environment because machines can reuse existing liquidity to make large numbers of low-latency payments without submitting every interaction to a blockchain.

The same economics apply to digital experiences where stopping to process a conventional payment would be disproportionate to the value being exchanged.

Players could purchase small digital items or transfer value without waiting for blockchain confirmations. Readers or viewers could make tiny payments for individual pieces of content. Users could tip creators amounts too small to justify conventional payment-processing fees.

The common requirement is that the payment should fade into the interaction rather than interrupt it.

Payment channel networks can also move value across borders without requiring each transfer to pass through the traditional chain of correspondent banks.

A sender can route a payment across an internet-native network and have it reach the recipient within seconds, with routing fees determined by the network rather than by a sequence of banking intermediaries.

Multi-asset networks can potentially extend this model further. If liquidity providers can exchange assets inside the payment path, the sender and recipient do not necessarily need to use the same asset.

A sender might pay using one currency or token while the recipient receives another, with the conversion taking place as part of the transfer.

This does not eliminate every challenge associated with international payments—foreign-exchange liquidity, regulation, fiat on- and off-ramps, and local access still matter—but it can significantly simplify the underlying movement of value.

What ties all of these scenarios together is not simply that payment channels are “fast.”

It is that they make repeated economic interactions cheap enough to become payments themselves.

An API call, a second of compute, a kilowatt-hour of electricity, or a small piece of digital content no longer has to be bundled into a larger transaction simply because processing the payment would otherwise cost too much.

That is where off-chain payment infrastructure becomes more than a way to scale existing payments. It begins to enable payment models that are difficult—or economically impossible—on conventional rails and base-layer blockchains.

Off-chain payments are payments processed without recording every individual transaction directly on a blockchain’s base layer. The blockchain may still be used for settlement, enforcement, or dispute resolution.

On-chain payments are processed and recorded directly by the blockchain, while off-chain payments move some or all of that activity outside the base layer. This generally allows for higher throughput, lower costs, and faster payments.

Usually. Off-chain payments can avoid waiting for block production and confirmation, allowing systems such as payment channels to complete payments in seconds or less.

Usually, especially when the same off-chain infrastructure is reused many times. Payment channels, for example, avoid paying a blockchain network fee for every individual payment, although routing fees may still apply.

No. A payment channel is one specific mechanism for making off-chain payments; other approaches include custodial transfers and rollups.

Two participants commit funds on-chain and then repeatedly update how those funds are divided by exchanging signed states off-chain. The blockchain is used when the channel is opened, closed, or needs to be enforced.

A payment channel network connects individual channels so users can route payments through intermediaries without opening a direct channel with every recipient. Lightning Network and Fiber Network are examples.

Rollups are generally designed to scale shared blockchain applications, while payment channels specialize in moving value quickly and repeatedly. This makes channels particularly well suited to micropayments and other high-frequency payments.

Their main challenge is liquidity: funds must be committed in advance, and sufficient liquidity must be available in the right direction along the payment route. Channels and routing liquidity may therefore need to be actively managed.

They offer greater privacy than fully on-chain payments because individual payments are not publicly recorded on the blockchain. However, they are not perfectly anonymous, and routing participants can still observe some payment information.

Lightning is built on Bitcoin and primarily handles BTC, while Fiber is built on CKB and is designed for multi-asset payments, programmable channel logic, asset swaps, and Lightning interoperability.