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

DAO v1.1 Web5 优化提案|社区审议月方案

为确保 DAO v1.1 Web5 优化提案能够在社区中获得充分讨论和理解,我们将把接下来的一个月设定为 社区审议月。期间我们除了持续收集和解答问题外,将组织2次AMA活动,帮助所有社区成员更好地把握提案内容、参与提问和表达意见。


1. 审议月目标

  • 充分沟通:让社区成员都能理解 DAO v1.1 提案的核心内容;收集反馈,完善提案。
  • 聚焦重点:第一场 AMA 集中解决核心问题,第二场 AMA 解决遗留问题 + 开放讨论。
  • 形成共识:为正式投票打下共识和透明基础。

2. 活动安排

:small_blue_diamond: 第一场 AMA(社区专场 · Google Meeting)| 中英双语(配交传)

  • 时间:第2周|9月25日(周四)09:00 UTC+8, 9月24日(周三)18:00 PDT

  • 平台:Google Meeting(社区内部) meet.google.com/rdj-ynpd-mse

  • 形式:逐题展开,“深度研讨会”(介绍 → 讨论 → 小结)

  • 目标:集中解决核心问题

  • 议程(约120分钟):

    1. 开场 &团队介绍/到场人员(5分钟)
    2. 概览提案当前状态(5分钟)
    3. 逐章节介绍提案重点,进行社区问答(100分钟)
    4. 总结 & 下一步说明(10分钟)

:small_blue_diamond: 第二场 AMA(公开场 · Twitter Space)| 中英双语(配交传)

  • 时间:第5周|暂定 10月中旬 |因中国国庆假期顺延一周

  • 平台:Twitter Space(完全公开)|中英双语(配同传)

  • 形式:集中讲解 → 集中讨论;“开放宣讲 + Q&A”

  • 目标:处理遗留问题,并通过开放讨论扩大共识圈层

  • 议程(约90分钟):

    1. 开场 & 提案回顾(5分钟)
    2. 最新进展 & Web5 平台(15分钟)
    3. 集中 Q&A:第一场 AMA 遗留问题(45分钟)
    4. 开放讨论(20分钟)
    5. 总结 & 投票动员(5分钟)

3. 讨论重点

  1. DAO Stewards 团队:中立性、职责边界、问责机制,组成方式
  2. 资金管理:两级金库设计 & 社区观察员机制,CKB/USDI/USD 三种方式利弊
  3. 治理流程:30天审议期 & 乐观/悲观投票模式
  4. 预算说明:100,000 USD 预算合理性
  5. 程序完整性:作为元规则修改提案,是否具备足够严谨性
  6. 其他话题

4. 时间线

  • 第1周

    • 发布《社区审议月方案》
    • 发布提案速览视频
    • 持续回应社区问题
    • 第一场 AMA 宣发
  • 第2周

    • 举办第一场 AMA(Google Meeting)
    • 发布 AMA 纪要 & 讨论总结
    • 持续回应社区问题
  • 第3周

    • 第二场 AMA 宣发
    • 持续回应社区问题
  • 第4周(中国国庆节)

    • 持续回应社区问题
  • 第5周

    • 举办第二场 AMA(Twitter Space)
    • 发布 AMA 纪要 & 总结
    • 持续回应社区问题
    • 发布正式投票前的最终总结

DAO v1.1 Web5 Optimization Proposal|Community Review Month Plan

To ensure the DAO v1.1 Web5 Optimization Proposal receives sufficient discussion and understanding within the community, we designate the coming month as Community Review Month. During this period, besides continuously collecting and answering questions, we will host two AMA sessions to help community members better grasp the proposal, raise questions, and share opinions.


1. Objectives of the Review Month

  • Full Communication: Ensure all community members understand the core content of the DAO v1.1 proposal; collect feedback and refine the proposal.
  • Focused Discussion: The first AMA will concentrate on core issues; the second AMA will address remaining questions and expand into open discussion.
  • Consensus Building: Lay the foundation of consensus and transparency ahead of the formal vote.

2. Event Schedule

:small_blue_diamond: First AMA (Community Session · Google Meeting | Bilingual with Interpretation)

  • Date & Time: Week 2|September 25 (Thu), 09:00 am UTC+8, September 24 (Wed), 18:00 pm PDT

  • Platform: Google Meeting (internal community session) meet.google.com/rdj-ynpd-mse

  • Format: Question-by-question “Deep Dive Workshop” (Presentation → Discussion → Recap)

  • Objective: Focused resolution of the proposal’s core issues

  • Agenda (Approx. 120 min):

    1. Opening & Team/Attendee Introductions (5 min)
    2. Overview of Proposal Status (5 min)
    3. Section-by-Section Highlights + Community Q&A (100 min)
    4. Wrap-up & Next Steps (10 min)


:small_blue_diamond: Second AMA (Public Session · Twitter Space )| Bilingual with Interpretation)

  • Date & Time: Week 5|Tentatively middle of October|Postponed one week due to China’s National Day holiday

  • Platform: Twitter Space (fully public)

  • Format: Concentrated presentation → Open discussion; “Public Briefing + Q&A”

  • Objective: Address unresolved questions and broaden the circle of consensus

  • Agenda (Approx. 90 min):

    1. Opening & Proposal Recap (5 min)
    2. Latest Updates & Web5 Platform Walkthrough (15 min)
    3. Focused Q&A: Unresolved Issues from AMA #1 (45 min)
    4. Open Discussion (20 min)
    5. Closing & Voting Mobilization (5 min)

3. Key Discussion Points

  • DAO Stewards Team: neutrality, scope of responsibilities, accountability mechanisms, formation method
  • Treasury Management: two-tier treasury design & community observer mechanism; pros and cons of CKB / USDI / USD denomination models
  • Governance Process: 30-day review period; optimistic/pessimistic voting models
  • Budget: justification of the 100,000 USD request
  • Procedural Integrity: does this Meta-Rule Change Proposal meet the highest standard of rigor?
  • Other Topics

4. Timeline

Week 1

  • Publish “Community Review Month Plan”
  • Release Proposal Overview Video
  • Ongoing responses to community questions
  • Promotion for AMA #1 (internal focus)

Week 2

  • Host AMA #1 (Google Meeting)
  • Publish AMA Notes & Discussion Summary
  • Ongoing responses to community questions

Week 3

  • Promotion for AMA #2 (external focus)
  • Ongoing responses to community questions

Week 4 (China National Day Holiday)

  • Ongoing responses to community questions

Week 5

  • Host AMA #2 (Twitter Space)
  • Publish AMA Notes & Summary
  • Ongoing responses to community questions
  • Release Final Summary before Formal Voting
3 Likes

This is an outstanding initiative. I had to read it twice to fully appreciate it. Genuinely excited about it; it’s exactly the bold, visionary effort Nervos needs to ensure long-term growth and sustainable impact. We see too often that DAOs and networks lose momentum when leaders stop pushing innovation, but here we see the opposite: a thoughtful, deliberate effort to strengthen foundations, identify gaps, and uplift the community. Massive props for the clarity of purpose, combined with well-thought-out planning, and massive respect to everyone involved. The positive effects of this work will be felt across the ecosystem for years to come.

6 Likes

Thank you so much for your incredibly supportive and motivating words. It’s heartening to see the vision resonate so clearly with you.

Now that we are in the one-month Community Review period, the best way you and all other community members can help us push this forward is by participating directly in the upcoming discussions.

We would be thrilled if you all could join our AMAs or continue to share any questions or thoughts you have right here in this thread!

Thanks again, and look forward to building this with you and the rest of the community!

2 Likes

Meeting Minutes 会议纪要: DAO V1.1 Proposal Community AMA 1

:spiral_calendar: Time:

Sep 24 (Wed) · 18:00–20:00 (PDT)
Sep 25 (Thu) · 09:00–11:00 (UTC+8)

:spiral_calendar: 时间:

9月25日(周四)09:00–11:00 (UTC+8)
9月24日(周三)18:00–20:00 (PDT)

Introduction 引言

We successfully hosted the first Community AMA for the DAO v1.1 Proposal as part of our one-month Community Review Month. This session was designed as an internal deep dive to discuss the core details of the proposal with our engaged community members.

We had nearly 20 participants join the call, and we were honored to have Matt and Jordan as special guests. Their presence and insightful questions greatly enriched the discussion. The AMA followed a section-by-section format, where the proposal team introduced each key component and then opened the floor for questions, ensuring a focused and in-depth conversation.

This document provides an anonymized summary of the key discussions and outcomes from the session.

我们成功举办了 DAO v1.1 提案社区审议月的第一场 AMA。本次会议定位为一次内部的“深度研讨会”,旨在与我们深度参与的社区成员共同探讨提案的核心细节。

我们有近20位参与者加入了会议,并非常荣幸地邀请到了 Matt 和 Jordan 作为特邀嘉宾。他们的出席和富有洞察力的问题,极大地丰富了我们的讨论。本次 AMA 采用了分章节介绍和问答的形式,由提案团队逐一介绍提案的关键组成部分,然后开放提问,以确保对话的焦点和深度。

本文档为本次会议关键讨论和成果的匿名化总结


Part 1: DAO Stewards 物业团队

Proposal Content Overview

  • DAO v1.1 proposes establishing DAO Stewards to address operational stagnation in DAO v1.0.

  • Stewards are a service team, not managers. They will hold no voting or decision-making power. Their role is to support governance processes so that community members can focus on actual decision-making.

  • Once the proposal is approved and funded, Stewards will operate as a completely independent entity, accountable only to the DAO, with no ongoing ties to Eco Fund (Eco Fund’s role is limited to early support).

  • The first Steward team will be publicly recruited from the CKB community. Members can self-nominate or be recommended. The first term will last 1 year, after which the team will transition to a community election.

