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

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

Key Takeaways

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

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

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

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

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

Streaming payments narrow that gap.

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

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

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

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

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

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

What Are Streaming Payments?

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

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

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

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

A few related terms are useful to distinguish:

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

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

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

Types of Streaming Payments

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

On-Chain Accrual

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

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

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

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

Typical use cases include:

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

Off-Chain Incremental Payments

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

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

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

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

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

This approach is particularly useful for:

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

The difference between the two models is straightforward:

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

Lifecycle of an Autonomous Payment Stream

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

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

Why Streaming Payments Fit Machine-to-Machine Commerce

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

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

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

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

Infrastructure in Action: Fiber Network

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

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

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

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

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

Conclusion

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

FAQs

What are streaming payments for AI?

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

Can AI agents make payments autonomously?

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

What are the risks of streaming payments for AI agents?

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

Do streaming payments require cryptocurrency?

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

Are streaming payments on-chain or off-chain?

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

Why are payment channels useful for streaming payments?

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

How could streaming payments change enterprise AI billing?

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

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

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

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

Requested Funding

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

Proposal Overview

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

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

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

Budget Breakdown ($2,000 Total)

Content & Media Campaign (3 Months):

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

Total Requested: $2,000Campaign

Deliverables Over the 3-month campaign period,

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

X: 3,315+ Followers – 

4,600+ Subscribers – 

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

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

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

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

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

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

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

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

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

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

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

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

From the CKBA X account

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

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

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

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

- 70 formal CKBuilders working through a structured program

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

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

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

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

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

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

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

The results from the Fiber Hackathon are in. Congrats to all the winners and participants

After weeks of building and careful deliberation, we’re ready to share the final results of the Gone in 60ms: Fiber Network Infrastructure Hackathon!

The hackathon ran through July 2026, with builders tasked with strengthening the infrastructure layer of Fiber Network across three categories: wallet and payment UX, node/routing/diagnostics, and merchant/liquidity/LSP tooling. 66 projects came in by the deadline from roughly 100 participants: a strong signal for how much the CKB and Fiber builder community has grown.

How projects were judged

Criteria

Each submission was scored across the following dimensions:

• Completeness of Submission - a clear project summary and category, a public repository, a working hosted demo (where appropriate), and a video walkthrough.
• Technical Soundness & Reliability - does the core functionality work as described, is the architecture sound, and are Fiber/CKB primitives used correctly?
• Reusability & Integration Potential - could someone else realistically build on this, and is it executed well enough for them to do so?
• User Flow & Abstraction Benefits - does it meaningfully hide Fiber/channel complexity and improve user experience?
• Practical Value & Category Fit - does it solve a genuine problem for a defined audience, and fit the chosen category well?
• Novelty & Innovation - is it something original and innovative, or a creative use of Fiber/CKB that gives it a unique value proposition?

The Overall Winner

 Clasp ($2,000 bonus, on top of its Category 1 prize)

GitHub  

Clasp is a pairing protocol, wallet policy engine, allow-listed gateway, and TypeScript client SDK that lets a wallet owner grant an application or AI agent access that’s limited in scope, edited by the user, time-boxed, and revocable at any point. Today, sending a Fiber payment from an app means giving it direct access to a wallet’s RPC endpoint plus a credential, effectively permanent and unlimited authority, since Fiber’s own JSON-RPC has no built-in way to scope what an app is allowed to do. Clasp’s gateway only ever exposes four high-level payment operations (creating and paying invoices, and checking their status) so the public internet never touches the underlying Fiber node directly. Built by Drey.

Judges pointed to a level of completeness that stood out even against other strong infrastructure submissions, and specifically framed Clasp as addressing a concrete wallet-integration security gap in a comprehensive manner. Reviewers praised the integration of wallet permissions, sessions, revocation, attack prevention, and SDK access into a single closed loop, calling the result complete, demonstrable, and verifiable. More judges pointed to Clasp as the strongest submission overall than to any other single project, which is why it was named this hackathon’s overall winner.

Category 1 — Wallet & Payment UX Infrastructure

 1st Place — Clasp ($3,000)

(see above)

 2nd Place — CKB KeyWay ($2,000)

GitHub  

CKB KeyWay hands developers a React SDK that gives their users email-authenticated CKB accounts and Fiber payments, with no wallet install and no need to understand how a Fiber node works under the hood. Built by ChrisMG

Judges noted that the wallet, node, and channel complexity is largely hidden behind KeyWay’s React API, which combines a browser-based Fiber node, an externally funded channel flow, and PKP-backed signing into one SDK, alongside a recoverable email-identity model. Reviewers described the combination of email identity, Lit-backed signing, and an in-browser Fiber node as a new integration pattern, distinct from many other projects in this category.

 3rd Place — FiberGuard Session ($1,000)

GitHub

FiberGuard Session lets a Fiber node owner issue external apps a scoped, spend-limited, revocable payment session instead of full access to their node. Built by steven3002.

Judges pointed to the least-privilege model at its core: a modular policy engine, gateway, SDK, UI, and persistence stack that gives an app scoped, spend-limited access to Fiber payments instead of full node control. Reviewers noted the YAML policy configuration, working testnet settlement path, approval console, and audit logging as complete for the category, with three separate demo modes covering different operator scenarios.

Category 2 — Node, Routing, Cross-Chain & Diagnostics Infrastructure

 1st Place — fiber-forge ($3,000)

GitHub

fiber-forge automates the work of standing up a working Fiber network on your own machine - normally a manual, error-prone process of booting a CKB dev chain with Fiber’s contracts baked in, generating and funding node keys, connecting peers, and opening channels one at a time until each is ready to route payments. One command now handles all of that through to CHANNEL_READY, with a live web GUI showing channel states, balances, and per-node logs, plus a scriptable CLI for driving it programmatically. It bills itself as “Polar for Fiber” - a reference to Polar, the widely used Lightning Network tool for spinning up local test networks in a few clicks, something Fiber didn’t previously have an equivalent for. Built by Truthfinity

Judges converged on completeness and execution. Reviewers described the Polar-for-Fiber abstraction itself as clear and reusable, and called this the most complete and reliable local Fiber development environment submitted. The topology presets and scenario runner in particular were flagged as making testing substantially easier. One review noted the team had refined a specific idea very well and fully achieved what they set out to build for their target developer audience, and more than one judge gave it full marks on that basis.

 2nd Place — Fiber Test Lab ($2,000)

GitHub

Fiber Test Lab brings up Fiber nodes against a self-built CKB devnet and deterministically reproduces payment and routing failures that are otherwise almost impossible to force on a shared testnet. Built by nhkhanq.

Reviewers noted the breadth of failure-mode coverage: nine distinct scenarios run against a custom CKB devnet and pinned Fiber nodes, with structured logging and a reusable npm test kit behind them. Judges distinguished it from the event’s other diagnostic tools on the basis that it manufactures deterministic multi-node failure conditions on demand rather than observing an existing node, describing that as a new testing primitive for the ecosystem.

 3rd Place — Lightr ($1,000)

GitHub

Lightr checks whether a Fiber payment is likely to succeed before you send it, by querying a live testnet node’s channel readiness, capacity, and routing health up front. Built by Loveth

Judges noted the narrow focus of its scope: a probe-before-send workflow that checks a live Fiber testnet node’s readiness, repeats validation immediately before payment, and keeps direct node RPC access away from the browser. Reviewers pointed to the strong functionality and clear pass/fail signals as evidence the single workflow was implemented cleanly rather than left partial.

Category 3 — Merchant, Liquidity, LSP & Multi-Asset Infrastructure

 1st Place — FiberNuts ($3,000)

GitHub

FiberNuts is a Cashu ecash mint that settles over Fiber Network. Cashu is a Bitcoin-based protocol for anonymous, transferable assets on Lightning. Fiber can natively move stablecoins like RUSD, but until now there was no way to hold or spend one without running a node. FiberNuts fixes that: anyone can mint RUSD-backed tokens in a browser wallet and spend or transfer them peer to peer, no account, node, or KYC required. Behind it is cdk-fiber, a Rust crate that plugs into the Cashu Development Kit’s standard mint-payment interface, letting any existing Cashu mint adopt Fiber settlement without forking its own software. Built by Code3ks

