Spark Program | CellScript AMM Transaction Builder

Core Member

Background
I have been working through CKB transaction construction, the Cell Model, CCC/offckb devnet workflows, and CellScript-based contract examples. My current work focuses on building an external transaction builder for CellScript AMM flows.
Related repositories:

  1. Project Background
    On account-based chains like Ethereum, a user usually calls a contract function and the chain computes the result. The wallet mostly builds a thin transaction around a function call.
    CKB is different. On CKB, the transaction must already describe the full state transition. The builder must find live cells, read their current data, compute the new state off-chain, assemble the expected output cells, attach witnesses and cell deps, then submit the complete transaction for verification.
    This makes external builders essential.
    While working with CellScript AMM examples, I found that the hardest part was not only the contract logic. The harder part was building the correct transaction around the contract:
  • Which cells should be consumed?
  • Which new cells should be created?
  • Which type scripts should be used?
  • How should witness bytes be generated?
  • How should script hashes be calculated?
  • How can a developer verify the transaction before signing or submitting?
    I already built a working prototype for the first step, launch_token, and verified it with CKB local devnet dry-run. The next step is to extend this into a complete AMM transaction builder flow.
  1. Solution
    The project will provide a CLI-first builder for CellScript AMM transactions.
    The builder will help developers construct transactions for these CellScript actions:
  • launch_token
  • mint_with_authority
  • seed_pool
  • swap_a_for_b
    From a developer’s perspective, the tool should let them run commands like:
    cellscript-amm-builder launch
    cellscript-amm-builder mint
    cellscript-amm-builder seed
    cellscript-amm-builder swap
    or equivalent script commands during the prototype phase.
    The builder will:
  • load compiler-generated CellScript resource identities;
  • generate canonical witness bytes using cellc entry-witness;
  • query CKB devnet for live cells;
  • construct valid transaction inputs and outputs;
  • run CKB dry-run verification;
  • optionally submit the transaction;
  • store output cell references in a state file for the next step.
    The difference from a normal script is that this project is not just hardcoding one transaction. The goal is to turn CellScript compiler outputs into a practical builder workflow that other CKB developers can inspect, reproduce, and extend.
  1. Technical Approach
    Tech Stack
  • CellScript v0.16.2
  • CKB local devnet / offckb
  • CKB JSON-RPC
  • Python and/or Node.js CLI scripts
  • CCC SDK where signing is needed
  • CKB Cell Model
  • CellScript resource identities, builder manifests, and entry witnesses
    Architecture Overview
    The builder will have these main parts:
  1. Compiler Metadata Loader
  • Reads CellScript resource identity plans.
  • Reads action ABI/manifest information.
  • Avoids guessing type scripts manually.
  1. Live Cell Reader
  • Queries CKB devnet for live input cells.
  • Reads cell data such as token amounts, symbols, pool reserves, and capacity.
  1. Transaction Constructor
  • Builds the correct inputs, outputs, outputs data, cell deps, and witnesses.
  • Uses Molecule-packed CKB Script hashing.
  • Uses cellc entry-witness for canonical CellScript witness bytes.
  1. Verifier
  • Runs CKB dry_run_transaction.
  • Optionally integrates cellc builder check --production where applicable.
  • Prints clear success/failure output.
  1. State Index
  • Records generated output cells after launch/mint/seed.
  • Allows the next command to use the previous transaction’s outputs.
  1. To-Do List
    Week 1: Finalize Launch Builder + Output Indexing
  • Finalize the existing launch_token builder.
  • Add optional submit mode.
  • Record created output cells into a state JSON file.
  • Improve error messages and configuration.
    Milestone:
    launch_token can be dry-run and optionally submitted. Created output cells are indexed.
    Week 2: Build mint_with_authority Flow
  • Consume a live MintAuthority cell.
  • Build updated authority and new token outputs.
  • Generate witness with cellc entry-witness.
  • Add dry-run verification.
    Milestone:
    mint_with_authority transaction dry-runs successfully.
    Week 3: Build seed_pool Flow
  • Consume Pool and Token cells.
  • Build updated Pool, LPReceipt, and change outputs.
  • Add capacity handling and dry-run verification.
    Milestone:
    seed_pool transaction dry-runs successfully.
    Week 4: Build swap_a_for_b Flow
  • Read pool reserves from live Pool cell.
  • Compute swap output off-chain.
  • Enforce minimum output / slippage.
  • Build updated Pool and output Token cells.
  • Run dry-run verification.
    Milestone:
    swap_a_for_b transaction dry-runs successfully.
    Week 5: Unified CLI + State Management
  • Wrap commands into one CLI interface.
  • Add config file support.
  • Add state file support for output cell tracking.
  • Improve command help and failure messages.
    Milestone:
    Developer can run launch, mint, seed, and swap commands from one CLI flow.
    Week 6: Documentation + Demo
  • Write setup guide.
  • Write verification guide.
  • Add sample transaction JSON outputs.
  • Record demo video or walkthrough.
  • Document current limitations.
    Milestone:
    Reviewer can reproduce the flow locally without reading the code.

