Spark Program | CKB Builder Lab: Interactive Developer Onboarding Infrastructure for the CKB Ecosystem

1. Project Overview

Project Name

CKB Builder Lab

One-Sentence Summary

CKB Builder Lab is an interactive developer onboarding infrastructure that helps developers understand and build on CKB through browser-based simulations, guided learning paths, and verified practical challenges.

Project Type

Developer Tool · Ecosystem Infrastructure · Interactive Education


2. Team Profile

Core Members

Zuhudev

Role: Full-stack Blockchain Developer

Experience:

  • blockchain application development

  • developer tooling

  • interactive web applications

  • ecosystem infrastructure products

GitHub:
@zuhdevzuhdev

Tele@zuhudevram:
@zuhudev

Email:
[email protected]

Charles

Role: Full-stack Developer

Experience:

  • web application development

  • blockchain integrations

  • developer-focused tooling

GitHub:
@charleslukes


3. Project Background

Problem

The CKB ecosystem introduces a powerful architecture, but developers coming from other blockchain ecosystems often face a significant onboarding challenge.

CKB uses a different programming model based on:

  • Cells

  • UTXO-based state transitions

  • capacity

  • lock scripts

  • type scripts

  • transaction-driven state changes

Developers familiar with other ecosystems need to build a new mental model.

For example:

Ethereum developers usually think in terms of:

Account

Contract

Storage Mutation

Transaction Execution

Solana developers usually think in terms of:

Program

Account Data

Instruction

Runtime Execution

CKB introduces:

Cell

Script Validation

Transaction State Transition

Programmable Ownership

The challenge is not that developers cannot learn CKB. The challenge is that they need a structured way to translate existing blockchain knowledge into CKB concepts.

Currently, developers often rely on:

  • documentation

  • examples

  • explorers

  • manual experimentation

This creates a gap between:

Understanding CKB concepts

        ↓

Building real CKB applications


Ecosystem Relevance

Developer onboarding is a critical growth factor for any blockchain ecosystem.

CKB Builder Lab aims to reduce friction by creating a reusable learning infrastructure that helps developers:

  • understand CKB architecture

  • practice through interaction

  • verify their understanding through challenges

  • transition into application development

The initial Spark phase focuses on the Cell Model because it is the foundation of CKB’s architecture.

Future phases will expand into:

  • RGB++

  • xUDT

  • Fiber

  • cross-ecosystem developer onboarding


4. Solution

Overview

CKB Builder Lab is a browser-based interactive learning platform for developers entering the CKB ecosystem.

The project does not attempt to replace documentation or existing developer tools.

Instead, it provides the missing layer between:

Reading documentation

        ↓

Understanding concepts

        ↓

Building applications

The first Spark milestone focuses on two core modules:

  1. CKB Architecture Learning Simulator

  2. Builder Challenge System


Deliverable 1: CKB Architecture Learning Simulator

Final Form

A browser-based interactive application where developers explore CKB concepts through simulations.


Purpose

The simulator helps developers understand how CKB represents state and executes transactions.

The first module focuses on the Cell Model.


User Flow

A developer opens the simulator.

They create a Cell:

Cell

Capacity:
100 CKB

Lock Script:
Alice

Type Script:
None

Data:
Hello

They modify the Cell and run a simulated transaction.

The system displays:

Input Cell

      ↓

Validation

      ↓

Output Cell

The developer can observe:

  • Cell creation

  • Cell consumption

  • State transition

  • Ownership changes

  • Validation results


Core Features

Cell Explorer

Developers can inspect:

  • capacity

  • lock scripts

  • type scripts

  • data fields


Transaction Simulation

Developers can simulate:

  • input Cells

  • output Cells

  • state transitions


Concept Visualization

The simulator explains:

  • why a transaction succeeds

  • why a transaction fails

  • how state changes occur


Deliverable 2: Builder Challenge System

Final Form

A challenge-based learning system integrated into the simulator.

