Spark Program | Cell Sandbox — A Visual Playground for the CKB Cell Model

DAOs & Funding Spark Program
, ,
1
  1. Project Name
    Cell Sandbox — A Visual Playground for the CKB Cell Model
  2. Team / Individual Profile and Contact Information

  • Name: zynorr

  • Role: Sole developer and maintainer

  • Background: Full-stack engineer with deep experience in TypeScript, React, Next.js, and the CKB ecosystem. Built the entire Cell Sandbox

  • github: zynorr (zynor) · GitHub
    email : [email protected]
    Telegram @zynorlawes

    Project Descr@zynorlawesption

    Problem
    CKB’s Cell model is one of the most powerful parts of the Nervos architecture, but it is also one of the hardest concepts for new developers to understand.

    A developer learning CKB needs to understand several concepts at once:

    • Cells as state containers

    • Capacity as a first-class resource

    • Lock scripts and ownership

    • Type scripts and state constraints

    • Cell data encoding

    • Inputs and outputs in a transaction

    • Cell deps and script execution context

    • Wallet signing and testnet broadcasting

    Today, much of this learning happens through documentation, SDK examples, explorers, and trial-and-error. This creates a high onboarding barrier. New developers often need to read several resources before they can confidently answer simple questions like:

    • What does a Cell contain?

    • What is the difference between an input Cell and an output Cell?

    • How does a transaction consume old Cells and create new Cells?

    • How do lock scripts and type scripts appear inside a real transaction?

    • How does a Cell configuration map back to code?

    The current Cell Sandbox MVP already makes Cells more visual and interactive. However, based on Spark Program committee feedback, the current demo still needs refinement. Even experienced CKB developers can find the interface confusing, and newcomers may not immediately know where to start, which module to use, or how to connect what they see on screen to the actual Cell model.

    For Cell Sandbox to become a strong educational tool, it must not only expose CKB concepts visually; it must guide developers through them clearly.

    Solution
    Cell Sandbox is a browser-based visual learning and prototyping environment for the CKB Cell model.

    The goal is to help developers understand Cells and transactions by interacting with them visually instead of starting directly from code.

    The current MVP already allows users to:

    • Design Cells using visual form fields

    • Edit capacity, lock scripts, type scripts, and data

    • View Cell structure as SVG diagrams

    • Assemble Cells into transactions

    • Estimate capacity and fees

    • Connect JoyID wallet

    • Broadcast transactions to testnet

    • Load Cells from chain by outpoint

    • Export CCC-compatible TypeScript code

    • Switch between Pudge testnet and mainnet

    • Share validated Cell configurations through URLs

    The next Spark phase will refine the MVP into a clearer educational tool focused on three priorities requested by the committee:

    1. Usability

    2. Feature completeness

    3. UI/UX interaction

    Instead of mainly adding more templates or growth metrics, this refined proposal focuses on making the existing tool easier to understand, more complete for real CKB transaction learning, and more accessible to developers using different wallets.

    The main improvements will be:

    • Reorganizing the app into a clearer guided learning flow

    • Adding prominent in-app usage guides

    • Improving labels, empty states, explanations, and error messages

    • Supporting both input and output Cell display after entering a transaction hash

    • Integrating @ckb-ccc/connector-react to support a wider range of wallet connections

    • Improving the UI/UX so the demo feels less confusing and more like a structured educational sandbox

    The intended outcome is that a developer can open Cell Sandbox and quickly understand the Cell model by seeing, loading, inspecting, and interacting with real CKB Cells and transactions.

    Current MVP Status

    The MVP is already live and functional.

    Current functionality includes:

    • Visual Cell designer with capacity, lock script, type script, and data editing

    • Known script registry including Secp256k1, Omnilock, xUDT, Spore, DAO, Cheque, Type ID, and Always Success patterns

    • Cell templates for token, NFT, DAO, authentication, and demo patterns

    • SVG Cell visualization with color-coded structure

    • Data editor with hex, text, and number modes

    • Auto-parsed preview for supported data patterns such as xUDT amounts, DAO blocks, and Spore content

    • Transaction flow builder using React Flow

    • Input/output assignment inside the transaction builder

    • Balance tracking and fee estimation

    • JoyID wallet integration

    • Testnet faucet claiming with status polling

    • Cell loading from chain by outpoint

    • CCC-compatible TypeScript code export

    • Zod-validated shareable URLs

    • Network switching between Pudge testnet and mainnet

    • 14 passing tests and zero type errors
      Repository: GitHub - zynorr/cell-sandbox · GitHub

    How this differs from existing CKB tools

CCC already ships two visual applications: live.ckbccc.com and app.ckbccc.com

Cell Sandbox occupies a different niche:

  • CCC Playground = code-first. Write TypeScript, see the resulting transaction.

  • CCC App = task-first. Select a pre-built operation (e.g., “Send xUDT”), fill parameters.

  • Cell Sandbox = free-form design. Design any cell from scratch by filling fields in a visual form, assemble cells into a transaction with drag-and-drop, visualize the structure as SVG, and export back to CCC-compatible code.

    Cell Sandbox fills the “blank canvas” gap it’s for learning and prototyping when you don’t yet know what you want to build, or when you want to understand how a cell configuration maps to a real transaction before writing any code.

Revised Phase Focus

The committee feedback made it clear that the next phase should focus on making Cell Sandbox an excellent educational tool, not simply a larger feature set.

The revised Spark phase will therefore focus on:

  1. Making the tool easier to use

  2. Making the transaction model more complete

  3. Improving the UI/UX and learning experience

  4. Supporting more wallet connection options

  5. Making tutorials and usage guidance visible inside the app

The project will be scoped around refinement and completeness rather than broad expansion.

Area 1: Usability Improvements

Current issue

