{ "base_url": "https://talk.nervos.org", "generated_at": "2026-04-29T18:10:37.230175+00:00", "since": "2026-04-28T18:10:29.347082+00:00", "until": "2026-04-29T18:10:29.347082+00:00", "window_hours": 24, "topics": [ { "topic_id": 10045, "title": "Spark Program | fiber-checkout — A \"Stripe-Style\" React Payment Library for Fiber Network", "slug": "spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network", "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045", "created_at": "2026-03-08T15:01:59.345000+00:00", "last_posted_at": "2026-04-29T12:43:50.204000+00:00", "category_id": 49, "tags": [ "Completion", "Spark-Program" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24064, "post_number": 28, "topic_id": 10045, "topic_title": "Spark Program | fiber-checkout — A \"Stripe-Style\" React Payment Library for Fiber Network", "topic_slug": "spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network", "author": "SalmanDev", "created_at": "2026-04-29T09:53:51.156000+00:00", "updated_at": "2026-04-29T09:53:51.156000+00:00", "reply_to_post_number": 27, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/28", "content_text": "Thank you @xingtianchunyan, @zz_tovarishch, and @Hanssen — and the full Spark Program committee.\nThis was my first time building developer tooling the network, and honestly the review process made the project significantly better than what I would have shipped on my own.\nThe committee’s final evaluation of where Fiber sits in the broader Crypto Payment landscape and what the ecosystem still needs is more thorough than I expected and useful to read as a developer building in this space. I’ll be referring back to it.\nFiber-checkout is live, open source, and MIT licensed. If anyone in the community wants to integrate it, contribute, or build on top of it, the repo is open and I’m reachable on Discord at salmansarwarr32.\nFinally, thank you to the CKB community for the support and time.\nSalman", "content_html": "

Thank you @xingtianchunyan, @zz_tovarishch, and @Hanssen — and the full Spark Program committee.

\n

This was my first time building developer tooling the network, and honestly the review process made the project significantly better than what I would have shipped on my own.

\n

The committee’s final evaluation of where Fiber sits in the broader Crypto Payment landscape and what the ecosystem still needs is more thorough than I expected and useful to read as a developer building in this space. I’ll be referring back to it.

\n

Fiber-checkout is live, open source, and MIT licensed. If anyone in the community wants to integrate it, contribute, or build on top of it, the repo is open and I’m reachable on Discord at salmansarwarr32.

\n

Finally, thank you to the CKB community for the support and time.

\n

Salman

", "like_count": 0, "quote_count": 0 }, { "post_id": 24065, "post_number": 29, "topic_id": 10045, "topic_title": "Spark Program | fiber-checkout — A \"Stripe-Style\" React Payment Library for Fiber Network", "topic_slug": "spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network", "author": "yifenzi", "created_at": "2026-04-29T12:43:50.204000+00:00", "updated_at": "2026-04-29T12:43:50.204000+00:00", "reply_to_post_number": 27, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/29", "content_text": "对一些可喜进展的一点建议\n把ckb的重心转移到支付领域是正确的，应该说对几乎所有公链来说，金融货币支付等领域即便不是全部也应该是绝大部分\n商户和用户采用意愿的挖掘和实现是核心\n实现上的技术需要我相信对ckb不是问题\n就提一点关于商户和用户意愿的挖掘:\n很简单，全世界一百多个法币地区对应的隐射币以及金银等大宗商品的隐射币\n不只是美元欧元隐射币，还有很多国家地区没有对应的隐射币，这就是ckb/fiber的机会，泰国币隐射币UtxoTHB对生活在泰国又没有银行账户的人来说就是极其方便的，同样肯尼亚币UtxoKES也是如此……\n全世界目前还有近二十亿人没有银行账户，他们就是第一受众，我们需要提供的就是一个“类本地银行账户”:一个本地银行以及本地货币账户；而对有银行账户的人，一个更方便匿名安全的开户方式也足够吸引力\n后来者超越的一个关键:人无我有，人有我优\n在全世界所有货币隐射币这条路上，人无我有目前还保存着空间\n如何实现:\n也许还有其他更好的技术实现路径比如合约，但今天说一个非合约也能实现的参考\n用现有的utxoswap，团队先生成一个多签地址，用这个地址生成需要的所有国家隐射币和一大笔ckb(或者fiber发的代币)一起去一个个的组LP，然后这个多签地址今后都不再动用，确定不会被任何人挪用即可(可以设置10/10甚至100/100的多签，总之难度越大越好，这是因为目的就是以后不用，是平常多签的反向使用)\n这里如果用ckb就需要一大笔的一次性投入，如果用fiber就可以在代币发行时就考虑好\n同时utxoswap的定位转变成整个ckb的基础设施也就是不谋求盈利，也不收费(除了交互的链上手续费)组LP没有利润空间且普通会员更不必参与，只是让ckb或fiber为一系列的utxo隐射币提供价值保证\n这个工作可以由某个神秘的团队来做，一堆代币一个多签地址组好LP后从此消失\n在稳定币/隐射币上不要想着盈利空间，一旦如此想必然滑向中心化和所谓合规和审查，只能走彻底去中心化的路，把利好的链条转向整个公链(ckb)或项目(fiber)", "content_html": "

对一些可喜进展的一点建议

\n

把ckb的重心转移到支付领域是正确的，应该说对几乎所有公链来说，金融货币支付等领域即便不是全部也应该是绝大部分

\n

商户和用户采用意愿的挖掘和实现是核心

\n

实现上的技术需要我相信对ckb不是问题

\n

就提一点关于商户和用户意愿的挖掘:

\n

很简单，全世界一百多个法币地区对应的隐射币以及金银等大宗商品的隐射币

\n

不只是美元欧元隐射币，还有很多国家地区没有对应的隐射币，这就是ckb/fiber的机会，泰国币隐射币UtxoTHB对生活在泰国又没有银行账户的人来说就是极其方便的，同样肯尼亚币UtxoKES也是如此……

\n

全世界目前还有近二十亿人没有银行账户，他们就是第一受众，我们需要提供的就是一个“类本地银行账户”:一个本地银行以及本地货币账户；而对有银行账户的人，一个更方便匿名安全的开户方式也足够吸引力

\n

后来者超越的一个关键:人无我有，人有我优

\n

在全世界所有货币隐射币这条路上，人无我有目前还保存着空间

\n

如何实现:

\n

也许还有其他更好的技术实现路径比如合约，但今天说一个非合约也能实现的参考

\n

用现有的utxoswap，团队先生成一个多签地址，用这个地址生成需要的所有国家隐射币和一大笔ckb(或者fiber发的代币)一起去一个个的组LP，然后这个多签地址今后都不再动用，确定不会被任何人挪用即可(可以设置10/10甚至100/100的多签，总之难度越大越好，这是因为目的就是以后不用，是平常多签的反向使用)

\n

这里如果用ckb就需要一大笔的一次性投入，如果用fiber就可以在代币发行时就考虑好

\n

同时utxoswap的定位转变成整个ckb的基础设施也就是不谋求盈利，也不收费(除了交互的链上手续费)组LP没有利润空间且普通会员更不必参与，只是让ckb或fiber为一系列的utxo隐射币提供价值保证

\n

这个工作可以由某个神秘的团队来做，一堆代币一个多签地址组好LP后从此消失

\n

在稳定币/隐射币上不要想着盈利空间，一旦如此想必然滑向中心化和所谓合规和审查，只能走彻底去中心化的路，把利好的链条转向整个公链(ckb)或项目(fiber)

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 8572, "title": "TeamCKB Dev Log (Updated: Apr 29, 2026)", "slug": "teamckb-dev-log-updated-apr-29-2026", "url": "https://talk.nervos.org/t/teamckb-dev-log-updated-apr-29-2026/8572", "created_at": "2024-12-26T07:32:39.609000+00:00", "last_posted_at": "2026-04-29T02:01:11.417000+00:00", "category_id": 32, "tags": [ "CKB", "CKB-VM" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24063, "post_number": 35, "topic_id": 8572, "topic_title": "TeamCKB Dev Log (Updated: Apr 29, 2026)", "topic_slug": "teamckb-dev-log-updated-apr-29-2026", "author": "CKBdev", "created_at": "2026-04-29T02:01:11.417000+00:00", "updated_at": "2026-04-29T02:01:11.417000+00:00", "reply_to_post_number": 34, "url": "https://talk.nervos.org/t/teamckb-dev-log-updated-apr-29-2026/8572/35", "content_text": "Updates\nFeatures\nDifferential Testing Framework for ckb-vm\nImplemented a differential test framework for ckb-vm. This provides a stronger foundation for validating optimizations and future architecture changes: GitHub - yuqiliu617/ckb-vm-contrib at differential-test · GitHub\nCKB DAO Treasury Design & Voting Research\nresearch on the CKB DAO Treasury design and voting settlement, with multiple directions under active discussion:\nOption 1: DAO-Bound Voting with Off-Chain State\nExplores a governance model where voting power is bound to Nervos DAO deposits, while proposal state, voting records, and tally data are maintained off-chain and committed on-chain through verifiable state roots.\nThis direction focuses on improving scalability while keeping governance state verifiable.\nOption 2: Experimental MVP Implementation\nBuilt an experimental MVP to validate core DAO Treasury workflows and voting-related transaction construction. Details see: ckb/dao-treasury at dao-treasury · chenyukang/ckb · GitHub\nOption 3: Rollup-inspired Voting Settlement\nExplores a rollup-inspired approach for voting settlement, where voting data is batched and compressed into verifiable state updates.\nThis direction focuses on improving settlement efficiency while preserving on-chain verifiability under CKB’s UTXO model.\nKey Question Identified & Follow-Up Research\nHow to handle on-chain settlement for the voting process. Continued follow-up research based on the design discussions:\nEvaluation of CKB partial transaction design based on the newly proposed voting architecture.\nA zkVM-based solution for voting.\nImprovements & Fixes\nCryptography & Performance\nckb-vm ARM64 optimization\nA series of optimizations were merged into ckb-vm to improve performance on ARM64-based hardware:\nSHxADD / ADDUW Instruction Optimization on AArch64 ckb-vm#504\nMULHSU Instruction Optimization on AArch64 ckb-vm#505\nDivision and Remainder Instruction Optimization on AArch64 ckb-vm#506\nAdd Fuzz Tests for RVM Instructions ckb-vm#507\nFinished optimization for Module-Lattice-Based Digital Signature Algorithm (ML-DSA).\nThis further prepares the network for post-quantum cryptographic standards: GitHub - XuJiandong/signatures at use-opt-shake128 · GitHub\nInfra & Tooling\nUpgraded CKB toolchain to 1.95.0: [rust-toolchain] Upgrade Rust toolchain to 1.95.0 #5175\nAdded SKILL.md for AI agents in ckb-debugger, making it easier for agents to assist devs in debugging CKB scripts.: Add SKILL.md for AI agents ckb-standalone-debugger#202\nFixed rich-indexer prefix search upper bound leading zero bytes issue: Incorrect prefix search results in Rich Indexer due to get_binary_upper_boundary() dropping leading zero bytes. #5165\nRe-organized molecule’s Cargo workspace structure: Organize Rust crates into a Cargo workspace molecule#115\nSynced the [ckb musl](GitHub - nervosnetwork/musl: A fork of https://git.musl-libc.org/cgit/musl with Nervos CKB changes · GitHub) fork with upstream: GitHub - mohanson-fork/musl at newest · GitHub\nNetworking & Connectivity\nContinued QUIC support for Tentacle:\nQUIC / UDP address parsing: quic: support quic/udp address parsing tentacle#430\nCertificate generation and verification, plus a simple QUIC smoke test:quic: cert generating and verifying, simple quic smoke test tentacle#431\nThe underlying P2P network Tentacle, is moving closer to full QUIC support. QUIC (built on UDP) provides faster handshake times and better resilience against connection migration compared to standard TCP.\nIn Pipeline\nCore Maintenance & Release Prep\nRocksDB key schema refactor: [BREAKING CHANGE] Refactor rocksdb schema to reduce Read/Write Amplification #5085\nUse the differential test framework to verify CKB-optimized libraries, including sha256, sha512, fip202, and others.\nPrepare for the next CKB release.\nNetworking\nContinue QUIC support for tentacle:\nRustls verifier for QUIC certificate\nQUIC session implementation\nServiceBuilder integration\nGovernance PoC\nContinue the zkVM-based voting system, including spec and demo / PoC.\nReview the previous open transaction design and continue investigating the partial transaction approach.", "content_html": "

Updates

\n

Features

\n

Differential Testing Framework for ckb-vm

\n

Implemented a differential test framework for ckb-vm. This provides a stronger foundation for validating optimizations and future architecture changes: GitHub - yuqiliu617/ckb-vm-contrib at differential-test · GitHub

\n

CKB DAO Treasury Design & Voting Research

\n

research on the CKB DAO Treasury design and voting settlement, with multiple directions under active discussion:

\n\n

Explores a governance model where voting power is bound to Nervos DAO deposits, while proposal state, voting records, and tally data are maintained off-chain and committed on-chain through verifiable state roots.

\n

This direction focuses on improving scalability while keeping governance state verifiable.

\n\n

Built an experimental MVP to validate core DAO Treasury workflows and voting-related transaction construction. Details see: ckb/dao-treasury at dao-treasury · chenyukang/ckb · GitHub

\n\n

Explores a rollup-inspired approach for voting settlement, where voting data is batched and compressed into verifiable state updates.

\n

This direction focuses on improving settlement efficiency while preserving on-chain verifiability under CKB’s UTXO model.

\n

Key Question Identified & Follow-Up Research

\n

How to handle on-chain settlement for the voting process. Continued follow-up research based on the design discussions:

\n\n
\n

Improvements & Fixes

\n

Cryptography & Performance

\n\n

A series of optimizations were merged into ckb-vm to improve performance on ARM64-based hardware:

\n\n

This further prepares the network for post-quantum cryptographic standards: GitHub - XuJiandong/signatures at use-opt-shake128 · GitHub

\n

Infra & Tooling

\n\n

Networking & Connectivity

\n\n

The underlying P2P network Tentacle, is moving closer to full QUIC support. QUIC (built on UDP) provides faster handshake times and better resilience against connection migration compared to standard TCP.

\n

In Pipeline

\n

Core Maintenance & Release Prep

\n\n

Networking

\n\n

Governance PoC

\n", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10214, "title": "Spark Program | CKB-VM Sail Formal Verification — Proving CKB-VM RISC-V Instruction Equivalence via Sail Specification and Coq Theorem Prover / CKB-VM Sail 形式化验证 — 基于 Sail 规范与 Coq 定理证明器的 CKB-VM RISC-V 指令等价性证明", "slug": "spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v", "url": "https://talk.nervos.org/t/spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v/10214", "created_at": "2026-04-27T21:14:40.905000+00:00", "last_posted_at": "2026-04-29T02:00:41.314000+00:00", "category_id": 49, "tags": [ "Spark-Program" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24062, "post_number": 4, "topic_id": 10214, "topic_title": "Spark Program | CKB-VM Sail Formal Verification — Proving CKB-VM RISC-V Instruction Equivalence via Sail Specification and Coq Theorem Prover / CKB-VM Sail 形式化验证 — 基于 Sail 规范与 Coq 定理证明器的 CKB-VM RISC-V 指令等价性证明", "topic_slug": "spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v", "author": "xingtianchunyan", "created_at": "2026-04-29T02:00:41.314000+00:00", "updated_at": "2026-04-29T02:00:41.314000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-vm-sail-formal-verification-proving-ckb-vm-risc-v-instruction-equivalence-via-sail-specification-and-coq-theorem-prover-ckb-vm-sail-sail-coq-ckb-vm-risc-v/10214/4", "content_text": "@TinyuengKwan 你好，感谢提交 ckb-vm-sail-verify 的提案。这个方向非常关键：CKB-VM 是 CKB 的执行层安全基石，而你提出的 “Sail（官方规范）+ Coq（形式化证明）+ 差分测试（工程验证）” 的双轨方案，也能看出你在 Sail/ACT 生态中有相对稀缺的一手经验与工程积累。\n需要说明的是，该项目已明显超出星火计划的支持范围（以 低门槛、快节奏 的方式帮助社区开发者启动小型原型项目）。如果你仍希望向委员会正式递交该项目，那么在提交委员会正式评审前，我个人建议你按 Spark 的预审要求补充/澄清以下几点信息，让评审能更快收敛到“本期资助是什么、怎么验收、验收失败影响什么”。\n1) 验证方案（How to Verify）——写成“可复现步骤 + 通过/失败标准 + 影响面（blast radius）”\n你在主贴里讲清楚了技术架构与实现设想，但仍缺少一段面向评审者/社区的 “低成本、可重复” 的验收章节。建议新增一个独立章节 How to Verify（或在 repo 内提供 VERIFICATION.md），至少包含：\n1.1 可复现步骤（评审者照着做即可）\n建议最少做到以下级别：\n环境一键化：提供 Docker/Nix/脚本，确保在干净 Linux 环境下可以复现（并 pin 关键依赖版本：Sail/Coq/OPAM/Rust 等）。\n生成与构建：从 sail-riscv 生成 Coq 产物的命令（以及预期输出在哪里）。\n证明检查：如何运行 Coq proof check（命令 + 预期输出）。\n差分测试：如何运行 diff-test（命令 + 测试集来源 + mismatch 报告格式）。\n证据发布位置：每个里程碑的证据放在哪里（release tag / CI artifact / 报告 / 日志）。\n1.2 通过/失败标准（必须可判定）\n形式化验证最大的风险，是“最后没有一个可客观判定的结果”。请明确写清：\n本期承诺证明/验证的指令子集是什么（例如 RV64I 的某些指令集合；或只覆盖 CKB-VM 的某个 VERSION 模式——你提到 VERSION2 only 的倾向，需要明确）。\n对 Coq 证明的要求：是否允许 admit？若允许，允许到什么边界（建议明确为“0 admitted”或“admitted 上限”）。\n差分测试的要求：覆盖哪些测试集（riscv-tests / riscv-arch-test / 自建 corpus），以及遇到 mismatch 的处理策略（“发现问题即成果” vs “必须修到一致才算通过”）。\n1.3 影响面（blast radius）与“保证边界”\n由于 CKB-VM 属于执行层安全边界，请你在文档中非常明确地写清：\n保证了什么：例如“对某版本/某子集/某模型假设下的语义等价”。\n没有保证什么：例如 MOP 扩展、cycle 计费、syscall/ECALL 语义差异、flat 4MB memory model 的限制、并发/原子指令的模型化边界等。\n如果外部误解为“全量等价/全链安全已证明”，可能造成的误用风险是什么，以及你准备如何在 README/报告中避免过度解读。\n2) 结项后的维护计划（持续有效性）\n形式化验证的成果很容易因上游演进而失效。建议你补充：\n你承诺维护的窗口（例如覆盖到 ckb-vm 的哪些版本线；以及 sail-riscv 更新后的跟进方式）。\nCI 策略：是否会把 proof check + diff-test 做成持续集成（例如 weekly/nightly），并在 README 放 badge。\n交接方案：如果你后续无法维护，社区如何接手（依赖锁定、脚本、文档、最小复现路径）。\n3) 部署架构与安全性（供应链 / 可信边界 / 结果可审计性）\n该项目不是线上服务，但仍然有“可信边界”与“供应链安全”需要写清：\n工具链与依赖如何 pin 版本（OPAM/Coq/Sail 等），避免“换个时间/换台机器就跑不出来”。\n是否提供可重复构建说明（reproducible build）与产物校验方式（hash / release artifact）。\n对外发布时的“声明口径”：建议在最终报告中用一段固定文本写清适用范围与非目标（避免被当作全量安全证明）。\n请在针对以上建议优化后 @ 我一下，我们再把更新版本提交委员会进入正式评审流程。", "content_html": "

@TinyuengKwan 你好，感谢提交 ckb-vm-sail-verify 的提案。这个方向非常关键：CKB-VM 是 CKB 的执行层安全基石，而你提出的 “Sail（官方规范）+ Coq（形式化证明）+ 差分测试（工程验证）” 的双轨方案，也能看出你在 Sail/ACT 生态中有相对稀缺的一手经验与工程积累。

\n

需要说明的是，该项目已明显超出星火计划的支持范围（以 低门槛、快节奏 的方式帮助社区开发者启动小型原型项目）。如果你仍希望向委员会正式递交该项目，那么在提交委员会正式评审前，我个人建议你按 Spark 的预审要求补充/澄清以下几点信息，让评审能更快收敛到“本期资助是什么、怎么验收、验收失败影响什么”。

\n
\n

1) 验证方案（How to Verify）——写成“可复现步骤 + 通过/失败标准 + 影响面（blast radius）”

\n

你在主贴里讲清楚了技术架构与实现设想，但仍缺少一段面向评审者/社区的 “低成本、可重复” 的验收章节。建议新增一个独立章节 How to Verify（或在 repo 内提供 VERIFICATION.md），至少包含：

\n

1.1 可复现步骤（评审者照着做即可）

\n

建议最少做到以下级别：

\n
    \n
  1. 环境一键化：提供 Docker/Nix/脚本，确保在干净 Linux 环境下可以复现（并 pin 关键依赖版本：Sail/Coq/OPAM/Rust 等）。
    2. \n
  2. 生成与构建：从 sail-riscv 生成 Coq 产物的命令（以及预期输出在哪里）。
    3. \n
  3. 证明检查：如何运行 Coq proof check（命令 + 预期输出）。
    4. \n
  4. 差分测试：如何运行 diff-test（命令 + 测试集来源 + mismatch 报告格式）。
    5. \n
  5. 证据发布位置：每个里程碑的证据放在哪里（release tag / CI artifact / 报告 / 日志）。
    6. \n
\n

1.2 通过/失败标准（必须可判定）

\n

形式化验证最大的风险，是“最后没有一个可客观判定的结果”。请明确写清：

\n\n

1.3 影响面（blast radius）与“保证边界”

\n

由于 CKB-VM 属于执行层安全边界，请你在文档中非常明确地写清：

\n\n
\n

2) 结项后的维护计划（持续有效性）

\n

形式化验证的成果很容易因上游演进而失效。建议你补充：

\n\n
\n

3) 部署架构与安全性（供应链 / 可信边界 / 结果可审计性）

\n

该项目不是线上服务，但仍然有“可信边界”与“供应链安全”需要写清：

\n\n
\n

请在针对以上建议优化后 @ 我一下，我们再把更新版本提交委员会进入正式评审流程。

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10212, "title": "Spark Program | Dular", "slug": "spark-program-dular", "url": "https://talk.nervos.org/t/spark-program-dular/10212", "created_at": "2026-04-26T16:35:20.268000+00:00", "last_posted_at": "2026-04-29T01:49:03.597000+00:00", "category_id": 49, "tags": [ "Spark-Program", "Submitted" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24061, "post_number": 4, "topic_id": 10212, "topic_title": "Spark Program | Dular", "topic_slug": "spark-program-dular", "author": "xingtianchunyan", "created_at": "2026-04-29T01:49:03.597000+00:00", "updated_at": "2026-04-29T01:49:36.043000+00:00", "reply_to_post_number": 3, "url": "https://talk.nervos.org/t/spark-program-dular/10212/4", "content_text": "@duongja 你好，感谢你提交 Dular 项目提案，并根据预审建议补充了 How to Verify、预算拆分与风险说明等内容。整体方向（Fiber + RUSD/UDT + 真实在地试点）很契合 Spark 对“可落地、可验证”的资助导向。\n本项目当前状态暂定为 Pending，并非否定项目价值，而是表示：在进入下次正式评审/投票前，我们还需要你补齐两类“可验证凭据”，并纠正提案中关于 CKB 发放与汇率折算机制的表述，以避免后续沟通成本与验收争议。\n1) 请补充：Daraja 生产环境凭据的可视化证据。\n你已声明持有 STK Push + B2C 生产凭据，请通过私信发我一张 Daraja Developer Portal 的后台截图（API Key 字段可全部打码，但需保留 Production 环境标识、App 名称、创建时间）。这一步用于委员会内部尽调，不会公开。委员会在验证后，会在本帖中发布一条信息，说明已经核验。\n2) 请补充：现有 multi-hop RUSD payment 的可核验证据。\n为了让委员会/社区能低成本持续复核你的技术交付（而不是只在结项时“补材料”），请在主楼直接给出对应的 Fiber payment hash 或相关 CKB testnet tx hash，并简要说明 Fiber payment hash 与 CKB L1 explorer 的对应关系（避免读者误以为每笔 Fiber 支付都能在 CKB explorer 直查）。\n3) 关于 CKB 发放与汇率风险：请修正提案中的流程假设，并按 Spark 口径重写\n你在提案的 “CKB Disbursement & Exchange Rate Risk” 中写到：\n“The CKB amount per milestone will be calculated at the market rate on the day of disbursement, per standard Spark procedure.”\n这里需要更正：Spark 的标准口径不是“每次发放按当日汇率重新折算 CKB”。\nSpark 2026 资金口径：\n发放币种：当前周期 Spark 资助仅支持100% 以 CKB 形式发放。\n折算口径（锁定）：委员会通常以 USD 口径沟通资助额度以便横向对比；但若以 CKB 发放，则会在项目审批通过时点以当时参考汇率折算并确定该项目的 CKB 总额，并在对外决议/公告中公示。后续发放以约定的 CKB 数额为基准执行，不随每次发放当日价格重新折算。\n汇率风险：审批通过后至实际支出期间，CKB 价格波动导致的购买力变化风险由提案申请人/团队自行承担，这是CKB生态相关grants的惯例。对存在法币硬成本的项目，建议在收到款项后及时换汇/锁定硬成本，并在预算中清晰区分“硬成本 vs 人力成本”。\n下一步\n请根据上述内容优化提案后，在本帖回复“已更新”并@xingtianchunyan，并标明你更新了主楼的哪些小节/新增了哪些链接或附件。委员会会在信息齐备后尽快推进正式评审流程。\n祝好，\n行天\n代表星火计划委员会", "content_html": "

@duongja 你好，感谢你提交 Dular 项目提案，并根据预审建议补充了 How to Verify、预算拆分与风险说明等内容。整体方向（Fiber + RUSD/UDT + 真实在地试点）很契合 Spark 对“可落地、可验证”的资助导向。

\n

本项目当前状态暂定为 Pending，并非否定项目价值，而是表示：在进入下次正式评审/投票前，我们还需要你补齐两类“可验证凭据”，并纠正提案中关于 CKB 发放与汇率折算机制的表述，以避免后续沟通成本与验收争议。

\n
\n

1) 请补充：Daraja 生产环境凭据的可视化证据。

\n

你已声明持有 STK Push + B2C 生产凭据，请通过私信发我一张 Daraja Developer Portal 的后台截图（API Key 字段可全部打码，但需保留 Production 环境标识、App 名称、创建时间）。这一步用于委员会内部尽调，不会公开。委员会在验证后，会在本帖中发布一条信息，说明已经核验。

\n
\n

2) 请补充：现有 multi-hop RUSD payment 的可核验证据。

\n

为了让委员会/社区能低成本持续复核你的技术交付（而不是只在结项时“补材料”），请在主楼直接给出对应的 Fiber payment hash 或相关 CKB testnet tx hash，并简要说明 Fiber payment hash 与 CKB L1 explorer 的对应关系（避免读者误以为每笔 Fiber 支付都能在 CKB explorer 直查）。

\n
\n

3) 关于 CKB 发放与汇率风险：请修正提案中的流程假设，并按 Spark 口径重写

