运营过程的制度缺失： DAO 的金库由一个 2/3 多签（Jan, Terry, Cipher）的金库委员会管理，但谁来监督项目进展、谁来核查里程碑交付物、由谁来正式通知多签人付款、如何披露金库使用情况等，这些关键的运营角色和流程存在模糊性。过去，部分职责（如检查Nervos Talk上提案是否30个点赞、核查非技术性里程碑、通知多签人打款）由社区成员 Jacky 以非正式、自发的形式承担，但这并非制度性安排。这种依赖个人而非机制的模式存在脆弱性和不可持续性。
监督角色的错位瓶颈： DAO v1.0 流程中，DAO在投票通过，批准初始预算后，便完全缺席了后续的里程碑监督决策环节。里程碑的核查工作由单一成员非正式承担，难以对技术、市场、设计等多元化的项目交付物做出全面的事实核查与披露。这导致了两个问题：首先，监督可能流于形式；其次，也是更关键的，DAO作为最终决策者，缺位了对项目执行过程的持续监督。
在 DAO 语境下，这个模型完美契合。CKB 质押者是 DAO 的“业主”，拥有对资金使用等DAO治理事务的最终决策权。但让每个人都去参与跟进项目进展、核查代码交付、组织社区会议等程序性事务，同样并不现实。本提案提议的DAO 物业，其本质正是一个服务于全体“业主”的、拥有多元化技能（技术、市场、研究）的专业程序性团队，作为中立的服务方，为 DAO v1.1 的日常运作提供支持。
3.1.2 定位使命
团队定位： DAO 物业是一个由社区信任、受 DAO 资助、并向全体投票人负责的程序型服务与促进团队。
核心使命： 作为中立的服务提供者和流程促进者，为社区治理提供高质量的运营、监督和技术支持。
权力边界： DAO 物业成员不拥有提案的审核通过权，也不拥有任何投票决策权。其所有行动目标，是保障治理过程的公平、透明和高效，并将最完整、最中立的信息呈现给社区决策者。
无决策权： DAO 物业团队不拥有提案的审核通过权，也不拥有任何投票决策权。他们是社区决策、治理的“服务员”，而非“审批官”。
Adjusted: The estimated timeline for “Milestone 1: MVP Development and Testnet Launch” is extended from 2 months to 3 months (Sep 2025 - end of Nov 2025).
Adjusted: The estimated timeline for “Milestone 2: Mainnet Launch and Trial Operation” is correspondingly shifted by one month to (Dec 2025 - mid-Feb 2026).
Changelog (Oct 23, 2025):
Adjusted: Shortened the Community Review Period to 21 days, and the AMA requirement has been adjusted to at least 1 session (Section 3.3.2).
Adjusted: The multi-sig implementation for the Project Execution Wallet, managed by the DAO Stewards, will no longer be specified and will instead be detailed in the future “Operational Handbook” (Sections 3.1.3 & 3.2.1).
Changelog (Oct 18, 2025):
Improved: Replaced the milestone inaction clauses with a new, automated milestone delay review process (within Section 3.3.2), removing the potential of Steward discretion and guaranteeing the community to directly decide on how to handle project delays.
Improved: Added a clarification to the “Fixed USDI Amount” funding option (within Section 3.2.2), which requires proposers to disclose the equivalent CKB value at submission time to ensure a predictable voting threshold.
Changelog (Oct 15, 2025):
Added: A “Milestone Deadline & Project Stalls” clause to the governance process (Section 3.3.2). Based on feedback from @knmo and the community, this empowers the DAO Stewards to initiate a review if a project stalls, closing a potential governance loophole: “Each milestone in a proposal must have a publicly stated, estimated deadline. If a project team fails to deliver a milestone within 30 days of its stated deadline, the DAO Stewards are empowered to directly initiate the ‘Project Full Review, Final Ruling, and Termination (Crisis Management)’ process.”
Added: A requirement for the DAO Stewards to create and maintain an “Operational Handbook” (Section 3.1.4). Based on feedback from AMA #1, this will separate high-level meta-rules from day-to-day operational procedures, enhancing transparency and adaptability: “One of the core responsibilities of the first Stewards team will be to compile and publish the first version of the “DAO Stewards Operational Handbook.” This document will detail the day-to-day procedures for implementing the governance rules. Each subsequent team, upon election, will be responsible for revising and updating this handbook to reflect lessons learned and adapt to community needs.”
Removed: The “Fixed USD Value (Paid in CKB)” funding option (Section 3.2.2). Based on feedback from AMA #1 regarding its operational complexity, we have simplified the funding policy to focus on the more straightforward “Fixed CKB” and “Fixed USDI” options.
Changelog (Updated Sept 10, 2025):
Changed: Reclassified the proposal from a “Budget Request” to a “Meta-Rule Change” based on constructive feedback to ensure procedural integrity. (Section 1 Statement on the Nature of the Proposal)
Added: Incorporated the option for USD / USDI denominated funding based on community feedback, and detailed its operational flow within the two-tier treasury system. (Section 3.2 Budget Denomination and Payment Currency)
1. Background and Objectives (Why)
CKB Community Fund DAO (hereinafter referred to as the DAO) v1.0 was a successful experiment in community governance, providing us with valuable experience. However, as the ecosystem has evolved, its minimalist rules and fragmented governance tools/platforms have revealed challenges in operational efficiency, project oversight, and community participation experience.
The current governance process of DAO v1.0 heavily relies on the spontaneous actions of community members, as illustrated below:
By analyzing this process and communicating with former operational contributors, we have identified five major structural challenges at the procedural level in DAO v1.0:
Lack of Institutionalized Operational Processes: The DAO’s treasury is managed by a 2/3 multi-sig treasury committee (Jan, Terry, Cipher), but key operational roles and processes are ambiguous. Who supervises project progress? Who verifies milestone deliverables? Who formally notifies the multi-sig holders to make payments? How is treasury usage disclosed? In the past, some responsibilities (like checking for 30 likes on Nervos Talk proposals, verifying non-technical milestones, and notifying multi-sig holders for payments) were informally and voluntarily handled by community member Jacky, but this was not an institutional arrangement. This reliance on individuals rather than a structured system is fragile and unsustainable.
Misaligned Oversight Roles and Bottlenecks: In the DAO v1.0 process, once a proposal is approved and the initial budget is allocated, the DAO is completely absent from the subsequent milestone oversight and decision-making. Milestone verification is informally handled by a single member, making it difficult to conduct a comprehensive factual review and disclosure for diverse project deliverables (technical, marketing, design, etc.). This leads to two problems: first, oversight can become a mere formality; second, and more critically, the DAO, as the ultimate decision-maker, is absent from the continuous supervision of the project execution process.
Fragmented Governance Tools and High Barriers to Entry: The current governance process spans multiple platforms: proposals and discussions on Nervos Talk, followed by formal voting on Metaforo. This fragmented experience not only increases the participation cost and cognitive load for community members but also leads to scattered information and loss of context, which is a major reason for low governance participation.
Lack of Information Dissemination Channels: During community discussion and voting, the dissemination of proposals relies on personal forwarding by the project team or active community members, lacking an official, neutral channel for information outreach. This results in information asymmetry, where core discussions fail to reach as many community members as possible in a timely manner, affecting the breadth and depth of decision-making. Similarly, after a project concludes, the lack of information channels restricts the community’s and the public’s understanding of and participation in the latest ecosystem developments.
Gaps in Key Processes: Projects lack a formal completion report and process, which prevents the accumulation of experience and the reuse of knowledge. The DAO cannot learn and grow from past funding. This process gap means that each new project starts from scratch, unable to build upon a systematic project management and knowledge accumulation mechanism.
These issues collectively point to a core dilemma: DAO v1.0 has a democratic decision-making mechanism but severely lacks the professional, continuous procedural services required to support the effective implementation of these decisions.
This proposal aims to address this dilemma. We propose, while preserving the core democratic spirit of v1.0 (e.g., voting weight based on Nervos DAO deposits), to conduct a upgrade to the DAO’s operational rules and supporting infrastructure by introducing two core components:
A professional operational team serving the DAO: the DAO Stewards, complemented by clear treasury management and governance processes.
A brand-new Web5-based governance platform to replace the current fragmented tools and enhance the overall governance experience.
Statement on the Nature of the Proposal (Updated Sept 9, 2025)
Following extensive, rigorous, and valuable discussions with community members, a consensus has been reached that to uphold the highest standard of procedural integrity, this proposal should be classified as a Meta-Rule Change Proposal.
Our team agrees with this assessment and is grateful for the community’s engagement in this foundational debate. Therefore, if this proposal proceeds to a formal vote, it will be subject to the more stringent conditions required for a meta-rule change.
To ensure the absolute clarity of this vote, we hereby commit that:
This proposal will be voted on as a single, indivisible package. If the proposal does not meet the passing threshold for a meta-rule change, it will be considered entirely rejected. In that event, our team will not seek DAO funding for any portion of it, we will also not unilaterally implement within the DAO any of the procedural changes contained herein, nor act in the capacity of any new roles defined in this proposal (such as the DAO Stewards) within the DAO.
We believe this is the most responsible path forward and honors the community’s desire for rigorous oversight.
2. The Team (Who)
This proposal is initiated by a group of community contributors with the support of the CKB Eco Fund. We are a diverse team that blends community passion, development expertise, and ecosystem strategic vision, dedicated to building a truly usable public infrastructure for DAO v1.1, enabling the community’s democratic decisions to be more smoothly translated into ecosystem development results.
2.1 Team Members
Baiyu (Team Advisor): Partner at the CKB Eco Fund. Baiyu will serve as the advisor to this proposal, providing strategic guidance and ecosystem resources to ensure the project remains aligned with the long-term development of the CKB ecosystem and DAO.
Yixiu (Project Manager / Test Lead): An OG member and long-term contributor to the CKB community with extensive experience in developer communities. Yixiu will be responsible for the overall project management, coordinating resources, and leading the community testing phase to ensure the final product meets the community’s genuine needs.
Zhouzhou (Operations Lead): Research Lead at the CKB Eco Fund. Zhouzhou has in-depth knowledge of decentralized governance and excels at translating complex concepts into actionable operational strategies. His experience in operating the CKB Eco Fund Spark Program will also be brought to DAO v1.1. He will be responsible for designing and initially executing the operational framework for the DAO Stewards team.
David (Development Lead): A seasoned community developer, the creator of Solo Mining Pool for CKB, and core developer of the first Web5 App, xjdao.xyz. David possesses a deep understanding of CKB’s underlying technology and Web5, he has consistently been committed to creating value for the community through code. He will lead the overall technical architecture and development of the governance platform.
2.2 Collaboration Model
This proposal aims to establish a healthy collaboration model within the CKB ecosystem: community members identify genuine problems, propose solutions, receive support from the Eco Fund, submit proposals to the Community Fund DAO, and upon receiving DAO approval and funding, ultimately deliver results to the community and be subject to DAO oversight.
The role of the CKB Eco Fund is strictly limited to the early incubation and support of this proposal. Should this proposal be approved by the DAO, the operation of v1.1 (including the formation of the Stewards team and platform maintenance) will function as a completely independent, community-funded project, accountable only to the DAO, with no subordinate or reporting relationship to the CKB Eco Fund.
Through this project, we hope to set an example for more community members with great ideas and capabilities: as long as your idea is solid and you are willing to put in the effort to build, the Eco Fund is more than willing to provide the necessary support to help you submit a proposal to the Community Fund DAO, and together, we can build a more prosperous CKB ecosystem.
3. Deliverables (What)
A. Service Delivery
3.1 DAO Stewards
3.1.1 Defining “Stewards”
In everyday language, the term “Steward” is often misunderstood as a manager with ambiguous power boundaries in a residential community, sometimes even perceived as a “ruler” within a specific social organization (especially in the Chinese context) due to various real-world issues. However, from a political and sociological perspective, the work of steward is precisely a purely procedural service created to solve the collective action problem.
Modern communities, born from private property rights, have numerous public facilities (like elevators, roads) and public order. Theoretically, these public affairs should be decided upon and maintained by all property owners collectively. In practice, however, it is unrealistic to expect all owners to invest their energy in handling these tedious matters, which is known as the “collective action problem.” The emergence of steward, through neutral and professional services, liberates owners from complex public affairs, allowing them to focus on core issues while ensuring the community’s normal operation. Its essence is to be entrusted by all owners to provide professional services, without ever interfering with the owners’ sovereignty.
In the context of a DAO, this model is a perfect fit. CKB stakers are the “owners” of the DAO, possessing the ultimate decision-making power over DAO governance matters such as the use of funds. But it is equally unrealistic to expect everyone to participate in procedural tasks like following up on project progress, verifying code deliverables, and organizing community meetings. The DAO Stewards proposed here are essentially a professional procedural team serving all “owners,” equipped with diverse skills (technical, marketing, research), acting as a neutral service provider to support the daily operations of DAO v1.1.
3.1.2 Positioning and Mission
Team Positioning: The DAO Stewards are a procedural service and facilitation team trusted by the community, funded by the DAO, and accountable to all voters.
Core Mission: As neutral service providers and process facilitators, to provide high-quality operational, oversight, and technical support for community governance.
Scope of Authority: DAO Stewards do not have the power to approve proposals or make any voting decisions. The objective of all their actions is to ensure the fairness, transparency, and efficiency of the governance process and to present the most complete and neutral information to the community decision-makers.
No Decision-Making Power: The DAO Stewards team does not have the authority to approve proposals, nor does it have any voting decision-making power. They are “servants” of community decision-making and governance, not “approvers.”
No Interpretive Power: The DAO Stewards team has no authority to interpret or arbitrate rule disputes; they can only execute procedures strictly according to the written rules approved by the community.
Financial Responsibility: The Stewards team has no autonomous financial authority. Their responsibilities related to funds are limited to:
After the community votes to approve a project, notifying the main treasury multi-sig holders to transfer the total project budget to the corresponding project execution wallet.
As multi-sig holders of the project execution wallet, fulfilling the procedural obligation of signing for payment after each milestone is confirmed by a community vote, along with other multi-sig holders.
As community members, Stewards retain the right to exercise their personal vote on all proposals based on their voting weight.
3.1.3 Core Responsibilities
In line with their positioning and mission, the core responsibilities of the DAO Stewards revolve around their procedural authority.
Proposal Lifecycle Management:
Proposal Coaching and Standardization: Provide clear proposal templates and assist applicants in refining their proposals.
Organizing Community Q&A: Responsible for organizing community AMAs or public debates before a proposal goes to a vote.
Oversight and Reporting:
Milestone Verification: For proposals that have received funding, responsible for verifying their milestone deliverables.
Publishing Verification Reports: Publicly release verification reports to the community at each milestone.
Transparency and Communication:
Treasury Asset Transparency: Responsible for operating and maintaining an asset dashboard based on the multi-sig wallet.
Information Outreach: Ensure that all important governance information effectively reaches community members.
3.1.4 Team Formation and Rotation:
Initial Formation: To ensure an efficient and stable launch, the formation of the first DAO Stewards team will be guided by the proposal team. Meanwhile, we will open to the entire CKB community to find the best candidates for the core professional roles within the Stewards.
Subsequent Elections: After the DAO Stewards team has been operational for one year, fully community-based elections will be initiated. Each term for the Stewards team will be one year.
3.1.5 Operational Funding:
During the initial formation phase, the operational funds for the DAO Stewards team are proposed within this proposal.
After community-based elections begin, the operational budget for the DAO Stewards team (such as member salaries, tool development fees) should also be applied for from the DAO every year in the form of an independent proposal.
3.1.6 Performance Evaluation and Accountability:
The DAO Stewards will publish a quarterly work report to the community, detailing their work content, service effectiveness, and budget usage.
The community has the right to initiate a vote of no confidence in the Stewards team at any time, or to vote on whether to renew their service at the end of their term.
3.2 Treasury Management and Financial Policies
3.2.1 Two-Tier Treasury System
To balance asset security, execution efficiency, and community oversight, we propose a clear two-tier treasury system. The balance and all transfer operations of both tiers of the treasury should be publicly displayed on the DAO governance platform.
Tier 1: DAO Main Treasury
Positioning: The core asset pool of the entire DAO, which is the current Community Fund DAO treasury.
Management: Continues to be managed by the existing fund management committee according to v1.0 rules and multi-sig methods.
Responsibility: After a proposal on the v1.1 platform is approved by vote, and upon notification from the DAO Stewards team, the total budget for that project is transferred to a newly created project execution wallet for that project.
Tier 2: Project Execution Wallet
Positioning: A temporary multi-sig wallet created independently for each approved project, used exclusively for that project’s milestone funding.
Management: Managed by a 2/3 multi-sig, with signers composed of:
DAO Steward Representatives x 2: provide neutral and professional services.
Community Observer x 1: Invited and publicly announced by the DAO Stewards from community members who actively participated in the discussion of the proposal.
Responsibilities:
Receive the total project budget transferred from the main treasury.
Pay the start-up funds and each milestone payment to the project team according to the process.
Upon project completion, either pay the outstanding funds to the project party or return any surplus funds in the wallet to the main treasury.
Upon project termination, return all remaining funds in the wallet to the main treasury.
3.2.2 Budget Denomination and Payment Currency
In response to community concerns about CKB price volatility and to provide greater flexibility and financial certainty for all future proposers, this proposal introduces multiple options for budget denomination. Proposers may choose one of the following methods:
Fixed CKB Amount: Propose a fixed amount of CKB, and disclose the equivalent USD value in the proposal based on the CKB/USD exchange rate at the time of submission.
Fixed USDI Amount: Propose a fixed amount of the ecosystem stablecoin, USDI, and disclose the equivalent CKB amount in the proposal based on the CKB/USD exchange rate at the time of submission.
Fund Flow Process Description
Suppose project a applies for a budget equivalent to 50,000 USD. The following examples illustrate the fund flow using Scenario A: Fixed CKB Amount and Scenario B: Fixed USDI Amount.
Proposal Approval: The community votes to approve project a’s total budget on the governance platform:
Scenario A: 10,000,000 CKB (equivalent to $50,000 USD at the rate of 0.005 CKB/USD at the time of submission).
Scenario B: 50,000 USDI (pegged 1:1 to USD).
Project Budget Allocation: The DAO Stewards notifies the main treasury multi-sig holders about the project establishment. The holders execute the multi-sig to transfer from the main treasury:
Scenario A: 10,000,000 CKB
Scenario B: 10,000,000 CKB converted to 50,000 USDI
These funds are transferred to a newly established execution wallet for project a. The three holders of project a’s execution wallet (2 property representatives and 1 community observer) execute a 2/3 multi-sig to pay 20% of the total budget to the project team’s wallet as startup funding:
Scenario A: 2,000,000 CKB
Scenario B: 10,000 USDI
Milestone Completion: Project a completes its first milestone. The DAO Stewards team publishes a verification report for the community quick poll.
Milestone Payment: (For passes the vote) The three holders of project a’s execution wallet (2 Steward reps, 1 community observer) execute a 2/3 multi-sig to pay the milestone funds (for example, 20%):
Scenario A: 2,000,000 CKB
Scenario B: 10,000 USDI
to the project team.
Project Completion: If project a’s execution wallet has remaining funds upon project completion:
Scenario A: The execution wallet holders sign to transfer all remaining funds to the project team’s wallet
Scenario B: Same as Scenario A
Project Termination: If the project is terminated for any reason and there are remaining funds in the Project a execution wallet, the holders of the execution wallet sign to return the full remaining amount to the main treasury.
3.3. Governance Rules and Process
To achieve the above objectives, we propose a new suite of governance rules and processes. It builds upon v1.0 by integrating the role of the DAO Stewards and optimizing the entire lifecycle from proposal deliberation to execution oversight. All processes will be completed on the new Web5 governance platform.
3.3.1 Scope of Governance
Same as DAO v1.0, governing two types of matters:
Making decisions on budget requests for ecosystem development projects.
Making decisions on modifying the meta-rules of the DAO.
3.3.2 Proposal Lifecycle
Phase 1: Community Review - 21 days
Proposers submit proposals using a standardized template on the Web5 governance platform.
Upon submission, the proposal automatically enters a 21-day public community review period. During this time, all community members can discuss it under the proposal.
The DAO Stewards must facilitate broad coverage of project information and community discussion during this period:
Organize at least 1 public Q&A sessions for the community. If multiple projects apply concurrently, sessions can be combined and ordered by proposal submission time.
Summarize community discussions, questions, and proposer responses weekly and sync them on the Nervos Talk Community Fund DAO section and various CKB community social media platforms.
During the community review period, the proposer can continuously refine the proposal content.
Condition for Passing: There is no threshold in this phase. After the 21-day review period, the proposer can choose whether to proceed to the next phase.
Phase 2: Approval Vote - 7 days
Initiation Condition: The proposer must hold at least 100,000 CKB in the Nervos DAO to initiate a vote on the Web5 governance platform.
Voting Mechanism: Voting power is based entirely on the user’s CKB deposits in the Nervos DAO, continuing the direct weighted voting model of v1.0.
Condition for Passing: Follows the core logic of v1.0.
Budget Proposal: “For” votes ≥ 51%, and the total CKB voted must be at least 3 times the requested budget.
Meta-Rule Change Proposal: “For” votes ≥ 67%, and the total CKB voted must be at least 185,000,000 CKB.
Phase 3: Execution Oversight
Project Start-up: After the proposal passes, the DAO Treasury and the project execution wallet will disburse the initial funding.
Milestone Oversight:
All proposals involving fund usage will be paid in stages. Initial funding will be limited to 20% of the total budget, with a maximum cap of $10,000 USD.
Proposals with a total budget exceeding $10,000 USD must have clear milestones, with payments made per milestone.
Each milestone in a proposal must have a publicly stated, estimated deadline.
After each milestone is delivered, the DAO Stewards must publish a verification report within 7 days.
If a project team fails to deliver a milestone within 30 days of its stated deadline, this review process is automatically triggered.
Once triggered, the DAO Stewards must communicate with the project team and, within 7 days, publish a delay status report. This report must include: the team’s explanation for the delay, current progress, and a revised milestone plan with a new, reassessed deadline proposed by the project team.
After the report is published, subsequent funding requires a quick confirmation vote from the community before it can be executed.
Quick Confirmation Vote Description: To balance governance efficiency with community oversight and avoid voter fatigue and formalism, the quick vote uses an “optimistic governance” model of “default pass with a community veto right”:
Voting Period: 3 days
Voting Options: Confirm VS Veto (The specific meaning of “Confirm” depends on the report: for a delivered milestone, it means “Confirm Funding”; for a delayed milestone, it means “Accept New Plan”.)
Minimum Turnout:
No less than the requested budget for the project (for budget proposals).
No less than 185,000,000 / 3 = 62,000,000 CKB (for meta-rule change proposals).
This minimum turnout is 1/3 of the initial approval turnout, considering the objective fact that community attention naturally declines during project execution. This allows DAO members who remain engaged to act as “whistleblowers” to pause the process and draw community attention for further review.
Decision Threshold and Outcome: Provided the minimum turnout is met, if Veto Funding votes are ≥ 51% (for budget proposals) or ≥ 67% (for meta-rule change proposals), the funding is vetoed. Otherwise, the funding is automatically approved.
If a project has no milestones, the final report and payment will be handled as a milestone.
Project Full Review, Final Ruling, and Termination (Crisis Management):
Process for handling a funding veto during milestone oversight:
Once funding is vetoed, the milestone is paused, and this and all subsequent milestone funds are immediately frozen.
The DAO Stewards must organize an emergency community meeting within 48 hours to facilitate a public dialogue between the project team and the veto voters to clarify the issues.
After the dialogue, the DAO Stewards will summarize the meeting minutes and submit them for a community full review vote.
Voting Period: 7 days
Voting Options: Terminate Project and Reclaim Funds VS Resolve Issues and Continue
Minimum Turnout: Same as for the initial proposal approval.
At least 3 times the total requested budget (for budget proposals).
At least 185,000,000 CKB (for meta-rule change proposals).
Decision Threshold and Outcome:
Provided the minimum turnout is met:
If “Terminate Project and Reclaim Funds” wins (≥ 51% for budget proposals, ≥ 67% for meta-rule changes), the project is formally terminated, and all remaining funds are returned to the DAO v1.0 main treasury. The DAO Stewards will issue a project termination report.
If “Resolve Issues and Continue” wins, the project returns to normal status, and the frozen milestone payment is disbursed.
If the vote fails to meet quorum (e.g., insufficient turnout), this indicates the community has not reached a consensus on immediate termination. To respect the veto from the milestone oversight, the milestone funds remain frozen, and the project enters a 30-day rectification period, during which a detailed rectification plan must be submitted. After this period, the community will hold a final ruling vote.
After the 30-day rectification period, the DAO Stewards will organize a final ruling vote. To balance governance efficiency with community oversight, this vote uses a “pessimistic governance” model of “default reject with a community approval right”, requiring the project team to proactively regain the community’s trust:
Voting Period: 7 days
Voting Options: Approve Rectification Plan VS Reject Rectification Plan
Minimum Turnout:
At least 3 times the total requested budget (for budget proposals).
At least 185,000,000 CKB (for meta-rule change proposals).
Decision Threshold and Outcome:
Provided the minimum turnout is met:
If “Approve Rectification Plan” wins (≥ 51% for budget proposals, ≥ 67% for meta-rule changes), the project is considered “resolved and continued.” The previously frozen milestone payment will be immediately disbursed, and the project returns to normal status.
If “Reject Rectification Plan” wins, the project is formally terminated as per “Terminate Project and Reclaim Funds.”
If the vote fails to meet quorum, the project is also automatically and formally terminated as per “Terminate Project and Reclaim Funds.”
Project Completion: The project is successfully completed, and funds are disbursed according to the treasury management plan. The Stewards team creates a completion report based on the deliverables and project implementation process.
Status Updates: The Stewards team is responsible for continuously updating the project status and funding records on a public dashboard.
3.3.3 General Rules
No Proxy Proposals: All proposals must be submitted by the project lead using their did:ckb identity.
No Vote Incentivization: Any form of airdrop or asset incentive in exchange for votes is prohibited.
B. Tool Delivery
3.4 Web5 Governance Platform
We will develop a one-stop Web5 governance platform to host all v1.1 governance processes. This platform is not just a tool upgrade but an implementation of a DAO governance philosophy.
Unified Experience: End the fragmented Nervos Talk + Metaforo + Multisig Wallet model. We will seamlessly integrate the entire process of proposal discussion, voting, oversight, and funding into a single platform, significantly reducing the community’s participation cost and cognitive load.
Process Transparency: Every core aspect of the platform will be maximally transparent. From every transaction in the treasury to every report from the Stewards team, all governance data will be public, traceable, and immutable.
User Sovereignty: The platform will use did:ckb as its core identity, returning ownership of governance identity and related data to community members, laying the foundation for a more open and composable governance ecosystem in the future.
3.4.2 Core Platform Modules
Module 1: Governance Homepage
As the platform’s entry point, it provides a global information overview for all users. It features a two-column layout, with a dynamic proposal feed on the left and a fixed personal dashboard on the right, ensuring core personal information is always visible.
Proposal Dashboard:
Displays all proposals as a stream of cards, clearly marking their current status (Community Review, Voting in Progress, Milestone Delivery, Project Review, Completed, Terminated).
Each card intuitively shows the proposal title, proposer, requested budget, and key progress (e.g., voting percentage, milestone completion).
Features: Provides keyword search and status filtering functions, allowing users to quickly locate specific proposals.
Personal Dashboard (Fixed Right Column):
My Governance: Displays the current user’s DID, real-time CKB voting power read from the Nervos DAO, and highlights pending actions (e.g., proposals to vote on).
Treasury Overview: Concisely displays the main treasury’s core financial data and provides a one-click link to the treasury details page.
Module 2: Proposal Details Page
This is the core page for deep interaction with a single proposal.
Top Information Bar: Contains the proposal title, proposer’s DID, total requested budget, and a prominent dynamic status timeline.
Main Content Area (Tabbed):
Proposal Details: Displays the full proposal content in a standardized, structured format (background, goals, budget breakdown, team introduction, etc.).
Community Discussion: An integrated, threaded comment system strongly linked to the proposal, where all community members can conduct public inquiries and discussions.
Governance Action Area (Right Column):
Dynamic Panel: Displays different action modules based on the proposal’s status:
Voting Period: Shows a “For/Against” voting panel, including real-time vote percentages, total votes cast, and a progress bar towards the minimum turnout.
Execution Period: Shows a “Milestone Tracker” module, clearly listing all milestone goals and their current status, and providing a “Quick Confirmation Vote” entry point for pending milestones.
Stewards’ Timeline: An official record wall published by the DAO Stewards for announcements like AMAs, meeting minutes, and milestone verification reports. Some records can be clicked to navigate to the corresponding report details page.
Module 3: Personal Profile (Web5 Identity Center)
The user’s hub for managing personal identity, assets, and activity records. The top of the page uses a three-column layout to display the user’s three most core types of information side-by-side, with detailed activity records below.
Core Information Area (Three Columns):
Basic Info: Users can edit their username and link social accounts like Nervos Talk, Twitter, and Telegram.
Web5 Identity: Displays the user’s decentralized identity (DID) and personal data storage (PDS) address in the platform’s unified visual style, and shows the status of privacy controls like data encryption and anonymous browsing.
Wallet & Nervos DAO: Shows the user’s connected CKB wallet address, the CKB balance in the wallet, and the amount of CKB deposited and being withdrawn from the Nervos DAO, with quick action buttons to the NervosDAO.
Activity Records Area (Tabbed):
Proposal History: A list of all proposals initiated by the user.
Voting History: All votes the user has participated in and their choices.
Discussion History: All comments posted by the user.
Activity Statistics: Used to track the user’s governance contributions.
Module 4: Create Proposal Page
Function: Provides a structured form that guides users to fill out the proposal’s various sections according to the official template, including title, background, goals, team, budget breakdown, milestone planning, etc.
Goal: Ensure that all proposals submitted for community review have complete and standardized information, improving governance efficiency.
Module 5: Treasury Page
Achieves full transparency in the display of DAO assets.
Main Treasury Dashboard: Graphically displays the main treasury’s total assets, allocated funds, and available funds. It also publicizes the main treasury’s multi-sig address and all signer DIDs, providing on-chain verification links.
Project Wallet List: A table showing all approved project execution wallets, their current balances, the 2/3 multi-sig composition (Steward DIDs + Community Observer DID), and links to the associated proposals.
Module 6: Stewards Page
This page serves both as a public announcement board and an internal management tool.
Stewards Team Display (Public Section): Shows all visitors the member information of the current DAO Stewards team, including names and DIDs, reflecting governance transparency.
This section is only visible after a Steward connects their wallet and verifies their identity.
It displays a to-do list of tasks requiring Steward action (e.g., standardizing new proposals, organizing community AMAs, verifying milestone deliverables, publishing verification reports) and provides corresponding action entry points.
Module 7: Report Details Page
Used to display various official documents published by the Stewards.
Function: As a standalone page, it fully presents the various reports linked from the “Stewards’ Timeline,” such as “Community AMA Meeting Minutes” and “Milestone Verification Reports,” ensuring information integrity and traceability.
4. Project Plan & Budget Request (How & The Ask)
This section details the implementation path, key milestones, budget composition, and funding schedule for the DAO v1.1 optimization project.
4.1 Milestone Plan and Deliverables
We have divided the project’s execution path into four distinct milestones.
Milestone 0: Project Kick-off
Estimated Timeline: 1 month (August 2025)
Core Objective: To complete all preliminary project preparations, establishing a solid foundation for the development phase.
Key Deliverables:
Finalization of the core team.
A complete technical architecture design document.
The final product prototype and partial UI/UX design drafts.
Milestone 1: MVP Development and Testnet Launch
Estimated Timeline: 3 months (September - late November 2025)
Core Objective: To develop an MVP with core functionalities and launch it before CKCon 2025 for initial community testing and feedback.
Key Deliverables:
An account system supporting Web5 did:ckb registration, QR code login, and account import.
Implementation of core governance features: proposal submission, detailed view, community discussion (comments), and voting.
A user profile center that supports binding a Nervos DAO address.
A homepage with a proposal list, treasury information display, and basic multi-language support.
Core Objective: To complete the development of all planned features, deploy the platform to the mainnet, and begin the community trial operation period.
Key Deliverables:
A feature-complete platform stably deployed in the mainnet production environment.
Launch of the milestone-based proposal governance feature.
Enhancement of homepage functionality, including a data overview dashboard, proposal search, and status filtering.
Completion of the Stewards Team and Governance Rules information pages.
The first round of bug fixes and UI/UX optimizations based on community feedback.
Milestone 3: Formal Operation by Stewards Team
Estimated Timeline: 12 months (commencing after the completion of Milestone 2)
Core Objective: For the DAO Stewards team to formally take over the platform’s daily operations and provide continuous, professional governance services to the community.
Key Deliverables:
Assembly of a professional and neutral Stewards team to manage the full lifecycle of all proposals.
Provision of ongoing system maintenance, optimization, and community support.
4.2 Budget Request and Allocation Plan
To accomplish the project plan outlined above, we are requesting a total of $100,000 USD equivalent in CKB from the Community Fund DAO. Based on the CKB/USD price of 0.003421 (2025.10.27), this is equivalent to approximately 29,231,218 CKB.
4.2.1 Milestone-Based Funding Schedule
The total budget will be disbursed in four tranches, strictly tied to the completion of each milestone:
Milestone 0 (Project Kick-off) (10% of total budget)
Payment Trigger: Upon the approval of this proposal by the community.
Milestone 1 (MVP Development and Launch) (52% of total budget)
Payment Trigger: Upon the completion and community verification of all Milestone 1 deliverables.
Milestone 2 (Mainnet Launch and Trial Operation) (20% of total budget)
Payment Trigger: Upon the completion and community verification of all Milestone 2 deliverables.
Milestone 3 (Formal Operation by Stewards Team) (18% of total budget)
Payment Trigger: Upon the commencement of Milestone 3, when the Stewards team formally takes over operations.
4.2.2 Budget Breakdown
The total budget of $100,000 USD is composed of the following three parts (a, b, and c):
a. Development Budget: $72,000 USD
By Role Composition:
Role
Headcount
Avg. Monthly Salary (USD)
Duration (Months)
Total (USD)
UI/UX Designer
1
3,000
2
6,000
Senior Frontend Engineer
1
3,000
4
12,000
Senior Backend Engineer
2
4,000
4
32,000
Senior Smart Contract Engineer
1
6,000
1
6,000
Product/Project/QA Manager
1
4,000
4
16,000
Total
6
72,000
Note: 1. Some roles require high-intensity work over 1-2 months, but all members will provide support until the project is fully delivered. 2. The average day rate is approximately $136 USD.
By Functional Module:
Feature
Key Considerations
Development Cost (USD)
UI/UX
Multiple pages, complex details
6,000
web5did-indexer
Sync on-chain data to a database, provide API access
Milestone data storage and retrieval, status display
800
Stewards’ Timeline Panel
Log proposal lifecycle, state transitions, report submission/retrieval
2,000
Milestone Funding Vote
Similar to proposal voting but with different data sets
3,000
Stewards Team Display
Stewards admin backend, configurable info management, API access
3,000
Governance Rules Page
Multiple static pages
800
Total
72,000
b. DAO Stewards Operational Budget (12 months): $18,000 USD
Role
Monthly Salary (USD)
Total (USD)
Strategic & General Lead
500
6,000
Technical Specialist
500
6,000
Marketing & Community Specialist
500
6,000
Total
1,500
18,000
c. Infrastructure Budget: $10,000 USD
Item
Term
Cost (USD)
Voting Contract Deployment
-
900
Testing Environment - Application Server
1 Year
1,500
Testing Environment - Database Server
1 Year
1,500
Testing Environment - PDS Server
1 Year
1,500
Production Environment - Application Server
1 Year
1,500
Production Environment - Database Server
1 Year
1,500
Production Environment - PDS Server
1 Year
1,500
Domain Name
2 Years
100
Total
10,000
5. Conclusion
This proposal focuses on solving the most pressing operational and tooling issues of DAO v1.0, offering a low-risk, high-reward optimization plan. It concentrates on providing tangible services and value that can immediately enhance the DAO’s governance capabilities. We believe this is a pragmatic and efficient step forward in promoting the small, rapid, and continuous evolution of Nervos community governance.
We eagerly await your valuable feedback and look forward to building a more prosperous ecosystem together.
Thank you for your time and consideration.
舟舟
On behalf of the v1.1 Proposal Team (Yixiu, David, and Baiyu)
FAQ
We anticipate that the community may have questions about certain aspects of this proposal. We are addressing them proactively here.
1. The spirit of DAO v1.0 was “keep everything simple” to encourage spontaneous community exploration. Doesn’t this proposal, with its professional “Stewards” team and complex processes, contradict that spirit and add bureaucracy?
A: We fully agree with and respect the original spirit of v1.0. However, as practice over the past two years has shown (and as noted in Jan’s reflection), over-reliance on pure spontaneity has led to stagnation in the DAO’s evolution. The core purpose of v1.1 is not to add bureaucracy, but to reduce the hidden costs of participation by providing professional procedural services.
The “Stewards team” acts as “servants” hired by the community, not “gatekeepers.” They handle burdensome procedural tasks (like organizing meetings and verifying deliverables) so that proposers can focus on building and voters can focus on judging the value of proposals. Our goal is to clear obstacles and provide support for true bottom-up innovation, not to replace it.
2. The initial “Stewards team” will be formed by the Eco Fund and the proposal team. How will you ensure its neutrality and prevent it from becoming a new center of power or having conflicts of interest?
A: This is a crucial question. We have designed multiple mechanisms to ensure fairness and neutrality:
Bootstrapping Necessity: The initial support of the Eco Fund is to leverage its existing project management experience to ensure a smooth launch for v1.1, effectively “bootstrapping” this service system. This is a temporary, service-oriented arrangement.
Checks and Balances: The Stewards team has no voting or decision-making power. Their most significant function—verifying milestones—results in a report that is fully public and subject to the community’s final verdict via the “milestone vote.” The community holds the ultimate veto power to halt any payment.
Community Oversight: Our “two-tier treasury” design includes a “Community Observer” invited from active community members to co-manage the project execution wallet’s multi-sig.
Limited Term: The first Stewards team has a clear one-year term, after which a fully community-based election will be held, returning power completely to the community.
3. The requested budget of $100,000 is quite high. Why is an “internal governance system” worth more than many “external ecosystem projects”? What is the Return on Investment (ROI)?
A: The ROI for this budget must be understood on three levels. Firstly, we are delivering not just a software platform, but a robust risk management and due diligence system composed of three integrated parts: the governance processes, the Stewards team, and the technology platform. Its value is:
Risk Mitigation (Insurance): The DAO treasury manages assets worth millions of CKB. The lack of oversight in v1.0 could lead to inefficient fund allocation or waste. This complete system provides a powerful risk management framework for all future DAO expenditures. It is essentially an “insurance policy” for the entire treasury, preventing potentially larger future losses.
Ecosystem Catalyst (Leverage): A professional, efficient, and transparent governance process will attract more and higher-quality builders to apply for funding in the CKB ecosystem. It acts as a multiplier effect that can unlock the entire ecosystem’s innovative potential, a value far exceeding the platform’s development cost.
Public Infrastructure (Lighthouse): This platform is itself a flagship application and open-source public good built on did:ckb and the Web5 philosophy. While serving the DAO, it also explores and validates cutting-edge technology for the CKB ecosystem, providing reusable examples and standards for future projects. We are investing in building the ecosystem’s “highways,” not just a single “car.”
4. Does the “optimistic vote” mechanism for milestones lower the bar for oversight and sacrifice accountability?
A: On the contrary, we believe this activates and strengthens effective accountability. The problem with v1.0 is that the community theoretically has power, but the cost of exercising that power (requiring constant attention and voting on every step) is too high, leading to oversight being largely dormant.
The “optimistic vote” design solves this by drastically lowering the barrier for “whistleblowers” to exercise their oversight power. It no longer requires a majority to “actively approve” every time, but instead empowers a smaller, engaged minority to easily “actively oppose.” If a contentious milestone is vetoed, the system immediately triggers a more stringent, “pessimistic” crisis management process. It is an intelligent, tiered risk-response system that addresses “voter fatigue” while making oversight more feasible and a more credible deterrent.
5. Why build a technically complex Web5 platform from day one? What are the technical risks, and why not solve the problem with simpler technology first?
A: Because the mission of this proposal is not just to solve an administrative efficiency problem. It is a flagship project to practice what we preach and demonstrate the practical application and value of the CKB and Web5 narrative to the entire ecosystem.
Building a Benchmark Application: The CKB ecosystem needs a Type A application (totally decentralized) as a benchmark to showcase the core advantages of Web5. Our core developer, David, has already successfully launched a Type C application (There are certain compromises for large-scale applications), xjdao.xyz, gaining valuable Web5 development experience. We will now leverage this expertise to build a more foundational piece of infrastructure that the entire ecosystem can reuse.
Accumulating Sovereign Data: By adopting a Web5 architecture, all generated governance data (proposals, discussions, voting records) becomes a valuable, sovereign, and composable asset owned by the users themselves. This high-quality on-chain behavioral data can serve as a trusted source for other ecosystem applications in the future (e.g., reputation systems, community credentials), an advantage that traditional centralized tools cannot match.
Controllable Risk: Technically, our team is experienced, and the milestone-based funding mechanism is itself an effective way to manage technical risk. Subsequent funding is only released after key technical deliverables are met.
In contrast, a traditional centralized tool would not fulfill our vision nor contribute truly valuable public infrastructure and sovereign data to the CKB ecosystem.
To help the community better understand and discuss the details of the DAO v1.1 Web5 Optimization Proposal, I’ve created a shared space for it in NotebookLM.
You can ask the AI specific questions about any part of the proposal and view an interactive mind map to quickly see the structure and key ideas.
为了帮助大家更好地了解和讨论 DAO v1.1 Web5 优化提案的细节，我在 NotebookLM 中创建了一个共享空间。
Hi Hongzhou, that’s a lot of info to take in , I’ll have to read this again to get my head around what the changes are as far as the way the DAO will operate.
But I fully support this proposal just for the development of the Web5 platform alone, this is a huge step forward from the current Metaforo system.
A couple of things I want to bring up at the moment:
I don’t see any mention of Neuron wallet or see it in the screenshot, will this not be available to connect directly?
I think this role is extremely important and needs more attention (money), not the ‘marketing’ part so much, but the ‘community specialist’.
I think there’s a big part of the CKB community that needs a lot of encouragement to get involved with the DAO. We need someone who can be very busy (daily when there is a current proposal being considered) in both the Chinese and English speaking communities actively encouraging and helping community members through the whole process of joining in.
Hi Yeti, thank you so much for taking the time to dive into the proposal and for your strong support. We appreciate your candid feedback. You’re right, it’s a lot of information to take in, and we’re here to clarify any questions you have.
Regarding Neuron Wallet, for the initial MVP, our frontend development will prioritize wallets supported by the CCC to streamline development and ensure a smooth launch. Therefore, a direct connection with Neuron won’t be supported. However, since during the login, the only usage of the wallet is creating Web5:did, if you wanna have a try with Neuron, we can provide support.
Regarding the voting weight, we have a clear solution for Neuron users who are also Nervos DAO depositors and wish to vote: the platform will include a secure binding protocol that allows them to delegate voting power from a Neuron-managed address to a CCC wallet address. This allows Neuron users to participate fully in governance without compromising the security of their main holdings. Meanwhile, for JoyID, Global, and other users, NervDAO could be a seamless approach.
Regarding the Community Specialist Role, I couldn’t agree more on the importance of this role for fostering an active and engaged DAO, together with the promotion of completed projects. This is one of the core problems v1.1 aims to solve.
The Community Specialist, as part of the Stewards, won’t just be a passive role. Their responsibilities are built directly into the governance lifecycle to actively foster participation. For every proposal, they will be responsible for:
Organizing at least two public AMAs sessions during the 30-day community review period to ensure proposers and the community can engage directly.
Actively summarizing and syncing discussions across different community channels to keep everyone informed.
Facilitating emergency community meetings/full review/etc., if a crisis occurs, like a milestone vote being vetoed.
The initial budget of $500/month is a pragmatic starting point for the trial operation phase. Given our team’s background and the support from the Eco Fund, we believe this part-time commitment is reasonable to kickstart the system.
During the proposed one-year trial, the Stewards team will produce regular operational reports, which will provide concrete data and insights into the actual workload and impact of the community specialist and any others. I believe this data would serve as a reference for future community-elected Stewards to propose a more refined and data-driven budget for these roles.
while I am very much in support of the ideas laid out here, this proposal is full of what (to me) are clearly meta-rule changes and the higher adoption barrier is appropriate to ensure the integrity of the efforts here.
This may not be an exhaustive list of meta-rule changes proposed, but one should definitely be formalized for a vote
Changing the “7 days+30 likes” is clearly a meta-rule change
While this is a formalization of previous intentions, the entire milestone voting process is a meta-rule change
Adding new parties to disbursement flow is a meta-rule change
Thank you, Matt, for this crucial feedback and for your support of the core ideas in our proposal. You’ve raised a fundamental question about governance integrity that is best addressed by returning to the first principles of our DAO’s constitution.
We absolutely agree that the integrity of the rules is paramount. The DAO v1.0 Rules and Process document lays out a clear legal framework. Let’s analyze it together. The “Scope of Governance” section defines two distinct types of governance actions:
The key here is the distinction between meta-rules (our Constitution) and operational rules (our Bylaws). The document explicitly defines meta-rule governance as those that govern the fundamental rights and powers of the voters.
Other rules within that same document, such as the “7 days + 30 likes” preliminary step, are not included in the definition of rights and powers. Therefore, they should be classified as operational procedures. They are the bylaws that govern how the DAO functions on a day-to-day basis, but they do not define the core power structure itself.
The v1.1 proposal is structured as a project contract, asking the DAO to approve a budget to procure a service that upgrades the DAO’s operational procedures (Bylaws). The new processes, such as the 30-day review period and the milestone voting system, are features of this upgraded operational service. They do not alter the constitutional meta-rules regarding who can vote, how their votes are weighted, or the conditions under which a proposal is formally adopted.
This is our good-faith interpretation of the existing rules. However, we believe this discussion on the distinction between constitutional and operational rules is a vital topic for the entire community to deliberate on. We are very keen to listen to the community’s wisdom on this matter and will respect the consensus that emerges from this discussion.
Thank you again for ensuring we have this rigorous, foundational conversation.
Matt，感谢您提供的宝贵反馈以及对我们提案核心理念的支持。您提出了一个关于治理完整性的根本问题，这个问题最好通过回归我们 DAO 章程的首要原则来解决。
正如 Jordan 本人富有建设性地指出的，拥有“多种路径探索”和“不把所有鸡蛋放在一个篮子里”，是一个健康的去中心化生态系统的标志。我们认为这赋予了社区一次有意义的选择，这是一种优势，而非劣势。此外，我们的 v1.1 提案本质上是关于工具和服务的，它可以被任何未来的治理体系所继承和融合，是一次无损的升级。
问题二：当初在讨论 DAO 2.0 的时候，并没有提及 v1.1 的计划。为什么这个提案现在才出现？
Thank you for the incredible engagement and thoughtful questions we’ve received on the DAO v1.1 proposal.
In the spirit of full transparency and to ensure everyone has access to the same information, we will periodically post a summary of significant questions that arise in the main thread, especially those that concern core governance principles and need the community’s collective wisdom, or questions not within Nervos Talk we’ve received. We will continue to do this throughout the 7-day discussion period.
Q1: I agree that the DAO needs a change, but was it necessary to have two different proposals (v1.1 and v2.0)? Doesn’t this divide the community instead of working on one solution together?
A1: That’s a very fair and important concern. Our intention is absolutely not to divide, but rather to provide a clear and different philosophical choice for how the DAO can evolve.
V2.0 proposal is a revolution, a constitutional change to a delegated democracy model. The v1.1 proposal is an evolution, a budget request to build tools and services that empower the existing direct democracy framework.
As Jordan himself constructively noted, having “multiple avenues” and “not putting all our eggs in one basket” is a sign of a healthy, decentralized ecosystem. We see this as giving the community a meaningful choice, which is a strength, not a weakness. Furthermore, our v1.1 proposal is fundamentally about tools and services that can be inherited and integrated by any future governance system, making it a non-destructive upgrade.
Q2: When the DAO 2.0 effort was being discussed, there was no mention of a v1.1 plan. Why is this proposal coming out now?
A2: The v1.1 proposal is a recent development and was not a pre-existing plan we held back on. It evolved quite quickly from our internal discussions and was greatly informed by the valuable community feedback that followed the v2.0 proposal. We truly appreciate all the effort the v2.0 team put into their proposal; the depth of their research and thinking is both insightful and inspiring.
It was through that process that we saw a clear desire from the community for a pragmatic, evolutionary path to solve the immediate operational issues of v1.0, and we felt it was our responsibility to offer a concrete proposal to address that specific need.
Q3: ( Community Wisdom Needed) Your proposal contains what appear to be clear meta-rule changes. Shouldn’t it be subject to the higher voting threshold to ensure process integrity?
A3: This is a fundamental and crucial question that is best addressed by returning to the first principles of our DAO’s governing document.
The v1.0 Rules establish a clear distinction between meta-rules (our Constitution), which define the fundamental rights and powers of voters (e.g., voting weights, adoption conditions), and operational rules (our Bylaws), which govern day-to-day procedures (e.g., the “7 days + 30 likes” step).
Our team’s view is that the v1.1 proposal is a “project contract” asking for a budget to upgrade the DAO’s operational rules (Bylaws). The new processes, like the 30-day review and milestone votes, are features of this upgraded service. They do not alter the constitutional meta-rules that define the core power structure of the DAO.
However, we acknowledge this is a key interpretation. The community’s consensus on how to classify this proposal is more important than our own view. We strongly encourage everyone to share their perspective on this distinction. We are here to listen and will respect the consensus that emerges from this discussion.
We hope this is helpful. We strongly encourage everyone to continue the discussion publicly in this thread. Every voice matters!
I fully support the distinction of constitutional rules vs operational rules, which is why I also included this in the v2.0 documents. However, I do not see a clear distinction in the v1.0 rules. I agree with @matt_ckb that there are several meta-rule changes included in the proposal.
As I’m sure you’re already aware, changing the meta-rules is difficult even with full support of the community. If you are going to make an effort to change the meta-rules, then it may be worth defining this distinction as part of that change so that operational rules are not so difficult to change in the future.
Problem: DAO v1.0 has operational fragility, fragmented tooling, weak oversight, poor info dissemination, and no post‑project learning, causing low execution quality despite democratic decisions.
Goal: Keep v1.0 voting/meta‑rules unchanged while funding a service+tooling upgrade (DAO v1.1) to improve execution, transparency, and participation.
Core asks (what they want funded):
Establish a professional procedural team called DAO Stewards (neutral facilitators, no decision/voting power, verify milestones, run AMAs, publish reports, manage dashboards).
Build a unified Web5 governance platform (did:ckb identity, integrated discussion→voting→oversight→treasury, public dashboards, milestone workflows).
Treasury/process changes:
Two‑tier treasury: Tier 1 = main DAO multi‑sig (unchanged) → transfers full project budget to Tier 2 = per‑project 2/3 multi‑sig execution wallet (2 Steward reps + 1 community observer).
Staged payments: initial startup ≤ 20% of budget and ≤ $10k, then milestone payments released after Steward verification + a 3‑day “optimistic” quick confirmation vote (default pass unless veto meets thresholds). Veto triggers emergency review, full vote, 30‑day rectification, then a 7‑day “pessimistic” final ruling vote.
Governance rules preserved:
Voting weight, proposer eligibility, and adoption thresholds remain the same as v1.0 (e.g., proposer must hold ≥100,000 CKB; budget proposals require FOR ≥51% and turnout ≥3×budget).
Team & timeline:
Core team: Baiyu (advisor), Yixiu (PM/test), Zhouzhou (ops), David (dev); Eco Fund bootstraps initial Stewards.
Development $72k, Stewards operations (12 months) $18k, Infrastructure $10k.
Disbursed by milestone: $10k / $52k / $20k / $18k.
Accountability & transitions:
Stewards publish quarterly reports; community can call no‑confidence votes; after 1 year steward positions become elected, terms = 6 months.
Rationale: Framing the request as a Budget Request Proposal (not a meta‑rule change) to buy services/tools that reduce hidden participation costs, manage risk, and create public Web5 infrastructure and sovereign governance data.
Treasury funds don’t even need to be converted into USD, the value of CKB granted just need to match the USD value of the milestone. Feel free to take inspiration from this previous suggestion:
Missing iCKB Mention
Given that this is already a real Meta-Rule change proposal, iCKB exists and it’s a fully community-owned project, what’s the reasoning for not integrate it for voting and/or storing treasury value?
If for any reason, you consider even marginally iCKB unsafe I can make a second audit with Trails of Bits funded by CommunityDAO. Last quote from them was 160k USD, so same ballpark cost as this current proposal.
Hi Phroi, thank you for the deep and thought-provoking feedback. You’ve brought up several ambitious and important long-term goals for the DAO, and we appreciate you pushing the conversation forward.
On Proposal Classification: This is the central debate, and we respect your perspective. However, we see a distinction between constitutional meta-rules and operational rules, and have invited the community to weigh in, as their consensus is what truly matters.
On USD Denominated Amounts & iCKB Integration: These are critical topics. However, our v1.1 proposal has a very intentionally narrow and focused scope: to solve the immediate operational and tooling crisis of v1.0 first.
We believe in an evolutionary, iterative approach to DAO governance. Trying to solve everything in one massive proposal would make it incredibly complex (Even so, you can see that the content of the v1.1 proposal is already very large.) Our philosophy is to tackle one major problem at a time through focused upgrades. You can think of it like this:
v1.1 (this proposal): Fixes the foundational operational framework.
A potential v1.2: Could be a dedicated proposal to address economic policies like stablecoin pricing.
A potential v2.0: Could be a major constitutional overhaul, like introducing a representative model.
Our v1.1 proposal is the necessary first step: building the modern, functional “parliament building.” Once that’s in place, it will be the perfect venue for the community to have focused, high-quality debates on major policy changes like those you’ve suggested.
Love & Peace,
Hi Phroi，感谢您深刻且发人深省的反馈。您为 DAO 提出了几个宏大且重要的长期目标，我们很感谢您推动了对话的深入。
I think there’s pretty wide support for USD denomination and I’d also love to see iCKB being used in the DAO, but both of these are obviously big changes and as we are seeing already, this proposal is about to get bogged down by debating what is and isn’t a meta-rule.
I think this proposal lays the framework for eventually making those changes possible.
Thank you, Jordan, for your incredibly constructive and insightful reply. We are very encouraged that we share the same fundamental view on the importance of distinguishing between constitutional rules and operational rules.
You’ve made an excellent point: the current v1.0 rules do not make this distinction explicit, which is the root of the current debate. And your suggestion, that if we are to change meta-rules, we should formally define this distinction for the future, is absolutely the right long-term goal for a mature governance system.
The challenge we face, and the reason we intentionally structured v1.1 as a Budget Request, is a strategic one rooted in the lessons from v1.0. Our primary concern was to avoid the governance inertia that often accompanies major constitutional debates. As we’ve seen, fundamental rule changes can lead to prolonged, complex discussions that, while important, can stall urgently needed practical progress. Our goal is to deliver immediate, tangible fixes to the DAO’s operational framework first.
If we were to add a formal definition of “constitutional vs. operational rules” into our proposal, it would, by its own logic, definitively turn our proposal into a meta-rule change. This would subject this practical, operational upgrade to the very type of constitutional debate process that we believe is better reserved for more fundamental changes, rather than for procuring tools and services.
Perhaps there is a path that honors both our goals:
The community first debates and votes on the v1.1 proposal as a project contract. This allows us to pragmatically address the current operational crisis and deliver value quickly.
Then, leveraging the new, efficient platform built by v1.1, a follow-up meta-rule proposal (perhaps a v1.2) could be introduced with the sole purpose of formally codifying the “constitutional vs. operational” distinction into the DAO’s main rules, making future operational changes much easier, just as you wisely suggested.
We believe this sequential approach allows for both immediate progress and principled, long-term improvement, avoiding the risk of getting bogged down and allowing the DAO to evolve continuously. What are your thoughts on this path?
感谢 Jordan 您极具建设性和洞察力的回复。我们备受鼓舞，因为我们在区分 “宪法规则” 和 “运营规则” 的重要性上，持有相同的根本性观点。
Hi Phroi, my apologies if my last message came across the wrong way. You are absolutely a vital and deeply respected member of this community, and your detailed feedback is exactly the kind of high-quality contribution we need.
To be clear, when I mentioned inviting the “community to weigh in,” I was referring to the specific procedural question of “proposal classification” that Matt raised, which is a broad topic for everyone.
My intention was not to dismiss your excellent suggestions on USD pricing and iCKB, but rather to give them the respect they deserve by arguing they should be major, standalone proposals themselves. Your ideas are too important to be side-notes in a proposal focused on operational tooling.
I hope this clarifies our position. I genuinely value your perspective and hope you continue to be a leading voice in these important discussions.
Love & Peace
Hi Phroi，如果我上一条信息的表达方式有所不妥，我深表歉意。您绝对是我们社区中至关重要的、备受尊重的一员，您详尽的反馈正是我们需要的那种高质量贡献。
我想澄清一下，当我说邀请“社区来权衡”时，我特指的是 Matt 提出的关于“提案分类”的程序性问题，这是一个需要所有人参与的广泛议题。
Another question for @zz_tovarishch: if you are inviting the community to weight in, why was this proposal not presented a few weeks ago to the Community as work in progress? Why present it as completed proposal?
Something as simple as: Hey Folks, we noticed CommunityDAO v2 is taking some time, we are working on creating a CommunityDAO v1.1 to smooth the transition process. These are our ideas, what do you think?
Hi Phroi, thank you for following up. I offer my sincere apologies if my previous reply made you feel unheard. Let me try to address your new points more directly.
On Open Development & Communication:
You’ve raised a very fair point about our communication process. You’re right, we could have shared our work-in-progress earlier. Our intention was to first consolidate our ideas into a coherent and complete proposal before presenting it, to ensure the initial discussion could be focused and productive. But we take your feedback to heart, and it’s a valuable lesson for us on how to better manage community expectations in the future.
On USD Denomination & the “Meta-Rule” Debate:
We hear your frustration. The “meta-rule” debate is indeed a risk, and as Yeti wisely pointed out in his reply, there’s a danger of related proposals getting “bogged down” in it.
This is precisely why our v1.1 proposal is intentionally and narrowly focused on one single goal: to fix the foundational operational framework first.
We believe that important, but complex, changes like USD denomination and iCKB integration deserve their own dedicated debates. As Yeti perfectly articulated, our v1.1 proposal aims to
Love & Peace,
Hi Phroi，感谢您的跟进。如果我之前的回复让您感觉被忽视了，我深表歉意。请允许我更直接地回应您的新问题。
的一个小说明
I Fully support this initiative
, I’ll have to read this again to get my head around what the changes are as far as the way the DAO will operate.
需社区智慧）提案包含了看起来是明确的元规则修改。为了保证程序的完整性，它难道不应该遵循更高的投票门槛吗？
