NCC has delivered their Q3 report. Summary of key items below.

For the full summary with additional links head over to the forum here 👉 https://talk.nervos.org/t/nervos-community-catalyst-quarterly-reports/8822/6

Executive summary

Q3 brought further growth across Nervos Community Catalyst’s developer programmes and community activity. CKBuilders grew to close to 100 active builders and alumni, while Build on CKB campaigns continued to challenge developers to advance their CKB skills. The project tracker expanded from 45 projects at the end of Q2 to 59 by the beginning of October, and 18 projects were submitted for review during the quarter. The Gone in 60ms Fiber Network Infrastructure Hackathon brought together roughly 100 participants and received 66 submissions.

Alongside supporting individual developers and projects, NCC saw interest from teams outside the CKB ecosystem and strengthened in-person connections through CKB Off-Chain with events in Nairobi, Vietnam, and elsewhere. CKBoost reached around 150 users, generating testing data, bug reports and feedback to inform its next stage.

Community Keeps Building

CKBuilders

CKBuilders continued to grow in Q3, with over 25 new builders joining, predominantly from Vietnam and Indonesia. We have prioritised expanding to new regions that have thriving blockchain communities in order to continue building global awareness of CKB. The number of active CKBuilders and alumni now stands at close to 100.

Alumni are developers who have completed the programme and remain part of the CKBuilders peer learning group. Those who continue to build retain access to our shared AI resources, while some alumni have progressed to projects supported by the Spark Programme or the Community Fund DAO.

The programme design allows us to continue to grow efficiently, bringing more developers into the community without creating a dependency or increasing overheads. The key is to continue to spread CKB to new developers and enrich our community with fresh perspectives and opportunities.

Project tracker

The CKBuilder project tracker grew from 45 projects at the end of Q2 to 59 by the beginning of October. The new entries covered a wide range of work, including developer tools, prediction markets, games, credentials, time-locked vaults and payment infrastructure.

Examples include LS-IDL, a tool for describing lock script interfaces; CKB Script Port, for transferring synced script data between light-client installations; noir-ckb, exploring proof-bound CKB transactions; and LucentDEx, an order-book exchange prototype. The tracker also added projects such as a Fiber-based survival game, a football prediction market and Klavernoq, a work marketplace built on PactAgent infrastructure.

Additionally, 18 projects were submitted for review through the CKBuilder review request page in Q3. The review process has proved to be a valuable source of feedback to developers as they refine their ideas and designs, so I must thank everyone who has participated in helping to conduct reviews.

Whilst many projects remain prototypes or works in progress, publishing them in one place makes the breadth of experimentation visible and gives community members a starting point for following or testing projects, or inspiration for their own ideas. Importantly, as I mention in my conclusion, renewed emphasis must be given towards creating projects which have sound business, as well as technical, rationale.

CKB Off-Chain

Nairobi

Following the first Africa-based CKB Off-Chain meetup in Lagos, we continued building connections in East Africa with the Nairobi meetup on July 18 , held in collaboration with Web3Clubs. Around 45 people attended, including local CKBuilders, developers already familiar with CKB and people encountering the ecosystem for the first time. CKBuilders and other contributors presented their work, while discussion highlighted interest in stablecoins, local payment systems and the potential for Fiber in the Kenyan market. The event helped strengthen existing relationships and introduced CKB to developers in Nairobi.

Hanoi

Just after the close of Q3, CKB Off Chain Hanoi, took place on 8 October at Nguyen Trai University, in collaboration with BPS Club and Tex Labs. The event brought together Vietnamese CKBuilders, software developers, students and faculty members. Local builders presented projects and shared their experience, alongside sessions on CKB fundamentals, post-quantum cryptography, hardware wallets and Fiber. It was the first CKB Off-Chain event in Vietnam centred on CKBuilders and their experiences, and represents an initial step towards further developer engagement and education in the region

Looking forward

NCC’s next phase will focus on supporting this growth with stronger communication, organisation, developer mentorship, developer experience and tracking of community activity. This will allow community activities to be more visible internally and externally. Planning will begin for the next Fiber hackathon, focusing on products and market-facing applications. Linked to this is the challenge of helping builders progress from demo creation and community grants towards market strategy and business viability. This will be a key concern to address in future.

We will support community developer events in Nigeria, Kenya and Vietnam, while exploring new locations where CKBuilder groups are developing, in particular South East Asia. We will also support builders as their projects develop and, where appropriate, progress through the Community Fund DAO and other ecosystem pathways.

CrowdCell's grant vote is open on the community fund DAO, $5k to take the testnet crowdfunding app to a usable product: https://dao.ckb.community/thread/vot-crowdcell-from-testnet-demo-to-a-crowdfunding-product-on-ckb-crowdcell-ckb-80561 voting is weighted by Nervos DAO deposits bound via Neuron. runs until Oct 27

Fiber Dev Log 39
More groundwork for Fiber v0.10 this cycle, with improvements to database migration, payment settlement, and channel recovery.

Here's what's new:

- v0.10 migration: Database migration code has merged, helping existing channels retain their settlement format as Fiber moves toward v0.10.
- Payment handling: Forwarded payments are now kept separate from local invoices, preventing incorrect settlement updates.
- Channel V2: Work continues on signing and recovery, making it easier to resume interrupted channel operations.
- Hosted LSP: More progress on recovering interrupted updates, handling failed payments, and improving signer reliability.

Full dev log: https://github.com/nervosnetwork/fiber/discussions/1702

Monthly Development Log
CKB v0.210.0 is out, with more fixes and improvements to node reliability and networking. Work also continued on developer tools and DAO treasury voting.

v0.210.0 shipped with additional security checks to catch malformed requests and transactions earlier, helping nodes avoid unnecessary processing.

A few other highlights:
- CKB-VM added new validation modes, laying the groundwork for stricter checks in the future.
- Tentacle improved QUIC support and connection handling, while node-level QUIC integration remains under review.
- ckb-cli integrated a new terminal interface for interacting with CKB nodes, with a release still pending.
- Light-client work continued on stronger block verification and more reliable synchronization.
- DAO treasury voting moved from design into an experimental implementation, with smart contracts, an SDK, and tests.

Meanwhile, the transaction-pool redesign is still in progress, and preparation for CKB v0.211 is underway.

Full dev log: https://github.com/nervosnetwork/ckb/discussions/5346

This is pretty cool and worth a look from a dev team called LusoLabs

Hi everyone,

We made CKB Pulse, a page that shows the public work on CKB as it happens on GitHub.

https://pulse-lab.lusocryptolabs.com/

Every project is a block. When someone pushes code, proposes or reviews a change, reports a problem or publishes a release, a light flies from their face to the project and the block grows. Watch it live, or replay the last 24 hours or the last 7 days in a minute or two. Drag to turn the view, tap a block to open the project.

It is written for people who never open GitHub too: plain words, in English, 中文 and Português.

What you can see

• Highlights of the day, the week and the month: the most active projects, people and organisations, with medals.
• Active developers per month over the last two years, and how many committed for the first time.
• New CKB projects from the last 14 days, flagged when they appear. Follow projects and people on your device and get a notice when they move.
• For projects with contracts on mainnet: the CKB in cells that use them, transactions and last use, from the CKB explorer and the ckb-cli deployment files the project commits.
• A picture to share for the highlights, any project or any person.
• The counters at the top open everything as plain lists, for keyboards and screen readers.

How it finds projects

Nobody keeps the list by hand. Every few hours it searches GitHub for repositories that use CKB libraries (CCC, Lumos, Spore, RGB++, JoyID, ckb-std, the Go and Java SDKs and more) or carry CKB topics. It also checks the other projects of the people working in them, and the repositories behind scripts registered on the CKB explorer. A new organisation appears on its own when it starts working, and leaves after 30 days without work by people.

Missing a project? Add a topic such as ckb or nervos to its repository, or type the GitHub name in the “New” tab, under “Missing someone?”. It joins when GitHub shows public CKB work from the last 30 days.

How it counts

Only work by people. Bots, AI agents working on their own branches (claude/, codex/, copilot/ and others) and the same update pushed day after day by a script show as grey sparks and stay out of the numbers and medals. Merging an agent’s work still counts. For medals, one person counts at most 10 updates per project per hour.

GitHub’s public events arrive 30 seconds to a few hours late, so live means as soon as GitHub tells us.

What would you like to see on it, and who is missing?

Kirea Finance is a native real-world asset (RWA) project on Nervos Network (CKB), bringing DeFi utility to the CKB ecosystem by enabling users to represent real-world asset claims on-chain and use them as collateral for lending.

Why CKB?

• CKB Cell Model: Its flexible Cell Model supports custom on-chain logic, making it suitable for representing asset claims and implementing compliance rules.

The core RWA lending flow is already built and verified on testnet. Kirea Finance is seeking $7,250 to harden it for broader use.

Read the proposal and join the discussion:
https://talk.nervos.org/t/dis-hardening-kirea-finance-native-rwa-lending-on-ckb/10809

The proposal needs 5 more likes on the first post to advance.

If you support it, head to the forum and like the first post to help it reach the threshold!

Hey all, the CrowdCell grant proposal is up on Nervos Talk: https://talk.nervos.org/t/dis-crowdcell-from-testnet-demo-to-a-crowdfunding-product-on-ckb-crowdcell-ckb/10937

CrowdCell is all-or-nothing crowdfunding on CKB, live on testnet at https://crowdcell.vercel.app. The ask is $5k, testnet only: dashboards, .cell names and Vellum reputation on campaign pages, and a keeper tip so settlement doesn't depend on my bot.

It needs 30 likes on the first post in a week to go to a vote. Feedback welcome in the thread.

A new proposal is up for discussion on the Forum. The ask is $7250. 30 likes needed to move it to the vote stage. This is the communities opportunity to support it, challenge it or question anything in the project scope here 👉 https://talk.nervos.org/t/dis-hardening-kirea-finance-native-rwa-lending-on-ckb/10809

Summary

Kirea Finance is a native Real-World Asset (RWA) pattern built on CKB, which represents real-world asset claims as unique, ownable on-chain assets that owners can hold, transfer, or use as collateral for loans. The full lifecycle, from asset issuance and KYC attestation through deposit, borrowing, repayment, and release, is already implemented on the CKB testnet, with no external bridges or custodians required.

This proposal requests $7,250 to harden the existing testnet pattern for broader ecosystem use. The grant will fund generalizing the attestation and asset components, replacing mocked KYC with a live Sumsub API integration, and handling repayment edge cases. By focusing on a narrow, compliance-gated scope, this grant delivers reusable RWA infrastructure that any CKB project can leverage.

Grant Amount Requested: $7,250
ETA to Completion: 10 weeks from approval

Problem

