[DIS] CrowdCell: From Testnet Demo to a Crowdfunding Product on CKB | CrowdCell:把 CKB 测试网上的免信任众筹做成产品

This is a smaller, rescoped version of the first CrowdCell proposal. The audit, the fee model and the mainnet launch are out of this one and will come back as a separate proposal later.

Edited 2026-10-12. Added at no change to the ask: categories and search (M1), creator updates and a Chinese interface (M3), early finalization once the goal is met (M4). The additions are marked “added” in §8 and §9. Edited 2026-10-13: early finalization is an option the creator sets when creating the campaign, and the .cell names PR is merged.

2. Summary

CrowdCell is all-or-nothing crowdfunding on CKB where scripts, not a platform, decide where every pledge goes. It is live on testnet at https://crowdcell.vercel.app.

This proposal requests $5,000 USD (payable in CKB) to turn the testnet app into a product people can actually run a campaign on. It stays on testnet and asks for no audit money. It covers five things:

  1. Trustless finalization, rebrand and landing page (already delivered). Since the first proposal, the campaign total moved on-chain so the outcome is verified by the script, the project became CrowdCell, and the site got a proper landing page. All of it is live and can be checked today.
  2. Dashboards and discovery. “My campaigns” for creators and “My pledges” for backers, plus categories and search on the campaign list.
  3. Creator identity. .cell names and Vellum reputation on campaign pages, so a backer sees who is asking for the money and not just a lock hash.
  4. Creator tooling and first real campaigns. Creator updates on campaign pages, shareable campaign pages, a Chinese interface, a creator guide and mobile QA, with a goal of at least three campaigns run by people outside the project.
  5. Keeper tip and early finalization. A small on-chain tip for whoever triggers release or refund, so settlement no longer depends on my bot. And a creator who turned the option on when creating the campaign can finalize it as soon as the goal is reached, without waiting for the deadline.
  • Grant Amount Requested: $5,000 USD (payable in CKB)
  • ETA to Completion: about 3 months from approval
  • CKB Wallet or Funding Address: ckb1qrgqep8saj8agswr30pls73hra28ry8jlnlc3ejzh3dl2ju7xxpjxqgqqxdl32chss0tlfyexs6h74ny8cc3vl90dgpt6evj

3. Project Introduction

A creator sets a funding goal in CKB and a deadline. Backers pledge. If the goal is met by the deadline, the funds go to the creator. If it isn’t, every backer is refunded. Nobody holds the money in between: each pledge sits in its own cell, and the lock script on that cell only allows those two exits.

What problem this solves

Kickstarter-style platforms ask you to trust an operator to hold the funds, decide the outcome and pay out. There is no crowdfunding platform on CKB today, and the cell model fits the problem well: a campaign is a cell, a pledge is a cell, and the rules are the scripts guarding them.

Who this is for

CKB builders first. CrowdCell is a launchpad for CKB projects: the people most likely to use it already have a wallet and CKB. Pledging from a Bitcoin wallet through RGB++ comes later, once the launchpad use case is proven.

What changed since the first proposal

The first proposal asked for $15,000 to go to mainnet, with $7,000 of it reserved for an audit. It got 16 likes and no objections, and the feedback I got afterwards was clear: too big a step, too early. Make it a product on testnet first, keep the ask small, and come back for the audit and mainnet when there is usage to point at.

So I kept building and cut the proposal down:

  • Out: the Scalebit audit, the 5% fee with its config cell and treasury, the mainnet deployment and the launch promo. Fees only matter once real money moves, and that code needs the audit anyway.
  • Already done, unfunded: the last on-chain trust gap is closed, the rebrand is live, the landing page is live.
  • In: the things that make it usable as a product, most of them asked for or offered by people in the community (see §8).

