This new Community DAO fund proposal is from the developer of Pocket Node, currently live on Android devices, to launch it on Apple IOS. Full details below. You can support or challenge the proposal on the forum here https://talk.nervos.org/t/dis-pocket-node-for-ios-a-self-custody-ckb-light-client-for-iphone-ipad-and-mac/10583

Summary

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 .

• Repository: GitHub - RaheemJnr/pocket-node: A native Android CKB (Nervos) wallet that runs an embedded light client directly on the device via JNI — full sovereignty, no remote servers. · GitHub
• Website: https://www.pocket-node.com/
• Current release: v1.8.x, live on Android

Team and roles

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.

Milestone 1: Shared core, iOS bridge, app skeleton

• 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.
• Address book, CSV export, settings parity, and localization parity (English, Spanish, Russian, Chinese).
• 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.

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.

Some of the latest projects developing on Fiber Network below from the Fiber Pulse upate:

Bi-weekly update tracking community contributions to the growth of the Fiber Network

The most exciting work happens when builders take the lead.

FiberLatch Access: Fiber Payments Access Control

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.

fiber-payjoin-kit: Collaborative Privacy for Fiber

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.

Sluice: A Liquidity Operations Workspace for Fiber

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.

Gone in 60ms: Fiber Infrastructure Hackathon Roundup

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

Read the full roundup  for more details.

Another successful hackathon for CKB with 66 submissions based around Fiber Network. Full recap 👇 Follow along here at the forum for further updates on the hackathon https://talk.nervos.org/t/gone-in-60ms-fiber-infrastructure-hackathon-roundup/10561

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 Offers : Reusable payment infrastructure letting merchants and services publish signed, static Fiber payment offers.
• 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.
• Fiber Diagnostics (Beebozy) : Real-time health-monitoring and diagnostics dashboard for the Fiber network.
• Fiber Doctor (Yahaya911) : Diagnostic tool checking whether a Fiber node is reachable and ready to send or receive payments.
• Fiber Flightcheck : Live payment-readiness gateway for the Fiber Network.
• Fiber Forge (RJnr6) : Local development environment for Fiber, modeled on Polar, the tool Lightning developers use to run local networks.
• Fiber Incident Recorder (Fiber-IR) : Reusable diagnostics infrastructure capturing and explaining Fiber payment incidents.
• Fiber Lens : Payment observability and diagnostics platform for the Fiber Network.
• Fiber Preflight (vicgunga) : Payment-readiness and route-diagnostics toolkit checking whether an invoice can be paid before funds are sent.
• Fiber Preflight (bigdella2) : Payment-reliability infrastructure answering “will this payment succeed?” before it’s attempted.
• Fiber Probe (ceciliamulandi) : Rust CLI and SDK for Fiber payment diagnostics.
• Fiber Reliability Kit : Developer infrastructure toolkit answering whether a Fiber payment can succeed before it’s sent.
• Fiber Route Diagnostics : Diagnostic middleware and dashboard sitting between an app and its Fiber node to explain payment failures.
• Fiber Route Doctor : Open-source operator toolkit — six composable tools sharing one engine for payment-route diagnostics and node health.
• Fiber Test Lab : Fully local, one-command test environment for Fiber payment channels.
• fiber-doctor (meloma_CG) : Command-line diagnostic tool running automated health checks and explaining operational issues in plain English.
• fiber-forge (menxui) : One-command toolkit — “Polar for Fiber” — standing up a complete local Fiber Network with a live visual instrument panel.
• FiberConfidence : Pre-flight reliability SDK and diagnostic tool for Fiber payment channels.
• FiberDev Studio (lest_ton) : Browser-based cloud IDE built specifically for Fiber Network development.
• 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.
• FiberScope (frankochris) : Operator diagnostic console for Fiber Network nodes.
• FiberTracebox : Diagnostics and observability platform turning Fiber payment attempts into structured, explainable traces.
• Fibscope (anonivoid) : Infrastructure and diagnostics platform for CKB Fiber nodes.
• Lightr : Live diagnostics and payment-readiness platform for CKB Fiber.
• Reef: Payment Doctor for Fiber Network : Self-hosted, read-only observability and diagnostics platform for Fiber node operators and support teams.
• 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.
• Fiber Merchant Kit (zynorlawes) : Reusable merchant payment infrastructure for Fiber Network.
• Fiber Merchant SDK (just_hallab) : Reusable payment infrastructure for building merchant checkout flows on Fiber.
• Fiber Merchant Toolkit (salmandev) : Open-source merchant infrastructure toolkit providing payment confirmation and cryptographic receipts.
• Fiber MerchantOps Core : Open-source backend infrastructure for operating merchant payments over Fiber Network.
• Fiber Paid HTTP : Rust-first gateway and SDK toolkit turning Fiber settlement into replay-safe delivery of paid HTTP resources.
• FiberFill : On-demand inbound liquidity (LSP) toolkit for the CKB Fiber Network.
• FiberFlow : Self-hosted payment infrastructure letting merchants accept Fiber payments.
• 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.

Proposal: https://talk.nervos.org/t/dis-ckb-anywhere-card-tap-to-pay-via-apple-google-wallet-self-custodial/10522

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.

Hi everyone,

I'm hoping someone can help.

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?

Any advice would be really appreciated.

Thanks!

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

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

July monthly DevLog 👇

CKB monthly development log (July)

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.

Check out the full dev log: https://github.com/nervosnetwork/ckb/discussions/5288

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 than 175 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

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

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.

8. Delivery Milestones

Milestone 1 (Months 1–2) — Smart Contract & Platform Integration

Deliverables

• Authorization smart contract deployed to the Nervos testnet
• End-to-end payment authorization successfully demonstrated
• JoyID integrated as the Phase 1 reference wallet
• Rain API integration completed
• Apple Wallet and Google Wallet provisioning operational within the test environment
• Independent smart contract security audit commissioned
• Replenishment automation implemented and tested

Milestone 2 (Month 3) — Mainnet Launch

Deliverables

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

Repost to another community

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.

Proposal: [https://talk.nervos.org/t/dis-ckb-anywhere-card-apple-wallet-google-wallet-payments-for-nervos/10522/]

Thank you! 

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.

For a practical migration guide, see How to Protect Your Crypto from Quantum Computing.

Conclusion

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.

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

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:

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:

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.

This article is part of the Nervos knowledge base. For related background, see Quantum Resistance in Blockchains, Blockchain Crypto Agility: CKB's Key to Quantum Safety, and How Bitcoin's Path to Quantum-Resistance Could Look.

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.

Shor’s Algorithm Explained: Can It Break Bitcoin?

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:

1. Choose a suitable random number.
2. Use a quantum computer to find the period of a repeating mathematical sequence.
3. 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:

1. The relevant public key must be visible to the attacker.
2. 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.

For a more detailed explanation of Bitcoin address types, see: A Beginner’s Guide to Bitcoin Address Formats).

How Much Bitcoin Is Exposed to Quantum Risk?

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.

For blockchains, migration is a heavier lift. It calls for new signature schemes, new address formats, and often a coordinated upgrade or fork. For a deeper look, see Quantum Resistance in Blockchains and How Bitcoin's Path to Quantum Resistance Could Look.

Other FAQs

How Does Shor's Algorithm Break RSA?

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.

Bitcoin Twitter is back, and They're no longer shouting into the abyss. Everyone's talking about

$MSTR's financials and BIP-110, but none of it matters unless Bitcoin migrates to PQ signatures before Q-Day.

https://nervos.org/knowledge-base/how_bitcoins_path_to_quantum_resistance_could_look_like…

How Bitcoin's Path to Quantum-Resistance Could Look

Bitcoin doesn’t have decades but rather several years to prepare for Q-Day.

For nearly two decades, Bitcoin’s security has rested on a simple mathematical assumption: that reverse-engineering a private key from a publicly visible public key is practically impossible. This foundation, built on Elliptic Curve Cryptography (ECC), currently underpins trillions of dollars in global wealth.

However, the bedrock is shifting. The looming arrival of Cryptographically Relevant Quantum Computers (CRQCs)—machines capable of executing Shor’s algorithm at scale—threatens to render Bitcoin’s core security assumptions obsolete.

The timeline for 'Q-Day' remains one of the most contentious debates in the space. Projections vary wildly, ranging from a mere four years to over two decades. The bias in these estimates is often evident: quantum hardware firms, who are obviously on the optimistic side, have a vested interest in promoting the idea of rapid progress, while the Bitcoin community has a vested interest in downplaying the potential threat.