Community Suggestions

  • Speaker A: Felt the role definition is clear, with no concerns.

  • Speaker B: Agreed, and emphasized that independence from Eco Fund is a positive factor for ensuring neutrality.

Summary
The community responded positively. DAO Stewards were recognized as a neutral, service-oriented team with no decision-making authority. The independence from Eco Fund and the plan for public recruitment and future elections were well received. No obvious opinions were raised in this session.

提案内容介绍

  • DAO v1.1 提案设立 DAO物业(Stewards),以解决 DAO v1.0 在执行层面缺乏专业支持团队的问题。

  • 物业是服务团队,而非管理者,不拥有任何投票或决策权,其职责是保障治理流程顺畅,帮助社区成员专注于决策。

  • 一旦提案获得批准和资助,物业团队将作为完全独立的实体运行,仅对 DAO 负责,与 Eco Fund 不再有从属关系(Eco Fund 仅在早期提供支持和孵化)。

  • 第一届物业团队将面向社区公开招募,允许自荐或推荐他人。首任期为 一年,之后转入社区化选举。

大家建议

  • 发言人A:认为物业角色的定义很清晰,没有问题。

  • 发言人B:同意,并强调 Eco Fund 不再管理物业团队是积极的一点,有助于保证独立性。

小结
社区整体反响积极。大家普遍认可 DAO物业作为中立、服务导向的团队,其独立性和未来的选举机制也获得支持。本环节未出现明显意见,显示社区在这一方向上已有较高共识。

Part 2: Treasury Management 金库管理

Proposal Content Overview

  • DAO v1.1 introduces a two-level treasury system to balance security and efficiency.

    1. Main Treasury: unchanged, holds the DAO’s overall funds.
    2. Project Execution Wallet: created for each funded project, managed by 2 DAO Stewards + 1 Community Observer (2/3 multisig).
  • To address CKB price volatility, three funding options are provided:

    1. Fixed CKB amount.
    2. Fixed USDI amount.
    3. Fixed USD value (paid in CKB; DAO tops up if price drops).

Community Suggestions

  • Speaker A: Questioned how teams receiving USDI could practically convert it into other assets.

  • Speaker B: Added that converting treasury CKB into USDI may currently require trusted individuals, since existing tools don’t support multi-sig swap.

  • Speaker A (follow-up): Suggested that if conversion is too complex, USDI might not be practical.

  • Speaker C: Considered this a technical/operational issue that the Steward team can handle once the proposal is approved.

Summary
The two-level treasury system was welcomed as an improvement for transparency and oversight. The flexibility of three funding options was valued, though practical challenges around USDI conversion and multi-sig swap support were highlighted. Consensus was that these are technical execution details to be resolved later by the Steward team with operational guidelines.

提案内容介绍

  • DAO v1.1 引入 两级金库体系,兼顾安全与效率:

    1. 主金库:保持不变,存放 DAO 总资金。
    2. 项目执行钱包:单独建立,由 2位物业成员 + 1位社区观察员 共同管理(2/3多签)。
  • 为应对 CKB 价格波动,提供三种计价方式:

    1. 固定 CKB 数额。
    2. 固定 USDI 数额。
    3. 固定 USD 价值(以 CKB 支付,下跌时 DAO 补足差额)。

大家建议

  • 发言人A:提出项目方在拿到 USDI 后,如何将其转化为其他资产,是否有明确的兑换路径?

  • 发言人B:补充,金库中的 CKB 转换成 USDI 的过程目前可能需要依赖个人操作,因为现有工具还不支持多签直接 swap,这涉及汇率与执行流程。

  • 发言人A(追问):认为若转换太复杂,USDI 选项可能不实用。

  • 发言人C:认为这些属于 执行层面的技术问题,应由物业团队在提案通过后制定操作指南来解决。

小结
社区普遍认可两级金库体系能够增强透明度和监督,三种计价方式增加了灵活性。但对 USDI 转换的可操作性 和 金库多签无法直接 swap 提出担忧。总体共识是:这些属于技术和执行层面的细节,应由 DAO物业团队在后续运行中制定明确流程来解决。

Part 3: Governance Process 治理流程

Proposal Content Overview

  • DAO v1.1 proposes significant changes to the governance process:

    • Proposal stage: Replace the current “7 days + 30 likes” with a 30-day community review period, ensuring sufficient discussion time. DAO Stewards will facilitate AMA sessions, weekly summaries, and information flow.

    • Voting stage: Core thresholds and voting weights remain unchanged, preserving existing democratic rights.

    • Execution & oversight stage: Introduces optimistic voting for milestone funding (default pass unless vetoed) to improve efficiency and reduce voting fatigue. If a milestone is rejected, a crisis management stage applies, using pessimistic governance (default fail, project must regain trust).

  • Overall, the new process aims to strike a better balance between efficiency and oversight.

Community Suggestions

  • Speaker A: Asked if the requirement of “two public Q&A sessions” is mandatory per project.

  • Speaker B (Proposal team response): Confirmed it is mandatory, regardless of project size, to ensure visibility and information flow. Each project must have at least two AMA/Q&A sessions during the 30-day review.

  • Speaker A (follow-up): Raised concerns about multiple projects being bundled in one AMA session (e.g., 5 projects at once). Response: The Steward team will manage this via operational guidelines. If many projects arise, sessions can be split, but each project will still receive two opportunities.

  • Speaker C: Asked if small proposals (e.g., $5,000) must also undergo the same process. Response: Yes, because the purpose is not only funding oversight but also ensuring awareness and community engagement.

  • Speakers A & C (conclusion): Accepted the explanation, recognizing the value of consistent Q&A sessions even for small proposals.

Summary
The governance process redesign was seen as one of the most important improvements in DAO v1.1. The community agreed that longer review, mandatory Q&A sessions, and milestone oversight mechanisms will improve transparency and engagement. Concerns about practicality (session length, small projects) were acknowledged, but consensus formed that these processes are necessary for solving DAO v1.0’s issue of fragmented information flow.

提案内容介绍

  • DAO v1.1 对治理流程提出了较大调整:

    • 提案阶段:将现有的“7天+30赞”升级为 30天的社区审议期,确保充分讨论。物业团队在此期间负责组织 AMA、每周总结和信息流转。

    • 投票阶段:核心门槛和投票权重保持不变,保障社区成员的民主权利。

    • 执行监督阶段:引入 里程碑拨款的乐观投票机制(默认通过,社区有否决权),提高效率并减少投票疲劳。若里程碑被否决,则进入 危机处理流程,采用悲观治理模式(默认失败,项目方需主动赢回信任)。

  • 整体目标是让治理在 效率与监督 之间找到更好的平衡。

大家建议

  • 发言人A:问到“每个项目是否必须进行两次公开 Q&A?”

  • 发言人B(提案团队回应):确认是必须的,无论项目大小,每个提案在30天审议期内至少有两次 AMA/Q&A,保证透明度和信息对称。

  • 发言人A(追问):担心多个项目集中在一场 AMA,是否会过长?回应:物业团队将通过操作指南细化,如果项目数量多,可以拆分场次,但仍保证每个项目有两次机会。

  • 发言人C:问小额提案(如5,000美金)是否也必须走此流程?回应:是的,因为流程不仅是资金监督,更是确保社区知情和参与。

  • 发言人A & C(结论):理解并接受,认为统一要求有助于信息流动和社区活跃。

小结
治理流程的调整被认为是 DAO v1.1 的重要升级。社区成员普遍认同更长的审议期、强制 Q&A 以及里程碑监督能有效提升透明度和参与度。尽管对操作性(如会议时长、小额项目适用性)有顾虑,但形成了共识:这些流程对解决 DAO v1.0 的信息割裂问题是必要的。

Part 4: Web5 Governance Platform Web5 治理平台

Proposal Content Overview

  • The Web5 governance platform is proposed as a another core deliverable of DAO v1.1 to fix the fragmentation of information and actions in DAO v1.0 (discussion on Talk, voting on Metaforo, staking on Nervos DAO/Neuron Store, etc.).

  • Goals: unify proposal discussion, voting, staking, milestones, and reporting into one coherent workflow to raise participation and transparency.

  • Technical & philosophy highlights:

    • User-sovereign identity (DID): Users log in with external Web5 DIDs; identity is owned by the user, not by the platform.

    • Data portability & choice: Users can store data in a default PDS (Personal Data Store) or their own server; data can be migrated across apps.

    • Verifiable voting data: Unlike centralized databases, DAO v1.1 aims for transparent weight attribution and verifiability, addressing issues like “double-spend” of voting power observed in current tools.

  • DID on-chain storage: current design uses Web5 DID stored on CKB (roughly “~300 CKB state occupancy” per DID depending on content), functioning more like a refundable state rent / occupancy, not a fee.

Community Suggestions

  • Speaker A: Asked about costs for DID creation (fees/state rent) and whether DID is required only for voting or also for discussion.

    • Response: DID is the identity layer and is required for platform participation (discussion + voting). Voting power still derives from Nervos DAO staking; DID binds identity to voting weight.
  • Speaker B: Concerned that ~300 CKB occupancy could become expensive if CKB appreciates, potentially discouraging participation.

    • Response:

      • It’s state occupancy, not a burned fee; CKB can be reclaimed (like an NFT deposit).

      • Classed Web5 application approach: high-trust, governance-critical “Class A” apps (e.g., DAO forum) use on-chain DID; mass-adoption apps (“Class B/C”) can use off-chain DID (e.g., DID:PLC-style) with no CKB occupancy.

      • As usage scales, expect Layer-2 / protocol upgrades / format optimizations to reduce costs; guidelines will evolve.

  • Speaker C: Emphasized that Web5 = Web3 (values) + Web2 (mature dev stack): decentralized identity & data control with practical developer ergonomics.

  • Speaker D: Noted that if millions adopt DID, on-chain storage for every DID may be unsustainable—anticipate L2 / hybrid models.

    • Response: Team agrees on a dual-track strategy (on-chain for A-class governance; off-chain for broader apps) and expects future cost optimizations.