The current demo exposes many useful features, but the module structure is not yet clear enough for first-time users. A newcomer may not know whether to begin by designing a Cell, loading a Cell, building a transaction, connecting a wallet, or exporting code.

This weakens the educational value of the tool.

Planned improvement

The app will be reorganized around a clearer guided flow:

  1. Learn what a Cell is

  2. Design or load a Cell

  3. Inspect capacity, lock script, type script, and data

  4. Load or build a transaction

  5. Compare input Cells and output Cells

  6. Connect a wallet

  7. Broadcast or inspect a transaction

  8. Export CCC-compatible code

Implementation details

The usability work will include:

  • A visible “How to Use” entry point in the main interface

  • A guided first-use panel for new users

  • Clearer section names and module grouping

  • Better empty states explaining what to do next

  • Inline explanations for core concepts

  • Short descriptions beside technical fields

  • Tooltips or helper text for capacity, lock scripts, type scripts, data, inputs, outputs, and Cell deps

  • A simple example path that users can follow without prior CKB knowledge

Expected result

A new developer should be able to open Cell Sandbox and understand the first useful action within the first minute.

The experience should feel less like a raw developer demo and more like a guided educational sandbox.

Area 2: Feature Completeness

Current issue

The current demo focuses heavily on designing and displaying output Cells. However, a complete CKB transaction depends on both:

  • Input Cells consumed by the transaction

  • Output Cells created by the transaction

Displaying only output Cells gives an incomplete picture of how CKB transactions work.

Planned improvement: input and output Cell display from tx hash

Cell Sandbox will add support for loading a transaction by transaction hash and displaying both input and output Cells.

A user will be able to paste a Pudge testnet transaction hash and inspect:

  • The input Cells consumed by the transaction

  • The output Cells created by the transaction

  • The capacity values

  • Lock scripts

  • Type scripts

  • Data fields

  • Transaction structure

  • Explorer link for verification

Implementation details

The transaction loader will include:

  • A tx hash input field

  • Fetching transaction details from Pudge testnet

  • Resolving consumed input Cells where possible

  • Rendering input Cells and output Cells separately

  • Clear visual labels for “Inputs” and “Outputs”

  • Explorer links for the loaded transaction

  • Helpful errors when a tx hash is invalid, unavailable, or unsupported

Expected result

This will make Cell Sandbox more complete as an educational tool.

Instead of only showing what a user creates, it will also show how real CKB transactions consume existing Cells and generate new ones. This directly teaches the core mental model of CKB.

Area 3: Wider Wallet Connection Support

Current issue

The current demo only supports JoyID wallet connection. This limits the number of developers who can try the full transaction experience.

Planned improvement

Cell Sandbox will integrate @ckb-ccc/connector-react to support broader wallet connection options through the CCC ecosystem.

Implementation details

The wallet work will include:

  • Adding @ckb-ccc/connector-react

  • Refactoring the wallet connection flow to use the CCC connector interface

  • Preserving JoyID support where possible

  • Adding support for other available CCC-compatible wallet connectors

  • Improving wallet connection states

  • Displaying clear messages when no compatible wallet is available

  • Handling connection, disconnection, unsupported network, and signing errors more clearly

Expected result

Developers will not be limited to JoyID only. They will be able to connect using their preferred supported wallet option, making the tool easier to access and more useful for the wider CKB developer community.

Area 4: UI/UX Refinement

Current issue

The current UI is functional but can be confusing. The user must understand too much before the interface becomes useful.

Planned improvement

The UI will be refined around clarity, learning, and guided interaction.

Area 5: Documentation and Learning Support

Current issue

The existing documentation explains the project, but users need guidance directly where confusion happens: inside the app.

Planned improvement

Cell Sandbox will include both in-app and external learning support.

Deliverables

The documentation work will include:

  • In-app “How to Use” guide

  • Short written walkthrough

  • Updated README

  • Example transaction inspection guide

  • Screenshots or diagrams showing input and output Cell flow

  • Explanation of how Cell Sandbox relates to CCC tools

  • Known limitations section

Expected result

When developers are confused, they should not need to search through external documentation first. They should be able to open help from inside the project and continue learning without leaving the flow.

Expected Deliverables

1. Guided Usability Flow

Reorganize the project into a clearer educational flow.

Includes:

  • Improved module organization

  • Visible “How to Use” guide

  • First-use guidance for newcomers

  • Inline explanations for key CKB concepts

  • Better empty states and next-step prompts

2. Input and Output Cell Display

Add support for loading a transaction by tx hash and displaying both input and output Cells.

Includes:

  • Tx hash input

  • Transaction loading from Pudge testnet

  • Input Cell rendering

  • Output Cell rendering

  • Clear labels distinguishing consumed Cells from created Cells

  • Explorer links for verification

  • Helpful error states

3. Wider Wallet Support

Integrate @ckb-ccc/connector-react.

Includes:

  • Broader wallet connector support

  • Improved wallet connection UI

  • Clear connection/disconnection states

  • Better unsupported wallet and network messaging

  • Continued support for the existing wallet flow where compatible

4. UI/UX Polish

The current Cell Sandbox MVP is functional, but the interface still feels like a raw tool surface. New users can see many actions at once, such as creating Cells, loading by outpoint, opening templates, switching to Tx Flow, exporting code, and connecting JoyID, but the app does not clearly explain where to start or how these actions relate to the CKB Cell model.

This phase will reorganize the interface into a clearer educational workflow.

The revised UI will be structured around four modes:

1**. Learn**
A short in-app guide explaining Cells, capacity, lock scripts, type scripts, data, inputs, and outputs.

  1. Design Cells
    A clearer version of the existing Cell designer, with the visual Cell canvas at the center and an inspector for capacity, lock script, type script, and data.

  2. Inspect Tx
    A transaction inspection view where users can paste a Pudge tx hash and see both **Input Cells Consumed** and **Output Cells Created**.

