[DIS] CKBoost Gamified Community Engagement Platform Proposal

[Alive24]

[DIS] CKBoost Gamified Community Engagement Platform Proposal

Link to VOT page: https://dao.ckb.community/thread/vot-ckboost-gamified-community-engagement-platform-proposal-61358

Summary

This proposal requests funding from the CKB Community Fund DAO to support the design, development, and deployment of CKBoost, a purpose-built open-source gamified engagement platform for the CKB ecosystem.

Amount requested: $20,000 USD (around 4635652.81 CKB at current price. Should use the latest price at the time of issuance)

10% paid at the time of grant commencement, with the remaining 90% split over 3 milestones

ETA to completion: 3 months from commencement

CKB address: ckb1qyqq5y2yu75h35shdke9gy4du9z536dvuruscqw90f

Purpose

CKBoost’s mission is to transform community engagement from scattered, ad-hoc efforts into a structured, rewarding, and measurable system that drives participation, incentivizes real contributions, and encourages ecosystem growth.

From the Nervos Community Catalyst announcement thread:

This initiative focuses on setting up structures whereby the community can be rewarded for participating in more trivial tasks such as sharing content, posting comments, participating in campaigns under a “proof of participation” quest platform. Tasks can form part of specific campaigns aimed at addressing a specific time-sensitive need (e.g. raiding an X post) or addressing an area of low activity (e.g. reply to DAO proposals). Other such campaigns may include rewards for on-chain or chain-related activity (e.g. deposit liquidity to DEX, mint iCKB or RUSD, run a CKB node).

A leaderboard will aggregate points from campaigns and daily activities with top participants earning CKB rewards and small rewards issued randomly to any participant.

CKBoost directly supports the goals of the Nervos Community Catalyst initiative by providing the technical backbone for quests, campaigns, verifiable proof of work, and fair distribution of on-chain rewards.

Why?

With the recent launch of initiatives (such as Community Keeps Building) to incentivize content creators, new CKB builders, activists and pioneers, the community now has a way to reward talented individuals in a formalised and structured manner.

Some problems still remain unaddressed, such as:

• How to reward community members who either don’t have directly transferable skills for a formal track, or cannot commit the necessary time to participate on one
• How to ensure that community effort is synergised for greater impact and focus on shared objectives across social media, off-chain and on-chain platforms.
• How to create a fun and incentivized experience that creates enthusiasm for community participation and growth
• How to create an experience that leverages CKB and encourages more on-chain activity

CKBoost has been conceived with these challenges in mind.

Who?

I’ve been actively building on CKB for more than one and a half years, starting from designing the product and architecture for Stable++, and authoring more than 95% of all code in the core repo (including contracts, tests, automation scripts) and part of the backend services and DevOps. I joined CKB Eco Fund Dev Rel afterwards and worked on Nest.js autotrade framework for CKB, Pausable UDT and implementation of SSRI protocol and SDK and the WASM implementation. I also worked on the ccc molecule module, deploy module, and a wide range of different tutorials, and the Awesome CKB AI friendly resource hub.

This summer, I switched my role and pattern of collaboration with the CKB community, and started by working independently on building dApps and smart contracts highly needed in the community.

This project will be completed on behalf of the Nervos Community Catalyst, as linked to above.

Design principles

Platform Overview

CKBoost will be an open-source web platform combining:

• Campaign & Quest Management: Admins, community members with governance or leadership roles, or whitelisted sponsors can design multi-task campaigns with detailed quests, success metrics, and fully funded CKB or xUDT reward pools.

• On-chain Points & Badges: All points and achievements are tracked on-chain via a dedicated UDT, ensuring transparent reward mechanisms.

• Gamification: Streak bonuses, difficulty multipliers, dynamic leaderboards, and badge milestones encourage healthy competition and consistent contribution.

• Verification & Anti-Sybil Measures: Flexible verification options, starting with manual Telegram proof and expanding to DID/KYC. Rewards remain locked until verification is passed.

• Community Tipping & Peer Recognition: Members can propose tips for exceptional contributions, with democratic multi-approval flow and automated treasury payouts.

• Comprehensive Admin Dashboards: Tools for campaign creators, platform admins, and reviewers to monitor progress, review submissions, and manage reward distribution.

Draft UI design

A front-end draft of the intended design of CKBoost v0 can be seen here:

https://ckboost.netlify.app/

Technical design

The github repository which contains detailed technical design specifications is available here:

https://github.com/Alive24/CKBoost

A summarized version is presented as follows:

Layer	Details
Frontend	Next.js React app, mobile-first, wallet-integrated (CCC), reusable component library, real-time quest tracking.
Smart Contracts	Modular Type Scripts: ckboost-protocol-type (governance & minting), ckboost-campaign-type (campaign logic), ckboost-campaign-lock (secure vaults for funds), ckboost-user-type (submission, verification, and bindings logic).
Decentralized API Service	Fully open source anyone-can-host Cloudflare Workers. Preferably hosted by campaign sponsors and community.
Data Storage	CKB Cell data for all critical states, anyone-can-host Neon storage for non-critical data (only for the purpose of completion submission, no need to store permanently), local cache for performance and fee saving.
Verification and Bindings	Multi-method verification options, starting with manual Telegram proof. DID/KYC integration planned. X, Discord, Reddit bindings to help validation.
External Integrations	Social APIs for quest verification (e.g., X/Twitter), Telegram Bot for verification, indexer services for on-chain proof validation.