Summary
The community agrees the Web5 governance platform directly targets DAO v1.0’s fragmentation by consolidating workflows and restoring data/identity sovereignty. The on-chain DID cost sparked constructive debate; consensus formed around a tiered identity model (on-chain for governance; off-chain for mass use) plus future technical optimizations (L2/format tweaks) to balance decentralization with scalability and cost.

提案内容介绍

  • Web5 治理平台是 DAO v1.1 的另一项核心交付物,目的在于解决 DAO v1.0 信息与行动割裂(Talk 讨论、Metaforo 投票、Nervos DAO/Neuron Store 质押分别在不同平台)导致的参与度下降问题。

  • 目标:将讨论—投票—质押—里程碑—报告串为一个统一流程,提升透明度与参与度。

  • 技术与理念要点:

    • 用户主权身份(DID):使用 Web5 DID 登录,身份归用户所有而非平台。
    • 数据可携带与选择:可存于默认 PDS 或自有服务器,数据在不同应用间可迁移。
    • 可验证的投票数据:相较中心化库,DAO v1.1 强调权重透明与可验证,针对现有工具存在的投票权重“双花”问题给出设计回应。
  • DID 上链:当前采用 存储于 CKB 的 Web5 DID(约“占用 ~300 CKB 状态”,随内容而变),更接近可退还的占用/质押,非一次性销毁费用。

大家建议

  • 发言人A:询问 DID 创建是否有费用/占用成本,以及 DID 是否仅用于投票还是讨论也需要。

    • 回应:DID 是身份层,用于讨论与投票;投票权仍来源于 Nervos DAO 质押,DID 用于把身份与权重绑定。
  • 发言人B:担心若 CKB 大幅升值,~300 CKB 占用会提高门槛、影响参与。

    • 回应:

      • 这是状态占用,非消耗性费用;可类似 NFT 存证那样赎回。

      • 采用分类的Web5应用策略:治理关键的 A 类应用(DAO 论坛等)用链上 DID;面向大众的 B/C 类应用可用链下 DID(如 DID:PLC 类),不占用 CKB。

      • 随规模发展,将通过 L2 / 协议升级 / 数据格式优化降低成本;细则将随运维指南演进。

  • 发言人C:强调 Web5 = Web3(价值)+ Web2(工程):在保障去中心化与隐私的同时,使用成熟的 Web2 技术栈落地。

  • 发言人D:指出若 DID 面向数百万用户,全部上链不具可持续性,应预期 L2/混合模式。

    • 回应:团队认同双轨身份策略(治理上链/大众链下)并将推进成本优化路径。

小结
社区整体认可:Web5 治理平台通过统一治理工作流、还权于用户(身份与数据)来直击 v1.0 的痛点。关于链上 DID 成本的讨论富有建设性,形成以分层身份模型(治理用链上、普适用链下)+ 未来技术优化(L2/格式升级)达成平衡的共识方向。

Part 5: Budget & Milestones 预算与里程碑

Proposal Content Overview

  • Milestones (4 total)

    • The proposal is structured into four milestones.

    • Team is already building at own risk during the review month: frontend is nearly complete; voting smart contract for the governance platform has been deployed to testnet.

    • MVP target: by end of October. If the proposal passes in mid-October, delivery will seamlessly proceed into subsequent milestones.

  • Budget: USD 100,000 equivalent in CKB

    • USD 72,000 → platform development
    • USD 18,000 → Year-1 operations of the first Steward (物业) team
    • Detailed breakdown is provided in the proposal’s budget table.
  • Open recruitment: If approved, the first Steward team will be publicly recruited from the community (self-nomination & recommendations welcome).

Community Suggestions

  • Speaker A: “Seems OK.” No objections to the budget split or milestone schedule.

  • Speaker B (general comment in open-mic): Recognizes v1.1 as a step forward to overcome stagnation; while different governance variants may exist elsewhere, supports voting in favor of this proposal.

Summary
The community expressed no material objections to the USD 100k budget or the 4-milestone plan. The team’s testnet progress and near-term MVP increased confidence. There is broad support to move ahead, with the understanding that alternative governance experiments can continue in parallel.

提案内容介绍

  • 里程碑(共4个)

    • 提案按 4个里程碑组织。

    • 团队已在审议期内自担风险推进:前端即将完成;治理平台的投票合约已部署到测试网。

    • MVP 目标:10月底完成;若 10月中旬投票通过,交付将无缝进入后续里程碑。

  • 预算:10万美元(等值 CKB)

    • 7.2 万美元 → 平台开发
    • 1.8 万美元 → 第一届物业团队一年运营
    • 细分项见提案内预算表。
  • 公开招募:若通过,第一届物业团队将面向社区公开招募(支持自荐与推荐)。

大家建议

  • 发言人A:认为“可以”,对预算结构与里程碑安排无异议。

  • 发言人B(开放麦总体意见):认可 v1.1 能推动治理走出停滞;尽管社区也在探索其他治理版本,但将投赞成票支持本提案向前推进。

小结
对 10万美元总额与 四大里程碑未见实质异议。团队已完成的测试网进展与MVP 时间表增强了社区信心。总体倾向:支持推进 v1.1,同时允许其他治理方案并行探索、相互借鉴。


Conclusion & Next Steps 总结与下一步

This first AMA was incredibly productive and helped build a stronger shared understanding of the proposal. We want to thank everyone who participated.

The Community Review Month will continue. We encourage everyone to keep the discussion going on the Nervos Talk thread.

Our second, fully public AMA will be a Twitter Space held in mid-October. We will announce the exact date and time soon. Please stay tuned, and let’s continue to build a better DAO together!

第一次 AMA 的讨论富有成效,帮助我们建立了对提案更坚实的共同理解。我们想再次感谢所有参与者。

社区审议月将继续进行。我们鼓励大家在Nervos Talk 的提案帖中继续讨论。

我们的第二场、完全公开的 AMA 将是在10月中旬举办的 Twitter Space。我们将很快公布确切的日期和时间。请大家保持关注,让我们一起建设一个更好的 DAO!

6 Likes

Update (Oct 15)

Hello everyone,

As we continue our Community Review Month, the proposal team has been closely following the discussions here on Talk and the fantastic feedback from our first AMA.

Your engagement is already making this proposal stronger. Based directly on your input, we have just pushed an update. This is your feedback in action!

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.

We encourage everyone to review these changes and continue sharing your thoughts. We’re now in the final stretch of the review period, with our second public AMA coming up soon. Let’s get this finalized together!

更新(10月15日)

大家好,

随着我们社区审议月的继续,提案团队一直在密切关注 Talk 上的讨论以及第一次 AMA 中极具价值的反馈。

你们的参与正在让这个提案变得更强大。基于大家的意见,我们刚刚发布了一次提案更新。这是社区反馈在行动的直接体现!

更新日志 (2025年10月15日):

  • 新增: 在 3.3.2 提案生命周期 中增加了“里程碑截止日期与项目停滞”条款。基于 @knmo 及社区的反馈,此条款授权 DAO 物业在项目停滞时启动监督,以堵上一个潜在的治理漏洞:
    提案中的每个里程碑都必须有一个公开的、预估的交付截止日期。如果项目团队在超出其声明的截止日期 30 天后,仍未交付里程碑,DAO 物业团队有权启动下述的“项目复核、最终裁决与终止(危机处理)”流程。
  • 新增: 在 3.1.4 团队产生与轮换 中增加了物业团队需编写并维护“运营手册”的要求。基于 AMA#1 的反馈,这将把高阶的元规则与日常操作程序分离开来,提升透明度与适应性。
    首届物业团队成立后,其核心职责之一是组织编写并发布第一版《DAO物业运营手册》。该手册将详细阐述执行治理规则所需的日常操作程序。此后每年换届时,由新一届团队负责对该手册进行修订和更新,以反映实践经验并适应社区需求。”
  • 移除: 移除了“固定USD价值 (以CKB支付)”的资金选项 (3.2.2节)。基于 AMA#1 关于其运营复杂性的反馈,我们简化了资金政策,专注于更直接的“固定CKB数额”和“固定USDI数额”两个选项。

我们鼓励所有人审阅这些变更,并继续分享你的想法。现在我们已进入审议月的后半段,第二次公开 AMA 也即将到来。让我们一起完成最后的打磨!

4 Likes

Hi everyone, I don’t use voice or video channels, also I’m not on social media. I’m much more at ease writing, so I’ll keep responding here as usual :flexed_biceps:

Challenge to Milestone Deadline & Project Stalls

I agree that points 2 and 3 look reasonable, but I want to push back on point 1:

I don’t know, but in my eyes milestone deadlines just create artificial pressure that encourages rushing, cutting corners, and deferring important work. Not the best match for our industry. Also, when a milestone is missed, teams can stall, waiting for decisions or approvals, which creates bottlenecks and lost momentum.

So my question are:

  1. How deadlines benefit the broader ecosystem?
  2. What Being Empowered means with a couple of concrete examples?
  3. How much decision-making authority will stewards actually have?
  4. What data or evidence led to choosing a 30-day deadline?
  5. Why was 30 days chosen instead of 60, 120, or 240 days?
  6. What are the risks or downsides of waiting even a full year to see whether the project can deliver?

A Couple Questions on Voting

  1. Will the CKB price at submission time (30+7 days before funds release) always be used to weight CKB votes for USDi proposals?
  2. Can the presenting team still choose when the on-chain vote begins, or must it start automatically at the end of the 30-day period?

