Hello Nervos Community,
I’d like to introduce CKB Kickstarter - a decentralized crowdfunding platform built natively on Nervos CKB, following the all-or-nothing funding model (like Kickstarter). The MVP is live on testnet with full lifecycle support, and I’m sharing it to get community feedback before moving toward mainnet.
Live Demo: decentralized-kickstarter-kappa vercel app
The Problem
There’s no trustless crowdfunding infrastructure on CKB today. If a builder or creator wants to raise funds for a project, the options are:
- Off-chain platforms - custodial, fee-heavy, not aligned with the CKB ecosystem
- Direct wallet transfers - no escrow, no accountability, no refund mechanism
- No all-or-nothing guarantee - backers have no assurance that funds will be returned if the project doesn’t reach its goal
CKB Kickstarter fills this gap: a fully on-chain crowdfunding platform where pledges are locked until the campaign deadline, and funds are either released to the creator (goal met) or refunded to backers (goal not met).
How It Works
Campaign Lifecycle
Create Campaign → Backers Pledge → Deadline Passes → Finalize → Release or Refund → Destroy
- Creator sets a funding goal (in CKB), a deadline (block height), and a title/description - all stored on-chain
- Backers pledge CKB to the campaign. Each pledge is its own cell, linked to the campaign
- After the deadline block, anyone can finalize the campaign - it becomes either Success or Failed based on whether the funding goal was met
- On success: backers release their pledge CKB to the creator
- On failure: backers claim refunds, getting their CKB back
- Once all pledges are resolved, the creator can destroy the campaign cell and reclaim the capacity
Why CKB Is a Natural Fit
1. Cell model maps directly to crowdfunding primitives
- Campaign cell = the campaign itself (goal, deadline, status, metadata)
- Pledge cell = individual backer commitment (amount, backer identity, campaign reference)
- Each is a discrete, ownable, verifiable on-chain object
2. Type scripts enforce the rules
Custom type scripts (written in Rust, compiled to RISC-V) validate every state transition:
- Campaign creation: valid parameters, status must be Active
- Finalization: only Active → Success/Failed, immutable fields preserved
- Pledges: must reference a valid campaign, immutable once created
3. Lock scripts provide custody guarantees
Using standard secp256k1 locks, backers have full custody of their pledge cells. No one can move a backer’s funds without their signature. In v1.1, a custom lock script will make this fully automatic (more on that below).
4. On-chain metadata
Campaign titles and descriptions are stored directly in the cell data as variable-length UTF-8 after the 65-byte structured header. No IPFS dependency for the core flow.
Current Status - Testnet MVP
The MVP is deployed on CKB testnet (Pudge) and has been externally tested by a CKB team member who successfully created a campaign, pledged to an existing one, and ran through the full lifecycle.
What’s Working
On-chain contracts (Rust, RISC-V):
- Campaign Type Script - creation, finalization, destruction validation
- Pledge Type Script - creation, immutability enforcement, destruction
Transaction builder (TypeScript + CCC SDK):
- 6 operations:
createCampaign,createPledge,finalizeCampaign,refundPledge,releasePledgeToCreator,destroyCampaign
SQLite-backed indexer:
- Background polling every 10s
- REST API for campaign/pledge queries
- Effective status computation (active, expired, success, failed)
Frontend (Next.js + React + Tailwind):
- Campaign listing with progress bars, status badges (5 states), time estimates, backer counts
- Campaign creation with form validation (title required, goal >= 100 CKB, deadline > current block)
- Campaign detail page with pledge form, sortable pledge list
- Role-based action buttons: Finalize, Release, Refund, Destroy
- Toast notifications, skeleton loading, transaction progress indicator
- JoyID wallet integration via CCC connector (verified working on testnet)
- Network-aware: supports devnet, testnet, and mainnet configurations
Testing & docs:
- 5 browser-automated E2E test scenarios
- Security review (5 findings documented)
- User guide, developer guide, testnet deployment guide
Architecture
contracts/
campaign/src/main.rs - Campaign Type Script (Rust, RISC-V)
pledge/src/main.rs - Pledge Type Script (Rust, RISC-V)
off-chain/
transaction-builder/ - CCC-based tx construction (6 operations)
indexer/ - Express + SQLite, background polling
frontend/ - Next.js 16 + React 19 + Tailwind CSS 4
Tech stack:
| Layer | Technology |
|---|---|
| On-chain | Rust + ckb-std, RISC-V target |
| Tx building | @ckb-ccc/core v1.12.2 |
| Wallet | @ckb-ccc/connector-react (JoyID, MetaMask Snap) |
| Indexer | Express 5 + better-sqlite3 |
| Frontend | Next.js 16 + React 19 + TypeScript |
| Styling | Tailwind CSS v4 |
| Hosting | Vercel (frontend), ngrok (indexer, temporary) |
Key Design Decisions
A few choices worth explaining:
total_pledged is always 0 on-chain. Real totals are computed by the indexer from live pledge cells. Updating the campaign cell on every pledge would mean consuming and recreating it per pledge, creating contention when multiple backers pledge simultaneously.
Finalization doesn’t enforce deadline on-chain. The lock script ensures only the creator can finalize (spending the campaign cell). The off-chain layer checks that the deadline has passed. This is a known trade-off - adding since field enforcement is planned.
Standard secp256k1 locks on pledge cells. Backers have full custody. This means they could withdraw a pledge before the deadline (a feature, not a bug - backers should be able to change their mind). The downside: after finalization, backers must manually release or refund. This is the main gap v1.1 addresses.
What’s Next - v1.1: Trustless Automatic Fund Distribution
This is the most important upgrade. Right now, backers must cooperate to release funds (on success) or claim refunds (on failure). If a backer disappears, the creator can’t get those funds. This defeats the purpose of a trustless platform.
The plan: a custom Pledge Lock Script that replaces the backer’s secp256k1 lock:
- On success: anyone can spend the pledge cell, but the lock script enforces that funds go to the creator’s address (read from the campaign cell via cell deps)
- On failure: anyone can spend the pledge cell, but the lock script enforces that funds go back to the backer’s address (stored in pledge cell data)
- While active: the pledge cell is locked - no one can spend it
This makes the entire flow trustless and automatic. A simple bot (or any user) can trigger the release/refund transactions - no private keys needed, since the lock script controls where funds go.
I’ve submitted a detailed technical request for feedback on this design to the CKBuilder-projects repo (CKBuilder-projects repo (issue #6)).
Further Roadmap
- v1.2: Campaign cancellation, editing (before first pledge), user dashboard
- v1.3: sUDT/xUDT support (stablecoin campaigns)
- v2.0: Milestone-based fund release with backer voting, NFT rewards via Spore, .bit identity integration
- v3.0: Cross-chain pledging via RGB++
Feedback Welcome
I’d appreciate feedback on any of the following:
-
Custom lock script design - Is the approach of reading campaign status via cell deps and routing funds accordingly a solid pattern on CKB? Any pitfalls?
-
Campaign cell identity - When a campaign is finalized, the cell is consumed and recreated (new outPoint). Should I use TypeID to give campaigns a stable identity?
-
Positioning - Does all-or-nothing crowdfunding fill a real gap in the CKB ecosystem? Any features you’d want to see as a potential backer or creator?
-
Architecture - Is the hybrid model (on-chain state + off-chain indexer + client-side tx building via CCC) a reasonable approach?
Please try the testnet demo and let me know what you think. Direct and critical feedback is welcome - I want to get this right before mainnet.
Thanks for reading!
