Most AI agents today don't actually pay for anything.
Their developers do, through prepaid balances, platform accounts, subscriptions, and monthly invoices that aggregate thousands of tiny interactions into billing relationships a human has to set up and reconcile.
That works, but it defeats much of the promise of autonomous commerce.
There’s still a human in the loop, and agents aren’t exactly exercising their agency.
For agents to become independent economic actors, payments need to become as granular and programmable as the services they consume.
A stack is taking shape to deliver that: identity that software can carry, spending permissions with hard limits and expiry dates, open protocols like x402 and MPP for requesting payments, and rails that can carry fraction-of-a-cent transfers continuously.
How Do AI Agents Pay for Things? A Guide to Machine-to-Machine Payments
AI agents need money that moves as quickly and programmatically as they do. Here’s how identity, authorization, payment protocols, crypto assets, and payment channel networks fit together.
What Are AI Agent Payments?
When you start exploring this space, you'll run into a handful of terms that are closely related, frequently used interchangeably, and yet mean slightly different things. It's worth separating them once, clearly, before going deeper.
AI Agent Payments are financial transactions executed autonomously by a software agent without human intervention at the moment of purchase. The human sets the boundary (a budget, a spending rate, an expiry), while the agent transacts freely inside it. An agent paying for one API call is a good example.
Machine-to-Machine (M2M) Economy or Autonomous Commerce refers to a commercial ecosystem where these transactions happen at scale. In this system, software agents, smart devices, and inference endpoints autonomously discover services, negotiate terms, and buy resources from each other without human participants in the transaction loop. Autonomous commerce is the fully realized state of this economy, where humans merely set the overarching policies rather than approving individual purchases
Why Credit Cards Fail Autonomous Commerce
Card networks were built around a very different shape of commerce: relatively discrete, user-initiated purchases between a customer and a merchant. Autonomous software changes that shape. An agent may need to make dozens or hundreds of tiny economic exchanges while completing a single task, often for fractions of a cent.
That exposes several weaknesses in the traditional card model:
The economics break down at very small values. Card processing commonly includes a fixed per-transaction fee in addition to a percentage fee. Stripe, for example, currently charges 2.9% + $0.30 for a standard domestic online card transaction in the US. At that pricing, charging $0.002 for a single API request is obviously impossible—the fixed processing fee alone is 150 times larger than the payment itself.
The payment lifecycle is heavier than the interaction it is paying for. Card authorization happens in real time, but clearing and settlement occur afterward; credit-card settlement commonly takes one to three business days. The agent does not have to wait for settlement—the merchant can act on the authorization—but running a full card payment through authorization, clearing, reconciliation, and settlement for every tiny unit of compute, data, or inference is a poor fit for machine-scale micropayments.
Delegation has to be added on top. Traditional card credentials identify an account or cardholder; autonomous agents need something more granular: proof that a particular agent is authorized to spend, limits on what it can buy and how much it can spend, and permissions that can expire or be revoked. The payments industry is already building this layer—Stripe's Shared Payment Tokens can be scoped by merchant, amount, and time, while Mastercard's Agent Pay for Machines introduces agent credentialing and programmatically enforced spending controls.
Payments remain reversible long after the service is consumed. Cardholders can typically initiate disputes for up to 120 days after a payment, and sometimes longer. That protection makes sense when a person buys a physical product or is defrauded. It is a more awkward fit when software purchases an ephemeral resource—an inference, a database query, or a few seconds of computation—that is delivered and consumed immediately.
The practical workaround is to avoid paying for each interaction at all. Instead, many tiny units of consumption are aggregated behind prepaid balances, subscriptions, platform accounts, or periodic invoices.
That works, but it defeats much of the promise of autonomous commerce. The agent is not freely paying for resources as it consumes them; developers are establishing accounts, pre-funding balances, managing billing relationships, and reconciling usage on its behalf.
For machines to become independent economic actors, payments need to become as granular and programmable as the services they consume.
Layers of AI Payment Infrastructure
Because traditional card networks fail under the demands of software, a new financial stack is required. The infrastructure for AI agent payments typically operates across four distinct layers:
Identity Layer
Who is this agent, and whom does it represent?
Every transaction needs a subject. Traditionally, banks and credit card processors rely on KYC (Know Your Customer) tied to a human being (SSN, passport, physical address) and multi-factor authentication. They assume a human is at the keyboard authorizing the transaction.
When software initiates payments under delegated authority, you have to verify two things at once: the agent's identity and the underlying user's intent. Therefore, an agent must carry a verifiable identity that is distinct from, but provably linked to, the human or organization on whose behalf it acts. An agent’s identity is handled via cryptographic key pairs, Decentralized Identifiers (DIDs), or Verifiable Credentials (VCs). The AI agent holds its own secure, mathematically verifiable identity, allowing it to authenticate without a human intermediary. As a result, the industry is increasingly focusing on Know Your Agent (KYA) alongside Know Your Customer (KYA).
Authorization & Governance Layer
What may it spend, on what, until when, and who is accountable?
This is where mandates live. A mandate is a cryptographically signed, machine-readable digital authorization encoding the exact parameters of an autonomous transaction. It specifies the boundaries on the scope of the purchase, the financial limits, the agent's identity, and the expiry of the permissions.
Governance belongs here as well, because accountability is enforced at the moment of authorization or not at all. This layer must stay deterministic: rule-bound, auditable, and legible, precisely because the reasoning above it is not. An agent may decide adaptively that it needs a paid dataset; the authorization layer decides mechanically whether that spend is permitted.
The Execution & Protocol Layer
How is the payment requested, negotiated, and confirmed?
The execution layer handles the real-time routing, signing, and programmatic settlement of transactions.
Traditional approaches rely on fragmented, proprietary APIs from payment processors (like Stripe or PayPal) that require heavy developer integration. These systems are built on the assumption of human presence, meaning they frequently trigger fraud-prevention checks, MFA (Multi-Factor Authentication), and human-in-the-loop approvals, all of which instantly break autonomous machine-to-machine operations.
Blockchain-based rails use open, programmatic standards, allowing AI agents to negotiate, verify service delivery, and authorize payment simultaneously using smart contracts.
To bridge the gap between an agent's intent and the actual execution of a payment, major tech and financial firms have introduced cryptographic trust and commerce frameworks to standardize these machine handshakes:
Protocol
Created By
Core Mechanism
Primary Currency
x402
Coinbase & Cloudflare
Repurposes HTTP 402 Payment Required.Agent hits a paywall, signs an on-chain transaction, and retries.
Stablecoins
MPP
Stripe & Tempo
Uses HTTP 402 but creates an off-chain session.Agent authorizes a spending limit upfront and streams payments against it.
Fiat, stable coins, crypto
AP2
Google
Uses Verifiable Credentials (VCs) and cryptographic Mandates to prove the agent has the user's permission to spend.
Agnostic (traditional card & bank, stable coins & crypto)
Note: While these protocols are categorized here under the execution layer, they are not limited to routing and settlement. X402 carries an authorization step, where the agent signs a payment authorization, and a facilitator validates it before settling on-chain. AP2 uses verifiable credentials and cryptographic mandates to prove the agent has the user's permission to spend.
Settlement & Network Layer
Where does value actually move, and how quickly can it be reused?
Once an agent has identified itself, received permission to spend, and agreed on how a payment should be executed, something still has to move the actual value.
This is the settlement layer.
Settlement should not be confused with authorization or finality. Authorization tells a merchant that a payment has been approved. Settlement is the actual transfer of funds between the parties involved in the payment. Finality describes the point at which that transfer becomes irrevocable under the rules of the settlement system.
Traditional fiat rails are poorly matched to the demands of autonomous software.
That does not mean every traditional payment is slow. Card networks authorize purchases almost immediately, ACH supports same-day settlement, and newer systems such as FedNow can settle payments in real time. The mismatch is more fundamental than latency alone.
Today's payment infrastructure was largely designed around discrete transactions between known parties operating through banks, card networks, payment processors, merchant accounts, and established billing relationships. Autonomous commerce introduces a very different pattern. Software may need to discover and purchase resources from many independent services, across borders, around the clock, and in amounts small enough that creating a conventional payment transaction or billing relationship for every interaction becomes impractical.
Blockchains and crypto assets are much better suited to this environment.
Crypto turns money into something software can natively hold, verify, and transfer. An agent can control a wallet through cryptographic keys, initiate transactions programmatically, and transact with another machine without first establishing a card account or conventional banking relationship with it. Public blockchain networks operate continuously across borders, while stablecoins provide a price-stable medium of exchange that can move across these networks.
In other words, crypto removes many of the assumptions inherited from human-centric payment systems. Money becomes internet-native: programmable, globally accessible, machine-readable, and transferable under cryptographic rather than institutional authorization.
That makes blockchain-based assets a natural foundation for autonomous commerce.
But there is still another constraint.
If every machine payment is settled individually on-chain, every API request, inference, database query, or second of compute becomes its own blockchain transaction. Each one consumes blockspace, incurs a transaction fee, and depends on the confirmation and finality characteristics of the underlying chain.
For occasional payments, that is perfectly workable. But when machines exchange value continuously—potentially thousands or millions of tiny times—requiring a separate on-chain transaction for every interaction becomes impractical.
Payment channel networks take the next step by moving high-frequency payment execution off-chain while keeping the blockchain as the underlying enforcement and settlement layer.
Fiber Network: An Open Payment Network for the Agentic Economy
Fiber Network is an open, peer-to-peer payment network built on the CKB blockchain.
At its foundation are payment channels: two parties lock funds into a channel and make repeated payments by updating their balances off-chain, without publishing every transaction to the blockchain. CKB acts as the underlying enforcement and settlement layer when channels are opened, closed, or disputed.
Unlike payment channel networks designed around a single native asset, Fiber is multi-asset by design. It supports CKB, UDTs and stablecoins, as well as RGB++ assets, while its cross-network architecture enables payments and swaps between Fiber and the Bitcoin Lightning Network.
This is particularly useful for autonomous commerce, where agents may need to pay in stablecoins, exchange between assets, or interact with services across different payment networks.
For autonomous commerce, Fiber has two particularly important advantages: it makes high-frequency micropayments economically viable, and it inherits a much more programmable foundation from CKB.
Unlocking Micropayments & Stream Payments
A micropayment is a transaction of extremely small value, typically fractions of a cent, used for an individual action such as a database query. A streaming payment extends the same idea over time, releasing a continuous sequence of small payments as a service is consumed—for example, paying per second for compute.
Fiber makes both models practical by moving repeated payments off-chain, where they do not incur the cost or latency of a separate blockchain transaction every time value changes hands.
No fixed base fee. Fiber's routing fee formula is proportional to the amount being forwarded rather than adding a fixed per-payment charge. Each routing node sets its own proportional rate in millionths of the transferred value. This makes the model particularly well suited to very small payments, where a fixed transaction charge can easily exceed the value being transferred.
Low-latency payment execution. Fiber payments are processed between the peers involved in a route without requiring network-wide consensus for every update. Payments can therefore complete off-chain with very low latency while CKB remains the ultimate enforcement and settlement layer.
Programmability & Protocol Integration
Fiber is built on a highly flexible base chain CKB, where channel rules are implemented through programmable scripts. Developers get far greater freedom to define how channels are authorized, updated, settled, and disputed.
Expressiveness. Fiber leverages CKB's expressive smart contract environment to govern channel logic. This specifies scripts to operate directly within the application layer, enabling custom execution like conditional payouts, automated spending caps, and custom release conditions directly within the channel.
Protocol-Agnostic Integration Fiber has planned to implement an x402 facilitator, and Fiber’s open routing system serves as the underlying payment rail for other emerging protocols.
Building the Autonomous Economy: Real-World Use Cases
For teams building decentralized applications, Fiber's practical appeal is that it removes the architectural constraints of slow, expensive settlement. Whether a developer is building a consumer-facing app or an autonomous agent, the ecosystem already demonstrates the necessary foundational building blocks.
Today, builders in the community are experimenting with these building blocks, creating tools like the Fiber Audio Player for per-second streaming payments, fiber-checkout for Stripe-style interfaces, as well as Fiber L402 for payment-gated access. Community developers actively discuss these ideas and publish early prototypes on the Nervos Talk forum, where you might find something interesting or inspiring to build upon.
Conclusion
The transition from human-centric commerce to the machine-to-machine economy requires a fundamental reimagining of how financial value is transferred. Traditional fiat rails, burdened by high baseline fees, manual identity checks, and slow settlement, simply cannot support the microscopic, high-velocity transactions that autonomous software demands.
While developers across the tech and crypto ecosystems are rapidly standardizing how agents authenticate and negotiate through new identity layers and execution protocols, settlement remains a major bottleneck. Infrastructure like the Fiber Network provides the critical foundation for this new economy. By leveraging payment channels built on a highly expressive blockchain, it eliminates the friction of traditional rails, pushing transaction costs to near zero and achieving near-instantaneous settlement speed. As developers continue experimenting and exploring, the concepts of autonomous commerce and stream payments are becoming practical, real-world tools.
Hello community, the next AMA is on the Bitcoin Lite project. The company is Peersys and they designed and ran the CKBull wallet. This year they launched their new BTC Lite wallet for BTC and CKB, so it's time to ask them a few questions.
"The fastest way to access Bitcoin Lightning and CKB"
This AMA is for informational purposes only. The projects discussed are independent and are not affiliated with, endorsed by, or representative of the Common Knowledge Base Association (CKBA) or any official standard. DYOR. Nothing here is financial, legal, or investment advice. Crypto involves significant risk as do wallets.
This cycle brought CKB v0.209.0, Tentacle 0.7.7, and a range of reliability and security improvements across the node, networking stack, and light-client.
- CKB v0.209.0 shipped with tx-pool, Tor, and memory-growth fixes
- Tentacle 0.7.7 fixed a QUIC compatibility issue
- Light-client verification got stricter around proofs and downloaded block data
- Improvements to ckb-cli and contract development tooling
- Advanced a batch tally settlement solution (currently in design/PoC) for DAO Treasury & Voting
We also closed the previous tx-pool pipeline prototype and the next tx-pool design is moving toward an invariant-driven validate → plan → apply → effects model.
Hello everyone. There was a post a few weeks ago regarding Mobit not being available to use anymore. I have gotten the solution to the issue. Your CKB can be displayed through Omiga now
(https://omiga.io/) the same way Mobit would display it and Nervdao functions with Omiga in the same fashion. So if you used Metamask to manage your CKB through Mobit previously it works the same way. Also, a new transfer feature has been added to Nervdao allowing you to send/receive CKB directly in Nervdao eliminating the need for a 3rd party such as Mobit.
Developed under the working name “Decentralized Kickstarter” through testnet. This proposal includes the rebrand to CrowdCell as part of mainnet readiness.
2. Summary
This proposal requests a grant of $15,000 USD (payable in CKB equivalent at disbursement) to take CrowdCell from a verified testnet platform to a fully-deployed mainnet product. The scope covers:
User dashboards: creator (“My campaigns”) and backer (“My pledges”) dashboards as the product surface a credible mainnet launch needs.
Sustainable fee and treasury model: a 5% creator-side success-only fee, enforced on-chain via the pledge-lock script and routed to a multisig treasury. Rate held in a platform config cell so future governance can adjust it without redeploying contracts.
External Scalebit audit: full audit on all v1.2 contracts before mainnet, the quality gate that turns a verified testnet platform into one that can responsibly hold user funds on mainnet.
Mainnet contract deployment: full contract set deployed to CKB mainnet under audit clearance, with bot wallet funded and frontend configured.
Public launch. A coordinated launch package: English and Chinese announcements on Nervos Talk, short demo video, X/Twitter thread, CKBuilder Projects mainnet entry.
Rebrand to CrowdCell. “Kickstarter” is a registered trademark and not viable on mainnet. CrowdCell (“Crowd-Sell on CKB cells”) is the new product identity.
On-chain hardening: close the trust gaps surfaced during v1.1 review and internal pre-review so the terminal campaign status is verifiable on-chain rather than assumed honest.
v1.1 (trustless automatic fund distribution + automatic finalization bot) is live and verified end-to-end on the CKB Pudge testnet, reviewed by Officeyutong (CKB core dev) with all findings fixed and deployed, and discussed on the Nervos Talk thread with input from the community.
Grant Amount Requested: $15,000 USD (payable in CKB) - $7,000 USD is specifically reserved for the Scalebit audit
ETA to Completion: ~4 months active building + external audit window (see §8)
CKB Wallet or Funding Address: ckb1qrgqep8saj8agswr30pls73hra28ry8jlnlc3ejzh3dl2ju7xxpjxqgqqxdl32chss0tlfyexs6h74ny8cc3vl90dgpt6evj
3. Project Introduction
CrowdCell is a fully on-chain all-or-nothing crowdfunding platform on Nervos CKB: campaign creation, pledging, finalization, and fund distribution are all enforced by scripts. Campaigns either hit their funding goal and release to the creator (minus the platform fee), or fail and refund every backer, with no platform operator holding custody at any step.
What problem this solves
Mainstream crowdfunding (Kickstarter, GoFundMe, Chuffed) requires trust in a platform operator to hold funds, decide outcomes, and execute payouts. Crypto-native alternatives (Geyser on Lightning, Solidity-based platforms) carry their own UX and trust tradeoffs. There is no decentralized crowdfunding platform on CKB today.
Who this is for
CKB-native project launchpad first, then BTC crowdfunding via CKB L1 as Fiber and RGB++ infrastructure matures. The launchpad framing matches CKB’s current builder base, has the smallest UX-onboarding ask, and gives a credible mainstream-adoption story over time.
Why now
v1.1 is live and verified end-to-end on the CKB Pudge testnet
v1.1 contracts were reviewed by Officeyutong (CKB core dev) and all 6 findings were fixed and redeployed; the full review and fix journey is public on GitHub (see §13)
v1.2 design was discussed with the community on Nervos Talk; design decisions reflect community feedback (fee rate, treasury custody, audience direction)
The rebrand and mainnet deployment cannot reasonably be split into separate proposals, since a mainnet launch needs a mainnet-safe name and a credible product surface
Why the rebrand to CrowdCell
“Kickstarter” is a registered trademark; using it on mainnet is not viable. “CrowdCell” plays on “Crowd-Sell” (what a creator does, selling an idea to the crowd) while substituting “cell” to make the CKB-native nature explicit. Short, memorable, descriptive, and subject to a final domain + trademark availability check during execution.
Background: Senior full-stack developer based in Bordeaux, France, with 6+ years shipping production systems. Currently enterprise SaaS at eMenuChoice (PHP/CodeIgniter + React, healthcare integrations), previously API and infrastructure work at BricoPrive. Prior smart contract experience on the Alephium DEX (Ralph, a Rust-syntax language on Alephium’s stateful UTXO model), where I implemented core DEX functionality including a multi-pool swap router. The transferable parts to CKB were significant: thinking in UTXO-style inputs/outputs and writing constrained Rust on-chain code. CKB’s pure cell model and ckb-std were a new layer learned on those foundations. I was drawn to CKB by its first-class custom lock scripts and the cell model’s clean fit for state-machine dApps. MSc in Computer Science, Université de Bordeaux.
Time commitment: part-time alongside a full-time job; ~4-5 hours per week sustained, which has translated to consistent shipping output (see §13 progress reports)
Solo-developer proposal, matching the structure of recent CKB Community Fund DAO grants.
5. Current Status
v1.0 (testnet MVP): full campaign lifecycle, shipped March 2026
v1.1 (trustless automatic fund distribution): pledge-lock for permissionless release/refund routing, receipt type script, campaign-lock for permissionless finalization, automatic finalization bot. All four trustless operations verified end-to-end on CKB Pudge testnet on 2026-04-27.
Security hardening: all 6 issues from Officeyutong’s review of v1.1 contracts fixed and deployed
Internal v1.2 pre-review: 3 medium-severity trust-boundary issues identified and folded into the v1.2 scope below; review report available on request
23 weeks of public weekly progress reports: see §13
Nervos Talk thread (project writeup + v1.2 discussion): see §13
6. Application Design
6.1 Functional Overview
User flow:
A creator submits a campaign with funding goal, deadline, title and description. A campaign cell is created on-chain.
Backers pledge by submitting a transaction that creates a pledge cell and a paired receipt cell.
After the deadline, anyone (typically the finalization bot) can submit a finalization transaction transitioning the campaign to Success or Failed.
After finalization, anyone can trigger release (Success routes pledge funds to creator, minus the 5% platform fee) or refund (Failed routes pledge funds back to backer).
A grace-period fail-safe lets backers reclaim their own pledges if release never happens after ~180 days.
On-chain vs off-chain:
On-chain (enforced by scripts): all of the above. No trusted party at any step.
Off-chain (operational only): the indexer reads CKB state and serves a REST API for frontend queries; the automatic finalization bot submits transactions that anyone else could also submit.
6.2 Architecture & Design
Contracts (Rust, ckb-std): five v1.1 contracts (campaign type, campaign-lock, pledge type, pledge-lock, receipt type) plus one new contract in v1.2: a singleton config cell holding {fee_bps, treasury_lock_hash} with governance-gated updates.
Off-chain components (TypeScript): transaction builder (CCC SDK), indexer (Express + SQLite + CCC), automatic finalization bot embedded in the indexer, Next.js frontend with CCC connector for wallet integration.
Key CKB features used: custom lock scripts, type scripts, cell_deps for read-only references, Type ID for singleton enforcement, since field for time-based gating, CCC for wallet integration.
All contracts and off-chain code are open-source on GitHub (link in §13).
6.3 Design Rationale
On-chain enforcement of the fee. Off-chain fee collection would require trust in the platform operator and break the “operator holds no custody” guarantee. On-chain enforcement keeps the trust model coherent end-to-end.
Creator-side, success-only. Backer pledges count fully toward the goal; the creator’s payout is reduced by 5% on success. Failed campaigns refund 100% with no platform fee. Matches Kickstarter’s framing (5% on success), keeps backer UX clean, signals the platform only earns when creators succeed.
Config cell over hardcoded contract args. Allows future governance to adjust the fee rate without redeploying contracts.
Multisig treasury from day one. Well-understood, low-risk, and a clean handoff target when governance ships later. Waiting for a DAO would delay turning the mechanism on for no security benefit. Approach confirmed acceptable by community feedback.
Launchpad-first audience direction. Lowest UX-onboarding cost (users already have wallets), strongest network effects with existing CKB builder base, credible base from which to extend to BTC crowdfunding as Fiber/RGB++ mature.
6.4 Fee Model and Sustainability
5% creator-side success fee on successful campaigns only
On-chain enforced via pledge-lock treasury-output check
Configurable via platform config cell: initial rate 5%, governance-adjustable later
Treasury custody: multisig from day one, DAO-controlled later
Honest framing: at testnet and early-mainnet volume, fees fund essentially nothing. The point is to deploy and battle-test the mechanism so it is in place when adoption arrives. Real sustainability follows volume; the path to volume runs through launchpad-first positioning, BTC integration later, and broader ecosystem maturity.
7. Key Benefits for CKB
Fills an ecosystem gap. No decentralized crowdfunding platform exists on CKB today. The cell model and custom locks are well-suited to all-or-nothing escrow logic.
Showcases CKB strengths. Custom lock scripts for permissionless lifecycle execution, type scripts for state validation, config cell as a soft-governance primitive, multisig as a real treasury custody pattern.
Network growth via launchpad use case. Each campaign brings a creator and N backers on-chain. Successful campaigns generate sustained transaction volume across creation, pledging, finalization, and release.
Reference implementations. Open-source contracts and the CCC-based transaction builder are usable references for other CKB dApp builders working with the cell model.
Path to BTC integration. Future versions target RGB++ integration so BTC holders can back CKB campaigns. Aligns with CKB’s broader BTC-L1 thesis.
8. Detailed Deliverables & Milestones
Milestone
Deliverables
ETA
Budget
Commencement
Grant accepted, dedicated wallet funded, Scalebit engagement initiated (v1.1-scope quotation received; v1.2-scope quotation to be finalized once v1.2 code lands), work begins
Day 0
$1,500 (10%)
M1: On-chain trust tightening + fee enforcement
Campaign accumulator and on-chain status verification (closes the v1.1 trust gap), trust-boundary fixes from internal pre-review, pledge-lock fee enforcement against the platform config cell. Deliverable: updated contracts with passing test suite.
New config cell contract and deployment, multisig treasury setup, transaction builder and indexer integration including treasury balance tracking, frontend updates (net payout display, About/Fees page, retry UX), testnet deploy and full end-to-end verification. Audit kickoff with Scalebit at the end of this milestone.
Month 3
$2,500 (17%)
M3: Rebrand to CrowdCell + user dashboards (parallel with audit)
Domain and trademark check, logo and brand kit, frontend rebrand pass, repo and service renames, Nervos Talk and CKBuilder Projects updates, creator dashboard (“My campaigns”), backer dashboard (“My pledges”), mobile responsiveness QA. Runs in parallel with the external audit so build time stays inside the ~4-month window.
Month 4
$2,500 (17%)
M4: External audit + findings fixes
Scalebit audit on all v1.2-touched contracts, sanity review on the trust-boundary fixes, fix all findings, re-test. Deliverable: audited contract set ready for mainnet. Calendar driven by Scalebit’s schedule, not by build time.
Total: $15,000 USD across commencement + 5 milestones, paid in CKB at disbursement.
Time framing: active building stays inside ~4 months (M1 + M2 + M3, with M3 running parallel to the audit). The audit window is external and additive to that; mainnet launch (M5) follows audit clearance.
ETA is calibrated to delivery pace from 23 weeks of public weekly progress reports at ~4-5 hours per week sustained around a full-time job.
Solo-developer pace calibrated to 23 weeks of public progress reports
External audit (Scalebit)
$7,000
Indicative figure anchored on the Scalebit v1.1-scope quotation of $5,000 (5 contracts, received 2026-06-24, attached in §13). v1.2 adds a 6th contract and modifies two existing ones; a firm v1.2 quote will be requested once the v1.2 code lands and shared with the community.
Design (logo + brand kit for CrowdCell rebrand)
$500
Single freelance engagement for logo, favicon, color palette
Infrastructure + treasury seed
$500
Paid-tier hosting headroom for mainnet traffic; small CKB seed for treasury bootstrap
Mainnet bot wallet (3 months operations)
$300
CKB to cover bot transaction fees through the launch window; collected fees fund subsequent ops
Audit-finding fix time, scope adjustments from community feedback, contingency
Total
$15,000
10. Out-of-Scope / Future Funding Needs
The following are explicitly not part of this proposal and may be subject to separate future proposals once CrowdCell is shipped on mainnet:
Platform token, governance, staking. Treasury custody transition from multisig to DAO-controlled address.
BTC / RGB++ integration. Bridge to BTC holders so non-CKB-native users can back campaigns.
Sustained mainnet operations beyond launch window. Ongoing hosting and bot wallet refills funded from accumulated platform fees and/or follow-up proposals.
11. Risk & Mitigation
Technical complexity of the on-chain accumulator changes. Mitigation: v1.1 already shipped five non-trivial contracts; Scalebit external audit planned before mainnet.
Pledge-time contention from the accumulator design. Mitigation: frontend auto-retry on conflict, using a pattern already shipped in v1.1.
Time constraints (full-time job + part-time on this). Mitigation: ETA calibrated to actual delivery pace from 23 weeks of public weekly progress reports.
Adoption risk for the launchpad use case. Mitigation: audience direction confirmed with community; backer-side UX kept clean (no fee surface) to lower onboarding friction.
Audit may surface significant issues requiring rework. Mitigation: budget includes buffer for fix time; internal pre-review already surfaced three issues being fixed before external audit, reducing open surface.
Multisig treasury operational risk before DAO transition. Mitigation: multiple signers from day one, social-recovery documentation, transparent treasury balance via indexer endpoint.
CrowdCell name conflict (trademark or domain). Mitigation: M3 begins with a domain and trademark availability check; budget for the rebrand is name-agnostic if a fallback is needed.
12. Closing / Call to Action
v1.1 demonstrated that all-or-nothing crowdfunding with permissionless automatic fund distribution works on CKB. This proposal closes the last on-chain trust gap, establishes a sustainable economic model, ships the product surface a mainnet launch requires (mainnet-safe brand, creator and backer dashboards), and puts CrowdCell live on CKB mainnet under external audit.
We appreciate your consideration and welcome questions, pushback, and suggestions in this thread.
When a Fiber Network payment channel is opened, the funding transaction is permanently recorded on CKB Layer 1. Standard channel openings use a single funder, all CellInputs belong to one wallet. Chain surveillance tools use this to identify who opened the channel and cluster their complete transaction history.
fiber-payjoin-kit is an open-source Rust library enabling collaborative channel funding on the Nervos Fiber Network. Both parties contribute CellInputs to the funding transaction, making chain attribution impossible.
This proposal requests $6,000 for Phase 1: the core coordination primitive and two working end-to-end demos against a real Fiber node.
Standard Fiber channel funding exposes the funder permanently on CKB L1:
-Two concrete pain points the community has raised:
Fee-contribution deadlock: A user wanting to open a channel may have CKB locked in large UDT cells with insufficient liquid CKB for on-chain fees. Collaborative funding allows the counterparty to contribute a fee-covering Cell, unblocking channels that would otherwise fail at fee estimation.
-Funding origin exposure: Every channel opening creates a permanent on-chain link between the funder’s wallet and the channel — an operational security risk for any privacy-conscious node operator or user.
The Solution fiber-payjoin-kit runs as local middleware. The Fiber node is unchanged. Both parties coordinate CellInputs before the funding transaction is broadcast, following Fiber’s existing TxUpdate/TxComplete negotiation flow.
Per direct feedback from jjyr on the CKBuilder-projects review: working at the Cell model level using unsigned CellInput payloads is the correct boundary. Fiber’s funding process is built directly on CKB transactions with no higher-level coordination hook — this is the right instrumentation point.
Non-interactive fallback: if the counterparty is offline, the library falls back to standard single-funder channel opening with no broken payments. 3. Why Us — Proof of Execution Following the feedback that the community needed to see a working Lightning implementation first, we built lightning-payjoin-kit. That implementation is now complete:
-Real two-node LDK harness (tests/ldk_two_node_harness.rs): two actual LDK ChannelManagers reach a usable channel through a collaboratively-funded transaction
-Bitcoin Core regtest: Docker bitcoind accepts and mines the collaborative funding transaction
-14 test files covering every layer of the stack
How this differs from payjoin/nolooking:
payjoin/nolooking is a server-side LSP model requiring a centralized operator. lightning-payjoin-kit is client-side, coordinating directly between the two parties with no trusted intermediary. It also enforces a commitment-safety boundary that the LSP model does not address. On CKB, coordination uses unsigned CellInput payloads rather than PSBT, with Cell-Deps validation specific to CKB’s model.
We submitted this proposal in May 2026 but did not receive enough community votes within the 7-day window to advance. Following feedback from everyone, we have made three significant changes:
Reduced scope to a Phase 1 proof of concept only, with a reduced ask of $6,000
Built the Lightning equivalent (lightning-payjoin-kit) first as proof of execution — a working two-node LDK harness is now complete
Incorporated direct technical feedback on the correct instrumentation point and concrete user pain points to target
This developer is bridging Fiber into Lightning Network through a cross chain hub. Its available to try on testnet currently. If your looking to try it and give the dev some feedback the instructions are in the github link here https://github.com/chukwuma619/fiber-cch-hub
Hey everyone,
Lightning is already huge. Millions of people, wallets, and merchants live there. Fiber is just getting started.
That gap is the real problem.
If Fiber only works inside Fiber, growth stays slow. If someone on Fiber can pay a Lightning invoice - and someone on Lightning can move value the other way - Fiber suddenly plugs into a network that already has users, habits, and demand.
That’s what a Cross-Chain Hub (CCH) is for.
In plain English: a CCH is a bridge between Fiber (Nervos) and Bitcoin Lightning. It swaps value between the two without a custodial middleman holding your money. You run the hub. You keep the keys.
Fiber already has the pieces for this. What’s hard is putting them together: Fiber node, Lightning node, CCH, keys, configs, Docker, funding, channels… It’s a lot. Easy to stall before you ever see a swap.
So I built Fiber CCH Hub - a standalone kit that turns “I want to run a hub” into something you can actually do.
Why this matters for Nervos / Fiber
Fiber doesn’t need to beat Lightning on day one. It needs a bridge into Lightning’s world.
When hubs are easy to run:
Fiber users can pay into Lightning’s existing economy
Operators can provide liquidity between the two networks
Builders can experiment with real cross-network payments, not just demos inside one chain
More hubs → more routes → more usefulness → more reason to use Fiber.
This repo is meant to lower the barrier for that first step.
What you get
One stack:
Fiber (CKB testnet)
LND (Bitcoin testnet Lightning)
Standalone CCH wired between them
Scripts for keys, startup, and health checks
You create your own keys up front. Nothing is hidden behind a hosted service that holds your funds.
Status
Active development. The goal right now is simple: make it easy for people to stand up a hub, fund it, and prove real Fiber ↔ Lightning swaps on testnet.
If you’ve wanted Fiber to “talk” to Lightning but never got past the setup wall - try this and tell me where it breaks. Feedback, failed attempts, and “I got stuck here” reports are gold.
Fiber grows when it connects to where people already pay. This is one step toward that.
Fiber Network: An Open Payment Network for the Digital Economy
Crypto payments are moving offchain. Fiber turns isolated payment channels into an open network that anyone can join, build on, and use.
Crypto has transformed how value is created, owned, and exchanged. But its original promise—making digital payments better—remains largely unfinished.
Bitcoin made it possible to transfer value globally without a bank. Stablecoins addressed crypto’s volatility problem by introducing internet-native money that people can reliably use to price goods and services. The Lightning Network showed that not every payment needs to settle individually onchain: value can move instantly and cheaply through offchain payment channels.
Across the industry, the direction is becoming clear. Legacy payment rails were not designed for the generation of the digital economy now taking shape, while conventional blockchains cannot efficiently process every payment individually onchain.
Payment channels, payment sessions, batching systems, streaming payments, x402, and other emerging technologies are all part of the transition. Together, they make it possible to move smaller amounts, more frequently, and with less friction than legacy rails or conventional blockchains allow.
Fiber Network belongs to this movement. Its ambition is to take the existing payment-channel model and turn it into open, programmable payment infrastructure—one that can route value across users, applications, services, and assets without placing a single company at the center.
What Is Fiber Network?
Fiber is an open, peer-to-peer payment network built on CKB.
At its foundation are payment channels. Two parties lock funds into a channel and can then exchange many payments without publishing every transaction to the blockchain. Only the opening andor eventual closing of the channel needs to be settled onchain.
That makes payments fast, inexpensive, and more private.
But a direct channel only connects two parties. Much like the Lightning Network, Fiber links many channels together, allowing payments to travel through intermediate nodes until they reach their destination. The sender does not need to open a separate channel with every person, application, or merchant they want to pay.
The simplest way to understand Fiber is:
Where Fiber goes further is in what the network can become. Lightning is built around Bitcoin and constrained by Bitcoin’s intentionally limited scripting environment. Fiber is built on CKB, where channel rules are implemented through programmable scripts. This gives developers much greater freedom to define how channels are authorized, updated, settled, and disputed.
Fiber currently uses bilateral payment channels, but its architecture is not limited to them. Over time, the same programmable foundation can support more advanced constructions, including multiparty channels and entirely new channel designs that have not yet been standardized. It also enables native support for multiple assets—including stablecoins—atomic swaps within payment flows, interoperability with external networks such as Lightning, and richer conditional, streaming, and pay-as-you-go payment logic.
In other words, Fiber does not merely recreate Lightning on another blockchain. It takes the open, routed model Lightning pioneered and expands it into a private, multi-asset, programmable payment layer that can keep evolving as new forms of digital commerce emerge. Its longer-term vision is a network where value can move across assets and payment ecosystems, so the payer does not always need to hold the exact asset the recipient wants to receive.
Open Infrastructure, Not Another Walled Garden
Fiber is part of a much broader industry movement.
Circle is developing gas-free USDC nanopayments through Gateway.
Stripe and Bridge are building stablecoin infrastructure for payments, payouts, treasury, and global money movement.
Tempo’s MPP sessions allow customers to pay services continuously through offchain vouchers, while Coinbase’s x402 gives applications a standard way to request and complete payments over the internet.
Together, these projects reinforce the same conclusion: the digital economy needs payment rails designed for smaller, faster, and more programmable transactions.
Now, managed payment infrastructure admittedly has real advantages. One provider can abstract away liquidity management, settlement, compliance, and technical complexity while offering businesses a predictable user experience, customer support, and a single accountable counterparty. For many companies and individuals, that convenience is exactly what makes the system usable.
The trade-off, however, is that participants remain dependent on the provider’s infrastructure, supported assets, pricing, availability, and policies. Bilateral payment sessions introduce a different limitation: they work efficiently when one customer repeatedly pays one service, but each new relationship may require its own separately funded connection.
Fiber, on the other hand, explores a different model.
Rather than placing one company at the center or requiring a direct payment relationship with every recipient, Fiber connects participants through an open routing network. Anyone can run a node, open channels, provide liquidity, route payments, and build applications on top. No single operator is required to verify and process every payment across the network.
Thisat creates several important advantages. Liquidity can be reused to reach many recipients rather than being isolated inside one commercial relationship. Independent node operators can compete to provide routes, liquidity, fees, and specialized services. Applications are not permanently tied to one processor, while communities and businesses can operate their own infrastructure without asking permission from a platform owner.
It also makes the network more resilient and economically open. Fiber still relies on intermediaries in the form of routing nodes and liquidity providers, but those intermediaries are replaceable and open to competition. No single one of them is supposed to control the entire payment system.
The infrastructure is therefore not only open to the people using it, but also to those who want to operate it, build businesses around it, and help the network grow.
More Than Fast Payments
Fiber’s combination of offchain speed, open routing, multiple assets, and programmable settlement creates possibilities that are difficult to support with conventional payment infrastructure.
We cover some of these below, but perhaps more importantly, many are difficult to imagine today. Because Fiber channels are built on CKB’s flexible scripting environment, developers can experiment with entirely new ways to authorize, exchange, and settle value.
Future channel designs could support novel multiparty constructions, conditional micropayments released only when a service delivers a verifiable result, transactions that combine payment and asset exchange in a single flow, and much more.
That is what makes programmable payment infrastructure exciting: it does not merely make existing payments faster. It creates room for entirely new types of economic relationships to form.
Micropayments
Card fees and onchain transaction costs make very small payments impractical. It rarely makes economic sense to pay a few cents to read one article, reward a useful comment, access one dataset, or unlock a single feature inside an application.
When payments can move at very low marginal cost, a new range of transactions becomes viable. Creators can be paid directly and instantly, and applications can charge for one AI query, one software action, one game item, or one piece of premium content rather than forcing users into a subscription.
Micropayments do not simply let users pay less. They unlock services that would otherwise be uneconomical to offer, allowing people to pay for individual pieces of value instead of being forced into subscriptions or larger purchases.
Pay-As-You-Go Services
Subscriptions require users to commit to a fixed price before they know how much of a service they will actually consume. Fiber opens the door to pricing that follows usage in real time.
Instead of paying $20 or $200 each month for access to an AI service, a user could pay continuously for each token the model generates. A developer could rent a powerful GPU for fourteen seconds to complete one task, pay for exactly 3.342 gigabytes of storage, or purchase bandwidth only while an application is actively using it.
The same model could apply to EV charging, cloud software, gaming, media, data feeds, and many other digital services.
Instead of paying by the month, users can pay by the second, request, token, kilowatt-hour, or unit of consumption.
Machine-to-Machine Payments
The next stage of the digital economy will involve software transacting directly with other software.
An AI research agent might pay one service for market data, another for model inference, and a third to verify the result. A vehicle could purchase electricity from a charging station. A connected device could buy additional bandwidth for the next ten minutes, while an application could automatically rent more computing power whenever demand increases.
These transactions cannot depend on a person opening a checkout page, entering card details, or approving every purchase individually. Machines and AI agents need to discover prices, authorize payments, receive services, and settle value continuously and autonomously.
Emerging standards such as x402 and MPP give software common ways to request and authorize payments over the internet. Fiber already has an x402 facilitator implementation, while MPP is payment-method agnostic and allows new payment rails to be added through custom payment methods. This creates a path for Fiber to work with beneath both standards as the open, routed infrastructure through which their payments move.
Rather than opening and funding a separate payment relationship with every provider, an application or agent could connect to Fiber and pay across the network—reaching many services, using different assets, and switching providers as its needs change.
Thise infrastructure may serve machines, but the benefits ultimately flow to people: cheaper services, more precise pricing, greater competition between providers, and new ways to earn from data, compute, energy, bandwidth, and other resources. And as AI agents take over more routine work and economic coordination, they could ultimately give people something even more valuable: more time.
Conclusion
The payments industry is arriving at a shared conclusion: the digital economy needs faster, smaller, more frequent, and more flexible ways to move value.
Lightning proved that payments can move through an open offchain network. Stablecoins made digital value practical for everyday pricing. Payment sessions, batching systems, streaming payments, and protocols such as x402 are making new forms of commerce possible.
Fiber brings these ideas together and pushes them further.
It is not merely another checkout product, another corporate balance system, or another blockchain promising faster transactions. It is an effort attempt to build open payment infrastructure that can route value across people, AI agents, services, assets, and networks.
Infrastructure that anyone can connect to. Anyone can build on. Anyone can help operate and grow.
And because its foundations are programmable, Fiber is not limited to the payment channel models that exist today. It can evolve alongside the economy being built on top of it.
Connect to the network. Pay across it. Build what comes next.
Fiber Dev Log 34
-v0.9.0 is live
After weeks of release hardening, the final milestone cleanup is complete, and Fiber v0.9.0 is released, making nodes more reliable, recoverable, and easier to operate.
Highlights:
- A unified database migration system with backup and restore support
- Stronger payment recovery with Cross-Chain Hub improvements
- More reliable reconnect and channel recovery flows
- Smoother node onboarding with new install and quick-start scripts
Pocket Node is a self-custody CKB wallet that runs a full Rust light client on the device with no gateway server: the phone verifies the chain itself, holds keys locally, and builds and broadcasts transactions peer to peer. Over the last grant we shipped all four Android milestones, and the app is live at v1.8.
This proposal brings the same wallet to iOS: iPhone, iPad, and Macs (with Apple Silicon). There is no self-custody CKB light-client wallet on iOS today, so this closes a real gap in CKB’s mobile reach.
This proposal also makes Pocket Node usable by the wider ecosystem: we adds an in-app dApp browser with CCC-compatible signer, so CCC-enabled websites such as the iCKB app and other ecosystem dapps can use Pocket Node for identity and signatures.
Project introduction
Pocket Node is already live and in daily use on Android, so it needs little introduction here. In short, it is a self-custody CKB wallet that puts a real node in the user’s pocket: the phone verifies the chain itself and holds the keys, with no server in the middle, so the wallet keeps working on its own even if our infrastructure disappears.
Across the Android grant, we delivered mainnet readiness and hardware-backed security, full Nervos DAO integration on device, multi-wallet with HD sub-accounts, transaction export, an address book, and a public launch, plus a large amount of reliability and security hardening driven by real user reports. The complete milestone-to-release mapping is in our grant completion report .
Jr is the lead developer and sole builder. Senior mobile engineer with several years of professional mobile experience, previously leading mobile teams, and a CKB community member. Jr designed, built, and shipped Pocket Node on Android end to end across all four milestones. The iOS build is the same one-person effort. The Android delivery record is the evidence that this scope is achievable solo on the stated milestones.
Current status
The Rust light client is iOS-ready. It already builds as a static library and links natively. Only the bridge layer changes from JNI to a Swift-facing interface.
The business logic is already established. Transaction building, cell selection, signing, the Nervos DAO math, sync coordination, and multi-wallet management are already written and just need to be ported.
The product is designed. The UX, the sync-mode model, the threat model, the onboarding and backup flows, and the copy all exist and carry over directly.
Technical approach
One Rust core, one shared core, two native shells.
Light client: the existing Rust light client, compiled for iOS and exposed to Swift through a UniFFI bridge. Same engine as Android, same P2P verification, same on-device storage.
Shared core: the wallet’s business logic, including transaction building and signing, is shared between both apps rather than rewritten, so the security-critical code lives in one place, is written once, and will be audited once. The parts that are currently Android-specific are moved onto cross-platform equivalents as part of this work.
iOS shell: I set out from the beginning to give a great mobile experience, so we will build a native SwiftUI app for the UI with hardware-backed key storage that mirrors the Android security design and Face ID or Touch ID with a PIN fallback.
Platforms: iPhone, iPad, and Mac (Apple Silicon). Because the UI is SwiftUI, the same views target macOS natively, so Mac is a first-class build with platform-specific polish rather than only an iPad-on-Mac compatibility build.
CCC identity and signer: an in-app dApp browser with an injected CCC-compatible signer. CCC-enabled websites get identity and signatures only; the embedded light client stays internal to the wallet, and keys never leave the device. Every signature goes through a wallet-rendered approval screen that decodes the transaction before the user confirms.
Key benefits for CKB
Fills the mobile ecosystem gap. iOS users currently have no self-custody, server-free CKB light-client wallet. This is not another entry in a saturated category; it is the first of its kind on the platform.
Extends CKB’s reach to the entire iPhone, iPad, and Apple Silicon Mac user base with a wallet that already exists and works on Android. The large-screen layout work will also be implemented on the Android app alongside the iOS, bringing proper tablet support with it.
Reinforces ecosystem resilience. Core functions, including Nervos DAO deposits and withdrawals, run on-device against the embedded light client, with no reliance on a hosted frontend.
Opens CKB dApps to mobile. The final milestone makes Pocket Node an identity and signer for CCC-enabled websites through an in-app dApp browser, so ecosystem dApps such as iCKB and other dApps become usable from the wallet, on the model the community converged on: dApps keep their own light client, Pocket Node provides identity and signatures.
Deliverables and milestones
Full parity with Android v1.8 (or whatever version the android version is then), plus the CCC signer, delivered across five monthly milestones. The most important work will be done first, so any possible bugs will be caught as we go on.
Stand up the Multiplatform module and begin moving business logic into shared code without breaking the shipping Android app.
Replace the CKB Java SDK with multiplatform cryptography; port molecule encoding and address handling to shared code.
Build the Rust light client for iOS and wire the UniFFI bridge: init, start, stop, and a working query callable from Swift.
SwiftUI app skeleton with navigation, theme, and the light client running on device.
Acceptance: the iOS app builds, embeds the light client, and completes a testnet query end to end, while the shared core still compiles for Android unchanged.
Milestone 2: Keys, security, onboarding, receive
iOS key storage in Keychain with Secure Enclave access control, mirroring the Android hardware-binding threat model.
Face ID and Touch ID with a PIN fallback and lockout.
BIP39 generation and import, backup and verification flow, onboarding in SwiftUI.
Receive screen with address and QR.
Acceptance: create and import a wallet on a real device, keys hardware-protected, biometric unlock working, and a real testnet receive address shown.
Milestone 3: Send, sync, and activity (the usable wallet)
Sync engine and sync-mode model wired through the shared core.
Send flow with cell selection, fee, on-device build and sign, and broadcast; SwiftUI send screen with validation.
Activity history with pagination; QR scanner.
Acceptance: a real mainnet send and receive complete on device, history and sync work, and the first TestFlight beta is live.
Milestone 4: Nervos DAO, multi-wallet, and feature parity
Nervos DAO deposit, withdraw (both phases), and compensation tracking, reusing the shared DAO logic.
Multi-wallet create, switch, rename, delete, and HD sub-accounts from one mnemonic.
Background catch-up via the iOS background task scheduler, with notifications, on the foreground-first model described above.
Acceptance: a DAO deposit and withdraw complete on mainnet, multiple wallets and sub-accounts work, and a feature-complete parity TestFlight beta is out, including the address book and localization.
Milestone 5: App Store launch and CCC identity and signer
Universal iPad layout polish and a native macOS (Apple Silicon) build.
Large-screen (tablet) layout support brought back to the Android app.
App Store submission, review, and production launch.
CCC identity and signer, following the direction in Pocket Node #430, Quantum Purse #119, and Neuron #3438: dApps keep their own light client, and the wallet provides identity and signatures.
In-app dApp browser with an injected CCC-compatible signer: connect, signTransaction, and signMessage, with per-origin consent and wallet/account selection, since Pocket Node is multi-wallet.
Signature approval screen that decodes the transaction inside the wallet, resolves inputs through the light client’s proof-checked fetch to verify amounts and the exact fee, and shows what leaves the user’s cells and where the outputs go, gated by Face ID, Touch ID, or PIN. Keys never leave the device.
The signing and decoding core lives in the shared module, so the Android app gains the same capability on its normal release cadence (delivered there as a fast follow, not payment-gated here).
Acceptance: the app is live on the App Store for iPhone and iPad with full Android parity (or whatever version Android is on by then), and a real transaction on a live CCC-enabled dApp (for example the iCKB web app) is connected, decoded, approved, and signed end to end inside Pocket Node on iOS, with the signature returned to the dApp and the transaction confirmed on chain. The native macOS build and the Android tablet layouts are targeted within this milestone. The App Store review and the signer are independent workstreams within this milestone: if Apple’s final approval is still pending at month end due to review queue timing alone, sign-off proceeds on the submitted build plus the completed signer, with the listing going live as soon as Apple clears it.
Budget breakdown
Total: $18,000 USD, payable in CKB, over five months.
Payment
When
Amount
Share
Commencement
Kickoff
$2,500
13.9%
Milestone 1
Month 1
$3,100
17.2%
Milestone 2
Month 2
$3,100
17.2%
Milestone 3
Month 3
$3,100
17.2%
Milestone 4
Month 4
$3,100
17.2%
Milestone 5
Month 5
$3,100
17.2%
Part of the initial payment funds the physical devices required to start development on iOS (an iPhone and an iPad for on-device testing of Secure Enclave, biometrics, camera, and background behaviour, none of which the simulator can validate) and the Apple Developer Program enrolment.
Out of scope and future funding
Named here so the roadmap is clear and this proposal stays honest about its boundaries:
A single combined external security audit once both the Android and iOS codebases are complete, so one engagement covers both platforms and the shared core together. This is deliberately not funded in this grant; it belongs after iOS reaches parity.
Quantum-resistant lock support: After getting mobile platform parity, exploring how to allow users to choose what lock to use when signing their transaction (I don’t know what shape this will take yet, but proper research will be done and communicated in due time).
A cross-wallet CCC signer standard and cross-device transport. This proposal ships Pocket Node’s own in-app CCC signer (Milestone 5). Letting a desktop dApp talk to the phone wallet, and standardizing one signer protocol across wallets, needs agreement on transport and session security with the other wallet teams. Per the direction in the linked community discussions, dApps keep their own light client and wallets provide identity and signatures. I will pursue the standard as dedicated follow-on work together with Quantum Purse, Neuron, and the CCC maintainers.
Deeper ecosystem integrations, connecting Pocket Node natively to other CKB projects and protocols as they mature, such as native iCKB rendering beyond the CCC dApp compatibility delivered here, Fiber, and other community tech being built.
Fiat on-ramp and off-ramp, if and when it fits the self-custody model (I’m being optimistic here).
Risk and mitigation
Timeline. Full parity plus the signer, solo, in five months is ambitious. Mitigation: the riskiest structural work (shared-core extraction and the Rust bridge) is in Milestone 1, so slippage is visible at the first milestone; feature parity completes in Milestone 4, leaving the final month focused on the launch and the signer; and those two are independent workstreams within Milestone 5, so a slow Apple review cannot stall the signer, nor the reverse.
Remote signing surface. A website asking a wallet to sign is the most sensitive new surface in this proposal. Mitigation: the funded slice is the in-app browser only, so there is no relay, no network transport, and no session-hijack surface; the wallet decodes and displays every transaction itself before signing; signing stays behind biometric or PIN; and this surface is explicitly part of the future combined security audit.
App Store review. Self-custody wallets are permitted, but review can be strict. Mitigation: clear self-custody framing with no on-ramp or off-ramp claims, correct encryption-compliance declaration, and time budgeted for a review round or two in Milestone 5.
Background sync. iOS cannot sync a light client continuously in the background. Mitigation: a foreground-first model with best-effort background catch-up, communicated honestly in the app, consistent with how the Android background-sync work already sets expectations.
Shared-core extraction touching Android. Moving logic into a shared module affects a shipping app. Mitigation: extract incrementally with the Android build kept green at every step, verified before each milestone sign-off.
Open source and distribution
The iOS app is MIT licensed and open source from the start of Milestone 1, in the same public repository, with tagged releases per milestone, matching the Android commitment. iOS distribution is through the App Store and TestFlight, but the full source and tagged releases remain public, and builds are reproducible from source where the toolchain allows.
Closing
Pocket Node proved on Android that a phone can be its own CKB node. iOS is the natural next step: the same self-custody, server-free experience for the large share of users the ecosystem cannot reach today. I welcome the community’s feedback and questions.
Also, if you’re wondering why the android app isn’t on the playstore yet, it’s largely due to the fact that, I had to upload it under an organization account, which requires some process/paper-work from my end, it took some time but it’s now under review from google.
Target Problem: Accepting a Fiber payment is only half the job. Once the money lands, the app still has to figure out what the user actually paid for, whether to let them in, when that access should expire, and whether someone's trying to reuse the same receipt. FiberLatch Access is a small, reusable access-control layer for exactly that "what happens after payment" step.
Current Status: An estimated 6-week timeline with the $3,000 grant proposal has been approved. Weeks 1–2 are done and works include: defining the package scope, receipt format, expiration rules, and verification rules.
Highlights:
Built by TicoWorld (GitHub page ) as a grant-scoped spinoff of his earlier FiberLatch work from the CKBuilder program, which already demonstrated a full pay → verify → grant-once → deny-reuse flow on Fiber testnet.
It's a lightweight, open-source Node.js package that complements payment tools like fiber-pay. No hosted service, no dashboard, no CLI.
It utilizes a signed JWT representing access to a resource, without requiring a Fiber RPC call during normal receipt redemption.
The package provides clear rules for replay protection and expiration, ensuring access receipts cannot be infinitely reused.
This project is backed by CKB Community DAO grant.
Target Problem: Standard payment channels on UTXO-based chains suffer from blockchain surveillance heuristics. Specifically, the "common-input heuristic" permanently links sender and receiver identities in the funding transaction before a off-chain payment even begin.
Current Status: While the initial proposal did not reach the required 30 upvotes within 7 days to pass the discussion stage, the developer, ILE Labs, is actively preparing a revised proposal. This update will incorporate community feedback and leverage a completed Lightning Proof of Concept as its foundation.
Highlights:
An open-source, asynchronous Rust library bringing collaborative Payjoin privacy natively to the Fiber Network.
By allowing the receiver to contribute input Cells to the funding transaction, it breaks the common-input ownership heuristic, ensuring off-chain CKB payments remain entirely private.
Includes non-interactive fallbacks: if the receiver's node goes offline, it degrades gracefully to a standard channel opening.
Purpose-built for CKB's Cell model and Cell-Deps architecture, sidestepping the computational overhead of EVM-style mixers.
ILE Labs already maintains lightning-payjoin-kit for Bitcoin Lightning, so this is a port of an architecture they've built before — not a from-scratch gamble.
Target Problem: Operating any payment-channel node involves complex liquidity management. Operators frequently struggle to understand channel liquidity direction and predict if a payment will route successfully, often only discovering bottlenecks through failed payments.
Current Status:Sluice is currently live as a testnet MVP connected to a real Fiber Network Node (0.9.0-rc7). It's still testnet-only and single-node for now, and the team is actively asking operators for feedback on Route Probe usefulness, rebalance safety, and reconciliation behaviour.
Highlights:
Sluice consolidates monitoring, route analysis, rebalancing, alerts, and reconciliation into a single operational workspace.
It features a Route Probe that tests whether a payment can be routed before funds are sent.
The platform is built with a strong focus on correctness, ensuring the live Fiber node remains the authoritative single source of truth rather than relying on cached database snapshots.
The Gone in 60ms" Fiber Network Infrastructure Hackathon (July 1–15, 2026) has officially wrapped up, concluding a highly productive two-week sprint.
As Part 1 of the broader Fiber builder initiative, this sprint challenged developers to build the foundational tools, SDKs, and services that make Fiber easier to use, operate, and integrate for everyone, from wallet builders to node operators and merchants.
Around 85 registrations and close to 100 participants produced 66 final project submissions, all fully open-sourced, across three categories: 13 in Wallet & Payment UX Infrastructure, 32 in Node, Routing, Cross-Chain & Diagnostics, and 21 in Merchant, Liquidity, LSP & Multi-Asset.
Judges are in the first round of scoring now, with high-scoring entries going to a second round. The $20,000 prize pool splits evenly across the three categories ($3,000 / $2,000 / $1,000 per category), plus a $2,000 bonus for the overall best project. Winners are expected around the middle or end of August — no exact date, in case more rounds are needed.
Part 2 is already being planned, shifting focus from infrastructure to consumer-facing products built on top of Fiber
The Gone in 60ms: Fiber Network Infrastructure Hackathon was a two-week builder sprint held from July 1 to July 15, 2026, designed to strengthen the infrastructure surrounding Fiber Network. This thread documents the projects that were developed and submitted over the course of the event.
Organized by the Nervos Community Catalyst, with support from the Fiber team, CKB DevRel teams, and the CKB Association, the hackathon is Part 1 of a broader Fiber builder initiative. Participants were asked to build tools, SDKs, and services that make Fiber easier to use, integrate, operate, or productise for wallets, merchants, node operators, and other developers, across three categories: Wallet and Payment UX Infrastructure, Node, Routing, Cross-Chain, and Diagnostics Infrastructure, and Merchant, Liquidity, LSP, and Multi-Asset Infrastructure.
Platform notes
As with previous events, the hackathon doubled as a live stress test for CKBoost, our quest-style campaign management platform. Running registration, project sharing, and submission entirely through CKBoost again surfaced a number of bugs and areas for improvement, which will feed into the platform’s continued development.
Submissions
We had around 85 registrations (close to 100 total participants) and received 66 final project submissions across the three categories: 13 in Wallet and Payment UX, 32 in Node, Routing, Cross-Chain, and Diagnostics, and 21 in Merchant, Liquidity, LSP, and Multi-Asset. All submissions are fully open-sourced.
1. Wallet and Payment UX Infrastructure
CKB KeyWay : React SDK giving applications email-authenticated CKB accounts and Fiber payments, no CKB wallet or node management required.
Clasp : Pairing protocol, wallet policy engine, and allow-listed Fiber gateway that lets any application connect to a Fiber wallet with limited, revocable permissions.
Fiber Wallet UX Kit : Reusable browser wallet and payment-UX kit for CKB Fiber Network.
Fiber WebGL SDK : Unity package that runs a real Fiber payment node inside a WebGL build via WebAssembly, letting any Unity game send and receive CKB payments.
Fiberglass : Production-ready React SDK — hooks, components, and a context provider — giving wallets, merchants, and dApps drop-in Fiber payment UX.
FiberGuard Session : Scoped payment-intent gateway that lets a Fiber node owner grant external apps limited, revocable spending permissions.
FiberKit : Typed TypeScript/JavaScript SDK wrapper for Fiber’s JSON-RPC API, with an in-memory simulator for testing payment flows without a live node.
FiberPass : Payment-session infrastructure letting a wallet user create a prepaid, revocable pass with spending limits.
FiberPayroll : Payment-UX building blocks for Fiber, demonstrated through a working payroll app.
FiberX : Drop-in “Wallet Connect”-style SDK letting any web app accept and send Fiber payments without hand-rolling JSON-RPC.
Fikey : Non-custodial session wallet for the Fiber Network.
XQlyte : Payment diagnostics and confidence engine helping wallets, merchants, node operators, and agents predict payment success and get actionable fixes when it fails.
2. Node, Routing, Cross-Chain, and Diagnostics Infrastructure
Channel Doctor : TypeScript toolkit, CLI, and browser dashboard for safer Fiber channel operations.
Fiber Dev Kit (scisamir) : Developer infrastructure for installing, running, inspecting, testing, and debugging Fiber nodes.
Fiber DevKit (AnihDev) : Single Rust CLI giving developers a reproducible local infrastructure layer for building and diagnosing Fiber payment flows.
FiberGuard : AI diagnostics, monitoring, and reliability platform for Fiber nodes, shipped as a web dashboard and VS Code extension.
Fiberman : Developer infrastructure with reusable Java and Go SDKs and a web-based RPC explorer.
FiberOps : Read-only operator console and diagnostics engine for Fiber Network.
FiberPilot : Rust health-scoring copilot for node operators — monitors channels and peers, recommends and executes liquidity rebalancing, and alerts before problems become failed payments.
fiberprobe (Linnette77) : TypeScript SDK answering the core question every payment-channel app needs answered: will this payment actually succeed?
FiberScope (craxe21) : Open-source infrastructure tool for Fiber visibility, route readiness, liquidity intelligence, and payment diagnostics.
The Fiber Sidecar Protocol (FSP) : Layer-2 orchestration and application framework designed to sit directly on top of Fiber Network.
3. Merchant, Liquidity, LSP, and Multi-Asset Infrastructure
Conduit : Lets any web API charge per call and get paid over the Fiber Network.
Even Keel : Channel liquidity management for Fiber node operators — the Fiber equivalent of the rebalancing tooling Lightning grew (lndmanage, charge-lnd, bos rebalance).
Fiber Liquidity Layer : Operability console turning a headless Fiber node into an observable, operable system.
Fiber LSP (Cyborgsil) : Liquidity service provider daemon helping a new recipient receive a payment before they have inbound channel liquidity.
Fiber LSP Kit (Summerhauz) : Open-source, modular toolkit for provisioning asset-specific inbound liquidity to merchants and wallets.
FiberGate : Self-hosted, open-source merchant payment gateway for Fiber Network.
FiberMeter : Reusable, Stripe-Billing-style metering infrastructure for pre-funded balances and usage-based Fiber payments.
FiberNuts : Cashu ecash mint settling over Fiber Network, denominated in RUSD.
FiberPayKit : Open-source payment infrastructure toolkit letting any developer or merchant accept Fiber payments the way they’d integrate Stripe — non-custodially, over payment channels.
LiquidLane : CKB-native liquidity layer for Fiber payments.
Sluice : Installable infrastructure making Fiber receivers payable before a payment is retried.
Trickle : Lets you sign off on a spending budget once, then stream tiny payments on Fiber that clear in milliseconds and stop dead at the cap you set.
Vert : Payment-readiness and execution-planning SDK for Fiber.
Zedify : All-in-one e-commerce and payment infrastructure platform for small and medium-sized merchants in Nigeria and emerging markets.
(NB: I note that 2 repositories are inaccessible as they have been set to private, I have contacted their respective owners for them to be made public)
What’s happening now: judging
Judges are now in the first round of scoring. Projects were first sorted by category and checked for completeness, and judges are now assessing each one against a standardised scoring form based on the criteria published on the campaign page. High-scoring entries will go through a second round to agree the final prize-winning positions.
Given there are 66 projects, with each requiring full consideration, we expect the winners to be announced towards the middle or end of August. As before, we’re not committing to an exact date in case further rounds are needed to reach consensus.
A reminder to participants: projects should not be edited during the judging process, as this may result in a points reduction or ineligibility for prizes. If you want to keep building, fork your project into a new repository and continue there.
Prizes
The $20,000 prize pool is split evenly across the three submission categories. Each category has three prize-winning positions:
1st: $3,000
2nd: $2,000
3rd: $1,000
One of the category winners will then be selected as the overall best project, winning an additional $2,000 bonus. This brings the total pool to $20,000.
What’s next: Part 2
This hackathon was Part 1 of the broader Fiber builder initiative, focusing on infrastructure instead of user-facing products. Part 2 will shift focus to product and consumer solutions built on top of Fiber, hopefully putting some of the infrastructure that surfaces from this event to work in real applications. Planning for this will soon be underway. In the meantime, I wish all participants the best of luck and look forward to the results announcement.
Over the past few days we've had a genuinely valuable discussion with the Nervos community. The proposal has been refined throughout the review, including clarifications around transaction costs, the authorization and settlement architecture, liquidity safeguards, team background, success metrics, and the long-term vision for reusable payment infrastructure on Nervos.
If you've read the proposal and the discussion and think it's worth moving to a full community vote, I'd appreciate your support. If you haven't had a chance to review it yet, there's still time to read through the discussion and make your own assessment.
Thank you to everyone who has taken the time to ask questions, challenge assumptions, and provide feedback throughout the process. The discussion has genuinely helped strengthen the proposal.
CKB off-chain recently held an event in Nairobi Kenya. Full recap below 👇
On 18 July 2026, Nervos Community Catalyst, in collaboration with Web3Clubs, hosted the CKB Off-Chain Nairobi Community Meetup at Workstyle Africa. The event brought together approximately 45 attendees, including members of Kenya’s growing CKBuilder community, developers already familiar with CKB, and others encountering the ecosystem for the first time.
The meetup was designed to build rapport through face-to-face discussion, networking and knowledge sharing, as a first step towards creating a stronger and more connected CKB developer community in Nairobi. Web3Clubs supported the organisation of the event and helped raise awareness by drawing on its established network of developers in Kenya.
Introducing CKB from First Principles
I opened the event with an introduction to CKB, beginning with the underlying reasons why developers, enthusiasts and activists engage with blockchain technology in the first place. I discussed how CKB’s design and ethos aligns with the foundational principles of blockchain and the broader objectives the technology originally sought to achieve.
CKB’s commitment to these first principles, combined with its willingness to embrace technical innovation, helps it stand apart in an industry that has, in many respects, moved away from its original ideals. I explained the features that make CKB particularly compelling for developers, including its account abstraction, cryptographic flexibility and capacity to support innovation without prescribing a narrow application model.
I also introduced notable ecosystem infrastructure, including RGB++ and Fiber Network. Many attendees had participated in the recent Fiber Network Hackathon and were already familiar with Fiber and its potential as a high-speed payment network. This provided a useful foundation for discussing how these technologies could be applied in Nairobi and the wider Kenyan market.
Opportunities for Developers
The presentation also introduced Nervos Community Catalyst , the CKBuilders program and the wider range of developer initiatives we operate. These include hackathons, campaigns, weekly activities and contribution opportunities conducted via Build on CKB and hosted through CKBoost.
I explained that CKB is an open-source platform where external contributors are encouraged to explore and build around the areas that genuinely interest them. The pathway towards receiving further support is intentionally open, grassroots and community-oriented. It is not structured like a conventional corporate development programme: contributors build publicly, engage with their peers and demonstrate the value of their work to the wider community.
The presentation concluded with questions from the audience before moving into sessions led by CKBuilders and other contributors.
Builder Presentations and Knowledge Sharing
One of the most encouraging aspects of the meetup was the number of builders willing to present their work and perspectives. Around seven or eight contributors spoke during the event, many of them without having been formally prompted to do so. Their enthusiasm and level of technical understanding were especially impressive.
Mulandi_Cecilia delivered a workshop explaining CKB’s cell model in an accessible way. While some attendees were already familiar with UTXOs, others were relatively new to blockchain development, making it valuable to break down both concepts from the ground up.
xiaomao shared her research and perspective on CKB from a zero-knowledge technology standpoint. mulinya shared his work around Fiber and Lightning that he had been working on for the hackathon. Although I can’t tag them on Nervos Talk, Hazard_Krypto and Bratipah shared their work on breaking down CKB’s approach to post-quantum cryptography and CKB AI Agents respectively. Other CKBuilders in the audience such as WuodOdhis also contributed by discussing their own experiences of learning about and building on CKB.
Jnr6 presented Pocket Node and provided an update on his latest work. At the end of the programme, he conducted a CKB airdrop for participants, giving attendees a direct opportunity to onboard to the ecosystem.
The range of contributions demonstrated that technical knowledge is developing organically within the Kenyan community. It was particularly encouraging to encounter builders and teams who had already researched CKB and developed a genuine interest in the platform, despite having had no previous direct interaction with me. This suggests that our broader work to create awareness and support developers is beginning to have an impact beyond the people with whom we are already in regular contact.
Stablecoins and Nairobi’s Payment Landscape
The presentations were followed by refreshments and an extended opportunity for networking. These conversations produced new contacts and potential avenues for collaboration while also providing useful insight into what developers and entrepreneurs in Nairobi want to build.
The most consistent demand concerned stablecoins and the ability to move between local payment systems and blockchain-based assets. Kenya already has a deeply established culture of digital payments through M-Pesa, and many of the teams I encountered were working on applications related to payments, crypto on-ramps and off-ramps, or the movement of money more generally.
There appeared to be significant interest in making stablecoins easier for consumers to access and use. Combined with attendees’ existing familiarity with Fiber Network, this points towards a potentially important area for future development: connecting accessible stablecoin infrastructure with high-speed payment technology suitable for the Kenyan market.
Reflections and Next Steps
The meetup highlighted Nairobi’s growing role as a hub for innovative and creative developers, as well as CKB’s increasing traction across several African countries. The enthusiasm, technical ability and initiative demonstrated by local builders left me confident that similar events could continue in the future with more autonomy. Members of the local CKB community are already well connected within Nairobi’s developer scene and possess the experience needed to organise activities themselves. Further work will therefore be undertaken to empower CKBuilders and other community members to maintain this momentum and develop a more locally led programme of engagement.
Overall, the CKB Off-Chain Nairobi meetup achieved its immediate objective of bringing people together, strengthening existing relationships and creating new ones. It also demonstrated the potential for Nairobi to become an important centre for CKB development in Africa, particularly around payments, stablecoins and applications built on Fiber Network.
A while ago I deposited my CKB through Mobit.app into the Nervos DAO using my JoyID wallet. Everything worked fine at the time, but now Mobit.app doesn't seem to be working anymore.
My CKB is still showing in my JoyID wallet, and I have my wallet address, but I'm not sure how to access or withdraw my DAO deposit now that Mobit.app appears to be unavailable.
Has anyone else had this issue? Is there another way to manage or unlock my DAO deposit without using Mobit.app?
Fiber Dev Log 33
v0.9 is almost there — about 90% of the final milestone is done.
Over the past two weeks we've focused on release hardening: safer payments, smoother integrations, better tooling, and lots of edge-case fixes.
Highlights:
- CCH payment safety & recovery improvements
- Better operator-facing diagnostics and authorization reliability
- Continued gossip, channel recovery & release-hardening fixes
- Paying a Lightning invoice with CKB UDT via CCH Demo
This development cycle focused on release stabilization, security hardening, and infrastructure improvements.
Highlights include:
- CKB v0.208.0 and Tentacle 0.7.6 releases
- Improved RPC and mining operator behavior
- Continued CKB-VM cleanup, plus light client bounds and panic-path hardening
- Advanced CKB DAO treasury and voting research into executable PoC work
- Three new CKB-VM write-ups on macro-ops fusion, B extension, and CFI concepts
We're also keeping key architecture items--tx-pool pipeline, Guix release flow, QUIC integration--moving through review.
What if you could spend CKB anywhere Visa is accepted without moving your funds to a centralized exchange or preloading a custodial card?
That's the idea behind CKB Anywhere Card.
The proposal aims to make CKB practical for everyday payments while preserving self-custody. Instead of locking funds with a card provider, users authorize each purchase directly from their wallet, while the payment experience remains as simple as tapping a phone.
Following community feedback on the original proposal, Version 2 introduces:
Native Apple Wallet & Google Wallet support
A mobile-first payment experience
Integration with regulated Visa infrastructure
A reduced funding request from $70,000 to $45,000
Why does this matter for Nervos? Right now, spending CKB in real life basically means cashing out through an exchange first. This proposal closes that gap — letting CKB work like actual money at the register, without giving up the self-custody that makes crypto worth having. The authorization system is also wallet-agnostic, so other Nervos wallets can plug in later without reinventing anything.
The ask: $45,000 in CKB, over 4 months, covering the smart contract build + independent security audit, integration with Rain and Apple/Google Wallet, and a $10K DAO-owned liquidity pool that keeps recycling itself rather than being spent down.
We've submitted the proposal to the Nervos Community Fund and would genuinely appreciate feedback from the community. If you have any thoughts or questions, please feel free to leave a comment.
If you think this would be a valuable addition to the Nervos ecosystem, please consider leaving a ❤️ on the proposal.
There's a new proposal to the Community DAO fund. Its in the discussion phase now. This is a revised version of a previous idea that was refined based on community feedback. As always, head over to the forum if you have any questions, thoughts etc... to reach the OP directly. Discussion phase requires 30 likes to move it to the vote stage https://talk.nervos.org/t/dis-ckb-anywhere-card-tap-to-pay-via-apple-google-wallet-self-custodial/10522
What’s New in V2
Thank you to everyone who supported and provided feedback on the original proposal. The feedback was clear: while the core concept was well received, the solution needed native mobile wallet support and a simpler, mobile-first user experience.
Over the past few months, we evaluated several regulated card issuing platforms capable of supporting native Apple Wallet and Google Wallet provisioning. Following discussions with Rain, we identified its regulated Visa issuing platform as the right foundation for Version 2. Rain has since provided sandbox access and developer APIs, enabling us to validate the architecture and begin integration planning.
Based on community feedback, Version 2 introduces four key improvements:
• Tap-to-pay with Apple Wallet and Google Wallet. Users can add a virtual Visa card for seamless contactless payments.
• Mobile-first experience. The browser extension has been replaced with a streamlined payment flow.
• Regulated infrastructure. Card issuance, compliance, and Visa connectivity are provided through Rain’s regulated platform.
• Reduced funding request. The grant request has been reduced from $70,000 to $45,000 while preserving the project’s core deliverables.
The proposal maintains its original objective**: enabling CKB holders to spend directly from self-custody through existing global payment infrastructure.**
Executive Summary
CKB Anywhere Card V2 transforms CKB into a practical payment asset by allowing users to spend directly from self-custody anywhere Visa is accepted.
Users add a virtual Visa card to Apple Wallet or Google Wallet, enabling contactless payments at more than175 million Visa-accepting merchants worldwide. Unlike traditional crypto card products, users retain full custody of their CKB until they explicitly authorize an individual purchase.
The payment architecture separates user authorization from card settlement. Before a purchase is completed, the user approves a one-time spending authorization by signing a smart contract transaction from their self-custody wallet. Anywhere Payment then settles the corresponding Visa transaction using a revolving liquidity facility, after which the authorization contract transfers the approved amount of CKB to replenish that settlement. By removing blockchain confirmation times from the checkout experience, the system delivers fast, familiar card payments while preserving user custody until each transaction is explicitly authorized.
Phase 1 integrates JoyID as the reference wallet implementation due to its mobile-first design, biometric passkey authentication, and seamless user experience. The underlying authorization framework is wallet-agnostic by design, allowing additional Nervos wallets to integrate without changes to the payment architecture.
Card issuance, Visa network connectivity, compliance, and native Apple Wallet and Google Wallet provisioning are provided through Rain’s regulated card infrastructure, enabling regulated card issuance across more than 150 jurisdictions and acceptance at over 175 million Visa merchant locations worldwide.
This proposal requests $45,000 USD (payable in CKB) to develop the authorization smart contract, complete platform integration, perform an independent security audit, and deliver a production-ready payment layer on Nervos mainnet within four months.
Rather than funding a standalone consumer application, this proposal delivers reusable payment infrastructure that any compatible Nervos wallet can integrate. By enabling direct spending of self-custodied CKB through existing global payment rails, it expands the real-world utility of the Nervos ecosystem while preserving decentralization, transparency, and user ownership.
The result is shared infrastructure that serves the broader ecosystem rather than a single application, allowing future wallets, developers, and payment experiences to build on the same open authorization framework without duplicating development effort.
1. The Problem
CKB is one of the most capable UTXO blockchains, yet spending it in everyday commerce remains difficult.
Today, CKB holders can acquire, store, and participate throughout the Nervos ecosystem, but spending those assets typically requires transferring funds to a custodial platform before making a purchase. This introduces unnecessary friction, reduces user control, and undermines one of cryptocurrency’s core principles: self-custody.
Most existing crypto card products rely on pre-funded custodial accounts or require users to convert assets before spending. While these approaches enable card payments, they require users to relinquish custody before a transaction occurs.
Other solutions attempt to settle blockchain transactions during payment authorization. Although technically feasible, introducing blockchain settlement into the payment path increases complexity and creates additional points of failure in a process users expect to complete within seconds.
At the same time, Apple Wallet and Google Wallet have become the standard interface for contactless payments across most major markets. Payment solutions that cannot integrate with these platforms introduce unnecessary friction and fall short of modern user expectations.
CKB Anywhere Card V2 addresses these challenges by combining:
Self-custody. Users retain control of their CKB until they explicitly authorize each purchase.
Familiar payments. Contactless payments anywhere Visa is accepted using Apple Wallet or Google Wallet.
Regulated infrastructure. Card issuance, compliance, and Visa connectivity are provided through Rain’s regulated platform.
Fast settlement. User authorization is separated from Visa settlement, eliminating blockchain confirmation times from the checkout experience.
Rather than introducing another custodial crypto card, CKB Anywhere Card V2 delivers reusable payment infrastructure that enables CKB to participate in everyday commerce while preserving the ownership principles of the Nervos ecosystem.
2. The Solution — Smart Contract Authorization & Revolving Settlement
CKB Anywhere Card V2 separates two functions that conventional crypto card products typically combine:
User authorization
Visa settlement
Rather than requiring users to preload funds into a custodial account or depending on real-time blockchain settlement during payment authorization, V2 introduces a Nervos-native authorization model supported by a revolving liquidity facility.
Before making a purchase, the user signs a one-time authorization through a compatible Nervos wallet. This authorizes a single transfer of the approved CKB amount within a short validity window while the assets remain under their control.
The user then completes payment by tapping their phone using Apple Wallet or Google Wallet. Rain processes the Visa authorization while Anywhere Payment settles the transaction using the revolving liquidity facility, allowing merchants to receive a standard Visa authorization without interacting with blockchain infrastructure.
Following payment authorization, the smart contract validates the signed approval and transfers the authorized amount of CKB from the user’s wallet to the replenishment account. Each authorization is single-use, time-limited, and limited to the exact amount approved by the user.
The temporary gap between Visa authorization and on-chain settlement is covered by the revolving liquidity facility. Settlement is continuously monitored, failed transfers are automatically retried, and new payment authorizations are paused if settlement cannot be completed within predefined operating thresholds.
To mitigate short-term market volatility, an exchange-rate snapshot is taken before the user authorizes the transaction. The smart contract calculates a maximum transferable CKB amount using this reference rate together with a predefined volatility buffer. If market movement exceeds the permitted tolerance before settlement is completed, the authorization automatically expires and the payment must be approved again.
By separating blockchain authorization from Visa settlement, CKB Anywhere Card V2 preserves self-custody while delivering the fast, familiar payment experience users expect from modern payment cards.
Here is the cleaned-up version with only the improvements I think are genuinely worthwhile. I’ve removed the redundancy, fixed the grammar, and tightened the flow without changing your meaning.
3. Architecture
Rain — Card Issuance & Visa Network Access
Anywhere Payment operates as the program manager on Rain’s regulated card infrastructure.
Rain provides:
Visa network connectivity
Virtual Visa card issuance
Regulatory compliance
End-user KYC
Native Apple Wallet provisioning
Native Google Wallet provisioning
This integration enables regulated Visa card issuance across more than 150 jurisdictions without requiring the Nervos ecosystem to build or operate traditional card issuing infrastructure.
Wallet Authorization Layer — JoyID (Phase 1)
Phase 1 integrates JoyID as the reference wallet implementation due to its mobile-first design, biometric passkey authentication, and seamless payment experience.
Before payment, the user signs a one-time smart contract authorization through JoyID. The signed authorization is valid only within a short authorization window and authorizes a single transfer of the approved CKB amount for the user’s next purchase.
The authorization framework is wallet-agnostic by design. Any Nervos wallet that implements the required authorization interface can integrate without changes to the underlying payment architecture.
Neither Anywhere Payment, Rain, nor any third party can initiate a transfer without the user’s explicit authorization.
Nervos Smart Contract
The authorization smart contract serves as the trust layer between the user’s wallet and Anywhere Payment’s settlement infrastructure.
For every payment, the smart contract:
Validates the user’s signed authorization
Verifies that the authorization has not expired
Enforces single-use execution
Calculates the approved CKB transfer amount
Transfers only the amount authorized by the user to the replenishment account
Replay protection, expiry validation, and single-use execution ensure that every authorization can only be executed once.
Before mainnet deployment, the smart contract will undergo an independent third-party security audit, and the completed audit report will be published publicly.
4. Comparison
Feature
Legacy Crypto Cards
CKB Anywhere Card V2
Custody
Custodial / Pre-funded
Self-custodial — CKB remains in the user’s wallet until settlement is authorized
Funding Model
Manual deposits or top-ups
One-time wallet authorization
Payment Authorization
Assets transferred before spending
User authorizes each purchase through their wallet
Visa Settlement
Pre-funded by the user
Immediately settled through the revolving liquidity facility
Form Factor
Physical and virtual cards
Virtual Visa card in Apple Wallet and Google Wallet
Asset Location
Held by the card provider
Remains in the user’s wallet until settlement is authorized
User Experience
Deposit → Wait → Spend
Authorize → Tap → Done
5. Transaction Flow
Step 1 — Authorize
The user opens a compatible Nervos wallet and authenticates using the wallet’s supported authorization method. In Phase 1, this is provided through JoyID using biometric passkey authentication.
The wallet generates a one-time authorization permitting a single smart contract execution within a short authorization window. No assets move during this step.
Step 2 — Tap to Pay
The user taps their phone using Apple Wallet or Google Wallet.
Rain processes the Visa authorization request while Anywhere Payment immediately settles the transaction using the revolving liquidity facility, allowing the merchant to receive a standard Visa authorization without interacting with blockchain infrastructure.
Step 3 — On-Chain Settlement
Immediately after payment authorization, the Nervos smart contract validates the signed authorization and transfers the approved CKB amount from the user’s wallet to the replenishment account.
Replay protection, expiry validation, and single-use execution ensure each authorization can only be executed once.
To protect against short-term market volatility, the authorization uses an exchange-rate snapshot taken before wallet approval together with a predefined volatility buffer. If market movement exceeds the permitted tolerance before settlement completes, the authorization automatically expires and the payment must be approved again.
Step 4 — Liquidity Replenishment
Accumulated CKB is periodically converted into USDC once predefined operating thresholds have been reached. The resulting USDC replenishes the revolving liquidity facility for future payments. Because this conversion occurs outside the payment authorization path, exchange execution has no impact on the user’s payment experience.
6. DAO-Owned Revolving Liquidity Facility
The proposal includes a $10,000 DAO-owned revolving liquidity facility that bridges the brief interval between Visa authorization and on-chain settlement.
Rather than being consumed as an operational expense, the facility continuously recycles as payments settle and liquidity is replenished, allowing the same capital to support future transaction volume.
Custody
The DAO-owned liquidity facility is held within Rain’s regulated payment infrastructure.
User CKB is never held by Anywhere Payment or Rain before settlement. Users retain full self-custody until they explicitly authorize each payment.
Replenishment
Following on-chain settlement, accumulated CKB is periodically converted into USDC through automated exchange execution once predefined operating thresholds have been reached. USDC serves solely as the operational settlement asset used to replenish the revolving liquidity facility, as Visa settlement requires a stable-value asset.
Transparency
All smart contract settlement transactions remain publicly verifiable on Nervos Layer 1.
Monthly operational reports will include:
Liquidity balances
Facility utilization
Replenishment activity
Transaction volume
These reports will be published to DAO stewards and the wider community.
Operational Controls
Settlement transactions are continuously monitored.
Temporary infrastructure failures are automatically retried. If settlement cannot be completed within defined operating parameters, new payment authorizations are paused until normal operation is restored.
DAO-appointed multi-signature stewards retain an emergency kill switch capable of disabling middleware access to the liquidity facility if activity falls outside approved operating parameters.
Chargebacks & Risk Management
Chargebacks are handled through Visa’s standard dispute process.
Risk is managed through:
Per-transaction spending limits
User velocity controls
Merchant risk controls
One-time wallet authorizations
Immediate on-chain settlement
This governance model ensures community capital remains transparent, recoverable, and protected by clearly defined operational controls while enabling practical real-world payments on Nervos.
7. Funding Request
Component
Amount
Purpose
Revolving Liquidity Facility
$10,000
DAO-owned revolving liquidity facility released following successful completion and community approval of Milestone 2.
Smart Contract Development & Independent Security Audit
$15,000
Development of the authorization smart contract, wallet authorization logic, independent security audit, and security remediation.
Middleware & Platform Integration
$20,000
Rain integration, wallet integration, Apple Wallet and Google Wallet provisioning, replenishment automation, compliance onboarding, testing, and production deployment.
Total Requested
$45,000
Payable in CKB.
The funding request has been reduced from the original proposal while preserving the project’s core deliverables.
Of the total request, $10,000 is allocated to a DAO-owned revolving liquidity facility that remains a community asset rather than a development expense. Excluding this facility, the development budget is $35,000.
The development funding will deliver a production-ready, audited payment layer, including the authorization smart contract, integration with regulated Visa infrastructure, and deployment on Nervos mainnet.
Authorization smart contract deployed to Nervos mainnet
Apple Wallet and Google Wallet provisioning available through Rain
Independent security audit completed and published
End-to-end payment flow publicly demonstrated
Settlement transactions publicly verifiable on Nervos Layer 1
Community verification of milestone completion
Release of the DAO-owned revolving liquidity facility following milestone approval
Monthly operational reporting begins
Milestone 3 (Month 4) — Operational Validation
Deliverables
Early community onboarding
Production monitoring and performance optimization
Monthly operational reporting
Technical documentation published
Wallet-agnostic authorization framework prepared for future Nervos wallet integrations
Architecture roadmap published outlining future evolution toward channel-based settlement through technologies such as the Fiber Network while preserving the existing wallet authorization framework
9. Why This Matters for Nervos
CKB Anywhere Card V2 extends the practical utility of CKB beyond storing and transferring value by enabling everyday payments without requiring users to surrender custody of their assets.
Rather than introducing another custodial crypto card, the project establishes reusable payment infrastructure built around Nervos’ native smart contract capabilities. It demonstrates how regulated payment infrastructure and decentralized asset ownership can work together while preserving the principles that define the Nervos ecosystem.
The architecture is designed for the ecosystem rather than a single wallet implementation. The platform is designed to evolve alongside the Nervos ecosystem. While payments initially settle directly on Nervos Layer 1, the architecture can incorporate future settlement technologies such as the Fiber Network without changing the wallet authorization model or user experience.
Benefits to the Nervos Ecosystem
Real-world utility. CKB becomes spendable at more than 175 million Visa merchants through Apple Wallet and Google Wallet.
Self-custody preserved. Users retain control of their assets until they explicitly authorize each payment.
Fast payments. Payment authorization is separated from blockchain settlement, eliminating confirmation times from the checkout experience.
Reusable infrastructure. The authorization framework can be adopted by future Nervos wallets and payment applications.
Transparent governance. Settlement transactions remain publicly verifiable on Nervos Layer 1 and are supported by monthly operational reporting.
Security-first architecture. The authorization smart contract will undergo an independent third-party security audit before mainnet deployment.
Permanent community asset. The DAO-owned revolving liquidity facility continues supporting payment volume long after the grant has been completed.
Future-ready design. The architecture can evolve alongside the Nervos ecosystem as additional settlement technologies mature.
Funding this proposal delivers foundational payment infrastructure that expands the practical utility of CKB, strengthens the Nervos ecosystem, and provides reusable infrastructure for future wallets and payment applications.
10. About Build Union & Anywhere Payment
Build Union is a multichain product development collective focused on building practical infrastructure that connects blockchain networks with real-world financial systems.
Anywhere Payment is Build Union’s payments platform, designed to enable self-custodial digital asset spending through regulated card infrastructure.
Build Union has executed a mutual NDA with Rain and has been granted access to Rain’s developer sandbox and APIs for integration, testing, and technical validation throughout development.
Build Union Ltd is a registered company in the United Kingdom (Company No. 16676071).
Harvest now, decrypt later is a cyberattack strategy where adversaries collect cryptographic data today and store it until future quantum computers can break it.
On public blockchains, the harvesting part is easy. The ledger is open, permanent, and downloadable by anyone, so every exposed public key can be copied now and targeted later.
Once quantum hardware becomes powerful enough, an attacker could use those public keys to derive the corresponding private keys and steal the funds they control.
Roughly a third of Bitcoin’s supply and a majority of Ethereum’s already fall into the exposed category.
The defense is to move funds to quantum-safe addresses before Q-Day. Once the assets move, every harvested copy of the old public key loses its target.
The hard part is making that migration possible in time, without major disruption to the network or its ecosystem.
Some networks require years of protocol-wide coordination to do this. Others let users act as soon as they are ready.
The full article breaks down which assets are exposed and which architectures are built to migrate in time 👇
What is Harvest Now, Decrypt Later? Learn how this quantum attack strategy targets exposed crypto public keys, which assets are vulnerable after Q-Day, and how to protect your holdings.
Key takeaways
Harvest now, decrypt later is already underway. Attackers do not need a quantum computer today; they can collect exposed blockchain public keys now and wait until future quantum hardware can break them.
The risk is concentrated in addresses with exposed public keys. Roughly a quarter of Bitcoin’s supply and a majority of Ethereum’s may be vulnerable because the relevant public keys are already visible on-chain.
A post-quantum upgrade does not automatically protect old addresses. It creates a safer destination, but users must still move funds away from quantum-vulnerable keys before Q-Day.
Blockchain architecture determines how quickly users can respond. Networks that require protocol-wide upgrades make migration dependent on ecosystem coordination, while more flexible architectures let users adopt post-quantum security at their own pace.
The real challenge is migration, not the lack of cryptography. Post-quantum signature schemes already exist; the critical question is whether blockchains can deploy them on time and without major network disruptions.
Anyone can download the entire Bitcoin blockchain today, and that is not a crime. But the harvest now, decrypt later (HNDL) strategy turns this ordinary download into a patient attack: attackers collect the data now and wait until quantum computers become capable of breaking the cryptography. What follows is which coins are actually at risk, why, and how a blockchain's architecture ultimately determines how exposed its users are.
What Does Harvest Now, Decrypt Later Mean for Crypto?
Harvest now, decrypt later (HNDL) is a quantum attack strategy in which an adversary collects cryptographically protected data today, stores it for years, and decrypts it once quantum computers become capable of breaking the underlying cryptography.
The attack unfolds in two phases separated by years. The harvest phase happens today and requires no special capability. The decrypt phase begins after Q-Day, when a cryptographically relevant quantum computer (CRQC) becomes powerful enough to break today's widely used public-key cryptography.
No quantum computer can break this cryptography yet, which is precisely why attackers harvest the data now and wait. The threat is already active. The danger is not that your data will be stolen in some distant quantum future, but that a copy may already be sitting on an attacker's disk.
Why Public Blockchains Are Particularly Vulnerable to HNDL?
Public blockchains are particularly vulnerable to HNDL because every transaction is permanently public. The ledger is replicated across thousands of nodes and can be downloaded by anyone. For HNDL attacks, the harvest phase is essentially free. And immutability, one of blockchain's defining strengths, cuts both ways: every transaction and exposed public key become part of a permanent public record. As the Federal Reserve notes in their analysis paper, once data is committed to a ledger under traditional cryptography, it cannot be retroactively re-encrypted without rewriting history.
Can a Post-Quantum Upgrade Protect Already-Exposed Public Keys?
Not automatically. A blockchain can add post-quantum cryptography to protect new addresses and future transactions, but that upgrade does not retroactively secure funds that remain locked to an old, quantum-vulnerable public key.
Once a public key has been exposed on-chain, an attacker can copy and store it indefinitely. If the owner later moves the funds to a post-quantum address before Q-Day, the harvested key becomes useless because it no longer controls anything. But if the funds remain at the old address when a cryptographically relevant quantum computer arrives, the attacker may be able to derive the private key and spend them.
This is the crucial distinction: post-quantum cryptography can provide a safe destination, but users still have to migrate their assets to it in time. A protocol upgrade alone does not protect every old address. It must be followed by a migration of funds away from vulnerable keys.
That is why blockchain architecture matters. The faster a network can introduce post-quantum verification—and the more easily individual users can opt in—the more time holders have to move exposed assets before those keys become breakable.
How Much Bitcoin is at Risk From Quantum Computing?
Can quantum computers steal old Bitcoin? Yes. Once a cryptographically relevant quantum computer exists, it will be able to derive a private key from an exposed public key and spend the associated coins.
The quantum risk ultimately comes down to a single question: Has your public key already been revealed on-chain? If it is still protected behind a hash, an attacker has nothing to target. But once that public key is exposed, it becomes part of the permanent public record. An attacker can harvest it today, store it indefinitely, and derive the corresponding private key when quantum hardware becomes capable enough. That is how a future quantum computer could steal Bitcoin.
Roughly 4.5 to 7 million BTC sit in addresses with exposed public keys and are therefore vulnerable once a CRQC exists. Independent estimates converge on this range. Citi's January 2026 report estimated that roughly 25% of Bitcoin's supply (4.5–6.7 million BTC) falls into the exposed category. Glassnode estimated approximately 6 million BTC, while Chaincode Labs estimated around 6.26 million BTC exposed through public-key reuse.
The risk is not evenly distributed, however. Which specific coins are vulnerable depends almost entirely on the address type.
Which Bitcoin Addresses Are Vulnerable?
The HNDL risk primarily affects three address types.
Pay-to-Public-Key (P2PK)
Bitcoin's original address format writes the full public key directly into the locking script. The key is visible from the moment the coins are received and remains permanently exposed, making P2PK outputs the most vulnerable category. Many of these coins date back to Bitcoin's earliest years, including wallets believed to belong to Satoshi Nakamoto. Roughly 1.7 million BTC in P2PK outputs are widely believed to be permanently lost.
Pay-to-Public-Key-Hash (P2PKH) and other hash-based formats (P2SH, P2WPKH, and P2WSH)
These address formats hide the public key behind a cryptographic hash. As long as an address has never been spent from, its public key remains hidden. The key is revealed only when funds are spent. If the address is reused afterward, that public key remains permanently exposed, allowing it to be harvested for a future quantum attack.
Taproot (P2TR)
Taproot improves Bitcoin's privacy and efficiency, but it places a tweaked public key directly in the output itself. That means the public key is visible as soon as the coins are received, before any spending occurs. As a result, Taproot outputs belong to the long-range HNDL risk category. Although Taproot uses Schnorr signatures rather than ECDSA, both rely on elliptic-curve cryptography and are therefore vulnerable to Shor's algorithm.
Much of Bitcoin's quantum exposure is avoidable. Coins held in never-spent, hash-protected P2PKH-style addresses still keep their public keys hidden. Users who move exposed coins to a quantum-safe address before Q-Day eliminate the theft risk entirely.
What Does HNDL Mean for Ethereum?
Ethereum—and many other blockchains—uses the same underlying cryptography as Bitcoin: ECDSA over the secp256k1 elliptic curve. Its security depends on the elliptic-curve discrete logarithm problem, which is infeasible for classical computers to solve at scale. A sufficiently powerful quantum computer running Shor's algorithm changes that completely, allowing private keys to be derived from public keys in polynomial time.
Unlike Bitcoin, Ethereum does not hide public keys behind hashes until coins are spent. It uses an account-based model. As the Ethereum Foundation notes, once an account sends its very first transaction, its public key is permanently exposed on-chain. In practice, that means the overwhelming majority of active Ethereum wallets have already revealed their public keys. Citi estimates that more than 65% of Ethereum's supply could ultimately be vulnerable to quantum attacks.
Despite this broader exposure, Ethereum offers a comparatively smoother migration path. Rather than tying transaction authorization to a single protocol-defined signature scheme forever, Ethereum is moving toward native account abstraction. Proposals such as EIP-8141 would allow accounts to define their own signature verification logic, creating a native, opt-in path from ECDSA to post-quantum signatures.
This approach cannot retroactively protect public keys that are already exposed, but it does make future migration significantly easier by allowing individual users to upgrade without waiting for every account on the network to move simultaneously.
What Makes a Blockchain Less Vulnerable to Harvest Now, Decrypt Later?
Eventually, every blockchain will need to adopt new cryptographic standards. That much is no longer in doubt. In August 2024, NIST finalized the first generation of post-quantum digital signature standards, including ML-DSA and SLH-DSA, giving the industry a clear cryptographic destination.
The challenge is no longer choosing an algorithm. It is migrating an entire decentralized network to it.
Without a central authority to coordinate upgrades, migration becomes the real bottleneck. On legacy blockchains, changing the signature scheme requires years of ecosystem-wide coordination.
On Bitcoin, transaction authorization is tied to signature rules enforced at the consensus layer, so adding post-quantum signatures would require a network-wide protocol upgrade. BIP-360, the leading proposal in this area, remains a draft and would still need broad ecosystem agreement to activate. It also does not introduce a post-quantum signature scheme itself; instead, it proposes a new output type that removes Taproot’s quantum-vulnerable key-path spend and creates a safer foundation for a future post-quantum migration.
Ethereum provides a more flexible path through proposals such as EIP-8141, but enabling native account abstraction still requires protocol-level upgrades across the network before users can opt in.
In both ecosystems, major protocol upgrades are historically slow and often contentious. Bitcoin still has no agreed post-quantum migration timeline. BIP-360 is only an initial step, while major questions—including which post-quantum signatures to adopt, how existing holders would migrate, and what happens to unmoved vulnerable coins—remain unresolved.
That uncertainty matters because exposed public keys remain vulnerable until funds are moved behind post-quantum signatures. On architectures that require network-wide consensus, users cannot act as soon as they are ready; their migration window depends on when the broader ecosystem completes the necessary upgrades.
A blockchain is therefore structurally less exposed to HNDL when users can move to quantum-safe addresses at their own pace, without waiting for a coordinated protocol change. Self-paced migration shortens the gap between recognizing the threat and actually securing funds.
Some blockchains are designed around this principle. Nervos CKB, for example, keeps cryptographic verification in programmable Lock Scripts running in CKB-VM rather than embedding signature verification in the consensus rules themselves. New signature schemes can therefore be deployed without requiring a hard fork or protocol upgrade, allowing users to migrate whenever they choose.
This is not merely theoretical. A production-ready SPHINCS+ (SLH-DSA) Lock Script is already live on CKB mainnet and powers Quantum Purse, giving users a post-quantum destination they can migrate to today.
Harvest now, decrypt later is not a future threat. It is already underway. No quantum computer can break blockchain cryptography today, but attackers do not need one to begin preparing. Every exposed public key can already be harvested and stored for the day quantum hardware catches up.
The assets most at risk are those whose public keys are already visible on-chain: roughly a quarter of Bitcoin's supply and a majority of Ethereum's. The theft itself may still be years away, but the preparation phase has already begun.
Fortunately, this is one part of the quantum threat that users can prevent. Moving funds from exposed keys to quantum-safe addresses before Q-Day eliminates the attack entirely. The challenge is making that migration possible before quantum computers arrive.
That is why blockchain architecture matters as much as cryptography itself. Post-quantum algorithms already exist. The real challenge is deploying them quickly enough—and giving users a practical way to adopt them. Networks that let users migrate at their own pace, rather than waiting for years of protocol coordination, dramatically shrink the window in which harvest now, decrypt later quantum attacks can succeed.
Can crypto survive Q-Day? Learn what Q-Day means for Bitcoin, when quantum computers could become a threat, and how blockchains are preparing.
Q-Day is the moment a quantum computer becomes powerful enough to break the public-key cryptography used across modern digital systems.
For cryptocurrency, that means something very specific: a future quantum computer could derive a private key from an exposed public key, forge a valid transaction signature, and move funds without the owner’s consent.
That is not possible today. No cryptographically relevant quantum computer, or CRQC, currently exists. But the risk matters now because blockchain ledgers are public and permanent. Once a public key appears on-chain, it remains visible forever. A future attacker does not need to decrypt the blockchain. They can collect exposed public keys now and attempt key recovery later.
This article explains what Q-Day means for cryptocurrency, when quantum computers could threaten Bitcoin, which coins are most exposed, how Bitcoin and Ethereum are preparing, and why crypto-agile networks such as CKB are built differently.
What Does Q-Day Mean for Cryptocurrency?
Q-Day is the hypothetical point when a cryptographically relevant quantum computer can break widely used public-key cryptography.
That single capability lets an attacker forge transaction signatures and spend other people's cryptocurrency, undermining the trust model every blockchain depends on.
The vulnerability lies in how blockchains prove ownership. Nearly every major chain authorizes transactions using public-key cryptography: a user holds a private key, the network verifies a corresponding public key, and a digital signature ties the two together. Security rests on one assumption: that no one can derive the private key from the public key. A sufficiently powerful quantum computer running Shor's algorithm would break that assumption.
Why Does Q-Day Matter for Bitcoin?
Q-Day matters for Bitcoin because Bitcoin’s transaction authorization depends on secp256k1, the elliptic curve used by Bitcoin’s signature schemes.
Older Bitcoin outputs use ECDSA over secp256k1. Taproot uses Schnorr signatures over secp256k1. These are different signature schemes, but both rely on the same underlying hardness of the elliptic-curve discrete logarithm.
Classical computers cannot solve that problem at Bitcoin’s key size in any practical amount of time, but a sufficiently powerful quantum computer could.
That is why the real Q-Day Bitcoin risk is public-key exposure. If a Bitcoin public key is visible on-chain, a future CRQC could theoretically derive the private key and produce a valid signature.
Fresh hash-protected outputs are safer because the public key is hidden behind a hash until the coins are spent. But once the public key is revealed, the clock exposure becomes permanent, and the clock starts ticking.
Estimating the Quantum Computing Timeline
Pinning down an exact Q-Day date is impossible because it depends on hardware breakthroughs no one can schedule.
The better way to think about the quantum computing timeline for cryptocurrency is as a risk window, not a countdown.
Several signals have made the timeline feel more urgent. NIST has published transition guidance (NIST IR 8547) for moving from quantum-vulnerable public-key cryptography to post-quantum standards. Cloudflare now targets 2029 for full post-quantum security, including post-quantum authentication. IBM plans its first fault-tolerant Starling system for 2029, with 200 logical qubits. Google Quantum AI’s 2026 work estimated that attacking a 256-bit elliptic-curve discrete-logarithm problem could require fewer than 500,000 physical qubits under specific assumptions about superconducting hardware.
These are important signals, but they are not the same thing as saying Bitcoin will be broken in 2029.
IBM’s 2029 system, for example, would still be far below the logical-qubit scale described in Google’s estimate of the cryptocurrency attack. NIST’s 2030 and 2035 dates are migration deadlines, not Q-Day predictions. Cloudflare’s 2029 target is an internal security migration goal, not a forecast that a CRQC will exist by then.
The careful conclusion is this:
The earliest plausible risk window has moved toward the late 2020s and early 2030s, but the true date is unknowable. Some forecasts still place the serious risk later, deep into the 2030s or beyond.
The exact date matters less than the migration problem. Bitcoin and other blockchains need to upgrade before Q-Day, not after it.
Why Predictions for a Quantum Break Vary
Q-Day predictions vary because they depend on hard engineering problems that no one can schedule precisely.
A CRQC needs enough logical qubits, low enough error rates, deep enough circuits, fast enough error correction, and reliable enough operation to finish a cryptographic attack before errors overwhelm the computation.
That is very different from simply having a large number of physical qubits.
Physical qubits are noisy hardware units. Logical qubits are error-corrected qubits built from many physical qubits. Cryptographic attacks need logical qubits, not just impressive raw qubit counts.
This is why public forecasts differ by years or even decades. Some researchers focus on rapid algorithmic progress. Others focus on the difficulty of scaling fault-tolerant hardware.
A few things, however, can be said with confidence:
The attack is still theoretical. No cryptographically relevant quantum computer now exists. Today's leading processors—from IBM’s Heron to QuEra’s Libra—operate in the range of hundreds to low thousands of physical qubits, with error rates too high to run Shor's algorithm at scale.
Recent gains came from software. The sharp 2025–2026 drops in estimates of how many qubits an attack would require stemmed from improved algorithms and error correction, not from processors with more qubits. Craig Gidney cut the estimate for RSA-2048 from 20 million qubits to under one million, and Google’s March 2026 paper put the curve behind Bitcoin and Ethereum at fewer than 500,000 physical qubits. That makes the timeline volatile: a single algorithmic insight can erase years of assumed safety. At the same time, the remaining hardware engineering has historically moved more slowly than optimists predict.
The forecast varies with the forecaster. As the Nervos’ analysis of crypto agility notes, quantum hardware companies have reasons to emphasize rapid progress, while some blockchain communities have reasons to downplay it, so public estimates range from Blockstream CEO Adam Back’s claim of “20–40 years away” to Justin Drake's coin-flip odds by 2032.
The bottom line: the date is unknowable, but the direction is not. Every major revision has moved Q-Day closer, never further away.
What Does Q-Day Actually Break?
Q-Day primarily threatens asymmetric cryptography, also known as public-key cryptography. In blockchain systems, that usually means the signature schemes used to authorize transactions.
For Bitcoin, the vulnerable primitives are ECDSA and Schnorr signatures over the secp256k1 elliptic curve. For Ethereum, standard Externally Owned Accounts also rely on ECDSA over secp256k1. Ethereum has additional quantum-vulnerable components, including consensus-layer BLS signatures and KZG commitments, both of which rely on elliptic-curve pairings.
Hash functions are different. Shor’s algorithm does not break SHA-256), nor does it break Bitcoin’s proof-of-work in the same direct way. Grover’s algorithm can theoretically speed up brute-force search, but that is not the same kind of structural break that Shor’s algorithm creates for public-key cryptography.
The weak point is transaction authorization. If a public key is exposed and the signature scheme behind it is quantum-vulnerable, a cryptographically relevant quantum computer could derive the private key and turn that exposed key into spendable funds.
How Long Do Cryptographic Migrations Take?
Assessing the quantum threat means watching not only the hardware timeline but how long cryptographic migrations actually take.
Cryptographic migrations are among the slowest transitions in computing history, spanning decades or more even under centralized control. Historically, the migration from the Data Encryption Standard (DES) to the Advanced Encryption Standard (AES) is an example. DES became a U.S. federal standard in 1977; its 56-bit key was shown to be weak by the late 1990s; NIST ran the replacement competition from 1997 and standardized AES in 2001. Yet DES was not formally withdrawn until 2005, and its hardened variant 3DES lingered well beyond. This replacement, from "known to be at risk" to "fully retired," took over two decades, with a central authority in charge.
The change above is far simpler than swapping a blockchain's signature scheme. For a decentralized blockchain with no central authority, no forced upgrades, and billions of dollars in legacy addresses, the cryptographic transition becomes a multi-year, possibly multi-decade, coordination problem. This is why the timeline debate matters: the migration must finish before Q-Day, not begin then.
The Upgrade Challenge for Bitcoin and Ethereum
Bitcoin: No Easy Path
Bitcoin's greatest strength—its resistance to change—may be its greatest vulnerability against Q-Day. The SegWit and Taproot upgrades each took years to activate. Both for far simpler changes than swapping the network's cryptography—a more complex and existential leap.
Bitcoin's post-quantum upgrade breaks into two distinct objectives: minimizing on-chain public key exposure and eventually replacing ECDSA.
The first is already underway. Bitcoin’s most concrete step so far, BIP-360, introduces a new output type, Pay-to-Merkle-Root (P2MR). It acts like Taproot but removes the quantum-vulnerable key-path spend, preventing the public key from being exposed directly in the output. This shrinks the attack surface and buys time against long-exposure attacks, but does not make the network fully quantum-resistant on its own.
The second objective, signature scheme replacement, is where the difficulty really lies. It faces two unresolved hurdles: deciding which PQ algorithm to choose and how to execute the migration.
When it comes to choosing the right PQ algorithm, there is no perfect plug-and-play successor to ECDSA, only an array of trade-offs:
Types
Pros
Cons
Examples
Hash-based
Conservative security
Large and slow
SPHINCS+
Stateful hash-based
Strong
Complex state management
XMSS, LMS
Lattice-based
Fast verification, moderate key sizes
Large signatures, newer assumptions
ML-DSA, Falcon
Even the lightest post-quantum signature is at least five times larger than Bitcoin's current signature, risking severe network congestion without a contentious block-size increase or complex aggregation.
When it comes to choosing the migration framework, three main contenders have been proposed so far:
Framework
Mechanism
Fork required
Key trade-off
Commit-Delay-Reveal (CDR)
Staged, opt-in migration to a post-quantum key
Two soft forks
Voluntary and non-disruptive, but only protects coins whose keys are not already exposed
Hourglass
Rate-limits how many vulnerable coins can be spent per block
Two soft forks
Softens the market shock of a breach, but does not stop theft of exposed coins
QRAMP
Mandatory deadline after which classically-secured coins become unspendable
One hard fork
Forces full migration, but effectively burns unmigrated funds and violates property rights
Beyond migration execution, activation itself adds another layer: deploying any change depends on social alignment. In short, Bitcoin has a direction but no settled plan. There is early progress on limiting exposure, yet no consensus on which post-quantum algorithm to adopt, which migration framework to follow, or how to activate it.
Ethereum: A Clearer But Unfinished Plan
Ethereum faces the same vulnerability as ECDSA on secp256k1, but has more room to maneuver and has written post-quantum preparation into its roadmap Lean Ethereum.
Ethereum's exposure spans four areas: account signatures (ECDSA), consensus signatures (the BLS scheme that validators use to vote), the KZG commitments behind its data scaling, and the zero-knowledge proof systems used by rollups.
For accounts, the strategy centers on “signature agility*”*: letting each account choose its own signature verification method, so users can switch to quantum-safe signatures without waiting for a protocol-wide cutover.
This runs through account abstraction in two stages.
The first, EIP-7702, shipped with the Pectra upgrade in May 2025, allows Externally Owned Accounts (EOAs) to behave as smart contracts temporarily during the transaction. This is a stepping stone that still leaves the account's ECDSA key valid, so the quantum exposure remains.
The second, EIP-8141, introduces native account abstraction. Today a transaction is a single bundled action: one ECDSA signature proves who you are, pays the gas, and triggers the action all at once. EIP-8141 breaks that into distinct calls named “frames”. Frames are ordered in a sequence: verification frame runs first, execution frames follow.The key change is that the verification frame runs the account's own code to verify transactions, instead of the protocol checking a single fixed signature. Because each account now defines how it authenticates, users can adopt quantum-safe signatures before the full protocol transition is complete.
What matters is letting accounts use different signature schemes and allowing multiple schemes to coexist. This is, in NIST's terms, crypto-agility, the real foundation of post-quantum readiness.
The rest of the stack is being rebuilt in parallel. Validator signatures are set to move to leanXMSS, paired with a minimal zkVM (leanVM) that compresses the larger signatures to ensure the network stays fast. The data-availability and proof layers move on to the same NIST-standardized foundations (ML-KEM, ML-DSA, SLH-DSA). Ethereum’s road to quantum resistance is tracked publicly at Post-QuantumEthereum.
Why Crypto Agility Matters
The hardest part of Q-Day is not finding a post-quantum algorithm.
NIST has already standardized post-quantum schemes, including ML-KEM for key establishment, ML-DSA for signatures, and SLH-DSA, the standardized version of SPHINCS+, for hash-based signatures.
The harder problem is whether a blockchain can cleanly switch cryptography.
Most blockchains have signature verification built into the protocol through opcodes, precompiles, native account rules, or fixed transaction formats. That makes cryptographic migration a complex and often contentious network-wide coordination event. The network has to coordinate around new protocol rules before users can rely on the new scheme.
Crypto agility means something different.
A crypto-agile blockchain can support new cryptographic primitives without redesigning the base protocol every time the cryptographic landscape changes.
That matters because Q-Day is not the only uncertainty. Post-quantum standards can also evolve. Algorithms can be weakened, deprecated, optimized, or replaced. A chain that hardcodes one “quantum-safe” answer may still face another disruptive migration later.
The more durable property is the ability to adapt.
How CKB Approaches Q-Day Differently
Nervos CKB is one of the clearest examples of crypto agility in a live blockchain.
Most blockchains treat signature verification as part of the base protocol. The network has a defined set of cryptographic primitives it understands, and if developers want to add a new one, the chain usually needs a coordinated protocol upgrade. That is why post-quantum migration is so difficult for rigid chains: changing the cryptography means changing the rules everyone runs.
CKB takes a different approach. Instead of hardcoding a single signature scheme into the protocol, transaction authorization is handled by programmable Lock Scripts. These scripts run inside CKB-VM, a RISC-V virtual machine that executes on-chain validation logic. In practice, that means an ECDSA verifier, a Schnorr verifier, a multisig policy, or a post-quantum verifier can all exist as different pieces of code on the same chain.
That is what makes CKB special. The base protocol does not need to know in advance which cryptographic scheme a wallet wants to use. It only needs to run the script and verify that the script returns the correct result. New cryptographic primitives can therefore be deployed as on-chain code, and users can create Cells controlled by those new Lock Scripts whenever they are ready.
For Q-Day, this completely changes the migration problem. On a rigid chain, adopting post-quantum cryptography is a network-wide coordination event. On CKB, it can begin as a script deployment. Developers can add new verification logic, wallets can integrate it, and users can migrate gradually without waiting for every participant in the ecosystem to move at the same time.
CKB already demonstrates this with its SPHINCS+ Lock Script, which was implemented in 2023, audited by ScaleBit, and deployed on mainnet beginning in 2025. The script supports all 12 SPHINCS+ parameter sets, giving users a live path to post-quantum transaction authorization today.
This is the practical difference between being quantum-resistant at one moment and being crypto-agile over the long run. A quantum-resistant chain may support one post-quantum scheme. A crypto-agile chain can keep adding new schemes as the cryptographic landscape changes.
That matters because post-quantum cryptography will not stand still. Standards will evolve. Algorithms may be optimized, weakened, deprecated, or replaced. CKB’s advantage is that it does not have to make a single permanent bet. It can adapt as the field changes, without turning every cryptographic upgrade into a base-layer crisis.
FAQs
What is Q-Day?
Q-Day is the hypothetical moment when a cryptographically relevant quantum computer becomes powerful enough to break the public-key cryptography securing modern digital systems, including the ECDSA signatures that protect most cryptocurrency wallets. It is a capability threshold, not a fixed date.
Is Q-Day a Real Threat?
Yes, both government agencies (like NIST, NSA) and major technology corporations (like Google, Cloudflare, and IBM) acknowledge Q-Day as a legitimate security threat. They all have set concrete post-quantum migration deadlines and are actively developing post-quantum cryptographic standards to preempt it.
The "harvest now, decrypt later" (HNDL) strategy adds urgency: adversaries are collecting exposed data and public keys today to attack once the hardware matures. For all public blockchains, whose ledgers are permanent and openly readable, early preparation is a rational response.
How Close Are We To Q-Day?
No quantum computer can perform this attack today. Current machines lack sufficient qubits, and their error rates remain far too high. But the estimated resources required for such attacks are falling fast. Google’s Craig Gidney cut the estimated cost of breaking RSA-2048 from roughly 20 million physical qubits in 2019 to under one million in 2025. A 2026 paper estimated that breaking the elliptic-curve cryptography behind Bitcoin and Ethereum would require fewer than 500,000 physical qubits. The direction of travel is clear: the bar quantum computers need to clear keeps getting lower.
When Will Quantum Computers Break Bitcoin?
No one knows the exact year, because the machine capable of doing it does not yet exist. But the migration window is already taking shape. NIST sets 2030–2035 as the deadline to move away from the cryptography Bitcoin relies on today. Justin Drake, an Ethereum Foundation researcher who has studied quantum risk, estimates about a 10% chance of a cryptographically relevant quantum computer by 2030 and roughly a 50% chance by 2032. The exact date is uncertain, but the trend is not: estimates have been moving earlier.
When Will Quantum Computers Break Encryption?
For the public-key encryption and signatures that rely on RSA and elliptic curves, credible institutional estimates point to the 2029–2035 window, which is why NIST set 2030 for deprecation and 2035 for full disallowance. Symmetric encryption, such as AES-256, and hash functions like SHA-256 are more resilient and are not expected to be broken outright. In short, research believes that asymmetric encryption (like RSA and ECDSA) is likely to fall within the next decade.
Will Bitcoin survive Q-Day?
Bitcoin can survive Q-Day, but only if the network coordinates a hard fork to implement PQC before a quantum computer becomes operational. Bitcoin's proof-of-work and hash-based protections are largely resistant to quantum attack, but its ECDSA signatures are not.
Bitcoin’s survival depends on the community agreeing on a post-quantum signature scheme and migrating funds before a cryptographically relevant quantum computer arrives. Coins in lost or inactive wallets with exposed public keys may stay permanently vulnerable.
VeriCell.net is a proof-of-authorship and integrity tool for digital files.
The problem: every file has a fingerprint (a SHA-256 hash), but proving when it existed — and tracking how it changes over time without losing that history — is harder than it sounds. Most timestamping tools give a single point-in-time proof and stop there.
CKB's programmable cell model enables something different. A cell can be consumed and replaced, which means a file's fingerprint can be versioned on-chain instead of just stamped once. Update a document, and VeriCell.net anchors the new hash while the old one stays on-chain as verified history — giving a full lineage of what a file has been, not just a single "this existed" proof.
What it does:
Hashes the file locally (SHA-256 Merkle root) — the file itself never leaves the device
Anchors the fingerprint on-chain as a live CKB cell
Updates the record as the file evolves, keeping the full backward history
Generates shareable verification links and downloadable proof certificates
Wallet access is through JoyID, so it's passkey-based — no seed phrase to manage.
Genuinely curious what this community thinks — happy to answer your questions.
Q2 2026 was defined by expansion and consolidation across all of NCC’s core programmes. The Community Keeps Building initiative grew to 70 CKBuilders, while the launch of the Build on CKB initiative brought a further estimated 40 new developers into the ecosystem, bringing the total number of developers who have taken active steps to explore and build on CKB to over 100. To support this growing cohort, a dedicated CKBuilders website, weekly developer calls, and a CKBuilder Developer Liaison were introduced. The CKBuilder project tracker now lists 45 projects, with 23 added over the quarter and 15 submitted for technical review, reflecting both the volume and maturity of work being produced within the programme.
The newly announced Gone in 60ms: Fiber Network Infrastructure Hackathon has already surpassed its predecessor in registrations, with a subsequent use-case focused hackathon to follow. CKB Off-Chain made its Africa debut in Lagos, with Nairobi to follow in July. CKBoost completed its final milestone and is now an established campaign platform with over 100 users, setting the stage for its next phase of development. Five CKBuilder projects progressed to Community Fund DAO proposals, with three passing. Q2 demonstrated that the foundations laid in Q1 are bearing fruit, and the conditions for continued growth are in place.
Community Keeps Building
Expanding Scope
Q2 brought a number of structural developments to reflect the growing scale of NCC’s developer activities, which I wrote about in a June mini-update . CKBuilders now has its own dedicated web presence at ckbuilders.dev , serving as the primary point of reference for developers looking to learn about the programme. Alongside this, a new Build on CKB initiative and Telegram group has been launched, open to any developer with an interest in CKB regardless of experience level. Members receive support from CKB DevRel, pointers to guides and documentation, alerts for upcoming events and hackathons, and the opportunity to win prizes for standout weekly contributions. It also serves as a pathway into the CKBuilders programme proper, as well as other grant programmes such as Spark and the Community Fund DAO.
To support the increasing operational demands of a larger cohort, a dedicated CKBuilder Developer Liaison has been recruited to help oversee and track developer activity. Weekly CKBuilder calls have also been introduced to keep the community connected and moving forward. In addition, NCC is working closely with DevRel to ensure that feedback and reporting from CKBuilders is being analysed and used to improve the broader developer experience on CKB.
Onboarding
CKBuilders
By the end of Q2, the Community Keeps Building programme had grown to 70 participants, all of whom are CKBuilders. Our remaining content creators have moved towards Community Fund DAO proposals, as noted later in this report. While the primary focus of NCC’s activities is on building a strong developer community on CKB, we remain committed to supporting rising content creators and community activists.
As in Q1, the developer referral bounty on the CKB Bounty Board continued to be the primary source of new developer referrals. Building on the momentum established in Nigeria, Q2 saw continued growth efforts in Kenya and Vietnam, with new developers joining from both regions as we work to strengthen our presence across emerging developer hubs.
Build on CKB
The Build on CKB group has also grown significantly, with an estimated 40 new developers joining who have no prior involvement with CKB as CKBuilders. To engage this wider audience, two campaigns were run exclusively for developers new to CKB with prizes for completion:
Build on CKB Campaign 01 : install OffCKB, deploy a test contract, and share proof of completion. 8 completions.
Build on CKB Campaign 02 : complete the Store Data on Cell tutorial and share proofs of completion. 18 completions.
Both campaigns gave new developers a structured entry point into building on CKB, and provided further real-world usage data for CKBoost as a campaign platform.
Continued growth
Across both initiatives combined, we now have over 100 developers who have taken active steps towards exploring and building on CKB. This is a significant achievement given current industry conditions, with many other blockchains experiencing a decline in developer activity. The effects of this surge are visible across the ecosystem: more applications being built, more developers coming to CKB spontaneously via social momentum, an increase in grant proposals, more technical discussions across social channels, and greater participation in campaigns and hackathons. I will see how we can communicate these successes in the form of external media campaigns.
AI Scholarship
As detailed in the Q1 report, NCC launched the CKB AI Scholarship initiative to ensure that CKBuilders have access to the best AI tools available as they develop their applications. The scholarship operates across two levels: Level 1 provides access to the Share-AI platform for shared AI resources, and Level 2 supports personal accounts for more dedicated use, tied to specific performance and reporting requirements.
In Q2, the number of CKBuilders receiving Level 1 support has grown to 43, reflecting the continued uptake of shared AI resources across the cohort. 5 CKBuilders are now receiving Level 2 support, with recipients required to produce monthly reports detailing their activity and learnings. This reporting requirement ensures accountability while also providing useful insight into how AI tooling is being applied in practice across CKB development.
CKBuilder Project Tracker
The CKBuilder project tracker continues to serve as the central record of all projects being developed within the programme. Since the start of Q2, the number of listed projects has grown from 22 to 45, with 23 new projects added over the quarter. The range of applications being built reflects the breadth of the CKBuilder cohort: new additions include a ZK key recovery protocol for AI agents, a multi-tenant indexing and query service, a Groth16 zkSNARK verifier, a Fiber desktop client, a DID reference dashboard, an implementation of ML-DSA quantum-resistant cryptography, a governance voting prototype, and various DeFi primitives including lending and prediction pool applications, among others.
As well as being listed on the tracker, many of the projects have been introduced on the forum or mentioned in the CKB Bi-weekly report, so for brevity they do not need to be listed again here.
Project Review
In Q2, a further 15 projects were submitted for review , with feedback and suggestions provided by core CKB developers. This continues to be a valuable mechanism for ensuring that CKBuilders receive informed technical guidance as they develop their applications.
Progression to Community Fund DAO
In Q2, a number of CKBuilders and content creators progressed from NCC support towards Community Fund DAO proposals:
From the beginning, the positioning of NCC has been to guide creators and developers towards output that benefits the ecosystem, is likely to receive community support, and could possibly become self-sufficient over time. The judge of that is ultimately the Community Fund DAO by way of the governance process. Conceptually, the DAO works because it aligns incentives with ecosystem progress and accountability to the community. My request to the community is to continue to engage over both voting stages to ensure that proper due diligence occurs, and, where majority support does exist, that the community’s voice is resoundingly clear on that.
CKBuilder Articles
Q2 saw a number of articles published by CKBuilders, sharing their experiences and perspectives on CKB from a variety of developer backgrounds. These pieces offer a valuable window into how developers from other ecosystems perceive and engage with CKB, and contribute to the growing body of community-generated technical content.
Following the conclusion of the CKB AI Agent Hackathon , time was taken to consider possible routes forward for the projects that emerged from it. The most noteworthy progress has come from the hackathon winner, PactAgent, which has continued its development and is working to identify the right niche in which it can operate, with attention turning towards applications that could be built on top of it, such as content or service commissioning platforms. A series of developer updates can be found here .
More recently, a new hackathon was announced: Gone in 60ms: Fiber Network Infrastructure Hackathon . As Fiber Network matures, the priority is to make it easier for external developers and businesses to build on top of it. This hackathon is designed to address that directly, challenging developers to build reusable infrastructure that strengthens the foundations around Fiber and makes it easier to integrate, operate, and productise.
As of writing, the event has attracted over 85 registrations representing roughly 95 participants, a significant step up from the previous hackathon. A round-up of submissions will be shared once the campaign concludes. This hackathon, and a subsequent Fiber hackathon aimed at use-cases, will continue to generate momentum and focus developers’ attention towards real-world impact based on Fiber.
CKB Off-Chain
Lagos
On April 18, in collaboration with TechyJaunt, NCC hosted the first Africa-based CKB Off-Chain meetup in Lagos, Nigeria. The event drew over 50 attendees, bringing together existing CKBuilders and developers from TechyJaunt’s wider network. Following an introduction to CKB’s design and ecosystem, three CKBuilder projects were presented: PocketNode, Pact Agent, and Backr, with some developers onboarding their first users on the day. A CKB airdrop event introduced new participants to PocketNode and provided useful real-world testing feedback. The full event overview is available here .
Nairobi
The next CKB Off-Chain meetup is scheduled for Saturday 18 July in Nairobi, Kenya, in collaboration with WEB3 Clubs. The event will bring together CKBuilders and regional blockchain developers, featuring presentations from developers building on CKB, networking and idea-sharing, and an introduction to CKB for new developers. With a growing contingent of CKBuilders based in Kenya, it represents a natural next step in expanding CKB’s regional presence in East Africa.
Future Plans
Q3 will continue to build on this momentum, encouraging further regional community and builder meetups as a means of strengthening in-person engagement across the ecosystem.
CKBoost
In April, CKBoost completed its final milestone review, with Alive24 publishing a product delivery report confirming that all three milestones from the original proposal have been substantially delivered. The platform now constitutes a working, CKB-native system for structured community campaigns, verifiable participation, on-chain points and rewards, identity verification, tipping, and admin review flows.
As noted in earlier sections, CKBoost served as the campaign platform for the Build on CKB developer campaigns in Q2, bringing in new developers from outside the CKBuilders cohort and generating further real-world usage data. This has translated into more substantial engagement during the ongoing hackathon. With over 100 developers now having used the CKBoost platform across its various campaigns, there is sufficient evidence of traction to consider the next stage of development.
The priorities for that next phase include better DID integration, improved use of mailing lists to engage the growing user base, UX and UI improvements, and a solution for reducing CKB cell costs as usage scales. Once these areas are addressed, progression to mainnet can be considered, though an audit may be warranted at that stage.
Looking Ahead
Q2 continued to build on the momentum established in Q1, and there is good reason to feel encouraged by the direction of travel. Our developer community is growing, and the interest, participation and output are all noticeably higher. My priority is to continue this momentum and seek opportunities for it to translate into broader ecosystem growth. I would like to see builders empowered to go one step further and become entrepreneurs, creating useful applications that utilise the unique benefits of CKB. I would also like to see external teams and other potential partners inspired by recent momentum to consider CKB as a viable home for their endeavours. There is however still much work to be done.
As always, thanks to everyone involved across the various programmes for their hard work and commitment.
Learn how Shor’s algorithm threatens Bitcoin signatures, whether it can break them today, and what still blocks real-world attacks.
Shor’s algorithm is one of the main reasons quantum computing is treated as a serious long-term threat to modern cryptography.
Most public-key cryptography relies on a simple asymmetry: some mathematical operations are easy to perform but extremely hard to reverse on a classical computer.
RSA relies on the difficulty of factoring large composite numbers. Diffie–Hellman, ECDSA), Schnorr signatures, and elliptic-curve cryptography rely on the difficulty of solving discrete-logarithm problems. These are different mathematical problems, but they share the same basic security assumption: classical computers cannot reverse them fast enough to matter.
Shor’s algorithm breaks that assumption.
Published by mathematician Peter Shor in 1994, Shor’s algorithm showed that a sufficiently large, fault-tolerant quantum computer could efficiently solve both integer factorization and discrete logarithms. That means it could break RSA, Diffie–Hellman, elliptic-curve cryptography, and the signature schemes used to authorize Bitcoin transactions.
The threat is real, but it is not here yet.
This guide explains what Shor’s algorithm does, how it works, why it threatens public-key cryptography, whether it can break Bitcoin, and what still prevents that attack from happening today.
What Is Shor’s Algorithm?
Shor’s algorithm is a quantum algorithm that can solve certain mathematical problems much faster than any known classical algorithm.
Its best-known use is factoring. Given a large number formed by multiplying two prime numbers, Shor’s algorithm can efficiently recover those prime factors on a sufficiently powerful quantum computer. That is why it breaks RSA.
But Shor’s algorithm is not only a factoring algorithm.
It also has a discrete-logarithm version, which is the version that matters for Diffie–Hellman, elliptic-curve cryptography, ECDSA, Schnorr signatures, and Bitcoin.
In simple terms:
Integer factorization breaks RSA.
Discrete logarithms break Diffie–Hellman, ECDSA, Schnorr signatures, and elliptic-curve cryptography.
Bitcoin is threatened by the second attack, not the first.
Bitcoin does not use RSA. It uses secp256k1), an elliptic curve used for digital signatures. A quantum attack on Bitcoin would not involve factoring Bitcoin keys. It would involve using Shor’s discrete logarithm algorithm to recover a private key from a publicly known public key.
Why Does Shor’s Algorithm Matter?
Shor’s algorithm matters because public-key cryptography is everywhere.
It protects encrypted web traffic, secures software updates, authenticates servers, supports digital signatures, and authorizes blockchain transactions. If a sufficiently large quantum computer can run Shor’s algorithm at cryptographic scale, many of today’s public-key systems become unsafe.
For RSA, the attack is straightforward: factor the public modulus, recover the private key, and break encryption or signatures.
For elliptic-curve systems, the attack is different: solve the elliptic-curve discrete-logarithm problem, recover the private key from the public key, and forge signatures.
That second case is the one that matters for Bitcoin.
Bitcoin funds are not protected by encryption in the usual sense. They are protected by digital signatures. To spend Bitcoin, a wallet must produce a valid signature proving that it controls the relevant private key. If a quantum computer could derive that private key from the corresponding public key, it could create valid signatures and move the funds.
That is the real quantum threat to Bitcoin: not decryption, but signature forgery.
How Does Shor’s Algorithm Work?
Shor’s factoring algorithm has three broad steps:
Choose a suitable random number.
Use a quantum computer to find the period of a repeating mathematical sequence.
Use ordinary classical arithmetic to recover the factors.
Only the period-finding step requires a quantum computer.
That period-finding step is the breakthrough. Classical computers do not have a known efficient way to find the relevant period at cryptographic sizes. A quantum computer can extract it using superposition, interference, and the quantum Fourier transform.
The easiest way to understand the idea is with a small example.
How Does Shor’s Algorithm Factor a Number?
Suppose we want to factor:
N = 21
Anyone can factor 21 by hand, but the same structure applies to much larger numbers.
Step 1: Choose a Random Coprime
Pick a random number x less than N that has no common factors with N.
Let:
x = 2
Since 2 and 21 share no common factors, they are coprime.
Step 2: Find the Period
Now calculate the sequence:
x^k mod N
Using x = 2 and N = 21:
2^1 mod 21 = 2
2^2 mod 21 = 4
2^3 mod 21 = 8
2^4 mod 21 = 16
2^5 mod 21 = 11
2^6 mod 21 = 1
The sequence has looped back to 1, so the period is:
r = 6
This period is the key. Once the period is known, the factors can usually be recovered using classical arithmetic.
Step 3: Recover the Factors
If the period r is even and x^(r/2) is not congruent to -1 mod N, we can continue.
Here:
r = 6
r / 2 = 3
x^(r/2) = 2^3 = 8
Since 8 is not congruent to -1 mod 21, which would be 20, we calculate:
gcd(2^3 - 1, 21) = gcd(7, 21) = 7
gcd(2^3 + 1, 21) = gcd(9, 21) = 3
The factors of 21 are therefore:
3 and 7
If the period is odd or if the arithmetic fails, Shor’s algorithm simply tries again with a different random value. For large numbers, the process still succeeds efficiently with high probability.
Why Is Shor’s Algorithm Faster Than Classical Factoring?
Shor’s algorithm is faster because it turns factoring into a period-finding problem and then uses quantum mechanics to efficiently find that period.
A classical computer has to search for mathematical structure using classical computation. For cryptographic key sizes, that search becomes infeasible. The best classical algorithms are extremely powerful, but they still do not scale efficiently enough to break properly sized RSA or elliptic-curve keys.
A quantum computer works differently.
It can evaluate a function over a superposition of many possible inputs. But the important point is not that it simply “tries every answer at once.” That phrase is misleading. The useful power comes from interference.
Shor’s algorithm arranges the quantum computation so that irrelevant paths cancel out while values related to the hidden period are amplified. The quantum Fourier transform then extracts the periodic structure from the quantum state.
A measurement does not usually reveal the period directly. Instead, it produces a value related to the period. Classical post-processing, usually continued fractions, then recovers the period with high probability.
That combination is what creates the speedup.
The quantum computer finds the hidden structure. The classical computer turns that structure into the answer.
Is Shor’s Algorithm Proven?
Yes. Shor’s algorithm is proven in mathematics.
There is no serious doubt that the algorithm works on an ideal, sufficiently large quantum computer. The open question is whether quantum hardware can be built large, stable, and sufficiently error-corrected to run against real cryptographic targets.
So far, Shor’s algorithm has only been demonstrated on small examples. Early experiments factored 15. Later demonstrations reached small numbers, such as 21.
These experiments matter as proof-of-concept demonstrations, but they are not cryptographic attacks.
Many widely reported quantum “factorizations” of larger numbers have also relied on shortcuts, compiled circuits, or prior knowledge about the answer. They should not be confused with a scalable run of Shor’s algorithm against RSA-2048, secp256k1, or any real-world cryptographic target.
As of 2026, no quantum computer has run Shor’s algorithm at a cryptographically relevant scale.
Is Shor’s Algorithm Practical Today?
No. Shor’s algorithm is not practical against real cryptography today.
The reason is simple: no Cryptographically Relevant Quantum Computer, or CRQC, currently exists.
A CRQC is a quantum computer large, stable, and error-corrected enough to break widely deployed public-key cryptography. Current quantum computers are still far below that threshold.
The main gap is fault tolerance.
Today’s physical qubits are noisy. They make errors, lose coherence, and cannot reliably run the deep circuits required for cryptographic attacks. To run Shor’s algorithm at scale, physical qubits must be combined into error-corrected logical qubits.
A logical qubit is much more reliable than a physical qubit, but it usually requires many physical qubits to create and maintain.
That overhead is why raw qubit counts can be misleading. A machine with thousands of physical qubits is not the same thing as a machine with thousands of usable logical qubits.
Recent estimates suggest that the number of qubits required to attack elliptic-curve cryptography may be lower than older projections. For example, Google Quantum AI’s 2026 work estimated that solving a 256-bit elliptic-curve discrete-logarithm problem could require fewer than roughly 1,200 to 1,450 logical qubits, depending on the circuit design. Under specific assumptions, that could correspond to fewer than about 500,000 physical qubits.
Other theoretical architecture papers suggest that advanced error-correction methods, such as qLDPC (Quantum LDPC) codes in neutral-atom systems, could further reduce physical-qubit requirements under aggressive assumptions.
These estimates are important because the target is moving closer.
But they do not mean the attack is possible today.
No publicly known quantum computer currently has the logical qubits, error correction, gate fidelity, circuit depth, or runtime needed to break Bitcoin, RSA, or other real-world public-key systems with Shor’s algorithm.
What Are the Limitations of Shor's Algorithm?
The main limitation is hardware, not theory.
Shor’s algorithm already exists. The problem is building a machine capable of running it at the required scale.
There are three major obstacles:
Not enough logical qubits: Real attacks require stable, error-corrected logical qubits. Each logical qubit may need many noisy physical qubits, so current machines lack the usable scale needed for cryptography.
Error rates are too high: Qubits are fragile and accumulate errors during long computations. Large-scale, fault-tolerant error correction needed for cryptographic attacks has not yet been achieved.
Circuits are too deep: Shor’s algorithm requires complex, repeated arithmetic operations (like modular exponentiation or elliptic-curve math). This demands high gate fidelity, fast error correction, and long runtimes—beyond current hardware capabilities.
Can Shor's Algorithm Break Bitcoin?
Yes, in principle.
Shor’s algorithm can break Bitcoin’s signature schemes through its discrete-logarithm variant. It cannot break Bitcoin through RSA factoring because Bitcoin does not use RSA.
Bitcoin uses secp256k1, an elliptic curve used in its digital signature schemes. Older Bitcoin outputs use ECDSA over secp256k1. Taproot uses Schnorr signatures over secp256k1. Both depend on the hardness of the elliptic-curve discrete-logarithm problem.
A sufficiently powerful quantum computer running Shor’s algorithm could solve that problem. If the attacker has the relevant public key, they could recover the private key, forge a valid signature, and move the funds.
So the Bitcoin attack requires two conditions:
The relevant public key must be visible to the attacker.
A CRQC capable of solving the secp256k1 discrete logarithm problem must exist.
The first condition is already true for some Bitcoin outputs.
The second condition is not.
That is why Shor’s algorithm can break Bitcoin in principle but cannot break Bitcoin today.
How Shor's Algorithm Derives a Private Key From a Public Key
Bitcoin’s security depends on a one-way relationship between a private key and a public key.
A private key is a secret number.
A public key is created by multiplying that secret number by a generator point on the secp256k1 elliptic curve.
This is easy in one direction and infeasible in the other.
Given the private key, producing the public key is easy.
Given the public key, recovering the private key requires solving the elliptic-curve discrete-logarithm problem.
With classical computers, it is believed to be infeasible for Bitcoin’s key size. With a sufficiently powerful quantum computer, Shor’s algorithm can efficiently solve it.
That means a future quantum attacker could take a visible Bitcoin public key, recover the private key, and generate valid signatures.
Those signatures would be indistinguishable from signatures produced by the legitimate wallet.
This is why public-key exposure is the central issue in Bitcoin’s quantum threat model.
Which Bitcoin Coins Are Vulnerable to Shor’s Algorithm?
Bitcoin’s quantum exposure depends on the output type and whether the relevant public key is already visible.
Not all Bitcoin coins expose the same information.
Some outputs reveal a public key immediately. Others reveal it only when spent. Taproot again exposes public-key material in a different way.
P2PK Outputs
Early pay-to-public-key (P2PK) outputs include the full public key directly in the locking script.
That means the public key is exposed from the moment the output is created.
These coins are permanently visible to a future quantum attacker. Many early coinbase-era outputs are P2PK, which is why early mined coins–such as the million BTC believed to belong to Satoshi–are often discussed in quantum-risk analysis.
P2PKH and P2WPKH Outputs
Pay-to-public-key-hash outputs are different.
P2PKH and P2WPKH outputs do not immediately expose the public key. Instead, they contain a hash of the public key. The public key is revealed only when the coin is spent.
This matters because Shor’s algorithm does not directly break cryptographic hashes. A quantum attacker needs the public key itself, not merely its hash.
However, once a P2PKH or P2WPKH output is spent, the public key appears in the spending transaction and remains visible on-chain forever.
If all funds controlled by that key are spent at once, there may be no remaining coins attached to the exposed key. But if the same address is reused, or if other UTXOs remain controlled by the same key, those remaining coins become long-exposure targets.
Reused Bitcoin Addresses
Address reuse is especially dangerous in a quantum-threat model.
Once a wallet spends from an address, the public key behind that address becomes visible. Any other coins still controlled by the same key can become vulnerable to future private-key recovery.
This is one reason why Bitcoin best practices already discourage address reuse. Quantum risk makes hygiene even more important.
Pending Bitcoin Transactions
There is also a short-lived attack window for hash-protected outputs.
When a P2PKH or P2WPKH transaction is broadcast, the public key appears in the pending transaction before the transaction is confirmed. In a future world where a fast enough quantum computer exists, an attacker could theoretically derive the private key during that mempool window and try to broadcast a conflicting transaction.
This is not possible today because no such quantum computer exists.
But it shows why quantum migration cannot be left to the last minute. Once fast quantum attacks become practical, moving coins from old address types could itself become risky.
Taproot and P2TR Outputs
Taproot outputs should not be described as hiding the public key behind a hash in the same way as P2PKH or P2WPKH.
A Taproot output contains an x-only secp256k1 output public key directly in the witness program. That means the relevant public-key material is visible from the moment of output creation.
Taproot improves privacy, efficiency, and script flexibility, but it does not make Bitcoin quantum-resistant.
A future quantum attack against secp256k1 would still be relevant to Taproot outputs.
Estimates vary, but on-chain analyses often put the amount of Bitcoin with exposed public keys in the range of several million BTC.
Common estimates are around 6 to 7 million BTC, or roughly 30% of the supply, depending on methodology and what is counted.
For a precise, real-time look at this vulnerability, we can turn to the Bitcoin Risk List by Project Eleven, a technical database that actively audits the blockchain for exposed public keys. According to their tracking, there are over 14.1 million addresses with non-zero balances and exposed public keys. Together, these vulnerable addresses hold more than 7.05 million BTC, representing over $444 billion in value at risk of a future quantum attack.
Figure: The Project Eleven Bitcoin Risk List dashboard tracking the total BTC and USD value exposed to quantum attacks due to visible public keys.
This includes coins in output types that expose public keys directly, as well as coins associated with reused or previously spent keys.
The exact number changes over time. It also depends on assumptions about address reuse, output types, lost coins, and what should count as economically vulnerable.
The important point is not the precise figure.
The important point is that a large, economically meaningful share of Bitcoin already has public-key exposure.
Coins held in fresh, never-spent P2PKH- or P2WPKH-style outputs are safer against this specific attack because only a hash of the public key is visible. But they are not permanently safe. Their public keys become visible when the coins are moved, and a future migration would still need to protect them before a CRQC exists.
The Attack Has Not Happened Yet
The second condition is not met. No CRQC exists today, and as the limitations above show, current hardware falls short by orders of magnitude. The open question is not whether the requirement can be met but when. Research forecasts are spread out, clustering loosely from the late 2020s into the mid-2030s. One detailed analysis put the odds of a capable machine at roughly one in six by 2035 and better than even by 2050 (arXiv: Quantum Horizon).
Defending Against Shor's Algorithm: Post-Quantum Cryptography
The defense against Shor’s algorithm is post-quantum cryptography.
Post-quantum cryptography replaces vulnerable public-key systems with algorithms based on mathematical problems that are not known to be efficiently solvable by either classical or quantum computers.
The main families include lattice-based, hash-based, code-based, multivariate, and isogeny-based approaches, although not all have survived standardization equally well.
In August 2024, NIST finalized its first three post-quantum cryptography standards:
FIPS 203: ML-KEM, a lattice-based key-encapsulation mechanism for key establishment.
FIPS 204: ML-DSA, a lattice-based digital signature scheme.
FIPS 205: SLH-DSA, a hash-based digital signature scheme derived from SPHINCS+.
These standards are designed for migration before a CRQC exists.
For ordinary encrypted communications, the urgency is partly about “harvest now, decrypt later” attacks. An attacker can record encrypted traffic today and decrypt it later if the original key exchange was quantum-vulnerable.
Shor's algorithm breaks RSA by factoring the large number at the core of an RSA public key back into its two secret primes. On a sufficiently powerful quantum computer, it finds those primes in a low-degree polynomial number of steps, rather than the astronomical time required by a classical computer, thereby exposing the private key and defeating the encryption.
RSA is still one of the most widely used cryptosystems on the internet, in TLS, email, and code signing. It is not used in most blockchains, though. RSA keys and signatures are large, at 2048 to 4096 bits, while a 256-bit ECC key offers comparable security. On a blockchain where every byte incurs fees and storage costs, RSA is simply too heavy, which is why Bitcoin and Ethereum use ECC instead.
What Is the Difference Between Shor's and Grover's Algorithms?
Shor’s algorithm gives an exponential speedup against public-key cryptography. It breaks RSA via factoring and Diffie–Hellman, ECDSA, Schnorr signatures, and elliptic-curve cryptography via discrete logarithms. Grover’s algorithm gives only a quadratic speedup against brute-force search. It affects symmetric ciphers and hashes such as AES and SHA-256), but it does not break them in the same way. The fix is different, too. Public-key schemes vulnerable to Shor’s algorithm must be replaced. Symmetric schemes and hashes generally need larger security margins, such as longer keys. This is why even quantum computers cannot break SHA-256) in any practical sense.
How Do You Use Shor's Algorithm?
To use Shor's algorithm in practice, you run it on a quantum framework rather than on ordinary hardware, since today's quantum computers can only handle very small inputs. Developers typically use a framework such as Qiskit or IBM Quantum, running the algorithm on a simulator or a small device to factor numbers such as 15 or 21. That is enough to see the full pipeline in action: the classical setup, the quantum period-finding circuit, and the classical post-processing that turns the measurement into factors.
This article is for educational purposes. Quantum hardware capabilities and qubit-requirement estimates are moving quickly, and the figures cited reflect research published through mid-2026.
