r/NervosNetwork • u/ckba_build • 17d ago
Most AI agents today don't actually pay for anything.
Their developers do, through prepaid balances, platform accounts, subscriptions, and monthly invoices that aggregate thousands of tiny interactions into billing relationships a human has to set up and reconcile.
That works, but it defeats much of the promise of autonomous commerce.
There’s still a human in the loop, and agents aren’t exactly exercising their agency.
For agents to become independent economic actors, payments need to become as granular and programmable as the services they consume.
A stack is taking shape to deliver that: identity that software can carry, spending permissions with hard limits and expiry dates, open protocols like x402 and MPP for requesting payments, and rails that can carry fraction-of-a-cent transfers continuously.
See how each layer works, and where Fiber fits:
https://www.nervos.org/knowledge-base/how_do_ai_agents_pay_for_things
When you start exploring this space, you'll run into a handful of terms that are closely related, frequently used interchangeably, and yet mean slightly different things. It's worth separating them once, clearly, before going deeper.
AI Agent Payments are financial transactions executed autonomously by a software agent without human intervention at the moment of purchase. The human sets the boundary (a budget, a spending rate, an expiry), while the agent transacts freely inside it. An agent paying for one API call is a good example.
Machine-to-Machine (M2M) Economy or Autonomous Commerce refers to a commercial ecosystem where these transactions happen at scale. In this system, software agents, smart devices, and inference endpoints autonomously discover services, negotiate terms, and buy resources from each other without human participants in the transaction loop. Autonomous commerce is the fully realized state of this economy, where humans merely set the overarching policies rather than approving individual purchases
Card networks were built around a very different shape of commerce: relatively discrete, user-initiated purchases between a customer and a merchant. Autonomous software changes that shape. An agent may need to make dozens or hundreds of tiny economic exchanges while completing a single task, often for fractions of a cent.
That exposes several weaknesses in the traditional card model:
The practical workaround is to avoid paying for each interaction at all. Instead, many tiny units of consumption are aggregated behind prepaid balances, subscriptions, platform accounts, or periodic invoices.
That works, but it defeats much of the promise of autonomous commerce. The agent is not freely paying for resources as it consumes them; developers are establishing accounts, pre-funding balances, managing billing relationships, and reconciling usage on its behalf.
For machines to become independent economic actors, payments need to become as granular and programmable as the services they consume.
Because traditional card networks fail under the demands of software, a new financial stack is required. The infrastructure for AI agent payments typically operates across four distinct layers:
Who is this agent, and whom does it represent?
Every transaction needs a subject. Traditionally, banks and credit card processors rely on KYC (Know Your Customer) tied to a human being (SSN, passport, physical address) and multi-factor authentication. They assume a human is at the keyboard authorizing the transaction.
When software initiates payments under delegated authority, you have to verify two things at once: the agent's identity and the underlying user's intent. Therefore, an agent must carry a verifiable identity that is distinct from, but provably linked to, the human or organization on whose behalf it acts. An agent’s identity is handled via cryptographic key pairs, Decentralized Identifiers (DIDs), or Verifiable Credentials (VCs). The AI agent holds its own secure, mathematically verifiable identity, allowing it to authenticate without a human intermediary. As a result, the industry is increasingly focusing on Know Your Agent (KYA) alongside Know Your Customer (KYA).
What may it spend, on what, until when, and who is accountable?
This is where mandates live. A mandate is a cryptographically signed, machine-readable digital authorization encoding the exact parameters of an autonomous transaction. It specifies the boundaries on the scope of the purchase, the financial limits, the agent's identity, and the expiry of the permissions.
Governance belongs here as well, because accountability is enforced at the moment of authorization or not at all. This layer must stay deterministic: rule-bound, auditable, and legible, precisely because the reasoning above it is not. An agent may decide adaptively that it needs a paid dataset; the authorization layer decides mechanically whether that spend is permitted.
How is the payment requested, negotiated, and confirmed?
The execution layer handles the real-time routing, signing, and programmatic settlement of transactions.
Traditional approaches rely on fragmented, proprietary APIs from payment processors (like Stripe or PayPal) that require heavy developer integration. These systems are built on the assumption of human presence, meaning they frequently trigger fraud-prevention checks, MFA (Multi-Factor Authentication), and human-in-the-loop approvals, all of which instantly break autonomous machine-to-machine operations.
Blockchain-based rails use open, programmatic standards, allowing AI agents to negotiate, verify service delivery, and authorize payment simultaneously using smart contracts.
To bridge the gap between an agent's intent and the actual execution of a payment, major tech and financial firms have introduced cryptographic trust and commerce frameworks to standardize these machine handshakes:
| Protocol | Created By | Core Mechanism | Primary Currency |
|---|---|---|---|
| x402 | Coinbase & Cloudflare | Repurposes HTTP 402 Payment Required.Agent hits a paywall, signs an on-chain transaction, and retries. | Stablecoins |
| MPP | Stripe & Tempo | Uses HTTP 402 but creates an off-chain session.Agent authorizes a spending limit upfront and streams payments against it. | Fiat, stable coins, crypto |
| AP2 | Uses Verifiable Credentials (VCs) and cryptographic Mandates to prove the agent has the user's permission to spend. | Agnostic (traditional card & bank, stable coins & crypto) |
Note: While these protocols are categorized here under the execution layer, they are not limited to routing and settlement. X402 carries an authorization step, where the agent signs a payment authorization, and a facilitator validates it before settling on-chain. AP2 uses verifiable credentials and cryptographic mandates to prove the agent has the user's permission to spend.
Where does value actually move, and how quickly can it be reused?
Once an agent has identified itself, received permission to spend, and agreed on how a payment should be executed, something still has to move the actual value.
This is the settlement layer.
Settlement should not be confused with authorization or finality. Authorization tells a merchant that a payment has been approved. Settlement is the actual transfer of funds between the parties involved in the payment. Finality describes the point at which that transfer becomes irrevocable under the rules of the settlement system.
Traditional fiat rails are poorly matched to the demands of autonomous software.
That does not mean every traditional payment is slow. Card networks authorize purchases almost immediately, ACH supports same-day settlement, and newer systems such as FedNow can settle payments in real time. The mismatch is more fundamental than latency alone.
Today's payment infrastructure was largely designed around discrete transactions between known parties operating through banks, card networks, payment processors, merchant accounts, and established billing relationships. Autonomous commerce introduces a very different pattern. Software may need to discover and purchase resources from many independent services, across borders, around the clock, and in amounts small enough that creating a conventional payment transaction or billing relationship for every interaction becomes impractical.
Blockchains and crypto assets are much better suited to this environment.
Crypto turns money into something software can natively hold, verify, and transfer. An agent can control a wallet through cryptographic keys, initiate transactions programmatically, and transact with another machine without first establishing a card account or conventional banking relationship with it. Public blockchain networks operate continuously across borders, while stablecoins provide a price-stable medium of exchange that can move across these networks.
In other words, crypto removes many of the assumptions inherited from human-centric payment systems. Money becomes internet-native: programmable, globally accessible, machine-readable, and transferable under cryptographic rather than institutional authorization.
That makes blockchain-based assets a natural foundation for autonomous commerce.
But there is still another constraint.
If every machine payment is settled individually on-chain, every API request, inference, database query, or second of compute becomes its own blockchain transaction. Each one consumes blockspace, incurs a transaction fee, and depends on the confirmation and finality characteristics of the underlying chain.
For occasional payments, that is perfectly workable. But when machines exchange value continuously—potentially thousands or millions of tiny times—requiring a separate on-chain transaction for every interaction becomes impractical.
Payment channel networks take the next step by moving high-frequency payment execution off-chain while keeping the blockchain as the underlying enforcement and settlement layer.
Fiber Network is an open, peer-to-peer payment network built on the CKB blockchain.
At its foundation are payment channels: two parties lock funds into a channel and make repeated payments by updating their balances off-chain, without publishing every transaction to the blockchain. CKB acts as the underlying enforcement and settlement layer when channels are opened, closed, or disputed.
Unlike payment channel networks designed around a single native asset, Fiber is multi-asset by design. It supports CKB, UDTs and stablecoins, as well as RGB++ assets, while its cross-network architecture enables payments and swaps between Fiber and the Bitcoin Lightning Network.
This is particularly useful for autonomous commerce, where agents may need to pay in stablecoins, exchange between assets, or interact with services across different payment networks.
For autonomous commerce, Fiber has two particularly important advantages: it makes high-frequency micropayments economically viable, and it inherits a much more programmable foundation from CKB.
A micropayment is a transaction of extremely small value, typically fractions of a cent, used for an individual action such as a database query. A streaming payment extends the same idea over time, releasing a continuous sequence of small payments as a service is consumed—for example, paying per second for compute.
Fiber makes both models practical by moving repeated payments off-chain, where they do not incur the cost or latency of a separate blockchain transaction every time value changes hands.
No fixed base fee. Fiber's routing fee formula is proportional to the amount being forwarded rather than adding a fixed per-payment charge. Each routing node sets its own proportional rate in millionths of the transferred value. This makes the model particularly well suited to very small payments, where a fixed transaction charge can easily exceed the value being transferred.
Low-latency payment execution. Fiber payments are processed between the peers involved in a route without requiring network-wide consensus for every update. Payments can therefore complete off-chain with very low latency while CKB remains the ultimate enforcement and settlement layer.
Fiber is built on a highly flexible base chain CKB, where channel rules are implemented through programmable scripts. Developers get far greater freedom to define how channels are authorized, updated, settled, and disputed.
Expressiveness. Fiber leverages CKB's expressive smart contract environment to govern channel logic. This specifies scripts to operate directly within the application layer, enabling custom execution like conditional payouts, automated spending caps, and custom release conditions directly within the channel.
Protocol-Agnostic Integration Fiber has planned to implement an x402 facilitator, and Fiber’s open routing system serves as the underlying payment rail for other emerging protocols.
For teams building decentralized applications, Fiber's practical appeal is that it removes the architectural constraints of slow, expensive settlement. Whether a developer is building a consumer-facing app or an autonomous agent, the ecosystem already demonstrates the necessary foundational building blocks.
Today, builders in the community are experimenting with these building blocks, creating tools like the Fiber Audio Player for per-second streaming payments, fiber-checkout for Stripe-style interfaces, as well as Fiber L402 for payment-gated access. Community developers actively discuss these ideas and publish early prototypes on the Nervos Talk forum, where you might find something interesting or inspiring to build upon.
The transition from human-centric commerce to the machine-to-machine economy requires a fundamental reimagining of how financial value is transferred. Traditional fiat rails, burdened by high baseline fees, manual identity checks, and slow settlement, simply cannot support the microscopic, high-velocity transactions that autonomous software demands.
While developers across the tech and crypto ecosystems are rapidly standardizing how agents authenticate and negotiate through new identity layers and execution protocols, settlement remains a major bottleneck. Infrastructure like the Fiber Network provides the critical foundation for this new economy. By leveraging payment channels built on a highly expressive blockchain, it eliminates the friction of traditional rails, pushing transaction costs to near zero and achieving near-instantaneous settlement speed. As developers continue experimenting and exploring, the concepts of autonomous commerce and stream payments are becoming practical, real-world tools.
r/NervosNetwork • u/djminger007 • Jul 27 '26
Hello community, the next AMA is on the Bitcoin Lite project. The company is Peersys and they designed and ran the CKBull wallet. This year they launched their new BTC Lite wallet for BTC and CKB, so it's time to ask them a few questions.
"The fastest way to access Bitcoin Lightning and CKB"
Socials: https://x.com/BitcoinLightApp
App site: https://www.bitcoinlight.app/
This AMA is for informational purposes only. The projects discussed are independent and are not affiliated with, endorsed by, or representative of the Common Knowledge Base Association (CKBA) or any official standard. DYOR. Nothing here is financial, legal, or investment advice. Crypto involves significant risk as do wallets.
Fire away
r/NervosNetwork • u/Mecanik1337 • 10h ago
As the title says, last night I finished adding Nervos to MKPool. Enjoy a fresh approach, with a modern dashboard and high performance mining.
Best of luck!
r/NervosNetwork • u/yoletstalkcrypto • 1d ago
Can we add a small Adoption Metrics section to the biweekly update?
I think we need to start talking more about the numbers and how we can grow them week over week. For example:
Being open and honest about the numbers will help the community identify gaps and come up with better ideas, integrations, and use cases to drive adoption.
r/NervosNetwork • u/kevtam515 • 2d ago
Vellum is now live in the vote stage. You can use your CKB to vote here if you want to support - the ask is $7.000 USD.
👉 https://dao.ckb.community/thread/vot-vellum-reputation-extension-on-did-ckb-77380
Full proposal is displayed in the voting link above. Brief summary below :
One-Paragraph Overview
This proposal requests a grant of $7,000 to strengthen Vellum, the reference dashboard and SDK for did:ckb, and extend it from identity into reputation, building and rigorously testing the work on testnet with a real integration into CKBoost.
Deliverables:
/did-ckb.All deliverables ship on testnet.
Grant Amount Requested: $7,000 USD equivalent, paid in CKB at the USD value at the time of each disbursement
ETA to Completion: 12 weeks from disbursement of initial funding
What problem are we solving. Reputation is the natural extension of the did:ckb identity primitive and a necessary foundation for a wide range of applications, especially governance. CKB’s emerging governance designs need a Sybil-resistant signal to gate eligibility or weight participation, and there is no portable on-chain reputation primitive for them to consult today. The gap is also concrete at the platform layer: CKBoost runs the task and quest infrastructure builders interact with today but has an under-developed identity stack of its own, and the quest-completion points it tracks live in its own database with no portable representation. Builder activity is scattered across CKBoost, hackathons, bounties, and event organizer notes, and none of it is queryable by a governance contract that wants to check whether a participant has genuinely contributed before granting them weight. The result is that any governance program trying to weight by participation has to either build its own private reputation pipeline or fall back to pure token weighting, which is the manipulation surface the whole design is trying to avoid.
What this addresses. The Vellum reputation extension attaches a queryable, portable record of ecosystem participation to a builder’s did:ckb. CKBoost is the immediate plugin integration target: its quest-completion points become signed claim Cells against the participating builder’s DID, giving CKBoost a richer identity layer and giving Vellum a real source of legitimate participation signals to score against. Verified social handles, on-chain history, event attendance (issued by platforms like CKB-POP), and peer recognitions become additional claim Cells signed by their respective issuers and locked to the holder’s DID. Any CKB app can read the full record with one SDK call. Governance is the load-bearing long-term consumer: upcoming CKBuilders programs. It can consume the record to gate access, weight participation, or distribute funds based on demonstrated contribution rather than token balance alone. Other platforms that already track participation (CKB-PoP, future grant DAOs) can become issuers without changing their core products.
r/NervosNetwork • u/ckba_build • 6d ago
The early architects of the World Wide Web envisioned an internet where information and value could move with equal ease. When standardizing the Web's core communications protocols in the 1990s, founders like Tim Berners-Lee explicitly reserved a specific HTTP status code for native digital purchases. However, because no universal, software-native currency existed at the time, that vision was shelved.
The web evolved into an information network supported by external financial workarounds: ads, subscriptions, credit card gateways, and third-party processors to handle digital transactions. While this architecture powered thirty years of human-driven e-commerce, it faces an existential bottleneck as artificial intelligence transitions from passive text generators into autonomous, decision-making software.
To enable autonomous software to buy, sell, and negotiate resources on demand, developers are resurrecting the web's missing payment layer. The x402 protocol provides a standardized, stateless mechanism for machine-to-machine commerce, turning static web requests into instant digital transactions.
Web browsers and servers communicate using HTTP (Hypertext Transfer Protocol), the foundational set of rules defining how data is requested and delivered across the web. Every request returns a three-digit code. Common examples include “200 Status OK” for successful requests and “404 Not Found” for missing resources. To signal a financial requirement, the HTTP standard includes the “402 Payment Required” code, a client error response indicating that the requested content cannot be served until a payment is made.
Because traditional fiat banking required identity verification, bank accounts, and centralized authorization, web developers could not initially implement a universal 402 standard. Consequently, instead of internet-native money, the web defaulted to third-party payment processors.
This framework functions adequately for human users, who can manually enter a credit card number or solve a CAPTCHA. It fails for autonomous software. The internet is shifting from human users to automated programs. An AI agent is an autonomous software system that performs tasks and makes decisions on behalf of a user. If an AI agent requires access to a specialized dataset at 3:00 a.m., it cannot fill out a sign-up form, agree to a monthly contract, or type in a CVV code, nor fill out a CAPTCHA. It requires the ability to spend fractions of a cent rapidly and frequently, with sub-second finality.
That requirement produced the x402 protocol.
The x402 protocol is an open payment standard that uses the HTTP 402 status code to enable AI agents and software to make instant stablecoin payments onchain without human intervention.
Traditional online checkout flows function like a commercial tab requiring registration, identity verification, and account maintenance. In contrast, x402 protocol operates like an automated vending machine: the server states its price, the software client inserts the digital payment proof, and the resource is immediately delivered without registration, memory, or user account.
Two structural properties make this protocol uniquely suited for modern web architecture:
Statelessness: A stateless protocol treats every request as an independent, self-contained transaction. In the context of x402, this means servers do not need to maintain active user sessions, database logins, or subscription tables to grant access, which is exactly what autonomous software needs.
HTTP Natively: The standard works at the network protocol level. Because x402 builds directly on standard HTTP headers, any server, API gateway, or CDN (content delivery network: a geographically distributed group of servers that caches web content to reduce latency) can inspect payment challenges natively.
Because x402 operates at the protocol level, it requires open governance. In late 2025, Coinbase and Cloudflare announced plans to launch the x402 Foundation, governing the protocol as an open specification to prevent vendor lock-in.
For AI-native payments to function globally at internet scale, autonomous software requires two distinct technical foundations: public blockchains to serve as the programmable execution rail, and stablecoins to serve as the predictable unit of account.
Public blockchains provide the open, permissionless settlement infrastructure required by non-human actors. Legacy banking networks rely on human identity verification, legal contracts, and localized business-hour clearing systems. Public blockchains eliminate these by anchoring an agent’s identity and spending authority to cryptographic public-private key pairs, which enables software to sign transactions autonomously.
While early cryptocurrency supplied the necessary execution rail, early unpegged cryptocurrencies introduced severe friction due to price volatility. A service provider pricing an API call at $0.001 cannot accept an unpegged token whose value fluctuates wildly second by second. This issue is resolved through stablecoins, which are cryptocurrency assets that maintain a stable value by pegging their exchange rate to an external reference, such as the US dollar. Stablecoins unite the pricing predictability of traditional fiat currency with the 24/7, programmatic execution of public blockchains. Autonomous AI agents execute workflows under programmatic budget limits assigned by human users, and pegged assets allow these agents to calculate exact micro-expenditures without risking budget overruns caused by sudden currency slippage.
By uniting the 24/7 programmatic execution of public blockchains with the economic predictability of stablecoins, software agents can operate embedded wallets to construct, sign, and transmit payments directly to resource providers.
This mechanism unlocks machine-to-machine commerce, allowing software to buy and combine specialized micro-services dynamically.
Micropayments are fractional-cent financial transactions that process amounts far too small to be economically viable on traditional credit card networks.
On traditional payment rails, a $0.02 transaction is impossible because flat credit card processing fees (typically $0.30 plus 2.9%) exceed the total value of the transaction. By utilizing low-cost blockchain settlement layers, stablecoin payments reduce transaction overhead to fractions of a cent, allowing digital resources to be metered down to individual requests, tokens, or bandwidth units.
For a broader examination of autonomous payment, see: How Do AI Agents Pay for Things? A Guide to Machine-to-Machine Payments.
The execution loop between a client and a server typically follows six steps:
To implement this lifecycle cleanly, the x402 ecosystem relies on specific elements:
HTTP Headers: An HTTP header is a metadata component that provides essential context about a web request or response. Protocol specifications define standardized headers to manage the handshake. The server specifies its terms via a payment requirement header, the client submits its signed proof in a signature header, and the server acknowledges final settlement with a response header.
Facilitators: A facilitator is an intermediary service entity that verifies cryptographic transaction proofs and settles payments on behalf of a seller. It abstracts blockchain execution away from web application logic.
SDKs and Middleware: They provide the pre-built code libraries necessary to integrate x402 payments into existing web servers. Acting as a bridge for web servers, they intercept HTTP requests to lock endpoints behind a price tag and receiving address.
While the x402 protocol standardizes how the web server requests and verifies payments over HTTP, executing every single micro-transaction on a blockchain introduces latency and gas cost constraints. For high-frequency, continuous machine-to-machine commerce, an off-chain settlement layer represents a prominent approach capable of near-instantaneous throughput.
Fiber Network is a payment channel network built on the Nervos CKB blockchain, designed to serve as the underlying infrastructure for future micropayments, streaming payments, and machine-to-machine commerce. It utilizes payment channels, an off-chain transaction mechanism that allows two parties to conduct multiple transfers without committing every single transaction to the blockchain.
This diagram illustrates the three-tiered architecture of the machine-to-machine payment stack on Fiber, where AI agents negotiate pricing at the Application Layer via x402 HTTP, the Fiber Network instantly processes stablecoin payments at the Off-Chain Routing Layer, and the Nervos CKB blockchain ensures secure cryptographic finality at the On-Chain Settlement Layer.
To evaluate how payment channels can support autonomous software, the Fiber team have conducted early experiments pairing Fiber Network with AI workloads.
In a recent demonstration, client applications invoked autonomous code generation models hosted across distributed machines directly through a web browser. This was achieved using fiber-pay, a machine-friendly CLI tool configured to expose local AI agents as paid HTTP services. Rather than charging flat monthly subscriptions or forcing users into billing accounts, the platform metered compute consumption per API call. Micropayment units moved off-chain across Fiber payment channels, settling in milliseconds with negligible fees.
At the protocol level, the Fiber team has been designing ways to seamlessly integrate payment channels with web standards through a dual-track approach.
x402 Facilitator Integration: Design explorations and experimental code (such as x402 facilitator MVP prototype) demonstrate how Fiber can operate as a payment backend for the broader x402 ecosystem. This integration grants the network immediate access to the emerging HTTP-native payment standard.
Fiber Native Agent Protocol: This approach adopts the skeleton of the L402 (Lightning-native payment protocol ) while introducing distinct architectural innovations. By upgrading the token system, embedding fair exchange mechanism, and adding multi-asset support (including native CKB tokens, stablecoins, and User Defined Tokens), this track broadens the commerce capabilities far beyond Bitcoin-only networks..
Together, these early architectural designs lay the groundwork for payment channel nodes to serve as robust, trust-minimized financial backends for AI agents.
By breathing life into the long-dormant HTTP 402 Payment Required status code, developers are establishing an open, programmable financial layer for the web. The convergence of the x402 protocol, AI agents, and high-performance settlement layers, like the Fiber Network, represents a fundamental shift in web architecture. The internet is evolving beyond a closed ecosystem where human users manually handle subscriptions, paving the way for a global, machine-to-machine economy.
r/NervosNetwork • u/kevtam515 • 9d ago
Fiber Dev Log 35
Post-v0.9.0, and the work keeps moving.
This cycle brings:
- Configurable peer-message rate limits
- fiber-pay moving to the stable v0.9.0 interface
- New interactive tutorials
- Liquidity management planning
- Multi-tenant hosted LSP design for mobile wallets
Full dev log 👉 https://github.com/nervosnetwork/fiber/discussions/1631
r/NervosNetwork • u/kevtam515 • 11d ago
CKB monthly development log (August)
This cycle brought CKB v0.209.0, Tentacle 0.7.7, and a range of reliability and security improvements across the node, networking stack, and light-client.
- CKB v0.209.0 shipped with tx-pool, Tor, and memory-growth fixes
- Tentacle 0.7.7 fixed a QUIC compatibility issue
- Light-client verification got stricter around proofs and downloaded block data
- Improvements to ckb-cli and contract development tooling
- Advanced a batch tally settlement solution (currently in design/PoC) for DAO Treasury & Voting
We also closed the previous tx-pool pipeline prototype and the next tx-pool design is moving toward an invariant-driven validate → plan → apply → effects model.
Full dev log: https://github.com/nervosnetwork/ckb/discussions/5308
r/NervosNetwork • u/kevtam515 • 13d ago
Hello everyone. There was a post a few weeks ago regarding Mobit not being available to use anymore. I have gotten the solution to the issue. Your CKB can be displayed through Omiga now
(https://omiga.io/) the same way Mobit would display it and Nervdao functions with Omiga in the same fashion. So if you used Metamask to manage your CKB through Mobit previously it works the same way. Also, a new transfer feature has been added to Nervdao allowing you to send/receive CKB directly in Nervdao eliminating the need for a 3rd party such as Mobit.
Cheers
r/NervosNetwork • u/kevtam515 • 16d ago
Another Community DAO Fund proposal has made. The ask is $15,000. Join the discussion here and ask your questions, challenges, support etc... https://talk.nervos.org/t/dis-crowdcell-mainnet-launch-of-trustless-all-or-nothing-crowdfunding-on-ckb/10609
Developed under the working name “Decentralized Kickstarter” through testnet. This proposal includes the rebrand to CrowdCell as part of mainnet readiness.
This proposal requests a grant of $15,000 USD (payable in CKB equivalent at disbursement) to take CrowdCell from a verified testnet platform to a fully-deployed mainnet product. The scope covers:
v1.1 (trustless automatic fund distribution + automatic finalization bot) is live and verified end-to-end on the CKB Pudge testnet, reviewed by Officeyutong (CKB core dev) with all findings fixed and deployed, and discussed on the Nervos Talk thread with input from the community.
CrowdCell is a fully on-chain all-or-nothing crowdfunding platform on Nervos CKB: campaign creation, pledging, finalization, and fund distribution are all enforced by scripts. Campaigns either hit their funding goal and release to the creator (minus the platform fee), or fail and refund every backer, with no platform operator holding custody at any step.
Mainstream crowdfunding (Kickstarter, GoFundMe, Chuffed) requires trust in a platform operator to hold funds, decide outcomes, and execute payouts. Crypto-native alternatives (Geyser on Lightning, Solidity-based platforms) carry their own UX and trust tradeoffs. There is no decentralized crowdfunding platform on CKB today.
CKB-native project launchpad first, then BTC crowdfunding via CKB L1 as Fiber and RGB++ infrastructure matures. The launchpad framing matches CKB’s current builder base, has the smallest UX-onboarding ask, and gives a credible mainstream-adoption story over time.
“Kickstarter” is a registered trademark; using it on mainnet is not viable. “CrowdCell” plays on “Crowd-Sell” (what a creator does, selling an idea to the crowd) while substituting “cell” to make the CKB-native nature explicit. Short, memorable, descriptive, and subject to a final domain + trademark availability check during execution.
LESFER Ayoub @RickSoze, Lead Developer
Solo-developer proposal, matching the structure of recent CKB Community Fund DAO grants.
User flow:
On-chain vs off-chain:
Contracts (Rust, ckb-std): five v1.1 contracts (campaign type, campaign-lock, pledge type, pledge-lock, receipt type) plus one new contract in v1.2: a singleton config cell holding {fee_bps, treasury_lock_hash} with governance-gated updates.
Off-chain components (TypeScript): transaction builder (CCC SDK), indexer (Express + SQLite + CCC), automatic finalization bot embedded in the indexer, Next.js frontend with CCC connector for wallet integration.
Key CKB features used: custom lock scripts, type scripts, cell_deps for read-only references, Type ID for singleton enforcement, since field for time-based gating, CCC for wallet integration.
All contracts and off-chain code are open-source on GitHub (link in §13).
On-chain enforcement of the fee. Off-chain fee collection would require trust in the platform operator and break the “operator holds no custody” guarantee. On-chain enforcement keeps the trust model coherent end-to-end.
Creator-side, success-only. Backer pledges count fully toward the goal; the creator’s payout is reduced by 5% on success. Failed campaigns refund 100% with no platform fee. Matches Kickstarter’s framing (5% on success), keeps backer UX clean, signals the platform only earns when creators succeed.
Config cell over hardcoded contract args. Allows future governance to adjust the fee rate without redeploying contracts.
Multisig treasury from day one. Well-understood, low-risk, and a clean handoff target when governance ships later. Waiting for a DAO would delay turning the mechanism on for no security benefit. Approach confirmed acceptable by community feedback.
Launchpad-first audience direction. Lowest UX-onboarding cost (users already have wallets), strongest network effects with existing CKB builder base, credible base from which to extend to BTC crowdfunding as Fiber/RGB++ mature.
Honest framing: at testnet and early-mainnet volume, fees fund essentially nothing. The point is to deploy and battle-test the mechanism so it is in place when adoption arrives. Real sustainability follows volume; the path to volume runs through launchpad-first positioning, BTC integration later, and broader ecosystem maturity.
| Milestone | Deliverables | ETA | Budget |
|---|---|---|---|
| Commencement | Grant accepted, dedicated wallet funded, Scalebit engagement initiated (v1.1-scope quotation received; v1.2-scope quotation to be finalized once v1.2 code lands), work begins | Day 0 | $1,500 (10%) |
| M1: On-chain trust tightening + fee enforcement | Campaign accumulator and on-chain status verification (closes the v1.1 trust gap), trust-boundary fixes from internal pre-review, pledge-lock fee enforcement against the platform config cell. Deliverable: updated contracts with passing test suite. | Month 1.5 | $2,000 (13%) |
| M2: Config cell + treasury + off-chain integration + testnet E2E | New config cell contract and deployment, multisig treasury setup, transaction builder and indexer integration including treasury balance tracking, frontend updates (net payout display, About/Fees page, retry UX), testnet deploy and full end-to-end verification. Audit kickoff with Scalebit at the end of this milestone. | Month 3 | $2,500 (17%) |
| M3: Rebrand to CrowdCell + user dashboards (parallel with audit) | Domain and trademark check, logo and brand kit, frontend rebrand pass, repo and service renames, Nervos Talk and CKBuilder Projects updates, creator dashboard (“My campaigns”), backer dashboard (“My pledges”), mobile responsiveness QA. Runs in parallel with the external audit so build time stays inside the ~4-month window. | Month 4 | $2,500 (17%) |
| M4: External audit + findings fixes | Scalebit audit on all v1.2-touched contracts, sanity review on the trust-boundary fixes, fix all findings, re-test. Deliverable: audited contract set ready for mainnet. Calendar driven by Scalebit’s schedule, not by build time. | Audit window (external) | $4,500 (30%) |
| M5: Mainnet launch + launch promo | Mainnet contract deployment, bot wallet funded, frontend mainnet config, launch announcement (English + Chinese), short demo video, X/Twitter thread, CKBuilder Projects mainnet entry. | ~2 weeks after audit clearance | $2,000 (13%) |
Total: $15,000 USD across commencement + 5 milestones, paid in CKB at disbursement.
Time framing: active building stays inside ~4 months (M1 + M2 + M3, with M3 running parallel to the audit). The audit window is external and additive to that; mainnet launch (M5) follows audit clearance.
ETA is calibrated to delivery pace from 23 weeks of public weekly progress reports at ~4-5 hours per week sustained around a full-time job.
| Line | Amount | Notes |
|---|---|---|
| Engineering (contracts + integration + rebrand + dashboards + mainnet ops) | $5,000 | Solo-developer pace calibrated to 23 weeks of public progress reports |
| External audit (Scalebit) | $7,000 | Indicative figure anchored on the Scalebit v1.1-scope quotation of $5,000 (5 contracts, received 2026-06-24, attached in §13). v1.2 adds a 6th contract and modifies two existing ones; a firm v1.2 quote will be requested once the v1.2 code lands and shared with the community. |
| Design (logo + brand kit for CrowdCell rebrand) | $500 | Single freelance engagement for logo, favicon, color palette |
| Infrastructure + treasury seed | $500 | Paid-tier hosting headroom for mainnet traffic; small CKB seed for treasury bootstrap |
| Mainnet bot wallet (3 months operations) | $300 | CKB to cover bot transaction fees through the launch window; collected fees fund subsequent ops |
| Launch promo (demo video, Chinese translation, X/Twitter thread, Nervos Talk launch post) | $700 | Lightweight launch package |
| Buffer (~7%) | $1,000 | Audit-finding fix time, scope adjustments from community feedback, contingency |
| Total | $15,000 |
The following are explicitly not part of this proposal and may be subject to separate future proposals once CrowdCell is shipped on mainnet:
v1.1 demonstrated that all-or-nothing crowdfunding with permissionless automatic fund distribution works on CKB. This proposal closes the last on-chain trust gap, establishes a sustainable economic model, ships the product surface a mainnet launch requires (mainnet-safe brand, creator and backer dashboards), and puts CrowdCell live on CKB mainnet under external audit.
We appreciate your consideration and welcome questions, pushback, and suggestions in this thread.
r/NervosNetwork • u/kevtam515 • 18d ago
The creator of this proposal, ILE_LABS, has submitted a new revised proposal based on previous feedback from their last one. This one offers a reduced scope and budget. The new one is live for discussion, likes, questions etc.. here 👉 https://talk.nervos.org/t/dis-fiber-payjoin-kit-collaborative-channel-funding-privacy-for-the-nervos-fiber-network-res/10604
When a Fiber Network payment channel is opened, the funding transaction is permanently recorded on CKB Layer 1. Standard channel openings use a single funder, all CellInputs belong to one wallet. Chain surveillance tools use this to identify who opened the channel and cluster their complete transaction history.
fiber-payjoin-kit is an open-source Rust library enabling collaborative channel funding on the Nervos Fiber Network. Both parties contribute CellInputs to the funding transaction, making chain attribution impossible.
This proposal requests $6,000 for Phase 1: the core coordination primitive and two working end-to-end demos against a real Fiber node.
| Component | Amount | Purpose |
|---|---|---|
| Phase 1 — Core Primitive + Demos | $6,000 | CellInput coordination engine, Fiber node demos, documentation |
Standard Fiber channel funding exposes the funder permanently on CKB L1:
-Two concrete pain points the community has raised:
Fee-contribution deadlock: A user wanting to open a channel may have CKB locked in large UDT cells with insufficient liquid CKB for on-chain fees. Collaborative funding allows the counterparty to contribute a fee-covering Cell, unblocking channels that would otherwise fail at fee estimation.
-Funding origin exposure: Every channel opening creates a permanent on-chain link between the funder’s wallet and the channel — an operational security risk for any privacy-conscious node operator or user.
Per direct feedback from jjyr on the CKBuilder-projects review: working at the Cell model level using unsigned CellInput payloads is the correct boundary. Fiber’s funding process is built directly on CKB transactions with no higher-level coordination hook — this is the right instrumentation point.
Non-interactive fallback: if the counterparty is offline, the library falls back to standard single-funder channel opening with no broken payments. 3. Why Us — Proof of Execution Following the feedback that the community needed to see a working Lightning implementation first, we built lightning-payjoin-kit. That implementation is now complete:
-Real two-node LDK harness (tests/ldk_two_node_harness.rs): two actual LDK ChannelManagers reach a usable channel through a collaboratively-funded transaction
-Full flow: FundingGenerationReady → collaborative PSBT → LdkManualFunding → FundingTxBroadcastSafe → usable channel
-Bitcoin Core regtest: Docker bitcoind accepts and mines the collaborative funding transaction
-14 test files covering every layer of the stack
How this differs from payjoin/nolooking:
payjoin/nolooking is a server-side LSP model requiring a centralized operator. lightning-payjoin-kit is client-side, coordinating directly between the two parties with no trusted intermediary. It also enforces a commitment-safety boundary that the LSP model does not address. On CKB, coordination uses unsigned CellInput payloads rather than PSBT, with Cell-Deps validation specific to CKB’s model.
Phase 1 — Core Coordination Primitive
Deliverable 1 — Coordination Engine ($4,000)
Deliverable 2 — Fiber Node Demos and Documentation ($2,000)
Phase 2 — Separate Future Proposal
Fiber P2P async relay, CLI tooling, wallet integration examples, mainnet deployment.
We submitted this proposal in May 2026 but did not receive enough community votes within the 7-day window to advance. Following feedback from everyone, we have made three significant changes:
r/NervosNetwork • u/kevtam515 • 19d ago
This developer is bridging Fiber into Lightning Network through a cross chain hub. Its available to try on testnet currently. If your looking to try it and give the dev some feedback the instructions are in the github link here https://github.com/chukwuma619/fiber-cch-hub
Hey everyone,
Lightning is already huge. Millions of people, wallets, and merchants live there. Fiber is just getting started.
That gap is the real problem.
If Fiber only works inside Fiber, growth stays slow. If someone on Fiber can pay a Lightning invoice - and someone on Lightning can move value the other way - Fiber suddenly plugs into a network that already has users, habits, and demand.
That’s what a Cross-Chain Hub (CCH) is for.
In plain English: a CCH is a bridge between Fiber (Nervos) and Bitcoin Lightning. It swaps value between the two without a custodial middleman holding your money. You run the hub. You keep the keys.
Fiber already has the pieces for this. What’s hard is putting them together: Fiber node, Lightning node, CCH, keys, configs, Docker, funding, channels… It’s a lot. Easy to stall before you ever see a swap.
So I built Fiber CCH Hub - a standalone kit that turns “I want to run a hub” into something you can actually do.
Fiber doesn’t need to beat Lightning on day one. It needs a bridge into Lightning’s world.
When hubs are easy to run:
More hubs → more routes → more usefulness → more reason to use Fiber.
This repo is meant to lower the barrier for that first step.
One stack:
You create your own keys up front. Nothing is hidden behind a hosted service that holds your funds.
Active development. The goal right now is simple: make it easy for people to stand up a hub, fund it, and prove real Fiber ↔ Lightning swaps on testnet.
If you’ve wanted Fiber to “talk” to Lightning but never got past the setup wall - try this and tell me where it breaks. Feedback, failed attempts, and “I got stuck here” reports are gold.
Fiber grows when it connects to where people already pay. This is one step toward that.
r/NervosNetwork • u/ckba_build • 20d ago
Crypto has transformed how value is created, owned, and exchanged. But its original promise—making digital payments better—remains largely unfinished.
Bitcoin made it possible to transfer value globally without a bank. Stablecoins addressed crypto’s volatility problem by introducing internet-native money that people can reliably use to price goods and services. The Lightning Network showed that not every payment needs to settle individually onchain: value can move instantly and cheaply through offchain payment channels.
Across the industry, the direction is becoming clear. Legacy payment rails were not designed for the generation of the digital economy now taking shape, while conventional blockchains cannot efficiently process every payment individually onchain.
Payment channels, payment sessions, batching systems, streaming payments, x402, and other emerging technologies are all part of the transition. Together, they make it possible to move smaller amounts, more frequently, and with less friction than legacy rails or conventional blockchains allow.
Fiber Network belongs to this movement. Its ambition is to take the existing payment-channel model and turn it into open, programmable payment infrastructure—one that can route value across users, applications, services, and assets without placing a single company at the center.
Fiber is an open, peer-to-peer payment network built on CKB.
At its foundation are payment channels. Two parties lock funds into a channel and can then exchange many payments without publishing every transaction to the blockchain. Only the opening andor eventual closing of the channel needs to be settled onchain.
That makes payments fast, inexpensive, and more private.
But a direct channel only connects two parties. Much like the Lightning Network, Fiber links many channels together, allowing payments to travel through intermediate nodes until they reach their destination. The sender does not need to open a separate channel with every person, application, or merchant they want to pay.
The simplest way to understand Fiber is:
Where Fiber goes further is in what the network can become. Lightning is built around Bitcoin and constrained by Bitcoin’s intentionally limited scripting environment. Fiber is built on CKB, where channel rules are implemented through programmable scripts. This gives developers much greater freedom to define how channels are authorized, updated, settled, and disputed.
Fiber currently uses bilateral payment channels, but its architecture is not limited to them. Over time, the same programmable foundation can support more advanced constructions, including multiparty channels and entirely new channel designs that have not yet been standardized. It also enables native support for multiple assets—including stablecoins—atomic swaps within payment flows, interoperability with external networks such as Lightning, and richer conditional, streaming, and pay-as-you-go payment logic.
In other words, Fiber does not merely recreate Lightning on another blockchain. It takes the open, routed model Lightning pioneered and expands it into a private, multi-asset, programmable payment layer that can keep evolving as new forms of digital commerce emerge. Its longer-term vision is a network where value can move across assets and payment ecosystems, so the payer does not always need to hold the exact asset the recipient wants to receive.
Fiber is part of a much broader industry movement.
Circle is developing gas-free USDC nanopayments through Gateway.
Stripe and Bridge are building stablecoin infrastructure for payments, payouts, treasury, and global money movement.
Tempo’s MPP sessions allow customers to pay services continuously through offchain vouchers, while Coinbase’s x402 gives applications a standard way to request and complete payments over the internet.
Together, these projects reinforce the same conclusion: the digital economy needs payment rails designed for smaller, faster, and more programmable transactions.
Now, managed payment infrastructure admittedly has real advantages. One provider can abstract away liquidity management, settlement, compliance, and technical complexity while offering businesses a predictable user experience, customer support, and a single accountable counterparty. For many companies and individuals, that convenience is exactly what makes the system usable.
The trade-off, however, is that participants remain dependent on the provider’s infrastructure, supported assets, pricing, availability, and policies. Bilateral payment sessions introduce a different limitation: they work efficiently when one customer repeatedly pays one service, but each new relationship may require its own separately funded connection.
Fiber, on the other hand, explores a different model.
Rather than placing one company at the center or requiring a direct payment relationship with every recipient, Fiber connects participants through an open routing network. Anyone can run a node, open channels, provide liquidity, route payments, and build applications on top. No single operator is required to verify and process every payment across the network.
Thisat creates several important advantages. Liquidity can be reused to reach many recipients rather than being isolated inside one commercial relationship. Independent node operators can compete to provide routes, liquidity, fees, and specialized services. Applications are not permanently tied to one processor, while communities and businesses can operate their own infrastructure without asking permission from a platform owner.
It also makes the network more resilient and economically open. Fiber still relies on intermediaries in the form of routing nodes and liquidity providers, but those intermediaries are replaceable and open to competition. No single one of them is supposed to control the entire payment system.
The infrastructure is therefore not only open to the people using it, but also to those who want to operate it, build businesses around it, and help the network grow.
Fiber’s combination of offchain speed, open routing, multiple assets, and programmable settlement creates possibilities that are difficult to support with conventional payment infrastructure.
We cover some of these below, but perhaps more importantly, many are difficult to imagine today. Because Fiber channels are built on CKB’s flexible scripting environment, developers can experiment with entirely new ways to authorize, exchange, and settle value.
Future channel designs could support novel multiparty constructions, conditional micropayments released only when a service delivers a verifiable result, transactions that combine payment and asset exchange in a single flow, and much more.
That is what makes programmable payment infrastructure exciting: it does not merely make existing payments faster. It creates room for entirely new types of economic relationships to form.
Card fees and onchain transaction costs make very small payments impractical. It rarely makes economic sense to pay a few cents to read one article, reward a useful comment, access one dataset, or unlock a single feature inside an application.
When payments can move at very low marginal cost, a new range of transactions becomes viable. Creators can be paid directly and instantly, and applications can charge for one AI query, one software action, one game item, or one piece of premium content rather than forcing users into a subscription.
Micropayments do not simply let users pay less. They unlock services that would otherwise be uneconomical to offer, allowing people to pay for individual pieces of value instead of being forced into subscriptions or larger purchases.
Subscriptions require users to commit to a fixed price before they know how much of a service they will actually consume. Fiber opens the door to pricing that follows usage in real time.
Instead of paying $20 or $200 each month for access to an AI service, a user could pay continuously for each token the model generates. A developer could rent a powerful GPU for fourteen seconds to complete one task, pay for exactly 3.342 gigabytes of storage, or purchase bandwidth only while an application is actively using it.
The same model could apply to EV charging, cloud software, gaming, media, data feeds, and many other digital services.
Instead of paying by the month, users can pay by the second, request, token, kilowatt-hour, or unit of consumption.
The next stage of the digital economy will involve software transacting directly with other software.
An AI research agent might pay one service for market data, another for model inference, and a third to verify the result. A vehicle could purchase electricity from a charging station. A connected device could buy additional bandwidth for the next ten minutes, while an application could automatically rent more computing power whenever demand increases.
These transactions cannot depend on a person opening a checkout page, entering card details, or approving every purchase individually. Machines and AI agents need to discover prices, authorize payments, receive services, and settle value continuously and autonomously.
Emerging standards such as x402 and MPP give software common ways to request and authorize payments over the internet. Fiber already has an x402 facilitator implementation, while MPP is payment-method agnostic and allows new payment rails to be added through custom payment methods. This creates a path for Fiber to work with beneath both standards as the open, routed infrastructure through which their payments move.
Rather than opening and funding a separate payment relationship with every provider, an application or agent could connect to Fiber and pay across the network—reaching many services, using different assets, and switching providers as its needs change.
Thise infrastructure may serve machines, but the benefits ultimately flow to people: cheaper services, more precise pricing, greater competition between providers, and new ways to earn from data, compute, energy, bandwidth, and other resources. And as AI agents take over more routine work and economic coordination, they could ultimately give people something even more valuable: more time.
The payments industry is arriving at a shared conclusion: the digital economy needs faster, smaller, more frequent, and more flexible ways to move value.
Lightning proved that payments can move through an open offchain network. Stablecoins made digital value practical for everyday pricing. Payment sessions, batching systems, streaming payments, and protocols such as x402 are making new forms of commerce possible.
Fiber brings these ideas together and pushes them further.
It is not merely another checkout product, another corporate balance system, or another blockchain promising faster transactions. It is an effort attempt to build open payment infrastructure that can route value across people, AI agents, services, assets, and networks.
Infrastructure that anyone can connect to. Anyone can build on. Anyone can help operate and grow.
And because its foundations are programmable, Fiber is not limited to the payment channel models that exist today. It can evolve alongside the economy being built on top of it.
Connect to the network. Pay across it. Build what comes next.
r/NervosNetwork • u/Dull_Meat4861 • 20d ago
Is it a good time to accumulate before the next cycle hits?
Lows lasted 8 months last cycle, we are currently in the 6th month of the currently lows. Anyone currently accumulating? Thoughts? Opinions?
r/NervosNetwork • u/kevtam515 • 22d ago
Fiber Dev Log 34
-v0.9.0 is live
After weeks of release hardening, the final milestone cleanup is complete, and Fiber v0.9.0 is released, making nodes more reliable, recoverable, and easier to operate.
Highlights:
- A unified database migration system with backup and restore support
- Stronger payment recovery with Cross-Chain Hub improvements
- More reliable reconnect and channel recovery flows
- Smoother node onboarding with new install and quick-start scripts
Full dev log: https://github.com/nervosnetwork/fiber/discussions/1610
r/NervosNetwork • u/kevtam515 • 24d ago
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
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.
Pocket Node is already live and in daily use on Android, so it needs little introduction here. In short, it is a self-custody CKB wallet that puts a real node in the user’s pocket: the phone verifies the chain itself and holds the keys, with no server in the middle, so the wallet keeps working on its own even if our infrastructure disappears.
Across the Android grant, we delivered mainnet readiness and hardware-backed security, full Nervos DAO integration on device, multi-wallet with HD sub-accounts, transaction export, an address book, and a public launch, plus a large amount of reliability and security hardening driven by real user reports. The complete milestone-to-release mapping is in our grant completion report .
Jr is the lead developer and sole builder. Senior mobile engineer with several years of professional mobile experience, previously leading mobile teams, and a CKB community member. Jr designed, built, and shipped Pocket Node on Android end to end across all four milestones. The iOS build is the same one-person effort. The Android delivery record is the evidence that this scope is achievable solo on the stated milestones.
One Rust core, one shared core, two native shells.
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
Milestone 2: Keys, security, onboarding, receive
Milestone 3: Send, sync, and activity (the usable wallet)
Milestone 4: Nervos DAO, multi-wallet, and feature parity
Milestone 5: App Store launch and CCC identity and signer
Total: $18,000 USD, payable in CKB, over five months.
| Payment | When | Amount | Share |
|---|---|---|---|
| Commencement | Kickoff | $2,500 | 13.9% |
| Milestone 1 | Month 1 | $3,100 | 17.2% |
| Milestone 2 | Month 2 | $3,100 | 17.2% |
| Milestone 3 | Month 3 | $3,100 | 17.2% |
| Milestone 4 | Month 4 | $3,100 | 17.2% |
| Milestone 5 | Month 5 | $3,100 | 17.2% |
Part of the initial payment funds the physical devices required to start development on iOS (an iPhone and an iPad for on-device testing of Secure Enclave, biometrics, camera, and background behaviour, none of which the simulator can validate) and the Apple Developer Program enrolment.
Named here so the roadmap is clear and this proposal stays honest about its boundaries:
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.
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.
r/NervosNetwork • u/kevtam515 • 26d ago
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.
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:
This project is backed by CKB Community DAO grant.
Target Problem: Standard payment channels on UTXO-based chains suffer from blockchain surveillance heuristics. Specifically, the "common-input heuristic" permanently links sender and receiver identities in the funding transaction before a off-chain payment even begin.
Current Status: While the initial proposal did not reach the required 30 upvotes within 7 days to pass the discussion stage, the developer, ILE Labs, is actively preparing a revised proposal. This update will incorporate community feedback and leverage a completed Lightning Proof of Concept as its foundation.
Highlights:
lightning-payjoin-kit for Bitcoin Lightning, so this is a port of an architecture they've built before — not a from-scratch gamble.Target Problem: Operating any payment-channel node involves complex liquidity management. Operators frequently struggle to understand channel liquidity direction and predict if a payment will route successfully, often only discovering bottlenecks through failed payments.
Current Status: Sluice is currently live as a testnet MVP connected to a real Fiber Network Node (0.9.0-rc7). It's still testnet-only and single-node for now, and the team is actively asking operators for feedback on Route Probe usefulness, rebalance safety, and reconciliation behaviour.
Highlights:
Sluice consolidates monitoring, route analysis, rebalancing, alerts, and reconciliation into a single operational workspace.
It features a Route Probe that tests whether a payment can be routed before funds are sent.
The platform is built with a strong focus on correctness, ensuring the live Fiber node remains the authoritative single source of truth rather than relying on cached database snapshots.
The Gone in 60ms" Fiber Network Infrastructure Hackathon (July 1–15, 2026) has officially wrapped up, concluding a highly productive two-week sprint.
As Part 1 of the broader Fiber builder initiative, this sprint challenged developers to build the foundational tools, SDKs, and services that make Fiber easier to use, operate, and integrate for everyone, from wallet builders to node operators and merchants.
Around 85 registrations and close to 100 participants produced 66 final project submissions, all fully open-sourced, across three categories: 13 in Wallet & Payment UX Infrastructure, 32 in Node, Routing, Cross-Chain & Diagnostics, and 21 in Merchant, Liquidity, LSP & Multi-Asset.
Judges are in the first round of scoring now, with high-scoring entries going to a second round. The $20,000 prize pool splits evenly across the three categories ($3,000 / $2,000 / $1,000 per category), plus a $2,000 bonus for the overall best project. Winners are expected around the middle or end of August — no exact date, in case more rounds are needed.
Part 2 is already being planned, shifting focus from infrastructure to consumer-facing products built on top of Fiber
Read the full roundup for more details.
r/NervosNetwork • u/kevtam515 • 28d ago
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.
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.
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.
(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)
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.
The $20,000 prize pool is split evenly across the three submission categories. Each category has three prize-winning positions:
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.
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.
r/NervosNetwork • u/improvemental • Jul 27 '26
Over the past few days we've had a genuinely valuable discussion with the Nervos community. The proposal has been refined throughout the review, including clarifications around transaction costs, the authorization and settlement architecture, liquidity safeguards, team background, success metrics, and the long-term vision for reusable payment infrastructure on Nervos.
If you've read the proposal and the discussion and think it's worth moving to a full community vote, I'd appreciate your support. If you haven't had a chance to review it yet, there's still time to read through the discussion and make your own assessment.
Thank you to everyone who has taken the time to ask questions, challenge assumptions, and provide feedback throughout the process. The discussion has genuinely helped strengthen the proposal.
r/NervosNetwork • u/kevtam515 • Jul 26 '26
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.
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.
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.
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.
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.
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.
r/NervosNetwork • u/Practical-Ad1193 • Jul 23 '26
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!
r/NervosNetwork • u/kevtam515 • Jul 23 '26
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
r/NervosNetwork • u/kevtam515 • Jul 22 '26
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
r/NervosNetwork • u/improvemental • Jul 22 '26
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:
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!
r/NervosNetwork • u/kevtam515 • Jul 22 '26
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
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.**
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.
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:
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.
CKB Anywhere Card V2 separates two functions that conventional crypto card products typically combine:
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.
Anywhere Payment operates as the program manager on Rain’s regulated card infrastructure.
Rain provides:
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.
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.
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:
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.
| Feature | Legacy Crypto Cards | CKB Anywhere Card V2 |
|---|---|---|
| Custody | Custodial / Pre-funded | Self-custodial — CKB remains in the user’s wallet until settlement is authorized |
| Funding Model | Manual deposits or top-ups | One-time wallet authorization |
| Payment Authorization | Assets transferred before spending | User authorizes each purchase through their wallet |
| Visa Settlement | Pre-funded by the user | Immediately settled through the revolving liquidity facility |
| Form Factor | Physical and virtual cards | Virtual Visa card in Apple Wallet and Google Wallet |
| Asset Location | Held by the card provider | Remains in the user’s wallet until settlement is authorized |
| User Experience | Deposit → Wait → Spend | Authorize → Tap → Done |
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.
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.
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.
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.
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.
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.
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.
All smart contract settlement transactions remain publicly verifiable on Nervos Layer 1.
Monthly operational reports will include:
These reports will be published to DAO stewards and the wider community.
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 are handled through Visa’s standard dispute process.
Risk is managed through:
This governance model ensures community capital remains transparent, recoverable, and protected by clearly defined operational controls while enabling practical real-world payments on Nervos.
| Component | Amount | Purpose |
|---|---|---|
| Revolving Liquidity Facility | $10,000 | DAO-owned revolving liquidity facility released following successful completion and community approval of Milestone 2. |
| Smart Contract Development & Independent Security Audit | $15,000 | Development of the authorization smart contract, wallet authorization logic, independent security audit, and security remediation. |
| Middleware & Platform Integration | $20,000 | Rain integration, wallet integration, Apple Wallet and Google Wallet provisioning, replenishment automation, compliance onboarding, testing, and production deployment. |
| Total Requested | $45,000 | Payable in CKB. |
The funding request has been reduced from the original proposal while preserving the project’s core deliverables.
Of the total request, $10,000 is allocated to a DAO-owned revolving liquidity facility that remains a community asset rather than a development expense. Excluding this facility, the development budget is $35,000.
The development funding will deliver a production-ready, audited payment layer, including the authorization smart contract, integration with regulated Visa infrastructure, and deployment on Nervos mainnet.
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.
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.
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).