4**. Build Tx**
The existing transaction builder, positioned after users understand how Cells and transactions work.

Planned UI/UX work includes:

  • Adding a visible Start here/ Guide entry point in the first screen
  • Separating Cell design from transaction inspection
  • Replacing vague transaction loading with a dedicated tx hash inspection screen
  • Showing input Cells and output Cells side by side
  • Adding short helper text for capacity, lock scripts, type scripts, data, and Cell deps
  • Moving wallet status into a clearer wallet connection area
  • Supporting connector-based wallet selection through `@ckb-ccc/connector-react`
  • Adding useful empty, loading, invalid hash, and partially resolved transaction states
  • Improving mobile layout with Learn / Design / Tx / Wallet tabs
  • Keeping raw technical fields available for advanced users while making the first-use path clearer

A design draft has been prepared to make this work reviewable before implementation. It includes:

  • Current live UI audit
  • current vs proposed main workspace
  • Transaction inspection screen
  • Input Cells Consumed vs Output Cells Created view
  • Wallet connector flow
  • Loading and error states
  • Mobile layout

Design artifact:

-design image: cell-sandbox/docs/cell-sandbox-ui-ux.png at main · zynorr/cell-sandbox · GitHub

5. Documentation and Tutorial Updates

Add usage support inside and outside the app.

Includes:

  • In-app guide

  • Updated README

  • Written walkthrough

  • Example tx hash guide

  • Screenshots or diagrams

  • Final report

How to Verify

All deliverables will be verifiable through the live demo, repository, README, and Pudge testnet explorer.

1. Guided Usability Flow

Reviewer steps:

  1. Open the live demo.

  2. Confirm there is a prominent “How to Use” or guide entry point.

  3. Confirm the app provides a clearer path for designing/loading Cells, inspecting transactions, connecting wallets, and exporting code.

  4. Confirm empty states and helper text explain what the user should do next.

Verification proof:

  • Updated live demo

  • README screenshots

  • In-app guide available in the UI

2. Input and Output Cell Display

Reviewer steps:

  1. Open the transaction loader in Cell Sandbox.

  2. Paste the provided Pudge testnet transaction hash from the README.

  3. Confirm the app displays both input Cells and output Cells.

  4. Confirm input Cells and output Cells are clearly labeled.

  5. Open the linked transaction in the Nervos explorer and verify the transaction data.

Verification proof:

  • Example tx hash in README

  • Explorer link in README

  • Input/output Cell display in the live demo

3. Wider Wallet Support

Reviewer steps:

  1. Open the wallet connection interface.

  2. Confirm that wallet support is not limited to JoyID only.

  3. Confirm wallet options are exposed through the CCC connector flow.

  4. Test connection with an available supported wallet.

  5. Confirm unsupported wallet or connection failure states are handled clearly.

Verification proof:

  • Updated wallet connection UI

  • Code integration using @ckb-ccc/connector-react

  • README notes on supported wallet flow

4. UI/UX Refinement

Reviewer steps:

  1. Open the live demo.

  2. Review the updated layout.

  3. Confirm the main modules are easier to understand.

  4. Confirm input/output Cell visualization is clearer.

  5. Confirm loading, empty, and error states are present.

  6. Test on desktop and mobile viewport.

Verification proof:

  • Updated live demo

  • Screenshots in README or final report

  • Responsive layout improvements in the repository

5. Documentation

Reviewer steps:

  1. Open the README.

  2. Confirm it explains the revised project flow.

  3. Confirm it includes an example tx hash.

  4. Confirm it explains input and output Cells.

  5. Confirm the app includes prominent help content.

Verification proof:

  • Updated README

  • In-app guide

  • Written walkthrough

  • Final report

Required Funding

Total request: $750

This revised request narrows the Spark phase toward usability, feature completeness, and UI/UX refinement.

This budget reflects a focused improvement phase rather than a broad feature expansion phase.

Budget Breakdown

Development and UI/UX Refinement — $600

Covers implementation of:

  • Guided usability flow

  • Module reorganization

  • In-app usage guide

  • Inline educational explanations

  • Transaction loading by tx hash

  • Input and output Cell display

  • @ckb-ccc/connector-react integration

  • Wallet connection UI improvements

  • Error/loading/empty state improvements

  • Responsive UI polish

  • README updates

  • Testing and final cleanup

Documentation and Final Report — $150

Covers:

  • Written walkthrough

  • Updated README

  • Example transaction inspection guide

  • Screenshots or diagrams

  • Final report preparation

  • Summary of completed usability, feature completeness, and UI/UX improvements

Milestones

Milestone 1 — Usability and Educational Flow

Timeline: Weeks 1–2

Goal: Make the app easier to understand and easier to use for new developers.

Tasks:

  • Reorganize the main app flow around learning and inspection

  • Add a prominent in-app “How to Use” guide

  • Add inline explanations for core Cell model concepts

  • Improve empty states and next-step prompts

  • Improve labels around capacity, lock scripts, type scripts, data, inputs, outputs, and Cell deps

  • Update README with the revised learning flow

Completion criteria:

  • Live demo has a clearer guided flow

  • “How to Use” guide is visible in the interface

  • New users are guided toward the first useful action

  • README reflects the new app structure

Milestone 2 — Input and Output Cell Transaction Viewer

Timeline: Weeks 3–4

Goal: Make Cell Sandbox more complete by showing both sides of a CKB transaction.

Tasks:

  • Add transaction hash input

  • Fetch transaction data from Pudge testnet

  • Resolve and display input Cells

  • Display output Cells

  • Clearly distinguish consumed Cells from created Cells

  • Add explorer links

  • Add useful error messages for invalid or unsupported tx hashes

  • Add example tx hash to README

Completion criteria:

  • Reviewer can paste a tx hash and inspect both input and output Cells

  • Input and output Cells are clearly labeled

  • README includes a reproducible example

  • Explorer link confirms the transaction

