如何创建你自己的 DAO？从零到上线指南

创建 DAO 不等于先发一个治理代币，再开设 Discord 和投票页面。真正的创建过程，是把使命、成员、资产、决策、执行与责任连接成一套能够运行的制度。工具只能把规则写进界面或合约，无法替你决定谁该拥有权力、什么事情值得投票、提案失败后由谁负责。

对大多数新团队而言，最稳妥的路线是渐进式上线：先用章程、论坛和 Safe 多签验证协作，再用 Snapshot 收集成员意见；当金库、成员与协议权限扩大后，才考虑治理代币、Governor、Timelock 和更复杂的法律结构。

本文提供从想法到正式运行的完整步骤。阅读前也可以先通过DAO 去中心化自治组织完全指南理解成员、提案、投票、执行、金库与法律边界。

第一步：先确认你真的需要 DAO

DAO 适合需要多人共同管理资产、协议、公共资源或社区规则的项目。例如开源协议希望把升级权交给用户，投资社群需要共同审批资金，服务团队希望按贡献分配预算，创作者社区需要共同管理品牌与活动。

如果项目只有两三位创始人、商业模式尚未验证、所有关键工作都由同一团队完成，普通公司加多签可能更高效。过早引入全民投票会增加沟通、合规和安全成本，却不会自动带来用户。

开始前回答三个问题：哪些决定必须多人共同作出？哪些资产需要共同保管？如果创始人离开，组织能否继续运行？没有清楚答案时，应先做小规模协作实验，而不是发行可交易代币。

第二步：写出一页 DAO 章程

章程不必从几十页法律文件开始，但至少要写清使命、治理范围、成员条件、提案流程、金库原则、紧急权限和修订方式。它是后续设置工具参数的依据。

使命应该能用一句话解释。例如，为某个开源协议维护公共基础设施，或为一个创作者网络分配共同收入。使命过于宽泛，会让所有提案都看似合理，金库也容易变成无方向的资助池。

治理范围要同时写“管什么”和“不管什么”。DAO 可能控制金库和品牌，却不控制开发公司的雇佣；可能管理协议参数，却不能要求独立前端执行商业决定。边界越清楚，成员越不容易误解代币权利。

还要定义章程如何修改。普通运营规则可以较低门槛更新，核心使命、代币供应、升级权和解散条款则应拥有更长讨论期与更高支持要求。

第三步：选择 DAO 类型与成员模型

协议 DAO 重点是合约升级、风险参数和开发协调；投资 DAO 重点是资金承诺、资产托管与退出；社交 DAO 重点是准入、文化和活动；服务 DAO 则更关心项目分配、交付与报酬。类型不同，不能复制同一套投票规则。

创建者应先确定成员如何进入。常见方式包括创始成员名单、贡献审核、持有 NFT、持有或质押代币，以及由现有成员邀请。开放加入有利于扩张，审核制能提高协作密度，但会增加管理者权力。

成员资格与投票权也可以分离。一个人可以参加讨论却没有金库投票权；专业委员会可以审核技术提案；社区代币可以决定方向，Safe 签名人负责核验执行。完整类型比较可阅读DAO 的类型：协议DAO/投资DAO/社交DAO/服务DAO。

第四步：画出权力与责任图

列出 DAO 的全部控制点，包括域名、论坛、社交账号、代码仓库、前端、合约管理员、金库、预言机、服务器、商标和法律实体。每个控制点都要对应当前负责人、备用负责人和撤换方式。

不要只画链上权限。攻击者控制论坛管理员或域名，也可能发布假提案和钓鱼链接；开发公司控制升级代码和部署流程，即使不持有治理代币，也拥有重要信息优势。

初期可以让创始多签保留部分权限，但要公开哪些权力尚未去中心化，以及满足什么条件后移交。模糊的“未来会交给社区”不是路线图，应设置时间、测试、审计与通过标准。

第五步：确定法律、税务与合同安排

智能合约可以持有链上资产，却无法自然解决银行账户、雇佣、税务、知识产权、供应商合同和诉讼。DAO 是否需要基金会、协会、公司、合作社、DAO LLC 或 DUNA，要根据业务、成员所在地和适用法律判断。

不要把匿名投票或注册在链上理解为免除责任。美国 Ooki DAO 执法案例已经表明，监管与法院可能把 DAO 视为可承担责任的组织；其他司法辖区的处理方式又可能不同。

正式吸收资金、发行可交易代币、向公众销售权益或开展金融业务前，应获得适用地区的法律和税务意见。章程还应明确链上投票与法律实体董事、管理员或签约人的关系，避免两套规则互相冲突。

第六步：设计金库和预算制度

DAO 金库不应直接放在创始人的个人钱包。初期可以部署 Safe Smart Account，设置多位 Owner 与确认阈值。Safe 的核心多签模型要求达到指定数量的签名后才执行交易，可以降低单点私钥风险。

