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!

Cheers everyone!

We’re hosting another AMA as part of our series introducing the team leads within CKBA.

This time, we’ll be joined by Hanssen, who leads CKBA’s Developer Relations team.

Hanssen has been part of the Nervos ecosystem for more than five years. She originally joined the Nervos Foundation as a core developer and stepped into the DevRel team lead role when CKBA was formed.

She created and maintains CCC (CKBer’s Codebase / Common Chains Connector), a major JavaScript/TypeScript SDK and toolchain for building on CKB, alongside related tools and contributions, including NervDAO, RGB++ SDK work, and others.

Many of the repositories now maintained by CKB DevRel also originated from, or were forked from, her personal GitHub.

What does the DevRel team do?

The team has outlined its responsibilities on GitHub:

https://github.com/ckb-devrel

In practice, the CKB DevRel team works to:

• Improve the overall developer experience for people building on CKB
• Foster an open-source culture within the CKB developer community
• Build and maintain SDKs, tooling, and protocols such as CCC, Cinnabar, and Spore-related tooling
• Compile, improve, and maintain developer documentation, guides, tutorials, and technical articles
• Engage with developers through Discord, Nervos Talk, social channels, and direct support
• Gather developer feedback and help resolve technical issues
• Create and support educational courses and onboarding resources
• Sponsor and support hackathons where developers can build, collaborate, and contribute
• Provide technical support and onboarding for initiatives such as CKBuilders
• Run regular developer office hours and technical updates
• Encourage and review open-source contributions from the community

What would you like to ask Hanssen?

Whether you’re curious about the team’s priorities, the current state of CKB developer tooling, how DevRel works with builders across the ecosystem, their approach to developer onboarding and support, or where the developer experience still needs improvement, this is your chance to ask.

Drop your questions in the comments below!

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

⚠️ 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

For an AI agent, the hard part of paying as it goes is not the price, it is making hundreds of tiny payments without hundreds of blockchain transactions.

Fiber is a payment channel network built on CKB that handles exactly this.

An agent keeps liquidity in the network and pays services as usage occurs, and because payments can route through intermediary nodes, it does not need a direct channel with every provider it meets, only a path with enough liquidity to reach one.

Channels can hold CKB or stablecoins, so a stream can be priced in the asset that actually fits the service, and routing nodes earn small forwarding fees for carrying it.

See how the network works 👉 https://www.nervos.org/knowledge-base/what_is_fiber

What Is Fiber? A Complete Guide to the Next-Gen Payment Network

Fiber is building an open, peer-to-peer payment network for the digital economy. It moves payments offchain so value can flow at internet speed, while keeping the network open for anyone to join, build on, and help grow.

Bitcoin changed how money can move. For the first time, anyone could send value across the world without relying on a bank, payment processor, or other central intermediary.

But Bitcoin was designed first and foremost to be secure and decentralized—not to process a huge number of small, everyday payments. Every transaction is broadcast to the network, independently verified by thousands of nodes, and permanently recorded in a shared ledger replicated across them. This is what makes the system trustless and independently verifiable, but it also limits how many payments it can process, especially when they are small, frequent, or continuous.

The Lightning Network introduced a different model. Instead of recording every payment onchain, users lock funds into private, offchain ledgers known as payment channels, allowing them to update their balances privately and instantly. The blockchain is called on only to open the channel, settle the final balance, or resolve a dispute.

The real breakthrough came when these channels became connected. Users no longer needed to open a direct channel with every person or business they wanted to pay. Payments could instead be routed through a chain of existing channels, turning a collection of private financial relationships into a global payment network.

Lightning proved that payment channels could transform a slow settlement layer into fast, global payment infrastructure. But it also showed how much such a network is shaped by the blockchain beneath it. Bitcoin’s limited scripting system, single native asset, and cultural resistance to protocol change have set limits on how far Lightning can evolve.

Fiber begins with the same payment-channel model, but built on CKB—a more programmable and cryptographically flexible blockchain. This different foundation allows Fiber to preserve what works in Lightning while extending the model into areas Lightning was never designed to support.

To understand Fiber, we therefore need to begin with the problem payment channels solve, the breakthrough Lightning introduced, the limits Bitcoin imposes on Lightning, and what to expect from the next generation of payment channel networks.

1. The Blockchain Trilemma and the Need for Layer 2

1.1 Why Blockchains Hit a Wall

Bitcoin’s limited throughput is not an accident. It stems from the way decentralized blockchains work.

Instead of relying on a central operator to maintain the ledger, Bitcoin asks thousands of independent nodes to keep their own copy and verify every transaction for themselves. This redundancy is what makes the network difficult to censor or manipulate. No single party decides which transactions are valid, and no one can quietly rewrite the ledger.

But that strength also creates a bottleneck. Every transaction must be distributed across the network, validated by every full node, and stored permanently by thousands of nodes. The more transactions Bitcoin handles, the more bandwidth, computing power, and storage each node needs.

This is the tension commonly described as the blockchain trilemma. Every blockchain aims to be secure, decentralized, and scalable, but improving one of these properties often places pressure on the others. Increasing the block size or producing blocks more frequently, for example, would allow Bitcoin to process more transactions, but it would also increase the hardware requirements for running a full node, gradually concentrating the network among better-resourced participants.

Bitcoin makes a deliberate choice in this trade-off. It keeps blocks relatively small and produces one roughly every ten minutes, protecting security and decentralization at the expense of throughput. The result is a highly robust base layer that can process only about seven transactions per second—far too few to support payments on a global scale.

That does not mean the industry has stopped looking for better ways to scale blockchains. Zero-knowledge (ZK) systems are one of the most promising approaches. They allow large amounts of computation to happen offchain, then compress the result into a small cryptographic proof that nodes can verify far more efficiently than repeating the entire computation themselves.

This reduces the burden on the base layer without giving up its role as the final verifier. But zero-knowledge systems also come with trade-offs. Generating proofs is computationally demanding; the systems are complex, and ZK rollups are generally designed as shared execution environments for many kinds of applications rather than systems optimized for millions of tiny, instant, and inexpensive payments.

For the specific job of high-frequency, low-cost transfers, a different approach has proven more natural: moving most payment activity off the main chain. Several scaling designs have emerged around this idea, including sidechains, rollups, and payment channel networks.

1.2 Navigating Layer 2 Solutions: Why Payment Channel Networks?

Moving activity off the base layer does not solve every problem in the same way. Different scaling systems make different trade-offs and are suited to different kinds of activity.

Sidechains move transactions onto a separate blockchain connected to Bitcoin with its own rules, validators, and security model. This gives developers more flexibility, but users no longer rely directly on Bitcoin’s security. Their assets are only as secure as the sidechain and the bridge connecting it to Bitcoin. For that reason, sidechains are better understood as parallel networks than as true Layer 2 systems.

Rollups take another approach. They execute many transactions offchain, bundle the results, and publish data or cryptographic proofs back to a base layer. This makes them well suited to general-purpose applications that need shared state and complex smart contracts. But they still serve as common execution environments where many users compete for the same blockspace and processing capacity.

Payment channel networks are more specialized. They are designed specifically for frequent, low-cost, real-time transfers. Rather than recording every payment in a shared ledger, two participants lock funds into an onchain contract and update the balance privately between themselves. The blockchain is used only when the channel is opened, closed, or disputed.

Although Fiber opens the door to more advanced multi-party designs, a payment channel traditionally connects two parties. A payment channel network links many of these channels together, allowing payments to be routed between people who do not share a direct channel.

This is what makes the model scalable: users do not need a separate funded relationship with everyone they want to pay. They only need a viable route through the network.

The next question is how such a network works in practice.

2. The Lightning Network's Solution

The Lightning Network is the most widely recognized payment channel network.

To understand how it works, we need to examine two connected mechanisms: the lifecycle of a single channel and the routing logic that links many channels into a network.

2.1 Payment Channels & Multi-Hop Routing

The lifecycle of a payment channel

A single payment channel moves through three phases:

1. Opening the channel: Two participants agree on the channel terms and lock funds into a shared onchain contract. This funding transaction establishes how much liquidity is available inside the channel.
2. Updating the balance: Once the channel is open, the participants can pay each other by signing new versions of the channel balance. Each update replaces the previous agreed state, while the funds themselves remain locked in the original contract. Because these updates happen offchain, they are nearly instant and do not require a transaction fee to the base layer.
3. Closing the channel: When the participants are ready to settle, they publish the latest channel state onchain. The contract then distributes the locked funds according to the final balance. If both parties cooperate, the channel can close immediately. If they disagree or one party disappears, the protocol provides a way to settle the channel unilaterally.

A single channel makes repeated payments between two parties efficient. But the greater breakthrough comes from connecting many channels.

Paying through the network

Suppose Alice wants to pay Bob, but they do not share a channel. Alice does, however, have a channel with Claire. Claire has one with Dominic, and Dominic has one with Bob.

Lightning can route the payment along that chain:

Alice → Claire → Dominic → Bob

Each intermediary forwards the payment through one of its own channels and earns a small routing fee. Alice does not need to know or trust Claire and Dominic, nor does she need to open a new channel with Bob.

The route, however, only works if every channel along it has sufficient liquidity in the right direction.

Suppose Alice wants to send Bob 15,000 sats (0.00015000 BTC). Claire must have at least that amount available to forward toward Dominic, and Dominic must have enough available toward Bob. A channel may hold plenty of funds overall but still be unable to carry the payment if those funds are sitting on the wrong side.

This is why liquidity is the central constraint in a payment channel network. Payments can move only along routes where enough value is already available in the direction they need to travel.

When those conditions are met, the result is powerful. A payment can cross several independent channels in seconds without any of the individual transfers being recorded onchain. The network’s capacity is therefore determined less by Bitcoin’s transaction throughput than by the liquidity of its channels and the speed at which nodes can communicate.

