Spark Program | Fiber Pay Studio

DAOs & Funding Spark Program
,
1

Fiber Pay Studio — A Lightweight Payment-Request and Channel Dashboard for the CKB Fiber Network

Revised submission — addresses Spark Program Committee feedback on differentiation and verification detail

Team / Individual Profile and Contact Information

  • Name: Frank

  • Role: Lead developer, Tefro Labs

  • Background: Frontend-focused development studio applying to the CKB ecosystem for the first time through this Spark application. Previously scoped a Spore/DOB tooling proposal (DOB Pattern Studio) that the committee correctly declined on ecosystem-fit grounds; this proposal is a deliberate pivot toward the ecosystem’s current BTCFi / Fiber Network priority.

  • Email: [email protected]

Project Description

Problem

The Fiber Network is CKB’s instant, near-zero-fee Lightning-style payment layer, and it just moved to testnet (v0.6.0) as part of the ecosystem’s broader BTCFi / Bitcoin Layer 2 push. But actually using it today requires interacting with a Fiber node directly through raw RPC calls or CLI tooling.

A user who wants to try Fiber Network payments needs to:

  • Generate a payment request (the Fiber equivalent of a Lightning invoice) by hand-crafting RPC calls.

  • Check channel balance and payment history by reading raw node output or logs.

  • Confirm whether a payment actually settled, with no simple visual confirmation.

Today, none of this has a simple web interface. This is exactly the kind of last-mile UX gap that slows adoption of a newly-launched, technically strong piece of infrastructure: testnet activity doesn’t turn into real usage if the only way to try it is raw RPC calls. New developers and everyday users have no easy on-ramp to experience what the Fiber Network actually does.

Solution

Fiber Pay Studio is a small, open-source, CCC-powered web tool that lets a user:

  • Generate a payment request — a simple form (amount, optional memo) producing a shareable payment request link/QR code, backed by a connected Fiber node.

  • Pay a request — paste or scan a payment request and complete the payment via a connected wallet through CCC, with a clear success/failure confirmation.

  • View a simple dashboard — current channel balance, and a plain-language history of recent payment requests: created, paid, or expired.

  • Export a verification bundle — a JSON record of a handful of test payment requests (created, paid, and one expired/failed) with their actual outcomes, so a reviewer can independently confirm the flow works without running their own Fiber node.

This is a frontend tool composing existing, audited infrastructure — the Fiber Network node and the CCC wallet connector. No new protocol logic or on-chain contracts are introduced, which keeps technical risk low and the timeline realistic for a Spark-sized grant.

This will be a fully functional MVP, usable end-to-end through the hosted demo alone: generate a request, pay it, see it settle. The verification bundle is a supplementary reproducibility artifact for reviewers, not a substitute for a working tool.

Differentiation from Fiber Checkout

The committee asked how Fiber Pay Studio differs from the existing Fiber Checkout project in the Spark Program. The two operate at different layers and are complementary rather than overlapping.

Fiber Checkout is a React component library and hooks package. It’s built for developers who want to embed Fiber payments into their own apps, replacing manual JSON-RPC calls and hex encoding at the code level. It ships as an npm package / importable components, not as something an end user ever visits directly.

Fiber Pay Studio is a standalone, hosted end-user web app. It’s built for end users and reviewers who want to try Fiber payments directly, with no code and no integration step required — they just open the live dashboard. Its goal is to give the ecosystem a working, clickable reference for what Fiber payments feel like end-to-end, not to serve as a library other developers import.

Fiber Pay Studio does not depend on Fiber Checkout to function — it talks to the Fiber node directly — so there’s no build-order risk between the two proposals. Once Fiber Checkout’s component library matures, Fiber Pay Studio is a natural candidate to be rebuilt on top of it as a reference implementation, and the README will note this relationship explicitly so future builders understand how the two projects fit together rather than duplicate each other.

Relevance to the CKB Ecosystem

  • Directly supports the ecosystem’s current BTCFi / Bitcoin Layer 2 priority by making the newly-testnet Fiber Network usable by non-technical people, not just node operators.

  • Lowers the barrier to trying Fiber Network payments — the single biggest lever for turning testnet interest into real, citable usage data.

  • Produces a reusable payment-request UI pattern that other Spark applicants or ecosystem dApps could adopt or fork, instead of every project re-building Fiber payment UX from scratch.

  • 100% open source, forkable into the Spark-Program GitHub org per the program’s knowledge-base policy.

Expected Deliverables

  1. Payment Request Generation — Form-based request creation, QR/link generation, CCC wallet connect.

  2. Pay-a-Request Flow — Paste/scan a request, pay via connected wallet, clear settlement confirmation.

  3. Balance and History Dashboard — Current channel balance and plain-language history of created/paid/expired requests.

  4. Verification Bundle — JSON export of real test payment requests with actual outcomes, plus a “Replay Verification” feature to re-check them against the live Fiber node.

  5. Documentation — Short README walkthrough for other builders who want to reuse the payment-request pattern, including a note on how the tool relates to Fiber Checkout.