Milestone 3 — Wallet Support and UI/UX Polish

Timeline: Weeks 5–6

Goal: Improve accessibility and finish the demo as a polished educational tool.

Tasks:

  • Integrate @ckb-ccc/connector-react

  • Add broader wallet connection support

  • Improve wallet connection UI and states

  • Improve loading, error, and unsupported-wallet messages

  • Polish layout and responsive behavior

  • Improve transaction visualization clarity

  • Final testing and cleanup

  • Prepare final report

Completion criteria:

  • Wallet connection is not limited to JoyID only

  • App has clearer wallet states

  • UI is easier to navigate

  • Final report is submitted with screenshots, links, and summary of completed work

Estimated Completion Time

6 weeks

The work is achievable in this timeframe because the MVP architecture, core components, transaction builder, wallet flow, deployment pipeline, and repository are already in place.

The Spark phase will refine and extend existing systems rather than building the product from scratch.

Clear To-do List

Weeks 1–2: Usability

  • Reorganize modules into a clearer learning flow

  • Add in-app “How to Use” guide

  • Add inline helper text for CKB concepts

  • Improve labels and empty states

  • Improve README usage flow

Weeks 3–4: Feature Completeness

  • Add tx hash loader

  • Fetch transaction details from Pudge testnet

  • Display input Cells

  • Display output Cells

  • Add explorer links

  • Add example tx hash to README

  • Improve transaction loading error states

Weeks 5–6: Wallet and UI/UX Polish

  • Integrate @ckb-ccc/connector-react

  • Add broader wallet connection options

  • Improve wallet connection UI

  • Improve loading and error states

  • Polish responsive layout

  • Improve transaction visualization

  • Prepare final report

Relevance to the CKB Ecosystem

Cell Sandbox addresses a real onboarding problem in the CKB ecosystem.

The Cell model is central to CKB, but it is unfamiliar to many developers coming from account-based blockchains. A developer may understand smart contracts on EVM but still struggle to understand how CKB represents state, ownership, and transitions through Cells.

Cell Sandbox helps solve this by making the Cell model visible and interactive.

Developer onboarding

A new developer can use Cell Sandbox to:

  • See the structure of a Cell

  • Understand capacity

  • Inspect lock scripts and type scripts

  • Load real transactions

  • Compare input and output Cells

  • Understand how transactions consume and create state

  • Connect a wallet

  • Export CCC-compatible TypeScript code

This lowers the learning barrier and creates a more practical path from concept to code.

Educational value

The revised project focus is directly aligned with the committee’s feedback: making Cell Sandbox an excellent educational tool.

Instead of only showing forms and diagrams, the improved version will guide developers through the concepts step by step. The app will explain what the user is seeing, what to do next, and how each part connects to the real CKB transaction model.

Technical alignment

Cell Sandbox uses CKB’s architecture directly:

  • Cells as programmable state

  • Capacity as an explicit resource

  • Lock scripts for ownership

  • Type scripts for constraints

  • Inputs and outputs as the basis of transaction state transitions

  • CCC-compatible code export

  • CCC wallet connector integration

  • Pudge testnet verification

This makes the project not only a learning tool, but also a practical reference for how modern CKB frontend tooling can be built.

Relationship to CCC

Cell Sandbox complements CCC rather than competing with it.

CCC provides strong SDK tooling, a code-first playground, and task-first demos. Cell Sandbox adds a design-first layer that helps developers understand the Cell model visually before moving into code.

The flow is:

Visual learning → Cell design → transaction inspection → CCC-compatible code

This makes Cell Sandbox a bridge between conceptual onboarding and real CKB development.

Reporting Approach

The committee has clarified that hard reporting metrics are less important than usability, feature completeness, and UI/UX quality.

The final report will therefore focus on the quality of the refinement work.

The report will include:

  • Summary of usability improvements completed

  • Before/after screenshots of the interface

  • Link to the updated live demo

  • Link to the updated repository

  • Example Pudge testnet tx hash used for input/output Cell inspection

  • Explanation of the input/output Cell viewer

  • Wallet connector integration summary

  • Documentation and in-app guide links

  • Known limitations

  • Future improvement ideas

  • Any available usage data from Vercel Analytics or anonymous app events, if available

Possible usage data may include:

  • Unique visitors

  • Number of transaction hashes inspected

  • Number of template loads

  • Number of wallet connection attempts

  • Number of testnet transactions broadcast through the tool

These metrics will be treated as supporting context, not the main success condition.

The main success condition is whether Cell Sandbox becomes clearer, more complete, and more useful as an educational tool for understanding the CKB Cell model.

Final Outcome

At the end of this Spark phase, Cell Sandbox should be a more polished and complete educational sandbox for CKB developers.

A reviewer or new developer should be able to:

  1. Open the live demo

  2. Understand where to start

  3. Read a visible usage guide

  4. Design or inspect a Cell

  5. Load a real transaction by tx hash

  6. View both input and output Cells

  7. Understand how Cells move through a transaction

  8. Connect using a broader CCC wallet flow

  9. Export CCC-compatible code

  10. Use the project as a practical learning tool for the CKB Cell model

This refined scope directly addresses the committee’s feedback and focuses the $750 Spark budget on making Cell Sandbox an excellent educational tool for the CKB ecosystem.

7 Likes
CKB Ecosystem Biweekly Update
Spark Program Q2 2026: What the Ecosystem Is Building
CKB Ecosystem Biweekly Update
CKB Ecosystem Biweekly Update
2

