Spark Program | DID Quickstart Kit — Practical DID Consumption Demo

English
1

Spark Program | DID Quickstart Kit — Practical DID Consumption Demo

Project Name

DID Quickstart Kit — A minimal, annotated reference app for integrating CKB Web5 DIDs into new applications

Team / Individual Profile

Cryptominiacs.

Cryptominiacs is a new team to the CKB ecosystem, but the scope of this proposal is intentionally narrow and matched to that: no new on-chain contracts, no novel cryptography, just composing two pieces of infrastructure that already exist (the DID Toolbox and CCC wallet connector) into a working reference flow. We’ve structured the 4-week timeline around weekly, independently-verifiable milestones precisely because we expect the committee to want to see steady proof of progress rather than take team history on faith. If useful, we’re happy to ship the Week 1 milestone (wallet connect + DID resolution) before the full grant is disbursed, as an additional capability signal.

Problem

The CKB Web5 ecosystem has made significant progress at the infrastructure and production-app layer. The DID Toolbox launched at CKCON25 provides solid primitives, and production deployments like xjdao.xyz, bbs.fans, and the web5fans/modules monorepo demonstrate that CKB-based DIDs work in real applications today.

The gap is not “nothing exists” — it’s that nothing exists at the quickstart layer: a minimal, single-purpose, heavily annotated reference that an outside developer can read in an afternoon and adapt to their own app the same week. Production apps aren’t designed to be copied. A full monorepo like web5fans/modules is comprehensive but carries substantial complexity for a developer whose only goal is to add DID-based identity to one feature in their existing project.

This is the same pattern seen with wallet connection before CCC — the primitives existed, but the “here’s the minimum viable integration” layer was missing. That layer is what lowers the cost of the first adoption decision.

Solution

DID Quickstart Kit is a deliberately minimal open-source reference app and standalone code module demonstrating one complete, real integration path.

A user connects their CKB wallet via CCC and resolves or creates a DID using the existing DID Toolbox. The app then requests a simple verifiable claim — specifically, whether this DID has held a specific Spore for more than N days — verified directly against on-chain Cell data with no off-chain attestation service required. The app verifies the claim client-side and unlocks a gated action, intentionally trivial, because the pattern is the deliverable, not the use case. The verification logic is then packaged as a small, documented, copy-pasteable module other builders can drop into their own apps independently of this demo’s UI.

How this differs from existing projects:

The existing production apps (xjdao.xyz, bbs.fans) are real deployments using CKB DIDs, but they are not builder references — they aren’t designed to be forked as a starting point. The web5fans/modules monorepo is comprehensive and genuinely useful, but its scope means a developer who just wants to add DID login to one feature in their app faces significant reading before they can extract what they need. DID Quickstart Kit is single-purpose, heavily annotated, and designed to be understood and adapted in one sitting. The goal is to be the thing a developer finds first — and then naturally follows deeper into the existing ecosystem.

No new on-chain contracts. No new infrastructure. This composes what already exists into the entry point that makes those existing tools more accessible.

Relevance to the CKB Ecosystem

Serves the named 2026 Eco Fund priority around DID and data sovereignty at the adoption layer — the piece that converts infrastructure into builder usage. Complements rather than duplicates existing work: web5fans/modules is the comprehensive reference; this is the five-minute on-ramp that leads developers there. Lowers the first-adoption decision cost for builders who aren’t already familiar with the CKB DID stack. Fully open source under MIT or Apache-2.0, forkable into the Spark-Program GitHub org per program policy.

Expected Deliverables

  1. Open-source repository with clean, annotated code throughout

  2. Hosted demo app showing the full connect → resolve DID → verify claim → unlock flow on testnet

  3. Standalone verification module, documented and usable independently of the demo UI

  4. README written for an outside developer, explaining the pattern and how to swap in a different claim type

How to Verify

Open the hosted demo, connect a testnet wallet, and walk through the flow — the gate should only unlock on a real verified on-chain claim, not a hardcoded condition. The repo includes sample DID and claim data; reviewers can confirm on explorer nervos organisation that the referenced on-chain data exists and matches what the app displays. The verification module ships with a test script runnable in one command, confirming it accepts valid claims and rejects invalid or forged ones.

Requested Funding

$1,000 USD, requested as 100% CKB.

DID Toolbox integration (connect, resolve) — $350: wiring to existing toolbox and CCC wallet connect.

Claim verification logic and standalone module — $400: core logic packaged for reuse, with test script.