Developers complete tasks and receive automatic verification.


Challenge Examples

Challenge 1: Create Your First Cell

Task:

Create a valid Cell.

Validation:

capacity > 0

lock script exists

Result:

✓ Challenge Completed


Challenge 2: Execute State Transition

Task:

Consume one Cell and create another.

Validation:

inputs.length > 0

outputs.length > 0

transaction valid


Challenge 3: Transfer Ownership

Task:

Create a valid ownership transfer.

Validation:

input owner != output owner


Completion Model

Challenges are completed through automatic validation.

No manual review is required.


Relationship With Existing Ecosystem Projects

Cell Sandbox

Cell Sandbox provides a visual playground for developers to directly design and inspect CKB Cells, transactions, wallet interactions, and CCC-compatible code.

CKB Builder Lab complements Cell Sandbox by focusing on structured onboarding.

The difference:

Cell Sandbox:

How does this Cell work?

CKB Builder Lab:

How do I learn this concept and become ready to build?

The intended developer flow:

Learn concepts

↓

Complete Builder Lab challenges

↓

Experiment deeper with Cell Sandbox

↓

Build CKB applications


Nervos Brain

Nervos Brain focuses on AI-powered developer assistance and ecosystem knowledge retrieval.

CKB Builder Lab does not build a competing AI assistant.

Future phases will explore integrating mature Nervos Brain capabilities as an optional learning support layer.

The future relationship:

Builder Lab provides:

  • learning context

  • simulation state

  • challenge progression

Nervos Brain provides:

  • ecosystem knowledge

  • technical explanations

  • documentation guidance

Together they create:

Interactive practice

+

Developer assistance

=

Better onboarding experience


5. Technical Approach

Technology Stack

Frontend:

  • Next.js

  • React

  • TypeScript

Simulation Engine:

  • TypeScript state machine architecture

Backend:

  • Lightweight API routes / Supabase

Deployment:

  • Vercel

Architecture Overview

Developer

    |

Next.js Application

    |

----------------------

|                    |

Simulator        Challenge Engine

|                    |

Cell State       Validation Rules

|

Learning Progress


Key Technical Challenges

1. Modeling CKB State Transitions

Challenge:

Representing Cell behavior in an educational but accurate way.

Solution:

Use deterministic state machines to model:

  • Cell creation

  • Cell consumption

  • Cell replacement

  • validation outcomes


2. Making Learning Verifiable

Challenge:

Avoid passive learning.

Solution:

Convert lessons into measurable tasks with automatic validation.


6. To-Do List

Week 1: Architecture Design

Tasks:

  • define simulator architecture

  • design Cell state model

  • define challenge framework

  • create learning flow

Milestone:

Simulation architecture completed.


Week 2: Simulation Engine Development

Tasks:

  • implement Cell objects

  • implement transaction simulation

  • implement validation rules

Milestone:

Working simulation engine.


Week 3: Frontend Implementation

Tasks:

  • build Cell editor interface

  • build transaction visualization

  • implement interaction flow

Milestone:

Interactive simulator available.


Week 4: Challenge System

Tasks:

  • implement challenge framework

  • add validation engine

  • create first learning challenges

Milestone:

Challenge MVP completed.


Week 5: Learning Content

Tasks:

  • create beginner lessons

  • add explanations

  • improve onboarding flow

Milestone:

Complete learning path available.


Week 6: User Testing

Tasks:

  • recruit developers

  • collect usability feedback

  • measure completion rates

Milestone:

Testing report completed.


Week 7–8: Finalization

Tasks:

  • documentation

  • open-source preparation

  • demo polishing

Milestone:

Public release.


7. Required Funding

Total Requested

$950 USD


Funding Breakdown

Category Amount
Simulation engine development $350
Frontend/UI implementation $250
Challenge system development $200
User testing and feedback $100
Hosting and documentation $50

Justification

The funding supports a focused MVP development effort.

The project prioritizes:

  • interactive learning infrastructure

  • measurable developer onboarding

  • open-source ecosystem value