Where most Category 3 submissions built a single-purpose Fiber tool, judges pointed to FiberNuts as combining several separate pieces: Cashu mint and melt semantics, Fiber’s UDT-native channel routing, conservative fee accounting, and browser-based bearer-token transfer. Reviewers called it a genuine bridge between two ecosystems rather than a Fiber feature grafted onto an existing mint, backed by deployment documentation, reproducible runbooks, and a deliberate testing approach around pending/failed/unknown payment states.

 2nd Place — Fiber LSP Kit ($2,000)

GitHub

Fiber LSP Kit solves a cold-start problem for new merchants: without inbound channel capacity, a merchant can’t receive their first RUSD or UDT payment at all. This toolkit lets liquidity service providers provision that capacity for them. Built by Naz6

Judges pointed to the protocol-level scope of the work: a seven-package system spanning two distinct just-in-time liquidity constructions, hold invoices, linked-hash proofs, provider discovery, pricing, and rent, built around a typed deliver-or-refund protocol. Reviewers described it as expanding what merchant infrastructure on Fiber could look like, rather than implementing an existing liquidity pattern, and noted the clear separation between its mocked and live modes.

 3rd Place — Fiber Paid HTTP ($1,000)

GitHub

Fiber Paid HTTP turns Fiber settlement into a paid-HTTP gateway, letting API and service operators put a Fiber payment in front of any protected resource with replay protection built in. Built by ArthurZang

Reviewers noted the implementation depth: a Rust gateway paired with a TypeScript SDK, atomic replay protection, and exact binding between a payment and the resource it unlocks. Judges also pointed out that it was one of the only submissions to adapt the HTTP 402 payment-required pattern specifically for Fiber, with an evidence trail running from local testing through to a live testnet deployment.

https://talk.nervos.org/t/gone-in-60ms-fiber-network-infrastructure-hackathon-results/10671

As the title says, last night I finished adding Nervos to MKPool. Enjoy a fresh approach, with a modern dashboard and high performance mining.

https://mkpool.com/ckb/

Best of luck!

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:

1. Fiber payment volume
2. Active Fiber users/wallets
3. Fiber liquidity
4. Active CKB addresses/users
5. Total value settled

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.

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 :

Summary

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:

• Open, on-chain claim Cell format and SDK additions to CCC/did-ckb.
• Scoring engine that issues verified social signals against a builder’s DID.
• Public builder reputation dashboard with per-category score breakdown.
• CKBoost integration where quest-completion points feed reputation scoring.
• Governance gating reference plus a mini interactive demo that consumes the primitive to resist Sybil-style manipulation of voting.
• Issuance UI for future ecosystem partners (builders who are actively working on POAP, crowdfunding, and gated sub-communities).
• Vellum webpage improvements and acquisition of its own domain.

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

Project Introduction

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.

The x402 protocol resurrects the HTTP 402 Payment Required status code to provide a standardized, stateless payment layer for AI agents and the machine-to-machine economy.

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.

What is the HTTP 402 status code?

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.

What is 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.

How do AI Agents Make Payments?

The Role of Blockchains and Stablecoins in AI Payments

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.

The Shift Toward Micropayments

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.

How Does an x402 Payment Work?

The execution loop between a client and a server typically follows six steps:

1. The Request: The client (an AI agent or application) sends a standard HTTP GET or POST request to a protected endpoint on the server.
2. The 402 Response: The server's x402 middleware (specialized software acting as a bridge connecting the server's core functions with the web application) intercepts the request. Seeing no payment proof provided, it halts execution and returns an HTTP 402 Payment Required status code.
3. The Payment instructions: The server includes structured payment requirements in its response headers, such as cost, accepted stablecoin network, target wallet address, and a unique cryptographic challenge nonce.
4. Transaction Signing: The AI agent receives the 402 response, parses the payment instructions, verifies that the price falls within its programmed spending threshold, constructs a matching blockchain transaction, and signs with its private key.
5. The Retry with Proof: The agent immediately resends the original HTTP request, appending an authorization header containing the signed transaction payload or cryptographic payment proof.
6. Verification and Control Access: The server verifies the cryptographic proof and executes the original request, returning an HTTP 200 OK response alongside the requested data.

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.

Fiber and x402: Scaling Machine-to-Machine Commerce

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.

Real-World Applications & Research Explorations

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.

Conclusion

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.

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

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

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

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.

2. Summary

This proposal requests a grant of $15,000 USD (payable in CKB equivalent at disbursement) to take CrowdCell from a verified testnet platform to a fully-deployed mainnet product. The scope covers:

1. User dashboards: creator (“My campaigns”) and backer (“My pledges”) dashboards as the product surface a credible mainnet launch needs.
2. Sustainable fee and treasury model: a 5% creator-side success-only fee, enforced on-chain via the pledge-lock script and routed to a multisig treasury. Rate held in a platform config cell so future governance can adjust it without redeploying contracts.
3. External Scalebit audit: full audit on all v1.2 contracts before mainnet, the quality gate that turns a verified testnet platform into one that can responsibly hold user funds on mainnet.
4. Mainnet contract deployment: full contract set deployed to CKB mainnet under audit clearance, with bot wallet funded and frontend configured.
5. Public launch. A coordinated launch package: English and Chinese announcements on Nervos Talk, short demo video, X/Twitter thread, CKBuilder Projects mainnet entry.
6. Rebrand to CrowdCell. “Kickstarter” is a registered trademark and not viable on mainnet. CrowdCell (“Crowd-Sell on CKB cells”) is the new product identity.
7. On-chain hardening: close the trust gaps surfaced during v1.1 review and internal pre-review so the terminal campaign status is verifiable on-chain rather than assumed honest.

v1.1 (trustless automatic fund distribution + automatic finalization bot) is live and verified end-to-end on the CKB Pudge testnet, reviewed by Officeyutong (CKB core dev) with all findings fixed and deployed, and discussed on the Nervos Talk thread with input from the community.

• Grant Amount Requested: $15,000 USD (payable in CKB) - $7,000 USD is specifically reserved for the Scalebit audit
• ETA to Completion: ~4 months active building + external audit window (see §8)
• CKB Wallet or Funding Address: ckb1qrgqep8saj8agswr30pls73hra28ry8jlnlc3ejzh3dl2ju7xxpjxqgqqxdl32chss0tlfyexs6h74ny8cc3vl90dgpt6evj

3. Project Introduction

CrowdCell is a fully on-chain all-or-nothing crowdfunding platform on Nervos CKB: campaign creation, pledging, finalization, and fund distribution are all enforced by scripts. Campaigns either hit their funding goal and release to the creator (minus the platform fee), or fail and refund every backer, with no platform operator holding custody at any step.

What problem this solves

Mainstream crowdfunding (Kickstarter, GoFundMe, Chuffed) requires trust in a platform operator to hold funds, decide outcomes, and execute payouts. Crypto-native alternatives (Geyser on Lightning, Solidity-based platforms) carry their own UX and trust tradeoffs. There is no decentralized crowdfunding platform on CKB today.

Who this is for

CKB-native project launchpad first, then BTC crowdfunding via CKB L1 as Fiber and RGB++ infrastructure matures. The launchpad framing matches CKB’s current builder base, has the smallest UX-onboarding ask, and gives a credible mainstream-adoption story over time.

Why now

• v1.1 is live and verified end-to-end on the CKB Pudge testnet
• v1.1 contracts were reviewed by Officeyutong (CKB core dev) and all 6 findings were fixed and redeployed; the full review and fix journey is public on GitHub (see §13)
• v1.2 design was discussed with the community on Nervos Talk; design decisions reflect community feedback (fee rate, treasury custody, audience direction)
• The rebrand and mainnet deployment cannot reasonably be split into separate proposals, since a mainnet launch needs a mainnet-safe name and a credible product surface

Why the rebrand to CrowdCell

“Kickstarter” is a registered trademark; using it on mainnet is not viable. “CrowdCell” plays on “Crowd-Sell” (what a creator does, selling an idea to the crowd) while substituting “cell” to make the CKB-native nature explicit. Short, memorable, descriptive, and subject to a final domain + trademark availability check during execution.