With this design, I am implementing a new pattern of decentralization in building decentralized applications: all backend services should be run in a rather “trustless” manner with open source anyone-can-host codebase, and reduce the reliance on any single, centralized operator.

This architecture fundamentally redefines the relationship between a dApp and its infrastructure. Instead of a single “backend” server that becomes a central point of failure or control, CKBoost operates as a resilient network of interoperable services. The core logic is enshrined in on-chain CKB contracts, while off-chain operations like data indexing and proof validation are handled by open-source, decentralized, and easily replicable workers. Anyone, from campaign sponsors to community members, can host these services, creating a truly robust and censorship-resistant ecosystem.

This approach not only enhances decentralization and security but also fosters a more engaged and empowered community. By providing open-source, anyone-can-host infrastructure, we invite our community not just to use the platform, but to actively participate in running it.

Core User Flows

1. Campaign Base Flow

   • Define quests → fund campaign → set proof requirements → get admin a → launch → monitor submissions → distribute rewards.

2. Campaign Sponsor Flow

   • Apply for sponsor status → define quests → fund campaign → set proof requirements → get admin approval → launch → monitor submissions → distribute rewards.

3. Contributor Flow

   • Connect wallet → browse campaigns/quests → complete tasks → submit proof → wait for approval → pass verification → claim on-chain rewards → earn badges & leaderboard ranking.

4. Tip Proposal Flow

   • Community member proposes a tip → receives 5 peer approvals → automated payout from community treasury → permanent record on user profile.

5. Admin Flow

   • Identity verification
   • Campaign Sponsor verification
   • Campaign approval
   • Base campaigns and leaderboard campaign creation

Campaign Examples

To test & demo the system, we’ll deploy real campaigns for common activities:

• AMA Boost: Points for asking questions, sharing AMA posts, and amplifying Nervos discussions.

• Knowledge Boost: Share and summarize an article from the Knowledge Base.

• On-Chain Quests: Lock CKB to mint iCKB, add liquidity on UTXOswap, or interact with other Nervos DeFi primitives.

• Community Governance: Engage with proposals, provide meaningful feedback, or share analytics insights.

These will show how CKBoost supports a wide range of contribution types: technical, content-based, social, and governance-related.

Risk Management

Key Risks & Mitigations:

• Sybil Attacks: Locked rewards + verification layer + multi-method proofs.

• Smart Contract Bugs: Small initial funds in contract vaults, gradual rollout, audit before scaling.

• Low Participation: Mock campaigns, partnerships with existing community leads, clear incentives.

• Scalability: Celldata-first design with caching and batch processing for high throughput.

Roadmap & Milestones

The funding covers ~3 months of focused delivery across three clear phases. An initial 10% downpayment is received at the commencement of the grant:

---

Milestone 1: Foundation & Core MVP (~Month 1) - 30% of grant paid

• Deploy Next.js scaffold with CCC wallet integration.

• Visual and interaction prototyping.

• Smart contract development for core Scripts (protocol-type, protocol-lock, campaign-type, campaign-lock, user-type).

• Launch Protocol Cell to manage whitelisted sponsors, admin roles, and Points UDT minting.

• Build campaign & quest creation flows (manual review only for proof).

• Implement Points UDT and locked reward distribution.

---

Milestone 2: Advanced Verification & Gamification (~Month 2) - 30% of grant paid

• Expand verification methods: integrate Telegram admin review, prepare DID/KYC hooks for later.

• Design simple leaderboards and user profiles with progress tracking.

• Add streak bonuses, difficulty multipliers, and badge milestone features.

• Develop the tipping system with multi-signature peer approvals.

• Improve user profiles: public achievements, contribution logs.

• Build out admin dashboard for better submission management and analytics.

---

Milestone 3: Mock Campaigns & Pre-Scaling (~Month 3) - 30% of grant paid

• Deploy real test campaigns with oversight (e.g., AMA Boost, On-Chain Boost).

• Test reward distribution and verification flows with real users.

• Research automated on-chain action verification (e.g., oracles for iCKB locks).

• Publish onboarding docs for sponsors and contributors.

• Final testing, bug fixing, and DAO report for next-phase proposals.

---

Cost Breakdown

The cost is broken down by milestone and reflects 3 months of full-time developer work.

Costs for webhosting, domain, IPFS storage will be covered by the Nervos Community Catalyst.

Conclusion

CKBoost lays the foundation for a sustainable community engagement system that any project, sponsor, or contributor can benefit from. This proposal has detailed the design, technical architecture, and phased roadmap for its implementation. The platform aims to provide a structured and transparent framework for community contributions, leveraging on-chain mechanics for reward distribution and recognition.

The core of the project is to build a practical, open-source tool that aligns with the decentralized ethos of the CKB ecosystem. By focusing on a modular contract design and anyone-can-host services, the platform is built for resilience and future extensibility.

