Spark Program | CellKit Actions — Reusable Transaction Actions for CKB Apps

[Fidelcoder]

Project Overview

Project Name: CellKit Actions

One-Sentence Summary: CellKit Actions is a reusable, private-key-free transaction-action toolkit for CKB apps.

Project Type: Developer Tool

Repositories:

Backend: https://github.com/FidelCoder/cellkitBE
Frontend: https://github.com/FidelCoder/cellkitFE

Vercel Deployments:

Frontend: https://cellkitfe.vercel.app
Backend Health: https://cellkitbe.vercel.app/health

Team Profile & Contact

Applicant: Fidelcoder
GitHub: https://github.com/FidelCoder
Role: Blockchain Engineer
Telegram: @GriffinsOduol
Email: [email protected]

Project Background

Building CKB applications requires developers to repeatedly handle low-level transaction work: cell lookup, capacity calculation, inputs, outputs, cell deps, witnesses, fee estimation, validation, dry-run, and broadcast.

This slows down application development and makes simple product flows harder to ship. A developer building a wallet, payment flow, xUDT interface, Spore/DOB tool, escrow flow, or data-cell app should not need to rebuild the same transaction patterns from scratch every time.

CellKit started from this problem: common CKB transaction patterns should be easier to reuse, inspect, verify, and integrate into application flows.

Solution

CellKit Actions is a reusable transaction-action toolkit for CKB apps.

It provides ready-to-use action flows that generate inspectable CKB transaction payloads for common app operations. The first production workflow focuses on CKB transfer:

build unsigned transaction → sign externally → validate → dry-run → broadcast → return real testnet transaction hash

CellKit does not manage private keys, does not custody funds, and does not hide the transaction structure. It helps developers build faster while keeping the CKB transaction model visible and verifiable.

Technical Approach

CellKit has two parts:

Backend: Rust + Axum API for CKB transaction actions, validation, fee estimation, live-cell lookup, dry-run, and broadcast.

Frontend: Next.js playground for generating transaction payloads, inspecting JSON, copying unsigned transactions, and broadcasting externally signed transactions.

The workflow is:

A developer generates an unsigned CKB transfer transaction.
The developer signs it externally with compatible CKB tooling or wallet software.
The signed transaction is pasted back into CellKit.
CellKit validates the transaction structure.
CellKit runs a CKB RPC dry-run.
If dry-run succeeds, CellKit broadcasts the transaction to CKB testnet.
CellKit returns the real transaction hash and explorer link.

CellKit remains testnet-first during this sprint.

Out of scope:

mainnet support
private key handling
wallet custody
in-browser signing
token swaps
user accounts
speculative or trading features

Funding

Requested funding: $1,000

I have adjusted the request from $1,500 to $1,000 so that it fits within the standard Spark Program budget for a technical developer-tool project.

This sprint is scoped around finalizing and verifying the CKB testnet signed-transaction workflow rather than expanding into additional action types, mainnet support, wallet integrations, or token features.

Milestone 1 — Signed Transaction Validation and Safety Checks

Funding: $350

Output: CellKit can accept signed CKB transaction JSON and reject structurally invalid or unsigned payloads before RPC interaction.

Work included:

Finalize POST /api/transactions/validate-signed
Validate required transaction fields
Check inputs, outputs, outputsData, cell deps, and witnesses
Reject empty or unsigned witness payloads
Return clear validation errors and warnings
Add unit and integration tests for signed transaction validation

Milestone 2 — Testnet Dry-Run and Broadcast API

Funding: $350

Output: CellKit can dry-run and broadcast signed CKB testnet transactions through configured CKB RPC.

Work included:

Finalize POST /api/transactions/dry-run
Finalize POST /api/transactions/broadcast
Run dry-run before broadcast by default
Support explicit dry-run skipping only when requested
Return RPC dry-run result, real tx hash, and explorer URL
Add missing-config and RPC error handling tests

Milestone 3 — Web Flow, Documentation, Demo, and Verification

Funding: $300

Output: CellKit provides a usable browser flow and clear verification path for the committee/community.

Work included:

Finalize /broadcast page
Add signed transaction JSON input
Add validate, dry-run, and broadcast controls
Display validation errors, dry-run cycles, tx hash, and explorer link
Update playground next-step instructions for external signing
Add README verification instructions
Record a short demo showing the full testnet flow
Publish final progress update with repo links, demo link, test output, and sample transaction hash

Timeline and To-Do List

Estimated duration: 4 weeks

Week 1 — Milestone 1

