[DIS] Community Fund DAO v1.1 Web5 优化提案/ Community Fund DAO v1.1 Web5 Optimization Proposal

Hi @phroi & @Yeti ,

Thank you both for this incredibly high-quality and insightful debate. Phroi, your questions are forcing us to rigorously examine every detail of the proposal, which is the most valuable part of this Community Review Month.

I want to start by directly addressing the core contradiction you pointed out between the “inaction clause” and the “no interpretive power” principle for Stewards. You are absolutely right. The original wording, “the DAO Stewards are empowered to initiate,” grants them discretion they shouldn’t have. This is a flaw in our previous draft, and we thank you for identifying it.

Based on your feedback, and incorporating Yeti’s view that rules need both rigor and common sense, we have designed a new, automated “Milestone Delay Review Process” to replace the previous clause. We believe this new solution is much more robust.


We propose to adjust the Section 3.3.2 ( Proposal Lifecycle - Phase 3: Execution Oversight - Milestone Oversight) with the following automated process, which removes all Steward discretion:

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.

New

  • 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.

New

  • 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

Adjustment

  • 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 changes to this part)
  • If a project has no milestones, the final report and payment will be handled as a milestone.

This new process ensures that any delay is automatically brought to the community. The Stewards are only responsible for executing the procedure, and the decision to accept a new timeline or escalate the issue lies entirely with the community. We believe this better addresses your concerns.


Point-by-Point Responses to Phroi’s Questions

On the Challenge to Milestone Deadlines:

  • Q1: How do deadlines benefit the broader ecosystem?

    • A: DAO funds are a community resource, and accountability is essential. Deadlines serve as clear accountability triggers. Their purpose isn’t to create undue pressure but to ensure a project maintains regular communication and doesn’t “go silent” indefinitely. It’s about responsible stewardship of our collective assets.
  • Q2 & Q3: What does “Being Empowered” mean & how much authority will stewards have?

    • A: Your question helped us see the flaw in that wording. In our new proposed process, the concept of being “empowered” is removed. Stewards will have zero decision-making authority. They are simply executors of an automated, rule-based process.
  • Q4, Q5, & Q6: What is the rationale for 30 days? Why not longer?

    • A: This is an excellent question about calibration. The 30-day grace period is not a “judgment day” for the project’s success but a mandatory communication checkpoint.
      • Symmetry: A 30-day review period is required before a proposal approval vote, so a 30-day grace period for a missed deadline is a logical and symmetrical check-in point.
      • Timeliness: A delay of over a month usually indicates a significant issue that the community deserves to be aware of.
      • Flexibility: The key is that this trigger does not mean termination. A team can propose a revised plan—even one that extends the total project timeline by a year or more. As long as the community agrees (by not vetoing the new plan or Crisis Management), the project can continue with full support.

On Voting Questions:

  • Q1: Will the CKB price at submission time always be used for USDi proposals?
    • A: Yes. Thank you for this clarifying question. To ensure predictability, we will add the following clarification to Section 3.2.2:

Adjustment

  • 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.

While the CKB price will fluctuate, we believe this is acceptable at the current stage. Moreover, the price at the time of submission best represents the community’s immediate assessment and consensus of the proposal’s value when setting the governance threshold.

  • Q2: Can the presenting team still choose when the on-chain vote begins?
    • A: Yes. As stated in the proposal (Section 3.3.2), after the 30-day review period concludes, the proposer has the flexibility to choose when to initiate the 7-day voting phase. This gives the proposer necessary flexibility, though they also bear the risk of potential declining community attention if they delay the vote for too long.

On Meta Rule Vote Rules:

  • Q: How was the 185M CKB threshold originally chosen?
    • A: The 185M CKB threshold is a legacy rule from DAO v1.0, designed to ensure any changes to the DAO’s fundamental constitution have extremely high community consensus. In the v1.1 proposal, we are respecting and adhering to it. We agree that the rationale for this threshold is a worthy topic for a future debate, which could be a major discussion held on the new, upgraded v1.L platform.

Thank you both again for your invaluable contributions. Your rigorous feedback is making this proposal substantially better. We look forward to hearing your thoughts on these revisions.


Hi @phroi & @Yeti ,

非常感谢你们两位带来的这场极其精彩和深刻的辩论。Phroi,你提出的每一个问题都切中要害,迫使我们深入思考提案的每一个细节。这正是社区审议月最宝贵的价值所在。

我想先正面回应你提出的、关于“不作为条款”与物业“无释法权”之间的核心矛盾。你说得完全正确。 我们最初的版本中“物业团队有权启动…”的措辞,确实赋予了物业不应有的自由裁量权。这是我们草案中的一个缺陷,非常感谢你指出来。

根据你们的反馈,并结合 Yeti 关于规则既需要严谨性又需要常识性的观点,我们设计了一个全新的、自动化的“里程碑延期审查流程”,以取代之前的条款。我们相信这个新方案更加稳健。