I’m fully committed to transparent milestone updates and community feedback throughout. I welcome everyone’s thoughts, questions, and suggestions below.

Thank you for your trust and support!
— Alive24

[DIS] CKBoost 游戏化社区参与平台提案

摘要

本提案请求 CKB 社区基金 DAO 为 CKBoost 的设计、开发和部署提供资金支持，这是一个专为 CKB 生态系统构建的开源游戏化参与平台。

申请金额：$20,000 USD（按当前市价约合 4635652.81.82 CKB）

项目开始时支付 10%，剩余 90% 分 3 个里程碑支付

预计完成时间：从开始后 3 个月

CKB 地址：ckb1qyqq5y2yu75h35shdke9gy4du9z536dvuruscqw90f

目的

⁠CKBoost 的使命，在于将当前分散、临时的社区贡献，转变为一个结构化、可衡量、且有明确回报的激励体系，以此来推动社区参与、激励真实贡献，并最终促进整个生态的健康发展。

摘自 Nervos Community Catalyst 公告帖：

该倡议专注于建立结构，使社区能够因参与更琐碎的任务而获得奖励，如分享内容、发表评论、在"参与证明"任务平台下参与活动。任务可以是特定活动的一部分，旨在解决特定的高时效性需求（如推广 X 帖子）或解决活跃度不足的领域（如回复 DAO 提案）。其他此类活动可能包括对链上或链相关活动的奖励（如向 DEX 存入流动性、铸造 iCKB 或 RUSD、运行 CKB 节点）。

排行榜将汇总活动和日常活动的积分，顶级参与者赚取 CKB 奖励，任何参与者都能随机获得小额奖励。

CKBoost 通过为任务、活动、可验证工作证明和链上奖励公平分配提供技术支撑，直接支持 Nervos Community Catalyst 倡议的目标。

为什么？

随着最近推出的倡议（如 Community Keeps Building）来激励内容创作者、新 CKB 构建者、活动家和先驱者，⁠社区现在终于有了一套相对正式和结构化的方法，来奖励那些有才华的贡献者。

但目前仍存在一些问题，例如：

• 如何让那些不具备特定技能，或无法投入大量时间的普通社区成员，也能通过贡献获得激励。

• 如何确保社区努力在社交媒体、链下和链上平台上协同作用，以产生更大影响并专注于共同目标

• 如何创造有趣且有激励的体验，为社区参与和发展创造热情

• 如何创造利用 CKB 并鼓励更多链上活动的体验

CKBoost 正是为了应对这些挑战而构思的。

谁？

我在 CKB 上积极开发已超过一年半，从设计Stable++和架构开始，编写了核心仓库中超过 95% 的代码（包括合约、测试、自动化脚本）以及部分后端服务和 DevOps。之后我加入了 CKB Eco Fund Dev Rel，开发了 CKB 的 Nest.js 自动交易框架、Pausable UDT 以及 SSRI 协议和 SDK 的实现和 WASM 实现。我还参与了 ccc molecule 模块、部署模块和各种不同的教程的开发，以及 Awesome CKB 这个AI友好的资源中心。

今年夏天，我改变了与 CKB 社区合作的合作模式和我的角色，开始以独立开发者的身份，致力于开发社区亟需的 dApp 和智能合约。

如前文所述，我将代表 Nervos Community Catalyst 完成这个项目。

设计原则

平台概览

CKBoost 将是一个开源网络平台，结合：

• 活动和任务管理： 平台的管理员、社区的治理或领导角色成员，以及通过白名单认证的赞助者，都可以发起包含多个任务的激励活动，包含详细任务、成功指标和完全资助的 CKB 或 xUDT 奖励池。

• 链上积分和徽章： 所有积分和成就都通过专用 UDT 在链上跟踪，确保透明的奖励机制。

• 游戏化： 连击奖励、难度乘数、动态排行榜和徽章里程碑鼓励健康竞争和持续贡献。

• 验证和反 Sybil 措施： 灵活的验证选项，从手动 Telegram 绑定，扩展到 DID/KYC。奖励保持锁定直到通过验证。

• 社区打赏和同行认可： 成员可以为杰出贡献提议打赏，通过民主多重批准流程和自动化社区金库支付。

• 综合管理仪表板： 为活动创建者、平台管理员和审核者提供工具，监控进度、审查提交并管理奖励分配。

UI 设计草图

CKBoost v0 的前端设计草图可在此处查看：

https://ckboost.netlify.app/

技术设计

包含详细技术设计规范的 GitHub 仓库在此处可用：

https://github.com/Alive24/CKBoost

摘要版本如下：

| 层级 | 详情 |

| ----- | ----- |

| 前端 | Next.js React 应用，移动优先，钱包集成（CCC），可重用组件库，实时任务跟踪。 |

| 智能合约 | 模块化 Type Scripts：ckboost-protocol-type（治理和铸造）、ckboost-campaign-type（活动逻辑）、ckboost-campaign-lock（资金安全金库）、ckboost-user-type（提交、验证和绑定逻辑）。 |

| 去中心化 API 服务 | 完全开源的任何人都可以托管的 Cloudflare Workers。优选由活动赞助商和社区托管。 |

