Author: Peter Todd
Source: https://petertodd.org/2025/fake-channels-and-rgb-lightning
One counterintuitive thing about the Lightning Network protocol is that the intermediate channels in the path that forward your payment don't necessarily have to be "real" channels. If Alice wants to pay David with Bitcoin, via the path Alice ↔ Bob ↔ Charlie ↔ David, then whether the Lightning channel between Bob and Charlie is real—a real channel locking in Bitcoin—or fake, is irrelevant! In fact, for Alice, it doesn't even matter whether David receives Bitcoin or not. What matters to her is that David accepted the payment (revealing the truth); if he hadn't revealed the truth, Alice would never have paid him money for no reason.
Similarly, if Alice is receiving a Bitcoin payment from David via the path David ↔ Charlie ↔ Bob ↔ Alice, Alice doesn't care whether David pays Charlie with real Bitcoin, or what Charlie pays Bob with. All she cares about is that Bob has been convinced to send her real Bitcoin, regardless.
The existing Lightning Network protocol does guarantee that public channels correspond to valid UTXOs. However, the rationale for this is solely to combat DoS attacks: there must be some way to limit the number of channels that can be broadcast. Binding Lightning channel UTXOs to gossip announcements is precisely the approach we (currently) have chosen.
Lightning Channel for client-side token verification
The fact that Lightning payments can be securely routed through publicly accessible "fake channels" has remained a theoretical topic for the Lightning Network, which is built on top of Bitcoin. It was conceived as a way to reduce liquidity requirements when establishing channels between mutually trusting parties. However, this idea has never been realized.
However, it's a completely different story when it comes to Lightning channels that establish client-verified tokens.
To recap, the client-verified token uses a protocol like " RGB ," treating the Bitcoin network as a purely anti-double-spending mechanism: the Bitcoin protocol simply ensures that a given coin has only one history. The validity of this history is verified by the client (the user themselves). Therefore, if Alice wants to give Bob a previous hold representing $1 (based on the RGB protocol), she only needs to convince Bob that the coin is real by providing him with the coin's complete history (tracing back from the transaction that created the coin to its genesis output).
Because this history is not global, client-verified tokens have enormous scalability potential. As I explained in this blog post , a client-verified token can literally handle billions of transactions per second. However, these transactions are still in-chain transactions, meaning they still require time to confirm; while lightning transactions can be near instantaneous.
Therefore, both RGB and "Taproot Assets" are developing lightning channels for transaction clients to verify tokens.
This brings us back to the issue of "fake" channels: While it might require several MB of transaction data to prove that an RGB token in your possession is genuine, if you use this token in a Lightning Channel, you don't need to know whether any other person's Lightning Channel has a genuine RGB token! As long as there is evidence that your channel is genuine and completely self-custodied, that's enough; if others are tricked into accepting fake currency, that's not your problem.
Taproot Asset “Universe”
This raises an interesting question: are the " universes " in the Taproot Asset protocol truly necessary? The idea behind this design is that light clients will—not verify themselves, but—trust third-party "universes" to perform currency verification for the assets they want to trade. These universes are expected to know all (or at least the vast majority) of transactions for an asset and will create a massive, signed Merkle tree to guarantee all valid currency at a given block height.
If a standard "light" wallet uses only Lightning Channels, it only needs to download a few MB of data to fully verify its own coins without relying on any third party. Because the authenticity of the intermediate Lightning Channel is irrelevant, the client can even construct its own route based on gossip messages (e.g., using a DoS-resistant mechanism based on scarcity evidence).
(over)
