Spark Program | FiberPass: Spending Permission Infrastructure for Fiber Network

DAOs & Funding Spark Program
, ,
1

1. Project Overview

FiberPass is a payment session layer for Fiber Network. Users create prepaid, revocable passes with spending limits and expiry. Apps, AI agents, and merchants execute payments automatically within those bounds. Fiber channel complexity is fully hidden.

Project type: DApp / Payment UX Infrastructure

2. Team Profile

XBeach (0xbeach)

Solo developer. Built FiberPass from scratch on CKB testnet including a custom vault lockscript, deployed Fiber RPC node, payment worker, and full session lifecycle. The project has a live testnet deployment, a video walkthrough, and a detailed system design document. Previous community feedback thread: FiberPass on Nervos Talk.

GitHub: buidlLabs3

3. Project Background

Fiber Network has fast, low-cost payment channels. But building anything that charges repeatedly is still painful. Every developer integrating subscriptions, API metering, merchant checkouts, or scheduled payouts must solve authorization, spending limits, channel liquidity, retry logic, recipient onboarding, settlement tracking, receipts, revocation, and expiry from scratch. This is not a missing feature. It is the gap between Fiber as a protocol and Fiber as a product platform.

The CKB ecosystem team confirmed this gap in their August 2026 opportunity map:

“Pieces to inspect first: Trickle, FiberPass, Infern, fiber-pay, FiberLatch, and the FNN RPC surface.”
AI, machine payments, and Fiber in 2026

FiberPass is listed in the Validate Next quadrant for Routed CKB-Asset Sessions. This means the ecosystem leadership considers the primitives proven but lacks evidence of recurring demand and independent users. That is exactly what this grant produces.

What exists today:

  • Live testnet deployment at fiberpassfrontend.vercel.app

  • Working Fiber RPC node with channel and payment execution

  • Custom fiberpass-vault-lock lockscript deployed to testnet

  • Per-user vault addresses with on-chain balance sync

  • End-to-end payout flow: reserve, bridge liquidity, Fiber payment, CKB settlement, explorer-linked receipts

  • Payment worker with scheduled execution and retry

  • Charge API with idempotency, daily limits, and failure classification

  • App API keys, webhook delivery with HMAC signatures, invoice batches

  • Video demonstration: YouTube

  • System design: GitHub

What does not exist: a reusable library for developers, measured payment metrics from real integrations, or any independent user beyond the original demo. This grant closes those three gaps.

4. Solution

Three use cases, each creating genuine demand for Fiber channels.

Use Case 1: AI Agent Micropayments

An AI agent calls an API repeatedly. The user creates a FiberPass with a cap and expiry. The agent charges automatically per call. Each charge reserves from the vault, executes through Fiber, settles to the provider, and emits a receipt with tx hash and explorer link. The agent never touches channel logic. The provider receives settled CKB. Every agent with a FiberPass is a reason for a provider to open an inbound Fiber channel.

Fiber primitives used: hold-invoice-style reservation, vault-funded liquidity bridging, idempotent charge API, daily spend limits, failure-code classification.

Use Case 2: Subscription and Recurring Payments

A content creator or SaaS provider issues a FiberPass to a subscriber. Monthly cap, weekly auto-pay schedule. The payment worker executes on cycle, sends receipt emails, logs attempts. The subscriber pauses, resumes, or revokes at any time. Recurring payments create sustained Fiber channel usage, not one-off spikes. Every cycle, subscriber vault funds flow to the provider through Fiber settlement.

Fiber primitives used: scheduled payment worker, magic-link recipient onboarding, pause/resume/revoke controls, explorer-linked receipts, daily safety limits.

Use Case 3: Merchant Invoice and Payout Sessions

A merchant creates a multi-recipient payout pass. Contractors, contributors, or vendors receive magic links by email. Each recipient submits a CKB wallet address. The payment worker pays all recipients automatically through Fiber exit settlement. Every payout tracked with tx hash, settlement status, and notification email. Multi-recipient payouts require multiple inbound channels. Each recipient who claims funds becomes a new CKB wallet holder with a received Fiber payment.

Fiber primitives used: invoice batches, multi-recipient magic links, Fiber exit gateway settlement, webhook delivery with HMAC signatures.

5. Technical Approach

Frontend: React 19, TypeScript, Vite, Tailwind CSS
Backend: Node.js, Express, TypeScript, Zod validation
Database: MongoDB + Mongoose
Wallet auth: JoyID CKB (passkey challenge-response)
CKB tooling: Lumos, CKB testnet RPC/indexer
Fiber integration: Fiber RPC (JSON-RPC), custom vault lockscript
Worker: Node.js payment scheduler (embedded + standalone)
Hosting: Vercel (frontend + API), Railway (Fiber node + worker)