| 数据存储 | 所有关键状态的 CKB Cell 数据，任何人都可以托管的 Neon 存储用于非关键数据（仅用于完成提交，无需永久存储），本地缓存用于性能和费用节省。 |

| 验证和绑定 | 多方法验证选项，从手动 Telegram 证明开始。计划 DID/KYC 集成。X、Discord、Reddit 绑定以帮助验证。 |

| 外部集成 | 用于任务验证的社交 API（如 X/Twitter）、用于验证的 Telegram Bot、用于链上证明验证的索引器服务。 |

通过这种设计，我正在探索一种构建dApp的新模式：所有后端服务都应以相当"无信任"的方式运行，使用开源的任何人都可以部署的代码库，并减少对任何单一集中式运营商的依赖。

这种架构从根本上重新定义了 dApp 与其基础设施之间的关系。CKBoost 不是作为单一的"后端"服务器（会成为单点故障或控制点），而是作为可互操作服务的弹性网络运行。核心逻辑固化在链上 CKB 合约中，而链下操作如数据索引和证明验证则由开源、去中心化且易于复制的工作器处理。任何人，从活动赞助商到社区成员，都可以部署这些服务，创造真正强大且抗审查的生态系统。

这种方法不仅增强了去中心化和安全性，还培养了更加参与和赋权的社区。通过提供开源的任何人都可以部署的基础设施，我们邀请社区不仅使用平台，还积极参与运行它。

核心用户流程

1. 活动基础流程

• 定义任务 → 资助活动 → 设置证明要求 → 获得管理员批准 → 启动 → 监控提交 → 分配奖励。

2. 活动赞助商流程

• 申请赞助商身份 → 定义任务 → 资助活动 → 设置证明要求 → 获得管理员批准 → 启动 → 监控提交 → 分配奖励。

3. 贡献者流程

• 连接钱包 → 浏览活动/任务 → 完成任务 → 提交证明 → 等待批准 → 通过验证 → 领取链上奖励 → 赚取徽章和排行榜排名。

4. 打赏提议流程

• 社区成员提议打赏 → 获得 5 个同行批准 → 从社区金库自动支付 → 用户资料永久记录。

5. 管理员流程

• 身份验证

• 活动赞助商验证

• 活动批准

• 基础活动和排行榜活动创建

活动示例

为了测试和演示系统，我们将部署常见活动的真实活动：

• AMA 提升： 为提问、分享 AMA 帖子和放大 Nervos 讨论获得积分。

• 知识提升： 从知识库分享和总结文章。

• 链上任务： 锁定 CKB 铸造 iCKB、在 UTXOswap 上添加流动性或与其他 Nervos DeFi 交互。

• 社区治理： 参与提案、提供有意义的反馈或分享分析见解。

这些将展示 CKBoost 如何支持广泛的贡献类型：技术、内容、社交和治理相关。

风险管理

关键风险和缓解措施：

• Sybil 攻击：锁定奖励 + 验证层 + 多方法证明。

• 智能合约漏洞：合约金库中的小额初始资金，逐步推出，扩展前审计。

• 参与度低：模拟活动，与现有社区领导合作，明确激励。

• 可扩展性：优先使用 Cell 数据设计，配合缓存和批处理以实现高吞吐量。

路线图和里程碑

资金涵盖约 3 个月的专注交付，分为三个明确阶段。资助开始时收到初始 10% 的预付款：

---

里程碑 1：基础和核心 MVP（约第 1 个月）- 支付 30% 资金

• 部署带有 CCC 钱包集成的 Next.js 脚手架。

• 视觉和交互原型设计。

• 核心脚本的智能合约开发（protocol-type、protocol-lock、campaign-type、campaign-lock、user-type）。

• 启动协议 Cell 以管理白名单赞助商、管理员角色和积分 UDT 铸造。

• 构建活动和任务创建流程（仅手动审查证明）。

• 实现积分 UDT 和锁定奖励分配。

---

里程碑 2：高级验证和游戏化（约第 2 个月）- 支付 30% 资金

• 扩展验证方法：集成 Telegram 管理员审查，为后续准备 DID/KYC 集成。

• 设计简单的排行榜和用户资料，进行进度跟踪。

• 添加连击奖励、难度乘数和徽章里程碑功能。

• 开发带有多重签名批准的打赏系统。

• 改善用户资料：公共成就、贡献日志。

• 构建管理员仪表板，更好地管理提交和分析。

---

里程碑 3：模拟活动和预扩展（约第 3 个月）- 支付 30% 资金

• 在监督下部署真实测试活动（如 AMA 提升、链上提升）。

• 与真实用户测试奖励分配和验证流程。

• 研究自动化链上行动验证（如 iCKB 锁定的预言机）。

• 发布赞助商和贡献者的入门文档。

• 最终测试、错误修复和下一阶段提案的 DAO 报告。

---

成本明细

成本按里程碑细分，反映 3 个月的全职开发者工作。

网站托管、域名、IPFS 存储的费用将由 Nervos Community Catalyst 承担。

结论