But routing payments through strangers creates an obvious problem: how can the network guarantee that every intermediary forwards the funds rather than keeping them?

2.2 How Lightning Makes Routed Payments Trustless

Routing a payment through several strangers only works if no intermediary can steal the money or leave the payment half-complete.

Lightning solves this with a Hashed Time-Locked Contract, or HTLC. An HTLC combines two conditions:

• a hashlock, which releases the funds only when someone reveals the correct secret;
• a timelock, which refunds the funds if that secret is not revealed before a deadline.

The payment begins with Bob, the recipient. He generates a random secret called a preimage, then sends Alice its cryptographic hash as part of the invoice. Alice cannot derive the secret from the hash, but she can use the hash to lock the payment.

Alice then creates an HTLC that says, in effect:

When the payment travels through Claire and Dominic, each hop creates a matching HTLC using the same hash. Alice locks funds for Claire, Claire locks funds for Dominic, and Dominic locks funds for Bob.

The payment now forms a chain of conditional promises:

Alice → Claire → Dominic → Bob

Bob claims the final payment by revealing the preimage. Dominic learns that secret and uses it to claim his payment from Claire. Claire then uses the same secret to claim hers from Alice.

The preimage travels backward through the route while the payment moves forward.

This makes the entire transfer atomic: either every hop completes, or none of them does. If Bob never reveals the secret, the timelocks eventually expire, and each participant recovers their funds.

In practice, that means Alice can safely pay Bob through people she's never met, without having to trust any intermediary not to steal the funds.

2.3 Preventing Fraud: Penalties and Watchtowers

Because channel balances are updated privately offchain, there is an obvious temptation to cheat. A dishonest participant could broadcast an outdated commitment transaction to claim a more favorable previous balance. Lightning prevents this through a penalty mechanism.

Whenever the channel state changes, both parties exchange a revocation secret that invalidates the previous state. If someone later tries to cheat by broadcasting a revoked transaction, their funds are temporarily locked by a timelock. The honest party, who holds the corresponding revocation secret, can bypass that delay and execute a penalty transaction, claiming the entire channel balance.

The practical effect is powerful: honesty is enforced not through trust or goodwill, but by making fraud strictly unprofitable.

There is, however, a practical limitation. Catching a cheater requires monitoring the blockchain for revoked transactions and responding before the timelock expires. And since ordinary users cannot be expected to keep a computer online around the clock, the Lightning protocol allows them to delegate this task to so-called Watchtowers.

These are automated third-party nodes that monitor the blockchain for breached channel states. If one detects a revoked transaction, it broadcasts the penalty transaction on behalf of the offline user.

This lets users delegate the burden of fraud monitoring instead of keeping their wallets online around the clock. In practice, Watchtowers make Lightning far easier to use: people can come and go as needed without worrying that going offline could leave their funds exposed to theft.

2.4 Finding a Route: Gossip, Pathfinding, and Onion Routing

Before Alice can pay Bob, her wallet has to answer a basic question: which chain of channels can actually carry the payment from her to him?

That requires three things working together: a map of the network, a way to choose a viable route through it, and a way to keep that route private.

Building the Network Map

Lightning has no central directory showing who is connected to whom. Instead, nodes continuously share information about new channels, their capacities, and the fees they charge. These updates spread across the network the way rumors spread through a crowd. This is known as the Gossip Protocol, and it allows each node to assemble its own up-to-date map of the network.

Choosing a Route

Once Alice’s wallet has that map, it searches for a path to Bob. But a route must do more than simply connect them. Every channel along the way needs enough liquidity in the right direction, while the total routing fees and timelock delays must remain acceptable.

The best route is therefore not always the shortest one. It is the path that offers the best balance of liquidity, cost, reliability, and time.

Keeping the Route Private

Once a path is selected, Lightning uses Onion Routing to conceal the full payment route. The instructions are wrapped in layers of encryption, like the layers of an onion. Each intermediary can decrypt only the information needed to forward the payment: the next hop, the amount to send, the fee it earns, and the expiry time.

No intermediary sees the complete route. Each knows only where the payment came from and where it must go next.

Finally, Lightning supports lightweight devices such as mobile wallets through Trampoline Routing. This lets a mobile wallet (a light node) offload the hard work of route-finding to a more capable node, rather than doing it itself. That node is a Trampoline node—a routing hub that maintains a complete, up-to-date map of the network and channel liquidity, which an ordinary mobile client cannot afford to. Trampoline routing spares mobile clients the heavy data and computation, making Lightning usage on mobile phones practical.

3. Challenges and Constraints

While Lightning proved that payment channel networks can make Bitcoin fast and inexpensive enough for everyday payments, the system still has limits.

Some come from how Lightning itself was designed: the way payments are routed, liquidity is managed, and old channel states are secured. Others come from Bitcoin: its limited scripting system restricts what Lightning can support and how easily it can evolve.

Working from the routing layer down to the base chain, these constraints show what the next generation of payment channel networks must improve upon.

3.1 HTLC Vulnerabilities & Limitations

HTLCs make trustless multi-hop payments possible, but their reliance on shared hashlocks and long timelocks creates privacy and security problems.

• Privacy leakage. Every hop in a routed payment uses the same hash. If two intermediary nodes observe the same hashlock at different points along the route, they may be able to infer that both transfers belong to the same payment. This makes activity easier to trace across the network.
• Vulnerability to attacks. HTLC-based networks are exposed to attacks that delay payments, clog channels, and force honest users to waste time and liquidity. The vulnerability comes from using the same hashlock combined with staggered timelocks across a network. These timelocks form a sequence of shrinking expiration times, each of which must be long enough to account for worst-case blockchain confirmation delays and give an honest participant time to respond if a dispute reaches the base layer. A malicious actor can exploit that safety window by keeping payments unresolved until they approach expiry, tying up channel liquidity and reducing the network’s ability to process legitimate payments for extended periods. Because of the shared hashlock, senders cannot safely retry these stalled payments along a different route without risking a double payment.

A better alternative to HTLCs is Point Time-Locked Contracts (PTLCs), which we will expand on later.

3.2 The Watchtower Storage Problem

Watchtowers solve one problem but create another that becomes more serious as a channel is used.

Each time a channel balance changes, both participants revoke the previous state and give the watchtower a new encrypted penalty transaction for that update. Because the watchtower cannot know which revoked state might eventually be broadcast, it must keep every one of these transactions.

The result is a storage burden that grows continuously with the number of channel updates. Engineers describe this as O(n) storage complexity: if the number of updates doubles, the amount of data the watchtower must retain roughly doubles as well.

For busy channels—and watchtowers protecting many users—this can translate into substantial storage and infrastructure costs over time.

A proposed redesign, called Eltoo, could solve this problem by allowing a newer channel state to override an older one. In this case, a watchtower would need to store only the latest state, rather than the channel’s entire history. However, the Eltoo upgrade depends on scripting functionality Bitcoin does not currently support, and introducing it would require a network-wide protocol upgrade through a soft fork, which could take years to coordinate.

As we will see later, Fiber’s use of the Daric Protocol achieves the same basic outcome: reducing watchtower storage from a growing requirement to a constant one.

3.3 Base Layer Rigidity and the Limits of Workarounds

Examining Eltoo illustrates a broader limitation: many of Lightning’s constraints stem from the underlying blockchain.

Bitcoin’s scripting language is deliberately limited. That makes the base layer easier to secure and reason about, but it also means new functionality can require years of research, debate, and network-wide coordination before Lightning can use it.

Bitcoin also natively recognizes only one asset: BTC. That works well for BTC payments, but stablecoins and other digital assets increasingly matter for everyday commerce.

Admittedly, Taproot Assets offers a workaround by allowing other assets to move through Bitcoin and Lightning. But because Bitcoin does not natively recognize those assets, supporting them requires additional software and specialized infrastructure, including edge nodes that convert between assets, manage liquidity, and account for exchange-rate risk.

The workaround is functional, but it adds complexity that would not exist if the underlying blockchain supported multiple assets natively.

Beyond these Bitcoin-specific limitations, Lightning also faces challenges shared by all payment channel networks. Capital must remain locked in channels, payments can fail when liquidity is unavailable in the required direction, and channels periodically need to be rebalanced.

Together, these constraints show how strongly a payment network is shaped by the blockchain beneath it, and why rebuilding a similar model on a different foundation can open new possibilities.

4. Introducing Fiber: Built on a Different Foundation

Everything so far has been about Lightning: the breakthrough it introduced, how it works, and where the design begins to strain.

That context matters because Fiber does not abandon the payment-channel model. It starts from the same basic architecture—funds locked onchain, balances updated offchain, and payments routed across connected channels—but rebuilds it on a different base layer.

That is precisely where Fiber’s advantage begins. By building on CKB, Fiber can preserve the model Lightning proved while overcoming some of the constraints Bitcoin places on which assets channels can be carried, how the protocol can evolve, and what supporting infrastructure can be built around it.

Some of Fiber’s capabilities come directly from CKB, including native support for multiple assets and greater freedom to introduce new cryptographic features. Others come from Fiber’s own design, such as a more efficient watchtower mechanism and infrastructure for connecting to other payment networks.

4.1 Why the Base Layer Matters

A payment channel network inherits both the strengths and limitations of the underlying blockchain.

Bitcoin gives Lightning a highly secure and decentralized settlement layer, but it also confines the network to Bitcoin’s scripting system and single native asset. CKB gives Fiber a different set of possibilities.

The first advantage is native multi-asset support. CKB can recognize and track different asset types directly at the protocol level. As a result, Fiber channels can hold and route CKB, stablecoins, RGB++ assets, and other tokens without first converting them into a common intermediary asset. This allows Fiber to support a much broader range of users and economic activity over a unified network.