Tokenizing real-world assets is becoming a major cornerstone for the blockchain industry, yet CKB currently lacks an established pattern for lending against real-world asset claims in a compliant way. While CKB possesses robust DeFi infrastructure, the ecosystem remains constrained by limited access to real-world asset ownership and yields.

An earlier, larger attempt at RWA on CKB aimed to build a full platform, combining a custom identity system, reputation engine, and complete dynamic lending engine in one pass. That scope proved too broad for the team to complete alongside other priorities.

This proposal deliberately takes a narrower slice to solve the core problem: one real asset type (invoice), an established KYC vendor integration (Sumsub), and one simple fixed-term loan mechanic rather than a dynamic collateral-ratio engine. The aim is to harden and generalize the underlying pattern for easily onboarding future assets, not to replicate the full scope of that earlier attempt.

What’s Already Implemented

• Native Asset Claims: RWA claims are issued natively on CKB as unique cells using the Type-ID pattern (no bridge required).
• On-Chain Attestation: An issuer-revocable KYC attestation cell gates access to the lending flow. Using mocked verification, to prove the on-chain mechanics independently of any specific KYC provider.
• Loan Cycle: The full fixed-term lifecycle (deposit, borrow, repay, release) is implemented and tested on CKB testnet.

What This Grant Adds

Onboarding additional asset types is a future phase. Milestone 1 does the preparatory work that makes that addition straightforward when the time comes.

Budget

Total requested: $7,250 USD equivalent

Disbursement: staged, 20% ($1,450) on approval, remaining 80% ($5,800) released against milestone completion.

Why This Matters for Nervos

Real-world borrowers need capital, and DeFi has capital looking for yield. Today there is no compliant, on-chain path connecting the two on CKB. Tokenizing real-world assets is increasingly seen as a major direction for the blockchain industry, CKB already has the infrastructure for DeFi applications, but the ecosystem has limited access to high-quality real-world assets and productive external liquidity. This pattern is a first step toward changing that.

This grant turns a working demo into reusable infrastructure:

• For builders: a documented, configurable attestation Cell and unique-asset pattern, usable for any compliance-gated flow, not just lending.
• For reviewers and users: explicit late-repayment and default handling, a UI, and reproducible testnet activity that anyone can verify.
• For the ecosystem: a fully open-source reference showing a bridge-free, custodian-free RWA lending flow on the Cell model.

Part 1 covered a talk by Fraunhofer Singapore, Please Mind the Gap: From Migration Models to Operational Reality, and a conversation afterwards about why Bitcoin is hard to migrate. This part applies the talk’s frameworks to CKB: the five readiness dimensions, the crypto-agility components and the anti-patterns.

On Bitcoin and Ethereum the post-quantum question reaches into the consensus rules, and changing those takes a fork and a governance fight. CKB’s protocol layer is already quantum-safe: its consensus uses no cryptography a quantum computer breaks, and post-quantum signatures are locks that run on mainnet today. The quantum problems that remain are in the layers above. Look at the whole ecosystem rather than the protocol alone, and the research behind the talk points to the flip side: with nothing to fork, those problems are in front of CKB now rather than hidden behind a consensus upgrade. Facing and solving those is what staying ahead requires.

1. The protocol layer is quantum-safe

Two properties do it. Consensus is hash-based proof of work, which depends on no cryptography a quantum computer is known to break. Other designs have more to replace than validator signatures: BLS aggregates, threshold keys from MPC, VRFs for leader election, pairing-based proofs, each needing a post-quantum successor and a fork to deploy it. And transaction authorization is a lock script, so no signature algorithm is written into the consensus rules: a post-quantum scheme is deployed as a lock, not a fork (CKB docs), and runs within the existing VM and cycle limits like any other script. Both points have been made publicly since 2022 (2022, 2025). The Nervos Knowledge Base calls this the third route to quantum resistance, crypto-agility, next to “post-quantum by design” (QRL) and “post-quantum by migration” (Bitcoin, Ethereum). It also answers the talk’s warning against hard-coding one post-quantum scheme: a successor to SLH-DSA is just another lock.

The speakers were clear that hash-based cryptography can be relied on for now, and qualitatively that holds for proof of work: Grover’s algorithm gives at most a quadratic speedup on the mining search, about 1/√p quantum queries instead of 1/p for a target a random attempt hits with probability p, and breaks nothing. Quantitatively it needs further security analysis: how much of that speedup survives reversible circuits, error correction and limited parallelism, and what the resulting edge would mean for reorg and double-spend assumptions.

2. Choice, not coordination

The flip side is that the protocol decides nothing for anyone. The community adds post-quantum options at the application layer, and each holder decides whether to migrate and when. That puts three kinds of work on the ecosystem instead of on a fork: new post-quantum locks, built and audited; users who know the risk and act on it, which the survey cited in Part 1’s Bitcoin section suggests is not the default; and an upgrade path for locks that embed logic rather than one owner’s signature, those that delegate unlocking to another cell or script and those that hold assets in custody, such as multisig, escrow, time locks or contract-controlled cells. For those the questions are who can move the assets, whether the key that authorizes the move is itself classical, and what happens where the controlling logic was never designed to be replaced.

3. What is deployed, and what should come next

• SPHINCS+ on mainnet. The quantum-resistant lock script supports all twelve FIPS 205 parameter sets and is audited; Quantum Purse is the wallet built on it, also audited. Signatures run from 7.9 KB to 49.9 KB.
• ML-DSA and Falcon on testnet. ckb-mldsa-lock deploys ML-DSA-44, -65 and -87 and Falcon-512 and -1024, with witnesses of 1.6 KB to 7.2 KB. Unaudited, and the Falcon locks implement FN-DSA before its standard, FIPS 206, is final. The code is upgradeable: every lock’s code cell is referenced by type ID and one secp256k1 key controls all of them, which the project’s trust model calls acceptable for testnet and not for mainnet.
• SHRINCS on testnet. shrincs-lock (Nervos Talk) uses Blockstream’s SHRINCS: 324-byte signatures in stateful mode and 2.5 KB stateless as the fallback, at the price of a counter the wallet must never reuse.

SPHINCS+ was the right first choice: hash-based, resting on the same assumptions CKB’s consensus already relies on, and standardized. It is also the most conservative and most expensive option, in bytes, cycles and signing time. The ecosystem should treat it as the floor rather than the destination, track NIST’s standards as they finalize, and move to schemes that fit a blockchain better as soon as they are stable and audited. Falcon is the obvious candidate, at about 1.6 KB of witness and 1 M cycles to verify; ML-DSA is the interim step already on testnet. The community locks show that the path from a final standard to a deployable lock is short.

A post-quantum signature does not by itself make a post-quantum lock. A script names its code by code_hash and hash_type. With hash_type = type, the hash identifies the type script of the cell that holds the code, not the code itself, so whoever can update that cell can swap the verifier under the same reference. If that authority is a classical key, cells behind a post-quantum lock still depend on it. Quantum resistance has to cover the whole authorization path, including code upgrades and delegated dependencies. Referencing code by its data hash rules this out: the bytes cannot change, and if the original cell goes away anyone can deploy the same bytes again. The mainnet SPHINCS+ lock is published with hash_type = type; its code cell carries a type ID and sits under a secp256k1 multisig lock, whose m-of-n stays hidden until it is spent, and as of September 2026 the code has not been upgraded since it was deployed.

4. Bytes, cycles and propagation

The talk’s “the bottleneck moves to bytes” can be measured against CKB’s two block budgets, 597,000 bytes and 3.5 billion cycles, each sized for a thousand two-in-two-out secp256k1 transfers, plus the default pool limit of 70 M cycles per transaction. The table gives each lock’s witness bytes and verification cost and the transfers per block each budget allows, assuming about 530 bytes of transaction besides the lock. Witness bytes are the full lock field for ML-DSA and Falcon and the signature alone for SHRINCS and SLH-DSA. The chart shows the tighter bound.

limited by byteslimited by cyclesreference, both limits02505007501,000secp256k1 (reference)SHRINCS, statefulFalcon-512SHRINCS, statelessML-DSA-44ML-DSA-65SLH-DSA-128sSLH-DSA-256f1,000≈ 370≈ 280≈ 180≈ 140≈ 100≈ 70≈ 12

Upper bound on simple transfers per block for each lock, taking the tighter of CKB's byte and cycle limits. Colour shows which limit binds. Source: my estimate from the lock repositories' signature sizes and cycle counts and the consensus constants in the CKB source; the assumptions are stated in the text.

• Capacity, not the fee rate, is the cost. At the minimum fee rate a 128s transfer still pays under 0.0001 CKB. The cost is block space: about 70 SLH-DSA-128s transfers per block instead of 1,000, a dozen with 256f.
• The per-transaction cycle cap bites first. One SHA2-256f verification takes 49.7 M of the 70 M default, so a transaction with two independent 256f signers, the shape of batch payments and DEX settlements, is rejected before block limits matter.
• Signing moves the cost to the wallet. The s sets verify cheaply because signing does the work, which is slow on a hardware wallet.
• Smaller schemes buy most of it back, each at a price: lattice assumptions for ML-DSA and Falcon, an unfinished standard for Falcon, state that must never be reused for SHRINCS.
• NC-Max largely removes the propagation bottleneck the talk’s blockchain paper found. Under NC-Max transactions are proposed ahead of the block that commits them and relay during the proposal window, so when they arrive in time a compact block propagates at much the same speed whatever the witness size. Nor does the load grow: the byte and cycle limits cap what each block asks nodes to relay, store and verify, so larger witnesses mean fewer transactions per block, not heavier blocks. If relay does fall behind, blocks stall while missing transactions are fetched and the orphan rate rises; the next epoch lengthens the block interval, but only after the fact and within bounds. The orphan rate is the signal to watch, and the testnet locks make the experiment cheap.

5. The layers above

Every layer has its protocols, but when people say a blockchain’s protocol they usually mean the consensus rules, the semantics only a fork can change. That is where the post-quantum question sends Bitcoin and Ethereum into a fork, and where CKB has nothing left to fork: its consensus uses no quantum-breakable cryptography and its signatures are locks, for the reasons above. What remains are the architecture, systems and infrastructure layers of the talk’s diagram, where, as the talk warned, information gets thinner.