Re-Evaluate Meta Rule Vote Rules

How was the 185M CKB threshold originally chosen as the quorum for a meta-rule vote, and does that rationale still apply today?

Love & Peace, Phroi %118

4 Likes

Good points and we definitely need to understand that there’s lots of legit reasons for delays and missed milestones and I’m sure anyone who we put in as Stewards will have enough experience in the industry to know this.

Project Full Review, Final Ruling, and Termination” probably sounds more harsh than the process actually is, I’m assuming there will be a lot of common sense involved and if the team can explain the reasons for the delay, then the Stewards will not only understand, but try and help if they can.

But I think there still needs to be a pretty strict approach to the milestones, just so the Stewards have the option to take action if they need to in certain cases.

2 Likes

@Yeti this rule has been presented as:

Stalled Project Clause: Added a rule to handle projects that go silent

Which which is more than reasonable, yet the rule is unreasonably broad:

  1. Almost all projects, for ex. Fiber, frequently miss milestones, often by a wide margin.
  2. By placing virtually all projects under this clause, we’re subjecting all teams to arbitrary judgment.
  3. Delaying funding puts projects at risk of bankruptcy, especially when the underlying issues are typically beyond their control.

Contradiction with “No Interpretive Power”

Yet the added clause seems to contradict this principle:

  • Judgment Calls: Enforcing deadlines requires evaluating delays, which involves interpretation. Possibly leading to team bankruptcies.
  • Rigid Enforcement Risks: Strict application could unfairly punish reasonable delays.
  • De Facto Discretion: If Stewards need to exercise discretion, they gain power that’s not sanctioned.

@zz_tovarishch can we explore better alternatives for addressing projects that go silent?

Phroi %63

4 Likes

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

Hey @zz_tovarishch, this change would address most of my concerns, thank you so much :folded_hands:

I still have some reservations about using a 30-day delay as the review trigger because it’s easy to hit in common scenarios. For longer projects with many milestones, small delays of a week or two per milestone can add up quickly and we could easily reach the 30-day threshold.

That said, since teams set these timelines up front, they can estimate how long a task typically takes and multiply that by 2-3 when choosing the milestone deadlines. That gives a buffer for unforeseen obstacles and normal variance.

In light of these considerations, do you think any other changes to the proposal are needed?

Love & Peace, Phroi %73

3 Likes

Hi Phroi,

Thank you for the thoughtful follow-up. It’s fantastic to hear that the revised process addresses most of your concerns.

You’ve raised an excellent point about the 30-day trigger. Your analysis that teams should build in their own buffers is spot on, and it clarifies a key distinction:

It is the Proposer’s responsibility to set realistic deadlines.

The Steward’s role is not to judge the plan, but to act as a part of the backstop, executing the automated process if a deadline is missed. They are the executors of the rule, not the interpreters of the plan.

Whether the initial milestones or a revised plan with new deadlines is reasonable is ultimately up to the community to decide via a vote.

That said, your core question remains valid: is a fixed 30-day trigger the best possible mechanism? I’d like to open that question to you and the entire community.

Does anyone have any suggestions to improve this clause, or any other part of the proposal?

We are committed to making this proposal as strong as possible before the final vote, and all constructive feedback is welcome.

Hi Phroi,

感谢你的跟进。听到这些修订解决了你的大部分担忧,我们感到非常振奋。

你针对“30天触发机制”提出了一个非常棒的观点。你分析的“团队应该自己留出缓冲时间”完全说到了点上,这也厘清了一个关键的区别:

设定可行的截止日期,是提案方的责任。

物业的角色不是去判断计划是否合理,而是作为制度底线的一部分,在截止日期错过后,去执行自动化的流程。他们是规则的执行者,而不是计划的诠释者。

至于项目方最初的milestone以及调整后的新计划是否合理,这依然是交给社区来投票决定的事情。

尽管如此,你的核心问题依然有效:一个固定的30天触发器是最好的机制吗?我想把这个问题开放给你和整个社区。

大家对于完善这个条款,或者对提案的任何其他部分,是否还有更好的建议?

我们致力于在最终投票前,将这个提案打磨得尽可能完善,欢迎所有建设性的反馈。

4 Likes