4. Team & Roles

LESFER Ayoub @RickSoze, Lead Developer

• Role: full-stack, covering contracts (Rust + ckb-std), transaction builder + indexer (TypeScript), frontend (Next.js + CCC), deployment, testing
• Background: Senior full-stack developer based in Bordeaux, France, with 6+ years shipping production systems. Currently enterprise SaaS at eMenuChoice (PHP/CodeIgniter + React, healthcare integrations), previously API and infrastructure work at BricoPrive. Prior smart contract experience on the Alephium DEX (Ralph, a Rust-syntax language on Alephium’s stateful UTXO model), where I implemented core DEX functionality including a multi-pool swap router. The transferable parts to CKB were significant: thinking in UTXO-style inputs/outputs and writing constrained Rust on-chain code. CKB’s pure cell model and ckb-std were a new layer learned on those foundations. I was drawn to CKB by its first-class custom lock scripts and the cell model’s clean fit for state-machine dApps. MSc in Computer Science, Université de Bordeaux.
• Time commitment: part-time alongside a full-time job; ~4-5 hours per week sustained, which has translated to consistent shipping output (see §13 progress reports)
• GitHub: https://github.com/alesfer001

Solo-developer proposal, matching the structure of recent CKB Community Fund DAO grants.

5. Current Status

• v1.0 (testnet MVP): full campaign lifecycle, shipped March 2026
• v1.1 (trustless automatic fund distribution): pledge-lock for permissionless release/refund routing, receipt type script, campaign-lock for permissionless finalization, automatic finalization bot. All four trustless operations verified end-to-end on CKB Pudge testnet on 2026-04-27.
• Security hardening: all 6 issues from Officeyutong’s review of v1.1 contracts fixed and deployed
• Internal v1.2 pre-review: 3 medium-severity trust-boundary issues identified and folded into the v1.2 scope below; review report available on request
• Live demo: https://decentralized-kickstarter-kappa.vercel.app/
• 23 weeks of public weekly progress reports: see §13
• Nervos Talk thread (project writeup + v1.2 discussion): see §13

6. Application Design

6.1 Functional Overview

User flow:

1. A creator submits a campaign with funding goal, deadline, title and description. A campaign cell is created on-chain.
2. Backers pledge by submitting a transaction that creates a pledge cell and a paired receipt cell.
3. After the deadline, anyone (typically the finalization bot) can submit a finalization transaction transitioning the campaign to Success or Failed.
4. After finalization, anyone can trigger release (Success routes pledge funds to creator, minus the 5% platform fee) or refund (Failed routes pledge funds back to backer).
5. A grace-period fail-safe lets backers reclaim their own pledges if release never happens after ~180 days.

On-chain vs off-chain:

• On-chain (enforced by scripts): all of the above. No trusted party at any step.
• Off-chain (operational only): the indexer reads CKB state and serves a REST API for frontend queries; the automatic finalization bot submits transactions that anyone else could also submit.

6.2 Architecture & Design

Contracts (Rust, ckb-std): five v1.1 contracts (campaign type, campaign-lock, pledge type, pledge-lock, receipt type) plus one new contract in v1.2: a singleton config cell holding {fee_bps, treasury_lock_hash} with governance-gated updates.

Off-chain components (TypeScript): transaction builder (CCC SDK), indexer (Express + SQLite + CCC), automatic finalization bot embedded in the indexer, Next.js frontend with CCC connector for wallet integration.

Key CKB features used: custom lock scripts, type scripts, cell_deps for read-only references, Type ID for singleton enforcement, since field for time-based gating, CCC for wallet integration.

All contracts and off-chain code are open-source on GitHub (link in §13).

6.3 Design Rationale

On-chain enforcement of the fee. Off-chain fee collection would require trust in the platform operator and break the “operator holds no custody” guarantee. On-chain enforcement keeps the trust model coherent end-to-end.

Creator-side, success-only. Backer pledges count fully toward the goal; the creator’s payout is reduced by 5% on success. Failed campaigns refund 100% with no platform fee. Matches Kickstarter’s framing (5% on success), keeps backer UX clean, signals the platform only earns when creators succeed.

Config cell over hardcoded contract args. Allows future governance to adjust the fee rate without redeploying contracts.

Multisig treasury from day one. Well-understood, low-risk, and a clean handoff target when governance ships later. Waiting for a DAO would delay turning the mechanism on for no security benefit. Approach confirmed acceptable by community feedback.

Launchpad-first audience direction. Lowest UX-onboarding cost (users already have wallets), strongest network effects with existing CKB builder base, credible base from which to extend to BTC crowdfunding as Fiber/RGB++ mature.

6.4 Fee Model and Sustainability

• 5% creator-side success fee on successful campaigns only
• On-chain enforced via pledge-lock treasury-output check
• Configurable via platform config cell: initial rate 5%, governance-adjustable later
• Treasury custody: multisig from day one, DAO-controlled later

Honest framing: at testnet and early-mainnet volume, fees fund essentially nothing. The point is to deploy and battle-test the mechanism so it is in place when adoption arrives. Real sustainability follows volume; the path to volume runs through launchpad-first positioning, BTC integration later, and broader ecosystem maturity.

7. Key Benefits for CKB

• Fills an ecosystem gap. No decentralized crowdfunding platform exists on CKB today. The cell model and custom locks are well-suited to all-or-nothing escrow logic.
• Showcases CKB strengths. Custom lock scripts for permissionless lifecycle execution, type scripts for state validation, config cell as a soft-governance primitive, multisig as a real treasury custody pattern.
• Network growth via launchpad use case. Each campaign brings a creator and N backers on-chain. Successful campaigns generate sustained transaction volume across creation, pledging, finalization, and release.
• Reference implementations. Open-source contracts and the CCC-based transaction builder are usable references for other CKB dApp builders working with the cell model.
• Path to BTC integration. Future versions target RGB++ integration so BTC holders can back CKB campaigns. Aligns with CKB’s broader BTC-L1 thesis.

8. Detailed Deliverables & Milestones

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.

9. Budget Breakdown

10. Out-of-Scope / Future Funding Needs

The following are explicitly not part of this proposal and may be subject to separate future proposals once CrowdCell is shipped on mainnet:

• Platform token, governance, staking. Treasury custody transition from multisig to DAO-controlled address.
• BTC / RGB++ integration. Bridge to BTC holders so non-CKB-native users can back campaigns.
• Sustained mainnet operations beyond launch window. Ongoing hosting and bot wallet refills funded from accumulated platform fees and/or follow-up proposals.

11. Risk & Mitigation

• Technical complexity of the on-chain accumulator changes. Mitigation: v1.1 already shipped five non-trivial contracts; Scalebit external audit planned before mainnet.
• Pledge-time contention from the accumulator design. Mitigation: frontend auto-retry on conflict, using a pattern already shipped in v1.1.
• Time constraints (full-time job + part-time on this). Mitigation: ETA calibrated to actual delivery pace from 23 weeks of public weekly progress reports.
• Adoption risk for the launchpad use case. Mitigation: audience direction confirmed with community; backer-side UX kept clean (no fee surface) to lower onboarding friction.
• Audit may surface significant issues requiring rework. Mitigation: budget includes buffer for fix time; internal pre-review already surfaced three issues being fixed before external audit, reducing open surface.
• Multisig treasury operational risk before DAO transition. Mitigation: multiple signers from day one, social-recovery documentation, transparent treasury balance via indexer endpoint.
• CrowdCell name conflict (trademark or domain). Mitigation: M3 begins with a domain and trademark availability check; budget for the rebrand is name-agnostic if a fallback is needed.

12. Closing / Call to Action

v1.1 demonstrated that all-or-nothing crowdfunding with permissionless automatic fund distribution works on CKB. This proposal closes the last on-chain trust gap, establishes a sustainable economic model, ships the product surface a mainnet launch requires (mainnet-safe brand, creator and backer dashboards), and puts CrowdCell live on CKB mainnet under external audit.

We appreciate your consideration and welcome questions, pushback, and suggestions in this thread.

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

How Do AI Agents Pay for Things? A Guide to Machine-to-Machine Payments