CKBoost 为可持续的社区参与系统奠定了基础，任何项目、赞助商或贡献者都可以从中受益。该提案详细说明了其实施的设计、技术架构和分阶段路线图。该平台旨在为社区贡献提供结构化和透明的框架，利用链上机制进行奖励分配和认可。

该项目的核心是构建一个实用的开源工具，与 CKB 生态系统的去中心化理念保持一致。通过专注于模块化合约设计和Anyone-Can-Host的服务，该平台是为了弹性和未来可扩展性而构建的。

我将致力于在整个过程中提供透明的里程碑更新和社区反馈。欢迎大家在提出想法、问题和建议。

感谢信任和支持！

— Alive24

[Dondara]

great proposal as it has a strong potential to drive community engagement and ecosystem growth.

[d3fus7.bit]

How is this different from this one:
https://www.ckbrewards.org/ ?

[neon.bit]

@d3fus7.bit The bounty board is for specific tasks that in many cases only need to be completed by one person (write an article, create an infographic etc). The quest platform is for more basic tasks that everyone in the community can do (e.g. raid social media posts). Both are described in the original NCC announcement.

That said, it’s quite likely that they will be merged in time.

[AIIA]

You used manus to generate that, right? The style of the image is so consistent with the style of my lottery dapp, it’s so funny, is this how you make money?

[AIIA]

so funny

[crookednervosness]

I would vote for this, here is the proposal?

[6figs]

I love this!

[matt_ckb]

please refrain from personal attacks on the forum

[Alive24]

Voting proposal is ready at https://dao.ckb.community/thread/vot-ckboost-gamified-community-engagement-platform-proposal-61358

[Alive24]

I reposted to start the vote immediately at https://dao.ckb.community/thread/vot-ckboost-gamified-community-engagement-platform-proposal-61358

All links in this post is updated.

[phroi]

Hey @Alive24, congratulations on the successful Community DAO funding!!

I was wondering, how is the project coming along? Could you share some juicy details?

Love & Peace, Phroi

[Alive24]

Hey Phroi!

Sorry for the late reply!

I’m already wrapping up for milestone 1 and will be releasing this week.

During this stage, a great proportion of the effort were put in preparing for shared libraries that would be used for later stages, including lots of the designs implemented in ckb_deterministic which would be consolidating patterns and utilities that are used in this project (and even those earlier like Stable++ and pausable udt) for a better dev experience and capability.

Above that, I’ve also built some utilities such as continuouse generation of data classes from a singleton mol schema for both the dapp and contract, nostr usage for non-persistant data, much more simplified tools to debug transaction with tracing, etc.

[matt.eth]

Which week？

[phroi]

@Alive24

During this stage, a great proportion of the effort were put in preparing for shared libraries that would be used for later stages, including lots of the designs implemented in ckb_deterministic which would be consolidating patterns and utilities that are used in this project (and even those earlier like Stable++ and pausable udt) for a better dev experience and capability.

That sounds so cool!!

If I can give you a small suggestion, try to see what of your work can be integrated in common libraries such as CCC and ckb-std (applicable?) cause otherwise nobody else will use your utilities, not even if they clearly solve an existing issue.

I did this mistake with iCKB CCC integration and now I’m redoing it piece by piece improving CCC wherever possible.

At any rate, it is good to prototype separately and later on re-do things with better integration.

@matt.eth

Which week？

I wouldn’t rush someone who is developing: he’s working on a few innovative solutions and that takes time, usually much more than anticipated

I’m sure that when he’s ready to deliver, he’ll let us know!

Love & Peace, Phroi

[Alive24]

Yes of course I’ve been always working on building upon CCC and ckb-std, and I’ve been only building things into new libraries if they are not covered and won’t be covered there. I don’t like rebuilding wheels when there’s existing ones to great extent XD.

I’ve finished most of the wrapping ups and finished the M1 report, and I’m preparing for the testing (including some works on docs and devops) as I get some direct feedback from Jordan and Neon who’s been watching this project closely.

[Alive24]

Milestone 1 Report for CKBoost

Preface

Development of CKBoost for Milestone 1 will be moving into review stage as we start to roll out more guidance and coordination on testing. At the same time, development for Milestone 2 has already started as well.

Overview

CKBoost Milestone 1 delivers the bare bone framework for CKBoost, implementing core smart contracts, dApp infrastructure, and essential user workflows. Additionally, the ckb_deterministic framework was developed to provide standardized smart contract validation patterns.

Notes: In milestone 1, we focus on delivering the bare bone framework of the project which involves a high level of interdependency between core modules of both smart contracts and dApp. As we progress to the next milestones, we will switch to issue based development and continuous delivery.

Delivered Components

Core Features

• Protocol deployment with multi-admin management

• Campaign creation with quest quota system

• UDT funding through secure lock contracts

• Campaign approval with on-chain registry.

• Quest submission interface with markdown support and Nostr intermediate storage

• User registration data storage

• Submission review/approval, Points UDT reward minting, and UDT distribution for rewards

• Unified molecule schema and type generation

Smart Contract Layer

• 5 core contracts deployed: ckboost-protocol-type, ckboost-campaign-type, ckboost-campaign-lock, ckboost-user-type, ckboost-points-udt