Finalize signed transaction request/response models
Complete signed transaction validation endpoint
Add witness/signature presence checks
Add transaction shape validation for required CKB JSON fields
Add tests for invalid shape, empty witnesses, mismatched outputs, and valid signed payloads

Week 2 — Milestone 2

Complete CKB RPC dry-run integration
Complete CKB RPC broadcast integration
Add dry-run-before-broadcast behavior
Add tx hash and explorer URL response
Add missing RPC config and RPC failure tests

Week 3 — Milestone 3

Finalize /broadcast frontend page
Add signed transaction JSON input and format helper
Add validate, dry-run, and broadcast buttons
Add result panels for errors, cycles, tx hash, and explorer link
Update playground to guide users from unsigned payload generation to external signing and broadcast

Week 4 — Milestone 3

Run backend and frontend checks
Run full CKB testnet verification
Prepare README verification steps
Record demo video
Publish final update with repo links, deployment links, test output, and sample testnet transaction hash

Deliverables

Signed transaction validation endpoint
CKB RPC dry-run endpoint
CKB RPC broadcast endpoint
Testnet explorer link after successful broadcast
Broadcast page for pasting, validating, dry-running, and broadcasting signed transactions
Playground update showing the external signing flow
Tests covering validation, dry-run, broadcast errors, and transaction shape checks
README verification instructions
Public demo showing the full workflow
Final progress update

How to Verify

The final work can be verified by running the following flow on CKB testnet:

Start CellKit locally.
Generate an unsigned CKB transfer transaction.
Sign the transaction externally.
Paste the signed transaction into CellKit.
Validate the signed transaction.
Dry-run the signed transaction.
Broadcast the signed transaction.
Confirm that CellKit returns a real transaction hash.
Open the returned testnet explorer link.
Confirm all tests pass.

Verification commands:

cargo fmt – --check

cargo clippy --all-targets --all-features – -D warnings

cargo test

pnpm lint

pnpm build

Expected output:

Backend formatting passes.
Backend clippy passes with no warnings.
Backend unit and integration tests pass.
Frontend lint passes.
Frontend production build succeeds.
The broadcast flow returns a real CKB testnet transaction hash and explorer link.

Current State vs Funded Work

Current state:

CellKit already has an initial working build.

Completed so far:

reusable action route structure
CKB transfer action route
xUDT transfer action route
cell consolidation action route
capacity lock action route
data cell create action route
action registry
validation helpers
fee estimation helpers
real CKB testnet address parsing
real CKB indexer get_cells integration
ordinary cell filtering
deterministic live-cell selection
two-pass fee estimation
secp256k1 cell dep config loading
unsigned CKB transaction skeleton construction
web playground
action forms
transaction JSON preview
copy flow
API error display
initial signed-transaction broadcast flow on main branches
README and Spark scope documentation

Funded work:

harden and finalize signed transaction validation
harden and finalize dry-run and broadcast workflow
complete public browser-based broadcast flow
complete final tests and verification docs
record demo and publish final progress update

This Spark request is not for an idea from zero. It is to complete and verify the next production step: turning CellKit into a usable CKB testnet transaction-action workflow.

Relationship With Existing CKB Tools

CellKit is complementary to existing CKB developer tools such as CCC. It is not intended to replace low-level CKB SDKs, wallet libraries, or signing tools.

CellKit focuses on reusable, inspectable transaction-action workflows at the application layer. Developers can use it to generate and verify common CKB transaction flows, while still signing externally with compatible wallet/tooling.

The goal is to reduce repeated transaction boilerplate without hiding the Cell Model or taking custody of private keys.

Alignment With CKB

CellKit is aligned with CKB because it directly improves the developer experience around the Cell Model.

CKB applications depend on transaction construction patterns that are powerful but repetitive. CellKit turns common transaction patterns into reusable actions without hiding the underlying structure.

This can help future CKB builders ship faster across:

wallets
payment tools
xUDT apps
Spore/DOB apps
data-cell apps
escrow flows
testnet prototypes
developer tools

The goal is practical ecosystem utility: make it easier to build working CKB apps.

Open Source Commitment

CellKit will remain open source.

License: MIT

Release timing: all funded work will be pushed publicly during the Spark funding period, with the final version available immediately upon completion.

Documentation: English documentation will be delivered with the final work. I will also provide a Chinese summary of the project purpose, usage flow, and verification steps to support Spark Program review and community understanding.

[xingtianchunyan]

Hi @Fidelcoder,

Welcome and thank you for your interest in the Spark Program! Below are some personal comments I have before the submission goes to the committee for review, for your reference. These are my thoughts after reading the proposal and do not represent the committee’s position.