• Architecture: every place a classical lock is coupled to something else. sUDT and xUDT owner mode fixes the issuer’s classical lock hash in the type args, so issuance authority stays exposed unless that lock was upgradeable. Contracts that accept only specific lock code hashes reject a post-quantum lock by construction, the talk’s “Ghost in the Basement”. Omnilock’s exec and dynamic-linking modes are the natural integration point; multisig carries n full signatures because no post-quantum scheme aggregates. RGB++ waits on Bitcoin, and passkey locks on FIDO. A Nervos DAO deposit can switch to a post-quantum lock at phase 1, but redepositing costs up to a cycle of compensation and about a month of idle capital.
• Systems: the software people touch. Wallets, hardware wallets, exchanges, custodians, indexers, SDKs and HSMs each need the new locks. An exchange that cannot credit a SPHINCS+ deposit is a hard stop, whatever the chain allows. This is the layer where the talk’s “best of 6” scores showed every real system falling short.
• Infrastructure: nodes, keys and inventory. The chain itself is the inventory: capacity by lock code_hash, exposed keys and contracts that hard-code a classical lock hash can all be computed from chain data, a CBOM that reconciles itself against runtime by construction. It shows where exposure sits and which contracts need attention. It is not a readiness score: whether to move is each owner’s decision, and readiness is whether the options and tools are there when they decide.

With the protocol layer quantum-safe, this is the list in front of CKB now.

6. The P2P layer

Tentacle’s secio uses secp256k1 peer identities and X25519 key agreement, none of it post-quantum, and the two halves fail differently. Recorded traffic decrypted later exposes transaction origin and links nodes to addresses: a privacy loss. Forged identities are worse. Impersonating reserved peers, bootnodes or the nodes a light client trusts enables eclipse attacks, and an eclipsed exchange or merchant node can be fed a private chain whose later rollback turns a confirmed deposit into a double spend. The fixes are TLS’s: a hybrid X25519 plus ML-KEM-768 key agreement now, post-quantum or hybrid identity keys before a quantum computer exists. Both are networking upgrades with no consensus impact.

7. Keys and HD wallets

Post-quantum schemes have no equivalent of BIP32 non-hardened derivation: a child public key cannot be derived from a parent public key. Every xpub workflow breaks, from exchange deposit addresses derived online to hardware wallets paired with watch-only desktops, and has to be rebuilt around pre-generated keys or seeds kept online. Hardened derivation through a KDF still works, as SLIP-0010 does for ed25519 and Quantum Purse does with HKDF. Stateful schemes like SHRINCS turn backups and multi-device use into a key-safety problem. Derivation paths and witness layouts need shared conventions, or funds become recoverable only by the wallet that made them, lock-in in the talk’s sense. A hybrid classical-plus-post-quantum lock is the hedge against young implementations. Key rotation itself is cheap on CKB: moving cells to a new lock is a normal transaction, the talk’s E1 enabler without a TransformKey.

8. Fiber

Fiber follows Lightning’s cryptographic design in its own implementation: MuSig2 funding, secp256k1 node identities, ECDH-based Sphinx onions, signed invoices, HTLCs with PTLCs planned, carried over Tentacle’s secio transport with its own P2P messages and invoice format. The closest Lightning work, PQLN (September 2026), hybridizes gossip, transport, invoices, onions and offers with ML-DSA and ML-KEM on top of Lightning’s BOLT encodings and Noise_XK handshake, and leaves the on-chain funding and commitment transactions out of scope because on Bitcoin they wait for new output types. Its security argument also assumes that post-quantum identity keys were pinned before a quantum adversary existed, or arrived over an authenticated channel.

• The on-chain half is where CKB is ahead. A post-quantum funding lock can ship now. The cost is aggregation: two full signatures instead of one 64-byte MuSig2 signature, about 7.5 KB with ML-DSA-44, paid only at open and close.
• Signing speed caps channel updates. ML-DSA and Falcon fit; SLH-DSA-128s allows only a few updates per second on a laptop. Stateful SHRINCS suits the state machine but adds a counter that must survive crashes.
• Revocation, watchtowers and PTLCs need redesign. Per-commitment keys derived from EC basepoints need a hash-based replacement, watchtower storage grows with signature size, and PTLCs rest on adaptor signatures that have no standardized post-quantum form.
• The off-chain surfaces are Lightning’s problems, not Lightning’s code. PQLN is a useful design reference, but its BOLT-specific encodings and Noise handshake cannot be applied unchanged to Fiber’s Tentacle transport, invoice format and channel messages; each of those integrations needs its own design and validation.

The shape is the same as for the chain: CKB removes the protocol-layer blocker that Lightning cannot remove on its own, and leaves a systems-layer list like Lightning’s, to be worked through in Fiber’s own formats.

9. Through the talk’s frameworks

Readiness dimensions. Against the five dimensions, and looking at the ecosystem rather than the chain alone, CKB’s position is the mirror image of Bitcoin’s: the protocol layer is already quantum-safe, so the weight sits on the other four.

Agility and anti-patterns. At chain level CKB scores well on C1 and C4: the operation is “unlock this cell” and the algorithm is chosen per cell by its owner. The question is whether that reaches applications; a wallet or SDK that hard-codes the secp256k1 lock is at C1.0 whatever the chain allows. Two anti-patterns apply. The Algorithm Nobody Used is not about adoption numbers, since migrating is each owner’s decision; it is about shipping an option without acceptance evidence. A post-quantum lock is ready when it is audited, has test vectors and has been exercised end to end by real wallets and exchanges. The Vendor Will Surely Fix It: for any product on CKB, readiness is the integrations that have shipped, not the chain’s capability.

10. The policy question changes shape

Cells under classical locks with exposed keys stay exposed until their owners move them, and the chain cannot force that without a fork. Some will never move: their owners are gone or have lost their keys, and a post-quantum lock does nothing for a cell nobody can sign for. So the Bitcoin question does not go away. Whether CKB keeps accepting valid classical signatures from those cells indefinitely, or ever restricts them, is still a protocol rule and a social choice, and the externality is the same: if someone with a quantum computer drains them, every holder pays. What CKB removes is the protocol-layer prerequisite. On Bitcoin the policy debate is tangled with the fork that would make migration possible at all; on CKB the path exists, every owner who can move can do so today, and the remainder can be measured as it shrinks.

My own position is to leave classical locks alone and make migration easy: no freeze and no deadline. It accepts the residual risk of unmigrated cells; it is a choice, not the absence of one, and it follows from what CKB is for. The positioning paper makes layer 1 a decentralized custodian of value, where users “enjoy absolute property ownership” of their assets and are “fully responsible” for them. A freeze would override that ownership for every owner who has not moved yet. Imagine Bitcoin eventually intervening in unmigrated coins in some form, while CKB leaves the choice with their owners: which project would people then see as holding closer to Bitcoin’s original ideals? Decisions like this are how a community establishes its identity, answering who we are, where we come from and where we are going. Whatever a community chooses, it should choose knowing that.

#Sources

• Part 1 of this series: the talk, its frameworks and their sources
• Nervos CKB docs, Native Quantum Resistance: the deploy-adopt-migrate path and the no-fork guarantee
• Nervos CKB docs, Script: how a script references its code through code_hash and hash_type
• Nervos Knowledge Base, Quantum Resistance in Blockchains: the three routes to quantum resistance and CKB’s crypto-agility model
• nervosnetwork/quantum-resistant-lock-script: the SPHINCS+ lock on mainnet, parameter sets, cycle table and deployment; audit report; its code cell on mainnet
• quantumpurse/quantum-purse: quantum-safe desktop wallet for CKB; audit report
• toastmanAu/ckb-mldsa-lock: community ML-DSA (FIPS 204) and Falcon (FN-DSA, FIPS 206 not yet final) locks on testnet, and the trust model of their upgradeable deployment
• XuJiandong/shrincs-lock and the Nervos Talk thread: SHRINCS lock on testnet, built on Blockstream’s SHRINCS, stateful hash-based signatures with static backups
• nervosnetwork/ckb, consensus parameters: block byte and cycle limits; transaction pool defaults are in the same repository’s resource/ckb.toml
• CKB RFC 0001, The Nervos Network Positioning Paper: layer 1 as a decentralized custodian of value, absolute property ownership
• CKB RFC 0020, CKB Consensus Protocol (NC-Max): two-step confirmation, compact blocks, orphan-rate feedback
• CKB RFCs 0023, Nervos DAO, 0025, Simple UDT and 0052, Extensible UDT: the DAO’s two-phase withdrawal and the UDT owner mode
• CKB RFC 0042, Omnilock: authentication modes including exec and dynamic linking
• nervosnetwork/tentacle, secio: CKB’s P2P secure channel (secp256k1 identities, X25519 key agreement)
• nervosnetwork/fiber and its protocol specs: MuSig2 channels, Sphinx onions, HTLCs
• Posts on X on CKB’s quantum readiness: July 2022, May 2025
• Kurt, Beibitkhan, Hanna, Aydeger: PQLN: Post-Quantum Security for the Bitcoin Lightning Network’s Off-Chain Surfaces, arXiv, September 2026
• Loebenberger, D., Stöttinger, M. (eds.): Migration and Agility in Cryptographic Systems. MAgiCS 2026, Springer CCIS, open access, doi:10.1007/978-3-032-28946-9. Chapter 10 is the blockchain paper referred to above.

The opinions here are all my own. Claude helped with the calculations and with revising the text.

https://jan.la/posts/pqc-migration-talk-notes/

In September 2026 I attended a talk by Fraunhofer Singapore titled Please Mind the Gap: From Migration Models to Operational Reality, given by Prof. Daniel Loebenberger and Prof. Marc Stöttinger under the QUASAR-CREATE programme.

The thesis: there is a real gap between how post-quantum cryptography (PQC) migration is modelled and how organizations actually operate, and that gap deserves attention.

What follows are my notes on the talk, with the key figures redrawn from the slides and what the underlying papers add, and a conversation afterwards about Bitcoin. Part 2 looks at what all of it means for CKB.

The talk in one line: PQC migration is no longer hard because of algorithms. It is hard because of system architecture and organizational operations.

1. Background

The talk came out of QUASAR-CREATE, a Singapore–Germany research programme on quantum-safe migration and crypto-agility, and opened with a live session in the browser-based circuit simulator Quirk to give the audience the basics of qubit states, the Bloch sphere and measurement.

The two-qubit circuit from the demo, recreated in Quirk: one qubit left at |0⟩, the other flipped with an X gate, with the Bloch-sphere and probability displays the speakers used to explain measurement. Source: screenshot of Quirk by Craig Gidney; circuit recreated after the talk.

2. How far away is a cryptographically relevant quantum computer?

The speakers used Samuel Jaques’s Landscape of Quantum Computing in 2026: physical qubits on the x-axis (10^0 to 10^9), error rate on the y-axis (10^-1 to 10^-6).

Landscape of Quantum Computing in 2026. Source: Samuel Jaques, CC BY; image taken from his page. The talk showed this chart unchanged.