Hey Zynor, welcome to the CKB ecosystem, and thanks for your interest in Spark! A few personal thoughts before this goes to the committee meeting. These are my own read, not the committee’s position. I went through the repo and the live build, I genuinely like it. A few things I’d tighten so the review goes smoothly:

  1. Get ahead of the “how is this different from CCC?” question, it will come up. The proposal says there’s “no existing browser-based visual tool,” and that might not be quite accurate. CCC already ships two hosted visual apps: live.ckbccc.com (the code-first playground that renders a tx/cell visually) and app.ckbccc.com (the form-based demo for transfer, xUDT, Spore, DAO, etc.). The potential and honest framing: CCC’s playground is code-first (write TS, see the tx) and its demo is task-first (pre-built flows), while Cell Sandbox lets you design an arbitrary cell from scratch by filling fields, drop it into a transaction, and export it back to CCC code. That no-code, free-form, design→code direction is your real wedge, name it explicitly and the proposal gets stronger.

  2. Please add a “How to Verify” section, it’s a required field for 2026 applications. For your project it’s easy: state that each new template produces a valid transaction on Pudge testnet and give the tx hash / outpoint, so a reviewer can open the explorer and confirm. Same idea for script-hash computation and multi-input. Low-cost and reproducible, which is exactly the point of the requirement.

  3. Two different demo URLs in the post (cell-sandbox-seven.vercel.app and cell-sandbox-m.vercel.app). Pick one and make it consistent, a reviewer trying to verify shouldn’t have to guess which is live.

  4. For the final report, please commit to concrete metrics up front (e.g. testnet txs sent through the tool, or unique users) instead of vague items.

Revising these will make the committee conversation a lot smoother. Looking forward to your adjusted proposal.

Best,

4 Likes
3

Hi ,
Thanks for the thoughtful review. I’ve revised the proposal based on your feedback. Here’s a summary of the changes:

  1. Differentiation from CCC
    Added a new section explicitly naming the two CCC tools ( live.ckbccc.com and app.ckbccc.com ) and clearly positioning Cell Sandbox’s niche: free-form, no-code cell design — the exploratory “blank canvas” gap. CCC is code-first and task-first; Cell Sandbox is design-first. The full revised framing is in the proposal.
  2. “How to Verify” Section
    Added the required section with a table mapping each deliverable to its verifiable proof testnet tx hashes, outpoints, screenshots, and explorer links. Each new template, the multi-input feature, and the script hash display all have specific verification steps.
  3. Consistent Demo URL
    Fixed — the canonical URL is demo (matches the README). it’s been corrected throughout.
  4. Concrete Final Report Metrics
    Replaced vague items with specific, measurable targets:
  • 50+ testnet transactions sent through the tool
  • 200+ unique users (Vercel Analytics)
  • 20+ new GitHub stars
  • 100+ template loads (anonymous tracking)
  • 500+ x post views, 200+ tutorial views
  • Test suite expanded from 14 → 25+ passing tests
5 Likes
4

Hi Zynor, thanks for your efforts! The committee will provide a review outcome after the meeting next week

3 Likes
5

Hi @zynor，

感谢你在提案优化时的积极反应。

经 Spark Program 委员会审核，该项目当前状态定为 Pending。原因不是否定方向，而是希望你能做到更好——委员会认为 Cell Sandbox 具有创新性，如果进一步打磨，有机会打造成一个面向开发者的优秀教育工具，帮助开发者快速理解 Cell 模型，这对扩大 CKB 的开发者人群有积极意义。因此，委员会愿意支持这个项目通过 Spark 进一步开发打磨。

但现阶段提案在以下方面需要进一步完善，才能进入正式资助流程：

1. 易用性方面
对于现有的 Demo 来说，即便是资深的 CKB 开发者使用起来也充满疑惑，对于新手开发者更是不知所措。为了让开发者能快速上手理解 Cell 模型，建议：
对目前的功能模块做更合理的规划
对 UI/UX 做更细致的打磨
配套的使用指南应在项目显眼位置放置，以便当开发者不知道如何使用时能快速阅览帮助教程

2. 功能完整性方面
2.1 应支持显示输入和输出的 Cells：目前的 Demo 只显示了输出的 Cell，但对于一个完整的 CKB 交易来说，输入和输出都是必备的，只有输出是不完整的。需支持输入一个 txhash 后，加载出 input、output 的 cells。
2.2 应支持更广泛的钱包进行连接：目前的 Demo 只支持 JoyID 连接，这大大限制了开发者的使用范围。建议集成 @ckb-ccc/connector-react 库，以便让开发者方便地使用自己习惯的钱包来体验。

关于报告指标
委员会对提案里提到的报告指标不做硬性要求，但对项目的易用性、功能完整性、UI/UX 交互方面有更高的预期。请在完善时重点围绕上述三个维度展开。

关于预算
根据当前项目的状态综合考虑后，委员会认为750美元的预算是合理的。这并非是否定你工作的价值，而是希望你在Spark期间专注于完善和优化Demo，聚焦实现“优秀教育工具”的目标。

下一步要求
请你基于上述反馈，对提案进行更新，重点说明你将如何在易用性、功能完整性和 UI/UX 三个方面进行改进，并相应调整项目计划和预算需求。更新后在本帖 @我，回复"已更新"，并说明修改了哪些章节 / 新增了哪些链接或附件，我们会在信息齐备后继续正式评审流程。

祝好
行天
代表 Spark Program 委员会

4 Likes
6

Hi @xingtianchunyan,

Updated.

Thank you again for the committee’s detailed feedback. I’ve revised the proposal to focus directly on the three areas highlighted: usability, feature completeness, and UI/UX refinement.