Demo app UI and documentation — $250: end-to-end demo and README.

CKB-equivalent amount finalized at submission per the program’s pricing-snapshot convention. Disbursement follows the standard 20% / 80% split.

Timeline & Milestones: 4 Weeks

Week 1 — Wallet & DID Integration

  • Integrate CCC wallet connect into the demo app shell

  • Wire DID resolution and creation against the existing DID Toolbox

  • Milestone: a connected wallet can resolve or create a DID and display it in the UI

Week 2 — Claim Verification Logic

  • Implement on-chain claim check against live Cell data

  • Write the standalone verification module, decoupled from any UI

  • Write test script confirming valid claims pass and invalid or forged claims fail

  • Milestone: module runs standalone via one command and passes its own tests

Week 3 — End-to-End Demo Flow

  • Wire verification module into the demo UI

  • Build gated content and Verified Holder unlock screen

  • Deploy to Vercel or equivalent on testnet

  • Milestone: reviewer can connect a testnet wallet and see the gate unlock only on a real verified claim

Week 4 — Documentation, Packaging, Buffer

  • Package verification module for standalone reuse with clear install and usage instructions

  • Write README explaining the pattern for outside builders

  • Buffer for committee feedback or fixes

  • Submit completion report with all links and verification instructions

4 Likes
2

I’m not a spark representative but adding this additional information may help..

  • Team / individual profile Add 2–4 sentences about who you are and why you’re the right person to ship this quickly (previous CKB/Web5 work, relevant experience, etc.). Spark evaluates “team capability”.
  • Title format Change to something like: Spark Program | DID Quickstart Kit — Practical DID Consumption Demo
  • To-do / milestone list Your “What to cover” section is fine, but make it more explicit (e.g. Week 1, Week 2… or clear milestones).
7 Likes
3

Thanks for taking the time to write this out, really appreciate it. Updated the title format as suggested, and broke the milestone list into explicit weekly checkpoints so it’s clearer what gets verified when. Working on filling out the team profile properly too — will post an updated version shortly.

4 Likes
4

Hi @Carl,

Glad to see your interest in the Spark Program!

Below are some personal thoughts for your reference before the submission goes to the committee for review. These reflect my own understanding and do not represent the committee’s position.

1. Proposal format:

I noticed you formatted the proposal according to the template—thanks for your diligence. However, your proposal shares similar issues with two other projects (DOB Pattern Studio, CCC vibe-coding Scaffold) and still has a few shortcomings you should address:

  • The budget and timeline sections contain excessive line breaks in multiple places, which clearly makes them harder to read.

Of course, you have already, following community partners’ reminders, added "Spark Program | " to the beginning of the proposal title and appended a detailed “Timeline and Milestones” section at the end of the proposal.

These are all positive moves, but I think you should remove the duplicated parts to ensure the proposal’s rigor.

2. Problem findings that seriously conflict with the facts:

I’m glad you saw and chose to participate in building Web5, but your claim in the proposal that “there is not a single small, replicable reference application demonstrating ordinary end-user flows” is factually inaccurate.

The web5fans ecosystem already has multiple production deployments using CKB-based DIDs in real applications; your suite appears to overlap significantly with these existing tools, and framing it as a “missing reference application” is misleading.

  • xjdao.xyz (a social platform where active users log in via DID, for example ack.web5.xjdao.xyz)
  • bbs.fans (a technology and humanities forum using the Web5 tech stack)
  • web5fans/modules (an open-source monorepo containing a full console demo app, with demo routes at /dids, /keys, /pds)

If you still wish to advance this project, please revise your proposal to explain to the committee and the community the additional value of the project and the core differences from existing projects.

Best of luck,
xingtian

3 Likes
5

Hi xingtian, thank you for taking the time to lay this out so clearly — this is exactly the kind of feedback that improves proposals before they reach the committee.

On the formatting issues: noted, will clean up the line breaks and remove the duplicated sections.

On the factual conflict: this is a fair and important challenge. You’re right that the “no existing reference apps” framing was too broad, and I appreciate you naming the specific projects — xjdao.xyz, bbs.fans, and web5fans/modules are all real counterexamples. I’ll revise the problem statement to be accurate rather than overclaim a gap that doesn’t exist.

I do think there’s still a valid and distinct case for this project, but that case needs to be made honestly against what already exists, not against a vacuum. Will update the proposal accordingly and repost.

Thanks again