签名人应来自不同设备、组织与地区，避免所有密钥存放在同一办公室或同一云账户。2-of-3、3-of-5 等只是常见例子，实际阈值要平衡安全、时区和紧急可用性。

创建金库后，先进行小额转入、普通付款、拒绝交易、替换签名人和恢复演练，再存入主要资金。记录 Safe 地址、网络、Owner、Threshold 与已启用模块，并通过多个公开渠道验证。

预算制度至少包含年度或季度上限、提案授权、收款地址核验、分期付款、报表和剩余资金处理。日常小额支出可以设置限额，核心资金仍需多签或治理批准。

第七步：选择网络与基础设施

选择网络时，要考虑成员钱包支持、Gas、资产所在链、治理工具兼容、区块确认、桥接和安全假设。便宜的网络能降低投票成本，但如果金库主要在另一条链，跨链执行会增加新的信任与操作风险。

不要默认同一个多签地址在所有网络都已部署。Safe 官方资料提示，多链账户存在版本和网络兼容限制；向未部署或不兼容的地址转账，可能导致资产难以找回。

基础设施还包括论坛、文档、日历、通知、链上浏览器、数据索引和备份。治理页面失效时，成员仍应知道如何读取提案、找到合约和完成紧急联系。

第八步：选择适合阶段的治理工具

小型团队可以使用论坛、Safe 与成员名单。需要低成本投票时加入 Snapshot；需要自动执行和更强抗审查时，再评估 Snapshot X、Aragon OSx 或 OpenZeppelin Governor 与 Timelock。

Aragon OSx 把 DAO 设计为能够持有资产、执行操作、安装插件和管理权限的链上组织。它适合需要模块化权限与自定义插件的团队，但插件获得的权限必须逐项审计。

OpenZeppelin Governor 适合需要自主部署治理合约的协议，可组合 Votes、Counting、Quorum、Settings、Timelock 和 Late Quorum 等模块。灵活性越高，部署、测试和维护责任也越大。

选择工具时不要只看前端。要确认投票权数据源、执行合约、管理员、升级权限、Timelock、前端替代方案和工具停运后的恢复方法。详细比较可阅读DAO 治理工具：Snapshot、Tally、Governor。

第九步：创建 Snapshot Space

根据当前官方文档，在 Snapshot 主网创建 Space 需要 Ethereum 主网 ENS 名称；测试环境则使用 Sepolia ENS。创建者进入 Space 创建页面后，依次设置资料、域名、基础网络、Voting Strategies、Proposal Validation、投票规则和成员。

Voting Strategy 决定谁有多少投票权，可以读取 ERC-20、NFT、白名单、委托或其他数据。Voting Type 决定如何表达选择，例如单选、加权、排序或赞成/反对/弃权。两者不能混淆。

Proposal Validation 用于限制谁能发起提案，避免垃圾与钓鱼。可以根据持仓、白名单或其他条件设置门槛；作者权限、管理员和 Space Controller 也要分散并记录。

正式创建前，应先在 Snapshot 测试网完整演练。创建测试提案，检查成员投票权、快照区块、开始与结束时间、Quorum、委托和多种钱包签名。

需要特别注意，oSnap 已在 2025 年 12 月停止支持，不能继续作为 Safe 自动执行方案。现有项目应依据官方说明迁移到 Snapshot X 或 SafeSnap，新 DAO 不应照搬旧教程部署 oSnap。

第十步：决定是否发行治理代币

DAO 不一定需要代币。早期组织可以用 Safe 签名人、白名单、贡献记录或成员 NFT 治理，等到权力分配和经济用途清楚后再发行可交易资产。

如果发行 ERC-20 治理代币，需要定义总供应、分配、锁仓、归属、金库份额、委托和增发权限。创始团队与投资者的解锁节奏会直接影响治理集中度，不能只在营销页面展示“社区占比”。

使用 Governor 时，投票代币通常需要历史投票权检查点，例如 ERC20Votes 或 ERC721Votes。持有人还可能需要先自我委托或委托给代表，余额才会进入治理权计算。

代币应有明确用途。为了“看起来像 DAO”而发行代币，会增加监管、税务、流动性和投机风险。治理权也不自动代表股权、利润分配、赎回权或法律成员资格。

第十一步：配置 Governor 与 Timelock

链上治理至少要确定投票权来源、提案门槛、Voting Delay、Voting Period、Quorum、计票方式和执行延迟。参数应根据真实可参与供应量和决策风险设置，而不是复制其他知名 DAO。

Voting Delay 给成员阅读、委托和发现恶意提案的时间；Voting Period 要覆盖主要时区；Proposal Threshold 抑制垃圾提案；Quorum 则防止少数地址在低参与时控制结果。

