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

CKB Community Fund DAO
55

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