Thank you to Jordan for organizing this proposal revision. It’s a great thing to turn past experience into structured rules. I’ve served for over four years as an IT budget committee member at a Fortune 500 company, and I’ve implemented many institutional mechanisms in budgeting, project management, and progress tracking. So I’d like to take this opportunity to share some of my thoughts on the DAO, for your reference.
Over the years, DAO-funded projects have seen successes, failures, and even cases of fraud. Failure is not scary — what’s scary is being scammed. It’s never too late to fix the pen after the sheep are lost. Perhaps we should compile a project review list, go over all past applications, and summarize: which ones succeeded? which ones failed? and why?
Goal: A Truly Decentralized Project Application & Governance Platform
1. Lack of End-to-End Accountability: Funds are disbursed like they belong to no one
The original intent of the DAO is to fund quality projects, so we should avoid a process that stops at presenting a PPT, casting a vote, and sending the funds, with almost no follow-up on project execution.
Take this project for example: [DIS] Palmyra: RWA Lending on Nervos
The team took the money — but did they actually deliver anything? Who’s responsible? Can anyone in the community answer?
According to the V2 proposal:
“Accountability - Recipients of grants must remain accountable to deliver on their commitments.”
So here’s the problem: how exactly do we enforce accountability? Who is in charge? What happens if the applicant disappears? Can the funds be recovered?
We’ve seen good actors like William, who, despite facing health issues, voluntarily returned most of the unused funds. But what about those who don’t?
2. Milestone System Exists in Name Only — No One Reviews or Approves
Milestone-based payments are good in theory, but in reality, it’s just “they say it, and we pay.” No validation, no follow-up, no responsibility.
Who is supposed to review the milestone? Where are the evaluation criteria?
Without these, the first payment is practically a graduation bonus.
3. Strictly Ban Proxy Applicants — Only Execution Teams Should Apply
I’ve clearly expressed my opposition to proxy-based applications before:
Just like in traditional engineering tenders, intermediaries introduce too many issues. The Palmyra project is a textbook example.
I also proposed this earlier: 关于DAO的三点改进提议
As the number of projects grows, we must institutionalize a ban on proxy applicants. If something goes wrong, the DAO needs to know who is truly accountable — not chase ghosts.
4. Add a Technical Expert Review Mechanism
The tech capabilities of token holders vary greatly. Many proposals have technical complexity that can’t be understood at a glance. Some may be fooled by fancy words and buzzwords.
I propose setting up a technical expert pool, and for each proposal, randomly select 3 experts to evaluate the technical feasibility.
Only after passing this stage should proposals enter community discussion and voting.
Nervos has enough top-tier technical experts to support this system.
5. Budget in USD, Pay in CKB — But Use Dynamic Price Calculation, or Default to CKB-based Applications
Volatility is a reality. In the past, we worried about prices dropping, leading teams to abandon delivery. But what if CKB price surges midway?
If a project is priced in USD at a low CKB price, and CKB then rises sharply, the DAO ends up giving away a valuable appreciating asset at a steep discount.
In this case, the project team benefits from price appreciation, while the DAO loses long-term value. This creates huge risk in a bull market and undermines capital sustainability.
My suggestions:
- Projects may apply in USD terms;
- But each fund release should be recalculated using the current CKB/USD exchange rate;
- Avoid “cutting ourselves” by paying out based on outdated low prices.
The DAO doesn’t hold stablecoins — it holds CKB.
We can’t just be afraid of price drops and neglect the risk of value loss when prices rise.
Of course, in the future we can also encourage CKB-denominated proposals, where builders and DAO share in the risks and rewards of CKB price fluctuation.
6. Split Structure: Separate Feasibility Assessment and Execution
As project volume increases — especially those over 1M CKB — I propose we separate technical & economic feasibility reviews from the execution itself.
- Is the project worth doing (tech + economics)?
- Can the team actually deliver?
Once feasibility is confirmed, a public team selection process can be initiated. This creates better governance and reduces moral hazard.
I’ve proposed this mechanism before: DAO分层建议
7. Require Man-Month Estimates & Per-Person-Day Cost to Prevent Overpricing
All proposals should clearly specify:
- Total man-months of work;
- Cost per man-month (or person-day);
- Whether pricing is in line with the market.
Let me give an example:
In 2004, IBM quoted us $1500 USD per person-day. We had no choice.
Today, server maintenance in China can cost as low as $200 per person-day, with solid quality.
With the wave of Web3 VC collapses, dev market rates are trending downward.
If DAO aims to allocate resources wisely, involving high-quality, cost-efficient Chinese developers is the best route to maximize returns.
People often talk about the significant gap between Eastern and Western communities — but in reality, many of these so-called “differences” stem from fundamentally different price expectations and cost structures
8. Formalize and Protect the Inquiry Process — No Interference Allowed
In a truly decentralized platform, only two mechanisms remain:
- Community inquiry
- Final voting
The inquiry stage must not become a formality. If a team can’t even answer hard questions, maybe the project isn’t solid to begin with.
The inquiry process is like a public prosecutor’s independent investigation —
no interference, no favoritism, no watering down due to “who submitted it.”
9. Add a Mechanism for Post-Evaluation of Economic Value
In addition to technical feasibility and execution, we should consider adding economic value assessments to both the proposal and post-completion stages.
Let me give an analogy: China’s “Road-to-Every-Village” public infrastructure campaign was, from a purely financial ROI perspective, a loss-making endeavor — the roads could never earn back their construction cost. However, these roads unlocked massive long-term value by stimulating rural economies and enabling the movement of people and goods.
Similarly, some DAO-funded projects may not be profitable in the short term, but they might play a key role in catalyzing ecosystem vitality, adoption, or developer engagement.
I propose that we introduce an economic value assessment module:
- In the application phase: ask applicants to provide their anticipated economic impact, even if indirect;
- After project completion: conduct backward-looking evaluations on what economic value was actually created (e.g., traffic, new users, network effects, CKB burned or locked, developer reuse, etc.).
This will help the DAO accumulate institutional knowledge, and improve decision-making quality over time.
10. The DAO Should Establish a Clear Exit Mechanism for Funded Projects
The Palmyra case highlights a crucial gap: while the DAO has a funding mechanism, it lacks a formal exit mechanism.
For projects that fail to meet their committed milestones, remain inactive for extended periods, or show no signs of execution, the DAO should define clear exit criteria and procedures, such as:
- Reclaiming unused funds;
- Public evaluation by the community or designated reviewers;
- Requiring the team to re-apply or explain delays.
Without a proper exit system, the DAO risks turning into a funding black hole — or worse, a source of reputational damage.
One Final Note: Do I Have a Personal Agenda? Yes — I Want a Healthy DAO
I am not targeting the English-speaking community.
I am not favoring the Chinese-speaking community.
My only personal agenda is this:
I want the DAO to use every CKB wisely, to grow the Nervos ecosystem, and to help the CKB I hold increase in value. That’s it.
Just as Nervos seeks to prevent a “tragedy of the commons” on-chain,
I don’t want to see a DAO-level tragedy of the commons happen under our own noses.
Thank you to everyone who read this far. I truly hope DAO v2 will bring stronger structure, deeper trust, and better outcomes for us all.
— woodbury.bit
感谢 Jordan 组织这次方案修改。将过去的经验总结并形成制度是一件好事。我曾在世界500强企业担任专职 IT 预算委员，在参与的预算、项目管理、进度管控中大量运用了制度化手段，所以借这个机会，也想表达一下我对DAO项目的一些思考，仅供参考。
这几年DAO的项目，有成功、有失败，也被骗过。失败不可怕，怕的是被骗。亡羊补牢，为时未晚。我们是否应该拉一份清单，把之前申请过的项目逐一梳理，总结一下哪些项目成功了，哪些项目失败了？失败的原因是什么？
目标：去中心化项目申报审核管理平台
1、缺乏闭环管控：只批预算不管后续，像谁的钱都不是似的
DAO 的本意是资助好项目，要尽量避免流程只走到「讲个 PPT + 投个票 + 发笔钱」，后续执行几乎没人追踪。
举个例子：[DIS] Palmyra: RWA Lending on Nervos 这个项目，钱拿走了，到底有没有做？谁在负责？有人能回答吗？
如果对照 V2 草案中的这句：
“Accountability - Recipients of grants must remain accountable to deliver on their commitments.”
那么现在问题是：后续的项目到底是怎么负责？谁来负责？如果项目申请人跑路了，能追回来吗？
就算是像 William 这样的好同志，身体出问题了还能退回大部分预算，那如果遇到更糟的情况，预算就彻底打水漂了吗？
2、里程碑机制形同虚设，没人审核，没人负责
分阶段付款是对的，但现在说白了就是“说了就给”，没人验证，也没人Care。希望将“里程碑事件”变成一个有具体责任人、有验收流程的制度，不然就是放空炮。
谁来审核？审核标准在哪？没有这些，项目拿到第一笔钱就等于毕业了。
3、建议禁止任何形式的代理申报，项目必须由实际执行人提交
我曾经明确反对代理人申报项目，[DIS] Palmyra: RWA Lending on Nervos - #19 by woodbury.bit ，就像传统工程里的代理招标一样，问题太多。Palmyra 是典型案例。
我曾提过这个建议：关于DAO的三点改进提议
未来项目多了以后，一定要从制度上明确禁止代理行为。否则出了问题，DAO连人都找不到。
4、增加技术专家审核机制
社区成员技术水平参差不齐，很多项目的技术壁垒一眼看不出，有可能被“高大上”唬住。
建议建立一个“技术专家库”，从中随机抽取3人，对提案中的技术逻辑进行评估与打分，只有通过这个关口，才进入后续讨论与投票流程。
Nervos 的技术社区人才水平是足够支撑这个制度的。
5、资金发放建议采用“美元定价、CKB支付”机制，但必须按释放时价格动态计算，或直接以 CKB 为本位定价
CKB 的价格波动是当前必须面对的现实。过去我们更担心币价下跌导致项目方执行困难，但反过来，如果未来 CKB 大幅上涨，而项目是在低价阶段以“美元为本位”申请并锁定预算，那 DAO 实际上就是低价出让了本该升值的核心资产。
这种情况一旦发生，不仅项目方等于白拿币价上涨的“溢价”，DAO 反而承担了资产流失的风险——这种机制在牛市中极其不利于 DAO 的长期资产保值与可持续发展。
因此我建议：
- 项目申请时仍可采用“美元本位”进行预算编制；
- 但每一笔资金发放应按发放当日的 CKB/USD 汇率进行重新换算；
- 防止 DAO 在 CKB 上涨时还按老汇率继续“割自己”。
DAO 本质上是以 CKB 为资产池的组织，不是稳定币机构。我们不能只担心 CKB 下跌时项目方跑路，也要防范币价上涨时 DAO 自己吃亏、资产被稀释的情况。
当然，未来条件成熟后，也可以直接以 CKB 为本位进行报价和申请，让项目与生态风险直接挂钩，共享价值波动带来的风险与收益。
6、预算可实行“分层结构”：项目可行性与执行分离
未来项目多了，特别是预算高的项目，例如超过100万个CKB的项目，建议把“可行性评估”与“具体执行”分离处理。
- 是否值得做（从经济性和技术性双维度）；
- 做的人是否靠谱。
项目评估通过后，可以再公开遴选团队执行。这样更规范，也更降低风险。
这个机制我之前也提过：DAO分层建议
7、明确每个项目的人月估算和单价，避免预算虚高
我强烈建议所有预算都需明确写出：
- 多少人月工作量；
- 每人月单价是多少；
- 是否高于市场均价。
我分享一个例子：2004年IBM给我们公司报价是 $1500 美元一人日（不是人月），我们必须买，没得选。
现在中国的服务器维修一人日才 $200，水平还不差。Web3 领域VC暴雷潮之后，开发市场价格还会继续下行。如果DAO希望资源配置更有效，让更勤奋、质量更高、成本更低的中国工程师参与是最佳选择之一。
人们常说东西方社区之间存在巨大差异，但实际上，很多所谓的“差异”，本质上源于对价格预期和成本结构的根本不同。
8、项目质询制度必须制度化且不可干预
在一个真正去中心化的平台里，项目审批只有两个关口：一个是质询，一个是投票。
质询环节不能流于形式，项目方不能抱着“随便糊弄一下”的心态。如果连质询都怕，说明这个项目本身就不稳。
质询制度就像检察院调查一样，是一种制衡。不能有人干预，不能有人带节奏，不能因为是谁提的就放水。
9、增加项目的经济价值后向评价机制
除了技术可行性与执行能力之外，建议在项目申请与项目结束阶段都增加经济价值层面的评价机制。
举个例子：中国曾经实施的“公路村村通”工程，从账面建设成本看，是一条永远也无法靠收费回本的亏损公路。但这条路却极大激活了沿线乡村的经济活力、人员流动与长期发展潜力，其实际带来的“价值”远超财务回报。
DAO 中也会遇到类似的情况：有些项目可能短期内看不到直接利润，但却可能是推动生态活力、促进开发者参与、扩大 CKB 使用范围的关键一环。
因此我建议 DAO：
- 在项目申报阶段，要求申请人预估其潜在的经济或生态影响，即便只是间接的；
- 在项目结束后，引入经济回顾性评价机制，评估项目是否带来了例如：流量提升、新用户增长、生态再利用、CKB 锁仓/销毁等正向指标。
这不仅有助于我们积累决策经验，也能不断优化 DAO 的资源配置效率与战略眼光。
10、DAO 应建立明确的资助退出机制
Palmyra 的案例提醒我们，DAO 不仅要有资助机制，更要有退出机制。
对于那些未按照计划推进、长期停滞、没有履约迹象的项目，DAO 应设定明确的退出条件与流程，包括但不限于：
- 回收未使用的资金；
- 社区或评估人对进度做出公示性判断；
- 项目方主动重提申请或说明原因。
一个没有退出机制的资助体系，最终将演变成“资金黑洞”或“声誉风险源”。
最后补充一点：我有没有私心？有。我希望DAO能更健康
我不是在针对英文社区，也不是在偏袒中文社区。
我唯一的“私心”是：希望 DAO 用好每一笔钱，推动 Nervos 生态价值的提升，让我手里的 CKB 能涨价，仅此而已。
Nervos 不希望区块链变成“公地悲剧”，我更不希望我们自己的 DAO 成为“DAO 版的公地悲剧”。
感谢所有认真看完这些建议的朋友，期待这个 V2 能带来更完善、更可信的 DAO。