I believe the 30 day is sufficient– though the potential for delays to stack up and lead to more major set backs is understandable.. As @phroi mentioned the initial timelines can be set up with intended buffers. With that being said, The primary intention of the 30 day trigger would be to re-visit and potentially halt funding to projects due to mis-management or at least falling well outside its original scope. Wherein with the help of stewards, the community can reassess the project and decide how to proceed forward. An important point– Its within the best interest of the community and the stewards to see the projects brought to fruition, assuming the delays are reasonable, its fair to expect the community to act amicable towards the project regardless of the time frame. So phroi can rest at ease well he cooks (: the reality is though we all love when things go smoothly, sometimes things happen, and in those times there is a need for exceptions!

4 Likes

Update and AMA#2 (Oct 18)

Hello everyone,

The debate over the last few days has been a fantastic example of our community governance at its best. Based directly on your input, we have just pushed another significant update.

This is your feedback in action (thanks, @phroi @Yeti @NightLantern and @knmo)! Key changes include:

A new, automated process for handling project delays.

A clarification on how voting thresholds are calculated for USDI proposals.

Please see the latest changelog at the top of the main proposal post for details. We encourage everyone to review these changes and continue sharing your thoughts.

Moreover, we will have the AMA #2 Oct 20 — 8 AM PDT / 5 PM CEST / 11 PM UTC+8
https://x.com/i/spaces/1yoKMPLDEepxQ

更新及AMA#2 (10月18日)

大家好,

过去几天的辩论是我们社区治理发挥其最佳作用的绝佳范例。基于大家的意见,我们刚刚发布了又一次重要的提案更新。

这是社区反馈在行动的直接体现(thanks, @phroi @Yeti @NightLantern and @knmo)!核心变更包括:

  • 一个全新的、用于处理项目延期的自动化流程。
  • 关于如何为 USDI 提案计算投票门槛的明确说明。

详情请见主提案帖子上方的最新更新日志。我们鼓励所有人审阅这些变更,并继续分享你的想法。

此外,我们将于 10 月 20 日上午 8 点(太平洋夏令时间)/下午 5 点(欧洲中部夏令时间)/晚上 11 点(UTC+8)举办 AMA #2

https://x.com/i/spaces/1yoKMPLDEepxQ

4 Likes

AMA#2 Oct 20

:microphone: DAO v1.1 Web5 Optimization Proposal | AMA #2 :speech_balloon:

:alarm_clock: Starting soon — Oct 20
:eight_o_clock: 8 AM PDT / 5 PM CEST / 11 PM UTC+8
:link: https://x.com/i/spaces/1yoKMPLDEepxQ
(EN↔️CN interpretation)

Recap & open discussion to build stronger community consensus.
:handshake: Welcome & look forward to seeing you all !


:microphone: DAO v1.1 Web5 Optimization Proposal | AMA #2​:speech_balloon:

:spiral_calendar: 北京时间 今晚11点
10月20日|08:00 PDT / 17:00 CEST / 23:00 UTC+8
:link: https://x.com/i/spaces/1yoKMPLDEepxQ
(中英交传)

一起回顾讨论,共建更有共识的社区 :globe_with_meridians:
:handshake: 欢迎大家来聊聊、提问、发声!

4 Likes

Meeting Minutes DAO V1.1 AMA 2

:link: https://x.com/i/spaces/1yoKMPLDEepxQ (EN↔️CN interpretation) 150 minutes

This document provides an anonymized summary of the key discussions and outcomes from the session.

本文档为本次会议关键讨论和成果的匿名化总结。

Outline 大纲


Part 0 Opening Session 开场介绍部分

The AMA focuses on open discussion and Q&A around the proposal’s core modules — DAO Steward, Treasury Management, Governance Process, and the Web5 Governance Platform.

Proposal Team Updates:
DAO v1.1 was first released in early September and has since undergone three key revisions based on community feedback:

  • September 10: Added USDI and Fixed USD Value Payment options.

  • October 15: Introduced Milestone Deadlines and Project Stagnation Clauses, and required the DAO Steward team to create an Operations Manual.

  • October 18: Improved Milestone Stagnation Handling to prevent over-concentration of power within the DAO Steward team, and added a clause requiring explicit disclosure of CKB value in USDI payments.

The proposal is currently in the Community Review Month phase and will proceed to the voting stage after the review period concludes.

本次为 DAO v1.1 优化提案的第二场社区 AMA,在 Twitter Space 举办。AMA2 旨在围绕提案核心模块(DAO 物业、金库管理、治理流程、Web5 平台等)进行公开交流与问答。

提案团队说明:DAO v1.1 于 9 月初发布,并在社区反馈基础上进行了三次关键更新:

  1. 9月10日:引入 USDI 与 固定美元价值支付 选项;

  2. 10月15日:增加里程碑截止与项目停滞条款,并要求物业团队编制运营手册;

  3. 10月18日:优化里程碑停滞处理机制,防止物业团队权力过度集中,并新增 USDI 支付披露 CKB 价值条款。

当前提案正处于 社区审议月 阶段,将在审议期结束后进入投票流程。

Part 1 DAO Stewards DAO物业

:puzzle_piece: Proposal Key Points

  • Objective: The DAO v1.1 proposal aims to resolve the operational stagnation seen in DAO v1.0, mainly caused by the absence of a professional, service-oriented team to handle administrative and procedural matters.

  • DAO Stewards are positioned as a service-oriented team, not a management body.

    • They have no voting or decision-making power and exist solely to support the community and improve process efficiency.
    • Once approved and funded, the DAO Stewards will operate as an independent entity, accountable only to the DAO, with no subordination to the EcoFund.
    • The first Steward team will be publicly recruited from the community, welcoming self-nominations and referrals. The initial term will be one year, followed by community elections.

:speech_balloon: Community Questions & Team Responses

Speaker 3 (Community Guest)
Why choose UTXO Global instead of Neuron for the multi-signature wallet? Since the goal is to enhance security, Neuron seems to be a more mature and safer option.

Team Response (Speaker 1 & Speaker 5)

  • The proposal uses UTXO Global for DAO Stewards’ multi-signature operations for the following reasons:

    1. Audit and stability – UTXO Global has undergone multiple audits and offers a mature product.
    2. Functional fit – The wallet aligns well with the execution wallet requirements described in the proposal.
    3. User experience – The team has tested it in Spark projects and found it more user-friendly than Neuron.
  • The team acknowledges security must take priority. While Neuron is a cold (desktop) wallet, UTXO Global is browser-based (hot wallet), which carries inherent risks.

  • The technical leads (Speaker 5 and Speaker 6) will evaluate security-focused alternatives in the next development phase.


Speaker 4 (Community Member)
Does this mean DAO members will need to move their tokens from Neuron to UTXO Global to participate?

Team Response (Speaker 1 & Speaker 5)

  • No asset transfer is required for regular DAO members.
    • The main treasury remains in Neuron.
    • UTXO Global is used only for execution wallets under project-level management by DAO Stewards.
    • Individual staking and voting remain unaffected.
  • If Neuron introduces built-in multi-signature support in the future, the team is open to migration or dual support.

Speaker 5 (Technical Lead, Supplementary Explanation)

  • Currently, Neuron lacks an accessible interface for creating and managing multi-signature wallets, while UTXO Global provides a visual, user-friendly experience.

  • Because DAO Stewards may not be developers, CLI-based tools would be impractical; thus, UTXO Global represents a balance between usability and security at this stage.

  • In future iterations, once safer and more intuitive multi-signature tools emerge within the CKB ecosystem, the team will prioritize migration to them.

:puzzle_piece: 提案要点说明

  • 核心目标: DAO v1.1 提案旨在解决 DAO 1.0 在操作层面的停滞问题,主要原因是缺乏专业化的服务团队来处理事务性与程序性事务。

  • DAO 物业(DAO Stewards) 被定位为一个服务型团队,而非管理层:

    • 无投票或决策权,仅负责执行事务、协助治理流程。
    • 提案通过并获得资助后,物业团队将成为独立实体,仅对 DAO 负责,不再隶属于 EcoFund。
    • 首届物业团队将面向社区公开招募,欢迎自荐与推荐,任期一年,之后由社区选举产生。

:speech_balloon: 社区提问与提案团队答复

发言人3(社区嘉宾)
为什么选择 UTXO Global 而不是 Neuron 作为多签钱包?考虑到资金安全,Neuron 看起来是更成熟、安全的选项。

提案团队答复:

  • 团队选择 UTXO Global 的原因如下:

    1. 稳定性与审计:该钱包已完成多轮安全审计,功能稳定。
    2. 功能适配:更符合提案中“多签执行钱包”的使用场景。
    3. 用户体验:在 Spark 项目中实际测试后,操作体验更佳。
  • 团队认同 安全性优先 的观点。Neuron 为冷钱包,UTXO Global 属于浏览器热钱包,存在潜在风险。

  • 团队后续由技术负责人(发言人5、发言人6)重新评估安全优先的替代方案。


发言人4(社区成员)
这是否意味着 DAO 成员需要将资产从 Neuron 转移到 UTXO Global 才能参与?

提案团队答复:

  • 普通成员无需迁移资产。

    • 主金库仍由 Neuron 管理。
    • UTXO Global 仅用于项目层面的 执行钱包,由 DAO 物业团队多签管理。
    • 个人质押与投票不受影响。
  • 若未来 Neuron 增加多签功能,团队将考虑迁移或并行支持。


发言人5(技术负责人补充)

  • Neuron 目前缺乏便捷的多签创建与签名界面,而 UTXO Global 拥有更直观的可视化体验。
  • 由于物业团队成员可能非开发者,命令行工具门槛过高,因此当前选型在安全性与易用性间取得平衡。
  • 未来若 CKB 生态出现更安全友好的多签方案,团队将优先迁移。

Part 2 Treasury Management 金库管理部分

:puzzle_piece: Proposal Key Points

  • The Treasury Management section of DAO v1.1 aims to balance security and operational efficiency.

  • A two-tier treasury system is proposed:

    1. The main treasury remains unchanged.
    2. Each approved project will have its own independent execution wallet, co-managed by two DAO Steward members and one community observer, ensuring that every milestone disbursement is transparent and supervised.
  • To address uncertainty caused by CKB price fluctuations, the proposal introduces two flexible funding models:

    1. Fixed CKB amount — for teams with long-term confidence in CKB.
    2. Fixed USDI amount — for teams requiring a stable budget and predictable funding.

:speech_balloon: Community Questions & Team Responses

  • No specific questions were raised by community members during this section.
  • The community acknowledged the two-tier treasury model and the dual pricing options as reasonable mechanisms to improve transparency and risk management.

:puzzle_piece: 提案要点说明

  • DAO v1.1 的 金库管理方案 旨在兼顾 资金安全与执行效率。

  • 提出 两级金库体系:

    1. 主金库 保持不变;
    2. 每个立项项目将拥有独立的 项目执行钱包,由 两位物业团队成员 与 一位社区观察员 共同管理,确保每笔里程碑拨款都有监督、有记录。
  • 为应对 CKB 价格波动带来的不确定性,提供两种灵活的资金计价方式:

    1. 固定 CKB 金额(适合长期看好 CKB 的团队);
    2. 固定 USDI 金额(适合追求预算稳定的团队)。

:speech_balloon: 社区提问与团队答复

  • 本环节社区成员暂无具体提问。
  • 社区整体认可 两级金库体系 与 双计价方式 的设计思路,认为有助于提升透明度与资金安全性。

Part 3 Governance Process

:puzzle_piece: Proposal Key Points 提案要点说明

  • Replace “7 days + 30 likes” with a 30-day Community Review to ensure sufficient discussion and visibility.

  • During the 30 days, DAO Stewards organize two AMAs, compile summaries/reports, and keep information flowing across channels.

  • Voting thresholds/weight formulas remain the same as v1.0.

  • Execution & Oversight: adopt optimistic milestone voting (default pass with veto) to reduce voting fatigue; if a milestone is vetoed or no delivery after 30 days, enter a pessimistic/crisis track (default fail; project must regain trust with Steward reports).

:speech_balloon: Community Questions & Team Responses

Speaker A
Moving from “7 days + 30 likes” to 30 days at the start seems like a big slowdown. In v1.0, some proposals effectively finished in ~2 weeks (likes in a week, vote in a week). Won’t this reduce momentum and make the process less attractive for projects?

Team (Speaker 1)

  • The 30 days address recurring feedback that past proposals lacked visibility and many members saw them too late. In this AMA cycle, meaningful questions kept emerging in weeks 3–4.

  • The aim is to raise participation and quality, not to slow things down.

  • For small/urgent requests, the ecosystem already has small-grant routes (e.g., Spark/Catalyst) for faster decisions; Community DAO handles larger, higher-impact grants that merit broader review.


Speaker B
Is 30 days fixed? In v1.0, 1 week was a minimum before moving to Stage 2. Can we keep a shortest-time concept (e.g., <30 days) if there’s clear support?

Team (Speaker 6 + Speaker 1)

  • v1.0’s “1 week” was designed as a minimum, not a hard timer; proposers could wait longer before Stage 2.
  • In v1.1, the team’s current design treats “30 days” as the baseline period to ensure outreach and discussion.
  • The team acknowledges concerns and is open to exploring adjustments (e.g., a 21-day baseline) but wants to avoid encouraging rushed decisions.

Speaker C
Could we add a fast-track when there’s clear community support, similar to the old “30 likes” signal?

Team (Speaker 1)

  • The “likes” gate blurred roles and looked like a pre-vote by non-governance signals; it confused accountability between process rules and data/governance rules.
  • The team does not plan to re-introduce a “likes-based” trigger.
  • However, the Stewards’ two AMAs + reports can serve as momentum builders and public visibility for strong proposals within the review month.

Speaker D
As proposal volume grows, one month may be acceptable as a default, but there should be some contingency to move faster.

Team

  • Noted. The team will re-evaluate timeline designs (e.g., shortest time vs. fixed baseline, and objective fast-track criteria) and return with refined guidance in the operational handbook.

:puzzle_piece: Proposal Key Points 提案要点说明

  • 将“7天+30赞”改为 30天社区审议期,确保讨论时间与可见度。
  • 审议期内由物业团队组织两场 AMA、输出阶段性报告,并在各渠道持续同步信息。
  • 投票门槛与权重算法沿用 v1.0。
  • 执行监督:里程碑采用乐观投票(默认通过,可否决)以降低投票疲劳;若被否决或30天未交付,进入悲观/危机流程(默认失败,项目方需主动赢回信任并附物业报告)。

:speech_balloon: 社区成员问题 & 提案团队答复

发言人 A
从“7天 + 30个赞”改成30天的社区审议期,这个改动会不会让整个流程太慢?
以前在 v1.0 里,一些提案基本上两周就能完成(第一周拿到30个赞,第二周进入投票)。
现在要等整整一个月,会不会降低项目方的积极性、影响节奏?

提案团队(发言人1)答复:

  • 设置 30天 的主要原因,是为了解决过去 DAO 提案中反复出现的一个问题:
    很多成员在提案结束后才看到或理解内容,信息触达严重不足。

  • 在这次 AMA 的实际过程中,很多有价值的讨论都是在第三、第四周才出现的。

  • 目的不是拖慢,而是让讨论更充分、更高质量。

  • 对于小额或紧急项目,生态中已有 Spark、Catalyst 等快速资助渠道;
    Community DAO 处理的是金额更大、影响更广的提案,应该经过更严谨的讨论周期。


发言人 B
这 30 天是不是固定时间?
在 v1.0 里,“1 周”只是最短时间,不是强制要求。
能否保留这种“最短时长”的机制,比如某些提案讨论充分时,不到 30 天就能进入投票阶段?

提案团队(发言人6 与 发言人1)答复:

  • 在 v1.0 的设计中,“1 周”确实只是最短时间,提案方可以选择延长讨论。
  • 在 v1.1 中,当前设定的 “30 天” 也是一个基础周期,用于确保信息传播与充分讨论。
  • 团队理解大家对效率的关注,会考虑优化方案(例如将基线调整为 21 天),
    但不希望因此导致“草率推进、讨论不足”的情况出现。

发言人 C
能否增加一种快速通道(fast-track)机制?
比如当社区支持度很高时,像以前“30个赞”那样,就可以提前进入下一阶段。

提案团队(发言人1)答复:

  • “点赞门槛”在 v1.0 中其实存在角色混淆问题。
    它让非投票成员的表达与治理权重混为一谈,
    容易造成“类预投票机制”的误解。

  • 因此,v1.1 提案不打算重新启用点赞机制。

  • 不过,提案在 一个月内举办的两场 AMA + 阶段报告,
    也能起到类似的“社区热度与传播”作用,
    对优质项目而言,这本身就是一次额外的曝光与动能积累。


发言人 D
如果未来提案数量增加,一个月的默认周期也许没问题。
但是否可以考虑一种应急或加速机制,
让特定情况的提案能更快推进?

提案团队答复:

  • 团队已记录该建议。

  • 后续将在**物业团队的操作手册(Operational Handbook)**中,
    进一步研究并明确:

    • “最短时间” vs “固定基线时间” 的适用范围;
    • 以及可量化、客观的加速机制(fast-track criteria)。

Part 4 Milestone Review 里程碑

:puzzle_piece: Proposal Key Points

  • Enter Milestone Review after initial approval. For each milestone:

    1. Stewards produce a Milestone Report (normal submission) or a Delay Report (if no delivery within 30 days of the stated milestone deadline or the team is unreachable).

    2. Every milestone is subject to a Quick Vote (Optimistic Mode): default PASS (funds released) unless a veto threshold is reached.

  • Veto Thresholds lowered to reduce fatigue and enable timely oversight:

    1. For regular project milestones: No-vote quorum = project budget equivalent in CKB.

    2. For meta-rule–related milestones (rare): No-vote quorum = 1/3 of the meta-rule threshold.

  • If veto happens (i.e., threshold reached), the proposal enters Risk/Crisis Management:

    1. Stewards organize one AMA + issue a situation report;

    2. Hold a 7-day Full Review Vote (same “spam/participation” threshold as initial approval, i.e., 3× project budget CKB for regular projects);

    3. If Yes → return to Execution/Oversight; if No → project terminated.

    4. If the team later gathers enough support, it may enter a 30-day “regain trust” review followed by another 7-day vote.

  • Stewards have no decision power on whether milestones are met; they collect evidence (e.g., GitHub, deliverables) and publish reports to trigger community voting.

:speech_balloon: Community Questions & Team Responses

Speaker A
How are delays handled in the milestone process? Who determines when a delay report is issued?

Team Response (Speaker 1):

  • At each milestone deadline, the DAO Stewards verify the deliverables and issue a Milestone Report.

  • If the project team fails to deliver within 30 days after the milestone date, or becomes unreachable, the Stewards issue a Delay Report.

  • Both reports automatically enter the Quick Vote (Optimistic Mode) — meaning the milestone is approved by default unless a veto quorum is reached.


Speaker B
What exactly does a Quick Vote look like? What are the thresholds and timeframes?

Team Response (Speaker 1):

  • A Quick Vote defaults to approval and fund release, unless vetoed.

  • Any community member can trigger a No vote if there are issues:

    • For regular project milestones – the No vote quorum equals the project’s total budget in CKB.

    • For meta-rule-related votes – the threshold equals one-third of the meta-rule quorum.

  • If the quorum is met and the milestone is rejected, the proposal moves to Crisis Management:

    • One AMA is organized and a situation report published;

    • A 7-day Full Review Vote follows, using the same threshold as the initial approval.

    • If “Yes” → project resumes; If “No” → project terminates.

    • The team may later re-enter a 30-day trust-rebuild period followed by another 7-day vote.


Speaker C
Wouldn’t this process feel too complicated or time-consuming for project teams? Will they actually cooperate?

Team Response (Speaker 1):

  • For normally delivered milestones, the Quick Vote passes automatically within 3 days if no objections reach the veto threshold.

  • It introduces no extra burden for responsible project teams;

  • Its value lies in empowering the community to intervene when issues arise — through transparent AMAs, reports, and secondary votes.

  • Most procedural work is handled by Stewards, not by the project team.


Speaker D
Since Stewards assess milestones, isn’t that too much power? Who decides whether a milestone is actually met?

Team Response (Speakers 1 & 6):

  • No, Stewards have no decision-making authority.

  • Their role is collecting evidence (GitHub links, documentation, deliverables) and publishing reports.

  • Every milestone still goes through a Quick Vote by the community.

  • If no objections reach the quorum, the milestone vote automatically passes and funds are released.


Speaker E (Community General Question)
Why use an “all-or-nothing” approach for this proposal? Why not separate the platform and rule components and approve them incrementally?

Team Response (Speaker 1):

  • This question was widely discussed on Talk, and the team appreciates all related feedback.

  • The proposal addresses a structural gap in procedural governance — from information flow, milestone review, to crisis handling — which are inter-dependent and cannot be cleanly separated.

  • Building the platform first without matching rules and a Steward team would waste DAO treasury and fail to achieve governance improvement.

  • Therefore, DAO v1.1 deliberately integrates the Web5 Platform + Steward Rules as a unified system to ensure practical implementation and sustainable efficiency.

:puzzle_piece: 提案要点说明

  • 初审通过后进入里程碑审核:

    • 正常交付 → 物业团队出具里程碑报告;
    • 逾期 30 天未交付/无法联系 → 物业团队出具延迟报告。
    • 每个里程碑均进行快速投票(乐观模式):默认通过并拨款,除非达到否决阈值。
  • 否决阈值下调,以降低投票疲劳、提升监督效率:

    • 普通项目里程碑:反对票参与权重合计达到“项目预算等值 CKB” 即形成否决;
    • 涉及元规则里程碑(极少):反对票阈值为“元规则门槛的 1/3”。
  • 触发否决后进入危机处理:
    1)物业组织1 场 AMA并发布情况报告;
    2)发起为期 7 天 的全面复审投票(参与门槛与初审一致:普通项目为 3×预算 CKB);
    3)若通过 → 回到执行监督;若不通过 → 项目终止;
    4)若项目后续重新凝聚支持,可进入 30 天“重建信任”审议并再次进行 7 天 投票。

  • 物业团队不裁决里程碑是否达成,仅收集证据、撰写报告并提交投票,具体裁决由社区投票完成。