• ConnectedTypeID pattern for O(1) cell lookups and binding using type_id

• Quest submission/approval/reward workflow with on-chain registry.

• Rule-based validation for all contracts

• SSRI Compliance for all contracts

CKB Deterministic Framework

• Comprehensive framework for deterministic smart contract development

• Unified TransactionRecipe style routing in combination with SSRI.

• Transaction context with recipe parsing and dependency validation

• Universal and customizable cell classification and retrieval

• ValidationPredicate functions with full TransactionContext access

• Jest-like assertion

• Type ID implementation and utilities

• Wrapped debug macros (debug_trace, debug_info) for contract debugging

CKBoost Shared Library

• Shared Rust library for common contract functionality

• Molecule type definitions generated from unified schema during build

• Common error types and error handling across all contracts

• Universal TransactionContext for all contracts

• Shared validation rules and helper functions

• ConnectedTypeID implementation for type_id pattern

dApp Infrastructure

• React/Next.js deployment: CKBoost

• SSRI integration for transaction building/validation separation

• Three role-based dashboards implemented: Platform Admin, Campaign Admin, and User

• Wallet connectivity via @ckb-ccc/connector-react

• Nostr integration for intermediate decentralized submission storage

SSRI-CKBoost Library

• TypeScript SDK for complete dApp-contract interaction

• SSRI trait implementations for Protocol, Campaign, and User contracts

• Transaction building helpers for all contract methods

• @ckb-ccc integration for wallet operations

Dev Utilities

• Automated contract deployment script with upgrade support

• New TypeScript generation script with ccc integration for molecule schema during build with both exact and Like types for flexibility

• Contract upgrade management with tag versioning

• Wrapper for transaction debugger

• Debug from transaction hash

• Debug from raw transaction input (directly copy from wallet like UTXOGlobal)

Testing & Documentation Status

• Test coverage designed and drafted but not strictly implemented yet

• Milestone 1 Testing Guideline drafted and under revision and coordination

• PRD-driven development methodology established

• Milestone 1 reports and follow ups drafted.

[Alive24]

CKBoost Milestone 1 Testing Guideline

Preface

As we are still in the development phase, the testing guideline is subject to change as we progress. Considering the size of the project, please check carefully if you’re testing features that are in the scope of M1. There are also deferred issues and new todo items in the [Follow Ups](./Milestone 1 - Follow Ups.md) document, so please check them out too before further testing or reporting.

Overview

This document provides comprehensive testing guidelines for CKBoost Milestone 1 release. The testing covers three main user roles: Platform Admin, Campaign Admin, and Regular User. All bugs and feedback should be reported as GitHub issues in the CKBoost repository.

Testing Environment

Prerequisites

1. CKB Testnet Wallet: Install a CKB-CCC compatible in-browser wallet (UTXOGlobal is recommended); tests have not been done with the rest of the supported wallets while reports are welcomed).
2. Test CKB: Obtain testnet CKB from the faucet
3. Browser: Tested on Chrome and Brave;
4. Test UDT Tokens: Shall share the test tokens with Stable++ which is available publicly at https://testnet0815.stablepp.xyz/

Access URLs

Note: Links to each of them will be available based on your roles under the global wallet connector.

• Main Application: https://ckboost.netlify.app/
• Platform Admin: /platform-admin
• Campaign Admin: /campaign-admin
• User Dashboard: /campaigns

Test Accounts

Any account can test as regular user while testing as platform admin and campaign admin shall be done after invitation and onchain authorization. Contact by creating issue or commenting here if you would like to try access too.

Testing Scenarios by Role (In M1 Scope)

1. Platform Admin Testing (Authorization Required)

Platform admins manage the entire protocol, including deployment, configuration, and campaign approvals.

1.1 Protocol Deployment & Configuration

Test Scenario: Initial Protocol Setup.

Note: You need to setup a brand new instance of CKBoost to test this part as it’s already deployed online.

1. Navigate to /platform-admin
2. Connect your wallet
3. Verify you see the Protocol Management section
4. Test Protocol Deployment:
   • Click “Deploy Protocol” button
   • Enter required parameters (admin addresses, UDT settings)
   • Confirm transaction
   • Expected: Protocol cell successfully deployed on-chain
   • Report: Any deployment failures, unclear error messages, or UI issues

Test Scenario: Protocol Management

1. In Protocol Management, find “Add Admin” section and “Add Endorser” section
2. Manage Admin:
   • Try adding admin by address
   • Try adding admin by script hash
   • Submit with wallet signature
   • Expected: New admin appears in list
   • Report: Invalid address handling, transaction failures
3. Manage Endorser:
   • Try adding endorser by address
   • Try adding endorser by script hash
   • Submit with wallet signature
   • Expected: New endorser appears in list
   • Report: Invalid address handling, transaction failures

1.2 Campaign Review & Approval

Test Scenario: Campaign Approval Workflow

1. View pending campaigns in dashboard
2. Review Campaign:
   • Click on a pending campaign
   • Review all details (title, description, quests, funding)
   • Check quest rewards configuration
   • Expected: All information clearly displayed
   • Report: Missing data, unclear UI elements
