Evidence snapshot: 22 August 2026.
Written by @JackyLHH and @zz_tovarishch, thanks to @Hanssen, @RetricSu, and @quake for their comments and input.
We have been following the overlap between AI services and machine payments, along with the Fiber prototypes appearing on Nervos Talk. This report puts external systems, FNN’s current capabilities, and community projects in one place, so developers can see what each layer solves and identify questions worth testing themselves.
The short version
| Position | Areas | How to approach them |
|---|---|---|
| Reuse now | GUM generic usage metering; RPA receipt-based paid access | x402, Circle, Stripe, Lightning, Celer, and Fiber community projects already implement these patterns. Treat them as components before building another generic version. |
| Validate next | RCS routed CKB-asset sessions; BSS browser self-custody sessions | These are the closest match to Fiber’s current capability mix and already have working prototypes. Independent users, repeat payments, and recovery tests would add useful evidence. |
| Build after recurring traffic appears | PCO provider channel operations | Sluice and Fiber Studio provide a starting point. Demand should become clearer as traffic, nodes, and operators grow. |
| Frontier hypotheses | LFB Lightning-Fiber bridging; PPR payment-linked portable rights; CGE cross-operator game or device events | These draw on properties specific to Fiber or CKB, but each still depends on a clear user problem, liquidity, and production-grade implementation. |
x402 now has vendor-neutral governance through the Linux Foundation and public implementations for fixed-price payments, usage authorization, batch settlement, and signed receipts[1][2][3][4][5]. Around Fiber, developers have built paid AI calls, model serving, metered sessions, receipts, browser integrations, mobile and light-client integrations, games, device simulations, desktop tools, and liquidity operations tools. Most remain local or testnet projects, but they give later builders real components to inspect and reuse.
Fiber starts to differ when an application needs a particular combination of these properties: bidirectional sessions, CKB or UDT assets, multi-hop routing, browser-side self-custody, payments connected to rights represented on CKB, or asset movement between Lightning and Fiber. Ordinary one-way USDC API payments already have mature external options.
Part 1: An opportunity map for builders
The opportunity quadrant
Two questions place the opportunities: how much does an application depend on specific Fiber and CKB properties, and how much public evidence supports the user problem? Positions show relative judgments. They are not measured scores, market-size estimates, or rankings within a category.
Quadrant chart of dependence on Fiber/CKB properties and available evidence. Each ID uses the initials of the three key terms in the English area name listed in the table; colors correspond to reuse now, validate next, build after recurring traffic appears, and frontier hypotheses.
quadrantChart
title Fiber/CKB dependence and evidence
x-axis Lower dependence --> Higher dependence
y-axis Earlier evidence --> More public evidence
quadrant-1 More evidence / Fiber-linked
quadrant-2 More evidence / general
quadrant-3 Early / general
quadrant-4 Early / Fiber-linked
GUM:::commodity: [0.18, 0.82]
RPA:::commodity: [0.28, 0.68]
RCS:::plausible: [0.80, 0.43]
BSS:::plausible: [0.66, 0.30]
CGE:::speculative: [0.58, 0.17]
PCO:::conditional: [0.48, 0.29]
LFB:::speculative: [0.91, 0.20]
PPR:::speculative: [0.78, 0.09]
classDef commodity color:#64748b,radius:4,stroke-color:#334155,stroke-width:2px
classDef plausible color:#7c3aed,radius:4,stroke-color:#4c1d95,stroke-width:2px
classDef conditional color:#ca8a04,radius:4,stroke-color:#713f12,stroke-width:2px
classDef speculative color:#ea580c,radius:4,stroke-color:#7c2d12,stroke-width:2px
| ID | Area | Color and assessment |
|---|---|---|
| GUM | Generic usage metering | Gray, reuse now: a mature category and useful application component |
| RPA | Receipt-based paid access | Gray, reuse now: a proven pattern that Fiber applications can adopt |
| RCS | Routed CKB-asset sessions | Purple, validate next: the primitives exist, while recurring demand needs evidence |
| BSS | Browser self-custody sessions | Purple, validate next: several experiments exist, while recovery and maintenance still need testing |
| PCO | Provider channel operations | Amber, build after recurring traffic appears: useful once payment activity and operator count grow |
| LFB | Lightning-Fiber bridging | Orange, frontier hypothesis: a distinctive combination with substantial operating dependencies |
| PPR | Payment-linked portable rights | Orange, frontier hypothesis: closely connected to CKB, with the market still unexplored |
| CGE | Cross-operator game/device events | Orange, frontier hypothesis: technical demos exist, while the user and trust model need more evidence |
Four positions and six opportunity cards
These cards define a problem and compare options. They are not a roadmap, and equal space would not imply equal priority. GUM and RPA already have many reusable implementations, so the cards focus on the remaining six areas and group them by evidence and dependency.
Validate next: RCS routed, bidirectional CKB-asset sessions
User and repeating loop: An unattended agent or service has an ongoing relationship with another provider. Money or application assets may move in both directions over many interactions, and either party may stop the session.
Why AI: When the buyer is an unattended agent, repeated calls can make per-payment approval the bottleneck.
Why blockchain: The two parties do not share a billing operator, and the asset already lives on a public ledger.
Why Fiber: FNN supports bidirectional channels, multi-hop routing, CKB or UDT funding, hold invoices, keysend, and swaps when an available channel path exists. This combination matters in a narrower setting: one funded route reaches several providers, and the workload involves a CKB UDT, RGB++ asset, bidirectional value flow, or routed swap. An ordinary ERC-20 or USDC API channel does not require that combination.
Pieces to inspect first: Trickle, FiberPass, Infern, fiber-pay, FiberLatch, and the FNN RPC surface.
Comparable existing options: x402 batch settlement for one-way API calls, Circle for USDC, Celer for USDC channels, or Lightning for BTC.
When Fiber may not be needed: If almost all machine spending is one-way USDC payment to reputable providers, Fiber’s broader asset model adds complexity without user value. USDI’s operator has announced that it will cease operations, and the asset is being withdrawn from use, so a public mainnet stable-value path must be rebuilt around another asset.[57]
Current evidence: The required protocol primitives exist, but the full application hypothesis still lacks public evidence of recurring demand and independent users.
Validate next: BSS browser-side self-custodial pay-as-you-use features
User and repeating loop: A visitor opens an ordinary web page, unlocks a limited payment session with a passkey or wallet permission, and pays for several AI actions without creating an account or approving every call.
Why AI: Inference, search, transformation, or generation has a marginal cost that a small site may not want to absorb.
Why blockchain: A portable, user-controlled balance gives public settlement a role. Credits held by one site do not need it.
Why Fiber: Scryve Reads, Fiber WebLN, and the FNN WASM path show an unusual combination of browser-side node logic, passkey-derived keys, and reusable channel state. FNN v0.9.0 also improved WASM database performance and synchronization.[27]
Pieces to inspect first: Scryve Reads, Fiber WebLN, FiberLatch, FiberFlow, and fiber-pay.
Comparable existing options: Circle’s non-custodial nanopayments, a smart-wallet x402 session, or simple site credits. Mutiny also demonstrated browser-native Lightning before the project was archived.
When Fiber may not be needed: The released and officially maintained WASM and fiber-js architecture uses browser nodes as edge nodes connected to native Fiber nodes that stay online. IndexedDB persistence and core backup and restore are available, while recovery after a page closes, a device is lost, software is upgraded, or the user switches devices still needs product-level testing. If users trust the site, normal credits are simpler.[62][65]
Current evidence: The pattern appears in several community experiments, but retention and mainnet use have not yet been documented.
Build after recurring traffic appears: PCO provider-side channel operations
Problem: A provider receiving repeated machine payments needs inbound capacity, route checks, alerts, rebalancing, backup, recovery, and accounting. AI traffic may raise payment frequency, but this remains a channel operations problem.
Starting point: Sluice, Fiber Studio, the FNN watchtower RPC, public-node documentation, and v0.9.0 recovery changes cover parts of the workflow. FNN also has an unreleased liquidity-management prototype under active development. Its current RPCs and schemas are not stable integration surfaces; the Fiber team identifies M5 as the first integration-ready milestone.[63][65] Lightning’s LSP model offers another reference.
When to build: Operations tooling has few users when payment traffic is low. Its value should become visible after sustained payments create more nodes and independent operators.
Current evidence: Community tools are working, and FNN implementation is active. The new liquidity-management code has not reached a stable release, and public measurements of demand do not yet exist.
Frontier hypothesis: LFB Lightning and Fiber invoice bridging
Hypothesis: A user pays an invoice on one network, and a hub completes the corresponding payment on another. A machine buyer can automate the flow, although the swap itself does not require AI. The case for blockchain comes from moving value across two independent ledgers.
Starting point: CCH, or Cross-Chain Hub, is a deployable experimental component included in the formal release. Its RPC exposes send_btc and receive_btc, with bidirectional conversion between Lightning BTC and an operator-configured UDT when both sides use the same asset configuration. A documented end-to-end demo uses cWBTC to pay a Bitcoin testnet Lightning invoice. CCH Daily Smoke runs live testnet checks in both directions, including a relayed Lightning path.[56][59][65]
Pieces to inspect: FNN CCH RPC, CCH Daily Smoke, the community AgentPay design, FiberLatch, and Fiber Studio’s public Lightning-facing interface.
When Fiber may not be needed: If users can pay on their original network, L402 or x402 avoids running a second channel network. CCH requires a controlled operator, liquidity on both sides, an agreed wrapped asset, and an operating runbook.
Current evidence: The RPC and automated testnet smoke tests now cover both directions. This is stronger operational evidence than a one-off demo, but it does not yet show a production hub, liquidity at useful scale, or recurring user demand.
Frontier hypothesis: PPR payment-linked portable rights or credits
Hypothesis: A provider sells a machine-readable right, credit, or application asset. The buyer can verify or transfer it outside the provider’s database while Fiber handles frequent drawdown and a CKB cell or UDT represents the portable right.
Why an onchain object may help: Public settlement adds value only when a right must move, be verified, or be transferred across providers. Infern, FiberLatch, FiberPass, CKB xUDT patterns, and FNN hold invoices provide starting points, but arbitrary CKB script conditions are not yet available inside a channel flow.
When Fiber may not be needed: A database balance or x402 signed receipt is enough when the right stays with one provider. If the application only needs inexpensive USDC payments, a CKB rights object adds no clear value.
Boundary: Transferable prepaid value can create legal and platform-terms problems. Any design must use provider-authorized rights rather than relay access that violates another service’s terms.
Current evidence: This is an early concept. Programmable conditional payment is an official roadmap item but is not part of the stable release; arbitrary CKB-script conditions are not available inside a channel flow today.[65][66]
Frontier hypothesis: CGE cross-operator game and device events
Hypothesis: Players, models, devices, or service operators exchange many small events during a session and settle a final balance that no participant can rewrite alone. AI can create high-frequency opponents, referees, or device controllers, though many game and device flows do not need AI.
Starting point: OpenStrike, the P2P game and escrow demos, Trickle, the turn-based framework proposal, and the charging simulation each cover part of the hold-invoice, repeated-payment, or adversarial-session flow.
When Fiber may not be needed: A game server or device platform database is usually enough when one trusted server judges every event. Public settlement adds value when events cross operators, assets must remain portable, or participants reject unilateral custody.
Boundary and evidence: Several technical demos exist, but market demand has not been documented. Real-money competition may be gambling-adjacent, while device payments add hardware, connectivity, and consumer-protection issues.
How to move an experiment forward
Reuse existing components first
- Metered LLM or API calls can use x402
upto, x402 batch settlement, Circle, Stripe, or Celer as building blocks. - Payment-bound receipts can build on x402 signed receipts or L402. A single-use, preimage-gated capability with replay rejection remains a narrower application pattern to explore.
- Milestone escrow can use hold invoices, while delivery verification and dispute handling remain application responsibilities.
- Agent spending policy can come from a general wallet layer and then authorize Fiber operations where needed.
- Agent identity and reputation become more useful after unrelated participants create a transaction history.
- A compute marketplace can use Fiber as one payment option, but hardware supply, scheduling, reliability, price, and buyer access remain the larger product.
All of these capabilities can appear inside a Fiber application. Fiber adds value only when the application needs its asset, routing, custody, or interoperability properties.
Produce evidence that the ecosystem does not have yet
The ecosystem already contains a generic CLI and SDK path, several MCP and x402-style experiments, paid AI calls, model serving, paywalls, receipts, merchant checkout, browser permissions, mobile FFI and light-client integrations, desktop node software, automated CCH tests, liquidity operations tools, and multiple game patterns.
A project can add useful evidence when it does one of the following:
- Reuses an existing component on FNN v0.9.0 and documents what broke
- Connects two independently maintained projects
- Compares Fiber with an existing alternative on a property that matters to the application
- Measures payment completion, latency, retry behavior, locked capital, rebalancing, recovery, and operator time
- Brings a provider or user who was not created for the demo
- Publishes enough instructions for another developer to reproduce the result
A wrapper around an existing testnet loop can still be a useful learning project. To support a new use case, connect existing components, measure their behavior, or bring in an independent user or provider.
Questions that test the hypothesis
- Which public projects still run against FNN v0.9.0 without private patches?
- Can a browser-side Fiber session recover safely after tab closure, device loss, or an FNN upgrade?
- What real workload needs bidirectional or non-USDC settlement strongly enough to accept channel operations?
- After USDI’s discontinuation, which stable-value asset could be issued, redeemed, routed, and accounted for on mainnet?
- Can an independent provider receive repeated payments without manually solving inbound liquidity?
- Does CCH remain reliable under repeated traffic, and what capital does its operator need?
- Which application condition requires a CKB script instead of a signed receipt or a database rule?
- What public evidence would show sustained use rather than hackathon completion or subsidized test traffic?
Part 2: Evidence and technical map
The rest of the report explains the layers, external benchmarks, FNN boundaries, and community projects behind the opportunity map. Readers choosing a direction can stop after Part 1. Builders comparing implementations can use Part 2 to check the technical limits and find existing components.
The layers of a machine-payment system
These terms often get mixed together even though they solve different problems.
| Term | Plain meaning | Why it matters |
|---|---|---|
| Agent wallet | A wallet that lets software spend within rules such as amount caps, allowed recipients, expiry, or human approval | An agent should not receive an unrestricted private key just because it needs to buy an API call. |
| x402 | A way for an HTTP server to request payment and for a client to attach payment evidence | It defines a web payment conversation. It does not require one settlement rail. |
| Payment channel | Funds are committed once, balances change offchain, and a later state settles onchain | Many small interactions can avoid one blockchain transaction each, but channel liquidity and recovery become operational work. |
| Hold invoice | A payment is accepted but not completed until a preimage is released or the invoice is cancelled | Useful for delivery gates, escrow-like flows, and adversarial events. It does not solve who judges delivery. |
| Keysend | A spontaneous channel payment that does not start from a normal invoice | Useful for repeated ticks and custom records, but an application still needs its own metering and delivery logic. |
| LSP | A service that provides inbound channel capacity and related liquidity operations | A provider cannot receive reliably just because the protocol supports channels. Someone must fund and operate useful routes. |
| Payment receipt | A verifiable record that a payment or service interaction occurred | Receipts can support access, audit, or reputation. Fiber applications can reuse the generic pattern and add value through the surrounding settlement or access flow. |
Together they form this stack:
flowchart LR
accTitle: Machine-payment layers from agent intent to market distribution
accDescr: A wallet policy controls an agent, an HTTP protocol negotiates payment, a rail settles value, operators provide liquidity, merchant software delivers and reconciles service, and identity or marketplaces can appear after transactions exist.
agent[Agent or software buyer]
policy[Wallet policy<br/>caps, scope, approval]
protocol[HTTP negotiation<br/>x402, MPP, L402]
settlement[Settlement<br/>direct, batch, channel]
liquidity[Liquidity and operations<br/>capacity, uptime, recovery]
service[Service delivery<br/>receipt, access, reconciliation]
market[Later distribution<br/>identity, reputation, markets]
agent --> policy --> protocol --> settlement --> liquidity --> service --> market
classDef buyer fill:#e0f2fe,stroke:#0284c7,stroke-width:1px,color:#0c4a6e
classDef protocolstyle fill:#eef2ff,stroke:#4f46e5,stroke-width:1px,color:#312e81
classDef rail fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#4c1d95
classDef experimental fill:#fff7ed,stroke:#c2410c,stroke-width:1px,color:#7c2d12
classDef later fill:#f3f4f6,stroke:#6b7280,stroke-width:1px,color:#374151
class agent,policy buyer
class protocol protocolstyle
class settlement rail
class liquidity,service experimental
class market later
Fiber provides a settlement network and a set of payment primitives. A complete product can combine those primitives with wallet policy, stable-value liquidity, merchant software, distribution, and a clear reason for users to pay.
The wider field
The intersection of AI and blockchain spans several markets with different customers and evidence. Their relevance to Fiber varies sharply.
| Area | Existing infrastructure | What it means for Fiber developers |
|---|---|---|
| Wallet policy | Coinbase Agentic Wallets, Turnkey, Privy[6][7][8] | Mature components already enforce amount, recipient, and approval rules. They can authorize Fiber actions without rebuilding wallet controls. |
| Payment interfaces and settlement | x402, Stripe/Tempo MPP, Lightning L402, Circle Nanopayments, Celer AgentPay[1][4][9][10][11][12] | HTTP negotiation, mainnet USDC, channels, and batch settlement all have working options. Before choosing Fiber, check whether the application depends on its assets, routing, or CKB rights objects. |
| Identity, reputation, and agent markets | ERC-8004 and NEAR Agent Market[14][54] | Draft standards and a market experiment already exist. On 22 August, the NEAR dashboard showed 5,103 agents, 117 active, 29 active over seven days, and one online service out of 976. Without repeat transactions, a reputation layer has little to evaluate. |
| AI for blockchain security and development | Hypernative, Blockaid, OpenZeppelin Contracts MCP, Forta[15][16][17][18] | Monitoring, response, and developer tools are already deployed. They can serve CKB projects without depending on Fiber. |
| Compute, training, and data | Akash, Render, io.net, Gensyn and its Delphi market, Sapien, Vana[19][20][21][22][58][23][24] | Hardware supply, scheduling, quality, rights, and buyer access usually shape the product more than the payment rail. Fiber becomes relevant when the service needs its asset or routing properties. |
| Verifiable computation | DeepProve and other proof systems[25] | A proof can show that a defined computation ran against committed inputs. It cannot establish that a model is accurate, fair, safe, or useful, and no clear Fiber dependency is visible today. |
Payments deserve the closest look because Fiber’s primitives overlap with current activity there. The other categories remain relevant to CKB, but they need a specific Fiber dependency before they belong in a Fiber thesis.
Payment systems developers can compare and integrate
x402
A server answers an unpaid request with 402 Payment Required. The client selects an accepted payment option, attaches an authorization or proof, and retries. The settlement scheme is extensible.
Current x402 documentation already covers several use cases often described as open opportunities:
exactsupports a known price.uptolets a buyer authorize a maximum while the seller settles the measured amount for that request. The examples include LLM tokens, bandwidth, compute time, and dynamic queries.[3]batch-settlementuses EVM escrow and cumulative offchain vouchers, then redeems many claims together. It is explicitly aimed at repeated API calls and usage-metered endpoints.[4]- Signed offers and receipts provide portable proof of terms and delivery.[5] The receipt is a seller-signed statement. It does not by itself create a single-use capability, track consumption, or reject replay.
The public x402 site reports 75.41 million transactions, $24.24 million in volume, 94,060 buyers, and 22,000 sellers for its latest 30-day window.[2] The figures describe operator-reported activity. They do not reveal how many buyers are autonomous agents, how many return, which scheme they use, or whether any traffic would choose Fiber.
Coinbase’s CDP facilitator lists exact, upto, and batch-settlement on Base, Polygon, Arbitrum, and World mainnets.[53] These listings establish a deployable production service for the schemes. They do not establish scheme-specific traffic, named users, or long-running reliability, because the published volume is not broken down by scheme.
Circle nanopayments
Circle’s mainnet product supports gas-free USDC payments down to $0.000001 across 11 chains. A user deposits USDC into a non-custodial smart contract and signs payment authorizations; Circle verifies them quickly and settles batches later.[11]
A channel system therefore competes with sponsored, delayed, and batched settlement, not with one onchain transaction per call. Circle is also not accurately described as a custodial balance that the operator can spend. Its published design says payments execute from user-signed authorizations.
Stripe and Tempo MPP
MPP is another HTTP payment protocol. Stripe supports stablecoins and traditional methods such as cards and buy now, pay later, then gives merchants the reporting, tax, fraud, accounting, refund, and payout machinery they already use.[9]
Fiber is unlikely to match that distribution through a cheaper rail alone. A complementary Fiber flow becomes more useful when it serves an asset relationship or user group that Stripe’s normal merchant stack does not cover well.
Lightning and L402
L402 combines a Lightning invoice with a macaroon. Paying reveals the preimage needed to form an access token. Aperture provides the reverse proxy and is used by Lightning Loop.[10]
L402 and Lightning are the closest operational precedents for payment-gated APIs, self-hosted services, hold invoices, keysend, and channel operations. Payment-bound access and browser channel wallets both predate Fiber. Mutiny demonstrated a non-custodial Lightning node in the browser before the project was archived in April 2025.[26]
Celer AgentPay
Celer places x402 above USDC state channels on Base. Its published demo opened a channel, made five paid calls that returned 2,500 market snapshots, and closed the channel.[12]
As a demo, the example is best used as a technical benchmark. It shows one way to combine x402 and an agent-payment channel. For repeated USDC payments, Celer benefits from using USDC on Base, where a native settlement rail already exists.
FNN’s current surface
FNN v0.9.0 was released on 6 August 2026 with improvements to recovery, routing, MPP, trampoline routing, CCH handling, watchtower behavior, database migration, and node operations.[27]
| Primitive | Current status | Practical boundary |
|---|---|---|
| CKB and UDT channels | Released | The mechanism can fund a channel with CKB or a UDT type script, and public mainnet nodes accept UDT channels. No publicly reusable UDT liquidity or routing path is currently available on mainnet. The documented public example uses testnet RUSD. USDI’s operator has announced that it will cease operations, so a public mainnet stable-value asset and funded route need a new path.[13][28][57][65] |
| Asset swaps across available channel paths | Official feature claim | The README says asset pairs can be swapped when channel paths are available. Useful operation still depends on asset liquidity and routes, and no production volume is documented.[13] |
| Multi-hop routing | Released | Useful routes still require funded capacity and reliable operators. |
| MPP and trampoline routing | Basic MPP released since v0.6.0; improved in v0.9.0 | Do not confuse Fiber’s MPP, multi-part payment, with Stripe and Tempo’s Machine Payments Protocol. Atomic all-or-nothing multi-path payment remains a longer-term research direction.[65][66] |
| Hold invoices | Released RPC lifecycle | Escrow-like settlement is possible; delivery verification and disputes remain application problems.[29] |
| Keysend and custom records | Released primitive, used by community experiments | Useful for metering data; payment and service delivery are not automatically atomic. |
| Watchtower module | Released inside FNN | No public hosted tower market or discovery mechanism is documented. |
| CCH | Released experimental component; controlled operator required | The RPC exposessend_btc and receive_btc and supports Lightning BTC with an operator-configured UDT. One documented demo uses cWBTC, while CCH Daily Smoke runs automated testnet checks in both directions. No recommended public operator, wrapped asset, or deployment runbook is currently published.[29][56][59][65] |
| Browser runtime | Released and officially maintained | FNN v0.9.0 improved WASM database performance and synchronization. Browser nodes are edge nodes connected to always-on native nodes and cannot open direct browser-to-browser channels. IndexedDB persistence and backup and restore are available; product-level recovery and the native-node dependency still need testing.[27][62][65] |
| x402 support | Paused draft PR#1301 | The draft covers an exact-payment backend but is not released or the planned integration entry point. The broader x402 direction remains under consideration.[31][65] |
| PTLC | Planned direction | The light paper and current Fiber glossary describe hash-based TLC/HTLC flows as today’s design and PTLC as a planned direction.[32][64] |
| Programmable conditional payment | Official roadmap item; not in the stable release | The scope includes PTLC, hold-invoice application protocols, onchain conditions, and agent fair exchange. Existing HTLC and hold-invoice primitives do not make arbitrary CKB-script conditions available inside a channel flow.[65][66] |
| Advanced liquidity management | Active unreleased development | Manual Loop In and Loop Out, persistent recovery, initial provider mode, and cross-node negotiation exist on a development branch. Do not treat the current RPCs or schemas as stable; M5 is the first planned integration-ready milestone.[63][65] |
The protocol and public mainnet nodes accept UDT channels, but no publicly reusable UDT liquidity or routing path is available on mainnet. The public-node guide demonstrates UDT payments through testnet RUSD. USDI’s operator has announced that it will cease operations, so it cannot serve as a future mainnet stable-value route.[28][57][65] Developers will need a different mainnet asset, liquidity path, and operating arrangement before building regular stable-value payments.
According to the AMA recap, core channel, routing, and multi-hop functions operate, while stability testing, security hardening, liquidity, wallet interoperability, and production operating experience still need work.[30]
What developers have already built around Fiber
The projects below are a starting point rather than a complete catalog. Status follows the cited project materials, and builders should recheck current compatibility before reusing a component. “Documented runnable testnet” means that the author provides a public or reproducible testnet path; mainnet safety, commercial demand, and long-term maintenance are separate stages.
AI services, policy, and payment access
| Project | Relationship | Public evidence | What another builder can reuse |
|---|---|---|---|
| fiber-pay[33] | CKB DevRel experiment | Public developer tool and testnet workflows | CLI and SDK patterns, node and channel operations, AI-tool integration |
| Paid AI Agent Calling[34] | CKB DevRel experiment | Public testnet demo with a fixed price per remote call | A complete buyer-to-agent-service payment loop and isolation discussion |
| Infern[35] | Independent community project | Public testnet prototype; specification described as early and rough | Local model serving, F402, provider listing, stake and reputation experiments |
| AgentPay, CKB community project[36] | Independent community project | Self-reported repository and local prototype; public demo, mainnet route, stablecoin route, and production hub remain pending | Hold-invoice escrow, MCP tools, and a proposed Lightning to CCH to Fiber flow |
| FiberPass[37] | Independent community project | Unaudited testnet beta | Caps, expiry, schedules, revocation, operator liquidity, and receipts |
| Trickle[38] | Independent community project | Runnable testnet prototype | Signed grants, budget enforcement, per-tick keysend, and custom records |
| FiberLatch[39] | Independent community project | Runnable testnet proof | Signed access receipts, one-time redemption, and replay rejection |
| FiberFlow[40] | Independent community project | Hosted testnet merchant tool | Invoices, checkout, webhooks, and self-hosted acceptance patterns |
| Scryve Reads[41] | Independent community experiment | Runnable testnet demo; author calls it an experiment, not a product | In-page WASM node, passkey-derived keys, and paid-content flow |
Wallet, client integration, and operations tooling
| Project | Relationship | Public evidence | What another builder can reuse |
|---|---|---|---|
| Fiber WebLN[42] | CKB DevRel experiment | Experimental testnet providers and browser extension | A website-to-wallet permission boundary, with embedded and remote-node modes |
| Fiber Studio[43][55] | Independent community project | Public desktop software with signed installers; v1.1.1 released on 20 August | Node, wallet, channel, and payment packaging. This is shipped tooling, not evidence of audited wallet security or adoption. |
| Sluice[44] | Independent community project | Hosted testnet operations tool | Route probes, operator-triggered rebalancing, alerts, and reconciliation |
| Fiber FFI[60] | Independent community experiment | Public source, integration guide, and Android and iOS demos; the author describes the ABI as exploratory | A C ABI for embedding the Rust Fiber node in native mobile or desktop applications; production key storage and lifecycle design remain with the host app |
| Fiber + CKB Light Client[61] | Independent community experiment | Public source; basic light-client preparation, node startup, channel, and payment flows work; the post says the integration is not production-ready | An embedded light client and local RPC gateway that can reduce a mobile or desktop application’s reliance on a remote full-node RPC |
| CCH Daily Smoke[59] | Public test and operations project | Scheduled live testnet checks across local and external CCH paths | Bidirectional CCH regression tests, version tracking, route checks, and failure reports |
Games, events, and devices
| Project | Relationship | Public evidence | What it shows |
|---|---|---|---|
| OpenStrike Fiber Arena[45] | CKB DevRel experiment | Public testnet FPS prototype | Hold invoices can settle rapid game events. A trusted server judges damage, and the demo does not supply a full anti-cheat system. |
| Fiber P2P game and escrow demos[46] | FNN core-maintainer experiments | Author-reported runnable local demos | Simple adversarial-game and escrow patterns can be built with two local nodes. |
| WarSpore Saga[47] | Independent community and DAO proposal | Testnet PVE exists; Fiber PVP appears in a proposed milestone | A game around CKB assets exists, but the cited thread does not show a completed Fiber PVP implementation. |
| Turn-based competition framework[48] | Independent community proposal | Architecture proposal | A useful trust and challenge design discussion, not a deployed framework. |
| Fiber charging simulation[49] | Independent community experiment | Author-reported runnable testnet simulation | One channel to a router can support repeated device-like payments. It does not demonstrate a charging business or hardware deployment. |
| Dular[50] | Spark Program project | Public web and testnet prototype | Browser and mobile payment UX, while formal fiat withdrawal and real USSD remain incomplete. |
Two builder events reported 22 AI-agent submissions and 66 Fiber-infrastructure submissions.[51][52] The roundups show substantial builder participation and provide many components to inspect. Because submissions span multiple FNN versions and project stages, maintainership and current compatibility are best checked project by project.