:speech_balloon: 社区成员问题与提案团队答复

发言人 A
延迟如何处理?谁来判断是否进入延迟流程?

提案团队(发言人1)答复:

  • 每个里程碑在到期后由物业团队核查交付物并出具里程碑报告;
  • 若超出里程碑截止日期 30 天仍未交付或无法联系,物业团队出具延迟报告;
  • 无论是里程碑报告还是延迟报告,一律进入快速投票(乐观模式):默认通过,除非达到否决阈值。

发言人 B
“快速投票”具体怎么运作?阈值与时长是什么?

提案团队(发言人1)答复:

  • 快速投票 = 默认通过(直接拨付该里程碑款项);
  • 若社区成员认为存在问题,可发起反对票:
    • 普通项目:反对参与权重合计达到**“项目预算等值 CKB”则否决**;
    • 元规则相关:反对参与权重合计达到**“元规则门槛的 1/3”则否决**;
  • 被否决后进入危机处理(含 1 场 AMA + 情况报告 + 7 天全面复审投票)。复审投票的参与门槛与立项初审一致。

发言人 C
这个流程会不会让项目方觉得“太麻烦”?他们会愿意配合吗?

提案团队(发言人1)答复:

  • 对正常交付的项目方而言,快速投票会在 3 天内自动通过(无人达到反对阈值时),拨款不受影响;
  • 该机制的价值在于:一旦出现问题,社区有权及时介入,并通过“AMA + 报告 + 复审投票”透明地纠偏或终止。
  • 这里的大部分流程性工作由物业团队执行,项目方不需要额外承担复杂操作。

发言人 D
由物业来判断是否达标,会不会有权力过大、主观裁决的问题?

提案团队(发言人1 & 6)答复:

  • 不会。物业团队没有决策权,只收集证据、生成报告、提交投票;
  • 每一个里程碑都必须进行快速投票,并由社区投票结果决定是否通过或进入危机流程;
  • 若没有达到否决阈值,快速投票自动通过并拨款。

发言人 E(社区成员的“整体/拆分”问题)
为什么采用“整体通过或整体否决”的推进方式?能否考虑把平台与规则拆开、分步推进?

提案团队(发言人1)答复:

  • 我们认真讨论过“拆分推进”的建议,也感谢社区在 Talk 上的充分讨论与反馈;
  • 但本提案的关键缺口是“流程化治理能力”:从信息同步、里程碑审核到危机处理,这些彼此耦合、难以拆分;
  • 仅做平台、缺少成套规则与团队职责,容易造成资源浪费、无法发挥平台效能;
  • 因此选择平台 + 物业规则联动推进,以确保落地时能真正提升治理效率与透明度。