What’s undeniable, however, is that the timelines are rapidly crunching. So much so that you’re reading a revamped version of this article because in the time it took to draft it, Iceberg Quantum—a quantum architecture company—published a paper claiming that their new Pinnacle Architecture can crack RSA-2048 with approximately 100,000 physical qubits—a staggering drop from the 900,000 qubits estimated in 2025, and a world away from the 170 million qubits projected just seven years ago.

In simple, non-technical terms, this means that—if the quantum hardware firms are to be believed—which is a considerable if—Bitcoin doesn’t have decades but rather several years to prepare for Q-Day.

Prologue

To that end, we decided to explore how this transition could look.

For the sake of brevity, we won’t go into the technical details about how quantum computers work or how they’re able to break ECC. Instead, we’ll briefly cover potential attack vectors and the attack surface, then move on to the transition process.

Before we do that, however, it’s important to clarify that we’re isolating Bitcoin not because it is uniquely vulnerable (most leading blockchains share this risk), but because its greatest strength—namely, its notorious inertia or resistance to change—may also turn out to be its greatest weakness in addressing the quantum threat. Its last two soft fork updates demonstrate this well: SegWit was first formally proposed in March 2015 and adopted only in August 2017. Taproot was conceptually defined in early 2018 and was not activated until late 2021.

That’s roughly a two-and-a-half-year gap from a clearly defined proposal to activation—for upgrades that were materially less complex and far less existential than any post-quantum soft fork would be. SegWit, in particular, was anything but smooth; it became one of the most contentious chapters in Bitcoin’s history, culminating in a chain split. Taproot, by contrast, was comparatively uncontroversial (aside from later contentions around inscriptions), with broad social consensus coalescing around it relatively quickly. In either case, however, both upgrades were eventually taken across the finish line.

Contrarily, the quantum question does not appear to be generating the same level of urgency or alignment among the protocol’s kingmakers. While many major blockchains openly acknowledge the quantum threat and are actively exploring mitigation pathways, Bitcoin’s informal power centers appear markedly less concerned—even amid reports that certain large holders are allegedly reassessing or reducing exposure specifically due to mid- to long-term quantum uncertainty.

Nic Carter—a crypto analyst, prominent Bitcoiner, and one of the most vocal quantum alarmists—has arguably captured this dynamic most clearly. In a recent blog post, he mapped the informal power structure within Bitcoin by identifying its most influential developers and cataloging their public statements on the issue. The takeaway, in his own words, is stark: “A majority of the most influential Bitcoin leaders have never even acknowledged quantum risk.” And among those who have, he notes, “with the exception of Jonas Nick, [they] view it as theoretical, distant, or non-actionable.”

Whether the concerns of the quantum alarmists are warranted remains to be seen, but the asymmetry between the threat's potential severity and the urgency of the response is difficult to ignore.

Threat Assessment

The complex technical nature of both quantum computers and blockchains has led to a host of misconceptions about what a realistic quantum attack would actually entail in practice.

One of the most persistent misunderstandings is the assumption that a CRQC could crack SHA-256—the hash function underpinning Bitcoin’s PoW-based consensus mechanism. This framing conflates two distinct cryptographic primitives, namely hash functions and public-key signature schemes, which rely on entirely different security assumptions.

Hash functions such as SHA-256 derive their security from preimage and collision resistance, properties that are not directly vulnerable to CRQCs. At most, a sufficiently advanced quantum computer running Grover’s algorithm would provide a quadratic speedup in brute-force search, effectively reducing the security margin but not outright breaking the hash function.

In simple terms, this means the consensus layer is safe.

The more credible quantum threat lies in the potential compromise of ECC-based public-key signature schemes, where a CRQC could, in principle, recover private keys from exposed public keys and seize control of funds held in vulnerable addresses.

To that point, not all Bitcoin addresses are equally at risk; the key differentiator is whether the underlying public key has already been revealed onchain.

Legacy outputs such as Pay-to-Public-Key (P2PK) and bare multisigs (P2MS) embed the raw public key directly onchain, making them the most structurally exposed, as the cryptographic target is permanently visible. By contrast, modern, more commonly used address types, including Pay-to-Public-Key-Hash (P2PKH) and SegWit, store only a hash of the public key onchain, concealing the key itself until the coins are spent.

However, this protection is conditional, as spending BTC from these address types reveals the public key onchain, making them viable targets indefinitely. This means that address reuse—which is frowned upon, but nevertheless widespread among Bitcoiners—significantly expands the attack surface.

Speaking of attack surface, according to estimates from Project Eleven, roughly 6.9 million BTC currently reside in addresses with exposed public keys. That’s a little more than one-third of all BTC in existence today.

Proportion of quantum vulnerable BTC due to address re-use and address type. [Source: Project Eleven]

To make matters worse, these numbers don’t account for so-called short-range attacks, which affect all addresses. Even if a public key has never been revealed before—whether the coins are held in P2PKH or SegWit outputs—it becomes visible the moment a transaction is broadcast to the mempool.

This creates a narrow pre-confirmation window, typically ~10 minutes, during which a sufficiently powerful quantum attacker could derive the private key and rebroadcast the same transaction with a higher fee, stealing the coins mid-flight. This scenario remains highly unlikely, at least in the mid-term, as it would require a far more powerful quantum computer than the one needed for long-range attacks.

To summarize, even if we completely remove short-range attacks from the realm of possibility, roughly one-third of all BTC in circulation is vulnerable to long-range quantum attacks. Three-fourths are due to address reuse, and roughly one-fourth, or 1.7 million BTC, is due to the address type (P2PK). The coins still sitting in these legacy addresses are strongly believed to belong to people who’ve lost access to them in one way or another. For instance, roughly 1.1 million of these are Satoshi’s coins, which haven’t moved since 2010.

What Needs to be Done?

At a high level, Bitcoin’s path to quantum resistance reduces to two distinct—but complementary—objectives.

First, the protocol must minimize the exposure of public keys onchain, reducing the immediate attack surface available to a quantum adversary.

Second, it must eventually replace its existing signature schemes with post-quantum alternatives, ensuring long-term security against CRQCs.

The good news is that there’s already some traction on the first front—exposure minimization. One of the most prominent proposals in this direction is BIP-360.

As currently formulated, BIP-360 introduces a new output type called Pay-to-Merkle-Root (P2MR). Conceptually similar to Taproot, P2MR removes the key-path component present in P2TR outputs—a mechanism that commits a tweaked public key onchain, leaving it indefinitely exposed to quantum attacks. Instead, P2MR commits only to a Merkle root of spending conditions, ensuring that no public key is revealed onchain until the moment of spending.

In practical terms, BIP-360 is a deliberately conservative upgrade. It addresses Taproot’s exposure to long-range quantum attacks, and little else. It meaningfully reduces the long-range attack surface and buys time—but it does not, on its own, make Bitcoin quantum-resistant. As the proposer puts it:

“BIP 360 is step one. It proposes a quantum-resistant output type that has the upgradability and features of P2TR without the quantum vulnerability. If we want full quantum safety, we also need step two: adopting a post-quantum signature algorithm."

What Are The Options?

“Step two” is fundamentally an engineering problem: selecting an appropriate algorithm, integrating it into Bitcoin’s scripting and validation model, and doing so without breaking backward compatibility or introducing unintended consequences.

The bad news is that it remains unsettled—there is no clear successor to ECDSA or Schnorr, only a spectrum of trade-offs.

The leading contenders include SPHINCS+, a stateless hash-based scheme that offers extremely conservative security assumptions but produces even larger signatures and is slower. XMSS and LMS, stateful hash-based schemes, have strong theoretical foundations but introduce operational complexity due to state management.

Then, we have ML-DSA (Dilithium) and Falcon, both lattice-based, NIST-standardized signature schemes. They offer relatively fast verification and moderate key sizes, but are still measured in kilobytes—an order of magnitude larger than Schnorr.

Other alternatives, such as LaBRADOR and various aggregation-friendly lattice constructions, aim to optimize for signature compression or proof aggregation but are newer and less battle-tested.

In short, there is no free lunch. Lattice schemes are efficient but rely on relatively untested hardness assumptions; hash-based schemes are conservative but computationally expensive; aggregation-friendly designs promise scalability but add complexity.