8. Deliverables + How to Verify

Deliverable 1

CKB Architecture Learning Simulator

Format:

  • Web application

  • GitHub repository

  • Documentation

Acceptance Criteria:

Users can:

  • create Cells

  • modify Cell properties

  • run simulated transactions

  • observe state transitions


Verification

Steps:

  1. Open demo URL

  2. Create a Cell

  3. Modify Cell parameters

  4. Execute simulation

Expected Result:

A visual transaction flow appears showing:

  • input state

  • validation

  • output state

Environment:

Modern browser.

No code review required.


Deliverable 2

Builder Challenge System

Format:

Integrated web module.

Acceptance Criteria:

Users can complete challenges and receive automated results.


Verification

Steps:

  1. Open challenge module

  2. Start challenge

  3. Complete required action

  4. Submit

Expected Result:

System returns:

Passed / Failed

with validation explanation.


Final Evidence

The final report will include:

  • demo link

  • repository link

  • screenshots

  • testing report

  • user feedback summary


9. Current State vs Funded Work

Current State

Completed:

  • project concept

  • architecture planning

  • ecosystem research

  • learning module design


Funded Work

During Spark period:

Build:

  • interactive simulator

  • challenge framework

  • learning modules

  • public demo

  • documentation


10. CKB Alignment

CKB Builder Lab directly supports the CKB ecosystem by improving developer understanding of CKB-specific architecture.

The first module focuses on:

  • Cell Model

  • capacity

  • lock scripts

  • type scripts

  • transaction state transitions

Future expansion will cover:

  • RGB++

  • xUDT

  • Fiber

  • developer migration paths from Ethereum and Solana

The long-term goal is to create a developer onboarding layer that helps more developers move from curiosity to building within the CKB ecosystem.

4 Likes

Hi @devnash,

Thank you for your interest in the Spark Program! Below are some of my personal comments before the submission committee review for your reference. These are my impressions from reading and do not represent the committee’s position.

After reading the proposal, I have summarized the following points that may affect the review. I suggest you make targeted adjustments before the formal review:

1. Regarding the content of the proposal

1.1 The deliverables are described unclearly — conceptual terms like “interactive environment” and “simulation environment” are too abstract

The committee is likely unable to determine what specific forms the core deliverables you mentioned in your proposal will take. For example:

  • “Cell Model Simulator” — Is this a web application? An npm package? An embeddable component? Do developers drag and drop Cells in the browser, or write code and see state changes in real time?
  • “RGB++ Learning Sandbox” — Is this two pages within the same product as the Cell Model Simulator, or two completely separate tools?
  • “Builder Challenge System” — Are challenges verified by automated tests (code submissions automatically judged right or wrong) or by manual review? What constitutes a developer having completed a challenge?
  • “AI Learning Assistant” — is it a dialogue interface based on an LLM, or a simple rule-based Q&A? What can a $250 budget achieve within 8 weeks?

Suggestion: For each core deliverable, use one sentence to state its final form (URL / npm package / code repository / documentation), and describe a specific user use case.

1.2 Missing the core “How to Verify” section

This is a required item for the 2026 Spark Program application and a core part of the proposal. The How to Verify section helps the committee and community members understand directly: under the assumption of no code review, how to determine whether your deliverables have met the proposal objectives.

It is recommended to at least include the following:

  • An accessible demo link or prototype (even if incomplete) so the committee can experience the interaction in advance;
  • Acceptance test scripts for each core deliverable;
  • What evidence you will provide at final review (screen recording? user data report? reproducible test environment?).

1.3 Missing Test Plan

Although the success metrics in Section 9 (10+ developers using, 20+ completing the learning path, 80%+ positive feedback, etc.) show the targets, there is a lack of a clear test plan, so the committee cannot determine how these metrics will be collected and verified.