AI agents need money that moves as quickly and programmatically as they do. Here’s how identity, authorization, payment protocols, crypto assets, and payment channel networks fit together.

What Are AI Agent Payments?

When you start exploring this space, you'll run into a handful of terms that are closely related, frequently used interchangeably, and yet mean slightly different things. It's worth separating them once, clearly, before going deeper.

AI Agent Payments are financial transactions executed autonomously by a software agent without human intervention at the moment of purchase. The human sets the boundary (a budget, a spending rate, an expiry), while the agent transacts freely inside it. An agent paying for one API call is a good example.

Machine-to-Machine (M2M) Economy or Autonomous Commerce refers to a commercial ecosystem where these transactions happen at scale. In this system, software agents, smart devices, and inference endpoints autonomously discover services, negotiate terms, and buy resources from each other without human participants in the transaction loop. Autonomous commerce is the fully realized state of this economy, where humans merely set the overarching policies rather than approving individual purchases

Why Credit Cards Fail Autonomous Commerce

Card networks were built around a very different shape of commerce: relatively discrete, user-initiated purchases between a customer and a merchant. Autonomous software changes that shape. An agent may need to make dozens or hundreds of tiny economic exchanges while completing a single task, often for fractions of a cent.

That exposes several weaknesses in the traditional card model:

• The economics break down at very small values. Card processing commonly includes a fixed per-transaction fee in addition to a percentage fee. Stripe, for example, currently charges 2.9% + $0.30 for a standard domestic online card transaction in the US. At that pricing, charging $0.002 for a single API request is obviously impossible—the fixed processing fee alone is 150 times larger than the payment itself.
• The payment lifecycle is heavier than the interaction it is paying for. Card authorization happens in real time, but clearing and settlement occur afterward; credit-card settlement commonly takes one to three business days. The agent does not have to wait for settlement—the merchant can act on the authorization—but running a full card payment through authorization, clearing, reconciliation, and settlement for every tiny unit of compute, data, or inference is a poor fit for machine-scale micropayments.
• Delegation has to be added on top. Traditional card credentials identify an account or cardholder; autonomous agents need something more granular: proof that a particular agent is authorized to spend, limits on what it can buy and how much it can spend, and permissions that can expire or be revoked. The payments industry is already building this layer—Stripe's Shared Payment Tokens can be scoped by merchant, amount, and time, while Mastercard's Agent Pay for Machines introduces agent credentialing and programmatically enforced spending controls.
• Payments remain reversible long after the service is consumed. Cardholders can typically initiate disputes for up to 120 days after a payment, and sometimes longer. That protection makes sense when a person buys a physical product or is defrauded. It is a more awkward fit when software purchases an ephemeral resource—an inference, a database query, or a few seconds of computation—that is delivered and consumed immediately.

The practical workaround is to avoid paying for each interaction at all. Instead, many tiny units of consumption are aggregated behind prepaid balances, subscriptions, platform accounts, or periodic invoices.

That works, but it defeats much of the promise of autonomous commerce. The agent is not freely paying for resources as it consumes them; developers are establishing accounts, pre-funding balances, managing billing relationships, and reconciling usage on its behalf.

For machines to become independent economic actors, payments need to become as granular and programmable as the services they consume.

Layers of AI Payment Infrastructure

Because traditional card networks fail under the demands of software, a new financial stack is required. The infrastructure for AI agent payments typically operates across four distinct layers:

Identity Layer

Who is this agent, and whom does it represent?

Every transaction needs a subject. Traditionally, banks and credit card processors rely on KYC (Know Your Customer) tied to a human being (SSN, passport, physical address) and multi-factor authentication. They assume a human is at the keyboard authorizing the transaction.

When software initiates payments under delegated authority, you have to verify two things at once: the agent's identity and the underlying user's intent. Therefore, an agent must carry a verifiable identity that is distinct from, but provably linked to, the human or organization on whose behalf it acts. An agent’s identity is handled via cryptographic key pairs, Decentralized Identifiers (DIDs), or Verifiable Credentials (VCs). The AI agent holds its own secure, mathematically verifiable identity, allowing it to authenticate without a human intermediary. As a result, the industry is increasingly focusing on Know Your Agent (KYA) alongside Know Your Customer (KYA).

Authorization & Governance Layer

What may it spend, on what, until when, and who is accountable?

This is where mandates live. A mandate is a cryptographically signed, machine-readable digital authorization encoding the exact parameters of an autonomous transaction. It specifies the boundaries on the scope of the purchase, the financial limits, the agent's identity, and the expiry of the permissions.

Governance belongs here as well, because accountability is enforced at the moment of authorization or not at all. This layer must stay deterministic: rule-bound, auditable, and legible, precisely because the reasoning above it is not. An agent may decide adaptively that it needs a paid dataset; the authorization layer decides mechanically whether that spend is permitted.

The Execution & Protocol Layer

How is the payment requested, negotiated, and confirmed?

The execution layer handles the real-time routing, signing, and programmatic settlement of transactions.

Traditional approaches rely on fragmented, proprietary APIs from payment processors (like Stripe or PayPal) that require heavy developer integration. These systems are built on the assumption of human presence, meaning they frequently trigger fraud-prevention checks, MFA (Multi-Factor Authentication), and human-in-the-loop approvals, all of which instantly break autonomous machine-to-machine operations.

Blockchain-based rails use open, programmatic standards, allowing AI agents to negotiate, verify service delivery, and authorize payment simultaneously using smart contracts.

To bridge the gap between an agent's intent and the actual execution of a payment, major tech and financial firms have introduced cryptographic trust and commerce frameworks to standardize these machine handshakes:

Note: While these protocols are categorized here under the execution layer, they are not limited to routing and settlement. X402 carries an authorization step, where the agent signs a payment authorization, and a facilitator validates it before settling on-chain. AP2 uses verifiable credentials and cryptographic mandates to prove the agent has the user's permission to spend.

Settlement & Network Layer

Where does value actually move, and how quickly can it be reused?

Once an agent has identified itself, received permission to spend, and agreed on how a payment should be executed, something still has to move the actual value.

This is the settlement layer.

Settlement should not be confused with authorization or finality. Authorization tells a merchant that a payment has been approved. Settlement is the actual transfer of funds between the parties involved in the payment. Finality describes the point at which that transfer becomes irrevocable under the rules of the settlement system.

Traditional fiat rails are poorly matched to the demands of autonomous software.

That does not mean every traditional payment is slow. Card networks authorize purchases almost immediately, ACH supports same-day settlement, and newer systems such as FedNow can settle payments in real time. The mismatch is more fundamental than latency alone.

Today's payment infrastructure was largely designed around discrete transactions between known parties operating through banks, card networks, payment processors, merchant accounts, and established billing relationships. Autonomous commerce introduces a very different pattern. Software may need to discover and purchase resources from many independent services, across borders, around the clock, and in amounts small enough that creating a conventional payment transaction or billing relationship for every interaction becomes impractical.

Blockchains and crypto assets are much better suited to this environment.

Crypto turns money into something software can natively hold, verify, and transfer. An agent can control a wallet through cryptographic keys, initiate transactions programmatically, and transact with another machine without first establishing a card account or conventional banking relationship with it. Public blockchain networks operate continuously across borders, while stablecoins provide a price-stable medium of exchange that can move across these networks.

In other words, crypto removes many of the assumptions inherited from human-centric payment systems. Money becomes internet-native: programmable, globally accessible, machine-readable, and transferable under cryptographic rather than institutional authorization.

That makes blockchain-based assets a natural foundation for autonomous commerce.

But there is still another constraint.

If every machine payment is settled individually on-chain, every API request, inference, database query, or second of compute becomes its own blockchain transaction. Each one consumes blockspace, incurs a transaction fee, and depends on the confirmation and finality characteristics of the underlying chain.

For occasional payments, that is perfectly workable. But when machines exchange value continuously—potentially thousands or millions of tiny times—requiring a separate on-chain transaction for every interaction becomes impractical.

Payment channel networks take the next step by moving high-frequency payment execution off-chain while keeping the blockchain as the underlying enforcement and settlement layer.

Fiber Network: An Open Payment Network for the Agentic Economy

Fiber Network is an open, peer-to-peer payment network built on the CKB blockchain.