\n

你在提案的 “CKB Disbursement & Exchange Rate Risk” 中写到：

\n
\n

“The CKB amount per milestone will be calculated at the market rate on the day of disbursement, per standard Spark procedure.”

\n
\n

这里需要更正：Spark 的标准口径不是“每次发放按当日汇率重新折算 CKB”。

\n

Spark 2026 资金口径：

\n
    \n
  1. 发放币种：当前周期 Spark 资助仅支持100% 以 CKB 形式发放。
    2. \n
  2. 折算口径（锁定）：委员会通常以 USD 口径沟通资助额度以便横向对比；但若以 CKB 发放，则会在项目审批通过时点以当时参考汇率折算并确定该项目的 CKB 总额，并在对外决议/公告中公示。后续发放以约定的 CKB 数额为基准执行，不随每次发放当日价格重新折算。
    3. \n
  3. 汇率风险：审批通过后至实际支出期间，CKB 价格波动导致的购买力变化风险由提案申请人/团队自行承担，这是CKB生态相关grants的惯例。对存在法币硬成本的项目，建议在收到款项后及时换汇/锁定硬成本，并在预算中清晰区分“硬成本 vs 人力成本”。
    4. \n
\n
\n

下一步

\n

请根据上述内容优化提案后，在本帖回复“已更新”并@xingtianchunyan，并标明你更新了主楼的哪些小节/新增了哪些链接或附件。委员会会在信息齐备后尽快推进正式评审流程。

\n

祝好，
\n行天
\n代表星火计划委员会

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