3. Approve Campaign:
   • Click “Approve Campaign”
   • Sign transaction
   • Expected: Campaign status changes to “Approved”
   • Report: Approval failures, status not updating

2. Campaign Admin Testing (Authorization Required)

Campaign admins create and manage individual campaigns with quests and rewards.

2.1 Campaign Creation

Test Scenario: Create New Campaign

1. Navigate to /campaign-admin/new
2. Fill Campaign Details:
   • Enter title (test with various lengths)
   • Add short description
   • Add long description
   • Select categories
   • Set start/end dates
   • Choose difficulty level
   • Expected: Form validates input correctly
   • Report: Validation issues, character limits not enforced

2.2 Quest Management

Test Scenario: Add Quests to Campaign

1. In campaign creation/edit, click “Add Quest”
2. Configure Quest:
   • Enter quest title and description
   • Add subtasks (if any)
   • Set quest difficulty
   • Configure rewards:
     • Points amount
     • UDT distribution (if applicable)
   • Set initial quota
   • Expected: Quest added to campaign
   • Report: Quest not saving, reward calculation errors

Test Scenario: Edit Existing Quest

1. Click edit icon on existing quest
2. Modify quest details
3. Save changes
4. Expected: Changes persist
5. Report: Edit not working, data loss

2.3 Campaign Funding

Test Scenario: Initial Campaign Funding with UDT

1. In campaign funding tab, click “Add Initial Funding”
2. Add UDT Funding:
   • Select UDT token from registry
   • Enter amount (test with decimal values)
   • Confirm funding transaction
   • Expected: Funding reflected in campaign
   • Report: Token selection issues, amount calculation errors

Test Scenario: Campaign Lock Management

1. View campaign lock status
2. Test Unlock Scenarios:
   • Admin unlock attempt
   • Time-based unlock (if applicable)
   • Expected: Proper access control enforced
   • Report: Unauthorized unlocks, lock status display issues

2.4 Submission Review

Test Scenario: Review Quest Submissions

1. Navigate to Submissions tab
2. Review Submissions:
   • View submission content (stored on Nostr)
   • Check user verification status
   • Approve/reject submissions
   • Expected: Smooth review workflow
   • Report: Content loading issues, approval failures

3. Regular User Testing

Regular users participate in campaigns, complete quests, and earn rewards.

3.1 User Registration & Verification

Test Scenario: First-Time User Setup

1. Connect wallet at /campaigns
2. Create User Profile:
   • System should detect no existing user cell
   • Fill verification data:
     • Name
     • Email
     • Twitter handle
     • Discord username
   • Submit profile creation
   • Expected: User cell created on-chain
   • Report: Cell creation failures, data not saving

3.2 Campaign Browsing

Test Scenario: Browse Available Campaigns

1. Navigate to campaigns list
2. Filter & Search:
   • Filter by category
   • Filter by status (active, upcoming, ended)
   • Search by keyword
   • Expected: Accurate filtering results
   • Report: Filter not working, incorrect results

Test Scenario: View Campaign Details

1. Click on a campaign card
2. Review Information:
   • Campaign description
   • Quest list with rewards
   • Participation requirements
   • Current progress/stats
   • Expected: All information displayed correctly
   • Report: Missing data, layout issues

3.3 Quest Participation

Test Scenario: Submit Quest Completion

1. Select a quest in campaign
2. Click “Submit Quest”
3. Complete Submission Form:
   • For each subtask, provide evidence/response
   • Use markdown editor for formatting
   • Storage Options:
     • Test Nostr storage (recommended)
     • Test alternative storage
   • Submit quest completion
   • Expected: Submission stored and pending review
   • Report: Submission failures, storage issues

Test Scenario: Edit Previous Submission

1. View a previously submitted quest
2. Click “Edit Submission”
3. Modify responses
4. Resubmit
5. Expected: Updated submission saved
6. Report: Edit not available, changes not saving

3.4 User Dashboard

Test Scenario: Track Progress

1. View user dashboard
2. Check Statistics:
   • Total points earned
   • Quests completed
   • Pending submissions
   • Available rewards
   • Expected: Accurate statistics
   • Report: Incorrect calculations, missing data

Test Scenario: View Submission History

1. Navigate to submission history
2. Review Past Submissions:
   • Approved submissions
   • Rejected submissions
   • Pending reviews
   • Expected: Complete history displayed
   • Report: Missing submissions, status errors

Cross-Role Testing Scenarios

Campaign Lifecycle Test

1. Platform Admin: Deploy protocol and configure
2. Campaign Admin: Create and fund campaign
3. Platform Admin: Approve campaign
4. Regular User: Submit quest completion
5. Campaign Admin: Review and approve submission
6. Regular User: Verify rewards received

Multi-User Interaction Test

1. Multiple users submit to same quest
2. Test quota limits enforcement
3. Test concurrent submission handling
4. Verify fair distribution of rewards

Security Testing

Input Validation

1. Test XSS attempts in text fields
2. Test SQL injection patterns (though using blockchain)
3. Test buffer overflow with extremely long inputs
4. Report: Any successful exploits

Authorization Checks