Funding Breakdown

  • $700 - Core builder development

  • complete the live-cell transaction builder flow after launch_token

  • implement/index the remaining AMM steps: mint_with_authority, seed_pool, and swap_a_for_b

  • $200 - Verification and devnet testing

  • local devnet dry-run checks

  • reproducible transaction JSON outputs

  • expected command outputs for reviewers

  • $100 - Documentation and demo preparation

  • setup guide

  • usage guide

  • verification walkthrough

  1. Deliverables + How to Verify
    A. Deliverable
  2. Updated Public GitHub Repository
  • Repository contains the completed builder scripts/CLI.
  • Acceptance: code is pushed and documented.
  1. Launch Builder
  • Builds and dry-runs launch_token.
  • Acceptance: command prints Dry run OK.
  1. Mint Builder
  • Builds and dry-runs mint_with_authority.
  • Acceptance: command prints Dry run OK.
  1. Seed Pool Builder
  • Builds and dry-runs seed_pool.
  • Acceptance: command prints Dry run OK.
  1. Swap Builder
  • Builds and dry-runs swap_a_for_b.
  • Acceptance: command prints Dry run OK and shows expected output amount.
  1. State File
  • Records created output cells after each step.
  • Acceptance: JSON file contains outpoints for later commands.
  1. Documentation
  • Setup, usage, and verification instructions.
  • Acceptance: reviewer can follow commands without reading source code.
  1. Demo Video / Walkthrough
  • Shows the tool running on local devnet.
  • Acceptance: video or written walkthrough demonstrates launch through swap dry-run.
  1. Current State vs. Funded Work
    Current State
    Already completed:
  • CellScript v0.16.2 local toolchain verified.
  • launch_token ELF verified against deployed local devnet artifact.
  • Cleaned script added: scripts/build_launch_tx.py.
  • Script loads compiler-generated resource identities.
  • Script reads paired funding token data from devnet.
  • Script generates witness bytes with cellc entry-witness.
  • Script computes CKB script hashes using Molecule-packed Script encoding.
  • Script builds launch_token transaction outputs.
  • Script dry-runs successfully.
    Verified output:
    Funding token: 10000 PAIR0001
    Creator lock hash: 0x0abf028eb7f3927ac1ee9761fb650b60f16ea4c25e6a076db1cd94eff954b413
    Pool type hash: 0xa952d9ec6d6bcb404c792eccccf398ee50a848f69ff7a3514118406690e6fb17
    Output capacity: 820.0 CKB
    Dry run OK: 49848 cycles
    Current commit:
    aeb0918 add devnet launch transaction builder

Funded Work
The Spark funding will cover the delta from launch-builder prototype to complete AMM builder demo:

  • submit/index launch outputs;
  • implement live-cell mint_with_authority;
  • implement live-cell seed_pool;
  • implement live-cell swap_a_for_b;
  • build unified CLI;
  • add reproducible docs and demo materials.
    Clear Boundary
    The current project proves the launch step.
    The funded project completes the full AMM transaction-builder flow.
  1. CKB Alignment

This project is directly aligned with CKB’s unique architecture.

It depends on:

  • Cell Model: transactions consume old cells and create new cells.
  • Type Scripts: AMM and token rules are enforced by CellScript-generated scripts.
  • Lock Scripts: output ownership is verified through script hashes.
  • Cell Deps: deployed ELF artifacts must be referenced correctly.
  • CKB-VM: CellScript compiles to RISC-V code executed by CKB-VM.
  • CellScript: the project uses resource-identity, entry-witness, builder manifests, and builder checks.
  • External Builder Pattern: the project demonstrates how CKB applications require off-chain transaction construction.

