Where this is going: strategic direction + v1.2 fee proposal
v1.1 (trustless automatic fund distribution) is live and verified on testnet. The full campaign lifecycle now runs without manual user cooperation. Before I start on v1.2 and the grant proposal, I want to step back and discuss direction with the community, because the right v1.2 design depends on where this platform is going.
Who is this for?
A few possible audiences, not mutually exclusive:
- CKB project launchpad: early-stage Nervos ecosystem projects raising from CKB-native users. Smallest TAM but easiest to serve well; users already have wallets, understand the model.
- BTC crowdfunding via CKB L1: BTC holders funding projects without leaving the Bitcoin trust assumption. Bigger audience, but UX has to abstract CKB almost entirely.
- General crypto-GoFundMe / charity: competing with Geyser (Lightning), Chuffed, etc. Largest reach, most UX work, hardest to differentiate.
My instinct is the path is 1 then 2 over time: launchpad first while the ecosystem is small, then lean into BTC as Fiber/RGB++ infrastructure matures. But I’d value pushback on this, especially from anyone who’s tried to bring non-crypto users into a CKB dApp.
Adjacent idea: subscriptions via Fiber
One thread worth flagging even though it’s out of scope for v1.2 (shoutout to @neon.bit for raising it): the current model is one-shot, all-or-nothing crowdfunding. A Patreon-style ongoing-subscription model via Fiber payment channels would serve a different need (sustaining creators, not launching projects) and could share a lot of frontend. Not committing to it, but interested whether the community sees demand.
v1.2: Platform fees & treasury
Within that direction, v1.2 is the concrete next step: put a sustainable fee/treasury mechanism in place now so it’s ready when volume arrives. Honest framing: at testnet/early-mainnet volume, fees fund essentially nothing. The point is to get the mechanism deployed and battle-tested before it matters financially.
Proposed design:
- 3% creator-side success fee. Charged only when a campaign hits its goal. Failed campaigns refund 100% to backers, no platform fee on failure, ever.
- Creator-side, not backer-side. Backer pledges X, X counts toward goal. On success, creator nets
raised × 97%, 3% routes to treasury. - On-chain enforced. The fee isn’t an off-chain convention. The pledge-lock script will require any success-release tx to include a treasury output ≥
pledge_amount × fee_bps / 10000. Skipping the treasury output causes the script to reject. Keeps v1.1’s “nothing important off-chain” principle. - Configurable via a platform config cell. Fee rate + treasury address live in a singleton cell read via cell_deps, not baked into contract args. Later governance (v1.5+) can adjust the rate without redeploying contracts.
- Multisig treasury. CKB secp256k1 multisig (me + 1-2 trusted community members) until v1.5+ ships governance and custody moves to a DAO-controlled address.
- No backer-facing fee surface. Backers see no fee, no surcharge. Creator sees their net payout on the create-campaign form. An About/Fees page explains the model.
Sequencing past v1.2:
- v1.3: Rebrand (the “Kickstarter” name isn’t usable on mainnet)
- v1.4: User dashboard and other UI/UX improvements
- v1.5+: Platform token, governance, staking; treasury custody transitions to DAO
- v2: BTC/RGB++ integration
- Open: Fiber subscriptions, other directions surfaced by community feedback
What I’d value feedback on:
- Audience. Launchpad first, then BTC. Does that match where you’d push this, or would you start somewhere else?
- Fee rate. 3% creator-side, success-only. Too high, too low, wrong side of the transaction?
- Treasury custody. Multisig in the v1.2 to v1.5+ gap. Acceptable, or wait for the DAO before turning fees on?
- On-chain enforcement. Any pitfalls in requiring a treasury output ≥ fee from the pledge-lock script?
- Fiber subscriptions. Real demand, or distraction?
- Anything I’m missing.
Holding off on v1.2 implementation to gather input. Thanks.