Sections revised:

  1. Project Description
    Reframed the proposal from broad feature expansion into a focused refinement phase aimed at making Cell Sandbox an excellent educational tool for developers learning the CKB Cell model.

  2. Problem Statement
    Updated the problem to clearly explain that the current MVP is functional, but the main issue is user confusion, especially for newcomers trying to understand where to start and how Cells relate to complete transactions.

  3. Solution
    Revised the solution around a guided learning experience, with clearer app flow, prominent usage guidance, input/output Cell inspection, broader wallet support, and improved UI/UX.

  4. Revised Spark Phase Focus
    Added a new section explaining that this phase will focus on usability, feature completeness, and UI/UX instead of simply adding more templates or growth metrics.

  5. Usability Improvements
    Added a detailed plan for reorganizing the app flow, adding an in-app “How to Use” guide, improving empty states, adding inline explanations, and making the first-use experience easier for newcomers.

  6. Feature Completeness
    Updated the scope to include loading a transaction by tx hash and displaying both input Cells and output Cells, so users can understand complete CKB transactions instead of only seeing outputs.

  7. Wallet Support
    Added the plan to integrate @ckb-ccc/connector-react so the demo is not limited to JoyID and can support a wider range of CKB wallet connections.

  8. UI/UX Refinement
    Expanded the UI/UX section with planned improvements to layout, module grouping, visual hierarchy, transaction visualization, loading states, error states, labels, helper text, and responsive behavior.

  9. Expected Deliverables
    Reworked the deliverables around guided usability flow, input/output Cell display, wider wallet support, UI/UX polish, and documentation/tutorial updates.

  10. How to Verify
    Updated the verification section so reviewers can confirm the work through the live demo, README, Pudge testnet tx hash examples, input/output Cell display, wallet connector UI, and explorer links.

  11. Required Funding
    Adjusted the budget from $1,500 to $750 as recommended by the committee.

  12. Milestones
    Updated the milestone plan into a focused 6-week refinement roadmap covering usability, transaction inspection, wallet support, UI/UX polish, documentation, and final reporting.

  13. Reporting Approach
    Revised the reporting section to focus less on hard growth metrics and more on usability improvements, feature completeness, UI/UX quality, screenshots, demo links, transaction inspection examples, wallet integration, and known limitations.

The revised proposal now directly reflects the committee’s guidance and narrows the Spark phase toward improving Cell Sandbox into a clearer, more complete educational tool.

4 Likes
7

Hi, @zz_tovarishch @xingtianchunyan
Just following up, haven’t received feedback yet and wanted to check if there are any updates. Thanks!

1 Like
8

Hi @zynor，

感谢你对 Spark Program 的持续关注和对 Cell Sandbox 的修订。

经 Spark Program 委员会审核，你的提案当前状态定为 Pending。

委员会认可 Cell Sandbox 的创新潜力，同时也注意到你在修订中对功能部分做了实质性改进：补充了 input/output Cell 显示支持、计划集成 @ckb-ccc/connector-react 扩展钱包连接选项、以及使用指南的放置规划——这些方向都是对的。

但此次修订中，UI/UX 部分的内容仍然不足以让委员会做出负责任的资助决定。以下是详细反馈：

Pending 原因：UI/UX 描述过于抽象，缺乏可验证的具体设计

在修订后的提案中，UI/UX 优化部分大量使用"更简洁"、“更好的”、“更合理的规划”、"更细致的打磨"等模糊表达。例如：

  • “对目前的功能模块做更合理的规划”——合理具体指什么？当前布局是什么问题？优化后的布局是什么样的？
  • “对 UI/UX 做更细致的打磨”——打磨的具体内容是什么？颜色、间距、交互流程、信息层级？当前哪里不好？优化后应该达到什么标准？
  • “在显眼位置放置使用指南”——显眼位置是哪里？使用指南的形式是什么（悬浮提示？侧边栏？独立页面）？

这些表述对于委员会评审来说无法回答一个核心问题：最终社区将看到一个什么样的界面？

委员会邀请你对以下内容进行补充

请补充一份静态 UI/UX 设计稿（wireframes 或 mockups），让委员会能在不阅读代码的情况下，看到你计划建造的东西长什么样。

设计稿可以是：

  • Figma 链接
  • 手绘线框图的照片/扫描件
  • 简单的图形工具绘制稿（如 Excalidraw、Whimsical）
  • 甚至是在现有 UI 截图上用标注说明改动点

核心主张是可视化加速开发者快速理解，而合适的UI/UX是关键一环，设计稿本身就是项目能力的预演。

下一步

请补充静态 UI/UX 设计稿后，在本帖 @我 并说明更新内容。委员会将在收到后尽快评审。

Best，
行天春彦
代表 Spark Program 委员会

2 Likes
9

Hi @xingtianchunyan,

Thank you for the clear feedback.

I understand the remaining issue: the UI/UX section was still too abstract and did not show what the community would actually see after the proposed changes.

I have now added a concrete UI/UX design draft as requested by the committee.

Excalidraw image:

The design draft compares the current live MVP with the proposed interface structure. It is intended to be reviewable without reading code.

It covers:

  1. Current UI issues visible in the live app
  2. current vs proposed main workspace
  3. Separate modes for Learn, Design Cells, Inspect Tx, and Build Tx
  4. Full transaction inspection by tx hash
  5. Separate Input Cells Consumed and Output Cells Created sections
  6. Connector-based wallet flow using `@ckb-ccc/connector-react`
  7. Empty, loading, invalid hash, and partially resolved transaction states
  8. Mobile layout preserving the same Learn / Design / Tx / Wallet model

I also updated the proposal’s UI/UX section to be more specific. Instead of only saying “cleaner layout” or “better visual hierarchy,” it now explains the planned structure, the concrete screens, and the exact states that will be implemented.

This should make the proposed UI concrete enough to review before implementation.

1 Like
10

Hi @zynor,

Thank you for your positive response. After review by the Spark Program Committee, your proposal is currently in Pending status. This is not a rejection but rather additional questions that need to be confirmed.

The committee would like to learn more about the wallet connection part:

1. About the wallet selector UI

The committee noted that you did not directly use the garage selector component provided by @ckb-ccc/connector-react, but instead implemented your own UI. We would like to understand the considerations behind this—whether the CCC selector does not meet your needs in terms of interaction or visuals, or if there are other technical reasons?