The wider ecosystem value is that this project is not only an AMM example. It is also an early reusable external-builder pattern for CellScript contracts.

Most CellScript applications will need similar builder logic:

  • loading compiler metadata;
  • generating canonical witnesses;
  • resolving live cells;
  • constructing full CKB transactions;
  • attaching the correct cell deps and scripts;
  • running dry-run checks before submission;
  • keeping a reproducible state index between transaction steps.

The AMM flow is a concrete test case because it involves multiple real CKB concepts at once: token cells, pool cells, LP receipts, capacity handling, type scripts, lock scripts, and multi-step state transitions. If this builder pattern works for the AMM flow, it can serve as a practical reference for other CellScript-based protocols that need external builders.

So the project should be understood as both:

  1. a CellScript AMM transaction builder; and
  2. an early prototype of reusable CellScript external-builder infrastructure on CKB.

It exists specifically because CKB transactions are complete state transitions that must be built off-chain and verified on-chain. The goal is to make that builder pattern easier for future CKB developers to understand, reproduce, and extend.

8 Likes

Great to see you are putting this together. If you hit anything awkward in the middle, feel free to leave a note here or ping me on Telegram. I’ll be happy to help unblock where I can.

There will also be a fairly large CellScript update next week, once that lands, I’ll help you align the builder with the updated outputs so the flow is easier to reproduce and review.

5 Likes

Hi @WuodOdhis,

Great to see your interest in the Spark Program!

Your proposal is already excellent and has no formatting issues. Below are some personal thoughts before I submit this for committee review, for your reference. These reflect my own reading and do not represent the committee’s position.

1. Budget of $1,500 exceeds the $1,000 standard

Recommend adjusting the budget.

  • First, for purely technical projects, Spark’s budget cap is $1000.
  • Second, your budget list does not include a community portion (Technical Development $1000 + Testing $300 + Documentation $200); testing and documentation both fall under development.

If you insist on requesting $1500, please provide a clear justification explaining why.

2. Scope boundary of dual positioning

The proposal includes the following statement:

“the project should be understood as both: a CellScript AMM transaction builder; and an early prototype of reusable CellScript external-builder infrastructure on CKB”

I think the “AMM builder” and the “reusable external-builder infrastructure” are two sides of one coin. But to avoid any ambiguity, could you confirm whether they are two completely separate but related components?

3. Positioning as an infrastructure-type project

If this project is both a tool (CLI AMM builder) and infrastructure (external-builder pattern). Unlike pure protocol-level infrastructure, it has clear “How to Verify” steps and a short-term delivery path. But the committee may still press: who are the beneficiaries of this project? How many CellScript developers currently need this tool?

best
xingtian

3 Likes

Hi @WuodOdhis,

Disclosure first: I maintain CellScript, so I will avoid commenting on the funding decision itself. The notes below are only technical and product-direction feedback from the CellScript / ecosystem-tooling side.

I think the committee’s question about beneficiaries is the right one. CellScript is now approaching a more production-oriented stage, but the current number of active CellScript developers is only beginning to grow. If this proposal is framed only as a developer-facing AMM-specific CLI, the adoption surface may indeed look narrow in the short term.

At the same time, I think Spark proposals are strongest when they are framed around concrete CKB ecosystem development, rather than research or experimentation for its own sake. A prototype or research component can be valuable, but the deliverable should make it easier for other builders, reviewers, users, or downstream projects to build on CKB.

From that angle, where I see stronger ecosystem value is in treating your proposed AMM builder as a concrete reference path toward application-facing and eventually user-facing transaction generation tooling for CellScript contracts. It may also be worth checking whether there are adjacent explorations elsewhere in the community, so the work can align with the broader CKB tooling landscape where possible.

On the CellScript side, I have also been preparing several primitives and CLI options with this kind of tooling in mind, so there may be some useful pieces for you to explore as the builder evolves.

Good luck with the proposal, and I’m happy to help clarify the CellScript-side interfaces where useful.

3 Likes

Hi @xingtianchunyan, thank you for the careful review and for the helpful comments.

I agree with the points raised, and I will adjust the proposal accordingly.

1. Budget

I will revise the requested budget to $1,000.

You are right that this is primarily a technical development project, and the testing/documentation work is part of the development process rather than a separate community component. I will update the funding breakdown to keep it within the standard Spark technical-project scope.