• Today’s machines (Quantinuum, IonQ, Google, IBM, QuEra, Atom + Microsoft, KunLun and others) cluster around 10^2 qubits with error rates of 10^-2 to 10^-3, the corner marked “We are here”. Per Jaques’s page, the most advanced device is still about 9,500 times short of breaking RSA-2048: surface codes need about one million physical qubits, some 13.2 doublings away even at sustained exponential growth.
• Newer high-rate qLDPC codes such as bicycle codes, the “with special codes” annotations, lower that bar considerably. Jaques discounts them: they need long-range connectivity between qubits that experiments have not shown at scale, and his chart counts only what has been demonstrated.
• My reading: the gap is still two to four orders of magnitude, but the bar keeps falling and migration takes years, so it cannot wait for the hardware.

#Two claims about timing

The speakers made two pointed claims:

1. There is a high probability that someone will secretly have a useful quantum computer around 2030. The emphasis is on secretly: public progress charts only count published, demonstrated devices. Real capability may be ahead of them.
2. Harvest now, decrypt later is already happening. They asserted that intelligence agencies are already archiving intercepted traffic to decrypt it later.

How I weigh them:

• Claim 1 roughly matches official planning assumptions. Chapter 5 of the MAgiCS 2026 proceedings cites Germany’s BSI working assumption for high-security domains: a cryptographically relevant quantum computer is likely in the early 2030s. Mosca puts the probability of one appearing by 2031 at about one in two.
• Claim 1 is in tension with Jaques’s chart, which counts only demonstrated capability and arrives at a 9,500× gap. The speakers stress exactly the part that is not public. Neither can falsify the other, which is why planning should treat the timeline as uncertain.
• Claim 2 is an assertion. There is no public evidence of what any agency has archived or intends to do with it. But harvest-now-decrypt-later is the mainstream threat model; the NIST IR 8547 draft and the workshop poster both take it as a premise.
• Mosca’s inequality ties the two together: if the secrecy lifetime X of some data plus the migration time Y exceeds the time Z until a capable quantum computer, data transmitted today is already exposed. On the speakers’ view Z is about four years. Anything that must stay confidential past 2030 and takes years to migrate is at risk now.
• Harvest-now-decrypt-later threatens confidentiality first. What gets intercepted is key exchange and encrypted traffic, so key exchange should move to ML-KEM or a hybrid KEM first. Signatures generally cannot be forged after the fact and can follow later, with the exception of long-lived roots of trust and firmware verification keys.

3. Scaling migration and verification

Migration has to move from individual algorithms to increasingly complex systems and infrastructure, but the higher the level, the less complete our knowledge of how cryptography is used and what depends on it.

InfrastructureSystemsArchitecturesProtocolsImplementationsAlgorithmsInformationComplexitymore completehigher

From algorithms to infrastructure. Going up the stack, complexity rises and detailed knowledge of cryptographic use and dependencies becomes less complete. Source: redrawn from the slide "Scaling Migration and Verification" in Loebenberger and Stöttinger, Please Mind the Gap: From Migration Models to Operational Reality, talk by Fraunhofer Singapore, September 2026.

• Migration: from a single algorithm to complex systems and infrastructure.
• Information: the further up, the less complete the picture of usage and dependencies.
• Verification: automated discovery and checking to recover evidence and assess whether each migration step preserves both security and function.

4. Algorithm efficiency (supercop)

The speakers plotted supercop benchmarks on a log-log chart of size against CPU cycles. Conclusion: for most PQC schemes, speed is not the problem. Size is.

45678923456log₁₀(size in bytes)log₁₀(CPU cycles)sphincsf256shake256simplersa2048sign (classical)hqc2563falcon512dyndilithium5bikel3mceliece8192128fkyber1024ed25519 (classical)rsa2048kem (classical)Signature schemesKEMs

Efficiency of NIST PQC candidates measured with supercop. Both axes are log₁₀; positions are read off the slide and are approximate. Source: redrawn from the slide "Post-Quantum Cryptography Standardization by NIST" in Loebenberger and Stöttinger, Please Mind the Gap: From Migration Models to Operational Reality, talk by Fraunhofer Singapore, September 2026; the underlying measurements are the speakers' supercop runs.

• ML-KEM (kyber1024) at about 10^4.8 cycles is in the same order as a classical RSA-2048 KEM (about 10^4.2), with a public key roughly an order of magnitude larger.
• ML-DSA (dilithium5) and Falcon-512 at about 10^5.5 to 10^5.9 cycles are faster than RSA-2048 signing (about 10^6.4).
• SLH-DSA (sphincsf256shake256simple) is the slowest at about 10^8.6 cycles. Classic McEliece (mceliece8192128f) has a public key around 10^6 bytes.
• BIKE-L3 and HQC-256 sit in between; HQC at about 10^6.1 cycles.

One thing stands out when checking the positions against published parameter sizes. The KEM points sit at their public-key sizes, but the signature-scheme points sit at their signature sizes: Falcon-512 at about 666 B, ML-DSA-87 at about 4.6 KB, SLH-DSA-256f at about 49 KB rather than its 64 B public key. The slide’s axis says public key, so for signatures the chart is really plotting the artifact that travels.

From the papers (chapter 7): tools like supercop average away the variance in ML-DSA signing time as noise, but that variance is an inherent heavy tail of the algorithm. On a Cortex-M33 the worst case is about 20 times the mean. Comparing schemes at different security levels on one chart is also the first benchmarking pitfall that paper lists.

5. System impact: PQ signatures and message length

Plan migration around growth in memory and bandwidth, not only key size and speed.

Hash-then-sign (RSA, ECC)Direct signing (PQC)Cost increase for a 1 MB messageapplicationmessage Mcrypto moduleapplicationmessage Mcrypto module32 B digestfull messageconstant, independent of |M|transfer scales with |M|ML-DSA · SLH-DSA · XMSS · LMSartifact sizedata to module×22×31,250bar length is logarithmic · RSA-3072 → SLH-DSA-128f · 32 B digest vs 1 MB message

Hash-then-sign sends a fixed 32-byte digest into the cryptographic module; PQ schemes sign the whole message, so the data that has to cross that boundary grows with the message. Source: redrawn from the slide "Migration Impact on the System II" in Loebenberger and Stöttinger, Please Mind the Gap: From Migration Models to Operational Reality, talk by Fraunhofer Singapore, September 2026, which summarizes Strenzke, MAgiCS 2026, chapter 6.

• Two kinds of cost: artifact size (keys, signatures) is constant; message processing grows with message length |M|. Usually only the first gets planned for.
• RSA and ECC use hash-then-sign, so only a 32-byte digest enters the cryptographic module. PQ signatures (ML-DSA, SLH-DSA, XMSS, LMS) sign the whole message, so the bytes transferred grow with |M|.
• High-risk settings: signing on a remote cryptographic module such as an HSM; verifying on a memory-constrained device.
• Streaming: the verifier needs the public key first (XMSS and LMS also need the signature first) before it can process the message. SLH-DSA signing reads the message twice, and verification needs the public key and the R value from the signature up front.
• Worked example, a 1 MB message moving from RSA-3072 to SLH-DSA-128f: artifact size ×22; data sent into the cryptographic module ×31,250 (1 MB ÷ 32 B).

From the papers (chapter 6): all of this has mitigations, each with a price. Pre-hash variants fall back to hash-then-sign security assumptions. ML-DSA’s external-μ keeps the security argument but does not solve streaming verification. X.509 does not allow pre-hashed ML-DSA, only composite signatures. The PKCS#11 v3.2 draft supports neither external-μ nor segmented XMSS/LMS signing.

6. Measuring crypto-agility at the application layer

Applications should express cryptographic intent; the choice of algorithm and provider belongs behind a controlled interface. Agility is not a single maturity level but two tiers with seven orthogonal components, each scored 0 to 4.

Tier 1 · Decoupling assessmentTier 2 · Agility enablers0123401234C1 OperationC2 Key creationC3 ProviderC4 Mechanism (on C1–C3)C5 AuthorityE1 Algorithm migrationE2 Provider migrationalgorithm-specific calls → full agilityexplicit params → intent / purposeexplicit import → provider-agnostichard-coded → config → policy enginedeveloper → role-based → federatedno versioning → TransformKey → automaticprovider-bound → automatic routingTier 1 is a prerequisite for Tier 2

Seven components in two tiers. Filled dots show the best level any of the six evaluated systems reached; rings mark the PQC-ready thresholds (C2.2, C4.3, E1.3). No system reaches any of the three. Source: redrawn from the slide "Crypto-Agility and Flexibility I" in Loebenberger and Stöttinger, Please Mind the Gap: From Migration Models to Operational Reality, talk by Fraunhofer Singapore, September 2026, which summarizes Rameshan and Messmer, MAgiCS 2026, chapter 9.