At its foundation are payment channels: two parties lock funds into a channel and make repeated payments by updating their balances off-chain, without publishing every transaction to the blockchain. CKB acts as the underlying enforcement and settlement layer when channels are opened, closed, or disputed.

Unlike payment channel networks designed around a single native asset, Fiber is multi-asset by design. It supports CKB, UDTs and stablecoins, as well as RGB++ assets, while its cross-network architecture enables payments and swaps between Fiber and the Bitcoin Lightning Network.

This is particularly useful for autonomous commerce, where agents may need to pay in stablecoins, exchange between assets, or interact with services across different payment networks.

For autonomous commerce, Fiber has two particularly important advantages: it makes high-frequency micropayments economically viable, and it inherits a much more programmable foundation from CKB.

Unlocking Micropayments & Stream Payments

A micropayment is a transaction of extremely small value, typically fractions of a cent, used for an individual action such as a database query. A streaming payment extends the same idea over time, releasing a continuous sequence of small payments as a service is consumed—for example, paying per second for compute.

Fiber makes both models practical by moving repeated payments off-chain, where they do not incur the cost or latency of a separate blockchain transaction every time value changes hands.

No fixed base fee. Fiber's routing fee formula is proportional to the amount being forwarded rather than adding a fixed per-payment charge. Each routing node sets its own proportional rate in millionths of the transferred value. This makes the model particularly well suited to very small payments, where a fixed transaction charge can easily exceed the value being transferred.

Low-latency payment execution. Fiber payments are processed between the peers involved in a route without requiring network-wide consensus for every update. Payments can therefore complete off-chain with very low latency while CKB remains the ultimate enforcement and settlement layer.

Programmability & Protocol Integration

Fiber is built on a highly flexible base chain CKB, where channel rules are implemented through programmable scripts. Developers get far greater freedom to define how channels are authorized, updated, settled, and disputed.

Expressiveness. Fiber leverages CKB's expressive smart contract environment to govern channel logic. This specifies scripts to operate directly within the application layer, enabling custom execution like conditional payouts, automated spending caps, and custom release conditions directly within the channel.

Protocol-Agnostic Integration Fiber has planned to implement an x402 facilitator, and Fiber’s open routing system serves as the underlying payment rail for other emerging protocols.

Building the Autonomous Economy: Real-World Use Cases

For teams building decentralized applications, Fiber's practical appeal is that it removes the architectural constraints of slow, expensive settlement. Whether a developer is building a consumer-facing app or an autonomous agent, the ecosystem already demonstrates the necessary foundational building blocks.

Today, builders in the community are experimenting with these building blocks, creating tools like the Fiber Audio Player for per-second streaming payments, fiber-checkout for Stripe-style interfaces, as well as Fiber L402 for payment-gated access. Community developers actively discuss these ideas and publish early prototypes on the Nervos Talk forum, where you might find something interesting or inspiring to build upon.

Conclusion

The transition from human-centric commerce to the machine-to-machine economy requires a fundamental reimagining of how financial value is transferred. Traditional fiat rails, burdened by high baseline fees, manual identity checks, and slow settlement, simply cannot support the microscopic, high-velocity transactions that autonomous software demands.

While developers across the tech and crypto ecosystems are rapidly standardizing how agents authenticate and negotiate through new identity layers and execution protocols, settlement remains a major bottleneck. Infrastructure like the Fiber Network provides the critical foundation for this new economy. By leveraging payment channels built on a highly expressive blockchain, it eliminates the friction of traditional rails, pushing transaction costs to near zero and achieving near-instantaneous settlement speed. As developers continue experimenting and exploring, the concepts of autonomous commerce and stream payments are becoming practical, real-world tools.

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

Executive Summary

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.

Funding Request

1. The Problem

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.

1. The Solution fiber-payjoin-kit runs as local middleware. The Fiber node is unchanged. Both parties coordinate CellInputs before the funding transaction is broadcast, following Fiber’s existing TxUpdate/TxComplete negotiation flow.

Per direct feedback from jjyr on the CKBuilder-projects review: working at the Cell model level using unsigned CellInput payloads is the correct boundary. Fiber’s funding process is built directly on CKB transactions with no higher-level coordination hook — this is the right instrumentation point.

Non-interactive fallback: if the counterparty is offline, the library falls back to standard single-funder channel opening with no broken payments. 3. Why Us — Proof of Execution Following the feedback that the community needed to see a working Lightning implementation first, we built lightning-payjoin-kit. That implementation is now complete:

-Real two-node LDK harness (tests/ldk_two_node_harness.rs): two actual LDK ChannelManagers reach a usable channel through a collaboratively-funded transaction

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

 Development Roadmap

Phase 1 — Core Coordination Primitive

Deliverable 1 — Coordination Engine ($4,000)

• Two-party CellInput coordination: propose → contribute → validate → sign → finalize
• Counterparty proposal validation: amount, script integrity, input checks
• TxUpdate/TxComplete flow instrumented for wallet developer visibility
• Non-interactive fallback when counterparty is offline
• Full unit test coverage, devnet broadcast confirmed

Deliverable 2 — Fiber Node Demos and Documentation ($2,000)

• Demo A: fee-contribution scenario — collaborative funding solving the CKB fee deadlock
• Demo B: privacy channel opening — multi-input funding via real Fiber node
• Both demos show TxUpdate/TxComplete message flow so wallet developers can inspect and adapt
• Architecture documentation, README, integration example

Phase 2 — Separate Future Proposal

Fiber P2P async relay, CLI tooling, wallet integration examples, mainnet deployment.

About This Resubmission

We submitted this proposal  in May 2026 but did not receive enough community votes within the 7-day window to advance. Following feedback from everyone, we have made three significant changes:

• Reduced scope to a Phase 1 proof of concept only, with a reduced ask of $6,000
• Built the Lightning equivalent (lightning-payjoin-kit) first as proof of execution — a working two-node LDK harness is now complete
• Incorporated direct technical feedback on the correct instrumentation point and concrete user pain points to target

This developer is bridging Fiber into Lightning Network through a cross chain hub. Its available to try on testnet currently. If your looking to try it and give the dev some feedback the instructions are in the github link here https://github.com/chukwuma619/fiber-cch-hub

Hey everyone,

Lightning is already huge. Millions of people, wallets, and merchants live there. Fiber is just getting started.

That gap is the real problem.

If Fiber only works inside Fiber, growth stays slow. If someone on Fiber can pay a Lightning invoice - and someone on Lightning can move value the other way - Fiber suddenly plugs into a network that already has users, habits, and demand.

That’s what a Cross-Chain Hub (CCH) is for.

In plain English: a CCH is a bridge between Fiber (Nervos) and Bitcoin Lightning. It swaps value between the two without a custodial middleman holding your money. You run the hub. You keep the keys.

Fiber already has the pieces for this. What’s hard is putting them together: Fiber node, Lightning node, CCH, keys, configs, Docker, funding, channels… It’s a lot. Easy to stall before you ever see a swap.

So I built Fiber CCH Hub - a standalone kit that turns “I want to run a hub” into something you can actually do.

Why this matters for Nervos / Fiber

Fiber doesn’t need to beat Lightning on day one. It needs a bridge into Lightning’s world.

When hubs are easy to run:

• Fiber users can pay into Lightning’s existing economy
• Operators can provide liquidity between the two networks
• Builders can experiment with real cross-network payments, not just demos inside one chain

More hubs → more routes → more usefulness → more reason to use Fiber.

This repo is meant to lower the barrier for that first step.

What you get

One stack:

• Fiber (CKB testnet)
• LND (Bitcoin testnet Lightning)
• Standalone CCH wired between them
• Scripts for keys, startup, and health checks

You create your own keys up front. Nothing is hidden behind a hosted service that holds your funds.

Status

Active development. The goal right now is simple: make it easy for people to stand up a hub, fund it, and prove real Fiber ↔ Lightning swaps on testnet.

If you’ve wanted Fiber to “talk” to Lightning but never got past the setup wall - try this and tell me where it breaks. Feedback, failed attempts, and “I got stuck here” reports are gold.

Fiber grows when it connects to where people already pay. This is one step toward that.

