Hello CKB and Fiber community,
I’m sharing FiberPass for early ecosystem validation and technical feedback.
FiberPass is wallet and payment UX infrastructure for prepaid, revocable Fiber Network payment sessions. It allows users to approve a spending limit once, while applications or scheduled payment flows execute payments automatically within the approved rules.
The project is currently deployed on CKB testnet and available for community testing.
The Problem
Fiber Network provides fast, low-cost payment channels, but repeated payments are still difficult to integrate into user-facing products.
Wallets and applications must separately handle:
-
User authorization
-
Spending limits
-
Channel liquidity
-
Payment readiness
-
Retry and failure states
-
Recipient onboarding
-
Settlement tracking
-
Transaction receipts
-
Revocation and expiry
This makes subscriptions, API metering, invoices, merchant payments, and other repeat-payment use cases harder to build.
FiberPass introduces a reusable payment-session layer that packages these requirements into a single pass.
How FiberPass Works
A user creates a FiberPass with:
-
A spending limit
-
An expiry time
-
A payment schedule or policy
-
One or more recipients
-
Revocation and pause controls
The current scheduled payment flow is:
-
The user connects a JoyID CKB wallet.
-
The user loads CKB into their FiberPass vault balance.
-
FiberPass reserves the amount assigned to the pass.
-
Recipients receive a magic link by email.
-
Each recipient submits their CKB wallet address.
-
FiberPass prepares Fiber channel liquidity from the reserved vault funds.
-
The payment worker executes the payment through the deployed Fiber node.
-
The Fiber exit settlement pays the recipient’s CKB wallet.
-
FiberPass records the payment proof, settlement transaction hash, explorer link, and receipt status.
-
The recipient receives a successful payment email.
The goal is to let users interact with limits, recipients, schedules, and receipts without requiring them to understand channel capacity or routing internals.
Current Functionality
The deployed testnet beta currently supports:
-
JoyID CKB wallet authentication
-
Per-user FiberPass vault balances
-
CKB testnet funding synchronization
-
Prepaid payment passes
-
Spending limits and expiry
-
Scheduled invoices
-
Multiple recipients
-
Recipient magic links
-
Automatic liquidity preparation
-
Fiber Network payment execution
-
CKB recipient settlement
-
Payment retries and structured failure states
-
Transaction hashes and Nervos explorer links
-
Recipient confirmation emails
-
Pass countdowns and detailed status
-
Pause, resume, revoke, top-up, close, and settlement controls
-
Pass history and payment attempt records
-
Developer apps, API keys, invoices, batches, and payment job records
-
Fiber node readiness, peer, channel, and outbound liquidity monitoring
Architecture
The core infrastructure includes:
-
React and TypeScript frontend
-
Node.js, Express, and TypeScript backend
-
MongoDB for wallet, session, recipient, and payment records
-
JoyID for CKB wallet authentication
-
Lumos and CKB testnet RPC/indexer tooling
-
A deployed Fiber RPC node
-
A dedicated payment worker
-
A custom FiberPass vault lockscript
-
SMTP email delivery for magic links and payout receipts
-
Vercel deployments for the frontend and API
-
Railway deployments for the Fiber node and payment worker
The detailed architecture, diagrams, user flows, developer flows, data models, and infrastructure components are documented here:
Initial Use Cases
FiberPass is being explored for:
-
AI and API usage metering
-
Subscription payments
-
Scheduled invoices
-
Multi-recipient payouts
-
Contractor payments
-
Rent and recurring fees
-
Merchant payment sessions
-
Wallet-integrated spending permissions
The longer-term goal is to package the session model into reusable wallet and application SDKs.
Early Validation Request
I would appreciate feedback from Fiber node operators, wallet developers, merchants, application developers, and the broader CKB ecosystem.
The main questions I’m trying to validate are:
-
Is a prepaid, revocable pass a useful abstraction for repeated Fiber payments?
-
Which use case should FiberPass prioritize first: API metering, subscriptions, invoices, or wallet integrations?
-
What should a Fiber wallet expose about channel liquidity and payment readiness?
-
Which failure states need clearer recovery flows?
-
What APIs or SDK components would make FiberPass easier to integrate?
-
Is the vault-to-Fiber liquidity model clear and practical?
-
What additional security controls should be required before mainnet use?
-
Would merchants or app developers use magic-link recipient onboarding?
-
What reconciliation, webhook, or accounting capabilities are most important?
-
Where could this design integrate better with existing Fiber infrastructure?
How to Test
-
Open the deployed FiberPass application.
-
Connect a JoyID CKB testnet wallet.
-
Load testnet CKB into the provided FiberPass vault address.
-
Create a scheduled invoice pass.
-
Add a recipient email and amount.
-
Open the recipient magic link.
-
Submit a valid CKB testnet wallet address.
-
Wait for the scheduled payout.
-
Review the pass details, Fiber execution state, transaction hash, explorer link, and receipt email.
NOTE: If email not delivered in inbox check spam!
Please use small testnet amounts only. FiberPass is an unaudited testnet beta and must not be used with mainnet funds.
Project Links
FiberPass is still early, and that is why ecosystem feedback is valuable now. I’m especially interested in identifying weak assumptions, missing infrastructure primitives, integration concerns, and the most practical path toward wallet and merchant adoption.