(Scope note: at this budget, this is deliberately a single clean core loop — generate request → pay request → dashboard → verification bundle — rather than a feature-complete wallet. Multi-channel management, routing visualization, and a mobile app are natural follow-ons if the program wants to extend support after Spark.)

How to Verify

Payment Request Generation

  • Reviewer steps: Open the hosted demo, generate a payment request, confirm a shareable link/QR is produced.

  • Verification proof: Live demo; example request in README.

Pay-a-Request Flow (expanded per committee request)

  • Reviewer steps:

    1. Open the hosted demo and either paste in the example payment request from the README or generate a new one via the Payment Request Generation step.

    2. Click “Pay,” which prompts a CCC-connected wallet popup to approve the payment.

    3. Approve the payment in the wallet.

    4. The UI polls the connected Fiber node for settlement status and updates the request’s state from “Pending” to “Paid,” typically within a few seconds given Fiber’s near-instant settlement.

    5. A confirmation panel displays the amount paid, timestamp, and a reference to the underlying Fiber node payment hash, so the reviewer can cross-check it against raw node output directly if desired.

    6. The same payment appears in the Balance and History Dashboard as a completed entry, and is included in the exportable verification bundle with its actual outcome recorded.

  • Verification proof: Live demo (a real, repeatable payment action producing a visible state change in the confirmation panel and dashboard); Testnet payment record with explorer/node reference; entry in the verification bundle, independently replayable via the Replay Verification feature without the reviewer needing to run their own node.

Balance and History Dashboard

  • Reviewer steps: After paying a request, open the dashboard and confirm the balance and history reflect it.

  • Verification proof: Live demo screenshot; README walkthrough.

Verification Bundle

  • Reviewer steps: Load /examples/sample-bundle.json from the repo, click “Replay Verification,” confirm each recorded request’s status matches the bundle (green checkmarks).

  • Verification proof: Sample bundle file in repo; Replay Verification feature in live demo.

Documentation

  • Reviewer steps: Open the README, confirm it explains the flow, includes a reproducible example, and states the relationship to Fiber Checkout.

  • Verification proof: Updated README.

This gives the committee a one-click, reproducible check on each deliverable rather than a line-by-line code review.

Required Funding

Total request: $1,000 USD, requested as 100% CKB (per the Committee’s 2026 update allowing single-currency payment).

Budget Breakdown

  • Payment request UI + generation flow — $400. Form-based request creation, QR/link generation, CCC wallet connect.

  • Payment + dashboard integration — $300. Wiring to the Fiber Network node’s RPC for paying requests and displaying balance/history.

  • Verification bundle export/replay + Testnet worked example — $300. JSON bundle format, “Replay Verification” feature, real Testnet payment requests as the reference example.

(CKB-equivalent amount will be finalized at the time of formal application, per the program’s pricing-snapshot convention. Disbursement follows the standard 20% / 80% split.)

Milestones

Milestone 1 — Core Payment Flow

  • Timeline: Weeks 1–2

  • Goal: Get a real payment request created and paid end-to-end on Testnet.

  • Tasks: Repo scaffold, CCC connector wired in, connect to a Testnet Fiber node, payment request generation form + QR/link output, pay-a-request flow via CCC wallet connect.

  • Completion criteria: A user can generate a request and pay it through the live demo, with a clear settlement confirmation.

Milestone 2 — Dashboard and Verification

  • Timeline: Weeks 3–4

  • Goal: Make the tool’s activity visible and independently checkable.

  • Tasks: Balance/history dashboard, verification bundle JSON format, “Replay Verification” feature.

  • Completion criteria: Dashboard reflects real payment activity; reviewer can replay the sample bundle and see it match.

Milestone 3 — Worked Example and Documentation

  • Timeline: Week 5

  • Goal: Ship a reproducible reference example and finish documentation.

  • Tasks: Run a handful of real Testnet payment requests as the worked example, write README (including differentiation from Fiber Checkout), buffer for review feedback.

  • Completion criteria: README includes a working example a reviewer can reproduce; final report submitted.

Estimated Completion Time

5 weeks. This is achievable in this timeframe because the tool composes existing, audited infrastructure (Fiber Network node RPC, CCC wallet connector) rather than building new protocol logic — the work is UI and integration, not new on-chain contracts.

Clear To-Do List

Weeks 1–2: Core Payment Flow

  • Scaffold repo (CCC dependencies, Fiber node RPC client)

  • Connect to a Testnet Fiber node

  • Build payment-request creation form + QR/link output

  • Implement pay-a-request flow via CCC wallet connect