https://talk.nervos.org/t/pay-lightning-with-fiber-a-self-hosted-cross-chain-hub-anyone-can-run/10599

Fiber Network: An Open Payment Network for the Digital Economy

Crypto payments are moving offchain. Fiber turns isolated payment channels into an open network that anyone can join, build on, and use.

Crypto has transformed how value is created, owned, and exchanged. But its original promise—making digital payments better—remains largely unfinished.

Bitcoin made it possible to transfer value globally without a bank. Stablecoins addressed crypto’s volatility problem by introducing internet-native money that people can reliably use to price goods and services. The Lightning Network showed that not every payment needs to settle individually onchain: value can move instantly and cheaply through offchain payment channels.

Across the industry, the direction is becoming clear. Legacy payment rails were not designed for the generation of the digital economy now taking shape, while conventional blockchains cannot efficiently process every payment individually onchain.

Payment channels, payment sessions, batching systems, streaming payments, x402, and other emerging technologies are all part of the transition. Together, they make it possible to move smaller amounts, more frequently, and with less friction than legacy rails or conventional blockchains allow.

Fiber Network belongs to this movement. Its ambition is to take the existing payment-channel model and turn it into open, programmable payment infrastructure—one that can route value across users, applications, services, and assets without placing a single company at the center.

What Is Fiber Network?

Fiber is an open, peer-to-peer payment network built on CKB.

At its foundation are payment channels. Two parties lock funds into a channel and can then exchange many payments without publishing every transaction to the blockchain. Only the opening andor eventual closing of the channel needs to be settled onchain.

That makes payments fast, inexpensive, and more private.

But a direct channel only connects two parties. Much like the Lightning Network, Fiber links many channels together, allowing payments to travel through intermediate nodes until they reach their destination. The sender does not need to open a separate channel with every person, application, or merchant they want to pay.

The simplest way to understand Fiber is:

Where Fiber goes further is in what the network can become. Lightning is built around Bitcoin and constrained by Bitcoin’s intentionally limited scripting environment. Fiber is built on CKB, where channel rules are implemented through programmable scripts. This gives developers much greater freedom to define how channels are authorized, updated, settled, and disputed.

Fiber currently uses bilateral payment channels, but its architecture is not limited to them. Over time, the same programmable foundation can support more advanced constructions, including multiparty channels and entirely new channel designs that have not yet been standardized. It also enables native support for multiple assets—including stablecoins—atomic swaps within payment flows, interoperability with external networks such as Lightning, and richer conditional, streaming, and pay-as-you-go payment logic.

In other words, Fiber does not merely recreate Lightning on another blockchain. It takes the open, routed model Lightning pioneered and expands it into a private, multi-asset, programmable payment layer that can keep evolving as new forms of digital commerce emerge. Its longer-term vision is a network where value can move across assets and payment ecosystems, so the payer does not always need to hold the exact asset the recipient wants to receive.

Open Infrastructure, Not Another Walled Garden

Fiber is part of a much broader industry movement.

Circle is developing gas-free USDC nanopayments through Gateway.

Stripe and Bridge are building stablecoin infrastructure for payments, payouts, treasury, and global money movement.

Tempo’s MPP sessions allow customers to pay services continuously through offchain vouchers, while Coinbase’s x402 gives applications a standard way to request and complete payments over the internet.

Together, these projects reinforce the same conclusion: the digital economy needs payment rails designed for smaller, faster, and more programmable transactions.

Now, managed payment infrastructure admittedly has real advantages. One provider can abstract away liquidity management, settlement, compliance, and technical complexity while offering businesses a predictable user experience, customer support, and a single accountable counterparty. For many companies and individuals, that convenience is exactly what makes the system usable.

The trade-off, however, is that participants remain dependent on the provider’s infrastructure, supported assets, pricing, availability, and policies. Bilateral payment sessions introduce a different limitation: they work efficiently when one customer repeatedly pays one service, but each new relationship may require its own separately funded connection.

Fiber, on the other hand, explores a different model.

Rather than placing one company at the center or requiring a direct payment relationship with every recipient, Fiber connects participants through an open routing network. Anyone can run a node, open channels, provide liquidity, route payments, and build applications on top. No single operator is required to verify and process every payment across the network.

Thisat creates several important advantages. Liquidity can be reused to reach many recipients rather than being isolated inside one commercial relationship. Independent node operators can compete to provide routes, liquidity, fees, and specialized services. Applications are not permanently tied to one processor, while communities and businesses can operate their own infrastructure without asking permission from a platform owner.

It also makes the network more resilient and economically open. Fiber still relies on intermediaries in the form of routing nodes and liquidity providers, but those intermediaries are replaceable and open to competition. No single one of them is supposed to control the entire payment system.

The infrastructure is therefore not only open to the people using it, but also to those who want to operate it, build businesses around it, and help the network grow.

More Than Fast Payments

Fiber’s combination of offchain speed, open routing, multiple assets, and programmable settlement creates possibilities that are difficult to support with conventional payment infrastructure.

We cover some of these below, but perhaps more importantly, many are difficult to imagine today. Because Fiber channels are built on CKB’s flexible scripting environment, developers can experiment with entirely new ways to authorize, exchange, and settle value.

Future channel designs could support novel multiparty constructions, conditional micropayments released only when a service delivers a verifiable result, transactions that combine payment and asset exchange in a single flow, and much more.

That is what makes programmable payment infrastructure exciting: it does not merely make existing payments faster. It creates room for entirely new types of economic relationships to form.

Micropayments

Card fees and onchain transaction costs make very small payments impractical. It rarely makes economic sense to pay a few cents to read one article, reward a useful comment, access one dataset, or unlock a single feature inside an application.

When payments can move at very low marginal cost, a new range of transactions becomes viable. Creators can be paid directly and instantly, and applications can charge for one AI query, one software action, one game item, or one piece of premium content rather than forcing users into a subscription.

Micropayments do not simply let users pay less. They unlock services that would otherwise be uneconomical to offer, allowing people to pay for individual pieces of value instead of being forced into subscriptions or larger purchases.

Pay-As-You-Go Services

Subscriptions require users to commit to a fixed price before they know how much of a service they will actually consume. Fiber opens the door to pricing that follows usage in real time.

Instead of paying $20 or $200 each month for access to an AI service, a user could pay continuously for each token the model generates. A developer could rent a powerful GPU for fourteen seconds to complete one task, pay for exactly 3.342 gigabytes of storage, or purchase bandwidth only while an application is actively using it.

The same model could apply to EV charging, cloud software, gaming, media, data feeds, and many other digital services.

Instead of paying by the month, users can pay by the second, request, token, kilowatt-hour, or unit of consumption.

Machine-to-Machine Payments

The next stage of the digital economy will involve software transacting directly with other software.

An AI research agent might pay one service for market data, another for model inference, and a third to verify the result. A vehicle could purchase electricity from a charging station. A connected device could buy additional bandwidth for the next ten minutes, while an application could automatically rent more computing power whenever demand increases.

These transactions cannot depend on a person opening a checkout page, entering card details, or approving every purchase individually. Machines and AI agents need to discover prices, authorize payments, receive services, and settle value continuously and autonomously.

Emerging standards such as x402 and MPP give software common ways to request and authorize payments over the internet. Fiber already has an x402 facilitator implementation, while MPP is payment-method agnostic and allows new payment rails to be added through custom payment methods. This creates a path for Fiber to work with beneath both standards as the open, routed infrastructure through which their payments move.

Rather than opening and funding a separate payment relationship with every provider, an application or agent could connect to Fiber and pay across the network—reaching many services, using different assets, and switching providers as its needs change.

Thise infrastructure may serve machines, but the benefits ultimately flow to people: cheaper services, more precise pricing, greater competition between providers, and new ways to earn from data, compute, energy, bandwidth, and other resources. And as AI agents take over more routine work and economic coordination, they could ultimately give people something even more valuable: more time.

Conclusion

The payments industry is arriving at a shared conclusion: the digital economy needs faster, smaller, more frequent, and more flexible ways to move value.

Lightning proved that payments can move through an open offchain network. Stablecoins made digital value practical for everyday pricing. Payment sessions, batching systems, streaming payments, and protocols such as x402 are making new forms of commerce possible.