Why now

  • The contracts are in their intended shape for testnet. What is missing is product surface, not mechanism.
  • Two other CKB projects are plugging into CrowdCell: Cellula’s PR that shows .cell names is merged and live on testnet (CrowdCell#10), and Vellum has offered its reputation SDK. A third, CKB Service Runner, is at the design stage and has used CrowdCell’s settlement as an example of a keeper job. Doing these while they are also building is cheaper than doing them later.
  • Someone outside the project has already created a campaign on the testnet app. Dashboards and a creator guide are what the next ones need.

4. Team & Roles

LESFER Ayoub @RickSoze, solo developer

  • Role: everything. Contracts (Rust + ckb-std), transaction builder and indexer (TypeScript), frontend (Next.js + CCC), deployment and testing.
  • Background: senior full-stack developer based in Bordeaux, France, with 6+ years shipping production systems. Currently enterprise SaaS at eMenuChoice, previously API and infrastructure work at BricoPrive. Prior smart contract experience on the Alephium DEX (Ralph, on Alephium’s stateful UTXO model), where I implemented core DEX functionality including a multi-pool swap router. Thinking in inputs and outputs carried over well to CKB; the cell model and ckb-std were learned on top of that. MSc in Computer Science, Université de Bordeaux.
  • Time commitment: part-time next to a full-time job, about 4-5 hours a week, sustained for 30 weeks of public progress reports (see §13).
  • GitHub: alesfer001 (Ayoub Lesfer) · GitHub · Telegram: @RickSoze · X: @crowdcellckb

5. Current Status

Everything below is live on the CKB testnet and open-source.

  • Full campaign lifecycle on-chain: create, pledge, finalize, release or refund, with a receipt cell for every pledge.
  • Automatic settlement: a finalization bot finalizes campaigns after the deadline and releases or refunds every pledge. Anyone else can trigger the same transactions from the campaign page.
  • Verified outcome: the campaign cell carries the on-chain total, and the campaign script only accepts “Funded” or “Unsuccessful” if it matches total pledged versus goal.
  • Fail-safe: about 180 days after the deadline, any unsettled pledge can be sent back to its backer without the campaign cell.
  • Reviewed: Officeyutong (CKB core dev) reviewed the v1.1 contracts. All 6 findings were fixed and redeployed, and the whole exchange is public (see §13). He reviewed the v1.2 contracts again in October and found 5 more issues, which are open and listed in §6.5.
  • Product: CrowdCell brand, landing page with the trust model spelled out, the app at /app, JoyID and other CCC wallets.
  • On the site today: four labelled demo campaigns (two active, one funded and paid out, one unsuccessful and refunded, both settled by the bot with nobody touching them), plus one campaign created by someone outside the project.

Links: live app · GitHub · project thread

6. Application Design

6.1 Functional Overview

  1. Create. A creator publishes a campaign cell with a goal and a deadline block. Neither can be changed afterwards.
  2. Pledge. A backer locks CKB into a pledge cell. The campaign’s on-chain total goes up in the same transaction, and a receipt cell lands in the backer’s wallet.
  3. Finalize. After the deadline, anyone can finalize the campaign. The script checks the status against the on-chain total.
  4. Settle. Anyone can release each pledge to the creator (if funded) or refund it to its backer (if not). The pledge lock rejects any other destination.

On-chain: all of the above. Off-chain: an indexer that reads the chain and serves the frontend, and the bot, which only submits transactions anyone could submit.

6.2 Architecture & Design

Contracts (Rust, ckb-std), five in total: campaign type, campaign lock, pledge type, pledge lock, receipt type. Campaigns reference them by code hash, so nobody can upgrade them under a live campaign.

Off-chain (TypeScript): transaction builder on the CCC SDK, indexer (Express + SQLite) with the finalization bot inside it, Next.js frontend with the CCC connector.

What this proposal adds:

  • Wallet-aware indexer endpoints and two dashboard pages.
  • Categories and search on the campaign list. The category is part of the campaign’s metadata; search runs in the indexer.
  • Creator updates: short posts on a campaign page, signed by the creator’s wallet and stored by the indexer. Off-chain, so they cost the creator nothing and add no risk to funds.
  • A Chinese interface next to the English one.
  • Name and reputation lookups on campaign pages: .cell names through Cellula, and reputation through the Vellum SDK, which reads claims by the creator’s lock. After a campaign is funded and paid out, CrowdCell issues a crowdcell.campaign-funded.v1 claim to the creator from its own did:ckb.
  • Two contract changes, shipped in one redeploy. The pledge lock lets the transaction that releases or refunds a pledge pay a small flat tip to whoever submitted it. The tip stays inside the 1 CKB fee allowance the lock already has, so the pledged amount is untouched. And the campaign script lets the creator finalize a campaign as “Funded” before the deadline once the on-chain total has reached the goal, with the pledge lock allowing release as soon as the campaign is finalized as “Funded”. Finalizing as “Unsuccessful”, and every refund, still has to wait for the deadline.

6.3 Design Rationale

Testnet first. The mechanism works. What nobody knows yet is whether builders want to run campaigns on it, and that can be found out on testnet for a fraction of the cost of an audit.

Identity through existing CKB projects, not a new system. A backer needs something to judge a creator by. .cell names and Vellum already exist, their authors offered to help, and both integrations are off-chain, so they add no risk to funds.

Reputation from real outcomes. A “campaign funded and paid out” claim is issued only after the payout transaction, with the campaign id, goal, total raised, backer count and payout transaction in the payload. It can be checked against the chain by anyone.

A tip instead of a trusted bot. Today release and refund are permissionless but only my bot has a reason to run them. A small tip gives independent operators a reason, and it is what a keeper network such as the planned CKB Service Runner would need to run CrowdCell as a job.

6.4 Fee Model and Sustainability

Not in this proposal. The design from the first proposal is unchanged (a 5% fee paid by the creator, on successful campaigns only, enforced on-chain and sent to a multisig treasury) and it ships with the mainnet proposal, after an audit. On testnet there is nothing to charge.

Running costs during this proposal are zero: the frontend and indexer are on free tiers, and the bot spends test CKB.

6.5 Security Without an Audit

A fair question from the last round: how is this safe without an audit? Short answer: it is on testnet, with test CKB only, and it will not go to mainnet without one. Until then, this is what stands in for it:

  • External review. Officeyutong’s review of the v1.1 contracts found 2 high and 4 medium issues. All 6 are fixed, and the thread is public.
  • A second external review, still open. In October 2026 Officeyutong read the v1.2 contracts and found 5 issues. I checked each against the code and he is right on all of them. The two that matter most: a pledge’s deadline is not checked against its campaign’s, and a campaign that has expired but is not finalized yet can still take pledges. Together they would let someone push a failed campaign to “Funded” on testnet for the cost of fees. Four of the five are small checks. They ship first, before M1, each with a test that reproduces the attack, and they are not billed to this grant. The fifth (pledges after the deadline) needs a design change, because CKB has no “not after” time lock, and it is delivered with the contract change in M4.
  • Internal trust-boundary review before v1.2, which found 3 medium issues. All fixed in the current contracts.
  • A balance accounting test that follows every CKB through a campaign. It caught 4 fund-routing bugs before the September redeploy. They are closed, and the exploit attempts are kept in the repo as tests that must keep failing.
  • Small surface for funds to go wrong. A pledge has two exits, plus the fail-safe back to the backer. No admin key, no upgradable contracts.
  • The contract changes in M4 (tip, pledge window, early finalization) get the same treatment: unit tests, exploit tests, the accounting test, and a request for review on the PR before it is deployed.

An independent audit is the first line of the mainnet proposal.

7. Key Benefits for CKB

  • A crowdfunding platform on CKB. There isn’t one. A launchpad where CKB projects can raise from the community is useful to the ecosystem on its own.
  • A use case for other CKB projects. .cell names get shown where they matter, Vellum gets a partner issuing reputation from real outcomes, and keeper projects such as Service Runner get a paid job they could run.
  • Activity on-chain. Each campaign brings a creator and its backers, and each one produces creation, pledge, finalization and settlement transactions.
  • A reference for the cell model. Custom locks that route funds by outcome, permissionless finalization, an on-chain accumulator with contention retry. All open-source, with the review and fix history public.
  • A cheap test of demand. $5,000 on testnet tells the community whether the audit and mainnet are worth funding next.

8. Detailed Deliverables & Milestones

Milestone Deliverables ETA Budget
M0: Trustless finalization, rebrand, landing page (delivered) On-chain total and script-verified outcome, trust-boundary and fund-routing fixes, testnet redeploy and end-to-end run with JoyID, CrowdCell rebrand, landing page. Live now, see §5. Done $1,500 (30%)
M1: Dashboards and discovery Wallet-aware indexer endpoints. “My campaigns”: status, raised, backers, and the actions available. “My pledges”: status and outcome of each pledge, receipts, and deposits that can be reclaimed. Added: categories and search on the campaign list. Week 4 $1,200 (24%)
M2: Creator identity .cell names for creators and backers, contributed by Cellula in CrowdCell#10 and extended to the dashboards. Vellum reputation shown on campaign pages and cards. crowdcell.campaign-funded.v1 schema published and the claim issued after payout. Week 7 $900 (18%)
M3: Creator tooling and first real campaigns Campaign pages with link previews for sharing, a creator guide, and mobile QA. Added: creator updates on campaign pages, and a Chinese interface. Goal: at least 3 campaigns on testnet run by people outside the project, with the result reported in this thread. Week 9 $600 (12%)
M4: Keeper tip, pledge window and early finalization Tip on release and refund in the pledge lock, the fix for pledges after the deadline (§6.5), tests, testnet redeploy and end-to-end run, and a standalone keeper script anyone can run. Added: early finalization by the creator once the goal is met, as an option set when the campaign is created, fixed after that and shown on the campaign page. Week 12 $800 (16%)

Total: $5,000 USD, paid in CKB at disbursement. The items marked “added” were added on 2026-10-12 and do not change the total or the dates. M0 is paid on approval since it is already delivered. Each later milestone is paid when it is live on testnet and reported in this thread.

Where each item comes from:

  • Dashboards have been on the roadmap since the MVP and were part of the first proposal.
  • Categories, search, creator updates and early finalization come from the project’s own backlog. They and the Chinese interface were added on 2026-10-12.
  • Making early finalization an option set at creation, so backers know before pledging whether a campaign can close early, was suggested by psawyerberlin (post).
  • .cell names were suggested by LusoCryptoLabs (Cellula), who also wrote the first version (CrowdCell#10). It was reviewed, merged and deployed on 2026-10-13. The work left for this milestone is names on the dashboards, and moving lookups to the indexer so visitors’ browsers don’t contact a third party.
  • The Vellum schema was worked out with truthixify on the Vellum thread.
  • The keeper tip comes out of the Service Runner thread, where psawyerberlin used CrowdCell’s finalization bot as an example of a keeper job and we discussed what a reasonable tip would be. Service Runner itself has no code yet, so the tip is built to work with any keeper.

The ETA is based on the pace of the last 30 weeks of public progress reports.

9. Budget Breakdown

All of it is development time. There is no audit, no marketing spend and no hosting cost in this proposal.

Milestone Line Amount
M0 On-chain total, verified finalization, fixes, redeploy and end-to-end run $900
M0 CrowdCell rebrand and landing page $600
M1 Wallet-aware indexer endpoints $300
M1 Creator dashboard $450
M1 Backer dashboard $450
M1 Categories and search (added) included
M2 .cell names: review of the Cellula PR (done, merged 2026-10-13), dashboards, indexer-side lookup $250
M2 Vellum reputation display $250
M2 Claim schema and issuance after payout $400
M3 Shareable campaign pages $150
M3 Creator guide $150
M3 Mobile QA and fixes $150
M3 Onboarding the first outside campaigns $150
M3 Creator updates (added) included
M3 Chinese interface (added) included
M4 Pledge lock tip, pledge window fix and tests $450
M4 Early finalization and tests (added) included
M4 Testnet redeploy and end-to-end run $200
M4 Standalone keeper script and docs $150
Total $5,000

10. Out-of-Scope / Future Funding Needs

Not part of this proposal. These are planned for a follow-up proposal once there is testnet usage to show:

  • Independent security audit. Scalebit quoted $5,000 for the v1.1 contracts in June. A firm quote for the final contract set will be attached to that proposal.
  • Fee model and treasury. The 5% creator-side fee, its config cell and the multisig treasury.
  • Mainnet launch. Deployment, bot funding, launch announcement.

Further out:

  • Pledging from a Bitcoin wallet through RGB++.
  • Token, governance and DAO custody of the treasury.

11. Risk & Mitigation

  • Nobody outside the project runs a campaign. M3 depends on other people. One outside campaign already exists, and the creator guide and dashboards are there to lower the bar. If three don’t happen by week 9, I’ll report how many did and what held the others back. M3 is paid for the tooling, the guide and the onboarding work, not for the count.
  • Dependencies on Cellula and Vellum. Both are young projects. The integrations fall back cleanly: no name shows the short hash, and no reputation shows nothing. The keeper tip depends on no other project: it works with any keeper, including my own script, whether or not Service Runner ships.
  • Contract changes without an audit (M4). Testnet only, test CKB only, with the checks listed in §6.5. If review turns up a problem I can’t close in the tip or in early finalization, that change stays off and M4 isn’t claimed.
  • Time. I work on this part-time. The estimate comes from what I’ve actually shipped per week over 30 weeks, not from a plan. The items added on 2026-10-12 are small next to the milestones they sit in, and the dates are unchanged. If one of them slips, I’ll say so in the milestone report.
  • Free-tier hosting. The indexer runs on a free tier and is kept awake by a scheduled ping. Fine for testnet; paid hosting belongs to the mainnet proposal.

12. Closing / Call to Action

The first proposal asked the community to fund a mainnet launch on trust. This one asks for a third of that, a good part of it for work that is already live, and the rest for the things that will show whether CrowdCell gets used.

If you have a project you’d like to run a test campaign for, tell me in this thread and I’ll help you set it up. Questions and pushback are welcome too.

Thanks for reading.

13. Supporting Links

31 Likes

I added four things to the proposal at the same $5k and the same dates. Categories and search on the campaign list, creator updates on campaign pages, a Chinese interface, and early finalization once a campaign reaches its goal. They’re marked “added” in sections 8 and 9.

4 Likes

Great to see CrowdCell progressing from a testnet demo toward a practical crowdfunding product on CKB! The smaller $5,000 scope makes sense, and I particularly like the focus on trustless settlement, keeper incentives, and creator tooling.

I’d love to see more testing of independent keeper settlement, especially under concurrent transactions and failure scenarios. Overall, a promising direction for the CKB ecosystem. Looking forward to the next milestones!

3 Likes

Thanks Dang. Agree on the keeper testing. Once there’s a tip in M4, several keepers racing for the same pledges is the normal case. Right now the bot skips a pledge it already has a tx in flight for and retries on the next cycle, but I’ve never run two independent keepers against one campaign. I’ll add a two-keeper test and a kill-mid-cycle one to M4 and post the results here.

2 Likes

Hi @Ayoub_Lesfer,

Reposting my support here, since my first comment ended up in the Service Runner thread.

I created a test campaign on the current version and the app works smoothly, without any bugs on my side. The concept is a very good fit for the CKB cell model: each pledge is its own cell, and the lock only allows release to the creator or refund to the backer. Testnet first, with the audit and mainnet once there’s usage, is the right order.

Thanks for taking the early finalization flag into M4. Set at creation, fixed afterwards and shown on the campaign page is exactly what backers need.

For the two-keeper test you mentioned to @Dangbaty2004: when you ping me about the tip, I’m happy to run one of the two keepers from my own node. That way the test uses a truly independent operator.

Good work, and good luck with the vote!

PSBerlin

1 Like