Suggested additions:

  • Recruitment approach for user testing (target population, recruitment channels, screening criteria);
  • Feedback collection mechanisms (built-in surveys? interviews? automatic collection from usage data?);
  • How metrics are calculated (“80% positive feedback” — based on how many samples? How is “positive” defined?).

1.4 To-Do List is too sparse

In your current project timeline you use high-level phrasing to briefly describe weekly tasks (e.g., “Weeks 1–2: Cell Model Simulator development”), but this does not allow the committee to properly judge whether the workload is reasonable and manageable.

Suggestion: Break the To-Do List down as much as possible and link items to deliverables for cross-verification. This way the committee can track whether weekly outputs align with budget allocation and determine if the project is controllable.

1.5 Budget Amount Is Too High

For pure development grants, the Spark Program’s usual cap is $1,000. Your budget request is $1,950 (about $1,700 for core development), and the proposal explicitly lists two MVPs (Cell Model Simulator and RGB++ Sandbox). I recommend focusing on the development and testing of a single MVP and keeping the budget within a reasonable range.

Suggestion:

  • Choose the single core module you consider the highest risk and most in need of validation as the sole MVP (pick either the Cell Model Simulator or the RGB++ Sandbox);
  • Explicitly list the other modules as “Phase 2” or “extensions after MVP validation”;
  • Reduce the budget for pure technical components to under $1,000, reallocate and map it to a detailed To-Do List.

1.6 Confusing heading hierarchy

Several subsections in the proposal use the same symbols as their parent sections, which greatly increases communication costs and makes review more difficult.

Recommendation: Use a clear hierarchy (e.g., H2 → H3 → bullet lists) to ensure the subordinate relationships of each section are immediately obvious.


2. Status of Existing Projects

I’m not sure if you noticed that the Spark Program–funded Nervos Brain project ($2,000, an AI-driven developer assistance tool currently in final testing) overlaps with your proposal in the areas of “AI learning assistant” and “developer onboarding.”

I believe the committee and the community would like to know:

  • Are you aware of the Nervos Brain project? They are doing final testing—have you considered participating in those tests?
  • How does the “AI Learning Assistant” in your proposal differ from Nervos Brain’s positioning? Have you considered adopting Nervos Brain’s results instead of building from scratch?

I believe the committee and the community would welcome connections and mutual recognition between Spark-funded projects. If your project can build on existing ecosystem tools, this will not only show the committee your ecosystem awareness but also help the final product better integrate into the CKB developer toolchain.


The above are the specific issues I have outlined. The proposal’s direction (interactive simulated learning) is valuable—CKB does need better developer onboarding tools—but it currently requires targeted adjustments in deliverable clarity, verification feasibility, budget rationality, and proposal formatting.

Make those adjustments before formally resubmitting to the committee, and the review process will go much more smoothly.

Looking forward to your updated version.

Best,
xingtianchunyan

1 Like

Hi @xingtianchunyan,

Thank you for the detailed feedback. I have updated the proposal based on the points raised.

Main changes made:

  1. Clarified the MVP scope and deliverables

The original proposal was too broad, with multiple large modules presented together. I narrowed the Spark scope into a focused MVP:

  • CKB Architecture Learning Simulator (starting with Cell Model)

  • Builder Challenge System

The Cell Model is now positioned as the first learning module because it is the foundation of CKB’s architecture, rather than the entire product scope.

The deliverables are now described as concrete web application features with specific user flows and acceptance criteria.


  1. Repositioned the project as CKB ecosystem onboarding infrastructure

The proposal is no longer framed as only a Cell learning tool.

The updated vision is:

CKB Builder Lab is a developer onboarding layer for the CKB ecosystem.

The initial phase focuses on helping developers understand the Cell Model, with future expansion planned for:

  • RGB++

  • xUDT

  • Fiber

  • onboarding developers coming from ecosystems such as Ethereum and Solana

A future goal is to provide comparison-based learning paths that help developers map existing concepts into CKB’s architecture.

Example:

Ethereum:
Account / Contract / Storage