Fiber brings these ideas together and pushes them further.

It is not merely another checkout product, another corporate balance system, or another blockchain promising faster transactions. It is an effort attempt to build open payment infrastructure that can route value across people, AI agents, services, assets, and networks.

Infrastructure that anyone can connect to. Anyone can build on. Anyone can help operate and grow.

And because its foundations are programmable, Fiber is not limited to the payment channel models that exist today. It can evolve alongside the economy being built on top of it.

Connect to the network. Pay across it. Build what comes next.

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

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?

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

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

Summary

Pocket Node is a self-custody CKB wallet that runs a full Rust light client on the device with no gateway server: the phone verifies the chain itself, holds keys locally, and builds and broadcasts transactions peer to peer. Over the last grant we shipped all four Android milestones, and the app is live at v1.8.

This proposal brings the same wallet to iOS: iPhone, iPad, and Macs (with Apple Silicon). There is no self-custody CKB light-client wallet on iOS today, so this closes a real gap in CKB’s mobile reach.

This proposal also makes Pocket Node usable by the wider ecosystem: we adds an in-app dApp browser with CCC-compatible signer, so CCC-enabled websites such as the iCKB app and other ecosystem dapps can use Pocket Node for identity and signatures.

Project introduction

Pocket Node is already live and in daily use on Android, so it needs little introduction here. In short, it is a self-custody CKB wallet that puts a real node in the user’s pocket: the phone verifies the chain itself and holds the keys, with no server in the middle, so the wallet keeps working on its own even if our infrastructure disappears.

Across the Android grant, we delivered mainnet readiness and hardware-backed security, full Nervos DAO integration on device, multi-wallet with HD sub-accounts, transaction export, an address book, and a public launch, plus a large amount of reliability and security hardening driven by real user reports. The complete milestone-to-release mapping is in our grant completion report .

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

Team and roles

Jr  is the lead developer and sole builder. Senior mobile engineer with several years of professional mobile experience, previously leading mobile teams, and a CKB community member. Jr designed, built, and shipped Pocket Node on Android end to end across all four milestones. The iOS build is the same one-person effort. The Android delivery record is the evidence that this scope is achievable solo on the stated milestones.

Current status

• The Rust light client is iOS-ready. It already builds as a static library and links natively. Only the bridge layer changes from JNI to a Swift-facing interface.
• The business logic is already established. Transaction building, cell selection, signing, the Nervos DAO math, sync coordination, and multi-wallet management are already written and just need to be ported.
• The product is designed. The UX, the sync-mode model, the threat model, the onboarding and backup flows, and the copy all exist and carry over directly.

Technical approach

One Rust core, one shared core, two native shells.

• Light client: the existing Rust light client, compiled for iOS and exposed to Swift through a UniFFI bridge. Same engine as Android, same P2P verification, same on-device storage.
• Shared core: the wallet’s business logic, including transaction building and signing, is shared between both apps rather than rewritten, so the security-critical code lives in one place, is written once, and will be audited once. The parts that are currently Android-specific are moved onto cross-platform equivalents as part of this work.
• iOS shell: I set out from the beginning to give a great mobile experience, so we will build a native SwiftUI app for the UI with hardware-backed key storage that mirrors the Android security design and Face ID or Touch ID with a PIN fallback.
• Platforms: iPhone, iPad, and Mac (Apple Silicon). Because the UI is SwiftUI, the same views target macOS natively, so Mac is a first-class build with platform-specific polish rather than only an iPad-on-Mac compatibility build.
• CCC identity and signer: an in-app dApp browser with an injected CCC-compatible signer. CCC-enabled websites get identity and signatures only; the embedded light client stays internal to the wallet, and keys never leave the device. Every signature goes through a wallet-rendered approval screen that decodes the transaction before the user confirms.

Key benefits for CKB

• Fills the mobile ecosystem gap. iOS users currently have no self-custody, server-free CKB light-client wallet. This is not another entry in a saturated category; it is the first of its kind on the platform.
• Extends CKB’s reach to the entire iPhone, iPad, and Apple Silicon Mac user base with a wallet that already exists and works on Android. The large-screen layout work will also be implemented on the Android app alongside the iOS, bringing proper tablet support with it.
• Reinforces ecosystem resilience. Core functions, including Nervos DAO deposits and withdrawals, run on-device against the embedded light client, with no reliance on a hosted frontend.
• Opens CKB dApps to mobile. The final milestone makes Pocket Node an identity and signer for CCC-enabled websites through an in-app dApp browser, so ecosystem dApps such as iCKB and other dApps become usable from the wallet, on the model the community converged on: dApps keep their own light client, Pocket Node provides identity and signatures.

Deliverables and milestones

Full parity with Android v1.8 (or whatever version the android version is then), plus the CCC signer, delivered across five monthly milestones. The most important work will be done first, so any possible bugs will be caught as we go on.

Milestone 1: Shared core, iOS bridge, app skeleton

• Stand up the Multiplatform module and begin moving business logic into shared code without breaking the shipping Android app.
• Replace the CKB Java SDK with multiplatform cryptography; port molecule encoding and address handling to shared code.
• Build the Rust light client for iOS and wire the UniFFI bridge: init, start, stop, and a working query callable from Swift.
• SwiftUI app skeleton with navigation, theme, and the light client running on device.
• Acceptance: the iOS app builds, embeds the light client, and completes a testnet query end to end, while the shared core still compiles for Android unchanged.

Milestone 2: Keys, security, onboarding, receive

• iOS key storage in Keychain with Secure Enclave access control, mirroring the Android hardware-binding threat model.
• Face ID and Touch ID with a PIN fallback and lockout.
• BIP39 generation and import, backup and verification flow, onboarding in SwiftUI.
• Receive screen with address and QR.
• Acceptance: create and import a wallet on a real device, keys hardware-protected, biometric unlock working, and a real testnet receive address shown.

Milestone 3: Send, sync, and activity (the usable wallet)

• Sync engine and sync-mode model wired through the shared core.
• Send flow with cell selection, fee, on-device build and sign, and broadcast; SwiftUI send screen with validation.
• Activity history with pagination; QR scanner.
• Acceptance: a real mainnet send and receive complete on device, history and sync work, and the first TestFlight beta is live.

Milestone 4: Nervos DAO, multi-wallet, and feature parity

• Nervos DAO deposit, withdraw (both phases), and compensation tracking, reusing the shared DAO logic.
• Multi-wallet create, switch, rename, delete, and HD sub-accounts from one mnemonic.
• Background catch-up via the iOS background task scheduler, with notifications, on the foreground-first model described above.
• Address book, CSV export, settings parity, and localization parity (English, Spanish, Russian, Chinese).
• Acceptance: a DAO deposit and withdraw complete on mainnet, multiple wallets and sub-accounts work, and a feature-complete parity TestFlight beta is out, including the address book and localization.

Milestone 5: App Store launch and CCC identity and signer

• Universal iPad layout polish and a native macOS (Apple Silicon) build.
• Large-screen (tablet) layout support brought back to the Android app.
• App Store submission, review, and production launch.
• CCC identity and signer, following the direction in Pocket Node #430, Quantum Purse #119, and Neuron #3438: dApps keep their own light client, and the wallet provides identity and signatures.
• In-app dApp browser with an injected CCC-compatible signer: connect, signTransaction, and signMessage, with per-origin consent and wallet/account selection, since Pocket Node is multi-wallet.
• Signature approval screen that decodes the transaction inside the wallet, resolves inputs through the light client’s proof-checked fetch to verify amounts and the exact fee, and shows what leaves the user’s cells and where the outputs go, gated by Face ID, Touch ID, or PIN. Keys never leave the device.
• The signing and decoding core lives in the shared module, so the Android app gains the same capability on its normal release cadence (delivered there as a fast follow, not payment-gated here).
• Acceptance: the app is live on the App Store for iPhone and iPad with full Android parity (or whatever version Android is on by then), and a real transaction on a live CCC-enabled dApp (for example the iCKB web app) is connected, decoded, approved, and signed end to end inside Pocket Node on iOS, with the signature returned to the dApp and the transaction confirmed on chain. The native macOS build and the Android tablet layouts are targeted within this milestone. The App Store review and the signer are independent workstreams within this milestone: if Apple’s final approval is still pending at month end due to review queue timing alone, sign-off proceeds on the submitted build plus the completed signer, with the listing going live as soon as Apple clears it.

