Quantir proposes to build a CKB-aware risk intelligence and monitoring layer for the Nervos ecosystem. The system will monitor selected public CKB ecosystem activity, detect abnormal behavior, compute normalized risk signals, and deliver explainable alerts for developers, ecosystem operators, dashboards, and community monitoring workflows.
\nQuantir is an existing DeFi and on-chain risk monitoring platform with live collectors, transaction monitoring, risk scoring, alert delivery, API/WebSocket interfaces, and explainability services. This proposal adapts the existing Quantir architecture to CKB-specific ecosystem signals rather than building a monitoring system from scratch.
\nRequested budget: $30,000 equivalent in CKB.
\nEstimated duration: 10 weeks.
\nPayment structure: milestone-based.
Project Motivation
\nCKB is a flexible and interoperable Layer 1 with a unique Cell model, xUDT/token capabilities, cross-chain potential, Bitcoin-related infrastructure, payment-channel development, and a growing application ecosystem. This flexibility is valuable, but it also makes ecosystem monitoring harder.
Developers and operators can inspect raw activity through explorers, dashboards, and individual tools, but there is no unified layer that turns ecosystem activity into structured, explainable risk signals. Important conditions such as unusual token flows, bridge-related stress, abnormal contract or cell activity, liquidity pressure, payment-channel anomalies, or DAO fund-flow risks may be noticed only after they become obvious.
\nQuantir aims to provide earlier and clearer visibility by converting fragmented public signals into normalized scores, alerts, and explanations.
\nProposal Overview
\nQuantir will build a CKB-specific monitoring module focused on public ecosystem signals. The system will collect and normalize selected CKB activity, detect abnormal patterns, score risk conditions, and generate alerts that can be consumed by dashboards, bots, APIs, or ecosystem monitoring tools.
The proposed module will focus on:
\nCKB ecosystem activity monitoring.
\nxUDT/token-flow anomaly detection.
\nBridge and cross-chain activity monitoring.
\nCKB DeFi and liquidity-risk signals.
\nAbnormal contract/cell activity detection.
\nDAO/community fund activity monitoring.
\nFiber/payment-channel risk signals where public data is available.
\nAPI/WebSocket-ready alert outputs.
\nHuman-readable explanations for risk events.
\nValidation examples and technical documentation.
This work will not modify CKB consensus, CKB-VM, core protocol code, or wallet infrastructure. It will operate as an external monitoring and intelligence layer using public or reviewable ecosystem signals.
\nTechnical Approach
\nThe implementation will reuse Quantir’s existing multi-service architecture and adapt it to the Nervos ecosystem.
Core components:
\nData ingestion layer
\nCollects selected public CKB ecosystem signals, including token activity, contract/cell behavior, DAO-related activity, DeFi signals, bridge-related events, and other supported public data sources.
Signal normalization layer
\nTransforms raw activity into comparable risk features such as flow intensity, concentration, repeated address patterns, abnormal activity spikes, liquidity changes, and risk-score deltas.
Risk scoring layer
\nComputes normalized risk scores and score changes for monitored entities.
Strategy layer
\nDetects abnormal activity patterns and triggers alert conditions.
Explanation layer
\nGenerates human-readable explanations describing why an alert was triggered, what evidence supports it, and what changed.
Delivery layer
\nOutputs structured alert payloads suitable for APIs, WebSocket streams, dashboards, and bots.
Example alert output:
\nAlert category: xUDT flow anomaly
\nSeverity: medium
\nRisk score: 71
\nReason codes: sudden transfer spike, repeated address pattern, abnormal concentration
\nEvidence: transaction hashes, token identifier, addresses, timestamps
\nExplanation: “This token activity was flagged because transfer frequency increased sharply while repeated address patterns and concentrated flows appeared within the same monitoring window.”
Deliverables
\nCKB-specific monitoring scope and architecture document.
\nPublic signal taxonomy for CKB ecosystem risk.
\nStructured alert schema.
\nCKB-aware ingestion prototype.
\nRisk scoring and anomaly detection logic.
\nExplainable alert generation.
\nAPI/WebSocket-ready output format.
\nReference consumer or integration example.
\nAt least 5 alert categories.
\nAt least 10 sample alert scenarios.
\nSetup guide and testing documentation.
\nFinal validation report.
Key Performance Indicators
\nAt least 5 CKB-specific risk categories documented.
\nAt least 10 sample alert scenarios produced.
\nWorking prototype that generates structured CKB ecosystem alerts.
\nAlerts include severity, score, reason codes, evidence, and explanation.
\nReference consumer can read or display alert outputs.
\nDocumentation allows reviewers or developers to understand and test the prototype.
\nAt least 3 validation examples completed.
\nFinal report delivered to the Nervos community.
Milestones and Timeline
\nTotal duration: 10 weeks.
Milestone 1: Scope, CKB Signal Taxonomy, and Architecture
\nTimeline: Weeks 1-2
\nFunding requested: $6,000 equivalent in CKB
Deliverables:
\nCKB-specific monitoring scope.
\nPublic data-source mapping.
\nRisk category taxonomy.
\nInitial alert schema.
\nTechnical architecture document.
\nImplementation plan.
Success criteria:
\nAt least 5 risk categories are defined.
\nInitial alert schema is complete.
\nData-source assumptions and technical scope are documented.
Milestone 2: Ingestion Prototype and Normalized Risk Signals
\nTimeline: Weeks 3-5
\nFunding requested: $9,000 equivalent in CKB
Deliverables:
\nCKB-aware ingestion prototype.
\nNormalized signal generation.
\nInitial scoring logic.
\nSample alert generation.
\nBasic test coverage for core signal processing.
Success criteria:
\nPrototype can process selected public CKB ecosystem signals.
\nStructured alerts are generated from sample or public data.
\nAt least 5 alert categories are implemented in sample form.
Milestone 3: Explainable Alerts and Integration Outputs
\nTimeline: Weeks 6-8
\nFunding requested: $8,000 equivalent in CKB
Deliverables:
\nExplanation logic for alert events.
\nAPI/WebSocket-ready alert format.
\nReference consumer or integration example.
\nSample documentation for external consumers.
Success criteria:
\nAlerts contain severity, score, evidence, reason codes, and explanation.
\nReference integration can consume alert outputs.
\nDocumentation explains how ecosystem tools can use the outputs.
Milestone 4: Validation, Documentation, and Final Delivery
\nTimeline: Weeks 9-10
\nFunding requested: $7,000 equivalent in CKB
Deliverables:
\nAt least 3 validation examples.
\nAt least 10 sample alert scenarios.
\nFinal setup guide.
\nTesting guide.
\nFinal technical report.
\nPublic or reviewable repository with schemas, prototype code, examples, and documentation.
Success criteria:
\nReviewers can inspect or run the prototype.
\nAll milestone deliverables are documented.
\nFinal report summarizes results, limitations, and recommended next steps.
Budget
\nTotal funding requested: $30,000 equivalent in CKB.
Budget breakdown:
\nEngineering and CKB-specific integration: $12,000
\nRisk signal design and scoring logic: $5,000
\nAPI/WebSocket-ready outputs and reference integration: $4,000
\nValidation, testing, and documentation: $4,000
\nInfrastructure, data access, storage, and monitoring: $3,000
\nGrant reporting and contingency: $2,000
Payment structure: milestone-based.
\nSuggested initial payment: 20% of total budget, with the remaining amount distributed after milestone review.
Team
\nThe project will be delivered by the Quantir core team.
Ilya Berdar — Senior Blockchain Developer / Project Lead
\nResponsible for technical architecture, CKB integration scope, risk engine adaptation, grant communication, and final delivery.
Andriy Boichuk — Senior Software Developer
\nResponsible for backend services, data ingestion, infrastructure, normalization logic, tests, and deployment workflows.
Alex Grishenko — Senior Software Developer
\nResponsible for alert schemas, explanation outputs, reference integration, documentation, validation examples, and product implementation.
Relevant Links
\nQuantir landing page: https://landing.quantirintelligence.com/
\nQuantir app: https://app.quantirintelligence.com/
\nQuantir GitHub repository: https://github.com/quantirintelligence/quantir-risk-engine
Long-Term Plan
\nIf the pilot is successful, Quantir can expand CKB ecosystem monitoring to additional applications, bridges, tokens, DAO fund flows, DeFi systems, and payment-channel infrastructure. The long-term goal is to provide an explainable risk intelligence layer that helps the Nervos ecosystem improve visibility, resilience, and integration readiness.
Additional Notes
\nQuantir’s differentiator is that it combines monitoring, scoring, explainability, and alert delivery in one workflow. It does not only show charts or raw events; it translates ecosystem behavior into actionable, interpretable, machine-readable outputs.
This proposal is implementation-focused and designed to deliver reusable monitoring infrastructure for the Nervos ecosystem.
", "like_count": 0, "quote_count": 0 } ] }, { "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-04-30T11:53:50.160000+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": 24080, "post_number": 17, "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-04-30T11:53:50.160000+00:00", "updated_at": "2026-04-30T11:53:50.160000+00:00", "reply_to_post_number": 15, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/17", "content_text": "@phroi\nBy the way, if you don’t mind, I have been looking into using real CKB protocols as maturity benchmarks for CellScript, and your iCKB seems like a natural stress test candidate.\nThe idea is not to make any production-equivalence claim, but to use normalised differential fixtures to expose weak spots in the language model under realistic DAO/xUDT/accounting-heavy scenarios.\nIn practice, this would mean comparing behaviour under the same semantic inputs, capacities, output data, deps, headers and witnesses where relevant, allowing only the script-under-test code cell/hash to differ, and then executing both sides in CKB VM/testtool with pass/pass and fail/fail alignment, plus explicit evidence: hashes, exit codes, cycles, named failure modes, etc.\nI will likely start putting this together properly around the end of next month. If you are interested, I would really value your perspective when it reaches a more concrete stage.", "content_html": "\nBy the way, if you don’t mind, I have been looking into using real CKB protocols as maturity benchmarks for CellScript, and your iCKB seems like a natural stress test candidate.
\nThe idea is not to make any production-equivalence claim, but to use normalised differential fixtures to expose weak spots in the language model under realistic DAO/xUDT/accounting-heavy scenarios.
\nIn practice, this would mean comparing behaviour under the same semantic inputs, capacities, output data, deps, headers and witnesses where relevant, allowing only the script-under-test code cell/hash to differ, and then executing both sides in CKB VM/testtool with pass/pass and fail/fail alignment, plus explicit evidence: hashes, exit codes, cycles, named failure modes, etc.
\nI will likely start putting this together properly around the end of next month. If you are interested, I would really value your perspective when it reaches a more concrete stage.
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10015, "title": "[DIS] Decentralized privacy order-book appchain based on CKB L1 - 2026.phase-1", "slug": "dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1", "url": "https://talk.nervos.org/t/dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1/10015", "created_at": "2026-02-28T04:17:08.724000+00:00", "last_posted_at": "2026-04-30T07:31:16.411000+00:00", "category_id": 65, "tags": [ "appchain" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24076, "post_number": 23, "topic_id": 10015, "topic_title": "[DIS] Decentralized privacy order-book appchain based on CKB L1 - 2026.phase-1", "topic_slug": "dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1", "author": "Lawliet_Chan", "created_at": "2026-04-30T07:23:16.038000+00:00", "updated_at": "2026-04-30T07:23:31.349000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dis-decentralized-privacy-order-book-appchain-based-on-ckb-l1-2026-phase-1/10015/23", "content_text": "milestone.1 已完成\n代码仓库： GitHub - invisibook-lab/invisibook: A privacy-preserving, censorship-resistant, decentralized order book. · GitHub\n检验方式： invisibook/docs/milestones/test_guide_1.md at main · invisibook-lab/invisibook · GitHub", "content_html": "milestone.1 已完成
\n代码仓库： GitHub - invisibook-lab/invisibook: A privacy-preserving, censorship-resistant, decentralized order book. · GitHub
\n检验方式： invisibook/docs/milestones/test_guide_1.md at main · invisibook-lab/invisibook · GitHub
Hi Lawliet, 验证方法文档里只有中文，建议加上英文的版本
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10216, "title": "Streamlining the forum categories needs your testing and feedback", "slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216", "created_at": "2026-04-29T19:34:39.105000+00:00", "last_posted_at": "2026-04-30T07:24:50.112000+00:00", "category_id": 40, "tags": [], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24067, "post_number": 1, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "terrytai", "created_at": "2026-04-29T19:34:39.156000+00:00", "updated_at": "2026-04-29T20:31:41.560000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/1", "content_text": "TL;DR 最新的分类重构已经在 Staging Server 上线，欢迎大家测试和反馈意见：https://talk-staging.nervos.org/\nBabel Reunited enters public beta — a new foundation for the future development of Nervos Talk\nNervos Talk Renewal & Governance\n翻译插件已经全站开始测试.\nBabel Reunited 翻译插件已经测试一个多月了，经过大家的反馈和改进，现在翻译质量和体验已经比最初好了很多。\n这里回顾一下最初做这个插件的目的：\n为什么做 Babel Reunited\n这个插件是我专门为 Nervos Talk 开发的，最初只是为了解决两个痛点：\n在设计和管理 CKB Community Fund DAO 的论坛规则时，我必须用双语发帖。这非常麻烦：需要先用一种语言写原帖，再翻译后手动贴回帖子中。这个过程不仅容易出错，也经常遇到帖子字数超限的问题。同时，一些回复者和发帖者也不会严格按照规则贴两个语言的版本，这也给讨论带来了一些障碍。\nNervos Talk 最大的分类是按语言划分的，目前只有三种语言：英文、中文、西班牙语。而每个语言分类下又有很多重叠但不完全相同的子分类。这让我有时不得不在三个地方用不同语言发布同样的内容，也意味着不同语言背景的人几乎不可能在同一个 thread 中讨论同一个话题。\n其中第1点已经解决了，相信参与了的人都能体会到。现在是时候解决第二个问题，也是我认为 Nervos Talk 最大问题之一。\n最新的分类重构已经在 Staging Server 上线，欢迎大家测试和反馈意见：https://talk-staging.nervos.org/\n改了啥？\n新的顶层分类（统一适用于所有语言）：\nAnnouncements & Meta — 官方公告 / 论坛治理\nDevelopment — CKB / Layer 2 开发 / 开发框架 / DSL 等\nApplications & Ecosystem — 生态与应用：比如讨论 Neuron, Fiber 的使用和开发问题\nTheory & Design — 加密经济学与机制设计\nMiners Pub — 和挖矿相关的话题\nCommunity Space — 社区活动（DAO / Spark Program 等都在这里，未来考虑开放给社区申请）\nGeneral — 其他\nArchived — 只读归档区\n这次重构减少了非常多不必要的子分类，让讨论更加集中。\n还做了一些整理：\n老帖（>2 年无活动的闲聊/公告类）自动归档，但技术类老帖原样保留，作为未来参考\n历史上的 Q&A / Grants 分区整体进归档（保留可读）\nSpark Program 从标签升级成了 Community Space 下的子分类\n你需要做什么？\n邀请你看看 Staging Server: https://talk-staging.nervos.org/ 如果你对分类有建议可以直接回复本帖\n做好心理准备，也许这个重构可能会在一个月内上线\n如果你对实现有兴趣的话： GitHub - poshboytl/discourse-category-migration: Migration bundle for Nervos Talk category restructure · GitHub\n感谢 @zz_tovarishch 的论坛重构文档，我参考了其中不少内容", "content_html": "TL;DR 最新的分类重构已经在 Staging Server 上线，欢迎大家测试和反馈意见：https://talk-staging.nervos.org/
\n\n\nBabel Reunited 翻译插件已经测试一个多月了，经过大家的反馈和改进，现在翻译质量和体验已经比最初好了很多。
\n这里回顾一下最初做这个插件的目的：
\n\n\n为什么做 Babel Reunited
\n这个插件是我专门为 Nervos Talk 开发的，最初只是为了解决两个痛点：
\n\n
\n- \n
\n在设计和管理 CKB Community Fund DAO 的论坛规则时，我必须用双语发帖。这非常麻烦：需要先用一种语言写原帖，再翻译后手动贴回帖子中。这个过程不仅容易出错，也经常遇到帖子字数超限的问题。同时，一些回复者和发帖者也不会严格按照规则贴两个语言的版本，这也给讨论带来了一些障碍。
\n- \n
\nNervos Talk 最大的分类是按语言划分的，目前只有三种语言：英文、中文、西班牙语。而每个语言分类下又有很多重叠但不完全相同的子分类。这让我有时不得不在三个地方用不同语言发布同样的内容，也意味着不同语言背景的人几乎不可能在同一个 thread 中讨论同一个话题。
\n
其中第1点已经解决了，相信参与了的人都能体会到。现在是时候解决第二个问题，也是我认为 Nervos Talk 最大问题之一。
\n最新的分类重构已经在 Staging Server 上线，欢迎大家测试和反馈意见：https://talk-staging.nervos.org/
新的顶层分类（统一适用于所有语言）：
\n![\":red_circle:\"](\"https://talk.nervos.org/images/emoji/apple/red_circle.png?v=15\" "\\":red_circle:\\"")
Announcements & Meta — 官方公告 / 论坛治理![\":blue_circle:\"](\"https://talk.nervos.org/images/emoji/apple/blue_circle.png?v=15\" "\\":blue_circle:\\"")
Development — CKB / Layer 2 开发 / 开发框架 / DSL 等![\":green_circle:\"](\"https://talk.nervos.org/images/emoji/apple/green_circle.png?v=15\" "\\":green_circle:\\"")
Applications & Ecosystem — 生态与应用：比如讨论 Neuron, Fiber 的使用和开发问题![\":purple_circle:\"](\"https://talk.nervos.org/images/emoji/apple/purple_circle.png?v=15\" "\\":purple_circle:\\"")
Theory & Design — 加密经济学与机制设计![\":brown_circle:\"](\"https://talk.nervos.org/images/emoji/apple/brown_circle.png?v=15\" "\\":brown_circle:\\"")
Miners Pub — 和挖矿相关的话题![\":orange_circle:\"](\"https://talk.nervos.org/images/emoji/apple/orange_circle.png?v=15\" "\\":orange_circle:\\"")
Community Space — 社区活动（DAO / Spark Program 等都在这里，未来考虑开放给社区申请）![\":white_circle:\"](\"https://talk.nervos.org/images/emoji/apple/white_circle.png?v=15\" "\\":white_circle:\\"")
General — 其他![\":black_circle:\"](\"https://talk.nervos.org/images/emoji/apple/black_circle.png?v=15\" "\\":black_circle:\\"")
Archived — 只读归档区这次重构减少了非常多不必要的子分类，让讨论更加集中。
\n感谢 @zz_tovarishch 的论坛重构文档，我参考了其中不少内容
", "like_count": 0, "quote_count": 0 }, { "post_id": 24070, "post_number": 2, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "RetricSu", "created_at": "2026-04-29T23:37:00.781000+00:00", "updated_at": "2026-04-29T23:37:00.781000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/2", "content_text": "两个小反馈：\nTheory & Design — 加密经济学与机制设计\n这个板块的名字中文似乎具体很多，英文稍微泛了点，如果我看中文的话会知道具体在这里应该发什么样的帖子，但是英文名字会不太知道。\nDevelopment — CKB / Layer 2 开发 / 开发框架 / DSL 等\nApplications & Ecosystem — 生态与应用：比如讨论 Neuron, Fiber 的使用和开发问题\n这两个细看名字好像也不是很容易能分清。可能还是因为 development 这个词含义比较泛？如果有一个社区开发者想要分享自己开发的一个新的 sdk （可能是ckb的，也可能是fiber 的），应该放在这两个中的哪一个分类？按照我的理解，这两个分类是不是更多其实是 low-level/core protocol 和应用层之间的区别？", "content_html": "两个小反馈：
\n\n\nTheory & Design — 加密经济学与机制设计
\n
这个板块的名字中文似乎具体很多，英文稍微泛了点，如果我看中文的话会知道具体在这里应该发什么样的帖子，但是英文名字会不太知道。
\n\n\nDevelopment — CKB / Layer 2 开发 / 开发框架 / DSL 等
\n
\nApplications & Ecosystem — 生态与应用：比如讨论 Neuron, Fiber 的使用和开发问题
这两个细看名字好像也不是很容易能分清。可能还是因为 development 这个词含义比较泛？如果有一个社区开发者想要分享自己开发的一个新的 sdk （可能是ckb的，也可能是fiber 的），应该放在这两个中的哪一个分类？按照我的理解，这两个分类是不是更多其实是 low-level/core protocol 和应用层之间的区别？
", "like_count": 0, "quote_count": 0 }, { "post_id": 24074, "post_number": 3, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "janx", "created_at": "2026-04-30T01:38:54.794000+00:00", "updated_at": "2026-04-30T01:40:21.789000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/3", "content_text": "RetricSu:\nThese two categories also feel a bit hard to distinguish at first glance — possibly because the word “development” is quite broad. If a community developer wants to share a new SDK they’ve built (whether for CKB or Fiber), which of these two categories should it go under? My intuition is that the real distinction between these two categories is more about low-level/core protocol vs. application layer — is that the right way to read it?\nI agree.\nI suggest recategorize “Development” and “Application & Ecosystem” into\n“Infrastructure” / “Infra Development” / … - for developers who build for other builders. All protocol (CKB, Fiber, …) and infrastructure (SDKs, common scripts, debuggers, testing harness, …) dev talks happen here.\n“Application” / “App Development” / … - for developers who build for end users.\nBoth types of builders are vital to the ecosystem, but they differ greatly in their principles and methods.\nThe category name “Community Space” is also unclear - it could even refer to Nervos Talk itself. A name like “DAOs” could be better, as it’s more specific and suggests governance and treasury-related activities.", "content_html": "\nI agree.
\nI suggest recategorize “Development” and “Application & Ecosystem” into
\nBoth types of builders are vital to the ecosystem, but they differ greatly in their principles and methods.
\nThe category name “Community Space” is also unclear - it could even refer to Nervos Talk itself. A name like “DAOs” could be better, as it’s more specific and suggests governance and treasury-related activities.
", "like_count": 0, "quote_count": 1 }, { "post_id": 24075, "post_number": 4, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "ArthurZhang", "created_at": "2026-04-30T03:32:48.645000+00:00", "updated_at": "2026-04-30T03:44:39.101000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/4", "content_text": "The new streamlining makes a lot of sense.\nSpeaking of dev topics, I had a small question about cross-domain discussions under the new category structure.\nThe old language-based sections had one practical advantage: discoverability was rather good, as people could see most discussions in one place. For infra or tooling projects, a topic may start in infrastructure, but occasionally wander, quite legitimately, into applications, governance, or protocol semantics.\nSo i guess my question is how infra-oriented work should maintain a sensible path to its downstream users under the new structure? I mean, without drifting too much into self-promotion\nWould it make sense to keep the main thread in the most natural category, and only add short linked RFC or milestone posts when the discussion genuinely needs to poke its head into another room? Or would the community prefer such projects to stay strictly within infrastructure for clarity?", "content_html": "The new streamlining makes a lot of sense.
\nSpeaking of dev topics, I had a small question about cross-domain discussions under the new category structure.
\nThe old language-based sections had one practical advantage: discoverability was rather good, as people could see most discussions in one place. For infra or tooling projects, a topic may start in infrastructure, but occasionally wander, quite legitimately, into applications, governance, or protocol semantics.
\nSo i guess my question is how infra-oriented work should maintain a sensible path to its downstream users under the new structure? I mean, without drifting too much into self-promotion ![\":slight_smile:\"](\"https://talk.nervos.org/images/emoji/apple/slight_smile.png?v=15\" "\\":slight_smile:\\"")
Would it make sense to keep the main thread in the most natural category, and only add short linked RFC or milestone posts when the discussion genuinely needs to poke its head into another room? Or would the community prefer such projects to stay strictly within infrastructure for clarity?
", "like_count": 0, "quote_count": 0 }, { "post_id": 24077, "post_number": 5, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "Thinker", "created_at": "2026-04-30T07:24:50.112000+00:00", "updated_at": "2026-04-30T07:30:36.215000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/5", "content_text": "我喜欢的分类界面：\n1.公告：社区治理原则/CKB双周报更新/重大事项（软/硬分叉）。 【属于 公告、公示型】\n2.构架及协议：开发框架 / CKB / Layer 2 / Fiber / RGB++ / DSL 等一些通用类协议统统归这类， 纯技术层面上一些协议引导（置顶）及其探讨 。 【 属于 引导+探讨型】\n3.生态与应用：主要DAPP应用层的探讨。 【属于 探讨型】\n子集1【项目】：供大家探讨提意见的\n子集2【想法】：社区非技术人员提供的好点子\n4.矿工/加密经济学：矿工及经济学方面的谈论，可能低频但必要有的 。 【属于 探讨型】\n5.资助：申请资助的项目通道（原版有些隐蔽)。 【属于 申请+探讨型】\n子集 1 【DIS】\n子集2 【Spark】\n6.社区空间：大杂烩，无法精准分类的 。 【属于 探讨型】", "content_html": "我喜欢的分类界面：
\n1.公告：社区治理原则/CKB双周报更新/重大事项（软/硬分叉）。 【属于 公告、公示型】
\n2.构架及协议：开发框架 / CKB / Layer 2 / Fiber / RGB++ / DSL 等一些通用类协议统统归这类， 纯技术层面上一些协议引导（置顶）及其探讨 。 【 属于 引导+探讨型】
\n3.生态与应用：主要DAPP应用层的探讨。 【属于 探讨型】
\n子集1【项目】：供大家探讨提意见的
\n子集2【想法】：社区非技术人员提供的好点子
4.矿工/加密经济学：矿工及经济学方面的谈论，可能低频但必要有的 。 【属于 探讨型】
\n5.资助：申请资助的项目通道（原版有些隐蔽)。 【属于 申请+探讨型】
\n子集 1 【DIS】
\n子集2 【Spark】
6.社区空间：大杂烩，无法精准分类的 。 【属于 探讨型】
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10130, "title": "Introducing CKB Kickstarter: Decentralized All-or-Nothing Crowdfunding on Nervos CKB (Testnet MVP Live)", "slug": "introducing-ckb-kickstarter-decentralized-all-or-nothing-crowdfunding-on-nervos-ckb-testnet-mvp-live", "url": "https://talk.nervos.org/t/introducing-ckb-kickstarter-decentralized-all-or-nothing-crowdfunding-on-nervos-ckb-testnet-mvp-live/10130", "created_at": "2026-03-25T20:44:37.875000+00:00", "last_posted_at": "2026-04-30T01:06:17.878000+00:00", "category_id": 32, "tags": [ "CKB", "dapp" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24073, "post_number": 10, "topic_id": 10130, "topic_title": "Introducing CKB Kickstarter: Decentralized All-or-Nothing Crowdfunding on Nervos CKB (Testnet MVP Live)", "topic_slug": "introducing-ckb-kickstarter-decentralized-all-or-nothing-crowdfunding-on-nervos-ckb-testnet-mvp-live", "author": "RetricSu", "created_at": "2026-04-30T01:06:17.878000+00:00", "updated_at": "2026-04-30T01:06:17.878000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/introducing-ckb-kickstarter-decentralized-all-or-nothing-crowdfunding-on-nervos-ckb-testnet-mvp-live/10130/10", "content_text": "awesome! keep it going.\nI just want to share that Sustainable platform business model is very important in the early stage for CKB applications. It might sound counter-intuitive. But I, personally, love to see more apps that has the pontencial to generate real cash flow in the CKB ecosystem. For crypto, money is the new attension.", "content_html": "awesome! keep it going.
\nI just want to share that Sustainable platform business model is very important in the early stage for CKB applications. It might sound counter-intuitive. But I, personally, love to see more apps that has the pontencial to generate real cash flow in the CKB ecosystem. For crypto, money is the new attension.
", "like_count": 0, "quote_count": 0 } ] }, { "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-30T01:02:11.434000+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": 24068, "post_number": 30, "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": "Yeti", "created_at": "2026-04-29T21:59:28.435000+00:00", "updated_at": "2026-04-29T22:00:37.927000+00:00", "reply_to_post_number": 29, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/30", "content_text": "I totally agree with your idea about targetting these types of countries and currency’s, this should be CKB’s niche in general, not just for payments and stable coins.\nLike @xingtianchunyan said in that excellent evaluation, CKBs market and network affect position makes it very hard to compete in the current stable coins/payment market, so your idea is the right direction.\nBut I’m not sure how your LP idea works, I don’t think you can just add one time liquidity paring a stable with a highly volatile token like CKB and expect it to maintain the currencies value, especially seeing as there’s no arbitrage opportunities to even attempt to maintain the value of the pool.\nYou could have the user bridge USDC/T and try and keep it backed by USD, but this is highly centralised and also, how do you manage the exchange rates?\nUsing the RUSD platform (is this even open source? @matt_ckb), might be the best way, and the Foundation/DAO/Secondary Issuance could be used to support the system by injecting CKB when needed until the system got off the ground.\nBut I think you’d just have to choose one currency and go all out trying to gain some real adoption before moving onto others.", "content_html": "I totally agree with your idea about targetting these types of countries and currency’s, this should be CKB’s niche in general, not just for payments and stable coins.
\nLike @xingtianchunyan said in that excellent evaluation, CKBs market and network affect position makes it very hard to compete in the current stable coins/payment market, so your idea is the right direction.
\nBut I’m not sure how your LP idea works, I don’t think you can just add one time liquidity paring a stable with a highly volatile token like CKB and expect it to maintain the currencies value, especially seeing as there’s no arbitrage opportunities to even attempt to maintain the value of the pool.
\nYou could have the user bridge USDC/T and try and keep it backed by USD, but this is highly centralised and also, how do you manage the exchange rates?
\nUsing the RUSD platform (is this even open source? @matt_ckb), might be the best way, and the Foundation/DAO/Secondary Issuance could be used to support the system by injecting CKB when needed until the system got off the ground.
\nBut I think you’d just have to choose one currency and go all out trying to gain some real adoption before moving onto others.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24069, "post_number": 31, "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-29T23:28:59.981000+00:00", "updated_at": "2026-04-29T23:28:59.981000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/31", "content_text": "如果说Fiber checkout 等工具是赋能开发者的基础设施，那么UtxoTHB/UtxoKES/UtxoARS……等隐射币就是赋能包括开发者在内的所有商户和用户的基础设施，这是其定位和意义\n绝大多数中国人也许永远不会接触UtxoKES,绝大多数美国人也许永远不会接触UtxoARS,\n但他们本国人会也很需要\n所以更具体的来说这个Utxo隐射集是由很多不同地区的需求组成的基础设施集\n很多个区域的需求组成了一个大需求，而这个需求正是CKB所擅长的，Fiber对多资产的支持具体来到了不用地区的隐射币这个层面\n当UtxoKES/UtxoTHB/UtxoARS这样的价值锚定解决后，节点的挂机由本地人自己完成，或者由Joyid钱包本身或其开源后本地团队运营的仿Joyid钱包完成，大客户自己运营UtxoKES等本地货币Fiber节点，小客户用Joyid或仿Joyid钱包，本地的真实需求和网络会一点点建立，从点到线到面\n一个本地网络如此，所有本地网络也是如此\nCKB只用做好自己的部分，其他的交给本地人\n关于UtxoKES等所有本地货币隐射币的建立机制，相信相关技术团队心里已经有数就不多说了，这是CKB/Fiber难得的机会，如果说用CKB拿出一大笔来做交易对有难度，最好的就是用一个新币来做这个交易对\n这个新币比如打算发行一亿个代币，那么这部分安排不变\n同时在每个UtxokKES这样的货币上也分一亿个，加上UtxoKES生成一个极大的数量比如一亿亿，这样我们就用很少的成本获得了UtxoKES/Fiber这样的交易对且有足够的深度，其他隐射币同理\n总之，全区域隐射币的建立是把Fiber支持多币种能力的正确落地和实现，是对自己和用户的真实双向赋能", "content_html": "如果说Fiber checkout 等工具是赋能开发者的基础设施，那么UtxoTHB/UtxoKES/UtxoARS……等隐射币就是赋能包括开发者在内的所有商户和用户的基础设施，这是其定位和意义
\n绝大多数中国人也许永远不会接触UtxoKES,绝大多数美国人也许永远不会接触UtxoARS,
\n但他们本国人会也很需要
\n所以更具体的来说这个Utxo隐射集是由很多不同地区的需求组成的基础设施集
\n很多个区域的需求组成了一个大需求，而这个需求正是CKB所擅长的，Fiber对多资产的支持具体来到了不用地区的隐射币这个层面
\n当UtxoKES/UtxoTHB/UtxoARS这样的价值锚定解决后，节点的挂机由本地人自己完成，或者由Joyid钱包本身或其开源后本地团队运营的仿Joyid钱包完成，大客户自己运营UtxoKES等本地货币Fiber节点，小客户用Joyid或仿Joyid钱包，本地的真实需求和网络会一点点建立，从点到线到面
\n一个本地网络如此，所有本地网络也是如此
\nCKB只用做好自己的部分，其他的交给本地人
\n关于UtxoKES等所有本地货币隐射币的建立机制，相信相关技术团队心里已经有数就不多说了，这是CKB/Fiber难得的机会，如果说用CKB拿出一大笔来做交易对有难度，最好的就是用一个新币来做这个交易对
\n这个新币比如打算发行一亿个代币，那么这部分安排不变
\n同时在每个UtxokKES这样的货币上也分一亿个，加上UtxoKES生成一个极大的数量比如一亿亿，这样我们就用很少的成本获得了UtxoKES/Fiber这样的交易对且有足够的深度，其他隐射币同理
\n总之，全区域隐射币的建立是把Fiber支持多币种能力的正确落地和实现，是对自己和用户的真实双向赋能
", "like_count": 0, "quote_count": 0 }, { "post_id": 24071, "post_number": 32, "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": "Yeti", "created_at": "2026-04-30T00:32:09.666000+00:00", "updated_at": "2026-04-30T00:32:09.666000+00:00", "reply_to_post_number": 31, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/32", "content_text": "Sorry mate, maybe I’m misunderstanding, so just to clarify, are these utxo coins, stable coins?\nIt’s sounds like they are, but how are you anchoring these to the value of the ‘real’ currency? I just don’t get that part.", "content_html": "Sorry mate, maybe I’m misunderstanding, so just to clarify, are these utxo coins, stable coins?
\nIt’s sounds like they are, but how are you anchoring these to the value of the ‘real’ currency? I just don’t get that part.
", "like_count": 0, "quote_count": 0 }, { "post_id": 24072, "post_number": 33, "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-30T01:02:11.434000+00:00", "updated_at": "2026-04-30T01:02:11.434000+00:00", "reply_to_post_number": 32, "url": "https://talk.nervos.org/t/spark-program-fiber-checkout-a-stripe-style-react-payment-library-for-fiber-network/10045/33", "content_text": "这些是稳定币，UtxoUSD是美元稳定币/隐射币，UtxoCNY是人民币稳定币，UtxoTHB是泰铢稳定币……其他依次类推\n你或者其他人之所以还没有听说过，是因为这是我设计的暂时还没有面世，但只要稍微说明大家就会懂了\n所有稳定币价值的保证和隐射原理很简单，就是各公链都有的多倍质押原理，就用ckb现有的RUSD举例，其价值由ckb来保证，具体来说是用一倍多美元的ckb来保证一个RUSD的价值，而UtxoUSD也是同理，由超额的ckb或fiber来保证，这个超额就不是几倍而可以是百倍千倍万倍\nckb/fiber在为稳定币做价值保证的同时，其自身价值也会增长，因为每一个一手的UtxoUSD或UtxoTHB都需要用户用ckb/fiber去换取，没有其他获取办法，这就会推动ckb/fiber的流通，占有率和沉淀\n总的来说，你可以理解成一个更安全更去中心化更多倍质押但是不谋求任何利益而把所有好处推向整个ckb或fiber项目的RUSD", "content_html": "这些是稳定币，UtxoUSD是美元稳定币/隐射币，UtxoCNY是人民币稳定币，UtxoTHB是泰铢稳定币……其他依次类推
\n你或者其他人之所以还没有听说过，是因为这是我设计的暂时还没有面世，但只要稍微说明大家就会懂了
\n所有稳定币价值的保证和隐射原理很简单，就是各公链都有的多倍质押原理，就用ckb现有的RUSD举例，其价值由ckb来保证，具体来说是用一倍多美元的ckb来保证一个RUSD的价值，而UtxoUSD也是同理，由超额的ckb或fiber来保证，这个超额就不是几倍而可以是百倍千倍万倍
\nckb/fiber在为稳定币做价值保证的同时，其自身价值也会增长，因为每一个一手的UtxoUSD或UtxoTHB都需要用户用ckb/fiber去换取，没有其他获取办法，这就会推动ckb/fiber的流通，占有率和沉淀
\n总的来说，你可以理解成一个更安全更去中心化更多倍质押但是不谋求任何利益而把所有好处推向整个ckb或fiber项目的RUSD
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 9879, "title": "[DIS] Mobile-Ready CKB Light Client (Pocket Node) for Android", "slug": "dis-mobile-ready-ckb-light-client-pocket-node-for-android", "url": "https://talk.nervos.org/t/dis-mobile-ready-ckb-light-client-pocket-node-for-android/9879", "created_at": "2026-01-27T09:25:31.938000+00:00", "last_posted_at": "2026-04-29T18:35:59.373000+00:00", "category_id": 65, "tags": [ "CKB", "light-client" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24066, "post_number": 39, "topic_id": 9879, "topic_title": "[DIS] Mobile-Ready CKB Light Client (Pocket Node) for Android", "topic_slug": "dis-mobile-ready-ckb-light-client-pocket-node-for-android", "author": "Jnr6", "created_at": "2026-04-29T18:35:59.373000+00:00", "updated_at": "2026-04-29T18:35:59.373000+00:00", "reply_to_post_number": 38, "url": "https://talk.nervos.org/t/dis-mobile-ready-ckb-light-client-pocket-node-for-android/9879/39", "content_text": "Release Summary - Pocket Node v1.5.1\nPocket Node v1.5.1 - User Education Release\nBig thanks to everyone who tried v1.5.0 and gave feedback,This release is the response.\nPocket Node is a self-custodial CKB wallet, but unlike most wallets it actually runs a CKB light client on your phone. That’s powerful, but the trade-off has always been that the first-time experience felt foreign to anyone whose mental model is MetaMask or Trust Wallet etc. v1.5.1 is the first round of fixing that.\nWhat’s new:\nFirst-run sync coachmark. When you create or import a wallet for the first time, a one-time spotlight on the Sync card explains what your phone is actually doing when syncing.\n? help icons everywhere they’re useful. On the Home screen Sync and Activity sections, on every option in the sync mode picker, and on the block height field when you’re entering a custom start point. Each one opens a plain-language explainer in a bottom sheet, with a Open FAQ link if you want to read more.\nIn-app FAQ. Settings > Help & FAQ now has 10 questions answered in plain English: why sync exists, which mode to pick, what Pending means, what confirmations are, why your balance doesn’t show instantly, and so on. The help icons deep-link straight to the relevant entry.\nSync mode picker rewrite. The old dialog has been replaced with a bottom sheet that includes a “Pick this if…” sentence under each option. Recent activity is now badged as Recommended. The Custom Block Height option is renamed to the friendlier From a specific date.\nBlock height removed from Home. The home screen no longer shows raw block numbers anywhere; it just says Catching up from 18,250,000 to 18,310,422 (with the values bolded so you can see progress at a glance) or Up to date. If you actually want the raw block height, it’s still on the Node Status screen(I made it less nerdy…).\nWhat’s fixed:\nSync sheet survives the explorer round-trip. If you tapped “Don’t know your block height? Look up on explorer” and Chrome opened, on some phones the OS killed Pocket Node in the background(still not 100% fixed, I ahve an issue opened to use webview instead of opening chrome directly). When you came back you had to unlock with your PIN and you’d land on Home with the sync mode dialog gone, meaning you had to start the flow over. The sheet now restores itself after you return, with whatever you’d typed still in the field.\nNode Status no longer freezes on stale block numbers. When you changed sync mode, the Node Status screen would sometimes get stuck showing the previous mode’s block number for ages because a JNI call threw an exception during the brief restart window and the screen just kept the old value. Each query is now individually fault-tolerant.\nCoachmark grace timer doesn’t fire prematurely. A subtle race condition where a sync poll that returned right before you changed sync mode could resurrect the dismissed coachmark. Closed off with a generation-token gate that ignores in-flight responses from the previous polling run.\nSmaller polish. Coachmark spotlight now has rounded corners matching the sync card; tap-swallow scrim prevents accidental taps on backgrounded UI; FAQ back button is now properly labeled for screen readers; coachmark anchor entries are cleaned up on dispose.\nUnder the hood:\nMigrated 4 small components and the sync mode picker to strings.xml. All the new copy in this release is resource-backed, so future translations can drop in without touching code. Full migration of the rest of the app is tracked separately.\nDownload: Release Pocket Node v1.5.1 — User Education Release · RaheemJnr/pocket-node · GitHub\nSource: GitHub - RaheemJnr/pocket-node: A native Android CKB (Nervos) wallet that runs an embedded light client directly on the device via JNI — full sovereignty, no remote servers. · GitHub", "content_html": "Big thanks to everyone who tried v1.5.0 and gave feedback,This release is the response.
\nPocket Node is a self-custodial CKB wallet, but unlike most wallets it actually runs a CKB light client on your phone. That’s powerful, but the trade-off has always been that the first-time experience felt foreign to anyone whose mental model is MetaMask or Trust Wallet etc. v1.5.1 is the first round of fixing that.
\n? help icons everywhere they’re useful. On the Home screen Sync and Activity sections, on every option in the sync mode picker, and on the block height field when you’re entering a custom start point. Each one opens a plain-language explainer in a bottom sheet, with a Open FAQ link if you want to read more.strings.xml. All the new copy in this release is resource-backed, so future translations can drop in without touching code. Full migration of the rest of the app is tracked separately.Download: Release Pocket Node v1.5.1 — User Education Release · RaheemJnr/pocket-node · GitHub
\nSource: GitHub - RaheemJnr/pocket-node: A native Android CKB (Nervos) wallet that runs an embedded light client directly on the device via JNI — full sovereignty, no remote servers. · GitHub