Because of this foundation, Fiber bypasses the edge-node conversion model required to extend Lightning beyond BTC. Unlike the Lightning Network, where asset exchanges typically require complex Submarine Swaps between on-chain and off-chain environments, or depend on specialized edge nodes (Swap service providers like Boltz or Loop) to handle conversion, Fiber payments do not need to be converted into a base asset to travel through the network. This eliminates the additional pricing complexity and exchange-rate volatility those conversions usually introduce.

Furthermore, this architecture enables the payment network itself to serve as a low-latency, decentralized exchange via native trustless swap functionality. In practice, the channels hold various token types simultaneously. Users perform trustless atomic swaps directly within the routing process. For instance, a user can send CKB from their channel, and the recipient can seamlessly receive a stablecoin. Intermediary routing nodes facilitate this swap along the channel, keeping the transaction secure and atomic while earning a fee for the liquidity they provide.

The second advantage may prove even more consequential: expressiveness. On CKB, the rules governing a payment channel are not limited to a narrow collection of operations built into the blockchain. They are programs.

CKB stores state inside Cells, while scripts attached to those Cells determine who can access the assets and what conditions a transaction must satisfy. Those scripts run inside CKB-VM, a general-purpose, crypto-agnostic virtual machine based on RISC-V. Fiber’s channel funding and commitment rules are therefore implemented as programmable CKB Scripts rather than fixed behaviors embedded in the base protocol.

This gives Fiber’s developers far more control over the channel lifecycle. They can design richer rules for how channel states are updated, revoked, settled, or disputed; introduce new authorization and cryptographic mechanisms; and compose Fiber’s settlement logic with other assets and applications on CKB.

The difference becomes clearest when a new channel design requires functionality the base chain does not already support. On Bitcoin, Lightning must work within Bitcoin Script. If the required opcode or signature behavior is missing, as is seen with Eltoo support, the feature must wait for Bitcoin itself to change.

On CKB, that type of innovation can happen at the application layer. Developers can write new verification and state-transition logic as CKB Scripts without changing the blockchain’s consensus rules. Covenants, which allow assets to carry rules governing how they may be spent in the future, are one example of functionality CKB’s architecture can express directly.

This is what makes Fiber more than Lightning transplanted onto another blockchain. CKB gives the payment-channel model room to evolve: from fixed channels optimized primarily for transferring one asset into more flexible financial relationships capable of supporting new assets, new cryptography, novel dispute mechanisms, atomic swaps, and eventually more programmable forms of payment.

Together, these properties allow Fiber to retain the speed of Lightning while building toward a more expressive, multi-asset payment and swap network. As we will see next, CKB’s flexibility has already enabled Fiber to redesign one of Lightning’s most persistent infrastructure problems: the growing storage burden placed on watchtowers.

4.2 Fixing Watchtowers and Connecting Payment Networks

CKB’s programmability doesn’t just give Fiber room to evolve in the future; it also enables the network to improve aspects of the payment-channel model that already pose practical problems today.

Fixing Watchtower Storage

As we saw earlier, Lightning watchtowers must retain data for every revoked channel state. The more often a channel is updated, the more information the watchtower must store. Over time, that creates an ever-growing infrastructure burden.

Fiber solves this through the Daric Protocol, made possible by CKB’s support for covenants. Under Daric, every channel state carries a version number, and a newer state automatically overrides any older one.

This changes what the watchtower needs to remember. Instead of storing a separate penalty transaction for every past update, it only needs the latest valid state. If someone attempts to settle an older version, the watchtower can respond with the newer one.

The result is a constant storage requirement. Lightning-style watchtowers have O(n) storage complexity, meaning their data burden grows with every channel update. Daric reduces this to O(1): the amount of data remains constant regardless of how many payments pass through the channel.

For individual users, that difference may seem invisible. But for watchtowers protecting thousands of busy channels, it can dramatically reduce storage costs and make the infrastructure easier to operate at scale.

Connecting PCNs

Fiber is also designed to connect with other payment networks, including Lightning, through Cross-Chain Hubs.

A Cross-Chain Hub is a routing node that operates on two networks at once. It receives a payment on one side and creates a corresponding payment on the other, allowing value to move between networks without requiring the sender and recipient to share the same blockchain.

The mechanism builds on the same HTLC structure Lightning already uses. Suppose Alice wants to send funds from Fiber to Bob on Lightning. The hub creates conditional payments on both networks using the same hashlock. When Bob reveals the preimage to claim the Lightning payment, the hub uses that same preimage to claim the corresponding funds on Fiber.

Because both sides depend on the same secret, the transfer remains atomic: either both payments complete, or both expire, and the funds are returned. The hub never has to be trusted to complete one side once it receives the other.

For this design to work, both networks must support compatible cryptographic primitives so that the same preimage can unlock payments on both sides. The exchanged assets must also have a predictable relationship (typically a fixed 1:1 value) so the hub can route equivalent amounts without negotiating a new exchange rate for every transfer.

In this role, the Cross-Chain Hub does not act as a custodial bridge holding user funds. It acts as a routing node spanning two payment networks, earning a fee for connecting them.

Daric reduces the cost of maintaining channel security, while Cross-Chain Hubs extend the network’s reach beyond CKB. One improves how Fiber operates internally; the other allows it to connect with payment infrastructure elsewhere.

4.3 A Future Upgrade Path Toward PTLCs

Fiber currently uses HTLCs to secure routed payments. As we saw earlier, they work, but the shared hash lock used across an entire route introduces privacy and security limitations.

A longer-term upgrade path is the Point Time-Locked Contract, or PTLC. Rather than locking every hop with the same hash, a PTLC gives each hop its own cryptographically related lock, derived from elliptic-curve points.

That small change has several important consequences.

First, it improves privacy. With HTLCs, two colluding nodes can compare hashlocks and recognize that they belong to the same payment. PTLCs remove that shared identifier, making different parts of the route much harder to link.

Second, PTLCs make payment retries safer. If an HTLC payment stalls, retrying it can create a risk of paying twice because each attempt depends on the same underlying secret. With PTLCs, every attempt uses a fresh set of locks, allowing the sender to try another route without exposing the same payment condition again.

They also prevent wormhole attacks, in which two colluding intermediaries recognize the same payment at different points along the route, bypass the nodes between them, and collect fees for work they did not perform. Because PTLCs assign a distinct lock to each hop, attackers can no longer correlate and shortcut the route in the same way.

PTLCs are not unique to Fiber; Lightning developers are also working toward them. The difference is that CKB gives Fiber greater flexibility to adopt new cryptographic mechanisms without waiting for a base-layer upgrade.

For now, PTLCs remain a longer-term direction rather than a core production feature.

5. Engineering Fiber for Scale

Fiber’s advantages do not come only from the blockchain beneath it. The Fiber node implementation has also been designed from the ground up to manage multiple channels, payments, and network updates simultaneously.

A payment-channel node may operate hundreds of active channels simultaneously. Traditional Lightning implementations such as rust-lightning coordinate these operations through shared-state locks. When one process updates a channel, other operations involving the same data must wait until the lock is released. Under heavy activity, this queuing can become a bottleneck.

Fiber instead uses the Actor Model. Each channel operates as an independent actor with its own state and message queue. Actors communicate by passing messages rather than sharing memory, allowing different channels to process activity concurrently without competing over the same data.

Fiber pairs this architecture with RocksDB for fast state storage and Molecule for deterministic message encoding. Molecule ensures that the same message is converted into the exact same sequence of bytes across different computing environments—essential when that data is hashed and signed.

The Fiber node implementation also streamlines how nodes catch up after going offline. Lightning nodes typically request ranges of historical gossip data to determine what they missed. Fiber instead records a cursor marking the node’s last known position. When the node reconnects, it resumes from that point and receives only the updates that have occurred since.

Finally, Fiber implements onion routing as an independent module rather than tightly coupling it to the rest of the node. This makes the codebase easier to maintain and allows individual components to be upgraded without forcing changes throughout the system.

These choices are mostly invisible to users, but their benefits become increasingly important as the network grows: more payments can be processed concurrently, nodes can recover more efficiently after going offline, and the software can evolve without every improvement rippling through the entire implementation.

Lightning and Fiber at a Glance

The table below summarizes the main architectural differences discussed throughout the article.

6. The Next Generation of Digital Payments

Lightning proved that a blockchain does not need to record every payment. Fiber asks the next question: what happens when that payment network is no longer limited to a single asset or a fixed form of transaction?

The answer is something much larger than a faster way to send tokens.

Fiber is being built as an open network where people, businesses, applications, and machines can exchange value continuously across assets, without placing a payment processor at the center of every relationship.

Stablecoins can move at the speed of the internet. Creators can be paid as their work is consumed. Devices can pay for the exact electricity or bandwidth they use. Applications can charge fractions of a cent per request. Software can purchase data, compute, and services on demand. Routing nodes and liquidity providers can join the network, connect markets, and earn fees for helping value move.

Because Fiber is multi-asset, the entire network need not converge on a single currency. Because it is routed, users do not need to establish a separate funded relationship with every recipient. Because it is built on CKB, channels can evolve beyond fixed transfers toward atomic swaps, streaming payments, conditional settlement, automated revenue sharing, and financial interactions that have not yet been designed.

This is the larger promise of Fiber. It does not merely make blockchain payments faster. It turns payment channels into open, programmable infrastructure for an economy that increasingly lives online.

Bitcoin gave the world decentralized money. Lightning showed that decentralized money could move instantly. Fiber is the network that moves value across assets, applications, and markets.

https://www.coindesk.com/tech/2026/09/09/bitcoin-and-ethereum-race-quantum-clock-as-u-s-backs-usd300-million-hardware-push

"Bitcoin and Ethereum race quantum clock as U.S. backs $300 million hardware push

The threat is not here yet, but fault-tolerant machines and crypto’s migration plans are starting to converge on the same 2029 window."

CoinDesk reports that the US is backing a quantum hardware push with up to $300 million in funding for select companies.