Weeks 3–4: Dashboard and Verification

  • Build balance/history dashboard

  • Design and implement verification bundle JSON format

  • Build “Replay Verification” UI feature

Week 5: Worked Example and Documentation

  • Run a handful of real Testnet payment requests as the worked example

  • Write documentation / README, including a section clarifying the relationship to Fiber Checkout

  • Submit completion report with all links, payment records, and verification bundle

3 Likes
CKB Ecosystem Biweekly Update
2

Hi @Frank,

Thank you for your interest in the Spark Program and for submitting the Fiber Pay Studio proposal.

After review by the Spark Program committee, your proposal has been assigned a status of Pending. This is not a rejection, but an invitation to revise and provide further clarification.

The committee recognizes the value of improving the last-mile UX for the Fiber Network and appreciates your alignment with the ecosystem’s current BTCFi priorities. However, the committee requires further clarification on two specific points before proceeding with the evaluation.

Main Revision Recommendations:

  1. Differentiation from Fiber Checkout:
    The committee notes the existence of the Fiber Checkout project within the Spark Program. Could you please clearly elaborate on the key differences between Fiber Pay Studio and Fiber Checkout? How do their scopes, target users, and intended functionalities differ?

  2. How to Verify – “Pay-a-Request Flow Reviewer steps”:
    In your proposal, you mention a verification bundle that includes a “Pay-a-Request Flow Reviewer steps”. The committee would like a more detailed explanation of what this specific verification process entails.

Please revise and resubmit your proposal based on the feedback above. We look forward to your updated proposal and will arrange a new round of review promptly.

Best,
xingtian
On behalf of the Spark Program Committee

1 Like
4

Hi @xingtianchunyan,

Thanks for the detailed feedback — happy to clarify both points.

1. Differentiation from Fiber Checkout

Fiber Checkout is a React component library and hooks package meant to be embedded into other developers’ web apps, replacing manual JSON-RPC/hex-encoding calls at the code level. It’s infrastructure for builders integrating Fiber payments into their own products.

Fiber Pay Studio is a different layer entirely: it’s a standalone, hosted end-user-facing dashboard — a place where anyone (developer or not) can go to generate a payment request, pay one, and see their channel balance/history, without writing any code or having their own app to embed a library into.

Concretely:

  • Target user: Fiber Checkout → developers building apps. Fiber Pay Studio → end users and reviewers who just want to try Fiber payments directly.

  • Form factor: Fiber Checkout → npm package / component library. Fiber Pay Studio → hosted web app with a UI.

  • Relationship: they’re complementary, not competing. In fact, Fiber Pay Studio could later be rebuilt on top of Fiber Checkout’s components once that library matures — but today it doesn’t require Fiber Checkout to exist, since it talks to the Fiber node directly.

If it’s useful, we’re glad to explicitly note in the README that Fiber Pay Studio is intended as a reference “live demo” of what Fiber Checkout’s components could eventually power, to reinforce that the two projects reinforce rather than duplicate each other.

2. Detail on the “Pay-a-Request Flow” verification step

To be concrete, here’s exactly what a reviewer would do and see:

  1. Open the hosted demo and either paste in the example payment request from the README or generate a new one from the “Payment Request Generation” step.

  2. Click “Pay,” which prompts a CCC-connected wallet popup to approve the payment.

  3. Approve the payment in the wallet.

  4. The UI polls the connected Fiber node for settlement status and updates the request’s state from “Pending” → “Paid” within a few seconds (Fiber settlement is near-instant).

  5. A confirmation panel displays: amount paid, timestamp, and a reference to the underlying Fiber node payment hash, so the reviewer can cross-check it against raw node output if they want to go deeper.

  6. The same payment now appears in the “Balance and History Dashboard” as a completed entry, and is included in the exportable verification bundle with its actual outcome recorded.

So the “proof” isn’t just a screenshot — it’s a live, repeatable action (pay a real testnet request) that produces a visible state change in two places (payment confirmation panel + dashboard history) and a machine-checkable record (the verification bundle), which the reviewer can independently replay via the “Replay Verification” feature without needing to run their own node.

Let me know if either of these needs more detail — happy to expand the README section on this before resubmission.

5

Hi @Frank,

Thank you for taking the time to revise the proposal based on our earlier feedback.

The committee has completed its review and, after careful discussion, regrets to Reject the Fiber Pay Studio at this time.

We want to be transparent about the reasoning behind this decision:

Overlap with existing solutions:
Given that Fiber Checkout already offers a web-based wallet solution, the committee finds it difficult to see any significant breakthroughs or unique value in this project and therefore cannot support additional funding. The overlap between its features and target use cases makes it difficult to establish the project’s unique contribution at this time.

We appreciate the work your team has put into scoping this project. We recognize the effort and enthusiasm behind the proposal. Keep building, and feel free to reach out anytime!

Best,
xingtian
On behalf of the Spark Program Committee