2. Support for CKBull

CKBull currently does not seem to have a browser extension wallet. If Cell Sandbox needs to integrate with CKBull, what specific plan is there for wallet connection and transaction signing? Is it through QR code scanning? Or other methods?

If you don’t have a clear implementation plan for this issue, you can consider removing CKBull first. The reason is: the core value of Cell Sandbox lies in the visual interactive experience of Cell Model. Wallet connection is just an entry point. Adding support for CKBull has no substantial impact on the demonstration effect of the tool and may instead confuse users when selecting a wallet (why does this wallet’s connection method differ from others?), becoming a point of cognitive hindrance.

In summary, the committee believes that as an educational tool for a Cell, using the default connector recommended by CCC here in Connect Wallet is sufficient—it supports enough wallets and lock types to cover most scenarios developers use. Focus your efforts on the visual interactive aspects of the Cell, that is the core value of this tool.

Anticipating your reply

Best wishes
xingtian
On behalf of the Spark Program Committee

1 Like
11

Hi @xingtianchunyan,

Thank you for the clarification. I agree with the committee’s point.

Regarding the wallet selector UI: the custom UI in the current MVP was mainly
built because the first version only supported JoyID and needed a small
connection/status area inside the existing sidebar. It was not because the
@ckb-ccc/connector-react selector is unsuitable, and there is no technical
reason that requires Cell Sandbox to replace the default CCC wallet selector.

As part of Milestone 1: Usability and Educational Flow, I will revise this
plan and align the wallet entry point with the default connector flow
recommended by @ckb-ccc/connector-react. Any custom UI will only be used for
surrounding educational context, connection status, and layout consistency,
not for replacing the core wallet selection logic.

Regarding CKBull: I agree that it should be removed from the current scope.
Since CKBull does not currently provide a browser extension wallet, I do not
have a clear and reliable implementation plan for browser-based connection and
signing at this stage. Adding a separate QR-code or special signing flow would
increase cognitive load and distract from the project’s main value, which is
visual Cell model learning and transaction inspection.

I will revise Milestone 1 and the related wallet/UI sections accordingly:

  • Use the default @ckb-ccc/connector-react wallet selector flow
  • Preserve JoyID support where available through the CCC connector ecosystem
  • Remove CKBull from the current deliverables
  • Treat future CKBull/mobile-wallet support as out of scope unless there is a
    clear CCC-compatible connection and signing path
  • Keep the main focus on guided learning, Cell visualization, transaction
    inspection, and UI/UX clarity
4 Likes
12

Hi @zynor,

We are pleased to inform you that the Spark Program Committee has approved the Cell Sandbox proposal, with a funding amount of 750 USD (100% paid in CKB, 1 CKB = 0.00095 USD, 789,474 CKB).

The committee recognizes the value of Cell Sandbox as an interactive educational tool that lowers the onboarding barrier for developers learning the CKB Cell model. Your MVP already demonstrates strong technical execution, and the refined focus on usability, feature completeness, and UI/UX interaction aligns well with the committee’s expectations for a practical developer tool.

Here are the next steps:

  1. Funding & Wallet Address

    The total grant is 750 USD (for the current cycle Spark grants are paid 100% in CKB).

    • The first installment (20%) equivalent to 157,895 CKB will be disbursed as soon as possible.
    • Please provide the CKB wallet address to receive the funds.
    • The remaining 80% is flexible: it can be requested during weekly syncs as needed or claimed upon project completion.

  2. Weekly Sync

    We would like to establish a regular weekly synchronization mechanism, with two options:

    • Text-based updates in this post, with progress updates at a fixed time each week and committee feedback in reply.
    • Or a brief video call.
      Please let us know your preference and a convenient time.

  3. Proposal Content Lock

    Once a proposal is approved, we will lock the current version of the proposal post as the reference baseline for subsequent delivery and acceptance. This is standard procedure for all approved Spark projects. If adjustments are needed during development, they can be discussed and documented during the weekly syncs.

Congratulations again, and we look forward to working together!

I also apologize for wasting your valuable time. Due to unstable VPN connectivity recently, I was unable to release this announcement in a timely manner. I hope for your understanding and forgiveness.

Best,
xingtian
On behalf of Spark Program Committee

3 Likes
13

Thank you for the approval and for the thoughtful feedback throughout the review process. I really appreciate the committee’s guidance in helping refine the proposal and align it with the goals of the Spark Program.l

I’m excited to move forward with Cell Sandbox and will keep the project aligned with the approved scope.

For the weekly check-ins, I prefer posting progress updates in this forum thread, as it provides a transparent record of development and allows the community to follow along with the project’s progress.

My CKB address for the initial disbursement is:

ckb1qyqqyxgc0n32uzj5kgpqm5p6ndd67v76rajsspv775

Thank you again for your support. I look forward to sharing regular updates over the coming weeks and delivering the planned improvements.

2 Likes
14

Hi @zynor ,

The first installment has been disbursed.

Transaction Hash: 0xb11d48918d809bb298907abaa2c5862d1abc9acab8c1bd7265f11cf902a1691d

Please confirm once received.

Looking forward to your first progress update.

Best,
xingtian
On behalf of the Spark Program Committee

15

Received

1 Like
16

Weekly Sync: Milestone 1 Progress Update

Hi everyone,

This week I worked on the Milestone 1 flow for Cell Sandbox and pushed the latest updates for review.

Live demo:

Repository:

Merged PR:

What i Worked On

Milestone 1 is focused on making Cell Sandbox easier to understand as a visual playground for the CKB Cell model.

The current flow is:

Learn → Design Cells → Inspect Tx → Build Tx