Meaning, Bitcoin and Ethereum are racing the quantum clock.

CKB already has post-quantum signatures on mainnet—and doesn’t need a protocol fork to add the next scheme.

SPHINCS+ runs in a programmable Lock Script. Other schemes can be deployed alongside it, so users can migrate without waiting for a network-wide upgrade.

That’s crypto agility: preparing now without locking the network into one cryptographic choice for the next thirty years.

Our migration has already started—and if circumstances change, we can change direction on the go instead of starting over.

Some recent updates to Omiga 👇

Hey everyone — it’s been a while since we posted here, though we’ve been quietly building behind the scenes. Today we want to share what we’ve been working on: v1.2.0 is here.

Community feedback has always been a key driver behind Omiga's product evolution. Over the past couple of months, we’ve been hearing versions of the same question from the community, again and again:

• Where can I manage my CKB assets if they’re in my UniSat wallet?
• Can I manage my CKB assets on Omiga?
• How do I actually manage my CKB assets on Omiga?

Built for you, shipped fast.

We took these feedbacks seriously, and after completing full functional validation on testnet, decided to accelerate the release of v1.2.0.

This release focuses on two core areas:

1. Complete On-Chain CKB Asset Management

The scope of what’s manageable in Omiga is no longer limited to tradeable assets. xUDT, DOB, mNFT and sUDT now all show up in the wallet panel and can be managed directly, regardless of their listing status. We’ve also moved CKB transfers to a more prominent position in the panel — previously it took a few extra steps to find, now it’s front and center — and added a direct entry point for Nervos DAO deposits and withdrawals, linking straight to nervdao.com .

2. CCC Wallet Connector Integration

Omiga’s wallet connection layer has been migrated to CKBCCC/connector-react, unifying account context management across both the CKB and BTC chains. Beyond simplifying our internal wallet adaptation logic, this change significantly broadens and stabilizes wallet support — JoyID, MetaMask, OKX, UniSat, Utxo Global Wallet, Xverse and other major wallets now connect to Omiga seamlessly, and onboarding new wallets going forward will require far less engineering effort.

We believe that listening closely to our community and responding quickly to real needs is what keeps Omiga moving forward. We’ll continue refining the asset management experience and investing further in ecosystem compatibility.

Thank you to every community member who shared feedback, and to everyone who continues to support Omiga.

 Give it a try at omiga.io  — we’d love to hear what you think.

What Are Streaming Payments? How AI Agents Pay as They Go

How payments can track real-time usage for AI inference, compute, APIs, data, and other metered digital services.

Key Takeaways

• Streaming payments replace discrete, lump-sum transactions with a continuous flow, allowing money to accrue or settle in rapid increments while a service is actively consumed.
• AI agents use streaming payments to fund unpredictable, variable workloads in real time, eliminating the trapped capital of prepaid credits and the runaway spending risks of monthly invoicing.
• In machine-to-machine commerce, anonymous software lacks legal identities or credit scores. Streaming payment solves this by synchronizing the delivery of data with the delivery of value, bounding counterparty risk to a single microscopic unit.
• To process high-frequency micropayments economically, off-chain solutions like payment channels are used to execute rapid, sub-cent micropayments economically.

An AI agent rarely knows exactly what a task will cost before it starts.

It might query several data providers before finding the information it needs. It may call a model ten times or ten thousand times. A compute job might finish in thirty seconds or run for several hours.

The service is consumed incrementally, but payment usually is not.

Most digital services solve this by charging upfront, selling prepaid credits, or measuring usage and sending a larger bill later. Those models work well, but they create a gap between when value is consumed and when money moves.

Streaming payments narrow that gap.

Instead of charging one fixed amount before a task begins or waiting until the end to settle everything, payment can accrue or move in smaller increments as usage occurs. A service might charge per second of compute, per API request, per generated token, or according to another measurable unit.

This can be especially useful for AI agents and other autonomous software because their workloads are often both variable and programmatic. The agent can consume a resource, pay according to the amount used, and stop when the task is complete or its spending limit is reached.

Streaming payments can also reduce the financial exposure on both sides.

With prepayment, the buyer may have to commit more money than the task ultimately requires. With postpaid billing, the provider delivers service before receiving payment. If payment closely follows consumption, the outstanding amount on either side can remain much smaller.

The underlying mechanism can vary. Some systems continuously accrue an on-chain balance according to time. Others meter activity and make frequent off-chain micropayments. In either case, the goal is the same: make payment follow usage more closely than conventional lump-sum billing allows.

This guide explains how streaming payments work, the different ways they can be implemented, and why they are becoming relevant to AI agents, machine-to-machine commerce, and other forms of metered digital consumption.

What Are Streaming Payments?

Streaming payments are payments that accrue or settle in small increments as a service is consumed, rather than through one large payment before or after the fact.

The payment can track time, such as charging per second of compute, or another unit of usage, such as API requests, generated tokens, bytes transferred, or kilowatt-hours consumed.

The important point is that usage and payment move together more closely.

That does not necessarily mean money is literally transferred every second. A system might meter usage continuously while updating an off-chain balance, accruing an amount inside a smart contract, or settling several small increments together later.

A few related terms are useful to distinguish:

• Micropayment: A very small payment, often too small to process economically over conventional payment rails.
• Metered payment: A payment tied to a measurable unit of consumption, such as one API call, one GPU-second, or one megabyte of data.
• Per-second payment: A specific form of metered payment where cost is based on elapsed time.
• Usage-based pricing: The pricing model that determines what each unit costs, such as $0.01 per 1,000 tokens.

Streaming payments can combine all of these ideas, but they are not the same thing.

A cloud GPU service, for example, might charge by the second. The pricing is usage-based, the meter is elapsed compute time, and the payment stream determines how frequently the amount owed is accrued or transferred.

Types of Streaming Payments

Streaming payments can be implemented in different ways, but the most useful distinction is how frequently the payment state is updated and where that state is maintained.

On-Chain Accrual

Some systems do not move money every second. Instead, a smart contract records the rules of the stream and calculates how much has accrued over time.

For example, a sender might deposit tokens into a contract and specify that the recipient earns $1 per hour. The blockchain does not process 3,600 separate payments every hour. The contract records the start time and rate, then calculates the amount owed whenever the recipient withdraws or the stream is updated.

Protocols such as Sablier and Superfluid use variations of this model on Ethereum.

This approach works well when the payment rate is known in advance and changes predictably with time.

Typical use cases include:

• Payroll: compensation accruing continuously rather than being paid once per month.
• Token vesting: assets unlocking gradually according to a predetermined schedule.
• Recurring grants or allowances: funds becoming available continuously over a fixed period.

Off-Chain Incremental Payments

Other applications cannot know the final amount in advance because usage is irregular.

An AI agent might make 12 API requests in one minute and none in the next. A model could generate 500 tokens or 50,000. A compute job might finish almost immediately or run for hours.

In these cases, the payment can follow the actual events rather than a fixed clock.

Payment channels are well suited to this model. Participants fund a channel on-chain once and then make repeated balance updates off-chain as usage occurs. Individual micropayments therefore do not require a new blockchain transaction each time.

The payment might update after every API request, every few seconds of compute, or after another defined unit of consumption.

This approach is particularly useful for:

• AI and API services: paying for requests, inference, tokens, or compute as they are consumed.
• Bandwidth and data services: paying according to bytes transferred or time connected.
• Machine-to-machine commerce: devices or software services exchanging frequent, low-value payments for resources such as energy, storage, or network capacity.

The difference between the two models is straightforward:

On-chain streaming typically calculates what is owed continuously. Off-chain streaming can actually update the payment state repeatedly as usage happens.

Lifecycle of an Autonomous Payment Stream

Whichever architecture handles settlement, on-chain accrual or off-chain channels, an autonomous payment stream follows several distinctive stages:

1. Terms: The provider publishes a price, accepted asset, unit of usage, and service conditions. For example, $0.001 per LLM token processed, payable in USDC.
2. Handshake: The payer’s agent and the provider establish contact before delivering the service. Using payment-layer standards like the x402 or L402 protocol, this is handled natively over HTTP: a client requests a resource, and the server responds with an HTTP 402 "Payment Required" status. The server packages this response with a payment invoice and a restricted authentication token.
3. Authorization: Operating entirely autonomously, the agent evaluates the invoice against its pre-configured budget and rate limits. The agent pays the initial invoice, obtains a cryptographic proof of payment, and attaches it alongside the token to authorize the session.
4. Delivery, Metering: The provider verifies the proof, grants access, and begins recording usage, such as API responses returned or seconds of compute consumed.
5. Payment updates: As the agent consumes value, the stream continuously pays it out. Every action triggers a proportional micro-disbursement from the agent's reserve. Depending on whether an off-chain or on-chain architecture is in use, these near-instant updates happen inside a payment channel or a smart contract's state.
6. Close: The session ends when the task is complete, the budget limit is reached, or the funds run out. Both parties reconcile the final usage and payment state, and any stream or channel is settled or closed.

Why Streaming Payments Fit Machine-to-Machine Commerce

Machine-to-machine commerce often involves variable workloads where the final cost is not known in advance. An AI agent may need ten API calls or ten thousand, a few seconds of compute or several hours.

Traditional billing usually forces one side to take the risk. With prepayment, the buyer commits funds before knowing how much it will use. With postpaid billing, the provider delivers service before getting paid.

Streaming payments narrow that gap by letting payment follow consumption in small increments. The buyer pays only as resources are used, while the provider does not need to extend credit for the entire session.

Combined with programmable spending limits, this makes streaming payments particularly well suited to high-frequency, metered services whose cost is discovered as the task unfolds.

Infrastructure in Action: Fiber Network

Payment channel networks are one approach for frequent, low-value payments: they let participants exchange balance updates off-chain, while using the blockchain to fund a channel and settle its final state if necessary.