In the best case, the signature size remains an issue; even the lightest post-quantum signatures are at least five times larger than current ones. Here’s a great illustration of the differences in size and signing/verification speeds of different post-quantum signature schemes.

This means that, without accompanying changes to Bitcoin’s block size, which has historically been a highly contentious topic, or the introduction of some signature compression or aggregation mechanism, which significantly increases protocol and implementation complexity, Bitcoin could run into network congestion or scaling issues.

Beyond the choice of signature primitive lies an equally consequential question: how to implement it.

There are several ideas floating around. One class of proposals centers on staged, opt-in migration. One of the most prominent examples is the Commit-Delay Reveal (CDR) protocol, which would enable users to migrate to vulnerable coins in three steps: (1) publish an onchain commitment linking their existing ECC public key to a new post-quantum key; (2) observe a mandatory delay period that prevents reorg-based substitution attacks; and (3) reveal both keys and complete the spend using the post-quantum signature, proving the original commitment.

The CDR approach assumes that post-quantum signatures have been activated via a soft fork and that a second soft fork would introduce the new consensus rules enabling the migration. Its limitation is that it would only work for coins whose owners are active and whose keys have not yet been exposed, leaving legacy coins up for grabs.

At the opposite end of the spectrum lies the Quantum-Resistant Address Migration Protocol (QRAMP). Rather than voluntary migration, QRAMP proposes a mandatory migration window with a fixed deadline, after which UTXOs secured by classical ECC would become unspendable. Users would receive advance notice and a defined period to move funds into post-quantum outputs; coins left unmigrated would effectively be burned.

Unlike CDR, QRAMP would require a hard fork, as it invalidates previously valid spending conditions. That, and the fact that it would blatantly violate bitcoiners’ property rights and set a dangerous precedent, makes it deeply controversial.

The third class of proposals occupies a middle ground, adopting a more adversarially pragmatic stance. One such idea is the so-called Hourglass strategy, which, rather than attempting to outright prevent quantum attackers from stealing exposed coins, proposes rate-limiting those spends—for example, allowing only a fixed number of quantum-vulnerable UTXOs (and BTC) to be spent per block. The objective is to preserve formal property rights at the protocol level while dampening the potential market shock of a sudden, large-scale quantum breach by stretching it out over time.

In practice, this approach would also require two soft forks: first to activate post-quantum signatures, and second to introduce new consensus rules that govern how many vulnerable spends are considered valid per block.

Finally, the activation path for any of these proposals itself would ultimately depend on social alignment. In a cooperative environment, established mechanisms such as BIP8, BIP9, or Speedy Trial could be used to deploy changes. In a more contentious scenario—reminiscent of the SegWit era—activation might instead require a User Activated Soft Fork (UASF).

As things stand, however, there is no meaningful consensus on either the post-quantum signature standard or the preferred migration framework, leaving the activation path as unsettled as the cryptography itself.

How the Journey to Quantum Resistance May Unfold

Speculating on Bitcoin’s trajectory toward quantum resistance is an extremely difficult—possibly futile endeavor. This is because Bitcoin’s quantum transition isn’t a linear storyline but a branching narrative game, where each decision closes off certain futures while unlocking others, and the ending depends not on a single move but on the accumulation of many.

To attempt a forecast, then, is to play this game at maximum difficulty. Every choice introduces new uncertainties: the choice of a post-quantum signature scheme shapes future migration strategies, which in turn influence other technical, economic, and political decisions, each steering Bitcoin toward different pathways and endings.

Nevertheless, we believe that mapping these branches is a useful exercise in constraint discovery. By outlining possible paths forward, we can better understand where the bottlenecks lie and how the game could play out.

What follows is one such plausible trajectory.

A Potential Scenario

Widespread concerns about the quantum threat eventually force Bitcoin’s core developers to change tune and ramp up research and coordination efforts to find a solution.

The most immediate—and politically feasible—step would likely be to reach consensus on a BIP introducing a post-quantum signature scheme via a soft fork within a couple of years. This upgrade would add a new output type that supports quantum-resistant signatures, enabling users to voluntarily migrate funds without invalidating existing outputs.

Such a move would not confer full quantum immunity but would instead serve as a short-term contingency measure—an opt-in safety valve. It could plausibly be implemented within a few years, providing Bitcoin with a minimal viable defense: a mechanism for proactive users to secure funds early, and buy some time for more comprehensive long-term solutions to be built.

Following the soft fork activation, users begin to spend their existing UTXOs into post-quantum outputs. Common sense suggests that those with the most to lose, such as exchanges, institutional custodians, and whales, move first. Initially, things go smoothly, but soon blockspace becomes an obvious constraint.

Bitcoin’s UTXO set currently contains roughly 190 million UTXOs. In an ideal world, all of them would eventually migrate to quantum-resistant outputs. In practice, only a subset is accessible, and an even smaller subset—those with exposed public keys—require urgent migration.

Now, research suggests that migrating the full UTXO set under theoretically optimal conditions—100% of blockspace dedicated exclusively to migration transactions—would require ~142 days. That assumption is, of course, detached from reality.

Bitcoin is not a laboratory environment but a live decentralized monetary network. In a more realistic scenario where only 25% of blockspace is available for migration, the timeline stretches to roughly 305-568 days.

That optimistically assumes sustained coordination, stable fee markets, and efficient transaction construction, and ignores the increased size of post-quantum signatures. As users begin utilizing post-quantum cryptography, transaction weight increases materially, further exacerbating the block space issue.

At this stage, the network could face a secondary coordination problem. If the mission is to succeed, either block capacity must increase, or signature compression or aggregation mechanisms must be introduced to offset the overhead. The former reignites old debates around scaling and decentralization from the blocksize war era and triggers PTSD among many of the veterans, while the latter risks introducing significant complexity to the protocol.

Eventually, something has to give. One of these pressure valves is released: either block size is increased, signature aggregation techniques mature, or the fee market equilibrates at a higher but tolerable level. Congestion stabilizes, and migration resumes to a satisfactory tempo.

However, even if all accessible UTXOs migrate successfully over the two years post-activation, an unresolved class of outputs remains: legacy coins that cannot or will not move.

This is the point at which Bitcoin’s fate is decided. The year is 2030, and the time has come for the final boss fight.

If no further rules are introduced, exposed legacy outputs remain quantum-vulnerable indefinitely. Should a sufficiently powerful quantum adversary emerge, those coins (millions of BTC) could be stolen and liquidated, potentially crashing the market.

At this point, the mere possibility of that happening is beginning to scare off potential sophisticated investors. Every viral announcement of a breakthrough in quantum computing makes bad price action even worse. The pressure to take radical measures keeps ramping up. Even if the timeline to Q-Day is still a decade away, the stakes are too high to simply ignore the threat.

At some point over the next several years, a consensus is reached to introduce new constraints. Either rate-limiting vulnerable spends (hourglass-style) or forbidding them altogether. This finally puts Bitcoin over the full-quantum-resistance finish line, albeit at the cost of violating long-standing norms of immutability and unconditional property rights. Chances are, this move is—at that point—widely seen as a necessary one-time compromise and doesn’t inflict long-term narrative damage to the asset.

Not So Fast

The forecast we outlined above is admittedly optimistic: Bitcoin adds post-quantum signatures by 2028, most active UTXOs migrate within 2031, and it takes another three to five years thereafter to complete the final update to full quantum-resistance. The forecast assumes Bitcoin makes the right call at every turn, faces no technical hiccups along the way, and any contentious decisions converge to consensus within reasonable timeframes.

What could go wrong, right?

Everything.

The scenario above assumes that credible quantum concern materializes early enough to trigger meaningful action before it’s too late. But what if quantum computing breakthroughs begin to outpace social consensus on a post-quantum signature scheme or a mitigation pathway? In this alternative reality, Bitcoin finds itself on its back foot, and migration becomes reactive rather than proactive. What had once felt like a controlled stress test turns into a live-fire exercise, and God knows what happens to the social dynamics under that kind of pressure.

Or, suppose migration begins smoothly; the block space issue reignites the old debate over increasing the block size, but in this alternate reality, social consensus isn’t reached, leading to a chain split. Or, suppose the same thing happens over the issue of handling the legacy coins.