After reviewing the proposal, I have summarized the following points that may affect the committee’s evaluation. I suggest you make targeted adjustments before the formal review:

1. The $1,500 budget exceeds the $1,000 cap for pure technical projects and no justification is provided.

According to the Spark Program funding rules, the standard maximum for regular project grants is $1,000, and for special projects the committee may approve up to $2,000. Your proposal requests $1,500, which is a purely technical developer tool project, but it does not at all explain why it needs to exceed the $1,000 standard threshold.

Although your proposal breaks the $1,500 into three $500 milestones with a clear structure, the total still exceeds the limit.

Suggestion:

• Either reduce the total budget to within $1,000, consolidating or trimming some milestones accordingly.
• Or explicitly justify in the proposal why $1,500 is needed so the committee can evaluate treating it as a “special project.”

2. The To-Do List should be linked to the milestones; currently the To-Do List is too brief.

Although your proposal specifies the three milestones (validation / dry-run + broadcast / web flow + demo), the To-Do List section is overly general (e.g., “Add signed transaction validation endpoint”, “Add CKB RPC dry-run endpoint”, etc.), and does not clearly correspond to the milestones. This makes it difficult for the committee to assess: which milestone contains each To-Do item? What are the concrete weekly outputs? Is the workload reasonable and manageable?

Suggestion: Make the To-Do List as detailed as possible and map each item to a milestone. That way the To-Do List and milestones corroborate each other, and the committee can track whether each task aligns with the budget allocation and judge whether the project is controllable.

3. Missing a standalone Open Source Commitment section.

Your proposal repeatedly mentions “open-source release” and an existing GitHub repository, but it does not include a separate Open Source Commitment section explaining:

• Under which license the code will be open-sourced (MIT? Apache-2.0?);
• The timing of the open-source release (immediately upon completion, or delayed?);
• Whether the documentation will be bilingual (the Spark Program requires application materials to be bilingual, and project documentation is also recommended to be bilingual).

Suggestion: Add a separate Open Source Commitment section that specifies the license, the timing of open-sourcing, and the planned documentation language.

4. The relationship with existing ecosystem tools needs further clarification.

The CKB ecosystem currently already has foundational libraries like CCC (CKB Core Components). You mentioned that CellKit “does not hide transaction structures” and “does not manage private keys” — that’s good, but the committee may ask: What is the relationship between CellKit and CCC? Is CellKit a wrapper around CCC, or an independent implementation?

Suggestion: In the Alignment With CKB section, add a sentence or two explaining the relationship between CellKit and existing tools like CCC (dependency? complementary? differentiated positioning?), to help the committee quickly understand your project’s place in the ecosystem.

---

Here are the four issues I’ve summarized. Your proposal is already of high quality — it has clear existing foundations (29 unit tests + 6 integration tests all passing), an independent How to Verify, concrete milestone breakdowns, and it is not a “conceptual” proposal starting from zero. The committee should appreciate this pragmatic positioning as a “next step toward a production-grade iteration.”

The main things to adjust are the budget justification and the refinement of the To-Do List. Once those two are addressed, the review process should go more smoothly.

Looking forward to your updated version.

Best,
xingtianchunyan

[Fidelcoder]

Hi @xingtianchunyan,

Thank you for the detailed review and suggestions.

I have updated the proposal to address the points you raised:

• Reduced the funding request from $1,500 to $1,000

• Reworked the milestones and To-Do List so they map clearly to each week

• Added a standalone Open Source Commitment section

• Clarified CellKit’s relationship with existing CKB tools like CCC

• Improved the Current State vs Funded Work section

I also updated the GitHub repositories with README, Spark scope, verification steps, and MIT license files.

Thanks again for the helpful feedback.

[xingtianchunyan]

Hi @Fidelcoder，

感谢你根据上一轮反馈积极调整提案——将预算从 $1,500 压缩至 $1,000，补充了独立的 Open Source Commitment 章节，To-Do List 也做了细化。目前提案的可读性已经大幅提高，但仍有一些问题需要确认，这些仍是我阅读提案后的想法，不代表委员会的立场。

但在提交正式评审之前，我想邀请你先回答以下三个问题：

1. CellKit 解决了 CCC（CKB Core Components）没有解决的具体问题是什么？

CCC 已经可以用 3 行代码完成 CKB 转账：

const tx = ccc.Transaction.from({ outputs: [{ lock: toLock, capacity: ccc.fixedPointFrom(amount) }] });
await tx.completeInputsByCapacity(signer);
await signer.sendTransaction(tx);