CKB:
Cell / Script / State Transition


  1. Clarified the relationship with existing ecosystem projects

I added explicit positioning around existing Spark-funded and ecosystem tools.

For Cell Sandbox:

  • Cell Sandbox focuses on visual Cell experimentation and transaction interaction.

  • CKB Builder Lab focuses on structured learning, guided progression, and challenge-based onboarding.

They complement each other:

Learn concept → Complete challenge → Experiment deeper → Build applications

For Nervos Brain:

I removed the AI assistant from the MVP scope to avoid overlap.

The updated proposal states that future phases may integrate mature Nervos Brain capabilities as the knowledge/support layer instead of building a separate competing AI system.


  1. Added verification and acceptance criteria

Added a full “Deliverables + How to Verify” section.

Each deliverable now includes:

  • final form

  • acceptance criteria

  • verification steps

  • expected output

  • environment requirements

The goal is that reviewers can verify the project through the demo and documented flows without requiring code review.


  1. Added testing methodology

The proposal now includes:

  • developer user testing

  • usability feedback collection

  • completion tracking

  • challenge validation results

Metrics are tied to measurable activities rather than only general adoption targets.


  1. Reduced scope and adjusted funding

The funding request was reduced to align better with a focused Spark MVP.

The new scope prioritizes:

  • simulation engine

  • learning interactions

  • challenge verification

  • testing

  • documentation

instead of attempting to build multiple independent products in one phase.


  1. Expanded technical implementation details

Added:

  • architecture overview

  • simulation approach

  • validation engine design

  • weekly development milestones

The timeline now maps directly to deliverables so progress can be tracked clearly.

Thank you again for the guidance. The feedback helped make the proposal more focused, measurable, and aligned with Spark review expectations.

1 Like

Hi @devnash,

We are pleased to inform you that the Spark Program Committee has approved the CKB Builder Lab proposal, with a funding amount of 950 USD ( 100% paid in CKB, 0.000959 CKB/USD, 990,615 CKB ).

The committee recognizes the value of your project as an interactive developer onboarding infrastructure that bridges the gap between documentation and real application building on CKB. The focus on the Cell Model simulator and challenge system is a practical and much-needed addition to the ecosystem, and we appreciate your clear problem analysis and structured approach.

Here are the next steps:

  1. Funding & Wallet Address

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

    • The first installment (20%) 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!

Best,
xingtian
On behalf of Spark Program Committee

Hi xingtian and Spark Program Committee,

Thank you very much for approving the CKB Builder Lab proposal and for the thoughtful feedback. I really appreciate the committee’s support and recognition of the project’s goal of making CKB development more accessible through hands-on building.

I confirm the funding details and will provide my CKB wallet address below:

ckb1qyqw4vmupk6vs42p7sy8v68zxqpfu2rnj6gqfzsc45

For the weekly sync, I prefer to provide feedback through text-based updates in this post. I will share progress updates regularly and look forward to the committee’s feedback and guidance throughout the development process.

I also acknowledge the proposal content lock and will use the approved version as the baseline. If any adjustments are needed during development, I will discuss and document them through the weekly syncs.

Thanks again to the Spark Program Committee. I’m excited to continue building CKB Builder Lab and contributing to the ecosystem.

Best,
Devnash and Charles

1 Like

Hi @devnash,

The first installment has been disbursed.

Transaction Hash: 0xb4b061630b7e214c4a26676c83a9ce8e6eb5a82587c282b33968bf6d7549b870

Please confirm once received.

Looking forward to your first progress update.

Best,
xingtian
On behalf of the Spark Program Committee

1 Like

Thanks Received

Week 1 Final Evidence: CKB Builder Lab

Hello everyone,

This is the Week 1 progress report for CKB Builder Lab, our approved Spark

Program project focused on interactive developer onboarding infrastructure for

the CKB ecosystem.

Week 1 Milestone

Github: GitHub - devnash11/ckb-builder-lab · GitHub

The Week 1 milestone was:

Simulation architecture completed.

The planned Week 1 tasks were:

  • define simulator architecture

  • design the Cell state model

  • define the challenge framework

  • create the beginner learning flow

  • prepare the implementation handoff for Week 2

These tasks have been completed.

What We Completed

The completed Week 1 files include:

  • `README.md`

  • `docs/architecture.md`

  • `docs/cell-state-model.md`

  • `docs/challenge-framework.md`

  • `docs/learning-flow.md`

  • `docs/week-1-plan.md`

  • `src/simulator/types.ts`

  • `src/challenges/types.ts`

  • `src/content/initial-challenges.ts`

Architecture Summary

We defined the system around four main parts:

  • Learning UI

  • Simulator UI

  • Simulator Engine

  • Challenge Engine

The expected flow is:

User edits Cells → Simulator UI builds a draft transaction → Simulator Engine

validates it → the app shows before/after Cell state and validation trace →

Challenge Engine checks whether the task was completed.

The simulator will be educational and deterministic. It will model the core

CKB Cell lifecycle, while clearly marking simplified areas such as real

signature verification, VM execution, full witness structure, cell deps,

header deps, fees, and real node submission.

Cell and Transaction Model

We designed the MVP Cell model with:

  • `id`

  • `capacity`

  • `lock`

  • optional `type`

  • `data`

  • `status`

Cells can be `live` or `consumed`.

A transaction contains:

  • input Cell IDs

  • output Cell drafts

  • witnesses

Successful simulations consume input Cells and create new live output Cells.

Failed simulations leave the ledger unchanged and return clear validation

errors.

Validation Rules

The first simulator validation rules include:

  • known live inputs

  • at least one output

  • positive capacity

  • lock script exists

  • capacity covers estimated occupied bytes

  • output capacity does not exceed input capacity

  • required owner witness exists

  • educational type script transition rules pass

Each validation result will include a human-readable trace so learners

understand why a transaction passed or failed.

Challenge Framework

We defined the challenge structure, lifecycle, validation inputs, and feedback

model.

The first MVP challenges are:

1. Create Your First Cell

2. Execute State Transition

3. Transfer Ownership

Stretch challenges identified:

  • Add a Type Rule

  • Fix a Failed Transaction

Learning Flow

The first learning path guides developers through:

1. What is a Cell?

2. How does state change?

3. Who owns a Cell?

4. What does capacity mean?

5. What can type scripts enforce?

The intended UI has three areas:

  • lesson and challenge prompt

  • Cell and transaction editor

  • validation trace and before/after state

Technical Direction

We confirmed the MVP stack:

  • Next.js

  • React

  • TypeScript

  • deterministic TypeScript state machine

  • local browser storage for MVP progress

  • optional API routes or Supabase later if needed

  • Vercel deployment

Week 1 Status

Week 1 is complete.

Completed items:

  • simulator architecture

  • Cell state model

  • transaction and local ledger model

  • validation rule plan

  • challenge framework

  • first three MVP challenge definitions

  • beginner learning flow

  • Next.js implementation decision

  • Week 2 handoff plan

Week 2 Plan

Week 2 will focus on simulator engine development.

Planned tasks:

1. Set up the Next.js prototype.

2. Implement simulator domain types.

3. Implement Cell factory helpers.

4. Implement occupied capacity estimation.

5. Implement transaction validation.

6. Implement transaction application to local ledger state.

7. Add unit tests for valid and invalid transactions.

8. Return explanatory trace events for UI rendering.

By the end of Week 2, we should be able to prove through tests that valid

transactions consume live Cells and create outputs, consumed Cells cannot be

reused, invalid capacity or missing locks fail, ownership transfer works, and

failed transactions leave state unchanged.

Summary

Week 1 is complete. CKB Builder Lab now has a clear architecture, Cell model,

challenge framework, learning flow, and Week 2 implementation plan. The

project is ready to move into the Next.js + TypeScript simulator engine build.