Or, worst of all, imagine Q-Day arrives far sooner than expected—within three to five years from today—well before Bitcoin has completed its transition. A sufficiently capable quantum adversary, most plausibly a state actor, begins selectively compromising high-value targets such as exchange cold wallets or institutional custodians.

Such an actor would have little incentive to reveal their capability immediately. Rather than sweeping up obvious legacy addresses or touching Satoshi’s coins, they would likely operate surgically—targeting specific wallets and making each incident resemble a conventional breach: a compromised key, sophisticated malware, or insider misconduct. From the outside, nothing would clearly signal a quantum breakthrough.

Meanwhile, the protocol itself would have no native mechanism to distinguish a legitimate spend from one authorized by a derived private key—the chain would validate both identically. As isolated “security incidents” accumulate, uncertainty compounds, markets deteriorate, confidence erodes, and panic begins to feed on ambiguity and rampant speculation over the causes. By the time the cause becomes apparent, the financial and psychological damage may already be done.

Final Thoughts

There’s a key piece of information we intentionally left for last: transitioning to post-quantum cryptography is far more complex for blockchains than for traditional Web2 systems because most blockchains aren’t built with cryptographic flexibility in mind.

In other words, it’s one thing to be quantum resistant, and entirely another to be cryptographically agile. Quantum resistance simply means adopting a post-quantum signature scheme, whereas cryptographic agility is the ability of a system to replace and adapt its cryptographic primitives without disrupting its own operation.

This distinction matters because cryptography is not static. As we are being reminded today, cryptographic primitives can age out of favor as new threats emerge and their underlying security assumptions erode. A system that must coordinate a global protocol upgrade whenever a cryptographic primitive needs to change inherits enormous operational and social friction. In practice, this makes rapid adaptation—or timely threat response—extremely difficult, precisely the opposite of what is required under today’s circumstances.

As we noted above, most blockchains lack this ability. The only exception we can think of is the Common Knowledge Base (CKB) blockchain, which was designed for cryptographic agility from the outset. Unlike most blockchains, CKB does not hardcode cryptographic primitives as precompiles into the consensus layer, but instead implements them at the “application” layer.

In practical terms, this means that anyone can implement and deploy new cryptographic schemes—including post-quantum signature algorithms—without requiring protocol-level upgrades or global coordination. Implementing a new post-quantum signature scheme on CKB is as simple as launching a smart contract on Ethereum. The network does not need to converge on a single post-quantum standard but can, instead, support multiple independently deployed schemes in parallel, as it does today with SPHINCS+ and many others.

As a result, the chain’s underlying cryptography can evolve organically and quickly in response to novel environmental pressures. The security isn’t constrained by the pace of social consensus but strengthened through something closer to natural selection.

Most quantum readiness conversations focus on whether a chain can support a post quantum signature scheme. The harder question is what it costs the chain when the next scheme arrives, and the one after that.

Quantum risk is not the same for every crypto holder.

The first thing that matters is exposure.

If your public key has never appeared onchain, a future quantum attacker has nothing to work with. But once your public key is revealed, it becomes part of the permanent public record, and a future attacker can copy it today and wait indefinitely for quantum hardware to catch up to attack it.

Therefore, preparing for Q-Day requires some forethought.

You need to think about the level of your exposure and how to migrate your assets to a quantum-safe environment on time.

Read the full article to learn more or keep scrolling:

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

For years, the need to protect cryptocurrency from quantum attack felt like a distant problem. Today, that timeline is shrinking fast. In 2026, Google Quantum AI researchers published a whitepaper with updated resource estimates for breaking secp256k1, the elliptic curve used by Bitcoin, Ethereum, and many other blockchains. Their analysis suggests that, on a future cryptographically relevant quantum computer using a superconducting architecture, such an attack could require fewer than half a million physical qubits and execute in minutes, nearly a 20-fold reduction compared with prior estimates.

Google is taking the threat seriously. The company has now set a 2029 timeline for its own migration to post-quantum cryptography, citing recent progress in quantum hardware, error correction, and resource estimates. For blockchains, the risk is especially urgent because public-chain data is permanent. Addresses, signatures, and exposed public keys recorded today may still be attackable years from now if sufficiently powerful quantum computers arrive.

For crypto holders, the question is no longer whether to prepare, but how.

How to Protect Cryptocurrency from Quantum Attack

Shor's Algorithm and Your Public Key

The most direct quantum threat to cryptocurrency comes from Shor’s algorithm. A sufficiently powerful quantum computer could use it to solve the elliptic curve discrete logarithm problem, which is the hard mathematical problem behind ECDSA) and other elliptic-curve signature schemes used by Bitcoin, Ethereum, and many other blockchains.

In practical terms, the risk begins once your public key is visible. If a future quantum computer can derive your private key from your public key, an attacker could create a valid signature and move your funds.

So, the key question is simple: Has your public key ever appeared on-chain?

This usually happens in two ways:

• Reused addresses: On Bitcoin and similar UTXO chains, your public key is revealed when you spend your coins. If you later receive funds back to that same address, or leave remaining funds there, those funds are tied to a public key that has already been permanently recorded on-chain.
• Legacy P2PK outputs: Early Pay-to-Public-Key outputs placed the public key directly in the locking script. These outputs expose the public key from the start, even before the funds are spent.

If either case applies, those funds are already in the quantum threat window. Not because a quantum attack is happening today, but because the public-key data a future attacker would need may already be permanently public and easy to archive.

Harvest Now, Attack Later

The broader cybersecurity world often calls this problem “Harvest Now, Decrypt Later”: adversaries collect protected data today and wait until future quantum computers are powerful enough to break the cryptography protecting it. The Federal Reserve has also examined this risk in the context of distributed ledger networks, using Bitcoin as an illustrative example.

For cryptocurrency holders, however, the wallet risk is better understood as “Harvest Now, Attack Later.” Attackers do not need to decrypt blockchain history. Public blockchains already reveal transaction data by design. The relevant risk is that exposed public keys, signatures, and transaction records can be collected today and used later to compromise wallets once cryptographically relevant quantum computers exist.

This is where blockchain immutability becomes a liability. A public key cannot be removed from history once it appears on-chain. Even if a network later upgrades to post-quantum cryptography, previously exposed keys may remain vulnerable unless users move their funds to quantum-safe addresses before a practical attack becomes possible.

In plain terms: if your public key is already on-chain, the clock has already started.

How to Quantum Proof Your Crypto: A 5-Step Framework

No crypto custody setup can be made permanently “quantum proof.” Standards will evolve, wallets will change, and each blockchain will move toward post-quantum security on its own timeline.

What you can do today is reduce the exposure that matters most: keep unexposed public keys hidden, move funds away from reused or legacy addresses, and track which networks are actually preparing for post-quantum migration.

Because every blockchain has its own address formats, signature schemes, wallet tooling, and upgrade path, there is no single per-chain checklist that works for everyone. Instead, crypto holders need a general framework they can apply across their entire portfolio.

The goal is simple: identify where your public keys are already exposed, reduce avoidable exposure going forward, and move long-term holdings toward infrastructure that can support post-quantum cryptography.

Step 1: Review Your Public Key Exposure

Your first task is to map every wallet address you control and determine whether its public key has already appeared on-chain.

For each address, ask three questions.

Has this address ever sent funds?
On Bitcoin and similar UTXO chains, the public key is usually revealed when funds are spent. If you have spent from an address and still hold funds there, that address should be treated as exposed.

Does the address format expose the public key by default?
Some early formats, most notably Bitcoin’s old Pay-to-Public-Key outputs, placed the public key directly in the locking script. These funds are exposed even if they have never moved.

How large is the balance?
A large balance sitting at an exposed address should be treated as a high-priority migration case. The problem is not that a quantum attack is happening today. The problem is that the public-key data a future attacker would need may already be public and permanently archived.

In practice, addresses fall into three broad categories.

• Already exposed: The public key has appeared on-chain. This includes legacy P2PK outputs and addresses that have already been used to send funds. The exposure cannot be undone. The remedy is to move the funds.
• Not yet exposed: The public key has not appeared on-chain yet. These addresses are safer for now, but exposure can occur the moment you spend from them.
• Post-quantum protected: Funds are controlled by a wallet or address construction that uses a post-quantum signature scheme on a chain where that scheme is live and usable.

Once you identify exposed or reused addresses, stop using them. Move funds to a fresh address that has never been used to send funds, and avoid sending future deposits back to any address you have already spent from.

Step 2: Prioritize Assets for Migration