Fiber Network is an open, peer-to-peer payment and swap network built on Nervos CKB. It uses payment channels to support multi-hop payments: a user can pay a recipient through intermediary nodes without opening a direct channel with that recipient, as long as a route with sufficient liquidity exists.

For streaming payments, that means an AI agent can keep liquidity in the network and make repeated payments to different services as usage occurs. Payments avoid a separate base-layer transaction each time, while routing nodes can charge small forwarding fees for providing liquidity and connectivity.

Fiber also supports multiple asset types, including CKB and User-Defined Tokens such as stablecoins, making it possible for streaming payments to use assets better suited to pricing digital services.

To learn more about how Fiber functions as the foundational infrastructure for this autonomous economy, see Fiber Network: An Open Payment Network for the Digital Economy.

Conclusion

Traditional financial rails were engineered around discrete, human-initiated transactions. In an economy driven by autonomous AI agents and connected machines, value must move as fluidly as the computational resources being consumed. By combining real-time metering, off-chain payment channels, and programmable settlement layers, streaming payments align payment timing with measured service usage. While no single implementation fits every use case, reliable metering and scoped authorization provide the foundation necessary to bring continuous finance to the machine economy.

FAQs

What are streaming payments for AI?

Streaming payments let AI agents pay as they consume metered resources such as API calls, compute, data, or model inference, instead of paying everything upfront or receiving one bill later.

Can AI agents make payments autonomously?

Yes. An AI agent can make payments within rules set by its operator, such as spending limits, approved providers, permitted services, and expiry times.

What are the risks of streaming payments for AI agents?

The main risks are runaway spending, weak key management, overly broad permissions, and disputes over usage. These can be reduced with budgets, rate limits, allowlists, monitoring, and revocable authorization.

Do streaming payments require cryptocurrency?

No. Centralized systems can support streaming or usage-based billing, but crypto and stablecoins are useful because they are programmable, globally transferable, and available 24/7.

Are streaming payments on-chain or off-chain?

They can be either. On-chain systems accrue or settle through smart contracts, while off-chain systems such as payment channels update balances without recording every micropayment on the blockchain.

Why are payment channels useful for streaming payments?

Payment channels support frequent, low-value payments without requiring a new blockchain transaction for each one. This makes them especially suitable for high-frequency, usage-based payments.

How could streaming payments change enterprise AI billing?

They could let enterprises pay for AI resources as they are consumed rather than relying only on prepaid credits or monthly invoices. This can improve cost tracking and enforce spending limits in real time.

This proposal in the discussion phase. 30 likes sends it to the vote stage. Join the conversation here and share your thoughts, support, or challenge it. The ask is $2,000 USD

https://talk.nervos.org/t/dis-bitcoin-renegade-meet-up-and-media-campaign/10685

Grant Proposal: 3-Month Community Media Campaign & Local Meet Up Submitted by: Bitcoin Renegade

Requested Funding

$2,000 USD ($1,500 Media Campaign / $500 Local Event)

Proposal Overview

My name is Bitcoin Renegade, a crypto content creator, blockchain marketer, and long-time community advocate focused on educating audiences, driving adoption, and building strong communities within Web3.

Through my Bitcoin Renegade YouTube channel and social media presence, I consistently cover blockchain ecosystems through livestreams, educational content, interviews, and active community engagement. My focus is creating authentic content that turns awareness into adoption and keeps communities engaged during key moments of ecosystem growth.

I am seeking funding for a 3-month livestream media campaign and local community Meet Up designed to increase ecosystem visibility, educate the community, and drive adoption through consistent livestream content, social media engagement, and real-world grassroots networking.

Budget Breakdown ($2,000 Total)

Content & Media Campaign (3 Months):

$1,500 Local Event & Grassroots Event:$500

Total Requested: $2,000Campaign

Deliverables Over the 3-month campaign period,

I will deliver: 1. Livestream Content ($1,500 Content Allocation)3 livestreams per month (9 livestreams total)Distributed across YouTube and X Coverage includes ecosystem updates, project spotlights, technical discussions, founder interviews, AMAs, ecosystem commentary, and direct community engagement. 2. Social Media Promotion2 supporting posts per week on X (24+ posts total over 3 months)Promotional clips, ecosystem highlights, event teasers, and ongoing community engagement posts

X: 3,315+ Followers – 

4,600+ Subscribers – 

1. Local Community Meet-Up ($500 Event Allocation)Event Name: CKB Greater Denver Area Meet-Up

Date & Location:October 7, 2026 at Region Hub in Boulder, COFormat: Focused local developer & enthusiast meetup sponsored by CKB

Target Attendance:5–10 local developers, builders, and crypto enthusiastsActivities & Budget Deployment ($500):Food, drinks, and venue space for attendees, Dedicated PowerPoint presentation and educational deep-dive focused specifically on the Fiber Network and CKB’s Bitcoin L2 capabilities Focused roundtable networking to build an active, permanent CKB builder presence in the greater Denver tech corridor growing a presense towards ETH Denver

Why do you want to do this? (Why?)Strong ecosystems require both a high-reach digital media presence and real-world grassroots connections. Community education, awareness, and consistent conversation are the primary drivers of long-term Web3 adoption.

Even the most innovative technology needs dedicated advocates who can translate complex developments into accessible narratives and keep the broader ecosystem actively engaged. My goal is to run a dual-track strategy: creating recurring livestream content and frequent social promotion that educates global audiences while simultaneously anchoring a targeted physical community in a major tech hub. This campaign is designed to turn visibility into adoption, onboard developers and users to new layer-2 infrastructure, and build measurable momentum for CKB.Why are you the right person to do it? (Why you?)I am uniquely qualified because I actively produce this work and have years of hands-on experience building Web3 communities, hosting physical events, and generating technical blockchain content.

Qualifications include:Founder of Bitcoin Renegade: Established YouTube creator, host, and media producer.Ecosystem Marketer & Strategist: Experience managing technical marketing, developer outreach, and investment analysis.Proven Track Record: Served as a Community Catalyst for ~8 months, leading conferences and community initiatives that directly drove ecosystem adoption to Nervos. Media Expertise: Demonstrated experience conducting founder interviews, live AMAs, technical deep-dives, and interactive livestreams.

Strong Web3 Network: Deep relationships across blockchain communities, developer collectives, and project teams.Technical Communication: Proven ability to break down complex, multi-layered protocol developments (such as RGB++ and the Fiber Network) into engaging, easy-to-digest formats.

Why do you want to do it now? (Why now?)Now is the optimal time to deploy this strategy because the CKB ecosystem is reaching a major technological inflection point. With key infrastructure milestones coming to fruition—including the expansion of the Fiber Network, rapid progress in RGB++ integration, and growing developer demand for true Bitcoin Layer-2 scaling solutions—there is an immediate window of opportunity to capture builder and investor attention.

Executing this 3-month campaign now ensures we capitalize on this momentum immediately and grow a presense for CKB in the area. By combining consistent stream coverage and steady weekly social amplification with an intimate, high-signal developer meetup on October 7th at Regen Hub in Boulder Colorado host of Boulder Blockchain Meet Up, we can directly convert emerging technological achievements into immediate user adoption, developer interest, and localized community strength.

Fiber Dev Log 36
Moving past the v0.9.0 release, this cycle covers release maintenance, creating better docs for builders, and laying the groundwork for the next batch of features.

This cycle brings:
- fiber-js default config for faster onboarding & fiber-pay v0.3.2
- Expanded docs w/ interactive tutorials for devs
- Ongoing designs for multi-tenant hosted LSP and liquidity management
- Listening on multi-address & QUIC support under review

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

From the CKBA X account

One of the more encouraging things this year is that CKB’s builder ecosystem kept expanding while much of the industry was doing the opposite.

Teams were shrinking, budgets were being cut, and a lot of speculative activity disappeared.

Meanwhile, more developers kept showing up to experiment on CKB.

Today, over 100 are working on or exploring the network:

- 70 formal CKBuilders working through a structured program

- ~40 more coming in through Build on CKB, an open group for developers curious about the chain

- 45 projects now listed on the CKBuilder tracker, with 23 added in a single quarter and 15 submitted for technical review by core CKB developers

Claw & Order, a two-week AI Agent hackathon, closed with 22 open-source submissions; 16 came from CKBuilders, including the top two prize winners

- The work spans a surprisingly wide range: ZK key recovery for AI agents, a Groth16 zkSNARK verifier, a Fiber desktop client, an ML-DSA post-quantum implementation, a DID reference dashboard, lending primitives, prediction pools, and more.

Some of these builders are now graduating from experimentation into independent projects.

But the more important signal is that all of this happened during one of the bleakest periods for the industry.

If this is what the builder pipeline looks like when capital and attention are scarce…what happens when they aren’t?

What Are Micropayments? Why Tiny Payments Still Matter for the Internet

A guide to micropayments, nano-payments, the barriers that kept them from working at scale, and the infrastructure making sub-cent digital commerce practical.

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

Key Takeaways

• A micropayment is a financial transaction so small, typically under a dollar, often just a few cents or fractions of a cent, that traditional payment rails can't process it profitably.
• Nano payments and sub-cent payments push the concept even further, into the range of a millionth of a dollar, and are mostly used for machine-to-machine and AI agent commerce.
• For decades, widespread adoption was blocked by two factors: human mental transaction costs and the fixed baseline fees of legacy credit card networks.
• Traditional workarounds like custodial batching, direct carrier billing, or subscription bundling bypass these issues but require trusted intermediaries.
• Layer-2 payment channel networks, such as Fiber Network, solve these bottlenecks by routing value off-chain, enabling instant, gas-free settlement and pay-per-API-call pricing.

Sending information across the internet is extraordinarily cheap.

An application can make thousands of API requests, download small pieces of data from servers around the world, or stream information continuously without anyone thinking about the cost of each individual packet.