Part 5 Web5 Platform Web5平台

:puzzle_piece: Proposal Key Points / 提案要点说明

  • The second core deliverable of DAO v1.1 is a Web5 governance platform to unify discussion, voting, and staking in one place, solving today’s fragmented experience across multiple tools.

  • Key design goals: (1) end-to-end governance flow on a single platform; (2) on-chain, verifiable voting via CKB smart contracts; (3) steward-operated reporting to keep information symmetrical for the community.

:speech_balloon: Community Questions & Team Responses

Speaker A
Q: What are the main technical differences versus DAO 1.0?

Team Response:

  • Integration: Discussion, voting, and staking move from multiple tools to one unified platform.

  • On-chain voting: Votes are recorded via CKB smart contracts for verifiability and auditability.

  • Open components: Data-fetch/verification components will be open-sourced so anyone can independently verify results.


Speaker B
Q: How are votes gathered and computed? Why build it this way?

Team Response:

  • Three-part design:

    1. Weight source: Voting weight = user’s CKB staked in Nervos DAO.
    2. Contract vote: On-chain contract records “who voted/what they voted” (one-account-one-ballot record; no weight here).
    3. Tally service: Merges address bindings + on-chain ballots, applies stake weights, outputs the final result.
  • Rationale: Keep DAO 1.0 functionality but add decentralization and verifiability, reducing reliance on centralized databases.


Speaker C
Q: Reliability wasn’t the issue; the real pain was voting with JoyID. Does this fix it?

Team Response:

  • Yes. An address-binding tool links a user’s Nervos DAO staking addresses (Neuron or others) with the JoyID login address:

    • Balloting: Cast the vote with JoyID.
    • Weighting: Count the staked CKB from the bound addresses.
    • If the user staked directly via JoyID, that stake counts natively.
  • Multiple addresses can be bound, lowering wallet-fragmentation friction.


Speaker D
Q: What’s the practical value for projects? Why prioritize this now?

Team Response:

  • A single entry point lowers participation friction and increases visibility and efficiency for proposals and milestone governance.

  • On-chain records improve transparency, long-term trust, and external auditability.

  • Reusable Web5 components act as public goods, benefiting other applications across the ecosystem.


Speaker E
Q: How much effort is being invested weekly?

Team Response:

  • Team: 1 designer, 1 frontend, 2 backend (working on the Web5 governance platform and related BBS components; shared infra is reusable).

  • Coordination: ~1–2 hours/day per person for community Q&A and refinement.

  • MVP target: Late October–early November. Even if funding isn’t granted, shipped parts will be open-sourced for reuse.


Speaker F
Q: What’s the difference between DID and .bit, and how does DID relate to future Web5 apps?

Team Response:

  • .bit is a human-readable naming system; DID is a globally unique identity better suited for machine verification and cross-app recognition.

  • In Web5, users control and migrate their data (e.g., to personal data stores, PDS) and reuse the same identity across apps.

:puzzle_piece: 提案要点说明

  • DAO v1.1 的第二个核心交付物是 Web5 治理平台,把讨论、投票、质押等行动 统一到一个平台,解决现有工具分散带来的参与门槛。

  • 设计要点:① 全流程一体化;② 通过 CKB 智能合约实现 链上可验证投票;③ 由物业团队产出里程碑报告,保障信息对称。

:speech_balloon: 社区成员问题与提案团队答复

发言人A
与 DAO 1.0 相比,技术上的主要差异是什么?

团队答复(发言人7 & 8)

  • Integration 一体化: 1.0 阶段“讨论在论坛、投票在 Metaforo”,1.1 改为 同一平台完成全流程。
  • On-chain voting 链上投票: 由 CKB 智能合约承载投票记录,可审计、可验证。
  • Open components 开源组件: 将开源抓取与校验链上投票数据的组件/服务,便于社区或第三方复核。

发言人B
投票如何采集和计权?为什么要这样设计?

团队答复(发言人8)

  • 三段式设计
  1. 权重来源:以 Nervos DAO 质押的 CKB 为投票权重基础;
  2. 合约投票:链上投票合约记录“是否投票/投给谁”(一人一票记账,不含权重);
  3. 结果汇总服务:同时读取“地址绑定关系 + 链上投票记录”,按权重计算最终结果。
  • 动机:功能上与 1.0 保持一致,但提升去中心化与可验证性,减少对中心化数据库的信任依赖。

发言人C
以往结果可信度不是核心问题,真正痛点是 JoyID 用户如何投票。这个方案能解决吗?

团队答复(发言人7 & 8)

  • 能解决。 通过 地址绑定工具 将用户在 Neuron/Nervos DAO 的质押地址与 JoyID(或其它钱包)登录地址绑定:

    • 投票时 使用 JoyID 钱包交互;
    • 计权时 依据被绑定地址在 Nervos DAO 的 CKB 质押数量 汇总计算;
    • 若用户直接用 JoyID 存入 Nervos DAO,也可直接计入权重。
  • 该机制同时兼容多地址绑定,降低不同钱包生态的参与门槛。


发言人D
这对项目的“实际价值”是什么?为什么现在优先做?

团队答复(发言人7 & 1)

  • 统一入口降低治理参与摩擦,提升提案讨论与里程碑治理的可见度与效率;
  • 链上记录增强透明度,有利于长期信任与外部审计;
  • 平台产出的通用组件与基础设施可被 复用到其他 Web5 应用(公共物品属性),带动更广泛建设。

发言人E
当前每周大约投入多少开发与协调工作?

团队答复

  • 团队配置:1 名设计、1 名前端、2 名后端(并行开发 Web5 治理平台与 BBS 相关工作,公共组件可跨项目复用)。
  • 管理协调:每人每日约 1–2 小时用于答复社区与方案完善;
  • MVP 目标:预计 10 月底–11 月初完成可用版本;即使提案未通过,已完成部分也会 开源 并支持其他 Web5 项目复用。

发言人F
DID 与 .bit 的差异?与后续 Web5 应用的关系?

团队答复(发言人8 & 7)

  • .bit 偏向可读的命名体系;DID 是全局唯一的身份标识,更适合机器可验证与跨应用识别;
  • Web5 体系中,用户可 自主管理与迁移数据(如选择个人数据存储 PDS),在不同应用间复用统一身份与数据连接。

Part 6 Budget 预算申请

:puzzle_piece: Proposal Key Points

  • The total budget of the DAO v1.1 proposal is USD 100,000 equivalent in CKB.

  • Allocation:

    • $72,000 for the Web5 governance platform development;
    • $18,000 for the first-year operation of the DAO Stewards team.
  • Detailed breakdowns are listed in the proposal table on Nervos Talk.

  • The first-term DAO Stewards recruitment will be open to the whole community once the proposal passes — welcoming both self-nominations and community recommendations.

  • The proposal team will also publish a follow-up post detailing each member’s background and transparency of roles.

:speech_balloon: Community Questions & Team Responses

Speaker A
Q: How transparent is the proposal team’s composition?

Team Response:

  • A separate post will be published on Nervos Talk after the AMA to introduce each member’s affiliation and responsibilities.

  • Transparency is key — the DAO Stewards team, once formed, will operate independently and publicly, under community oversight.


Speaker B
Q: Will the DAO Stewards actively promote CKB and attract more external proposals?

Team Response:

  • The DAO Stewards’ primary role in v1.1 is to optimize internal governance mechanisms — ensuring procedural integrity, milestone tracking, and information flow.

  • External outreach is not part of this proposal’s current scope, but the team agrees it’s essential for future DAO evolution.

  • Future DAO teams or other task groups could take this role once internal operations are stabilized.


Speaker C
Q: Any technical follow-up regarding the multisig wallet?

Team Response :

  • Neuron already supports multisig, but its process is manual and cumbersome — members must exchange JSON files via email or Telegram to complete signatures.

  • UTXO Global offers smoother task management and a unified interface, though it concentrates more functions in one place, slightly increasing the attack surface.

  • Security trade-offs will be further discussed in Talk threads after the AMA.

:puzzle_piece: 提案要点说明

  • DAO v1.1 提案的 总预算为等值 10 万美元的 CKB。
  • 资金分配:
    • 7.2 万美元 用于 Web5 治理平台的开发;
    • 1.8 万美元 用于 DAO 物业团队第一年的运营。
  • 详细预算分配已在 Nervos Talk 的提案表格中列出。
  • 若提案通过,首届 DAO 物业团队的成员将面向整个社区公开招募,欢迎自荐与推荐。
  • 提案团队将在 AMA 后发布补充帖,说明成员构成与背景信息,以增强透明度。

:speech_balloon: 社区成员问题与提案团队答复

发言人 A:
团队的构成与透明度如何?

提案团队答复:

  • AMA 结束后,团队会在 Nervos Talk 上发布一篇独立帖子,详细介绍各位成员的所属背景与职责。

  • 透明度是核心原则。未来的 DAO 物业团队在成立后,也将 独立运作、公开透明,并接受社区监督。


发言人 B:
DAO 物业团队未来是否会主动对外推广 CKB,吸引更多外部项目参与?

提案团队答复:

  • 在 v1.1 提案中,DAO 物业团队的首要任务是 优化内部治理机制,包括流程化的执行、里程碑追踪与信息同步。

  • 对外拓展不在当前提案范围之内,但团队认为这对未来 DAO 的发展非常重要。

  • 未来无论是 DAO 物业团队还是其他社区工作组,都可以在内部治理稳定后承担外部推广与合作的职责。