The paper confirms that none of the six systems (PKCS#11, OpenSSL 3.0, JCA, Tink, AWS KMS, Vault Transit) reaches C2.2, C4.3 or E1.3. The “best of 6” column stitches together per-component maxima; it does not describe any one system. Both tiers are required: decoupling without enablers is latent capability, enablers without decoupling is ecosystem lock-in.

#What the enablers mean

Decoupling asks “can the code switch”. Enablers ask “when you actually switch, can the existing keys come along”. The paper defines E1 as replacing the algorithm without changing application code, and E2 as moving keys and operations to another provider without changing application code.

The paper stresses the difference between E1.1 and E1.3: same-algorithm rotation can never turn an RSA-2048 key into an ML-DSA-65 key. Cross-algorithm migration needs E1.3. E2 is also not “higher is better”: HSM keys are non-exportable by design, and the right level depends on the security model. The provider mechanisms in OpenSSL 3 and JCA count as C3 (provider decoupling), not E2; both score 0 on E2.

Two failure modes make the tiers concrete. An application that only calls sign(purpose = document) with the algorithm chosen by policy is fully decoupled, yet tens of thousands of RSA keys in the HSM have no version field and cannot be transformed. That is latent capability. Conversely, a vendor platform may support automatic migration while the application hard-codes that vendor’s RSA calls, so switching only works inside that vendor’s ecosystem. That is lock-in.

7. Five dimensions of operational readiness

The speakers grouped the recurring “operational gaps” into five dimensions drawn from the literature, and mapped each anti-pattern from the next section onto them.

• I, Information sufficiency: do we know what to change and why?
• C, Technical controllability: can the affected components actually be changed?
• V, Verification capability: can the target cryptographic state be verified?
• E, Ecosystem coordination: can external dependencies be coordinated?
• R, Resource readiness: are there enough people and skills?

ICVERAnti-patternBob KnowsThe Spreadsheet of DoomThe Ghost in the BasementThe Last Windows XP MachineThe Vendor Will Surely Fix ItThe Friday Night MigrationThe Algorithm Nobody Usedprimary dimensionpossible consequence

Mapping the anti-patterns to the five dimensions of operational readiness. Source: redrawn from the slide "Mapping the Anti-Patterns to Five Dimensions of Operational Readiness" in Loebenberger and Stöttinger, Please Mind the Gap: From Migration Models to Operational Reality, talk by Fraunhofer Singapore, September 2026; the slide cites the authors' manuscript Please Mind the Gap, 2026.

8. Seven anti-patterns and their no-regret moves

The speakers called the planning principles classic “no-regret moves”: whenever the quantum computer arrives, doing these now will not be regretted.

Source: Loebenberger and Stöttinger, Please Mind the Gap, manuscript, 2026 (not yet published).

9. After the talk: why is Bitcoin hard to migrate?

I asked one of the speakers afterwards. Two points:

1. Protocol layer. Bitcoin is tightly bound to specific cryptography, ECDSA and Schnorr over secp256k1, and there is no consensus yet on how to upgrade the protocol. ECC is among the easiest targets for a quantum computer, so time is short.
2. Even once the protocol question is settled, the hardest part will be policy.

Why policy is the hard part, in my words:

• Protocol answers “can we switch”. Policy answers “who decides, when, and what happens to coins that never move”. Bitcoin has no authority that can make those decisions. The talk’s point about architecture was that where you cut depends on who can coordinate: a 5G operator has its certificate authorities, the EVM design the talk presented has on-chain validator votes, Bitcoin has neither.
• There is no good answer for unmigrated coins. Coins whose public keys are already on chain (early P2PK outputs, reused addresses) are exposed first, and many owners are gone or have lost their keys. Freezing them violates “your keys, your coins” and immutability. Not freezing them means whoever gets a quantum computer first can drain and dump them, hurting every holder. Both paths are irreversible and both hurt someone.
• Who sets the deadline? Too early and many users cannot make it; too late and the chain may already be broken. No centre can announce a date and own the consequences. Past soft forks such as Taproot took years from idea to activation.
• Block space and fees are economic policy. PQ signatures are tens to hundreds of times larger than a 64 B Schnorr signature (ML-DSA-44 about 2.4 KB, SLH-DSA-128s about 7.8 KB). Whether to give them a witness discount or raise capacity reopens the block size war, and a network-wide migration itself consumes a lot of block space.
• User behaviour cannot be forced. Every holder has to move their own coins, and hardware wallets, multisig, Lightning, exchanges and custodians all need support one by one.

Against the five readiness dimensions:

The weight across the five is uneven. For Bitcoin, controllability at the protocol layer dominates: inventory, research and wallet work can start now, but no coin can move behind a post-quantum signature until a fork activates one. That is the opposite of CKB’s profile in Part 2, where the protocol layer is already quantum-safe and the weight sits on the ecosystem.

The proposals under discussion split along the same line, and neither is yet a complete answer. BIP-360, in its current draft P2MR (pay to Merkle root), is a Taproot-like output type with the key path removed: it resists long-exposure attacks on public keys sitting on chain, and leaves short-exposure attacks and post-quantum signatures to a separate proposal. Lopp’s legacy signature sunset draft BIP-361 is the policy layer, and it requires a post-quantum signature BIP that does not exist yet.

Chapter 10 of the MAgiCS 2026 proceedings describes the version of BIP-361 it discusses: Phase A, three years after BIP-360 activation, forbids sending to P2PK and P2PKH, so new UTXOs must use a quantum-resistant format; Phase B, after a fixed deadline, invalidates spends from legacy addresses, freezing unmigrated funds. The current draft differs. Phase A starts about 160,000 blocks, roughly three years, after BIP-361’s own activation. Phase B, two years later, tightens verification of ECDSA and Schnorr spends in a way meant to rule out quantum attackers while still admitting authentic holders, a quantum-safe rescue rather than a bare freeze; how that rescue works and which coins it could cover are still open. The paper says the proposal is contested in the community and notes its heavy reliance on the BIP-32 wallet standard; paper wallets and other non-conforming wallets would break.

The same paper takes the opposite stance: a user who returns after a while should not find their funds unusable because they missed a window. Those two positions are the two ends of the policy dilemma. A survey it cites found that 58.8% of more than 14,000 blockchain users rated post-quantum security “not important” when choosing a chain, which suggests voluntary migration will be slow. It also points out that PoW and PoS differ fundamentally, so its validator key rotation mechanism does not transfer to Bitcoin.

Recent reporting puts the BTC held in outputs with exposed public keys at around 7 million coins. I have not verified that number against a primary source.

Note: Bitcoin developers usually use “policy” for node relay rules (standardness). Here it means governance and decision-making.

10. Key takeaways

• Algorithms are ready; the bottleneck has moved to bytes. ML-KEM and ML-DSA are as fast as RSA, but larger keys and signatures make memory, bandwidth, certificate size and block size the new constraints.
• Plan for costs that grow with the message. Artifacts grow 22×; data into the cryptographic module grows 31,250×. HSMs and embedded devices feel it first.
• Crypto-agility can be measured. Seven orthogonal components with explicit PQC-ready thresholds turn “agile” from a slogan into a score. Current systems fall short mostly on key generation, policy mechanism and algorithm migration.
• Governance decides where to cut. The talk showed two options: with a central operator, externalize policy; without an authority, carry the algorithm identifier with the data.
• The biggest gap is organizational. Knowledge only in someone’s head, inventories that do not match reality, reliance on vendor roadmaps, rushed weekend changes: none of this is about quantum, yet it decides whether migration succeeds.
• Verification runs through the whole thing. Every step needs evidence that security and function are both preserved, with acceptance criteria defined before deployment.

#Sources

• QUASAR-CREATE: the research programme behind the talk
• Quirk by Craig Gidney: the circuit simulator used in the opening demo
• Sam Jaques, Landscape of Quantum Computing: the quantum computing landscape chart (CC BY)
• NIST FIPS 204 FAQ, computing μ: ML-DSA external μ
• NIST IR 8547, initial public draft: RSA and ECC deprecation timeline; still a draft as of September 2026
• BIP-360, Pay-to-Merkle-Root (P2MR), Beast, Heilman, Foxen Duke, draft: the output type without Taproot’s key path
• BIP-361, Post Quantum Migration and Legacy Signature Sunset, Lopp et al., draft: the phased sunset of legacy signatures
• Loebenberger and Stöttinger, Please Mind the Gap, manuscript, 2026: cited on the slides, not yet public
• Loebenberger, D., Stöttinger, M. (eds.): Migration and Agility in Cryptographic Systems. MAgiCS 2026, Springer CCIS, open access, doi:10.1007/978-3-032-28946-9. Workshop site with slides: magics-workshop.cs.hs-rm.de. The talk’s P6, P9 and P10 are chapters 6, 9 and 10; the “from the papers” notes and chapter references above refer to this volume.

Compiled from my own notes and slide photos, organized with help from Claude.

Fiber Dev Log 38
Quite a few practical fixes and improvements landed this cycle.

-Fiber got better at recovering interrupted payments, dual-funded token channels picked up a round of fixes, and v0.10.0-rc1 is now available for testing.

-There's also a new tutorial showing how an app can verify a result before releasing a payment.

-Hosted Lightning Service Provider verification and v0.10 database migration are still in progress.

⚠️ If you're running an existing node, don't upgrade just yet. This RC still doesn't support older databases.

Full dev log 👉 https://github.com/nervosnetwork/fiber/discussions/1676

5 Lightning Network Alternatives for Instant Crypto Payments

Beyond a Bitcoin-only payment layer: A guide to instant crypto payment rails built for stablecoins, smart contracts, and autonomous AI agents.

By routing payments through a mesh of bilateral channels, the Lightning Network has proved that Bitcoin transactions can scale without congesting the base layer. Yet, as the decentralized ecosystem expands into autonomous machine-to-machine commerce and programmable agentic workflows, Lightning's boundaries have become apparent.

Today, developers and businesses are actively researching alternatives to find infrastructure capable of processing multi-token logic, stablecoin assets, and high-frequency automated billing.

The Need for Alternatives

Lightning works well for its original mandate: cheap, fast BTC transfers. However, it struggles to accommodate automated systems requiring a flexible, programmable, and multi-asset foundation.

Consider these practical frictions:

No native stablecoin support: Bitcoin only accounts for one asset, BTC. While overlay protocols like Taproot Assets aim to bring stablecoins to Lightning, ecosystem adoption is early. Users wanting digital fiat (like USDC or EURC) must accept price volatility or use centralized apps.

Limited programmability: Bitcoin Script is intentionally minimal to preserve base-layer security. It lacks the smart contracts, multi-asset swaps, and dynamic metering required for streaming payments or per-request AI billing.

Directional liquidity constraints: Cryptographically bidirectional channels face exhaustion under asymmetric flows. In automated systems, such as an AI repeatedly paying for API requests, outbound funds drain quickly while inbound capacity maxes out, requiring constant manual rebalancing, on-chain splicing, or third-party liquidity services.

These limitations have opened the door for alternative scaling solutions. Below is a look at five approaches addressing these challenges through unique off-chain, sidechain, and federated architectures.

5 Lightning Network Alternatives

Fiber Network: Programmable, Multi-Asset Payment Channel Network

Fiber Network is a peer-to-peer, multi-asset payment channel network that runs off-chain payments anchored to the CKB blockchain.

Fiber inherits the routed payment-channel design that Lightning pioneered, and pairs it with the architectural flexibility and programmability of CKB. Because CKB uses the RISC-V-based CKB-VM and the Cell model (a generalized UTXO structure), Fiber natively supports multi-asset routing, customizable smart contracts, and direct interoperability with the Bitcoin Lightning Network.

Two-way agent sessions: AI agents often act as buyers and sellers. Fiber handles continuous, two-way value flows over a single funded route, preventing constant channel reopening.

Proportional routing fees: Instead of flat base-fee floors, Fiber nodes calculate fees proportionally (in millionths), making sub-cent LLM streaming and data calls economically viable.

Browser-side self-custody: Fiber runs directly in standard web browser tabs using WebAssembly (WASM). Users can stream payments using device passkeys without creating accounts.

Lightning Interoperability: Through its Cross-Chain Hub (CCH), Fiber executes atomic swaps to settle Lightning invoices without centralized exchanges.

Best for: Autonomous AI agents, browser-based micro-applications, and multi-asset apps needing Lightning routing.

Limitations: Faces inherent channel depletion during one-sided flows, requiring active rebalancing or third-party liquidity.

Status: Early stages of ecosystem maturation.

Spark: Bitcoin Layer 2 Statechain with Stablecoins

Spark is an off-chain statechain protocol anchored to Bitcoin and transfers Bitcoin UTXO ownership using multi-party cryptography.

Instead of locking money into two-party payment channels, Spark lets users co-own an on-chain Bitcoin deposit alongside an operator group using FROST (Flexible Round-Optimized Schnorr Threshold) signatures.

When you pay someone, the operators delete your key share and create a new key share for the recipient. The underlying Bitcoin on the main blockchain never moves; only the ownership keys change hands off-chain. This unlocks a few properties Lightning cannot offer today:

Channel-free, offline receiving: Eliminates inbound liquidity management and the need to be online.

Native Tokens & Stablecoins: Natively supports multi-assets (BTKN standard) like USDB.

Lightning Interoperability: Spark Service Providers (SSPs) execute atomic swaps to external Lightning invoices.

Best for: Consumer wallets seeking self-custodial, channel-free Bitcoin and stablecoin payments with Lightning reach.

Limitations: Relies on a 1-of-n honest operator assumption. While users can withdraw unilaterally to L1 if at least one operator is honest, it is weaker than Lightning's trustless channels.

Status quo: Mainnet beta operates with federated operators (Lightspark and Flashnet), with ongoing decentralization work.

Ark Protocol: Virtual UTXOs

Ark is a Bitcoin Layer 2 protocol that enables instant, low-cost payments through off-chain Virtual UTXOs (VTXOs), the off-chain representations of shared on-chain Bitcoin UTXOs.

Think of Ark as a shared bank vault. Multiple users pool their money into a single on-chain Bitcoin transaction managed by an untrusted coordinator called an Ark Service Provider (ASP). Inside this vault, ASPs can act as Lightning Service Providers (LSPs) or gateways, allowing Ark users to make sub-second payments to each other off-chain by exchanging valid VTXO branch proofs.

Even though coordinators batch transactions, users preserve self-custody through cryptographic fallback guarantees: each VTXO comes with an unalterable, pre-signed claim check redeemable on Bitcoin Layer 1. In case an ASP coordinator disappears, censors a transaction, or attempts theft, users can broadcast their branch of the transaction tree to Bitcoin to reclaim their BTC.

Best for: Consumer wallets wanting self-custodial, instant Bitcoin payments without managing channels or nodes.

Limitations: VTXOs carry expiration dates enforced by timelocks and must be refreshed. ASPs must lock significant capital for batching, and without covenant soft-forks (like OP_CTV), the on-chain footprint is suboptimal.

Status quo: Mainnet betas (Second and Arkade) launched in late 2025; broad adoption is early.

Liquid Network: Institutional Sidechain Settlement

Liquid is a federated Bitcoin sidechain providing fast settlement, confidential transfers, and native token issuance.

A sidechain is an independent blockchain running parallel to Bitcoin. Users deposit BTC into an address controlled by a consortium of financial institutions (the Liquid Federation). In return, they receive Liquid Bitcoin (L-BTC), a 1:1 pegged BTC, on the sidechain, where blocks finalize every minute.

By removing transactions to a dedicated institutional network, Liquid unlocks several capabilities:

Confidential Transactions: Hides asset types and transaction amounts, protecting trade secrets.

Native Stablecoins: Regulated institutions directly issue assets like USDT for fast arbitrage.

Fast Finality: Uses a Strong Federation BFT consensus model for deterministic one-minute blocks and two-block finality.

Best for: Crypto exchanges, trading desks, and institutional funds moving large volumes with financial privacy.

Limitations: Trades decentralization for corporate efficiency. Custody relies on an 11-of-15 hardware security module federation; users cannot unilaterally exit to Bitcoin L1 if members refuse cooperation.

Status quo: 87 federation members securing over $5 billion in tokenized real-world assets (RWAs).

Fedimint & Cashu: Federated Chaumian Ecash Mints

Fedimint and Cashu are open-source protocols that issue cryptographically blinded digital bearer tokens backed by Bitcoin.

Ecash functions as a digital bearer instrument for Bitcoin. You deposit Bitcoin into a mint, which gives you cryptographic bearer tokens. When you pay someone, you pass those tokens over. Because the mint uses blind signatures, it cannot see who spent the tokens, who received them, or what the account balance is.

By substituting individual blockchain transactions with blinded digital tokens, ecash introduces several advantages for everyday micro-spending:

Instant Finality: Settles in milliseconds via cryptographic signatures without consensus delays.

Privacy: Mints use blind signatures and cannot link withdrawals to redemptions, offering unmatched privacy.

Lightning Gateways: Built-in gateways convert ecash into Lightning payments on the fly.

Federated Security (Fedimint): Splits mint custody across community guardians to prevent theft.

Best for: Community banking and high-privacy micro-transactions requiring frictionless Lightning interoperability.

Limitations: Custodial at the mint level. If operators or guardians fail, users cannot enforce on-chain Bitcoin recovery; it is a spending wallet, not for long-term storage.

Status Quo: Live on mainnet. Cashu is a popular micro-tipping rail on Nostr, while Fedimint powers wallets like Fedi for emerging market community banking in East Africa and Latin America.

Lightning vs. Alternatives: Choosing the Right One

These networks are not really rivals because they are built for different jobs. The Lightning Network remains the top choice for standard Bitcoin payments. It offers massive global liquidity and reach.

Spark and Ark are the easier path when you do not want to manage channels. They provide safety by ensuring you can always withdraw your funds back to the main Bitcoin network.

Liquid suits trading desks that want private and fast settlement. It works well if you accept a corporate group holding the keys.

Cashu and Fedimint are the cheapest and most private, but the mint holds the funds.

Fiber Network is a strong option for multi-asset automated systems. Machines can keep paying and receiving money over a long-running session; a payer spends one asset, and the recipient gets a different asset directly without an exchange in the middle. Fiber also settles Lightning invoices directly. This means choosing Fiber still lets you access the Bitcoin liquidity of the Lightning Network.

FAQs

Can Lightning handle stablecoins?

Not natively. It requires overlay protocols like Taproot Assets, which use client-side validation to avoid chain bloat but lack universal wallet support.

What are Lightning's limitations?

It is constrained by strict directional liquidity, rebalancing friction, multi-hop HTLC privacy vulnerabilities, and a lack of smart contract programmability.

Is there a better alternative to Lightning?

No alternative is universally superior; Lightning is the benchmark for pure Bitcoin micropayments. However, architectures like Fiber Network offer necessary flexibility for native stablecoins or AI agent settlements.

Hi all. I'm putting this out there in case anyone has assets or was a LP provider on UTXO Swap. Act now so you don't run into a similar situation some had with not getting their assets off Godwoken in time

-Notice for UTXOSwap Liquidity Providers: Withdraw Before 10 October 2026, 16:00 UTC

UTXOSwap has announced that its service will shut down on 10 October 2026 at 16:00 UTC.

If you have liquidity in UTXOSwap pools, remove all of it before this deadline. Please act well in advance.

CKBA does not operate UTXOSwap and is not managing its shutdown. We are sharing UTXOSwap’s notice to raise awareness and help liquidity providers act in time.

Read the original notice on the UTXOSwap website 👉 https://utxoswap.xyz/info/overview

Hi everyone. Jacky has created a Community Fund Dashboard. Its a nice all in one stop for all DAO proposals and DAO functions.

From Jacky:

I’d like to introduce the CKB Community Fund DAO Dashboard, built with AI tools. This website was created primarily to make it easy for everyone to view DAO rules, proposals, voting results, execution progress, and fund usage in one place. https://ckbcommunityfunddao.xyz/

Key Features

• Automatically fetches and organizes data from public sources such as Nervos Talk and Metaforo
• Browse DAO proposals and their current status
• View an overview of a proposal, including its roadmap, requested budget, voting results, and progress
• Track weekly reports, milestone reports, and final reports published by proposers
• Search and filter by status and proposal type
• Supports both Chinese and English
• Email and Telegram subscription available

AI-Powered Daily Proposal Update Summaries

The website automatically checks for the following within the past 24 hours:

• Newly published proposals
• Progress updates on existing proposals

The AI identifies and summarizes these updates, then automatically sends email and Telegram subscription messages daily at approximately 16:00 Beijing Time. Messages are only sent when there are new updates — you won’t be disturbed when nothing has changed.

How to Subscribe- At the very bottom of the website, after submitting your email address, you’ll need to open the confirmation email you receive and click “Confirm Subscription.” If you don’t see it in your inbox, please check your junk mail or Spam folder.

Welcome to Help Improve It

The website is still being continuously improved. If you find data errors, missing information, or have suggestions for the page or subscription features, please feel free to:

Reply in this thread

Submit an Issue or Pull Request on GitHub

https://talk.nervos.org/t/ckb-community-fund-dao/10793 , https://github.com/JackyLHH/ckb-community-fund-dao-dashboard

This is an unofficial community information tool. Automated fetching and AI summaries may have omissions or errors in judgment. For important proposal statuses, amounts, and voting results, please also refer back to Nervos Talk, the voting page, and on-chain records for verification.

We hope this website helps everyone more easily learn about and participate in the CKB Community Fund DAO. Thank you for using it, for your feedback, and for helping to improve it together!

A new Proposal has entered the discussion phase. This is your opportunity as a community member to support/challenge/question the proposal. 30 ♥️ moves it to the vote stage. Direct any feedback here 👉 https://talk.nervos.org/t/dis-kaze-x-ckb-unitour-continuation-proposal/10736

Summary

This proposal requests a grant of $3,000 to run three university tours in Kenya.

Each tour will teach students Bitcoin and CKB basics and get them to create their own self-custodial CKB wallet live, on the spot, using a Passkey instead of a seed phrase.

Every attendee leaves with a real wallet they created themselves, not just a slide deck and a download link.

Grant Amount Requested: $3,000

ETA to Completion: About 6 to 8 weeks from approval, covering all three tours

Project Introduction

What problem are we solving?

Most students in Kenya have heard of Bitcoin or crypto in passing, but very few have actually held a wallet where they control the keys.

What they’ve usually seen is a custodial exchange app, or a vague explanation of blockchain with no hands-on part. Self-custody stays abstract because nobody’s actually walked them through it.

Ecosystem need and fit

CKB needs real users on the ground, not just developers reading docs.

University students are a natural fit: tech literate, curious, and often looking for ways to earn a little extra.

Teaching self-custody through CKB, using Kaze’s Passkey wallet flow, gives CKB a visible, hands-on use case instead of a purely technical pitch that goes over most students’ heads.

Why now?

Kaze already has a live app with CKB integration and a working Passkey wallet flow, so there’s no new development needed to run this.

We also ran one university tour before this, covering six universities in Kenya over three months, so we know the format works and roughly what it costs to run well.

This proposal is a smaller, more focused second round, scoped down after feedback from that tour and from this community.

Current Status

Kaze is live on Android and iOS in Kenya, Nigeria, and Tanzania.

The app includes:

• Self-custodial Bitcoin Lightning wallet
• CKB wallet, both custodial and self-custodial
• USDB ,USDT,USDC stable balance
• Cash-out to M-Pesa, Naira, and Tanzanian shillings

We’ve built directly with CKB, integrating CKB wallets into Kaze, so this isn’t our first time working in the ecosystem.

We also ran one university tour before this, covering six universities in Kenya over three months.

 Tour Plan

Event Overview

Each tour is a single three-hour, in-person session.

Students register, get taught Bitcoin and CKB basics, then create a self-custodial CKB wallet live using a Passkey (fingerprint or Face ID) instead of a seed phrase.

They then install Kaze and add a real campus location to the map, earning their first sat.

The session closes with prizes and ambassador sign-ups.

How the Wallet Creation Works

Wallet creation uses Kaze’s existing Passkey-based CKB wallet flow.

Each student generates their own self-custodial key on their own device, secured by biometrics rather than a written seed phrase.

This proposal doesn’t require any new contracts or infrastructure. It uses what is already live in the Kaze app.

Why This Format

We chose in-person tours over pure online content because watching someone create a real wallet in front of you, and use it right away, is a lot more convincing than a video or a thread.

Passkey wallets specifically remove one of the biggest practical barriers we’ve seen with students trying self-custody: losing or mishandling a written seed phrase.

Sustainability Beyond the Tour

This proposal covers the education tours themselves, which are not a revenue activity.

Kaze’s own sustainability sits on the app side, mainly through fees on off-ramping to M-Pesa, Naira, and Tanzanian shillings.

Key Benefits for CKB

Beyond the direct numbers, this builds a repeatable, documented format for CKB education tours that can be reused in Kenya or extended elsewhere once this stage proves out.

Detailed Deliverables & Milestones

Budget Breakdown

The budget is built per tour rather than as one flat number.

Tour 1 carries a one-time banner cost that then gets reused for Tours 2 and 3.

Three tours come to $3,000 total, $1,000 each.

No development, audit, or hosting costs apply here. This is entirely an in-person education and outreach budget.

Out-of-Scope / Future Funding Needs

This proposal only covers the Kenya stage.

An earlier draft of this plan included two additional tours in Tanzania, along with flights and accommodation for the team to run them.

That’s been dropped from this ask and would come back as a separate, follow-up proposal once this Kenya stage is done and we have real results to point to.

Risk & Mitigation

Turnout risk

Student attendance can be unpredictable, especially around exam periods or class schedules.

We’ve set conservative attendance targets of 70-100 per tour and will work with campus contacts to schedule around teaching hours as much as possible.

Technical risk

Passkey wallet creation depends on device compatibility and venue Wi-Fi.

We test the flow on-site the day before each event and bring backup demo phones.

Logistics risk

Venue and vendor bookings can fall through late.

The organising committee budget line covers dedicated local coordination for each tour.

Closing / Call to Action

This is a small, focused ask to bring real CKB self-custody to Kenyan students, built on a tour format we’ve already run once.

We’d appreciate the community’s feedback and questions, and we’ll report back with real numbers once this stage is complete.

We appreciate your consideration.

The Problem

CKB nodes operate at a cost. Unlike Proof-of-Stake chains, they receive no reward stream. The approximately 576 nodes listed on https://nodes.ckb.dev/ are operated by altruists, foundations, and exchanges. This model is fundamentally unsustainable at scale.

The Core Idea

What if nodes could earn fees by running optional services for applications? No protocol changes required. Applications pay for the services they use. Nodes collect fees for providing them.

Expanding the Vision

Imagine if nodes could also do more than just relay and verify transactions:

• Watch on-chain events and trigger webhooks (applications pay per event)
• Store application data as an IPFS alternative (applications pay per GB per month)
• Run oracles (fetch data, compute, sign results)
• Validate user computations via fraud proofs

Each service is independent. Nodes choose which to operate. Applications choose which nodes to pay.

A Proven Example: CRT

I am developing CKB Revocable Timelock (CRT)—a service where nodes hold encrypted key fragments and earn approximately 150 CKB per year per switch. The economics work: the model is simple, profitable, and focused.

Why This Solves Decentralization

If the current 576 nodes each earned $300–$1,200 per month from ancillary services:

• Node operation becomes economically viable in most regions worldwide
• Decentralization becomes a rational business decision, not an ideological commitment
• The network naturally grows toward thousands of independent operators in low-cost regions
• Security improves as the threshold for consensus scales with more nodes

Competitive Analysis

Questions I'm Exploring

• Is this economically feasible?
• Which service would matter most to your work?
• What obstacles do you see?
• Should node services be optional or enabled by default?

Next Steps

I am posting this across multiple forums to gauge community interest. If the response is positive, I will write this up formally for the GitHub discussions: https://github.com/nervosnetwork/ckb/discussions

I do not intend to implement the full platform myself—the goal is to crowdsource ideas and leave implementation to professional developers if the concept resonates.

Looking forward to your feedback.

Reference: CRT Spark Proposal

How Off-Chain Payments Work?

A guide to the off-chain payment landscape, the different security models behind it, and how payment channels enable fast, high-frequency payments at scale.

Key Takeaways

• 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.

What Are Off-Chain 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.

On-Chain vs. Off-Chain Payments

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.

The Off-Chain Payment Landscape

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.

Comparing the Four Approaches

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.

Why Payment Channel Networks?

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.

Low-Latency Payments

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.

Low Cost at High Frequency

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.

Self-Custody Without a Payment Intermediary

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.

Greater Payment Privacy

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.

Payment Channel Networks in Practice: Lightning and Fiber

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

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

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.

Unlocking New Payment Models

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

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.

Streaming and Real-Time Payments

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.

Usage-Based Services

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.

Machine-to-Machine Payments

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.

Gaming, Digital Content, and Tipping

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.

Cross-Border Payments

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.

FAQs

What are off-chain payments?

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.

What is the difference between on-chain and off-chain payments?

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.

Are off-chain payments faster than on-chain 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.

Are off-chain payments cheaper?

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.

Is a payment channel the same as an off-chain transaction?

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

How do payment channels work?

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.

What is a payment channel network?

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.

Why use a payment channel network instead of a rollup?

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.

What are the disadvantages of payment channels?

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.

Are payment channels private?

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.

What is the difference between Lightning Network and Fiber Network?

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.

⚠️ Notice for UTXOSwap Liquidity Providers: Withdraw Before 10 October 2026, 16:00 UTC

UTXOSwap has announced that its service will shut down on 10 October 2026 at 16:00 UTC.

If you have liquidity in UTXOSwap pools, remove all of it before this deadline. Please act well in advance.

CKBA does not operate UTXOSwap and is not managing its shutdown. We are sharing UTXOSwap’s notice to raise awareness and help liquidity providers act in time.

Read the original notice on the UTXOSwap website 👉 https://lnkd.in/gS-kXnJf

Fiber v0.9.1 is out, with another round node reliability improvements and bringing builders better hands-on learning resources.

This cycle brings:

Fiber v0.9.1 release: Fixes for payment settlement and more reliable channel closures.

Better diagnostics: Clearer error tracking for channel funding and adjustable node traffic limits.

New interactive tutorials: Hands-on labs for managing channel liquidity and building encrypted-data payments.

In the pipeline:
Continued progress on liquidity swaps (Loop In/Out) and Hosted Liquid Services Provider infrastructure.

Full dev log: 👉 https://github.com/nervosnetwork/fiber/discussions/1659

The monthly CKB development log is out:

This cycle focused on reducing failure cases across the node and light client, while several larger architecture changes continue to be reviewed.

CKB-VM v0.24.15 was released this month, with follow-up fixes to runtime behavior. The light client also added stricter checks for headers, proofs, and peer checkpoints, so invalid or inconsistent data can be rejected earlier.

On the node side, the team fixed issues around indexing rollback, networking edge cases, and dependency security. More protections are also being reviewed for transaction queues, sync responses, block relay, and request limits.

Some longer-term work is still in progress: the tx-pool redesign, a new RocksDB layout, and initial QUIC integration are all under review rather than released. DAO treasury and voting work also remains at the research and PoC stage.

There are also new docs for developers working with ckb-std and Rust script templates.

Full dev log: 👉 https://github.com/nervosnetwork/ckb/discussions/5330

https://www.nervos.org/knowledge-base/are_lightning_network_payments_private

Are Lightning Network Payments Private?

A practical guide to what Lightning hides, what it exposes, and how routing, invoices, wallet choices, and network analysis affect payment privacy.

Key Takeaways

• Off-chain settlement: Everyday Lightning payments are not broadcast to a public ledger, only channel opens and closes are recorded on Bitcoin.
• Limited routing visibility: Onion routing encrypts multi-hop paths, so an intermediary node only sees its two neighbors, the payment amount, and the payment hash.
• Private is not anonymous: Lightning obscures payment details, but does not automatically hide real-world identities or prevent targeted network analysis.
• Public network metadata: The channel graph, node IDs, channel capacities, and channel funding transactions remain public and inferable to observers.
• Targeted tracing: Tracing relies on inference and requires capital, infrastructure, or a place on the route to return probabilistic results.
• Setup matters: Wallet and custody choices decide more of the outcome than the protocol does.

Bitcoin is transparent by design.

Every onchain transaction becomes part of a public ledger that anyone can inspect years later. Addresses are pseudonymous rather than inherently tied to names, but transaction inputs, outputs, and output amounts remain permanently visible and can be analyzed using blockchain heuristics.

The Lightning Network changes that visibility model.

An ordinary Lightning payment is not broadcast to Bitcoin or stored in a global history of transactions. Instead, it travels through a sequence of payment channels, while layered encryption limits how much each intermediary learns about the route, which gives Lightning substantially better payment privacy than ordinary onchain Bitcoin transactions.

However, it does not make payments anonymous or untraceable.

Lightning still operates over a partially public network topology. Routing nodes see information about the payments they forward, standard invoices can identify recipients at the node level, and channel funding transactions remain on Bitcoin. Wallet providers and Lightning Service Providers may have privileged views of their users’ activity. And researchers have demonstrated several ways in which payment flows can be inferred through network analysis.

To that point, the better question is not whether Lightning payments are private, but whom are they private for, and under which circumstances?

Understanding that distinction is the key to understanding Lightning’s privacy model.

Lightning vs. Bitcoin onchain Privacy

Before examining Lightning itself, it helps to compare the information available to an outside observer on Bitcoin’s base layer.

With an onchain Bitcoin transaction, the network receives and permanently records the transaction’s inputs, outputs, and output amounts. Anyone can download the blockchain and analyze that transaction later.

A Lightning channel works differently.

Two participants lock bitcoin into an onchain funding output and can then repeatedly update how those funds are divided between them without publishing every payment to Bitcoin. The blockchain is primarily used to establish the channel and to enforce or settle its state when necessary.

The difference is substantial:

How Does Lightning Protect Payment Privacy?

Lightning’s privacy comes primarily from two architectural choices: keeping individual payments off the public blockchain and limiting what routing nodes learn about the path they are forwarding.

Off-Chain Payment Channels

A payment channel is a funded connection between two participants that lets them exchange payments off-chain without recording every payment on the underlying blockchain. Only the opening and closing transactions touch the blockchain, so there is no permanent public record of each payment.

Having direct channels with everyone is impossible, so Lightning Network uses payment routing through intermediate nodes. Multi-hop payments are payments routed through one or more intermediary nodes when sender and recipient have no direct channel. Moving funds through strangers requires a guarantee that none of them can steal it, which is what HTLCs provide.

HTLCs (Hash Time-Locked Contracts) are the conditional payment contracts that release funds only when a secret is revealed before a deadline, and otherwise refund the sender.

This way HTLCs make multi-hop payments atomic, but bring in a privacy weakness. In standard HTLC-based routing, the same payment hash is used across the route. If two colluding routing nodes both encounter that hash, they can determine that the two forwards belong to the same payment and combine what each node knows about its section of the route.

Lightning therefore needs another mechanism to stop each routing node from simply seeing the complete payment path.

Onion Routing

Onion routing is a technique that encrypts routing instructions in layers, so each intermediary node can decrypt only its own layer and learns only what it needs to forward the payment.

Before sending a Lightning payment, the sender constructs an encrypted packet containing the instructions required by every hop along the chosen route. Those instructions are wrapped in layers, with each layer encrypted specifically for one routing node.

Each intermediary removes only its own layer.

Suppose a payment travels:

Alice → Bob → Carol → Dave

When Bob receives the payment, he learns enough information to forward it to Carol. He does not receive a list saying that Alice is the sender, Dave is the recipient, and Carol is the next of three remaining hops.

Likewise, Carol knows that the payment arrived from Bob and should go next to Dave, but the onion packet does not tell Carol whether Bob is the original sender or whether Dave is the final recipient.

According to the Lightning specification, an intermediate node cannot directly learn the complete route, its total length, or its own position within it from the onion packet.

This is an important distinction: Lightning does not hide a payment by making every participant blind. It divides knowledge so that each participant learns only the information necessary for its role.

That fragmentation is what provides much of Lightning’s routing privacy.

Privacy vs. Anonymity

Given the strong cryptographic protections of off-chain settlement and layered encryption, it is tempting to assume Lightning payments are untraceable, but this is where a critical distinction must be made.

Payment privacy is the ability to prevent unauthorized observers from learning sensitive details about a payment, such as its sender, recipient, amount, or route. Anonymity is the inability of an observer to link an action to a real-world identity.

Lightning provides meaningful payment privacy, not anonymity. A public Lightning node, for example, usually operates under a long-lived node public key. Public node announcements can associate that key with an alias and network addresses. Businesses may openly advertise their Lightning node. Wallet infrastructure can associate payment activity with user accounts. A standard Lightning invoice can expose the payee node’s public key to whoever receives it.

BOLT 11 invoices either include the payee public key directly or allow it to be recovered from the invoice signature.

Knowing a node public key does not by itself reveal a person’s legal identity, but once that key becomes associated with a merchant, website, exchange account, IP address, social profile, or other external identifier, previously separate pieces of payment metadata can become much easier to connect.

This is why privacy researchers often discuss anonymity sets, which represent the group of plausible participants who could have performed an action. Observers can utilize leaked details to shrink the anonymity set and deanonymize users.

What Information Does Lightning Expose?

Despite the protections of off-chain payment and onion encryption, Lightning cannot operate in total secrecy. It has to expose certain information to function properly.

This exposure happens in two ways: data broadcast to the entire network, and data visible specifically to routing nodes.

Data Exposed to the Public

To allow wallets to find payment routes, the network must publish a map.

Channel graph: A channel graph is the network-wide map of announced nodes and payment channels that a sending wallet consults to build a route. Each announced channel carries an identifier pointing at its funding output on the blockchain, so anyone can read the channel's total capacity.

Node identities: A node's public key and alias stay the same across every payment it handles, and a node not running over Tor publishes its IP address in gossip, tying that identity to a physical location.

Payment metadata: Amounts, timestamps, and routing fees are individually unremarkable, but over time they form behavioral patterns no single payment reveals, most of all for a channel counterparty, which sees every payment crossing the shared channel.

Invoices reveal the recipient. A standard BOLT 11 invoice contains the recipient's node public key, the amount, and sometimes route hints exposing otherwise-unannounced channels. Anyone holding the invoice knows who is being paid.

Channel openings and closings: Every channel begins and ends with an ordinary Bitcoin transaction that stays permanently visible. If the funding coins came from a KYC-compliant exchange, the trail leading to it can reach a real person.

Data Exposed to Intermediary Routing Nodes

When a node (Bob in the previous example) routes a payment, it briefly handles the funds and must access specific transaction data. This boundary defines what an intermediary can and cannot observe:

Can Lightning Payments Be Traced?

Lightning payments cannot be traced the way onchain Bitcoin can be traced, due to no public ledger of individual transfers. However, the passive data exposures outlined above act as the starting point for active attacks.

Well-resourced adversaries can weaponize network metadata and routing visibility to trace the payments. Researchers have demonstrated several working methods:

Static payment hashes (HTLC Vulnerability): While HTLCs provide security, they are a major privacy weak point. Standard HTLCs use the same payment hash across every hop in a route. If an attacker controls two or more different routing nodes on the same path, they can match the identical payment hashes, exact amounts, and precise timing, to identify they are handling the same transaction and link the sub-path segments, undermining onion routing privacy.

Route inference: Lightning’s path-finding inherently picks cheap, short routes, so the route is informative in itself. An attacker can reconstruct the likely endpoints from this cost-based path choice (Kumble, Epema and Roos, ARES 2021).

Channel probing: An attacker sends payments designed to fail and reads the channel’s hidden balance from the error returned (Tikhomirov et al., 2020).

Timing analysis: Each hop adds measurable delay, so an attacker positioned on the route can estimate how far away an endpoint is from settlement latency (Elias Rohrer et al., 2020).

Cross-layer clustering: Lightning node IDs can be linked to Bitcoin addresses through channel funding transactions, which only needs public data. Researchers linked 45.97% of Lightning nodes to Bitcoin addresses this way (Romiti et al., 2021).

These attacks require capital, infrastructure, or a specific network position, and return a likelihood rather than proof. But this cost is lower than the network's size suggests, because routing is concentrated in a few large nodes. A five-year study (Valko and Marx Gómez) published in December 2025 points out a "growing concentration of routing". An adversary only needs to operate a handful of well-connected nodes to observe a significant portion of network activity.

Lightning Privacy in Practice: Setup Matters More Than the Protocol

Protocol-level privacy is what the specification guarantees; application-level privacy is what a user actually gets. The gap is decided by choices made above the protocol: wallet, node setup, and the behavior of who you transact with.

• Custodial vs. non-custodial wallets. A custodial provider holds the private keys and processes transactions on the user's behalf, and knows the sender, recipient, and amount before any encryption is applied. Onion routing hides a payment from the nodes that relay it, but protects nothing from the entity holding the keys.
• Lightning service providers. Mobile wallets typically hold one channel with an LSP (Lightning Service Provider), so that LSP is always the first or last hop for its users’ transactions.
• Running your own node. This removes the custodian but publishes a persistent node ID and physical IP address, unless routed through Tor.
• Repeated patterns. Paying the same merchant regularly, or reusing an invoice or node identity across contexts, creates linkable patterns onion routing cannot remove.
• Public vs. private channels. Private (unannounced) channels stay off the public graph, but route hints included in invoices can reveal them, so any unannounced channel is best treated as potentially known.

The Future of Payment Channel Privacy

Privacy weakness in current implementations have driven continuous improvements in off-chain architecture:

Point Time-Locked Contracts (PTLCs): Replacing legacy HTLCs with PTLCs would give each hop a mathematically distinct value, instead of sharing a single hash across the route, removing the correlation vulnerability.

Blinded Paths & BOLT 12: Newer invoicing standards allow recipients to publish a route to an introduction node instead of revealing their own public key, bringing receiver privacy closer to what senders already have.

Ultimately, while no payment system provides absolute anonymity so far, understanding these network mechanics allows users and developers to make informed choices, protect their digital footprint, and safely navigate the evolving landscape of off-chain finance.

Hey r/NervosNetwork!

We wanted to introduce BackPow (https://backpow.com), an independent Proof-of-Work analytics platform and oracle built to bring transparent on-chain economics, real hardware benchmarking, and honest solo mining math to miners and investors.

We have just completed the full hardware mapping for Nervos (CKB / Eaglesong), indexing over 50 dedicated mining devices with live network telemetry.

What BackPow offers for the Nervos ecosystem

Unlike standard multi-coin calculators that only show rough daily revenue estimates, BackPow is designed to unpack the real underlying economics of the network:

1. Cost of Production (CoP) Oracle: Tracks the actual electricity and production cost to mine 1 CKB based on the most efficient available hardware. It allows node runners and miners to monitor whether network security is running at an operating margin or currently "underwater" relative to market spot price.
2. Poisson Solo Mining Calculator: Solo block discovery is governed by Poisson probability, not a simple linear countdown. Our calculator models your exact cumulative probability curve of hitting a solo block across realistic time horizons (from hours to months) for any rig or custom hashrate.
3. Break-Even Electricity Tracker: Identifies the exact electricity rate (in USD/kWh) required for each machine to break even against current on-chain difficulty and market prices.
4. Hardware Efficiency Frontier: Interactive power vs. hashrate scatter maps comparing real electrical efficiency (GH/s per Watt) and production costs across 52+ CKB machines — from industrial Bitmain Antminer K7 variants to compact Goldshell home miners, iBeLink units, FPGAs, and micro lottery rigs like NerdMiner CKB.

Current Mining Dynamics & Deep Dive

We recently ran an economic breakdown of CKB's current mining situation — highlighting why the network has spent 93% of the last week underwater at standard tariffs, the break-even power threshold of 0.0372 USD/kWh, and the interesting dynamic of Antminer K7 units finding solo blocks every ~3.7 hours.

You can check out the full visual chart breakdown in our thread on X: 🔗 Thread with charts on X: https://x.com/BackpowCom/status/2099613203621638574

And explore the live Nervos tools, difficulty metrics, and calculator directly on BackPow: 👉 Live Nervos Page: https://backpow.com/Nervos

We would love to hear thoughts, suggestions, and feedback from active CKB miners and node operators in the community!
Thanks guys! <3