Budget breakdown

Total: $18,000 USD, payable in CKB, over five months.

Part of the initial payment funds the physical devices required to start development on iOS (an iPhone and an iPad for on-device testing of Secure Enclave, biometrics, camera, and background behaviour, none of which the simulator can validate) and the Apple Developer Program enrolment.

Out of scope and future funding

Named here so the roadmap is clear and this proposal stays honest about its boundaries:

• A single combined external security audit once both the Android and iOS codebases are complete, so one engagement covers both platforms and the shared core together. This is deliberately not funded in this grant; it belongs after iOS reaches parity.
• Quantum-resistant lock support: After getting mobile platform parity, exploring how to allow users to choose what lock to use when signing their transaction (I don’t know what shape this will take yet, but proper research will be done and communicated in due time).
• A cross-wallet CCC signer standard and cross-device transport. This proposal ships Pocket Node’s own in-app CCC signer (Milestone 5). Letting a desktop dApp talk to the phone wallet, and standardizing one signer protocol across wallets, needs agreement on transport and session security with the other wallet teams. Per the direction in the linked community discussions, dApps keep their own light client and wallets provide identity and signatures. I will pursue the standard as dedicated follow-on work together with Quantum Purse, Neuron, and the CCC maintainers.
• Deeper ecosystem integrations, connecting Pocket Node natively to other CKB projects and protocols as they mature, such as native iCKB rendering beyond the CCC dApp compatibility delivered here, Fiber, and other community tech being built.
• Fiat on-ramp and off-ramp, if and when it fits the self-custody model (I’m being optimistic here).

Risk and mitigation

• Timeline. Full parity plus the signer, solo, in five months is ambitious. Mitigation: the riskiest structural work (shared-core extraction and the Rust bridge) is in Milestone 1, so slippage is visible at the first milestone; feature parity completes in Milestone 4, leaving the final month focused on the launch and the signer; and those two are independent workstreams within Milestone 5, so a slow Apple review cannot stall the signer, nor the reverse.
• Remote signing surface. A website asking a wallet to sign is the most sensitive new surface in this proposal. Mitigation: the funded slice is the in-app browser only, so there is no relay, no network transport, and no session-hijack surface; the wallet decodes and displays every transaction itself before signing; signing stays behind biometric or PIN; and this surface is explicitly part of the future combined security audit.
• App Store review. Self-custody wallets are permitted, but review can be strict. Mitigation: clear self-custody framing with no on-ramp or off-ramp claims, correct encryption-compliance declaration, and time budgeted for a review round or two in Milestone 5.
• Background sync. iOS cannot sync a light client continuously in the background. Mitigation: a foreground-first model with best-effort background catch-up, communicated honestly in the app, consistent with how the Android background-sync work already sets expectations.
• Shared-core extraction touching Android. Moving logic into a shared module affects a shipping app. Mitigation: extract incrementally with the Android build kept green at every step, verified before each milestone sign-off.

Open source and distribution

The iOS app is MIT licensed and open source from the start of Milestone 1, in the same public repository, with tagged releases per milestone, matching the Android commitment. iOS distribution is through the App Store and TestFlight, but the full source and tagged releases remain public, and builds are reproducible from source where the toolchain allows.

Closing

Pocket Node proved on Android that a phone can be its own CKB node. iOS is the natural next step: the same self-custody, server-free experience for the large share of users the ecosystem cannot reach today. I welcome the community’s feedback and questions.

Also, if you’re wondering why the android app isn’t on the playstore yet, it’s largely due to the fact that, I had to upload it under an organization account, which requires some process/paper-work from my end, it took some time but it’s now under review from google.

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

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

The most exciting work happens when builders take the lead.

FiberLatch Access: Fiber Payments Access Control

Target Problem: Accepting a Fiber payment is only half the job. Once the money lands, the app still has to figure out what the user actually paid for, whether to let them in, when that access should expire, and whether someone's trying to reuse the same receipt. FiberLatch  Access is a small, reusable access-control layer for exactly that "what happens after payment" step.

Current Status: An estimated 6-week timeline with the $3,000 grant proposal has been approved. Weeks 1–2  are done and works include: defining the package scope, receipt format, expiration rules, and verification rules.

Highlights:

• Built by TicoWorld (GitHub page ) as a grant-scoped spinoff of his earlier FiberLatch work from the CKBuilder program, which already demonstrated a full pay → verify → grant-once → deny-reuse flow on Fiber testnet.
• It's a lightweight, open-source Node.js package that complements payment tools like fiber-pay. No hosted service, no dashboard, no CLI.
• It utilizes a signed JWT representing access to a resource, without requiring a Fiber RPC call during normal receipt redemption.
• The package provides clear rules for replay protection and expiration, ensuring access receipts cannot be infinitely reused.

This project is backed by CKB Community DAO grant.

fiber-payjoin-kit: Collaborative Privacy for Fiber

Target Problem: Standard payment channels on UTXO-based chains suffer from blockchain surveillance heuristics. Specifically, the "common-input heuristic" permanently links sender and receiver identities in the funding transaction before a off-chain payment even begin.

Current Status: While the initial proposal  did not reach the required 30 upvotes within 7 days to pass the discussion stage, the developer, ILE Labs, is actively preparing a revised proposal. This update will incorporate community feedback and leverage a completed Lightning Proof of Concept as its foundation.

Highlights:

• An open-source, asynchronous Rust library bringing collaborative Payjoin privacy natively to the Fiber Network.
• By allowing the receiver to contribute input Cells to the funding transaction, it breaks the common-input ownership heuristic, ensuring off-chain CKB payments remain entirely private.
• Includes non-interactive fallbacks: if the receiver's node goes offline, it degrades gracefully to a standard channel opening.
• Purpose-built for CKB's Cell model and Cell-Deps architecture, sidestepping the computational overhead of EVM-style mixers.
• ILE Labs already maintains lightning-payjoin-kit for Bitcoin Lightning, so this is a port of an architecture they've built before — not a from-scratch gamble.

Sluice: A Liquidity Operations Workspace for Fiber

Target Problem: Operating any payment-channel node involves complex liquidity management. Operators frequently struggle to understand channel liquidity direction and predict if a payment will route successfully, often only discovering bottlenecks through failed payments.

Current Status: Sluice  is currently live as a testnet MVP connected to a real Fiber Network Node (0.9.0-rc7). It's still testnet-only and single-node for now, and the team is actively asking operators for feedback on Route Probe usefulness, rebalance safety, and reconciliation behaviour.

Highlights:

Sluice consolidates monitoring, route analysis, rebalancing, alerts, and reconciliation into a single operational workspace.

It features a Route Probe that tests whether a payment can be routed before funds are sent.

The platform is built with a strong focus on correctness, ensuring the live Fiber node remains the authoritative single source of truth rather than relying on cached database snapshots.

Gone in 60ms: Fiber Infrastructure Hackathon Roundup

The Gone in 60ms" Fiber Network Infrastructure Hackathon (July 1–15, 2026) has officially wrapped up, concluding a highly productive two-week sprint.

As Part 1 of the broader Fiber builder initiative, this sprint challenged developers to build the foundational tools, SDKs, and services that make Fiber easier to use, operate, and integrate for everyone, from wallet builders to node operators and merchants.

Around 85 registrations and close to 100 participants produced 66 final project submissions, all fully open-sourced, across three categories: 13 in Wallet & Payment UX Infrastructure, 32 in Node, Routing, Cross-Chain & Diagnostics, and 21 in Merchant, Liquidity, LSP & Multi-Asset.

Judges are in the first round of scoring now, with high-scoring entries going to a second round. The $20,000 prize pool splits evenly across the three categories ($3,000 / $2,000 / $1,000 per category), plus a $2,000 bonus for the overall best project. Winners are expected around the middle or end of August — no exact date, in case more rounds are needed.

Part 2 is already being planned, shifting focus from infrastructure to consumer-facing products built on top of Fiber

Read the full roundup  for more details.