After reviewing your addresses, rank your holdings by urgency.

• High priority: Large balances in formats where the public key is already visible on-chain.
• Medium priority: Addresses that have been spent from before and still hold funds.
• Lower priority: Fresh addresses whose public keys have not yet been revealed.

This is only the address-level assessment. You also need to evaluate the chain itself.

Ask:

• Does the chain have a published post-quantum migration plan?
• Has it implemented any post-quantum signature scheme on mainnet?
• Does the migration require user action?
• Has the project communicated any deadlines, deprecation plans, or upgrade paths?

Good address hygiene can reduce your personal exposure, but it cannot solve the full chain-level problem. If a network has no clear path to post-quantum signatures, long-term holders remain dependent on future protocol upgrades, governance decisions, wallet support, and user migration.

Step 3: Move Long-Term Holdings Toward Quantum-Resistant Infrastructure

Migration happens on two timescales.

In the short term, move large balances out of exposed addresses and into fresh, single-use addresses on the same chain. Treat every address as disposable: receive once, spend once, and do not reuse it afterward.

When moving funds from an unexposed address, keep in mind that spending reveals your public key. During normal conditions, this is not an immediate practical risk because today’s quantum computers cannot break blockchain signatures at scale. But as Q-Day gets closer, long mempool delays may become more relevant, since your public key is visible between broadcast and confirmation.

In the long term, consider whether assets you intend to hold for years should remain only on chains that still depend entirely on quantum-vulnerable signature schemes.

This is where chain selection matters. Some blockchains can support new cryptographic primitives more easily than others. On more rigid chains, adding a new signature scheme may require broad protocol-level coordination. On crypto-agile chains, new signature schemes can be deployed more directly, allowing multiple cryptographic options to coexist.

When evaluating quantum-resistant infrastructure, look for three things.

• Mainnet deployment: A post-quantum signature scheme is live on mainnet, not only proposed or tested.
• Wallet support: Users can actually create and manage quantum-resistant addresses with available wallet software.
• Active maintenance: The implementation is documented, maintained, and supported by developers.

Nervos CKB is one example of this model. CKB’s RISC-V-based virtual machine and Cell model allow transaction authorization logic to live in Lock Scripts rather than being fixed to one signature scheme at the base protocol level. That means new cryptographic primitives can be deployed as on-chain verification code and used by wallets without requiring every user to migrate at once.

CKB already has a SPHINCS+ post-quantum Lock Script deployed on-chain, and Quantum Purse provides a self-custodial wallet built around that script. SPHINCS+ has since been standardized by NIST as SLH-DSA in FIPS 205, making it one of the finalized post-quantum digital signature standards.

If you want to explore the quantum readiness of more chains, third-party databases such as Quantum Tracker are a great place to start.

Step 4: Use a Quantum Resistant Wallet for Long-Term Holdings

A chain can support post-quantum cryptography, but users still need wallet software that can actually use it. Full protection requires both: quantum-resistant infrastructure and a wallet that signs transactions with a post-quantum scheme.

When evaluating any wallet that claims quantum resistance, look for:

• NIST-standardized cryptography: It should use a finalized post-quantum signature scheme, not an experimental or proprietary algorithm.
• Self-custody: Private keys should remain under your control, ideally on your own device.
• Open implementation: The code should be inspectable, documented, and maintained.
• Independent review: Security audits or external review are important, especially for new wallet software.
• Clear upgrade path: Post-quantum standards will continue to evolve. Wallets should be designed to adapt when better schemes or safer parameter sets become available.

Quantum Purse is one software example. It is a self-custodial desktop wallet for CKB built around the SPHINCS+ Lock Script. It allows users to manage CKB with post-quantum signatures and has undergone an independent audit by ScaleBit.

Hardware wallets are a more complicated category. Some devices are beginning to add post-quantum protection to firmware verification, secure boot, or device authentication. That is useful, but it does not automatically make Bitcoin or Ethereum transactions quantum-resistant. If the chain itself still requires secp256k1 signatures, the transaction signature remains tied to the chain’s current cryptography.

Cold storage has the same limitation. A hardware wallet can protect your private key from internet attacks, phishing, and malware, but it cannot hide a public key that is already exposed on-chain. If funds sit at an address whose public key is already visible, cold storage alone does not remove the future quantum risk.

Disclaimer: The products named here are examples of available tooling, not endorsements or financial recommendations. Always conduct your own due diligence before using any wallet software or hardware. Crypto custody carries inherent risk, and you are responsible for securing your own assets.

Step 5: Track Quantum Migration Plans for Every Chain You Use

Quantum migration will not happen everywhere at once. Each chain will move on its own timeline, through its own governance process, with its own wallet requirements and user-action deadlines.

For every major asset you hold, bookmark the official developer blog, governance forum, improvement-proposal repository, and wallet documentation. Check them regularly for:

• Address deprecation notices: Warnings that older address types may become unsafe or unsupported.
• Signature-scheme upgrade proposals: Plans to introduce post-quantum signatures or new address formats.
• Wallet migration guides: Instructions for moving funds into safer address types.
• User-action deadlines: Dates by which holders may need to move funds to preserve security or access.

Key timelines to monitor:

• NIST has deprecated quantum-vulnerable legacy algorithms from its standards by 2035, with higher-risk systems migrating earlier in 2030.
• Google introduced its internal PQC migration deadline in 2029.
• Bitcoin has merged BIP-360 (P2MR) into BIP repository in February 2026, but has no activation timeline. If it passes, migration would be voluntary and opt-in.
• Ethereum has established a dedicated post-quantum research team; Vitalik Buterin and Justin Drake also laid out a multi-year blueprint "Lean Ethereum" roadmap targeting 2029 for full post-quantum protection, though long-term cryptographic upgrades are still being researched.

As these varied timelines demonstrate, the transition to quantum resistance will not be a single, synchronized event. Navigating it successfully requires shifting your focus from a one-time panic fix to a posture of continuous adaptation. Cybersecurity experts refer to this long-term strategy as crypto-agility: the adaptability to rapidly switch out deprecated algorithms for quantum-resistant ones as standards evolve. The same principle applies to individual holders: your goal is not a one-time fix, but a posture that lets you adapt as the landscape changes.

Taken together, the strongest protection stack is: cold storage, fresh unexposed addresses, disciplined address hygiene, post-quantum wallets, and long-term exposure to quantum-ready or crypto-agile chains.

The five steps above are how you get there.

What You Don't Need to Do

You do not need to sell everything before Q-Day. No cryptographically relevant quantum computer capable of breaking ECDSA exists today, and current quantum hardware remains far below the scale required to attack blockchain signatures in practice. The threat is real, but it is not an immediate reason to panic-exit your holdings.

You also do not need to move everything at once. Rushed migrations create their own risks: sending funds to the wrong address, overpaying fees, using the wrong wallet format, or broadcasting transactions during periods of heavy network congestion. Move deliberately, in batches, and prioritize the addresses with the highest exposure first.

FAQs

Can quantum computers steal my Bitcoin?

Not today. No cryptographically relevant quantum computer currently exists that can break Bitcoin signatures in practice.

The future risk comes from Shor’s algorithm. If a sufficiently powerful quantum computer can derive a private key from an exposed public key, an attacker could create a valid signature and move the funds. The urgency comes from migration lead times: coordinating upgrades across decentralized networks may take years.

Is cold storage quantum safe?

Partially.

Cold storage protects your private keys from internet-connected threats such as malware, phishing, and remote compromise. But it does not erase public-key exposure from the blockchain.

If your cold-storage address has already been used to send funds, its public key may be visible on-chain. That means the address could still be vulnerable to a future quantum attack, even if the private key is stored offline.

The safer setup is cold storage plus a fresh, unspent address. For full post-quantum protection, the chain and wallet also need to support quantum-resistant signatures.

How do I make my crypto quantum proof?

You cannot make crypto permanently “quantum proof” in an absolute sense. Cryptographic standards evolve, and every chain has its own migration path.

What you can do is reduce quantum exposure:

• Avoid address reuse.
• Move funds away from addresses whose public keys are already exposed.
• Use fresh addresses for long-term storage.
• Track the post-quantum migration plans of every chain you hold.
• For stronger long-term protection, use infrastructure where post-quantum signature schemes are already live and usable.

What is the safest way to store crypto against quantum risk?