Timelock 应真正持有被治理的资产、合约所有权和访问角色。OpenZeppelin 官方说明强调，使用 Timelock 时由它执行提案，因此权限放在 Governor 本身可能导致治理无法操作相关资产。

部署后还要检查 Admin、Proposer、Executor 与 Canceller。额外 Proposer 或 Canceller 可能绕过治理或阻断已批准提案，初始化管理员应在完成配置后按设计移交或放弃权限。

第十二步：建立提案模板

每份提案应包含标题、问题、目标、背景、备选方案、预算、负责人、时间表、里程碑、利益冲突、风险、执行步骤与失败处理。涉及链上操作时，还要列出目标合约、金额、函数与模拟结果。

提案最好分为讨论、温度检查和正式执行三个阶段。讨论阶段允许修改，不要急着投票；温度检查确认方向；正式提案必须使用最终地址和可执行载荷。

避免把多个无关操作打包。社区可能支持预算却反对权限修改，捆绑会迫使成员作出错误取舍。高风险操作应单独提案，并由作者之外的人员复核。

还要设置提案完成后的报告。通过并不等于交付，负责人应在固定日期更新支出、里程碑和结果；未使用资金、延期与失败需要预先规定处理方式。

第十三步：设计日常运营与授权

全民投票适合决定使命、年度预算、核心升级和重要选举，不适合审批每张发票。DAO 可以建立工作组、委员会和服务商，在明确范围与预算内执行日常事务。

每项授权都应包含负责人、权限、金额上限、任期、报告频率和撤销方法。运营多签与核心金库最好分离，小额支出账户不应同时拥有协议升级权。

Safe Spending Limit 可以让指定地址在额度内快速付款，但这类权限能够绕过普通多签确认。所有限额、模块和受益地址都必须定期复核，项目结束后立即撤销。

代表制度也需要问责。代表应披露报酬与利益冲突，发布投票理由和参与记录；成员应能撤回或覆盖委托，避免少数代表永久积累权力。

第十四步：进行测试网和桌面演练

上线前至少完成一次完整生命周期：创建提案、进入延迟、投票、达到或未达到 Quorum、排队、等待 Timelock、执行和验证结果。还要测试失败提案、取消提案和错误地址拦截。

桌面演练用于模拟真实事故。假设一名签名人失联、论坛被盗、恶意提案达到 Quorum、前端离线或金库收到错误资产，团队是否知道联系谁、在哪个合约操作、哪些权限可以暂停？

所有地址和参数应由两名以上成员独立核对。部署交易、Owner、Threshold、Token、Governor、Timelock 与权限移交都要形成发布记录，不能只保存在个人聊天中。

主网启动时先使用小额资金和低风险权限，观察一至两个治理周期后再扩大金库或移交核心合约。一次性“完全去中心化”会让配置错误难以恢复。

第十五步：正式上线 DAO

上线公告应同时发布官方域名、论坛、文档、Snapshot Space、金库、治理合约、区块浏览器和支持渠道。对每个地址进行多渠道交叉验证，避免成员从搜索广告进入仿冒页面。

公布第一批成员、签名人、管理员、代表和工作组的任期与权限。若身份匿名，应说明筛选、验证与更换机制；匿名不应成为无法问责的理由。

首批提案应选择低风险事项，例如社区规则确认、小额活动预算或委员会选举。不要把代币增发、全部金库迁移和协议升级塞进第一次投票。

同时设立事故渠道和治理日历。成员要知道何时讨论、何时投票、谁发布提醒，以及发现钓鱼、合约漏洞或签名人异常后如何报告。

上线后的 30/60/90 天做什么？

前 30 天重点观察基础运行。检查提案是否容易理解、投票权是否正确、签名人能否及时响应、报表是否发布，以及成员是否能找到官方入口。

第 31 至 60 天开始评估参数。根据实际参与率调整提案门槛、Voting Period 和 Quorum，删除不再使用的管理员与模块，并复核金库限额。

第 61 至 90 天进行第一次治理复盘。比较提案从讨论到执行的时间、预算完成率、委托集中度和安全事件，决定哪些权限可以进一步下放，哪些流程需要保留人工复核。

参数调整应通过公开提案完成，不能由后台管理员悄悄修改。DAO 的可信度来自持续记录，而不是上线当天宣布“治理已交给社区”。

创建 DAO 最常见的错误

第一，先发代币再找用途。投机者进入后，使命和成员文化更难建立。

第二，所有决定都投票。成员很快疲劳，真正重要的提案反而得不到关注。

第三，只看多签阈值，不看 Safe Modules。恶意或过度授权的模块可能绕过 Owner Threshold 并执行任意交易。

第四，Quorum 直接复制大项目。若大量代币不参与，新 DAO 会因过高门槛停摆。