1. Attempt admin actions without admin role
2. Try to approve own campaign
3. Attempt to modify other users’ submissions
4. Report: Any unauthorized access

Bug Reporting Guidelines

Creating GitHub Issues

When reporting bugs, use this template:

**Bug Title**: [Role] Brief description

**Environment**:

- Browser:
- Wallet:
- Network: Testnet/Mainnet
- User Role: Platform Admin/Campaign Admin/User

**Steps to Reproduce**:

1.
2.
3.

**Expected Behavior**:

**Actual Behavior**:

**Screenshots/Videos**: (if applicable)

**Transaction Hash**: (if applicable)

**Error Messages**: (copy exact error text)

**Severity**: Critical/High/Medium/Low

Severity Guidelines

• Critical: System crash, funds at risk, complete feature failure
• High: Major feature broken, significant UX impact
• Medium: Feature partially working, workarounds available
• Low: Minor UI issues, cosmetic problems

Feature Requests

Use the “enhancement” label and provide:

• Use case description
• Expected benefit
• Priority suggestion

Contact & Support

Reporting Channels

• GitHub Issues: GitHub · Where software is built
• Direct message to @Alive24 on Nervos Talk

[Alive24]

Milestone 1 Follow Ups

UX Improvements

1. Don’t skip loading campaign or protocol even if wallet is not connected. Just use a generic client without signer.

   • Camapaign Detail page

2. Non Admin should be properly guided away from admin page, and admin links (including Parse Nostr Submission) should not be on the wallet connector

3. In Platform Admin Dashboard - Campaign Reviews, approved campaigns should not show up. The tag showing “1 Connected Campaigns” should be removed too.

4. fetchAllUserCells is available for Pending Submissions

   <Badge className="bg-yellow-100 text-yellow-800">
     <Clock className="w-3 h-3 mr-1" />
     {/* TODO: Get actual pending count */}
     Pending Submissions
   </Badge>
   

5. Show Points UDT balance for regular users in the navigation bar (on the left of the wallet connector).

6. In campaign detail page, buttons should show up for campaign-admin and platform-admin to manage (jump to /campaign-admin)

7. Quests with UDT rewards should show it in the tags too in the Quests tab in the campaign detail page, campaign cards on campaign list (it’s now mock data, replace them), and also in the Submission tab for campaign-admin detail page.

8. In the Rewards tab for campaign, should show info about Total Points Rewarded and the available UDT rewards left (also provide the available completion quota calculated with the average amount of UDT rewards per quest dividing the left over)

9. Quest progress on campaign card

10. JoyID compatibility issue

11. Nostr submission for editing

12. Indicate approved submission (not editable as such)

13. Simplified Quest Submission UI

Contract Improvements

1. Validate approve_completion UDT amount in campaign-lock.

DevOps

1. Full walkthrough on Netlify;

M1 Deferred Issues & New Todo Items

The following issues are deferred as they are not critical features at the moment but they will be registered as trackable issues.

1. Approve Completion - Status Check Commented Out

• File: /contracts/contracts/ckboost-campaign-type/src/recipes.rs
• Content:

// TODO: Not handling this for now
// // Verify campaign status is active (4)
// if input_campaign_data.status() != 4u8.into() {
//     debug!("Campaign is not active, status: {}", input_campaign_data.status());
//     return Err(DeterministicError::BusinessRuleViolation);
// }

• Issue: Campaign status validation is disabled, allowing approval at any status.
• Status: Deferred as only necessary for marginal cases.

2. Protocol Type - Timestamp

• File: /contracts/contracts/ckboost-protocol-type/src/recipes.rs
• Content:

// TODO: Implement proper timestamp retrieval from header deps
// TODO: Check expiration when we have proper timestamp access

• Issue: Protocol timestamp is accurate and validated
• Status: Deferred as only needed in tipping proposal and it is not a critical feature at the moment.

3. SSRI Server Error Reporting

• File: Multiple service files in /dapp/lib/services/
• Issue: When SSRI server is not ready, errors are generic.
• Status: Deferred as implementations of executor is not confirmed yet and it shouldn’t be sensible to generic users.

4. Re-funding after approval of campaign

• Issue: After approval of campaign, the re-funding interface is not available yet.
• Status: Deferred as it is not a critical feature at the moment.

5. Store Campaign cover with Nostr

• Issue: Campaign cover should be stored on Nostr
• Status: Deferred as it is not a critical feature at the moment.

6. Rewards stats for campaign detail page

• Issue: It’s getting the available rewards but not the distributed rewards.
• Status: Deferred as it is not a critical feature at the moment.

7. Endorser info for campaigns

• Issue: Endorser info is not showing up for campaigns.
• Status: Deferred as it is not a critical feature at the moment.

8. Campaign Rules are descriptive

• Issue: Campaign Rules are only descriptive. Should work together with automatic submission approval.
• Status: Deferred as it is not a critical feature at the moment.

(NOTE: All items in this post are either solved or posted as issues).

[neon.bit]

Thanks @Alive24 for your work so far. I have conducted a review of the above M1 testing scenarios and provided feedback or bug reports where necessary. Based on this I would suggest he is ready to proceed to M2. @zz_tovarishch