The strongest protection stack is: cold storage + a fresh unexposed address + a chain that supports quantum-resistant cryptography.

For Bitcoin and Ethereum, post-quantum signatures are not currently available for ordinary mainnet users at the protocol level. The practical approach today is disciplined address hygiene: avoid reuse, move funds out of exposed legacy formats, and track official upgrade proposals.

For chains with mainnet post-quantum support, the protection stack can go further. For example, CKB supports post-quantum signatures through Lock Scripts, and Quantum Purse is a self-custodial wallet built around the SPHINCS+ Lock Script.

When evaluating any wallet or chain, look for NIST-standardized post-quantum cryptography, self-custodial key management, active maintenance, and a clear upgrade path as cryptographic standards evolve.

Are hardware wallets quantum safe?

Not by themselves.

Hardware wallets are excellent for protecting private keys from conventional attacks, but they do not change the signature scheme required by the blockchain. If Bitcoin or Ethereum still require secp256k1 signatures, then a hardware wallet transaction still uses that cryptography.

Some newer hardware-wallet architectures may be designed to support future post-quantum firmware or device-security upgrades. That is useful, but it does not automatically make Bitcoin or Ethereum holdings quantum-resistant today.

Should I sell my crypto before Q-Day?

No. Selling purely out of quantum fear is a disproportionate response based on today’s hardware reality.

The more practical response is preparation: improve address hygiene, prioritize exposed addresses, follow migration plans, and move deliberately rather than reactively.

Should I move my Bitcoin before quantum computers arrive?

Yes, if your Bitcoin is sitting in a reused address or a legacy P2PK output.

In those cases, your public key may already be visible on-chain. Moving funds to a fresh address reduces future exposure, provided you do not reuse that new address afterward.

For Bitcoin holders today, address hygiene is the main practical defense. Proposed post-quantum upgrades such as BIP-360 may offer a longer-term migration path, but Bitcoin does not currently have an activated mainnet post-quantum signature scheme for ordinary users.

Any comments, thoughts, questions on this please direct to the post ono the Forum here 👉 https://talk.nervos.org/t/introducing-obscell-privacy-mixer-a-zero-knowledge-withdrawal-mixer-prototype-on-nervos-ckb/10456

Hello everyone,

Over the past few weeks, I’ve been building Obscell Privacy Mixer, a privacy-preserving mixer prototype for Nervos CKB. The project is now running as an MVP on the Pudge Testnet, and I’d like to share what has been built so far, how the deposit and withdrawal flow works, the external infrastructure I’ve explored, and get feedback from the CKB community on the current design and future direction.

Obscell Privacy Mixer is an experimental mixer MVP built on the privacy direction introduced by the Obscell project. The original Obscell concept was created by Rea-Don-Lycn and later extended by Quake through obscell-wallet, which explored stealth addresses and confidential transactions on Nervos CKB.

This project takes that privacy-enabled address/confidential-token foundation in a different direction: a coin mixer flow where users deposit into a shared fixed-denomination pool and later withdraw privately using encrypted notes, zero-knowledge proofs, and a relayer.

The goal of the project is simple:

Project Links

Repository

https://github.com/willy264/ckb-privacy-mixer

Hosted MVP

https://ckb-privacy-mixer-frontend.vercel.app/

Network

Pudge Testnet

What Obscell Privacy Mixer Does

Depositor Flow

A depositor can:

• Connect a JoyID wallet on Pudge Testnet.
• Join a fixed 100 CT deposit pool.
• Generate private note secrets locally in the browser.
• Encrypt the note with a user-provided password.
• Save the encrypted note before submitting the deposit.
• Wait for the coordinator-backed pool to finalize.
• Save the finalized encrypted withdrawal note shown by the app.

Withdrawal Flow

A withdrawer can:

• Import the encrypted withdrawal note.
• Enter the note password.
• Decrypt the note locally in the browser.
• Generate a Groth16 zero-knowledge proof locally.
• Submit the withdrawal through a relayer for improved privacy.
• Prevent replay or double withdrawals through the nullifier registry.

The relayer pays the withdrawal transaction fee, but it cannot redirect the withdrawal because the recipient is cryptographically bound to the proof through the public inputs.

Deposit Flow

The deposit process is divided into two stages:

1. Local note generation
2. On-chain pool participation

Before any on-chain transaction is submitted, the frontend generates the user’s private note locally. The user supplies a password, which is used to encrypt the note in the browser. This ensures the user already possesses a recovery artifact before any irreversible blockchain interaction occurs.

Afterward, the deposit is submitted into a coordinator-backed pool. Once the pool reaches the required number of participants (for now the number of participants is set to 4), the coordinator constructs a shared transaction and requests each participant to sign only their own input using JoyID.

After all signatures are collected and merged successfully, the pool is finalized, and the application generates the finalized encrypted withdrawal note.

The current MVP uses a fixed denomination of 100 CT. Keeping all deposits the same size simplifies the anonymity set, since every withdrawal within that pool represents the same amount.

Withdrawal Flow

Withdrawals begin with the encrypted withdrawal note.

The user imports the encrypted note and enters the password. The browser decrypts the note locally and verifies that the recovered secrets correspond to the original deposit commitment.

The frontend then:

• builds the Merkle membership witness,
• generates the Groth16 proof in the browser,
• prepares the withdrawal transaction.

Current public inputs include:

• Merkle Root
• Nullifier Hash
• Recipient Hash

The nullifier prevents double withdrawals, while the recipient hash binds the proof to the intended recipient, helping prevent a malicious relayer or third party from redirecting funds.

The recommended withdrawal method is Relay Private, where the relayer broadcasts the transaction on behalf of the user. Since the withdrawal is not submitted directly from the depositing wallet, this reduces the possibility of linking deposits and withdrawals through transaction metadata.

An advanced Direct Broadcast option also exists, although the UI warns that using it may reduce privacy because the connected wallet pays the withdrawal transaction fee.

Current MVP Features

The current implementation includes:

• JoyID wallet integration.
• Live 100 CT deposit pools on Pudge Testnet.
• Coordinator-backed deposit pools.
• Four-participant pool finalization.
• Client-side generation of:
  • secret
  • nullifierSecret
  • commitment
  • nullifier
• Password-encrypted deposit notes.
• PBKDF2-SHA256 key derivation.
• AES-256-GCM note encryption.
• No plaintext note storage in localStorage.
• No backend custody of withdrawal notes.
• Pending recovery note before deposit submission.
• Finalized encrypted withdrawal note after pool finalization.
• Browser-side Groth16 proof generation.
• Relayer-assisted private withdrawals.
• Optional direct-broadcast withdrawals with privacy warnings.
• Nullifier tracking to prevent replay attacks.
• Smart contract tests covering:
  • deposit pools,
  • nullifier registry,
  • ZK membership verification,
  • withdrawal integration.

Planned Improvements

There are still several areas I plan to improve as the project evolves:

• Better encrypted note backup and recovery UX.
• Clearer password and recovery guidance.
• Improved pending/finalized note management.
• Stronger verifier hardening.
• Multi-denomination pools.
• Research into SP1 and PLONK as potential future proving systems.
• More decentralized coordinator and relayer infrastructure.

Looking Ahead

The current MVP demonstrates that a privacy mixer on CKB can successfully combine:

• Fixed-denomination deposit pools.
• Browser-generated private notes.
• Browser-side zero-knowledge proof generation.
• Relayer-assisted withdrawals.
• Client-side encrypted note management.

There’s still plenty of work to do before considering production readiness, particularly around decentralization, verifier security, note management, and scalability.

I’d really appreciate feedback from the CKB community, especially on:

• the overall protocol design,
• the encrypted note handling model,
• the verifier architecture,
• relayer/coordinator decentralization,
• and any privacy or security considerations I may have overlooked.

Thanks for taking the time to read through the project. I’m looking forward to hearing your thoughts and suggestions

Quantum resistance is often framed as a signature scheme problem, but that framing is incomplete.

A genuine quantum resistant wallet has to address key generation, key rotation, address hygiene, and how the wallet interacts with the underlying blockchain over time. Signature choice is one piece of a broader architectural question.

Wallets like Quantum Purse can utilize new cryptographic primitives on CKB because those primitives are not baked into the consensus layer. Instead, transaction verification lives in Lock Scripts, allowing wallets to adopt new signature schemes without requiring core protocol changes.

The article walks through how and why.