第五，文字提案与 Calldata 不一致。链上只执行地址、金额和函数，不会理解社区本意。

第六，创始权限没有退出条件。临时管理员最终变成永久后门。

第七，忽视链下责任。没有合同、税务、知识产权和交付制度，链上投票也无法完成现实工作。更多风险可阅读DAO 的挑战：治理攻击、投票冷漠与效率瓶颈。

Hotcoin LAUNCH 六维上线检查法

18.1 L：Logic，创建理由是否成立

确认 DAO 解决的是共同资产与共同决策问题，而不是单纯为了发币或营销。

18.2 A：Authority，权限是否可见

列出合约、金库、域名、前端、多签和法律实体控制者，确保每项权力都有边界与撤换方法。

18.3 U：Users，成员与代表是否明确

说明加入、退出、委托、投票和利益冲突规则，避免钱包数量被误当作真实成员数。

18.4 N：Numbers，治理参数是否经过测试

用真实代币分布和预期参与率测试门槛、Quorum、投票期、Timelock 与多签阈值。

18.5 C：Controls，安全防线是否完整

检查快照、权限最小化、模块、暂停、取消、监控、备份和事故沟通，并完成恢复演练。

18.6 H：Handoff，权力能否安全交接

确认创始管理员如何移交、签名人如何轮换、工作组如何结束，以及前端失效后能否继续治理。

普通成员如何安全加入新 DAO？

先阅读章程和权限图，确认 DAO 真正控制哪些资产，以及代币是否只有投票用途。查看金库、多签、管理员和执行合约，不只看社交媒体人数。

连接治理网站前核对官网、网络和合约。使用独立钱包参与提案、委托和领取，把主要资产与新项目风险隔离。

委托通常只分配投票权，不应要求把代币转给代表。任何 Permit、Token Approval 或资产发送都需要单独核验。

阅读提案的可执行内容，尤其是收款地址、金额、权限和 Timelock。高赞评论、KOL 推荐和当前票数不能替代个人判断。

常见问题

20.1 创建 DAO 一定要发行代币吗？

不需要。小型组织可以使用多签、白名单、贡献记录或 NFT 管理成员和投票，确认需要可转让治理权后再发行代币。

20.2 创建 DAO 需要会写代码吗？

简单 DAO 可以用 Safe 和 Snapshot 等界面完成，但权限、策略和安全仍需专业复核。自定义 Governor、插件和跨链执行通常需要开发与审计能力。

20.3 DAO 金库应该设置多少位签名人？

没有统一答案。应根据资金规模、成员独立性、时区、设备和紧急可用性设置，并确保任何单个人都不能独立转移核心资金。

20.4 Snapshot 投票通过后会自动付款吗？

经典 Snapshot 通常只记录链下投票。付款需由 Safe 签名人执行，或通过 Snapshot X、SafeSnap 等经过配置的机制连接链上执行。

20.5 DAO 可以没有法律实体吗？

技术上可以，但现实合同、税务、责任和雇佣问题仍然存在。是否设立实体及采用何种结构，应根据业务和适用司法辖区获得专业意见。

20.6 DAO 上线后还能修改治理参数吗？

可以，但应由章程或治理合约规定修改流程。核心参数变更需要充分讨论、公开投票与权限核验，不能依赖不透明管理员。

20.7 如何判断 DAO 已经可以正式上线？

至少应完成章程、权限图、金库演练、提案全流程测试、事故预案、法律评估和公开地址验证。仅部署代币和投票页面不算完成。

结论：先验证协作，再扩大自治

创建 DAO 的正确顺序是使命、成员、责任、金库、提案、工具、测试和交接，而不是代币、空投和宣传。治理设计必须回答谁能决定、谁能执行、谁能暂停、谁对结果负责。

早期使用 Safe 与 Snapshot 并不代表失败或不够去中心化。只要临时权限公开、受限且有清楚移交条件，渐进式治理通常比一次放弃所有控制权更安全。随着组织成熟，再将高价值权限交给 Governor、Timelock 和经过审计的模块。

DAO 上线只是开始。参与率、执行周期、代表集中、预算完成率和安全事件都要持续复盘，工具停运、成员退出和法律变化也需要迁移方案。

回到DAO 去中心化自治组织完全指南，可以把本指南与 DAO 类型、治理工具、挑战和案例文章结合，形成从理解到创建的完整路径。

如需管理多链资产和连接治理应用，可使用 Hotcoin Web3 Wallet；需要移动端行情与交易工具，可前往 Hotcoin App；浏览更多教育内容，请访问 Hotcoin。

风险提示： 本文仅用于教育与信息分享，不构成投资、法律或税务建议。DAO 的代币、工具、合约权限、法律结构、税务责任和项目状态可能变化；创建或参与前请核验最新官方文档、审计、合约地址、钱包签名和所在地区规则。