A revised breakdown could be:

  • $700 - Core builder development

    • complete the live-cell transaction builder flow after launch_token
    • implement/index the remaining AMM steps: mint_with_authority, seed_pool, and swap_a_for_b
  • $200 - Verification and devnet testing

    • local devnet dry-run checks
    • reproducible transaction JSON outputs
    • expected command outputs for reviewers
  • $100 - Documentation and demo preparation

    • setup guide
    • usage guide
    • verification walkthrough

2. Scope Boundary

To clarify: the AMM builder and the reusable external-builder pattern are not two separate deliverables.

The concrete deliverable is still the CellScript AMM transaction builder.

The broader “external-builder pattern” is the reusable lesson/reference produced by building that concrete tool. In other words, the AMM flow is the test case and implementation target, while the reusable pattern is the documented structure that other CellScript builders can learn from.

So I will rephrase this in the proposal to avoid making it sound like two separate projects.

A clearer framing is:

The funded deliverable is a CLI-first CellScript AMM transaction builder. Because AMM transactions require live cell resolution, compiler metadata, canonical witnesses, full transaction construction, dry-run checks, and state indexing, the project also serves as a practical reference implementation for how external builders can be structured for future CellScript contracts.

3. Beneficiaries and Ecosystem Value

I also agree that the beneficiary question is important.

The immediate audience is not a large existing user base yet. CellScript adoption is still early. The short-term beneficiaries are:

  • developers experimenting with CellScript contracts;
  • hackathon builders who need examples of full CKB transaction construction;
  • CKB developers trying to understand the external-builder model;
  • reviewers who need reproducible transaction-building examples;
  • future protocol teams that need a reference for building around CellScript actions.

The value is not only that this builds one AMM-specific CLI. The value is that the AMM flow is a concrete and non-trivial example of a broader CKB problem: on CKB, the transaction builder must construct the full state transition off-chain.

This project gives that pattern a working, reproducible reference path:

  • load compiler-generated resource identities;
  • generate canonical cellc entry-witness bytes;
  • resolve live cells from devnet;
  • construct complete CKB transactions;
  • run dry-run checks before submission;
  • keep a state/index file across multi-step transactions.

So I will adjust the proposal to frame it less as “AMM infrastructure for an existing large audience” and more as:

a concrete CellScript AMM builder that also acts as an early reference path for application-facing transaction generation tooling on CKB.

Thanks again for the review. I will update the proposal with these clarifications before committee review.

2 Likes

Hi @ArthurZhang, thank you for the clarification and technical direction

I agree with your framing. I have adjusted the proposal so the concrete deliverable remains the CellScript AMM transaction builder, while the broader value is presented as a reference path for application-facing transaction generation tooling around CellScript contracts.

Thank you also for the support and I will be reaching out.

2 Likes

Hi @WuodOdhis,

Thank you for taking the time to join Spark Program.

The committee has completed its review and, after careful discussion, regrets to Reject the CellScript AMM Transaction Builder project at this time.

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

  • Poor timing, too aggressive:
    The committee acknowledges that the CellScript AMM trading builder project has value; additionally, CellScript is an active project within the CKB eco and community; and AMM is a promising direction. However, pursuing development that addresses needs which have not yet been clearly established, based on a project still in its early stages, remains too “aggressive.”

We greatly appreciate the effort your team has put into exploring the development of CellScript trades. If you plan to focus on more practical product development in the future, we would welcome you to submit another application.

Thank you very much for all the hard work your team has put in. Keep building, and feel free to reach out anytime!

Best,
xingtian
On behalf of the Spark Program Committee

1 Like

@WuodOdhis

One thing I would gently flag from the CellScript side is that the ground is moving quite quickly. CellScript 0.21 is expected to introduce generated builders, and some cross-cell state-transition semantics are being planned for 0.22, so a CellScript-based AMM builder may indeed end up tracking a moving target for a while.

That said, I still think the proposal is meaningful. During the discussion, you have shown a good grasp of the underlying CellScript semantics, and I would encourage you to keep exploring this contract-ergonomics direction, without being boxed in too tightly by the current DSL surface. It may also be worth looking at similar tooling experiments in the Cardano ecosystem, as well as some recent CKB-side work around contract vibe-coding harnesses and developer education.

Please feel free to DM me if any assistance or advice would be useful. Great work so far.

3 Likes