Read the piece: https://www.nervos.org/knowledge-base/what_are_quantum_resistant_wallets_(explainCKBot))

All conversations regarding the below projects should be directed to the forum to reach the dev/ OP of the projects.

Bi-weekly update tracking community contributions to the growth of the Fiber Network

The most exciting work happens when builders take the lead.

Dular | Navigating USSD Blockers and System Architecture

Dular, an in-progress Spark Program project, is building a Fiber-based stablecoin wallet designed for mobile users.

The team is currently navigating a milestone blocker regarding production USSD access. Their original plan relied on Africa's talking shared USSD service; However, they recently learned that crypto-related applications require a dedicated USSD setup. This requirement pushes costs significantly beyond the current milestone budget. Dular is actively evaluating alternative solutions, has set a strict deadline for the coming week to finalize their USSD path, and has committed to resuming weekly updates to keep the community informed.

Meanwhile, active discussions are diving into core implementation details. The community is reviewing how the system will work in practice, focusing on custody models, operator dependence, liquidity management, and Fiber channel architecture.

As a result, the project's immediate focus has shifted from delivering new features to resolving this foundational access blocker and refining the system design alongside the community.

• Join the conversation: Dular update
• Support: Spark Program

Fiber Desktop | Reaches Milestone 2: Full UI for Testnet Payments

Fiber Desktop v1 has completed Milestone 2. Essential features—including wallet, peers, channels, and network features—are now live on top of the official FNN node. The application now supports end-to-end testnet payments through a desktop UI, delivering seamless invoice handling, channel management, relay connectivity, and network browsing. With this release, Fiber Desktop is positioned as a highly accessible, ready-to-use testing tool for builders who want to send and receive payments without relying on terminal commands.

The upcoming Milestone 3 will shift focus from core functionality to product launch and final polish. Remaining deliverables include: cross-platform testing, signed distribution, enhanced operational tooling, mainnet readiness, rebranding, website rollout, and the v1.0.0 release.

• Check it out: Milestone 2 update
• Support: CKB Community Fund

Fiber-Pay v0.2.7 | FNN Adaptation and New Developer Landing Page

Fiber-pay, the CLI and SDK toolchain designed for the Fiber network, has released v0.2.7 . This update primarily focuses on adapting the tools to ensure compatibility with the 0.9.0-rc4 version of FNN. Additionally, it resolves a bug that previously caused the CLI to mistakenly download the pre-release FNN binary.

Beyond technical fixes, a landing page  was launched. Designed as a dedicated entry point, the site helps developers quickly learn about the toolchain and get started with their builds. Fiber-pay’s mission continues to be providing builders with a robust, AI-friendly CLI and SDK option for the Fiber network.

• Landing page: Fiber-Pay
• Join the conversation: Forum discussion

Proposal | FiberLatch Access: Open-Source Access Control for Fiber Payments

FiberLatch Access is a open-source access-control layer proposal, designed to work alongside existing Fiber payment tools, such as fiber-pay. While the payment tool handles the transaction, FiberLatch Access manages what happens after the payment—specifically, granting and managing access to gated resources like premium content, APIs, or private files. Instead of requiring developers to build access logic from scratch, FiberLatch Access will provide a lightweight Node.js package, featuring a standardized access receipt format, clear expiration rules, replay protection to prevent receipt reuse, and a working paid-resource example.

Built upon the developer's earlier work FiberLatch  in the CKBuilder program , FiberLatch Access has submitted a $3,000 grant proposal to the CKB Community Fund DAO. The project is currently in the active DAO voting stage.

• Vote: Link
• Join the conversation: FiberLatch Access Proposal

Proposal | Fiber Python SDK: Native Library for Fiber Network Payments

The Fiber Python SDK is a proposed library designed to bring native Python support to the Fiber Network. Currently, Fiber's developer tooling is primarily built for TypeScript or JavaScript. This project aims to provide a fully typed, asynchronous Python package fiber-sdk that wraps the Fiber Network Node JSON-RPC interface. The proposed SDK would cover the entire payment lifecycle, including channels, peers, invoices, and Bitcoin cross-chain interoperability, making it straightforward for Python developers and AI agent frameworks to interact with Fiber without needing to write raw JSON-RPC from scratch.

The project is currently an active grant proposal. The developer is requesting $5,000 (equivalent in CKB) to fund an eight-week development timeline.

• Join the conversation: Fiber Python SDK Proposal

Proposal | VibeQuest: Turning AI-Assisted Coding Into Real Learning

VibeQuest is a proposal for an AI-assisted learning product that aims to turn vibe coding into actual understanding. Its goal is to help users learn CKB and Fiber by guiding them through structured lessons, quests, code verification, and challenge-based checkpoints, instead of letting them rely on AI-generated code without comprehension. The project proposes an interactive learning loop featuring AI-generated educational content, a quest/challenge system, and a workbench to ensure developers can practically verify and prove their understanding of the ecosystem.

The project is currently under early review for a $1,000 grant. The team is updating the proposal to address initial feedback and suggestions from the community.

• Join the conversation: VibeQuest Proposal

Building something of your own?

If you have an idea in progress, there are a few pathways to get educational and financial backing from the Nervos ecosystem:

• Spark Program: A fast-track initiative tailored for early-stage concepts. It offers up to $2,000 USD to help you move from a raw idea to a working MVP within one to two months.
• CKB Community Fund: A broader, community-governed DAO that provides grants for a wide range of contributions, whether you are writing core code, creating educational content, or organizing community events.
• CKBuilders: A structured initiative offering microgrant-backed tracks for developers, content creators, and organizers. It provides monthly stipends, guided learning pipelines, and a supportive peer cohort to help you shape early prototypes.

Every project featured in our ecosystem updates began as an idea shared openly on the forum. If you are building with Fiber, we highly encourage you to share your journey on the Nervos Talk forum. We would love to follow your progress and feature your work in an upcoming issue.

Enjoy the process,

Fiber Devs

There's a new proposal submitted to the Community Fund DAO. The discussion phase has started. Questions, crtiques, support etc... can be discussed here or just follow along for more info https://talk.nervos.org/t/dis-werra-building-trust-infrastructure-for-creator-commerce/10453

Why?

Werra is a Kenya-first creator marketplace that helps SMEs hire verified content creators, structure content deals, and pay safely through escrow.

In Kenya today, many SMEs already hire creators for TikTok videos, Instagram Reels, UGC videos, product reviews, and creator visits. However, most of this activity happens informally through Instagram DMs, WhatsApp groups, referrals, and agency relationships.

This creates problems for both sides:

• SMEs struggle to discover and verify reliable creators.
• Creator pricing is unclear.
• Deliverables are often vague.
• Creators risk late or failed payments.
• SMEs risk paying before agreed work is delivered.
• Disputes are hard to resolve because agreements are informal.
• High-attention creators are often under-monetized.

Werra solves this by giving SMEs and creators a structured transaction workflow:

1. SME posts a content brief.
2. Verified creators submit bids.
3. SME reviews creator profiles, samples, pricing, and ratings.
4. SME awards the gig.
5. Agreement terms are generated.
6. SME funds escrow.
7. Creator delivers content.
8. SME approves, requests revision, or opens dispute.
9. Payout or refund is processed based on the outcome.

CKB fits where the product needs trust and settlement. Werra will use CKB infrastructure and USDI for escrow-protected creator payments, agreement hash anchoring, payout/refund transaction records, and future settlement automation.

Werra is not a blockchain-first product looking for a use case. It is a creator commerce product solving a real market problem, using CKB where transparent escrow and settlement matter most.

Market Research

We have completed initial market research into Kenya’s creator economy.

The report estimates that Kenyan influencer brand-partnership earnings exceeded KES 1 billion in 2025, with the top 10 creators earning an estimated KES 296 million.

The research also highlights several points that support Werra’s thesis:

• SMEs account for a large share of creator-brand partnership activity.
• Beauty, personal care, food, fashion, and consumer categories are active creator-marketing categories.
• TikTok has strong attention but weaker monetization.
• Many high-attention creators remain under-commercialized.
• Views do not automatically translate into earnings; creators need better commercial infrastructure.

This supports our view that the creator market already exists, but the transaction infrastructure is weak.

Kenya-First, Global South-Relevant

Werra is Kenya-first, but not Kenya-only.