3 Likes

Hi @devnash ,

Great to see your first-week update!

The committee believes that for educational projects, providing a corresponding video demonstration might help novice developers in the community notice the project’s progress earlier and make appropriate preparations.

Therefore, the committee invites you to showcase your concrete results via video.

Best,
xingtian
On behalf of the Spark Program Committee

1 Like

Hello

Thank you for the encouraging feedback and for the committee’s suggestion regarding the video demonstration.

I appreciate the importance of providing a visual showcase of the project’s concrete progress, especially for novice developers in the community. I will prepare and share the video demonstration soon, together with the Week Two milestones update, in the coming days.

Thank you again for the guidance and support. I look forward to sharing the next stage of progress with the Spark Program Committee.

2 Likes

Hello everyone,

This is the Week 2 update for CKB Builder Lab, our Spark Program project focused on interactive developer onboarding infrastructure for the CKB ecosystem.

Week 2 Milestone

The Week 2 milestone was focused on Simulation Engine Development.

The main goal was to move from Week 1 architecture planning into a working, tested simulator engine that can later power the interactive Cell Model learning interface.

What We Completed

This week, we implemented the core simulator engine inside a Next.js + TypeScript project.

Completed work includes:

- Next.js + React + TypeScript project setup

- Framework-independent simulator engine

- Cell creation helpers

- Local ledger state model

- Transaction simulation logic

- Input Cell consumption

- Output Cell creation

- Occupied capacity estimation

- Lock/witness validation

- Educational type script validation

- Validation traces for learner feedback

- Challenge evaluator for the first MVP challenges

- Vitest test suite for simulator behavior

- Week 2 final evidence documentation

Simulator Features Implemented

The simulator now supports two modes:

1. Educational genesis mode

  • Allows creating beginner Cells without inputs as a teaching shortcut.

2. Transaction mode**

  • Requires live input Cells.

  • Consumes input Cells.

  • Creates new live output Cells.

  • Rejects invalid transactions.

The validation engine now checks:

- missing inputs

- missing outputs

- unknown input Cells

- already consumed Cells

- invalid capacity

- missing lock scripts

- insufficient occupied capacity

- output capacity exceeding input capacity

- missing owner witnesses

- educational type rule violations

Challenge System Progress

The first three MVP challenges are now executable against the simulator engine:

1. Create Your First Cell**

2. Execute State Transition**

3. Transfer Ownership

The challenge evaluator checks simulator results and returns:

- passed or failed status

- completed criteria

- failed criteria

- feedback messages

Verification

The following checks were run successfully:

```bash

npm run typecheck

npm test

npm run build

```

Results:

- TypeScript check passed

- Vitest test suite passed

- 2 test files passed

- 20 tests passed

- Next.js production build completed successfully

Video Proof

I recorded a short proof-of-completion video showing the project files, Git status, verification commands, test results, production build and local app.

Video link:

https://drive.google.com/file/d/1gM05bla6h8-dw46nVKlGarjzKMBO8Itj/view?usp=sharing

Repository

GitHub repository:

https://github.com/devnash11/ckb-builder-lab

Latest Week 2 commit:

```text

766c4f4 Implement week 2 simulator engine

```

The project is ready for Week 3, where we will focus on the interactive Cell editor interface, transaction visualization, and user-facing learning flow.

2 Likes

Hi @devnash ,

Thank you for the ongoing updates. After reviewing the latest materials, the committee has the following two points of feedback:

  • Demo Video:
    The current video does not help the committee and the community to see the project’s true state. Please provide a demo video that clearly demonstrates the actual functionality and user experience.

  • Weekly Update Format:
    The format of recent weekly updates has been somewhat disorganized, resulting in a poor reading experience. Please pay closer attention to the visual appeal of your formatting in future posts—use clear headings, bulleted lists, and a logical structure. This will make it easier for the committee and the community to track your progress.

Looking forward to your next update.

Best,
xingtian
On behalf of the Spark Program Committee