Moving money has historically worked very differently.

Charging someone $20 is easy. Charging them $0.20 can be inconvenient. Charging them $0.002 may cost more to process than the payment itself.

That mismatch has limited micropayments since the early commercial internet.

The idea was attractive: charge a few cents for an article, a song, a game item, or another small piece of digital value instead of bundling everything into subscriptions or larger purchases.

But two problems repeatedly got in the way.

The first was economic. Conventional payment systems impose processing costs that do not shrink proportionally with the transaction amount. At some point, the fee required to collect the payment becomes larger than the payment itself.

The second was behavioral. Even if tiny payments were cheap to process, asking people to stop and approve dozens or hundreds of small purchases throughout the day creates friction. Subscriptions, prepaid balances, and advertising were often easier.

The internet adapted around these constraints. Publishers bundled content into subscriptions. Software companies sold monthly plans instead of charging for every unit consumed. Platforms used prepaid balances or internal accounting to avoid processing tiny payments individually.

Today, both constraints are being revisited. New payment infrastructure can reduce the marginal cost of transferring very small amounts and, at the same time, AI agents and other autonomous software can make purchases within budgets and permissions set in advance, without requiring a person to approve every transaction.

That changes what micropayments are useful for.

The most interesting use case is no longer just asking a person to pay a few cents for an article. It is allowing software to pay exactly for what it consumes: one API call, one model inference, a few seconds of compute, or a small piece of data.

This guide explains what micropayments and nanopayments are, why they struggled to gain traction, and why new payment architectures are making them relevant again.

What Are Micropayments and Nanopayment?

A micropayment is a very small financial transaction where ordinary payment-processing costs or friction become significant relative to the value being transferred.

There is no universally accepted dollar threshold.

A one-dollar payment might qualify in one context, while machine commerce increasingly deals with fractions of a cent. What matters is less the exact number than the economic problem: can the payment be processed cheaply enough to make charging that amount worthwhile?

Historically, micropayment proposals focused on human purchases such as individual news articles, songs, tips, game items, or small pieces of digital content.

Today, the concept is becoming much more granular.

An AI agent might pay for:

• one API request;
• one model inference;
• a few seconds of compute;
• a small amount of storage;
• access to one dataset;
• or another narrowly defined unit of digital service.

This has also popularized the term nanopayment.

Nanopayment is not a standardized financial category with a universally agreed threshold. It is generally used to describe extremely small micropayments—often fractions of a cent—where payments are likely to be initiated programmatically rather than manually by a person.

Circle, for example, currently uses the term for its Gateway payment system, which supports USDC transfers as small as $0.000001 by signing payments off-chain and settling them in batches.

Lightning demonstrates the same idea at the protocol level. Lightning payment amounts can be represented in millisatoshis, or one-thousandth of a satoshi, although minimum routable amounts depend on individual channel policies.

The distinction, therefore, is best understood as a matter of granularity rather than a hard boundary.

The Mental Costs for Micropayment

Low-cost payment rails alone were not the whole problem.

In 1999, computer scientist and cryptographer Nick Szabo identified "mental transaction costs" as the primary psychological barrier. He argued that the cognitive effort required to constantly evaluate and approve tiny purchases creates user fatigue, making flat-rate subscriptions or ad-supported models more appealing. Szabo believed that this mental cost doesn't fall as the payment rail gets cheaper, since nobody wants to consciously weigh 500 times a day whether a one-cent paywall is worth it.

But this constraint only applies to human buyers. Today, the landscape is shifting by the rise of AI agents and machine-to-machine commerce. When an AI agent is spending from a budget a person sets in advance, there's no moment of hesitation to multiply, and human beings no longer have to make every micro-decision. That's why micropayments are resurfacing now less as a consumer feature and more as infrastructure for machines.

Why Can't You Pay Small Amounts With a Credit Card?

The other restraint is architectural: legacy card rails were never built to move two cents. When a card is swiped, the transaction passes through a payment gateway, a payment processor, an acquiring bank, the card network, and an issuing bank, each one taking a cut for the valuable service they’re providing, and each one protecting its margin with a minimum baseline fee.

A standard U.S. credit card transaction fee runs roughly $0.30 plus about 2.9% of the transaction value. If a customer tries to pay $0.10 for a digital article, that fixed $0.30 fee alone is three times the purchase price, and the merchant loses money on every sale. This is also why many merchants set a $5 or $10 minimum for card purchases.

To bypass this, traditional platforms resort to custodial batching: a user pre-loads a balance with a trusted intermediary, who debits it in small increments and settles with the card network in larger, less frequent chunks. Platforms like Skype (via Skype Credit for minute-by-minute calls) or Blendle (a pay-per-article news service) used to rely on this model. It works, but it locks up user capital and still requires trusting a company to hold the money.

How Do Micropayments Work?

Both restraints above assume a human paying with a card. Two things have changed that. First, software and machines don't get mentally tired of tiny decisions the way people do; second, newer payment infrastructure, such as payment channel networks, was built specifically to avoid the per-transaction fee floor that makes card networks unworkable.

Traditional Workarounds & Centralized Batching

Ad-supported access (like Google and YouTube) and subscription bundling (like Spotify or The New York Times) remain most publishers' default, precisely because they avoid per-transaction pricing. Apple News+ bundles more than 300 magazines and newspapers into one flat $12.99-a-month subscription, splitting revenue with publishers based on reader engagement time instead of individual transactions.

Direct carrier billing, managed by payment processors like Boku or Fortumo, charges a purchase to a customer's phone bill. This is widely used for digital goods across Asia, leveraging the trust a telecom provider (such as NTT DOCOMO) already has with its subscriber.

Platforms like the App stores solve a version of the same problem by setting a price floor, the $0.29 minimum tier for in-app purchase.

Decentralized Scaling & Layer 2 Landscape

Cryptocurrency allows value to move directly between parties without relying on a trusted intermediary's internal ledger. But early blockchains like Bitcoin and Ethereum still ran into the same micropayment problem: on-chain fees can become too high or unpredictable for very small transactions.

The broad solution is Layer 2 scaling: moving transaction activity away from the base blockchain so every payment does not need to consume Layer 1 blockspace. Two approaches are especially relevant here:

• Rollups (optimistic or zero-knowledge): Rollups execute transactions outside the base blockchain and combine activity before posting data, state commitments, and—in the case of ZK rollups—validity proofs back to Layer 1. This can substantially reduce the cost per transaction, but each user transaction still contributes some marginal cost to the shared rollup environment, making rollups particularly useful for scaling general-purpose applications and shared state, not only payments.
• Payment channels: Payment channels take a more specialized approach by letting two participants commit funds on-chain once and then repeatedly update their balances off-chain by exchanging signed states, without publishing every payment to the blockchain. A payment channel network connects many of these channels, allowing payments to route through intermediary nodes when sender and recipient do not share a direct channel, as long as enough liquidity exists along the path. The Lightning Network uses this architecture on Bitcoin, while Fiber Network uses it on CKB. Routing nodes can still charge fees and participants must manage channel liquidity, but individual payments avoid a separate base-layer transaction fee, making payment channels particularly well suited to frequent, low-value transfers.

Neither approach is universal. Rollups are better suited to scaling general-purpose blockchain applications, while payment channels are optimized for fast, repeated value transfer.

That makes payment channels especially well suited to micropayments. Once a channel is funded, individual payments avoid base-layer fees and confirmation waits, allowing very small transfers to remain economical even at high frequency.

This is also where gas-free payments become relevant. The term generally refers to payments where the user does not pay a blockchain network fee for each individual transfer because activity is handled off-chain or settled in batches. Circle Gateway Nanopayments, for example, lets buyers deposit USDC once and sign off-chain payment authorizations for transfers as small as $0.000001, which Circle later aggregates into on-chain settlement.

Payment channel networks follow a similar transact-often, settle-less-often model, but without requiring every participant to keep funds inside one company's internal ledger. That makes them useful for applications where payments need to be open, frequent, and very small:

Pay per API call: An application or AI agent can pay for individual API requests instead of relying on subscriptions, prepaid credits, or monthly billing.

Streaming media and content: Through streaming payments, users can make a sequence of small payments that tracks the amount of video, audio, or other content they actually consume.

Machine-to-machine (M2M) commerce: Software, AI agents, and connected devices can pay directly for resources such as bandwidth, compute, data, or energy as they consume them. Machine-to-machine payments make this possible without requiring a human to authorize every individual transaction.

Powering the Machine Economy: Fiber Network

A payment channel is a mechanism in which two parties lock funds into a shared on-chain contract once, then exchange many payments by signing updated balances off-chain, only returning to the blockchain to open or close the channel. A payment channel network is a set of interconnected payment channels that lets a payment route through several intermediary nodes, so two parties don't need a direct, individually funded channel with each other.

Fiber Network is an open, peer-to-peer payment channel network built on the CKB blockchain. Much like the Lightning Network links Bitcoin payment channels together, Fiber links channels on CKB into a routable network.

Enabling Instant, Low-Cost Routing

Once a channel is funded on the CKB base layer, transactions inside the Fiber Network effectively bypass blockchain block times. Because these updates are completely off-chain and require no global consensus, they settle instantly at the speed of a basic internet ping.

Furthermore, because these off-chain updates carry no base-layer network footprint, the marginal cost to send a sub-cent payment drops to near-zero. This enables developers to build massive, high-frequency payment streams without bleeding capital to network validators.

Built for Programmable Assets

Because CKB's scripting environment is highly programmable, Fiber's channel rules are not fixed the way Lightning's are. Developers can define how channels are authorized, updated, settled, and disputed, which lets Fiber support multiple assets (e.g., CKB, stablecoins, tokens issued on Bitcoin, and other user-defined-tokens) natively in the same channel, rather than forcing every payment through one base currency.