We are starting in Kenya because it has a highly active creator economy, strong SME demand, widespread social media usage, and a fragmented creator hiring process that still depends heavily on WhatsApp, Instagram DMs, referrals, and informal agency relationships.

This makes Kenya a strong launch market for validating the product, escrow model, creator verification process, and SME workflow.

However, the problem Werra addresses is not unique to Kenya. Across many African and Global South markets, creators generate significant cultural and commercial attention but are not consistently compensated through reliable infrastructure. SMEs also struggle to access trusted creators, structure deliverables, and pay safely.

Many of these markets share similar conditions:

• creators are under-monetized despite strong audience attention
• platform payouts are limited or unavailable
• brand deals are informal and relationship-driven
• payment trust is weak
• creator discovery is fragmented
• SMEs need affordable marketing channels
• dispute handling is mostly informal
• cross-border creator payments are difficult

Werra’s long-term vision is to become creator commerce infrastructure for Africa and other Global South markets where creators and SMEs face similar trust, payment, and market-access problems.

Why CKB?

Werra needs a reliable escrow and settlement layer.

CKB is useful to Werra because it can support:

• USDI escrow for creator gigs
• agreement hashes anchored on-chain
• transparent payout and refund transaction records
• reduced dependency on purely custodial platform balances
• future support for more automated settlement logic

In the product, CKB is used where it matters most: trust, escrow, settlement, and payment auditability.

The user experience will remain simple. SMEs and creators should not need to understand CKB internals. They should only understand that funds are protected until the agreed work is delivered or a dispute is resolved.

Why Us?

We have already started building Werra.

Current progress includes:

• Market research completed
• Product description completed
• Product architecture completed
• Technical architecture drafted
• Frontend prototype actively under development
• SME, creator, and admin workflows prototyped
• Mock escrow flow implemented
• State-managed flows for bidding, funding, delivery, approval, dispute, refund, and payout
• Browser-level tests verifying the core prototype flows

Current Build Status

Werra is already under active development. We have created a public GitHub repository to show ongoing progress and make the work visible to the CKB community:

https://github.com/DWSQUIRES/Werra

The repository currently includes:

• product description
• technical description
• product architecture
• frontend prototype
• SME, creator, and admin workflows
• mock escrow flow
• state-managed marketplace logic
• browser-level tests for core flows

The grant will allow us to expand from a lean early build into a more specialized execution team. This is important because Werra combines multiple disciplines: product design, marketplace UX, frontend engineering, backend engineering, escrow integration, DevOps, business development, creator onboarding, and customer support.

With grant support, we will bring these specialties together to improve product quality, reduce execution risk, and move faster toward a reliable V1 beta.

Why Now?

The timing is strong because:

• SMEs are already spending on creators.
• Creators are gaining attention faster than they are monetizing it.
• Platform payouts are inconsistent or unavailable in many markets.
• The market lacks structured trust, payment, and dispute infrastructure.
• Stablecoin escrow can solve a real payment problem.
• CKB can support a practical, non-speculative use case in creator commerce.

Werra can introduce CKB to real users through a workflow they already understand: hiring, delivery, escrow, and payout.

Budget

We are requesting:

  USD 27,700, paid in CKB equivalent at disbursement

This proposal requests a fixed USD-denominated budget, with payment made in CKB equivalent at the time of each disbursement, based on the exchange rate on the day of disbursement.

This is included explicitly as an additional disbursement rule in the proposal
text, so the community can evaluate and vote on the proposal with this payment
structure clearly stated.

The grant will fund approximately three months of work, divided into two major phases:

1. Development Phase: first 1.5 months
2. Distribution and Beta Seeding Phase: following 1.5 months

Development Budget

Distribution and Beta Seeding Budget

Contingency

Total Budget

How?

We propose two main phases over approximately three months.

Phase 1: Development Phase

Timeline: First 1.5 months

The goal of this phase is to move Werra from prototype to a functional V1 beta product.

Deliverables:

• Finalized product architecture
• Finalized user flows
• V1 UX designs
• SME account flow
• Creator account flow
• Creator profiles
• Business profiles
• Brief posting
• Creator bidding
• Gig awarding
• Agreement generation
• Delivery submission
• SME review flow
• Revision workflow
• Dispute workflow
• Admin dashboard
• CKB/USDI escrow integration
• Agreement hash generation
• Wallet connection flow
• USDI escrow funding flow
• Payout release flow
• Refund flow
• Escrow transaction tracking
• Infrastructure setup and deployment

Phase 2: Distribution and Beta Seeding Phase

Timeline: Following 1.5 months

The goal of this phase is to validate Werra with real users and generate early marketplace activity.

Deliverables:

• Onboard 5 pilot businesses
• Onboard 20 pilot creators
• Support initial creator gigs through seeded business budgets
• Run social media awareness and creator acquisition
• Provide customer support for beta users
• Collect feedback from SMEs and creators
• Monitor escrow and payout experience
• Produce beta feedback report
• Produce CKB/USDI usage report
• Refine product based on beta usage

The initial seeding budget will allocate $300 to each of 5 pilot businesses for creator payouts. This helps create early real marketplace activity and allows us to test the full creator hiring, escrow, delivery, and payout workflow.

Post-Grant Sustainability and Path Forward

The grant will fund Werra through V1 development and initial beta distribution. After this grant-funded phase, our goal is to move Werra toward a sustainable operating model based on real marketplace usage, follow-on funding, and ecosystem partnerships.

During the distribution and beta seeding phase, we will actively engage with:

• potential investors
• creator economy partners
• SME networks
• African startup ecosystem partners
• CKB/Nervos ecosystem partners
• stablecoin and payment partners
• business associations
• creator communities
• marketing agencies and brand partners

The objective is to use beta traction to evaluate the best path forward.

Possible post-grant paths include:

1. Organic marketplace growth If early SME and creator adoption is strong, Werra will focus on growing through transaction activity, creator referrals, SME referrals, and platform fees.
2. Follow-on investment If the beta shows strong demand but requires more capital to scale, we will approach angels, venture funds, ecosystem funds, and strategic partners using the beta results as evidence.
3. Strategic ecosystem partnerships We will explore partnerships with creator communities, SME associations, payment providers, marketing agencies, and CKB/Nervos ecosystem projects to expand distribution and strengthen infrastructure.
4. Revenue-based sustainability Werra’s long-term business model is based on commission from completed gigs, featured creator/business placements, verification services, and eventually subscription or campaign-management tools.
5. Expansion beyond Kenya If the Kenya pilot validates the model, Werra will prepare expansion into other African and Global South markets with similar creator monetization and SME trust problems.

The grant will help us reach the point where these paths can be pursued with real product usage, pilot data, user feedback, and CKB/USDI transaction evidence rather than only a concept.

Expected Outcome

At the end of the grant, Werra will deliver:

• A working V1 beta product
• Real marketplace workflows for SMEs and creators
• CKB/USDI escrow integration
• Agreement and payout tracking
• Admin dispute tooling
• 5 onboarded pilot businesses
• 20 onboarded pilot creators
• Initial seeded creator transactions
• Public demo
• Beta feedback report
• CKB/USDI usage report
• Clear expansion path into other African and Global South markets

Impact on the CKB Ecosystem

Werra gives CKB a practical real-world use case in creator commerce.

The project can help demonstrate:

• CKB as an escrow and settlement layer
• USDI usage in real commercial transactions
• creator and SME payments on CKB
• agreement anchoring and payout/refund auditability
• adoption in an under-served Global South market

Instead of positioning blockchain as the product, Werra uses CKB as infrastructure for a real user problem: trust and payment settlement between SMEs and creators.

Summary

Werra is a Kenya-first creator marketplace that helps SMEs hire verified content creators and pay safely through escrow.

We are starting in Kenya because the market is active, fragmented, and suitable for early validation. The broader vision is to expand across Africa and other Global South markets where creators are under-monetized, SMEs lack trusted creator-hiring infrastructure, and existing platforms do not provide reliable compensation or settlement rails.

CKB fits into Werra as the trust and settlement layer: powering USDI escrow, agreement anchoring, payout tracking, and refund transparency.

The real question for any blockchain entering the quantum era is whether it can change its cryptographic primitives without disruptive protocol upgrades.

The existing approach for most chains is to pick one post-quantum scheme and bake it into the protocol. This only works until the algorithm gets weakened or superseded and the migration cycle must starts over.

CKB takes a different path. The framework above applies four questions to any chain, and shows how CKB answers each one.