{ "base_url": "https://talk.nervos.org", "generated_at": "2026-05-03T17:44:55.593609+00:00", "since": "2026-05-02T17:44:49.988061+00:00", "until": "2026-05-03T17:44:49.988061+00:00", "window_hours": 24, "topics": [ { "topic_id": 10193, "title": "CellScript - A DSL for Cell-Based Contracts", "slug": "cellscript-a-dsl-for-cell-based-contracts", "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193", "created_at": "2026-04-21T04:43:38.654000+00:00", "last_posted_at": "2026-05-03T17:39:54.554000+00:00", "category_id": 49, "tags": [ "CKB-VM", "CellScript", "DSL" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24119, "post_number": 20, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "ArthurZhang", "created_at": "2026-05-03T17:39:54.554000+00:00", "updated_at": "2026-05-03T17:39:54.554000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/20", "content_text": "CellScript v0.13.2: closing the 0.13 stable line with strict CKB acceptance evidence\nCellScript v0.13.2 is now ready as the stable closing release for the 0.13 line.\nThis release is not only a compiler update. The main focus of 0.13.2 is release hardening: making the syntax surface more stable, keeping Cell effects audit-visible, and strengthening the CKB acceptance evidence behind the bundled production examples.\nWhat changed in 0.13?\nThe 0.13 line introduced and stabilised several important areas:\nbounded stack-backed Vec helper support;\ncanonical action/update syntax with named outputs, where proof blocks, and explicit move state edges;\nvisible lock-boundary data sources through protected, witness, and fixed-width lock_args;\nstdlib lifecycle and Cell metadata helpers that lower to explicit verifier obligations;\nsyntax-combination audit gates across parser, formatter, type checking, lowering, metadata, and codegen;\nstronger local CKB production acceptance for the bundled examples.\nA core design rule in this release is:\nSugar may shorten source code, but it must not hide Cell movement, ownership, or authorisation.\nFor example, helpers such as lifecycle transfer/claim/settle patterns and Cell metadata helpers are intended to be audit-visible shorthand. They lower to explicit verifier obligations rather than silently inventing protocol policy.\nStateful CKB acceptance\nThe biggest release-evidence improvement in v0.13.2 is the new strict stateful acceptance layer.\nPreviously, the acceptance suite already covered individual production actions and builder-backed local CKB transaction checks. In 0.13.2, the stateful runner now exercises committed multi-transaction flows where live outputs from earlier actions become real inputs to later actions.\nThe current release evidence includes:\n7 production bundled examples\n43/43 production acceptance actions covered\n16 builder-backed lock valid/invalid spend cases\n27 stateful local CKB scenarios\n46 committed stateful steps\n7 end-to-end business-flow scenarios\n20 stateful action-branch scenarios\nThe stateful scenarios cover the main bundled example families:\ntoken.mint-transfer-mint-merge-burn\nnft.mint-list-transfer-by-listing\ntimelock.create-lock-lock-asset-request-release-execute\nlaunch.launch-token-then-mint\namm.seed-add-swap-remove\nvesting.create-config-grant-revoke\nmultisig.create-propose-sign-sign-execute\nAdditional stateful action-branch scenarios cover the remaining production acceptance actions not already exercised by those end-to-end flows.\nThis means the release evidence is no longer just “the examples compile” or “a few happy paths run”. The gate now checks that every production acceptance action appears in the stateful report, with no missing action IDs or missing action artifacts.\nWhat each committed step records\nEach stateful step records concrete execution evidence, including:\ndry-run evidence;\ncommitted transaction evidence;\nmeasured cycles;\nconsensus-serialized transaction size;\noccupied capacity;\ncapacity checks;\nconsumed-input liveness checks;\noutput liveness checks;\nmalformed transaction rejection where applicable.\nUnder-capacity outputs are rejected by the release gate.\nThe release-facing command is:\n./scripts/cellscript_ckb_release_gate.sh full\nThis full gate includes compiler/tooling checks, syntax-combination CI audits, VS Code validation, documentation-boundary checks, builder-backed local CKB acceptance, and stateful scenario/action coverage.\nWhat this proves\nThe current evidence proves that the bundled production CellScript examples compile under the CKB target profile and that the generated artifacts can participate in concrete local CKB devnet transactions.\nMore importantly, it proves that the acceptance gate observes actual Cell lifecycle behaviour:\nvalid transactions dry-run and commit;\nlive outputs can be handed into later transactions;\nconsumed inputs are no longer live;\nexpected outputs remain live;\nmalformed variants are rejected;\ncycles, size, and occupied capacity are measured.\nIn other words, the bundled examples are no longer merely compile-time demonstrations. They now have committed stateful CKB protocol-flow evidence behind them.\nWhat this does not claim though\nCellScript v0.13.2 is not claiming:\nexternal security audit closure;\nmainnet-value certification;\nexhaustive state-space verification;\nformal verification;\nhidden signer authority;\nhidden sighash defaults;\nfull generic maps;\nCell-backed generic collection ownership;\ndeclarative capacity or since/header policy.\nThose remain future work or intentionally out of scope.\nIn particular, witness Address is still just decoded witness data. It is not a cryptographic authorisation proof by itself. First-class signer values and explicit sighash verification need stronger CKB binding semantics and separate release evidence before they should become stable source syntax.\nNext\nThe 0.13 implementation scope is now closed. The remaining CKB semantic work is being kept explicit for the next line, including areas such as structured WitnessArgs, ScriptGroup conformance fixtures, broader Source-view semantics, and explicit signature-verification primitives.\nAs always, comments, criticism, and review are very welcome.\nThank you to everyone who has been following the project and giving feedback.", "content_html": "

CellScript v0.13.2: closing the 0.13 stable line with strict CKB acceptance evidence

\n

CellScript v0.13.2 is now ready as the stable closing release for the 0.13 line.

\n

This release is not only a compiler update. The main focus of 0.13.2 is release hardening: making the syntax surface more stable, keeping Cell effects audit-visible, and strengthening the CKB acceptance evidence behind the bundled production examples.

\n

What changed in 0.13?

\n

The 0.13 line introduced and stabilised several important areas:

\n\n

A core design rule in this release is:

\n
\n

Sugar may shorten source code, but it must not hide Cell movement, ownership, or authorisation.

\n
\n

For example, helpers such as lifecycle transfer/claim/settle patterns and Cell metadata helpers are intended to be audit-visible shorthand. They lower to explicit verifier obligations rather than silently inventing protocol policy.

\n

Stateful CKB acceptance

\n

The biggest release-evidence improvement in v0.13.2 is the new strict stateful acceptance layer.

\n

Previously, the acceptance suite already covered individual production actions and builder-backed local CKB transaction checks. In 0.13.2, the stateful runner now exercises committed multi-transaction flows where live outputs from earlier actions become real inputs to later actions.

\n

The current release evidence includes:

\n
7 production bundled examples\n43/43 production acceptance actions covered\n16 builder-backed lock valid/invalid spend cases\n27 stateful local CKB scenarios\n46 committed stateful steps\n7 end-to-end business-flow scenarios\n20 stateful action-branch scenarios\n
\n

The stateful scenarios cover the main bundled example families:

\n
token.mint-transfer-mint-merge-burn\nnft.mint-list-transfer-by-listing\ntimelock.create-lock-lock-asset-request-release-execute\nlaunch.launch-token-then-mint\namm.seed-add-swap-remove\nvesting.create-config-grant-revoke\nmultisig.create-propose-sign-sign-execute\n
\n

Additional stateful action-branch scenarios cover the remaining production acceptance actions not already exercised by those end-to-end flows.

\n

This means the release evidence is no longer just “the examples compile” or “a few happy paths run”. The gate now checks that every production acceptance action appears in the stateful report, with no missing action IDs or missing action artifacts.

\n

What each committed step records

\n

Each stateful step records concrete execution evidence, including:

\n\n

Under-capacity outputs are rejected by the release gate.

\n

The release-facing command is:

\n
./scripts/cellscript_ckb_release_gate.sh full\n
\n

This full gate includes compiler/tooling checks, syntax-combination CI audits, VS Code validation, documentation-boundary checks, builder-backed local CKB acceptance, and stateful scenario/action coverage.

\n

What this proves

\n

The current evidence proves that the bundled production CellScript examples compile under the CKB target profile and that the generated artifacts can participate in concrete local CKB devnet transactions.

\n

More importantly, it proves that the acceptance gate observes actual Cell lifecycle behaviour:

\n\n

In other words, the bundled examples are no longer merely compile-time demonstrations. They now have committed stateful CKB protocol-flow evidence behind them.

\n

What this does not claim though

\n

CellScript v0.13.2 is not claiming:

\n\n

Those remain future work or intentionally out of scope.

\n

In particular, witness Address is still just decoded witness data. It is not a cryptographic authorisation proof by itself. First-class signer values and explicit sighash verification need stronger CKB binding semantics and separate release evidence before they should become stable source syntax.

\n

Next

\n

The 0.13 implementation scope is now closed. The remaining CKB semantic work is being kept explicit for the next line, including areas such as structured WitnessArgs, ScriptGroup conformance fixtures, broader Source-view semantics, and explicit signature-verification primitives.

\n

As always, comments, criticism, and review are very welcome.

\n

Thank you to everyone who has been following the project and giving feedback.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10224, "title": "CellScript 0.13 Direction Update: Actions, State, and Syntax", "slug": "cellscript-0-13-direction-update-actions-state-and-syntax", "url": "https://talk.nervos.org/t/cellscript-0-13-direction-update-actions-state-and-syntax/10224", "created_at": "2026-05-01T15:34:27.229000+00:00", "last_posted_at": "2026-05-03T13:59:55.397000+00:00", "category_id": 49, "tags": [ "CKB-VM", "CellScript" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24118, "post_number": 3, "topic_id": 10224, "topic_title": "CellScript 0.13 Direction Update: Actions, State, and Syntax", "topic_slug": "cellscript-0-13-direction-update-actions-state-and-syntax", "author": "ArthurZhang", "created_at": "2026-05-03T13:59:55.397000+00:00", "updated_at": "2026-05-03T14:02:17.638000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/cellscript-0-13-direction-update-actions-state-and-syntax/10224/3", "content_text": "0.13.2 Patch Preview Preview: Standard Library Patterns Arrive\nCellScript 0.13.2 adds the first stable standard-library audit patterns. This is a small but important step for the language. The goal is not to hide CKB Cell semantics behind magic syntax. The goal is to give common verifier patterns a clear, namespaced spelling while keeping their lowering explicit and auditable.\nThe new standard-library surface includes lifecycle helpers:\nstd::lifecycle::transfer(input, output, to) {\namount\nsymbol\n}\nstd::receipt::claim(receipt, output, lock) {\namount\n}\nstd::lifecycle::settle(input, output, lock) {\namount\n}\nIt also includes Cell metadata helpers:\nstd::cell::same_lock(output, input)\nstd::cell::preserve_lock(output, input)\nstd::cell::preserve_capacity(output, input)\nThese helpers are not hidden protocol policy. They lower to explicit verifier obligations such as consuming an input, creating a named output, preserving a whitelisted set of fields, checking lock or capacity continuity, and keeping type continuity visible.\nCore syntax stays small:\naction\nwhere\nmove\nrequire\ncreate\nconsume\nread / protected / witness / lock_args\nThe standard library sits one layer above that: typed, explicit, reusable audit patterns that expand back into the verifier model.\n0.13.2 also hardens the boundary around this feature:\npreserve sugar is type-equivalent to its canonical require expansion;\nanonymous require { ... } blocks remain pure boolean grouping only;\nlifecycle operations cannot hide inside require blocks;\nsyntax-combination audit now checks parser, formatter, type checking, lowering, metadata, and codegen combinations before release.", "content_html": "

0.13.2 Patch Preview Preview: Standard Library Patterns Arrive

\n

CellScript 0.13.2 adds the first stable standard-library audit patterns. This is a small but important step for the language. The goal is not to hide CKB Cell semantics behind magic syntax. The goal is to give common verifier patterns a clear, namespaced spelling while keeping their lowering explicit and auditable.

\n

The new standard-library surface includes lifecycle helpers:

\n
std::lifecycle::transfer(input, output, to) {\n    amount\n    symbol\n}\n
\n
std::receipt::claim(receipt, output, lock) {\n    amount\n}\n
\n
std::lifecycle::settle(input, output, lock) {\n    amount\n}\n
\n

It also includes Cell metadata helpers:

\n
std::cell::same_lock(output, input)\nstd::cell::preserve_lock(output, input)\nstd::cell::preserve_capacity(output, input)\n
\n

These helpers are not hidden protocol policy. They lower to explicit verifier obligations such as consuming an input, creating a named output, preserving a whitelisted set of fields, checking lock or capacity continuity, and keeping type continuity visible.

\n

Core syntax stays small:

\n
action\nwhere\nmove\nrequire\ncreate\nconsume\nread / protected / witness / lock_args\n
\n

The standard library sits one layer above that: typed, explicit, reusable audit patterns that expand back into the verifier model.

\n

0.13.2 also hardens the boundary around this feature:

\n", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10131, "title": "Spark Program | CKB Developer Onboarding Guide", "slug": "spark-program-ckb-developer-onboarding-guide", "url": "https://talk.nervos.org/t/spark-program-ckb-developer-onboarding-guide/10131", "created_at": "2026-03-26T08:49:26.745000+00:00", "last_posted_at": "2026-05-03T06:45:38.142000+00:00", "category_id": 49, "tags": [ "In-Progress", "Spark-Program" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24117, "post_number": 15, "topic_id": 10131, "topic_title": "Spark Program | CKB Developer Onboarding Guide", "topic_slug": "spark-program-ckb-developer-onboarding-guide", "author": "Mateja3m", "created_at": "2026-05-03T06:45:38.142000+00:00", "updated_at": "2026-05-03T11:34:49.841000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-developer-onboarding-guide/10131/15", "content_text": "Hello @xingtianchunyan, here is the report for Week 1 (overall week 3) Milestone 2\nWeek 1 Milestone 2 Progress Report\nStatus\nMilestone 1 has been completed.\nMilestone 2 has started, and the Week 1 scope has been completed in the local repository workspace.\nWork Completed\n1. First CKB-Specific Overview Layer Added\nThe existing document at docs/03-quick-start.md was repurposed to fit the current repository structure and now works as the first CKB-specific overview layer.\nThis section now explains:\nwhat CKB is\nwhat Nervos is\nwhat role a CKB node plays\nwhat RPC is\nwhy a developer may use a local node or a public RPC endpoint\nwhat the guide currently covers and does not yet cover\nThis was done without creating duplicate files or breaking the Milestone 1 document ordering.\n2. CKB Node Setup Guidance Expanded\nThe existing document at docs/04-ckb-node-setup.md was expanded from a narrower setup page into a more practical onboarding decision guide.\nThe updated section now covers:\nwhen a local node is needed\nwhen a public or shared RPC endpoint may be enough\nthe repository-validated local setup path\nhigh-level preparation before local node work\ncommon beginner mistakes\na verification checklist\nWhere the repository does not already contain validated evidence for exact broader setup instructions, the page now marks those areas for later verification against official CKB documentation.\n3. RPC Basics Documentation Added In The Existing RPC Section\nThe existing document at docs/05-rpc-setup.md was expanded and reframed as an RPC basics page while keeping the current file structure intact.\nThe updated section now explains:\nwhat RPC means\nwhy RPC matters in CKB development\nthe difference between local RPC and public RPC\nthe health-check concept used during onboarding\nwhat a successful response means\nwhat failure usually means\n4. Local Checkpoint Guidance Folded Into The Existing Milestone 2 Flow\nInstead of creating a new top-level numbered document, the local-check guidance was kept inside the existing Milestone 2 documentation flow so the repository structure remained unchanged.\nThis checkpoint guidance now emphasizes:\nconfirming that the basic local tools still work\nconfirming that terminal handling is no longer a blocker\nconfirming that the node or RPC path is still reachable\nconfirming that the developer knows which endpoint actually worked\nconfirming that official documentation should still be used whenever the repository marks a detail for later verification\nconfirming that a beginner can classify common early failure types before assuming the node is broken\nThis keeps the Milestone 2 readiness checks practical without creating an unplanned structural change in the docs directory.\n5. README Scope Messaging Updated For Milestone 2\nThe top-level README was updated so the repository no longer reads as if only Milestone 1 exists.\nThe updated wording now makes it clear that:\nMilestone 1 remains the completed documentation foundation\nMilestone 2 has started\nthe first Milestone 2 additions are CKB-specific setup, RPC basics, and local verification guidance\nlater sections are still placeholders unless validated\nThis improves project-state clarity without claiming that Milestone 2 is complete.\n6. Commands For Week 1 Milestone 2 Were Kept Explicit\nThe Week 1 Milestone 2 documentation includes the following exact commands where repository validation already existed:\nnpm install -g @offckb/cli\noffckb --help\noffckb node\noffckb clean\nExample local RPC validation command (tested against local CKB node)\nThe documentation did not add new exact commands in areas that are still marked for later verification.\nRemaining Scope For Week 2 Of Milestone 2\nThe second week of Milestone 2 should focus on completing the remaining planned CKB-specific content modules that are still placeholders.\nThe next sections to complete are:\ndocs/06-indexer-setup.md\ndocs/08-first-developer-workflow.md\ndocs/09-common-errors-and-remediation.md\ndocs/10-troubleshooting-matrix.md\ndocs/11-ai-assisted-debugging.md\ndocs/12-ckb-mental-model.md\ndocs/13-common-misconceptions.md\ndocs/13-common-misconceptions.md", "content_html": "

Hello @xingtianchunyan, here is the report for Week 1 (overall week 3) Milestone 2

\n

Week 1 Milestone 2 Progress Report

\n

Status

\n

Milestone 1 has been completed.

\n

Milestone 2 has started, and the Week 1 scope has been completed in the local repository workspace.

\n

Work Completed

\n

1. First CKB-Specific Overview Layer Added

\n

The existing document at docs/03-quick-start.md was repurposed to fit the current repository structure and now works as the first CKB-specific overview layer.

\n

This section now explains:

\n\n

This was done without creating duplicate files or breaking the Milestone 1 document ordering.

\n

2. CKB Node Setup Guidance Expanded

\n

The existing document at docs/04-ckb-node-setup.md was expanded from a narrower setup page into a more practical onboarding decision guide.

\n

The updated section now covers:

\n\n

Where the repository does not already contain validated evidence for exact broader setup instructions, the page now marks those areas for later verification against official CKB documentation.

\n

3. RPC Basics Documentation Added In The Existing RPC Section

\n

The existing document at docs/05-rpc-setup.md was expanded and reframed as an RPC basics page while keeping the current file structure intact.

\n

The updated section now explains:

\n\n

4. Local Checkpoint Guidance Folded Into The Existing Milestone 2 Flow

\n

Instead of creating a new top-level numbered document, the local-check guidance was kept inside the existing Milestone 2 documentation flow so the repository structure remained unchanged.

\n

This checkpoint guidance now emphasizes:

\n\n

This keeps the Milestone 2 readiness checks practical without creating an unplanned structural change in the docs directory.

\n

5. README Scope Messaging Updated For Milestone 2

\n

The top-level README was updated so the repository no longer reads as if only Milestone 1 exists.

\n

The updated wording now makes it clear that:

\n\n

This improves project-state clarity without claiming that Milestone 2 is complete.

\n

6. Commands For Week 1 Milestone 2 Were Kept Explicit

\n

The Week 1 Milestone 2 documentation includes the following exact commands where repository validation already existed:

\n\n

The documentation did not add new exact commands in areas that are still marked for later verification.

\n

Remaining Scope For Week 2 Of Milestone 2

\n

The second week of Milestone 2 should focus on completing the remaining planned CKB-specific content modules that are still placeholders.

\n

The next sections to complete are:

\n", "like_count": 0, "quote_count": 0 } ] } ] }