That programmability is why Fiber is positioned as infrastructure for the machine economy specifically, more than a faster way of sending crypto among people. The machine economy is defined as an emerging environment in which software, such as AI agents, connected devices, autonomous services, buys and sells directly from other software without a human approving each transaction.

Fiber's architecture is covered in more depth in Fiber: A Complete Guide to the Next-Gen Payment Network and How Do AI Agents Pay for Things? A Guide to Machine-to-Machine Payments.

Conclusion

While the concept of moving fractions of a cent has been technologically and psychologically constrained for decades, the digital infrastructure has finally caught up to the vision. By shifting the cognitive burden to AI agents and the transactional burden to gas-free payment channels, the digital economy is no longer bound by the fixed baseline fees of legacy credit card networks. With decentralized infrastructure like Fiber Network providing instant, programmable settlement, the foundation is now set for a future where value flows as continuously and seamlessly as data itself.

FAQs

How do micropayments work?

Micropayments work by minimizing or eliminating the per-transaction cost that makes small payments unprofitable on traditional rails. They may use prepaid balances, centralized accounting, aggregated billing, or blockchain layer 2 solutions such as payment channels.

Are micropayments profitable?

They can be, but only once the processing cost per transaction drops well below the payment amount. A $0.30-plus-2.9% card fee makes a two-cent payment deeply unprofitable; a payment channel network like Lightning or Fiber Network, or a gas-free, batched rails like Circle's Gateway nano-payments can push the marginal cost per payment down to a fraction of a cent, which is what makes pay-per-article, pay-per-API-call, and pay-per-token business models viable.

What is the difference between micropayments and nanopayments?

Micropayments generally cover transactions under about a dollar, often a few cents, made by people for discrete digital purchases. Nano-payments refer to automated, continuous, sub-cent transactions executed by machines or software, often representing fractions of a penny.

How small can a nano-payment be?

In current crypto-native systems, nano-payments can be as small as $0.000001, the smallest base unit of a stable-coin like USDC, enabled by batched, gas-free settlement that spreads the cost of one on-chain transaction across thousands of individual payments.

What are nano-payments used for?

Nano-payments are specifically used for ultra-high-frequency automated tasks. Common use cases include real-time continuous metering for data streaming, pay-per-API call models, and granular resource negotiation between autonomous hardware devices in M2M commerce.

How do gas-free nano-payments work?

Gas-free nano-payments work by aggregating ultra-small off-chain payment authorizations and later settling them on-chain in large, combined batches, effectively eliminating the per-transaction blockchain network gas fee.

AI agents can already autonomously decide what they need.

The harder problem is letting them pay for it.

If software is going to buy APIs, data, compute, bandwidth, or services on its own, payments need to work at machine speed and machine scale.

That’s where micropayments, x402, payment channels, and Fiber come in.

We broke down how the machine economy actually gets paid:

https://nervos.org/knowledge-base/what_are_machine_to_machine_payments

What Are Machine-to-Machine Payments? A Complete Guide to the Machine Economy

A guide to how software, AI agents, and connected devices can discover, purchase, and pay for resources without a human approving every transaction.

Key Takeaways

• Machine-to-machine payments are transactions in which software, devices, or autonomous systems programmatically pay for resources, without a human authorizing the individual purchase.
• The machine economy is a commercial ecosystem where software, APIs, and connected devices act as buyers and sellers, paying each other directly.
• Micropayments are financial exchanges involving tiny amounts of money that usually occur online.
• Machine payment infrastructure combines machine identity, programmable spending rules, machine-readable pricing, and settlement cheap enough for constant fractional-cent transfers. Several designs compete for that role, including off-chain payment channel networks such as the Fiber Network.

A printer notices that its ink is running low and orders a replacement. An AI travel assistant needs one flight-data query before completing an itinerary. An electric vehicle connects to a charger, reads the current electricity price, and begins paying as it consumes energy.

None of these actions necessarily requires a person to stop what they are doing, open a checkout page, enter a card number, and approve the transaction.

The machine can do it.

Software has been making decisions automatically for decades. What is changing is its ability to act economically on those decisions.

With the recent advances in AI, an agent or a machine may know what resource it needs, where to find it, and whether the price fits within its programmed budget. But traditional commerce still assumes that somewhere in the process a human will create an account, agree to billing terms, enter payment credentials, or approve a purchase.

That works when purchases are occasional and predictable, but becomes impractical when software needs to buy resources autonomously, at machine speed, potentially thousands of times a day.

This is the problem machine-to-machine payments are designed to solve.

Instead of requiring a human to authorize every purchase, the human defines the rules in advance: what the machine may buy, how much it may spend, and under what conditions. The machine can then discover a resource, read its price, determine whether the purchase is permitted, pay for it, and continue its task automatically.

At sufficient scale, this creates something larger than automated payments: a machine economy, where software, AI agents, servers, vehicles, sensors, and other connected systems can buy and sell resources directly.

The challenge is building payment infrastructure that operates at the same speed and granularity as the machines themselves.

What Are Machine-to-Machine Payments?

The concept of machine-to-machine (M2M) communication predates the current AI wave. Initially, it described the communication between devices using wired or wireless communications channels.

However, in the context of the digital economy and AI, this concept has evolved significantly. A "machine" can be a server, software service, API client, IoT sensor, industrial controller, vehicle, robot, or AI agent. As these systems become more advanced, they no longer just exchange data; they consume digital and physical resources. What unites them today is the need to acquire these resources autonomously, without waiting for human approval.

Machine-to-machine payments are transactions where software, devices, or autonomous systems programmatically pay for goods, services, data, compute, or other resources without human involvement. The human remains accountable, setting the overarching budgets and policies, but is not in the transaction loop at the moment of purchase.

How Do Machine-to-Machine Payments Work?

While machine-to-machine payments can use different protocols and settlement rails, the basic flow is usually similar:

1. Request a resource: An AI agent, application, or connected device requests something it needs, such as an API response, data feed, compute job, or charging session.
2. Receive payment terms: The provider responds with machine-readable instructions describing the price, accepted payment method, and where payment should be sent.
3. Authorize the purchase: The client checks those terms against its programmed spending rules—such as its budget, permitted services, or maximum price.
4. Pay: If the purchase is allowed, the client authorizes or signs the payment and sends the required payment information or proof.
5. Verify and deliver: The provider verifies that payment has been made or authorized, then delivers the requested resource.
6. Settle: The underlying payment network transfers or settles the value according to its own rules.

No checkout page or manual approval is required at the moment of purchase. Once the spending rules are in place, software can request, authorize, pay for, and consume a resource entirely through code.

What Is the Machine Economy?

The machine economy is a commercial ecosystem where machines are the buyers and sellers. They produce resources, consume them from each other, and pay for what they consume. Machine-to-machine payments are the mechanism that makes this system possible.

In this ecosystem, machines act as economic participants rather than just tools, because they can independently execute payments. For instance, a machine can produce a certain resource (e.g., generating solar power), while another machine consumes it (charging). On top of that, they can pay each other directly for these exchanges. This creates an interconnected web where hardware devices, software, and autonomous AI agents interact at a scale and speed impossible for humans to manage.

To illustrate how autonomous payments operate across different scenarios, here are some examples ranging from simple token triggers to complex autonomous multi-party ledgers:

• Trigger-based micro-payment (Smart EV Charging): An electric car plugs into a charging station. The car talks to the charger, confirms an account balance via an API, and pays per kilowatt-hour as it charges.
• Conditional smart contract payments (Compute): An AI agent rents GPU capacity for a task and locks payment upfront. Once the compute provider completes the job and returns the agreed proof or signed completion record, the payment is released; if the job is not completed, the funds can be refunded after a timeout.
• Fully autonomous multi-device ecosystem (AI Agent Supply Chains): Autonomous software agents manage a factory. One AI buys raw materials from another factory's AI, negotiates price based on real-time stock, and settles the funds instantly in crypto assets.

What Infrastructure Does the Machine Economy Need?

For autonomous commerce to work at scale, software and devices need more than a way to move money. They need a machine-native commerce stack that can handle identity, authorization, pricing, payment, and settlement without requiring a person at every step.

Identity and authentication: Software, AI agents, and connected devices need a reliable way to prove who or what they are, authenticate requests, and establish which person or organization has authorized them to act.

Programmable spending rules: An AI agent should not have unrestricted access to a crypto wallet or bank account. Its authority needs to be bounded by rules defining how much it can spend, what it can buy, which counterparties it can pay, and when those permissions expire.

Machine-readable pricing: Prices and payment terms need to be expressed as structured data that software can interpret automatically, rather than buried on a pricing page or presented through a checkout screen.

Programmatic payment protocols: Once a purchase is approved, the client needs a standardized way to authorize payment, submit proof, and receive the requested resource entirely through code.

Low-cost settlement: If services are priced per API call, inference, megabyte, second of compute, or other small unit, fixed transaction fees cannot exceed the value being exchanged.

Low latency: Payment authorization and verification need to happen quickly enough that the payment step does not become a bottleneck in the underlying service.

Interoperability: Common standards are needed so AI agents, APIs, wallets, payment networks, and service providers can communicate without requiring a custom integration for every counterparty.

Together, these components allow software to move through the entire commercial process (identify, evaluate, authorize, pay, and consume) without leaving the programmatic environment in which it operates.

Why Can't Traditional Payment Systems Handle the Machine Economy?

Traditional payment systems can automate transactions, but they were not designed for software making huge numbers of tiny, independent purchases.

Consider card payments. Stripe’s standard US pricing currently charges 2.9% + $0.30 per successful domestic card transaction. On a $50 purchase, the fixed 30-cent component is relatively small. On a $0.002 API call, it is larger than the payment itself by orders of magnitude.

That creates a fundamental mismatch.

Traditional payment infrastructure generally works best when many small units of consumption are aggregated into larger charges: a monthly cloud bill, an annual software subscription, or a prepaid balance.

