Membership isn't the only way to participate in CKB. ckba.build now has a general enquiry form. Questions about CKB, General Member interest, or anything else for the team to know. We read every one 👉 ckba.build/contact

Most payment networks are islands. Fiber is being built to reach the biggest one next door. Fiber and Lightning share the same basic machinery, payment channels and multi-hop routing, so a Cross-Chain Hub can sit between them and link a payment on one network to a payment on the other. Say Alice holds assets on Fiber and wants to pay Bob, who only takes BTC over Lightning. The hub accepts her Fiber-side payment and makes the matching Lightning payment to Bob, and the two are tied together by the same cryptographic secret, so revealing it to settle one side is what settles the other. The hub provides liquidity and connectivity, not custody. It cannot claim the incoming payment without making the outgoing one, because if the condition is not met in time, both sides unwind. See what's being built on Fiber 👉 fiber.world/showcase

Paying for something with crypto shouldn’t have to mean publishing every purchase to a permanent public ledger. With payment channels, individual payments happen through signed balance updates exchanged off-chain. Thousands of payments can take place without creating thousands of public blockchain transactions. That offers a privacy benefit, though it isn’t perfect anonymity: routing nodes can still observe some information, and timing or network activity can reveal more. Our guide explains how payment channels reduce what gets published, and how the blockchain still protects the funds 👇 nervos.org/knowledge-base/ho…

Rollups and payment channels both move activity off the base layer, but they optimize for different jobs. A rollup executes transactions in a separate environment, batches them, and submits data and proofs or state commitments to the base chain for verification or challenge. That makes rollups a good fit for applications where many users interact with shared state, such as decentralized exchanges, lending markets, and games. Payment channels take a more specialized approach. Two parties lock funds in an on-chain contract, then exchange signed balance updates directly. The blockchain steps in to open or close the channel, or enforce a valid balance if needed. If the goal is scaling a shared application, a rollup is a natural fit. If the goal is moving value between parties frequently, quickly, and inexpensively, payment channels are built for the job. Fiber brings that channel model to CKB. Try it yourself 👇 fiber.world/docs/build/inter…

The basic logic behind payment channel networks like Lightning or Fiber is based on a simple question: why involve the whole network? If two parties want to make 10,000 micro payments to each other, does the entire blockchain need to process all 10,000? With scaling solutions like Lightning and Fiber, it doesn’t. The parties commit funds onchain, then exchange signed updates to their balances directly. The blockchain remains available to settle the channel and enforce those balances if cooperation breaks down. This allows crypto to move quickly and inexpensively while preserving a non-custodial setup. Although not with without trade-offs, it’s arguably the best solution we have for permissionless micro and streaming payments—payment modalities that the machine economy will be built on. Dive deeper into the ins and outs of offchain payments with our latest guide 👇 nervos.org/knowledge-base/ho…

“Off-chain” is an umbrella term for very different ways to move money, each with its own security and trust assumptions. With centralized custodial platforms like Binance Pay, you’re trusting the company with your assets. Sidechains are often included in this conversation, but they’re really “off the main chain.” You still rely on the sidechain’s consensus for transaction finality, plus the security of any bridges or cross-chain protocols involved. With rollups, depending on the setup, you may rely on the sequencer operator to include and order your transactions. That doesn’t necessarily mean trusting it with your funds, but it can mean depending on it for timely withdrawals or transaction inclusion. With payment channels and payment channel networks, you retain control of your funds and can enforce your balance on-chain anytime, even if the other party stops cooperating. Security rests on the base chain, the channel contracts, and your or a watchtower’s ability to respond to disputes in time. Same label. Different trust assumptions. Read our latest article to dive deeper into off-chain payments 👇 nervos.org/knowledge-base/ho…

A Fiber node can now run directly inside native Android and iOS apps through an experimental integration. The cool thing is, the app runs the node itself! It’s not just an interface to one hosted on a server. The integration reuses Fiber’s existing Rust implementation, letting developers call its functions from native app code without rewriting the node for each platform. The demos already cover starting a node, connecting to peers, opening and closing payment channels, creating invoices, and sending payments. This is still an exploratory reference integration, not an official mobile SDK. Security, reliability, and background operation need further work before production use. But developers now have a working starting point for mobile apps that manage their own Fiber channels and payments. Explore the Android and iOS demos and integration guides 👇 fiber.world/docs/build/ffi/f…

A Fiber node can now run entirely inside a Chrome extension, with no separate app or server behind it. Chrome normally puts an extension’s background worker to sleep when it’s idle, which is a problem for a node handling payments. Fiber gets around this by running in a Chrome Offscreen Document: a hidden browser page that keeps the node active even when you close the extension’s popup. Under the hood, this setup requires SharedArrayBuffer access, cross-origin isolation, and a content security policy that permits WebAssembly and worker threads. For now, it’s limited to Chrome-based browsers. Firefox and Safari don’t yet support the same extension setup. Check the full build walkthrough👇 fiber.world/docs/build/brows…

⚠️ 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 👉 utxoswap.xyz/info/overview