Architecture: User creates pass via JoyID-authenticated webapp. API validates, reserves vault balance, stores session. Payment worker bridges vault liquidity to Fiber channel, executes payment, settles to recipient CKB wallet. Charge API allows apps and AI agents to charge passes via API key with idempotency and scoped permissions. Webhooks notify external systems on payment events.

Key design: reserve-before-execute. Every Fiber payment first reserves funds from the user vault, then executes the Fiber payment, then debits on success. Failed charges never spend reserved funds. This is the core invariant that makes the system safe for automated spending.

6. Milestones and Deliverables

Milestone 1: Library and AI Agent Demo ($500)

Week 1: Extract session creation, charge, webhook verification, and receipt validation from the monolith into a lightweight TypeScript library (@fiberpass/lib). Publish in the buidlLabs3/fiberpassbackend repository under lib/. Write developer documentation with code examples: create a pass, charge it, verify a webhook, check a receipt. All types exported. Zero framework dependencies.

Week 2: Build a minimal AI API service that charges FiberPass per-call using the library. Deploy to testnet at a public URL. Measure charge success rate, average latency, retry count per 100 calls. Record video: create pass, make 5 API calls each charging the pass, view charge history with tx hashes, check explorer links.

Deliverables:

  • Library repo with passing tests, README with code examples, importable TypeScript types

  • Deployed testnet AI service at a public URL

  • Recorded video of full AI agent flow

  • Measurement data (completion rate, latency, retries)

Verification: Clone repo, run npm install && npm test, all tests pass. Import in a TypeScript file, types resolve. Watch video. Open tx hashes in Nervos Explorer. Confirm transactions exist with correct amounts.

Milestone 2: Subscription and Merchant Payout Demos ($500)

Week 3: Build a subscription pass template using the library: monthly cap, weekly auto-pay, pause/resume. Create a test merchant that issues subscription passes. Record video: auto-pay execution, subscriber pause, subscriber revoke, receipt emails.

Week 4: Build a multi-recipient invoice batch using the library: 3 recipients, magic links, scheduled payout. Record video: create pass, recipients receive magic links, submit wallets, Fiber payout executes, receipt emails sent.

Deliverables:

  • Deployed testnet subscription merchant

  • Deployed testnet payout service with 3 recipients

  • Recorded video of subscription lifecycle (auto-pay, pause, revoke)

  • Recorded video of merchant payout flow (magic links, wallet submission, settlement)

Verification: Watch both videos. Check explorer link for subscription auto-payment. Open 3 recipient settlement tx hashes in explorer. Confirm 3 separate CKB transactions to 3 different wallets.

Milestone 3: Independent Integration and Metrics ($500)

Week 5: Reach out to 3 existing CKB/Fiber community projects to integrate the library. Candidates: Infern, Trickle, FiberFlow. Document integration experience: what worked, what broke, what library changes are needed. Collect at least 1 integration from a project not built for this demo.

Week 6: Publish a Nervos Talk post with: payment completion rates across all 3 demos, latency percentiles, failure code distribution, retry behavior analysis, library adoption feedback, funding usage breakdown, lessons learned.

Deliverables:

  • At least 1 external integration from a community project not built for this demo

  • Integration documentation and library iteration log

  • Published Nervos Talk metrics and completion report

Verification: Open linked repository or PR. Confirm it uses @fiberpass/lib and was not authored by FiberPass builder. Read the Nervos Talk post. Confirm concrete numbers (percentiles, counts, distributions), not qualitative descriptions.

7. Budget Breakdown

Total requested: $1,500 USD

Infrastructure

Vercel Pro is required for 60-second function timeouts and cron jobs — both needed for Fiber payment execution and the daily payment worker. Railway hosts the Fiber node as a 24/7 P2P process with persistent storage. Domain registration (fiberpass.app) provides stable API endpoints for community integrations and webhook delivery.

  • Vercel Pro (frontend + backend + cron): $150

  • Railway (Fiber node + worker, 24/7): $200

  • Domain registration (fiberpass.app, 1 year): $60

  • CKB testnet tokens and channel funding: $20

Infrastructure total: $430

Development Work Per Milestone

  • Milestone 1 — Library + AI Agent Demo: $350

  • Milestone 2 — Subscription + Merchant Demos: $350

  • Milestone 3 — Independent Integration + Metrics: $370

Development Work: $1,070

8. Current State vs. Funded Work

Already built:
Full-stack FiberPass application with JoyID auth, per-user vaults, custom fiberpass-vault-lock with consensus-level owner refund action, Fiber node integration, payment worker, charge API, webhooks, invoice batches, magic-link recipient flow, and end-to-end settlement. Live testnet demo. Video demonstration. System design documentation.

Funded scope:
Library extraction and packaging with owner refund transaction builder. Three independent integration demos with measurement. Independent user acquisition. Payment metrics the ecosystem currently lacks. Developer documentation for adoption.

Out of scope:
Mainnet deployment. Formal security audit. Production-scale operations.