自动完成 live-cell 查找、capacity 计算、费用估算和广播。你声称 CellKit"让开发者不必每次都从底层重建交易"，但 CCC 本身已经将这些操作抽象到了极简的 API 层级。请明确说明：在 CCC 已经覆盖转账全流程的情况下，CellKit 为开发者增加了什么不可替代的价值？

2. “build unsigned transaction” 这一步到底是谁完成的？

你的第一个工作流描述为"build unsigned transaction → sign externally → validate → dry-run → broadcast"。第一个环节的"build unsigned transaction"——包含 live-cell 查找、capacity 计算、费用估算——是 CellKit 自动完成的，还是用户在调用 CellKit 之前手动构建的？如果是手动构建的，那么 CellKit 的核心功能似乎就只是"验证 + dry-run + 广播"，而非完整的交易构建工具。

3. CellKit Web Playground 与现有的 CCC Playground 有什么差异化？

CCC Playground（https://live.ckbccc.com/）已经在浏览器中提供了交互式 CKB 开发环境，支持转账、UDT、Spore、DAO 等多种场景的可视化调试和数据图形展示。CellKit 的 Next.js Web UI 与之相比，提供什么 CCC Playground 没有的功能？

以上三个问题的答案将直接影响委员会对项目独立价值的判断。请在提案中补充说明，或在本帖直接回复。

Best，
xingtianchunyan

[Fidelcoder]

Hi @xingtianchunyan,

Thank you for the clear questions. I agree this distinction needs to be made more explicit.

CellKit is not intended to replace CCC. CCC is already the right low-level SDK/tooling layer for developers building directly in JS/TS. CellKit’s goal is different: it is an API-first transaction-action workflow layer for apps that want reusable, inspectable, externally signed CKB actions.

For the first question: CellKit does not try to make a shorter transfer snippet than CCC. Its value is packaging common CKB workflows behind HTTP/API and UI flows, so developers can build unsigned payloads, inspect them, sign externally, validate, dry-run, and broadcast through a standard process. This is useful for backend services, non-JS apps, internal tools, demos, and teams that want transaction generation and verification separated from signing.

For the second question: for CKB transfer, CellKit handles the unsigned build step automatically. The user provides fromAddress, toAddress, amountCkb, and optional feeRate. CellKit handles testnet address parsing, live-cell lookup through the indexer, ordinary cell filtering, cell selection, fee estimation, change calculation, secp256k1 cell dep loading, witness placeholder creation, and unsigned transaction skeleton construction. Other action types are currently scaffolded/validated, but CKB transfer is the real implemented build flow.

For the third question: CCC Playground is mainly an interactive SDK/code playground for experimenting with CCC. CellKit Web UI is an action workflow console for the CellKit backend. It focuses on form-based action inputs, generated transaction JSON preview, copy flow for external signing, signed transaction validation, RPC dry-run, broadcast, and explorer-link verification.

So the positioning is:

CCC = low-level SDK/tooling layer.
CellKit = reusable API/UI workflow layer for inspectable, externally signed CKB transaction actions.

Thanks again, hope this helps clarify the independent value of the project.

[Fidelcoder]

@xingtianchunyan Hello, I’ve not heard from you since my previous response/clarification!

[xingtianchunyan]

Hi @Fidelcoder,

Thank you for taking the time to revise the proposal based on our earlier feedback.

The committee has completed its review and, after careful discussion, regrets to reject CellKit Actions project.

We want to be transparent about the reasoning behind this decision:

1. Redundant with existing ecosystem tools: The committee finds that CellKit Actions essentially splits the complete, already-integrated transaction flow provided by CCC (CKB Core Components) into separate pieces, while only offering partial functionality and basic RPC wrappers. This does not bring new value to CKB developers — they can already achieve the same results using CCC directly.
2. Limited scope and low differentiation: The current proposal focuses on a single CKB transfer action with external signing, which is a well-covered use case. The committee sees no significant technical innovation or developer experience improvement over existing solutions.
3. Ecosystem impact: For a developer tool to be funded, it must demonstrably reduce friction or enable new capabilities for the broader CKB developer community. CellKit Actions, as proposed, does not meet this bar — it repackages existing patterns without solving a real gap.

We appreciate the work your team has put into CellKit Actions and recognize your enthusiasm for building on CKB.

If in the future you plan to focus on a genuinely novel tool or address an unmet need in the CKB developer toolchain, we would welcome a new application.

Keep building, and feel free to reach out anytime!

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