The most important privacy decision on Lightning is not made by the protocol, it is made by you. Protocol-level privacy is what the specification guarantees. Application-level privacy is what you actually get, and the gap is decided above the protocol. A custodial wallet holds your keys and sees the sender, recipient, and amount before any encryption is applied, so onion routing protects nothing from the entity holding the keys. Mobile wallets usually keep one channel with a service provider that then sits on every payment as the first or last hop. Paying the same merchant or reusing an invoice builds patterns routing cannot erase. Running your own node removes the custodian, and an open, permissionless network is what makes that a real option rather than a technicality. The tools to run your own are here 👉 fiber.world/docs/build/toolc…

Lightning can hide a payment and still leak the map around it. For wallets to find routes, the network has to publish a channel graph, so every announced channel's capacity and the Bitcoin funding transaction behind it are public. That funding transaction is the seam between the two layers. It is also what researchers actually attack. One study linked 45.97% of Lightning nodes to Bitcoin addresses using nothing but public channel-funding data. And because routing concentrates in a handful of large nodes, a five-year study published in December 2025 warns of a growing concentration of routing, so an adversary only has to run a few well-connected nodes to watch a lot of traffic. The payment stays private, the infrastructure carrying it does not.

The privacy weak point inside Lightning is quieter than people expect, and it lives in the payment contract itself. Standard HTLCs, the contracts that make a multi-hop payment atomic, reuse the same payment hash across every hop of a route. If an attacker controls two nodes on that route, they can match the identical hash, amount, and timing, and confirm both hops belong to the same payment, which is exactly what onion routing was meant to prevent. The fix researchers point to is PTLCs, which give each hop its own distinct secret instead of one shared value running the whole way down the route, so there is nothing for two nodes to match on. On Lightning, a change like that waits on Bitcoin. Fiber is built on CKB, where channel rules are programs rather than fixed Script, so upgrades of this kind can be adopted without a base-layer fork. Try building a Fiber channel yourself 👉 fiber.world/docs/build/inter…

Privacy and anonymity get used interchangeably, and Lightning is where the difference bites. Payment privacy is keeping the details of a payment, the sender, recipient, amount, and route, away from unauthorized observers. Anonymity is an observer being unable to tie an action to a real-world identity. Lightning mostly delivers the first, and much less of the second. A public Lightning node usually runs under one long-lived public key. Announcements can attach that key to an alias and an IP address, businesses advertise their node openly, and a standard BOLT 11 invoice hands the payee's public key to whoever holds it. None of that is your legal name. But the moment a node's public key is linked to a merchant, an exchange KYC record, or a naked IP address, a node's historical public footprint becomes linkable to a real identity.

Lightning has a reputation for being private, and it mostly earns it. Everyday payments never touch Bitcoin's public ledger, and a middleman node sees only its two neighbours and the amount it forwards. But private is not the same as anonymous. Lightning hides the details of a payment, it does not hide who you are, and the node graph, invoices, and channel funding all leak more than people assume. The better question is not whether Lightning is private, but private for whom. We broke down what Lightning hides and what it exposes 👇 nervos.org/knowledge-base/ar…

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. coindesk.com/tech/2026/09/09…

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 👉 nervos.org/knowledge-base/wh…

Streaming payments come in two shapes, and the difference is where the payment state lives. On-chain streams accrue inside a smart contract. A sender deposits tokens and sets a rate, say $1 an hour, and the chain never processes 3,600 separate payments an hour, the contract simply calculates what is owed whenever someone withdraws. Sablier and Superfluid work this way on Ethereum, and it fits payroll, vesting, and it fits payroll and vesting, where the rate is known in advance. Off-chain streams move the payment state as usage happens. Participants fund a payment channel once, then update the balance after every API request or every few seconds of compute, with no blockchain transaction per update. One calculates what is owed over time, the other pays it out event by event.

An AI agent rarely knows what a task will cost before it starts. It might call a model ten times or ten thousand times, and a compute job might finish in thirty seconds or run for hours. The service is consumed incrementally, but payment usually is not. Money moves upfront as prepaid credits or afterwards as a bill, and someone carries the gap in between. Streaming payments close that gap by letting money accrue or move in small increments as usage happens. We broke down how AI agents pay as they go 👇 nervos.org/knowledge-base/wh…

Vitalik's bigger point here isn't just that SNARKs could become dramatically cheaper. Across several posts this week, he's describing a future where signatures, ZK proofs and other expensive checks can increasingly be compressed into proofs, and where "cryptographizing" computation eventually becomes as routine as using HTTPS. If that happens, it changes what we should want from a blockchain VM. If more of the base layer's job becomes verifying proofs of computation happening elsewhere, its cryptographic capabilities shouldn't be frozen around the primitives that happened to matter when the chain launched. Interestingly, that was one of CKB's earliest architectural bets. CKB is designed as a universal verification layer. CKB-VM runs RISC-V and hardcodes no cryptographic precompiles, so new signature schemes, SNARK/STARK verifiers and other cryptographic constructions can be implemented as software at the smart contract or script layer rather than added one by one to the base protocol. We've already seen this flexibility in practice. Groth16 and other ZK proof verifiers have been implemented directly on CKB-VM without modifying the underlying chain, and NIST-standardized SPHINCS+ is already live on mainnet as an opt-in Lock Script. The point is, nobody knows which cryptographic primitives will dominate ten years from now. So if Vitalik is right that cryptography is about to evolve much faster than most expect, the advantage isn't predicting the winners today. It's crypto agility: being able to adopt whatever wins tomorrow.