9. CKB Alignment

Every component depends on CKB-specific primitives:

Wallet auth uses JoyID, CKB-native passkey authentication. Vault addresses are derived from per-user CKB lock scripts via Lumos. Vault funding uses CKB UTXO cells with on-chain balance sync. Fiber execution uses Fiber RPC for channel open, payment send, and exit settlement. Settlement is a CKB transaction to the recipient wallet. Receipts are CKB transaction hashes with Nervos Explorer links. App API keys use CKB-address-based scope binding.

Without CKB’s cell model, there are no per-user vaults. Without Fiber, there are no instant micropayments. Without JoyID, there is no passkey auth. The session model is inseparable from CKB’s architecture.

10. Vault Self-Custody Guarantee

Users can withdraw vault funds without FiberPass backend or operator cooperation.

On-chain mechanism: The fiberpass-vault-lock script encodes ACTION_OWNER_REFUND (0x00) at the CKB consensus layer. Any transaction consuming vault cells only requires an owner auth input — a cell locked by the user’s JoyID/secp256k1 key. The operator cannot block this path.

Recovery flow:

  1. User locates vault cells on Nervos Explorer using their vault address

  2. User constructs a CKB transaction: consume vault cells → include owner auth input → output to personal wallet

  3. User signs with their JoyID/secp256k1 key and broadcasts via any CKB RPC

No backend dependency. The refund path is enforced by CKB consensus. FiberPass going offline, revoking API access, or refusing to cooperate does not prevent withdrawal. The user’s key is the only requirement.

What this grant adds: The @fiberpass/lib library will include a buildRescueTransaction() helper that constructs the owner refund transaction from on-chain data alone. This becomes a verified deliverable in Milestone 1.

Project Links

Live demo: fiberpassfrontend.vercel.app
Video demo: YouTube
Pitch deck: Google Drive
System design: GitHub
Frontend repo: GitHub
Backend repo: GitHub
Fiber node readiness: API
Previous community feedback: Nervos Talk
Ecosystem opportunity map: AI, machine payments, and Fiber in 2026

2 Likes
CKB Ecosystem Biweekly Update
2

Hi @XBeach , great to see your new proposal!

The following are my personal thoughts before submitting this proposal to the committee for review, for your reference. These views are based solely on my own understanding and do not represent the position of the committee.

  1. Scope and Priorities:

  • The current proposal lacks information regarding funds (Section 7), and the amounts specified do not align with standard practices: the budget for phases one to three is $500 each, which would mean the total amount should be $1,500. Please clarify the total amount and provide a detailed breakdown of the budget.

  • And most importantly, the core business logic of the project: The current proposal does not address how users should retrieve the funds stored in the insurance vault on their own in case of service disruption. Nor does it clarify whether users can withdraw their account balances solely based on on-chain data. If this is possible, it should be presented as a verifiable deliverable; otherwise, such a design poses custody risks.

Please revise it and reply in this post.

Best regards,
Xingtian

2 Likes
3

Hi @xingtianchunyan

Thanks for the feedback. Both points have been addressed:

  1. Budget: Section 7 now breaks down the full $1,500 — $430 infrastructure (Vercel Pro $150, Railway $200, domain $60, testnet $20) and $1,070 development across three milestones ($350, $350, $370). Each infrastructure item includes justification for the cost.

  2. Vault withdrawal: Section 10 (Vault Self-Custody Guarantee) explains the on-chain ACTION_OWNER_REFUND mechanism. Users can withdraw vault funds using only their JoyID/secp256k1 key — no backend or operator cooperation required. The @fiberpass/lib library will include a buildRescueTransaction() helper as a verified deliverable in Milestone 1.

2 Likes
4

Hi @XBeach,

Thank you for continuing to follow the Spark Program and for taking the time to prepare and submit the FiberPass project proposal.

The committee has completed its review and, after careful consideration, has regrettably decided to reject the FiberPass proposal at this time.

We would like to transparently explain the reasons behind this decision:

  1. A similar project with a higher level of completion:
    The Clasp project, which won first place in the Gone in 60ms: Fiber Network Infrastructure Hackathon Results (Gone in 60ms: Fiber Network Infrastructure Hackathon Results), is highly similar to this project and demonstrates a more complete implementation. The committee believes that the two projects have significant overlap in scope.
  2. Outdated technology stack:
    The proposal’s technical architecture is based on Lumos, which has been officially deprecated by the CKB ecosystem. The community has transitioned to CCC (CKBers’ Codebase) as the standard development framework—this information has been publicly announced through multiple official channels, and the committee has reiterated it several times during the review of other projects. The committee does not encourage or support building new infrastructure on a deprecated technology stack.

We sincerely appreciate all the effort your team has put in. Keep building, and feel free to reach out to us at any time!

Sincerely,
xingtian
On behalf of the Spark Program Committee