Updates So Far

  • Added a Learn view to introduce the Cell model before users start editing fields.
  • Added a How to Use guide and Start Here panel.
  • Improved wording around CKB concepts:
    • Cells as state containers
    • Capacity as storage limit and CKB amount in shannons
    • Lock scripts as ownership/spending rules
    • Type scripts as optional state-transition rules
    • Transactions consuming live input Cells and creating new output Cells
  • Added a transaction inspector for full transaction hashes.
  • Improved the Build Tx page so users understand that designed Cells are local drafts until they are marked as Outputs.
  • Clarified that wallet inputs are supplied automatically when sending.
  • Fixed faucet response handling and wallet balance refresh behavior.
  • Improved Build Tx scrolling and responsive layout.
  • Added README screenshots and a reviewer walkthrough.

Suggested Review Flow

  1. Open the live demo.
  2. Start from Learn and read the Cell model explanation.
  3. Move to Design Cells and inspect or edit a Cell.
  4. Open Inspect Tx and load the sample transaction.
  5. Move to Build Tx.
  6. Click Output under a designed Cell.
  7. Check whether the transaction flow and wallet/send explanation feel clear.

Verification

So far, I have verified locally with:

  • TypeScript check
  • ESLint
  • Vitest test suite
  • Next.js production build
  • Desktop and mobile walkthroughs

Feedback Welcome

I would appreciate feedback on whether the Milestone 1 flow feels clear enough for new CKB developers, especially around the transition from designing a local Cell to marking it as a transaction output.

Next, I plan to continue with wallet selector work and further refine the wallet/send experience based on feedback.

2 Likes
CKB Ecosystem Biweekly Update
17

Hi @zynor ,

The committee has noted that there has been a period without progress updates recently.

Since these projects are still ongoing, timely progress reports help the committee and the community track development.

If there are obstacles or a need to delay, please communicate openly so we can understand the situation and provide assistance where possible.

We look forward to your prompt response.

Best,
xingtian
On behalf of the Spark Program Committee

1 Like
18

Hi everyone,

This week I focused on improving the Cell Sandbox wallet flow, Build Tx experience, and alignment with current CKB documentation.

Live demo:
https://cell-sandbox-m.vercel.app/

Repository:
https://github.com/zynorr/cell-sandbox

Commits:

What I Worked On

  • Added the CCC wallet selector with JoyID, MetaMask, OKX Wallet, UniSat, and UTXO Global.

  • Clarified that designed Cells are local drafts until marked as transaction outputs.

  • Improved Build Tx to show wallet-selected inputs, fees calculated during signing, and change returned to the wallet.

  • Added stricter validation and separated lock-script and type-script presets.

  • Updated CKB terminology across Learn, Design, Inspect, and Build.

  • Made CKB Transfer and fresh DAO Deposit buildable.

  • Marked xUDT, Spore, Omnilock, and Always Success as design-only.

  • Corrected DAO data and cell dependencies, xUDT amount decoding, and Spore Molecule decoding.

Transaction Inspector

The inspector now resolves previous input Cells, recognizes cellbase inputs, handles DAO capacity exceptions, and uses exact capacity and fee calculations. It also includes reproducible cellbase and multi-input Pudge examples.

Documentation

I rewrote the README and added fresh screenshots for Learn, Design Cells, Inspect Tx, and Build Tx.

Verification

The current version passes TypeScript, ESLint, 104 Vitest tests, the Next.js production build, wallet selector testing, and a manual Learn-to-Build walkthrough.

I would appreciate feedback on whether the transition from designing a Cell to marking it as an output is clear, and whether wallet funding and design-only templates are explained well enough.

Next, I plan to test another complete signed Pudge transaction and continue refining mobile and wallet error states.

19

Based on the completion of Milestones 1 and 2, together with the core wallet and UI/UX work from Milestone 3, I would like to request an additional 60% of the approved grant.

This is equivalent 473,684 CKB at the approved conversion rate.

This would bring total disbursement to 80% of the grant. The final 20% can remain pending until I complete the remaining final testing and submit the final report with screenshots, links, verification results, and a summary of all deliverables.

20

Hi @zynor，

我是 Spark Program 委员会成员 Yixiu。我最近体验了 Cell Sandbox 的最新版本，发现以下几个问题，先同步给你和委员会同事参考：

1. UI/UX 未见实质改善

立项时委员会两次（6/3、6/17）指出界面混乱、新手难以上手，要求重新规划并打磨。但目前 Learn 页面依然是"概念说明卡片"和"完整可编辑表单"（Capacity/Lock Script/Type Script/Output Data 等原始字段）堆在同一屏，Learn / Design Cells / Build Tx 三个 tab 的信息密度几乎没有差异，没有看到真正的渐进式披露设计。立项时点出的核心问题，至今仍然存在。

image
image1920×916 206 KB

2. 大量重复造轮子，未复用 CCC 已验证的能力
下面列举其中一部分：

这样重复造轮子带来两个风险：

  • 教学内容可能与链上真实行为不一致，等于在教一个错误的心智模型；
  • 维护成本会随着 CCC 自身迭代持续增加。

作为一个"CCC 生态教育工具"却不复用 CCC 自身能力，这一点在定位上是矛盾的。

3. 工具本身的复杂度已经超过它想简化的东西

用 CCC 本身几行代码（Transaction.from → completeInputsByCapacity → completeFeeBy）就能讲清楚的流程，用这个工具摸索半天反而没搞懂。这不只是"体验有待打磨"的问题，而是核心价值主张已经倒挂——工具带来的认知负担，超过了它本该降低的认知负担。

4. 缺少可用性验证证据

两次周报（7/13、7/25）里的 Verification 部分全部是 tsc、eslint、vitest、Playwright 等功能正确性测试，没有看到找一个不熟悉 CKB 的开发者实际试用、观察上手耗时或卡点的记录。作为一个面向新手的教育工具，这恰恰是最应该验证的部分，目前的自我评估更多停留在主观感受层面。

以上是我目前的发现，先同步给大家，供后续讨论参考。

3 Likes