发言人 C:
关于多签钱包的技术方案,还有需要补充的说明吗?

提案团队答复:

  • Neuron 其实已经支持 多签功能,但操作方式非常原始——多签成员需要通过邮件或 Telegram 传递 JSON 文件完成签名。

  • 相比之下,UTXO Global 提供了更流畅的任务管理体验和一体化界面,但也因此 集中度更高、潜在攻击面更单一。

  • 团队认为这是一种可讨论的安全权衡,后续将在 Nervos Talk 社区中进一步展开技术讨论。


7 Likes

Hey @zz_tovarishch!! :hugs:

Would it be possible to share the implementation you’re currently working on?

Public GitHub links to the Web Dapp and L1 contracts would be greatly appreciated. Since this is a community-led open-source project, sharing the repos shouldn’t cause any issues.

Thanks,
Phroi

更新日志,持续问答,及团队透明度/独立性说明(2025.10.23)

大家好,

随着我们社区审议月临近尾声,我们的目标是在进入投票前,以完全的透明度,回应所有悬而未决的社区问题。

更新日志 (2025年10月23日):

  • 调整: 将社区审议期缩短为21天,AMA调整为至少1场 (3.3.2节)。
  • 调整: 由DAO物业团队管理的项目执行钱包的多签方案实现方式将不再指定,转由未来的《运营手册》详细规定 (3.1.3节 & 3.2.1节)。

变更理由说明

1. 关于缩短社区审议期 (30天 → 21天):
在 AMA#2 中,社区提出了一个中肯的观点,即我们需要在“充分讨论”和“保持势头”之间找到更好的平衡。我们认为将审议期缩短为21天是一个合理的折中。这个时长依然能为深度讨论和至少一场 AMA 提供充足的时间,同时也让整个治理流程变得更加敏捷。

2. 关于项目执行钱包多签方案的调整:
我们最初的提案为“项目执行钱包”指定了UTXO Global的方案,这引起了社区成员对安全性的担忧,提出是否能同样使用Neuron。然而,经过测试,我们发现Neuron在 UDT 支持上存在一定的技术局限,其多签目前仅直接支持 CKB。若要满足对USDI的多签,需要额外开发或者需要联系外部技术人员构造交易,这一定程度上超出了DAO v1.1提案和物业团队的范围。

为了平衡安全性和效率,并保证未来的可扩展性,我们从元规则中移除了项目执行钱包特定多签方案的指定。具体的实现方案,将交由物业团队在《运营手册》中根据实际情况设置和及时调整。这赋予了 DAO 灵活性,可以始终选择当下最合适的技术方案,而无需再次修改元规则。

具体来说,如果v1.1通过,现阶段的项目执行钱包可能会完全采用UTXO Global,或者对 “固定 CKB 数额”的项目使用 Neuron,为“固定 USDI 数额”的项目采用UTXO Global。

DAO 主金库钱包方案由其委员会决定,不受此变更影响。


持续问答更新

问:DAO v1.1 提案是否应该包含一个‘日落条款’——即在一年后进行一次强制投票,以决定是否恢复到 v1.0?

答: 这是一个极具战略性的构想,我们也对此进行了严肃的思考。设置该日落条款无疑能增强社区对v1.1的信心。然而,我们最终决定在提案中增加“日落条款”,这是基于一项我们认为必须捍卫的 DAO 治理核心原则。

理由如下:
我们认为,一个预设的、强制性的“日落”投票,会损害所有 DAO 成员的一项基本权利:在任何时候发起元规则修改的权利。 改变规则的权力应该始终掌握在社区手中,按照他们自己的节奏,而不是由一个预设的时钟来决定。

这次讨论帮助我们厘清了一个至关重要的区别:

  • 对框架 (规则) 的问责: 元规则是 DAO 的宪法,应该是持久的,直到社区自己通过下一个提案来改变它。
  • 对团队 (物业) 的问责: 团队必须被问责。我们的提案已有强力机制:物业团队为期一年的任期,以及社区在任何时候可以罢免DAO物业团队的权利

关于团队透明度/独立性的说明

1. 我们的身份:独立的社区贡献者
提案团队成员均在生态某部分担任职务: Baiyu (CKB Eco Fund 合伙人)、Yixiu (CKB Eco Fund DevRel) 、David (App5 团队成员) 、舟舟 (CKB Eco Fund 研究负责人)。但我们均是以独立的社区成员身份参与此次提案,而非各自组织的官方代表。

2. 资助的性质:一个独立的社区项目
DAO v1.1 提案向 Community Fund DAO 申请资助。重要的是,Community Fund DAO 与 Nervos 基金会是两个独立的实体。App5 团队受基金会委托,负责开发和维护生态系统内的数个公共产品,Eco Fund 也有其独立的预算。因此,不存在一个已受 DAO 资助的实体或该实体成员,为其他目的再次申请资金的利益冲突。

3. 关于承诺与报酬
本提案申请的预算,旨在为个人贡献者在这个特定的社区项目上付出的、专注的、专业的劳动(平台开发及后续物业团队运营)提供合理且必要报酬。交付成果的质量及其对应的生态价值是我们遵循的标准,同时也全面接受DAO 的监督。


感谢每一位参与本次审议月的朋友。你们的反馈让这个提案变得更加强大。我们相信,它现在已经准备好,可以交付给社区进行最终的决策。

Updates, Q&A, and a Note on Transparency (Oct 23, 2025)

Hello everyone,

As our Community Review Month comes to a close, our goal is to address all remaining community questions with full transparency before we move towards a vote.

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

Rationale Behind the Changes

1. On Shortening the Community Review Period (30 → 21 Days):
During AMA #2, the community raised a valid point about finding the right balance between thorough discussion and maintaining momentum. We recognize shortening the review period to 21 days is a reasonable compromise. This duration still provides ample time for deep discussion and at least one AMA, while making the entire governance process more agile.

2. On the Adjustment of the Project Execution Wallet’s Multi-sig Solution:
Our initial proposal specified the UTXO Global solution for the “Project Execution Wallet,” which raised community concerns about security, with suggestions to use Neuron instead. However, after testing, we found that Neuron has certain technical limitations regarding UDT support, as its multi-sig currently only directly supports CKB. To fulfill the multi-sig requirements for USDI, it would require additional development or the need to engage external technical personnel to construct the transactions, which, to some extent, falls beyond the scope of the DAO v1.1 proposal and the Stewards team.

To balance security with efficiency and ensure future scalability, we have removed the specification of a particular multi-sig solution from the proposal. The specific implementation will be determined by the Stewards in the “Operational Handbook” based on the situation at the time. This gives the DAO the flexibility to always choose the most appropriate technical solution without needing another meta-rule change.

Specifically, if v1.1 is approved, the Project Execution Wallet might initially use UTXO Global exclusively, or use Neuron for “Fixed CKB Amount” projects and UTXO Global for “Fixed USDI Amount” projects.

The main DAO treasury’s wallet solution is determined by its committee and is not affected by this change.


Ongoing Q&A Update

Q: Should the DAO v1.1 proposal include a ‘sunset clause’—a mandatory vote after one year to decide whether to revert to v1.0?

A: This is a brilliant strategic idea, and we gave it serious consideration. A sunset clause would undoubtedly enhance community confidence in v1.1. However, we have decided not to add a sunset clause to the proposal, based on a core principle of DAO governance that we believe must be defended.

The Rationale:
We believe a scheduled, mandatory “sunset” vote would undermine a fundamental right of all DAO members: the right to propose a meta-rule change at any time. The power to change the rules should always lie with the community, on their own schedule, not on a pre-determined clock.

This discussion helped us clarify a crucial distinction:

  • Accountability of the Framework (The Rules): The meta-rules are the DAO’s constitution. They should be durable until the community itself decides to change them again through another proposal.
  • Accountability of the Team (The Stewards): The team must be held accountable. Our proposal already has strong mechanisms for this: a one-year term for the Stewards, and the community’s right to impeach the DAO Stewards at any time.

A Note on Team Transparency & Independence

1. Who We Are: Individual Community Contributors
The proposal team members each hold roles within the ecosystem: Baiyu (Partner at CKB Eco Fund), Yixiu (DevRel at CKB Eco Fund), David (member of the App5 team), and Zhouzhou (Research Lead at CKB Eco Fund). However, we are all participating in this proposal as individual community members, not as official representatives of our respective organizations.

2. The Nature of the Grant: An Independent Community Project
The DAO v1.1 proposal is applying for a grant from the Community Fund DAO. It is important to note that the Community Fund DAO and the Nervos Foundation are two separate entities. The App5 team is commissioned by the Foundation to develop and maintain several public products within the ecosystem, and the Eco Fund also has its own independent budget. Therefore, no conflict of interest exists in the sense of a DAO-funded entity or its members applying for more funds for other purposes.

3. On Commitment and Compensation
The budget requested in this proposal is to provide reasonable and necessary compensation for the dedicated, professional work that individuals will contribute to this specific community project (platform development and subsequent Steward team operations). The quality of the deliverables and their corresponding ecosystem value are the standards we will adhere to, and we will be fully accountable to the DAO’s oversight.


Thank you to every community member who participated in this review month. Your feedback has made this proposal significantly stronger. We believe it is now ready to be presented to the community for a final decision.

4 Likes

Hey Phroi,

I’ve already reached out to get the public GitHub links for both the Web Dapp and the L1 contracts.

I’ll share them here in this thread as soon as they send them over to me.

Thanks for your continued diligence on this!

5 Likes

Thank you so much @zz_tovarishch for your work!!

I am so curious to see how exactly the voting is gonna be implemented. Also I will be really interested into perusing this one month GitHub history to see who exactly is making this USDi-funding dream come true :star_struck:

Feel free to share any time now,
Phroi

1 Like