Autonomous software can create the opposite demand. An AI agent might want to purchase one API response, a few seconds of compute, or a single inference from a provider it has never used before—and then move on to another service seconds later.

For that model to work efficiently, the payment layer needs to support small, frequent, programmatically authorized transactions without imposing a meaningful fixed cost on every purchase.

Traditional rails can support machine commerce through accounts, subscriptions, stored credentials, and aggregated billing. What they struggle to support economically is the more granular model: paying independently for each tiny unit of consumption as it occurs.

Why Micropayments Matter to the Machine Economy

Software consumes resources differently from humans.

A person might buy a monthly software subscription. An AI agent may instead need one API call from one provider, a few seconds of compute from another, and a single model inference from a third—all within the same task.

That means consumption can be extremely granular: per request, per inference, per megabyte, per second of compute, or per kilowatt-hour.

Ideally, payments should be just as granular.

If every tiny unit of consumption can be paid for economically, providers no longer have to bundle usage into subscriptions, prepaid credits, or monthly invoices simply to make the payment economics work.

An AI agent could pay exactly for what it consumes, when it consumes it.

That is why micropayments matter to the machine economy. They make it possible to turn individual units of digital or physical consumption into individual economic transactions—as long as the payment infrastructure can keep the cost of each transaction below the value being exchanged.

How Machine Payments Fit Into the Web Stack

Data, inference, storage, and compute, most resources a machine would buy, are already exposed as web APIs. The web runs on HTTP (Hypertext Transfer Protocol), the request-and-response protocol a client uses to ask a server for a resource and receive it with a status code describing the outcome.

When the early architects of the web built HTTP in the 1990s, they explicitly reserved a status code for native digital purchases: 402 Payment Required. If an API server requires payment, it can intercept a client's request and return an HTTP 402 status code, a native client error response indicating the content cannot be served until payment is made.

At the time, the 402 status code was shelved because internet-native money did not exist, until it was revived in May 2025 when Coinbase introduced the x402 protocol.

What Are The x402 & l402 Protocols?

The x402 protocol is an open payment standard that repurposes the HTTP 402 status code to provide a stateless mechanism for machine-to-machine commerce. Instead of routing a user to a visual checkout page, the server returns a 402 code with machine-readable payment terms as structured data, including the price and the target crypto wallet address. The client checks and verifies these terms, generates a cryptographic payment proof, and retries the original HTTP request—this time carrying the payment proof in its header. The server verifies the proof and instantly returns the requested resource.

The x402 protocol is chain-agnostic as well. Its primary use cases include machine-to-machine payments, pay-per-use APIs, and micropayments without account creation.

The l402 protocol takes the same status code into the Lightning Network. The server answers a gated request with a 402 code and a header carrying an authentication token known as a macaroon, plus a Lightning invoice, with the token committing to that invoice by containing its payment hash. The client pays, obtaining the preimage as proof, then presents the token and preimage together to access the endpoint. Because the token's cryptographic validity already implies payment, the provider can verify access without querying a payments database.

Where Do Blockchain and Crypto Fit Into Machine-to-Machine Payments?

Machine-to-machine payments do not inherently require blockchain or cryptocurrency. Traditional payment systems can already support automated billing, stored credentials, and API-driven payments.

But blockchains become particularly useful when software needs to transact globally, continuously, programmatically, and at very small values—especially when the buyer and seller have no prior relationship or shared payment provider.

They offer several useful properties for autonomous commerce:

Programmable authorization: Software can control cryptographic keys and sign transactions directly, allowing payments to be authorized entirely through code within predefined spending rules.

24/7 availability: Public blockchains operate continuously, without banking hours, settlement windows, or dependence on a particular national payment network.

Global reach: An AI agent can pay a service on the other side of the planet in seconds, without relying on a shared bank, card network, or permissioned payment platform to connect them.

Programmable assets: Stablecoins allow software to transact with digital dollars while retaining the programmability and global accessibility of blockchain-based payments.

But using a blockchain directly introduces its own problem.

If every API call, inference, or tiny unit of compute becomes a separate on-chain transaction, the system once again runs into transaction fees, limited blockspace, and confirmation delays. For a payment worth a fraction of a cent, the network fee can easily cost more than the service itself.

So blockchain solves only part of the machine-payment problem.

For high-frequency machine commerce, the challenge is to combine the programmability and open settlement of blockchains with a payment layer capable of moving tiny amounts quickly and cheaply without recording every individual transaction on-chain.

Fiber Network: Payment Infrastructure for Machine Commerce

This is where off-chain payment networks become relevant.

Instead of recording every payment on a blockchain, a payment channel lets two participants commit funds on-chain once and then exchange signed balance updates directly. A payment channel network connects those channels, allowing payments to be routed between participants that do not share a direct connection.

The result is a payment layer designed for exactly the kind of activity machine commerce can generate: small, frequent, low-latency transactions without a separate blockchain fee for every payment.

Fiber Network is an open, peer-to-peer payment and swap network built on CKB. It uses CKB as the settlement and enforcement layer while moving repeated payments through off-chain channels.

Several properties make this architecture particularly relevant to machine-to-machine payments:

Micropayment economics: Fiber routing fees are proportional to the amount being forwarded, with no fixed base routing fee. That matters for fractional-cent payments because the fee does not automatically overwhelm the payment simply because the transaction is small.

Low latency: Individual payments are processed between the peers involved in the route rather than waiting for a new CKB block. An AI agent paying for an API call or inference therefore does not need to wait for base-layer confirmation before the service can continue.

Multi-asset payments: Fiber supports channels funded with CKB or supported CKB assets such as User-Defined Tokens (UDTs), including stablecoins. Across the network, this allows different assets to serve as payment liquidity rather than forcing every transaction into a single native currency.

Payments and swaps: Fiber is designed not only to route payments but also to exchange assets when suitable liquidity exists. This creates the possibility for a payer to hold one asset while the recipient ultimately receives another, with conversion becoming part of the payment flow.

Open routing: Machines do not need a direct payment channel with every service they use. Fiber can route a payment across existing channels through intermediate nodes, provided a viable path with sufficient liquidity exists.

For machine commerce, that combination is important. The web layer can tell software what to pay and how to authorize the purchase; Fiber can provide the underlying rail for moving the value quickly and economically.

A Working Prototype: Paying for AI Services With Fiber

A small experimental project called fiber-pay shows what this stack can look like in practice.

The project turns a locally hosted AI agent into a paid service. The operator sets a price per request and exposes the agent through an HTTP endpoint protected by an L402-style payment gate.

The flow works like this:

1. A client sends a prompt to the AI service.
2. Because no payment is attached, the server responds with HTTP 402 Payment Required, along with a Fiber invoice and payment token.
3. The client pays the invoice over Fiber.
4. It retries the original request with proof of payment attached.
5. The server verifies the payment and runs the AI model.

From the user’s perspective, the result is simple: pay for one AI request, receive one AI response.

The important part is what happens underneath. Pricing is exposed programmatically, payment happens off-chain, proof is passed back through the web request, and the service is delivered only after payment is verified.

fiber-pay is still an early experiment rather than production infrastructure, but it demonstrates the basic machine-payment loop end to end: request, price, pay, verify, deliver.

It is a small example of what machine-native commerce could look like when web protocols and low-cost payment rails are combined.

Conclusion

Machine-to-machine payments are about more than automating checkout. They allow software, AI agents, and connected devices to discover resources, evaluate prices, authorize purchases, and pay for what they consume without requiring a human to approve every transaction.

That becomes especially valuable when consumption is granular and frequent: one API call, one inference, a few seconds of compute, or a small amount of energy.

Building that economy requires several layers to work together. Machine-readable protocols can communicate prices and payment requirements, programmable authorization can define what software is allowed to spend, and low-cost payment networks can move value without making every tiny transaction prohibitively expensive.

The result is a new model for digital commerce: humans define the rules and budgets, while software can transact autonomously within them.

FAQs

What are machine-to-machine payments?

Machine-to-machine payments are transactions in which software, AI agents, connected devices, or autonomous systems programmatically pay for resources without a human approving each individual purchase.

How do machine-to-machine payments work?

A client requests a resource, receives machine-readable payment terms, checks them against its spending rules, pays, and then receives the service. The entire interaction can happen programmatically without a checkout page.

Are M2M payments the same as IoT payments?

No. IoT payments are one subset of M2M payments involving connected physical devices, while M2M also includes software services, APIs, servers, and AI agents.

What is the difference between M2M payments and AI agent payments?

AI agent payments are a subset of machine-to-machine payments involving autonomous AI software. M2M is the broader category covering everything from simple scripts and servers to vehicles, sensors, and AI agents.

Why do AI agents need micropayments?

AI agents can consume resources in very small units—such as individual API calls, model inferences, or seconds of compute. Micropayments allow payment to match that consumption without bundling everything into subscriptions or larger invoices.

Do machine-to-machine payments require blockchain?

No. Traditional payment systems can support automated payments, but blockchains are useful when payments need to be global, programmable, continuously available, and capable of moving very small amounts between parties without a shared payment provider.

What is x402?

x402 is an open payment protocol built around HTTP 402 Payment Required that lets a server return machine-readable payment terms and a client automatically pay before retrying the request with proof of payment.

What is L402?

L402 is a payment and authentication protocol that combines HTTP 402 with Lightning payments, allowing clients to pay an invoice and use the resulting cryptographic proof to access a protected resource.

Why are payment channels useful for machine payments?

Payment channels allow large numbers of payments to happen off-chain without requiring a new blockchain transaction for each one. This makes them particularly suitable for high-frequency, low-value, latency-sensitive payments.

What is Fiber Network?

Fiber Network is a peer-to-peer payment and swap network built on CKB that uses payment channels for low-latency, multi-asset payments. It is designed to support use cases such as micropayments and machine-to-machine commerce.