@jm9k What sort of timeframe are we looking at here to get v2 off the ground?
1 Like
11. Establish a Clear DAO Project Change Control Mechanism
In reality, many projects encounter delays, scope changes, team adjustments, or tech stack shifts during execution.
However, the current DAO lacks a formal “change management process,” which leads to updates being delivered late — or worse, silently brushed over.
To ensure transparency and responsible fund usage, the DAO should introduce a lightweight but effective change control framework that includes:
- Clear triggers for when a project must submit a change request (e.g. extended timeline, scope modifications);
- A formal change submission process where teams must explain why, what’s changing, and the updated timeline;
- Defined review paths: changes must be reviewed and approved by delegates, technical reviewers, or even via community vote;
- Unreleased funds should be frozen until the change request is reviewed;
- All approved changes should be recorded and archived for accountability and transparency.
DAO doesn’t mean “freedom without rules” — it means “freedom with clear responsibility.”
Projects may change, but accountability should not be optional.
12. Establish a Biannual Project Review & Reporting Framework
Currently, once DAO grants are approved, there is no formal follow-up or periodic tracking of their execution.
This creates a blind spot: the community has no clear overview of which projects are delivering and which are quietly drifting off track.
We recommend implementing a baseline policy:
- Every 6 months, all DAO-funded projects must be reviewed and summarized;
- A designated person or committee publishes an overview: status, completion %, funds spent, milestones reached;
- Project teams should submit brief progress updates;
- The results must be publicly documented and shared with the community.
This will:
- Provide a snapshot of DAO-funded activity;
- Help inform future grant decisions or reforms;
- Increase the public accountability of project teams.
13. Set Up a DAO Project Monitoring & Early Warning Mechanism
The Palmyra case highlights a serious flaw:
Nearly a year went by with no visible progress, no status reports, and no intervention from the DAO or Foundation.
A DAO cannot operate on “fund-and-forget.” Even a lightweight monitoring mechanism is critical:
- Assign one person (or a small group) to monitor active projects and flag irregularities;
- Trigger alerts when signs appear: overdue milestones, silence, team changes, or other red flags;
- Authorized monitors or the community may pause payouts, request explanations, or initiate review;
- All alerts and follow-up actions should be documented and publicly visible.
DAO governance isn’t about distrust — it’s about not relying on blind trust.
Consistent monitoring is a baseline requirement to protect DAO assets and community credibility.
11、DAO 应建立项目变更管理机制
现实中，很多项目都会在实施过程中出现延期、调整内容、修改技术方案或团队结构的情况。
但当前 DAO 缺乏一套正式的“变更管理流程”，导致项目变更时没有标准路径，最终变成“做完了再补报告”或“模糊带过”。
为了保障 DAO 资金的使用透明、过程可控，建议建立一套基础的项目变更处理机制，包括：
- 明确什么情形必须触发“变更申请”：如工期超过预期、交付内容与原计划不一致等；
- 规定变更申请的提交流程：由项目方说明变更理由、影响范围和新的时间线；
- 指定审核角色：由代表、评审人或社区投票确认是否接受该变更；
- 必要时冻结未释放的资金，直至变更审核完成；
- 所有变更记录必须公开归档，以便未来追责和参考。
DAO 不是为了追求形式上的“自由”，而是为了实现程序上的“责任”。
项目可以变，但责任必须变得清楚、流程必须规范。
12、DAO 应建立 半年一次的项目跟踪与公开整理制度
目前 DAO 项目在完成资助后，往往缺乏阶段性的回顾与整理，很多项目在执行过程中无人跟进，也没有定期汇报，造成社区成员无法了解执行进度，更无法判断哪些项目执行良好、哪些存在问题。
建议建立一个最基础的制度：
- 每半年由指定人或委员会对所有 DAO 项目进行一次跟踪汇总；
- 明确每个项目当前的执行状态、完成程度、已拨款与剩余款项；
- 项目方需填写简要项目进展简报，支持公共归档；
- 汇总结果应在社区公开发布，接受社区监督。
这项机制将有助于：
- 给社区提供一个项目进展的“快照”；
- 为后续拨款、复议、评估等治理决策提供数据基础；
- 提高项目方执行的公开压力与交付责任感。
13、DAO 应建立 项目日常监控机制与问题报警制度
Palmyra 项目的情况说明了一个严峻问题：
在长达近一年的时间里，项目既没有实质性推进，也没有主动汇报，而社区与基金会竟然无人介入或提醒。
DAO 治理不是“发钱之后等运气”，应该至少有基础的监控机制：
- 明确由一人（或小组）担任“执行监督角色”，负责每个项目执行过程的基本跟进；
- 出现超期无进展、沟通中断、项目成员变更等异常情况时，应触发“项目预警”机制；
- 社区或监督人有权暂停资金拨付、要求说明或召集变更审核；
- 所有监控记录与预警通知，应在社区有公开可追踪档案。
DAO 不是不信任机制，而是不能没有任何机制。
对项目的日常关注，是保障 DAO 资产安全与生态健康的基本功。
1 Like
Very well written! I look forward to seeing it finished! 
2 Likes
Agreed Yeti…What is CKB? A utility token to reserve space on the blockchain (that happens to cost something) or a currency? It cannot be both in this instant because its not stable enough in price to be a SOV. That maybe the case in the future if its less volatile (or at least never retreats down past a certain price) but ultimately it’s not now. These little things no doubt would evolve over time through community adjustments and voting in the DAO. CKB cannot be used in its entirety as a construct currently within a payment system that floats a business. This is even proven by the fact the CKB reserves were mainly in stable coins or so it has been offically announced on many occasions.
3 Likes
I don’t think there is an advantage to the DAO itself. The benefit is more in the encouragement to hold CKB rather than trade it for stablecoins. In the long-term this may help reduce volatility, but I agree that it makes very little sense in the short-term.
1 Like
There is no firm timeline as of yet. I want to start hosting public debate sessions next month on any areas of disagreement or confusion.
We also need to allow the community some time for any alternative DAO designs to be presented if there is interest in doing so.
Once we have overwhelming community consensus around a particular direction, then it’s more likely we will set more formal timelines.
3 Likes
Thanks for the suggestion. I agree it would be easier to follow as GitHub issues, but in the interest of keeping things accessible to the wider community and I want to make sure all avenues are left open for community debate.
Hi Jordan, can I just get some clarification on this part?
Will community members still be allowed to vote individually, or are you saying everyone must go through a representative?
@jm9k
1 Like
What is being described here is the realistic situation that community members cannot be domain experts in all areas. It is also unlikely that most will put in the time and effort to become experts so they can make an informed vote. Not even all “experts” are experts in every area of knowledge.
This is why the representative system has been proposed; so community members can designate someone to make informed decisions on their behalf. However, this does not remove their ability to vote on the issue directly if they choose do to so. Direct voting by community members that are informed on the topics is always preferred.
When a technical review or other review of any kind is produced, it will be posted publicly only as a recommendation. It is not a vote in itself. Votes must always still be cast by representatives and community members on the proposal.
If a community member does not agree with the decisions of a representative, they can immediately remove their delegation from them and delegate to someone else, or remove all delegations.
Above all else, community members always have granular control over how their votes are cast. Not only can they change their delegation at any time, but they can also choose to exercise their vote directly on a single proposal without removing their delegations. For example: Say you delegated to a representative and you believe they are doing a good job in voting with your interests in mind. However, there is one proposal where you disagree with your representative. You can cast your vote directly on this specific proposal and it will overrule the delegation, removing your votes automatically from the representative for this proposal only.
4 Likes
This is not a grant proposal on the v1 DAO. This is a proposal to build an entirely new system that is separate. In particular, portions of this proposal are intended to directly take advantage of the treasury fund, which has always been part of the tokenomics of CKB but is currently being burned. This treasury fund can only be activated by the community in the form of a hard fork.
4 Likes
Ok, sounds good!
I think the delegation system is the game changer here and I fully agree with the concept, but I also think holders retaining their right to vote individually if they want to is really important.
Also, I have to read the whole doc again more thoroughly, so you might have already mentioned this, but have you thought about the issue of Representatives using incentives to get people to delegate to them?
Would this be allowed?
2 Likes
Hey folks, please keep the conversation here focused on the v2 ideas.
Meanwhile I’ve cleaned this thread by moving off-topic conversations into a new thread, feel free to continue there.
5 Likes
If I’m honest until AI agents materialise for DAO usage, humans will have to do lol Its not how I envisioned DAOS years ago but then DAOs tend to lead or be lead by ideological flaws. I’d prefer something that didn’t feel so ‘Polliticky’ with people making cringe comments about how they will ‘do well’ for the cause. But here we are, making the best we can out of a flawed system.
3 Likes
I think the rules should incentivize delegates, thereby fostering competition among them. Such competition can spur the entire community to vote enthusiastically. As for whether delegates will incentivize their own principals, the rules need not place any restrictions on that.
3 Likes
I do not think it should be allowed, but I’m open to hearing any differing opinions if they exist.
2 Likes
Yeah, I think I agree, the community should really be delegating to people who they think hold the same values as them, but competition between representatives is also an interesting aspect which could help promote more involvement.
But this would all come down to how much the Representatives get compensated and how much they are able to ‘give back’ for any incentives.
1 Like
I was wondering, what is the community sentiment on these two ideas? @jm9k do you see any particular show-stopper?
Open-Source
Decentralization of deployments by Type
3 Likes
maybe like a multisig of prominent community members? It is tricky though
2 Likes
Hey Phroi, Jordan has already made this a requirement in his proposal, all CKB specific code must be open source.
I just had a quick look, not sure which section it’s in, but I read it there somewhere.
2 Likes
@Yeti good catch, @jm9k already considered this extensively:
Public Funding Policies
- Public funding implies public code. Every project that received grant funding must agree to open source the Nervos specific portions of the project. This is typically smart contract code, and transaction generation code. It does not include the project’s complete codeebase.
- Projects that receive grant funding in excess of $50,000 USD must agree to provide a reasonable means for the Nervos community to persist the project if the team chooses to abandon it. In most cases the most simple way to accomplish this is to transfer the full source code and all relevant data, accounts, and rights, to a community team that can takeover operation of the project. If a suitable team cannot be found, the project must be open sourced completely.
- Projects that sell virtual assets must agree to provide a reasonable means for the Nervos community to persist said assets if the team chooses to abandon it. Failing to do so is considered a breach of contract, gross negligence, and destruction of personal property.
- Projects that receive a down payment but show little to no progress after 12-months must return the full amount of the down payment to the DAO treasury. Projects can request an extension which is decided by DAO vote. Projects that return the full amount of the down payment remain elegible to submit new grant proposals.
- Projects that fail to meet the requirements of the public funding policies must return the full amount of the grant to the DAO treasury within 90 days of the violation. Projects that are in violation and fail to repay the grant within the 90 day period are subject to pursuit of legal action.
2 Likes