我们建议在提案的 3.3.2 章节(提案生命周期 - 第三阶段:执行监督 - 里程碑监督) 中,调整文本以整合这个新的自动化流程。修订后的该部分将如下所示,已标出变更处:

里程碑监督:

  • 所有涉及资金使用的提案均分阶段支付,初始资金将限制在总预算的 20%,最高限额为 10,000 美元。
  • 总预算超过 10,000 美元的提案必须明确里程碑,按里程碑支付。

新增

  • 提案中的每个里程碑都必须有一个公开的、预估的交付截止日期。
  • 每个里程碑交付后,DAO 物业需在 7 天内发布核查报告

新增

  • 如果项目团队在超出其声明的截止日期 30 天后仍未交付里程碑,此审查流程将被自动触发。
    • 流程触发后,DAO 物业团队必须在 7 天内与项目方沟通,并发布一份“延期状态报告”。该报告须包含:团队对延迟的解释、当前进度,以及项目团队提出的修订后的里程碑计划和新的、重新评估的截止日期。
  • 报告发布后,后续拨款需由社区进行一次快速确认投票,通过后方可执行。

  • 快速确认投票说明: 为平衡治理效率与社区监督,避免投票疲劳和治理流于形式,快速投票采用 ”默认通过,附带社区否决权 “的乐观治理模式:

    • 投票时间:3 天

    调整

    • 投票选项: 确认 VS 否决。(“确认”的具体含义取决于报告内容:对于已交付的里程碑,意为“确认拨款”;对于延期的里程碑,则意为“接受新计划”。)*
    • 最低投票数: … (无变化)
    • 决策门槛及结果: … (无变化)
  • 若项目无里程碑,则结项报告、款项支付按里程碑操作。

这个新流程确保了任何延期都会被自动提交给社区。物业只负责执行程序,而接受新时间表或将问题升级的决定权,完全在于社区。我们相信这更好地回应了你的担忧。


对 Phroi 其他问题的逐一回应

关于“对里程碑截止日期的挑战”:

  • Q1: 截止日期对生态有何益处?

    • A: DAO 的资金是社区的共同资产,问责制是必不可少的。截止日期的目的不是施加压力,而是建立一个清晰的 “问责触发点”。其目的并非制造过度压力,而是确保项目保持定期沟通,不会无限期地“沉默”。这关乎对我们集体资产的负责任的管理。
  • Q2 & Q3: “被赋权”是什么意思?物业有多少决策权?

    • A: 您的问题帮助我们发现了措辞中的缺陷。在我们新提出的流程中,“赋权”的概念被删除了。物业将没有任何决策权。 他们只是一个自动化、基于规则的流程的执行者。
  • Q4, Q5, & Q6: 30天这个期限的理由是什么?为什么不是更长?

    • A: 这是一个关于度的绝佳问题。30天的宽限期并非“审判日”,而是一个 “强制沟通的检查点”
      • 对称性: 一个提案立项需要30天审议期,那么在执行中给予30天宽限期作为一个检查点,是合乎逻辑的。
      • 及时性: 超过一个月的延期通常意味着项目遇到了需要社区知晓的实质性问题。
      • 灵活性: 最关键的是,触发这个流程不等于终止项目。团队完全可以提出一个调整后的新计划(哪怕总时长延长一年)。只要社区通过不否决或危机管理的方式接受新计划,项目就可以继续。

关于“投票问题”:

  • Q1: USDI提案的投票门槛是否总是按提交时的CKB价格计算?
    • A: 是的。感谢你提出这个需要澄清的问题。为确保确定性,我们将在提案的 3.2.2 章节 增加如下说明:

      调整

      • 固定 USDI 数额: 提案申请固定数量的生态稳定币 USDI,并披露按申请时的CKB/USD汇率该提案的申请预算的等值CKB数量。

虽然 CKB 价格会波动,但我们认为在现阶段这是可以接受的。此外,提交时的价格最能代表社区在设定治理门槛时对提案价值的即时评估和共识。

  • Q2: 提案方是否仍能选择何时开始链上投票?
    • A: 是的。如提案所述 (3.3.2),30天审议期结束后,由提案人自主选择何时进入7天的投票阶段。这给予了提案方必要的灵活性,但他们也需自己承担延后投票可能带来的社区关注度下降等风险。

关于“元规则门槛”:

  • Q: 185M CKB的门槛是怎么来的?
    • A: 185M CKB的门槛是 DAO v1.0 的历史规则,旨在确保对DAO根本规则的修改能获得极高的社区共识。在 v1.1 提案中,我们选择尊重并沿用此规则。我们同意,这个门槛的合理性是一个非常值得在未来,在我们搭建好的 v1.1 这个新平台上,由整个社区专门讨论的议题。

再次感谢你们两位贡献了如此高质量的思考。你们的严格审视正在让这个提案变得更加完善。期待听到你们对这些修订方案的看法。

7 Likes