为什么有的 DAO 投票冷场、成员出走，有的却能持续运转？从 MakerDAO 到 Uniswap 的实战启示
一、 那个凌晨三点的投票，像极了无人接听的电话
你有没有经历过这样的场景：
凌晨三点，手机震动了一下。你迷迷糊糊点开 Discord，发现某个 DAO 发起了一个提案投票。
“关于金库资金配置的提案”
你眯着眼扫了两眼，心想”这不关我事”，随手划走。
第二天醒来，投票已经结束了。通过？还是否决？没人知道。参与率 3.7%，创历史新高。
然后群里一片死寂。
这种情况太常见了。据统计，超过 60% 的 DAO 治理提案投票参与率低于 10%，约三分之一在启动后 48 小时内就彻底冷场，而成员流失率最高的时间段恰恰是投票结束后的一周。
但与此同时，也有一些 DAO 像永动机一样持续运转——MakerDAO 管理着超过 100 亿美元的价值，Uniswap 每天处理数十亿美元的流动性，治理提案一个接一个，总有人投票、有人提案、有人执行。
差距在哪里？
这不是运气问题，也不是”社区凝聚力”这种空话能解释的。背后有一套可以拆解、可以复制、也可以规避陷阱的系统。
二、 投票冷场的三层死结
在深入对比之前，我们先把”冷场”这件事拆明白。投票冷场从来不是单一原因造成的，而是三个层面的问题叠加在一起：
2.1 激励错位：为什么我要投票？
这是最核心的问题。在 MakerDAO 早期，一个典型持有 MKR 的人面临着这样的计算：
投票成本 = 学习时间 + 决策精力 + 机会成本
投票收益 = 几乎为零（除非你的投票改变了结果）
理性选择 = 不投票
这是一个经典的”理性冷漠”困境。每个持有者都心想：”我一个人一票改变不了结果，不如让别人去操心。”当所有人都这么想，投票率就塌了。
2.2 信息过载：提案写得像论文
很多 DAO 的提案文档长这样：
“鉴于当前 ETH 基准利率处于 0.12% 水平，结合 Macro 环境中的通胀预期与稳定币发行量的增长趋势，我们提议调整 DSR（Dai Savings Rate）至 0.75%…”
配图是一个 47 页的 PDF，还有一张复杂的参数矩阵表。
一个普通的代币持有者（可能是个上班族，只是买了 USDC 赚利息）看到这些东西，大脑直接关机。这不是”社区参与度低”，这是认知门槛太高。
2.3 执行黑箱：投票完了之后呢？
这是最容易被忽视的一环。很多 DAO 的治理流程是这样的：
提案提交 → 社区讨论 → 链下投票（Snapshot） → 链上执行？
然后就没有然后了。
有人投票赞成一个提案，等了一周，发现没有任何链上交易发生。再等一个月，发现提案被”无限期推迟”。于是第二次、第三次，参与者越来越少。
信任一旦透支，重建的成本是指数级的。
三、 MakerDAO：从”币圈央行”到治理机器
MakerDAO 是目前最老牌的 DAO 之一，成立于 2015 年，发行 Dai 稳定币。它经历过的治理危机比大多数 DAO 整个生命周期还长。
3.1 MakerDAO 的治理架构：三层结构
┌─────────────────────────────────────────────┐
│ MakerDAO 治理三层结构 │
├──────────────┬──────────────┬────────────────┤
│ 风险参数组 │ 治理委员会 │ MKR 持有人 │
│ (Rug Pull) │ (Governance │ (最终决策权 │
│ │ Committee) │ 委托给委员会) │
├──────────────┼──────────────┼────────────────┤
│ • 抵押率 │ • 日常决策 │ • 发起提案 │
│ • 利率 │ • 紧急响应 │ • 委托投票 │
│ • 资产准入 │ • 参数调整 │ • 监督委员会 │
└──────────────┴──────────────┴────────────────┘
这个设计的关键在于：它承认了”直接民主”在复杂金融系统面前的局限性。
3.2 核心策略一：把决策分成”日常”和”重大”
MakerDAO 没有让所有决策都走全社区投票。它把参数分为两类：
第一类：日常风险参数
- 由”风险参数组”（Risk Parameters）负责
- 这些是专业人士，通常有金融背景
- 他们可以相对快速地调整利率、抵押率等
- 不需要每次都全社区投票
第二类：重大治理决策
- 比如添加新的抵押品类型
- 比如修改核心协议逻辑
- 这些需要 MKR 持有者投票
// 简化的 MakerDAO 治理逻辑示意
contract MakerDAOGovernance {
// 紧急参数 - 可以在短时间内调整
mapping(bytes32 => uint256) public riskParameters;
// 关键参数 - 需要社区投票
mapping(bytes32 => bool) public criticalParameters;
// 风险参数组可以调整日常参数
function updateRiskParameter(
bytes32 id,
uint256 newValue
) external onlyRiskGroup {
require(!criticalParameters[id],
"This is a critical parameter requiring vote");
riskParameters[id] = newValue;
}
// 重大变更需要治理投票
function proposeCriticalChange(
bytes32 id,
uint256 newValue,
string calldata description
) external onlyGovernance {
// 创建治理提案
GovernanceProposal memory proposal = GovernanceProposal({
id: nextProposalId++,
parameterId: id,
proposedValue: newValue,
description: description,
votesFor: 0,
votesAgainst: 0,
startTime: block.timestamp,
endTime: block.timestamp + 7 days,
executed: false
});
proposals.push(proposal);
}
}
这个设计的精妙之处在于：它既保证了日常运营的敏捷性，又保留了社区对重大决策的最终控制权。
3.3 核心策略二：用”负反馈”机制维持系统稳定
MakerDAO 有一个非常独特的机制——当系统出现风险时，MKR 持有者会被”征税”来填补窟窿。
系统发生不良贷款 → 清算不足 → 需要填补差额
↓
铸造新的 MKR 代币
↓
稀释现有 MKR 持有者
↓
MKR 价格下跌 → 持有者遭受损失
↓
持有者被迫关注治理、参与决策
↓
形成"负面激励"——不参与治理的代价更高
这不是一个”鼓励参与”的正面激励，而是一个“不参与的代价”机制。从行为经济学角度看，损失厌恶（loss aversion）比收益吸引更有驱动力。
3.4 核心策略三：治理委员会的专业化
2021 年，MakerDAO 成立了治理委员会（Governance Committee），由 7 名经过筛选的专业人士组成。他们的职责是：
- 处理日常治理事务
- 在紧急情况下快速响应
- 作为 MKR 持有者和系统之间的”缓冲层”
MKR 持有者（分散、非专业）
↓ 委托投票权
Governance Committee（专业、集中）
↓ 管理
Risk Parameters & System Operations
这个设计听起来有点”精英主义”，但它解决了一个实际问题：金融系统的参数调整需要专业知识，不是每个代币持有者都有时间学习。
3.5 MakerDAO 的代价：治理过于中心化
MakerDAO 的模式也有明显的代价。批评者指出：
- 投票参与率长期偏低——大多数 MKR 持有者选择”委托投票”给治理委员会，自己完全不参与
- 委员会的权力过大——7 个人控制了数十亿美元的系统
- 改革阻力极大——既得利益者（委员会成员、大额持有者）阻碍改变
四、 Uniswap：从”无代币治理”到代币治理的曲折路
Uniswap 的故事更加曲折，也更接近大多数 DAO 的现实困境。
4.1 Uniswap 的治理历程
2018-2020: 无代币治理阶段
├── 核心开发者（Hayden Adams 等）主导决策
├── 无正式治理机制
└── 社区通过讨论和反馈影响方向
2020-2023: 代币治理探索阶段
├── UNI 代币发行（2020年3月）
├── 治理合约上线
├── 大量提案提交
└── 投票参与率极低（普遍低于 5%）
2023-至今: 务实调整阶段
├── 聚焦少数关键提案
├── 强化生态基金和开发人员激励
└── 接受"有限治理"的现实
4.2 Uniswap 面临的经典困境
Uniswap 早期遇到了几乎所有 DAO 都会遇到的问题：
困境一：代币分发导致的投票权分散
UNI 代币分发结构：
├── 40% 社区成员（按历史使用情况空投）
├── 35% Uniswap 团队和投资者（4年线性释放）
├── 15% 核心贡献者
└── 10% 储备金
问题：
- 早期持有者大部分选择"卖出"而非"参与治理"
- 实际参与投票的钱包数量远低于代币供应量
- 出现了"治理套利"——有人专门买入代币投票，投完就卖
困境二：提案质量参差不齐
Uniswap 治理平台上出现过各种提案：
| 提案类型 | 例子 | 结果 |
|---|---|---|
| 技术参数调整 | 修改手续费分配 | 通常通过 |
| 生态基金分配 | 资助新项目 | 有争议 |
| 道德/方向性提案 | “Uniswap 应该关注环保” | 没有约束力 |
| 个人利益提案 | “给我的项目拨款” | 被社区驳回 |
问题在于：大量低质量提案淹没了重要提案，消耗了社区的注意力。
4.3 Uniswap 的务实调整
经过几年的试错，Uniswap 逐渐形成了一套更务实的治理方式：
策略一：聚焦核心提案，降低噪音
// Uniswap 治理合约的关键设计
contract UniswapGovernor {
// 提案门槛：需要一定数量的代币才能提交
uint256 public proposalThreshold = 100_000e18; // 10万UNI
// 投票持续时间
uint256 public votingPeriod = 17280; // 约4天
// 执行冷却期：防止恶意提案快速执行
uint256 public votingDelay = 45840; // 约1天
// 只有达到法定人数的提案才能进入执行阶段
uint256 public quorum = 40_000_000e18; // 4000万UNI
}
这些参数设计的目的是：让严肃的提案有足够的时间被讨论，让恶意的提案没有机会快速执行。
策略二：接受”有限治理”的现实
Uniswap 的核心团队逐渐明确了一个认知：不是所有事情都需要社区投票。
需要社区投票的：
├── 资金库大额支出
├── 核心协议的重大变更
└── 治理规则本身的修改
不需要社区投票的：
├── 日常 bug 修复
├── 标准参数的微调
├── 已授权的发展活动
└── 社区反馈收集（非约束性）
这个区分非常重要。它避免了”治理过度”——什么小事都要投票，最后什么事都投不了。
策略三：用”治理代币”绑定长期利益
Uniswap 的代币分发设计有一个关键特征：团队和投资者的代币有 4 年解锁期。
时间线：
Year 0: 团队持有 100%，社区持有 40%
Year 1: 团队解锁 25%，社区仍持有 40%
Year 2: 团队解锁 50%，社区仍持有 40%
Year 3: 团队解锁 75%，社区仍持有 40%
Year 4: 团队解锁 100%，社区仍持有 40%
效果：
- 团队长期利益与协议价值绑定
- 短期投机者无法主导治理
- 社区通过空投获得"历史贡献"的认可
五、 可持续 DAO 生态的五大实用策略
基于 MakerDAO 和 Uniswap 的经验教训，我们可以提炼出一些可操作策略：
策略一：设计”分层治理”，不是所有事都要投票
治理层级设计：
┌─────────────────────────────────────────────┐
│ Layer 3: 社区投票（重大决策） │
│ • 协议核心参数修改 │
│ • 大额资金支出 │
│ • 治理规则变更 │
├─────────────────────────────────────────────┤
│ Layer 2: 委员会决策（专业决策） │
│ • 日常风险参数调整 │
│ • 紧急情况响应 │
│ • 技术开发优先级 │
├─────────────────────────────────────────────┤
│ Layer 1: 核心开发团队（执行层） │
│ • Bug 修复 │
│ • 标准功能开发 │
│ • 已批准提案的执行 │
└─────────────────────────────────────────────┘
关键原则：让合适的人做合适的决策，不要用社区投票解决所有问题。
策略二：降低参与门槛——让投票变得简单
很多 DAO 的投票界面复杂得让人望而却步。一个可持续的 DAO 应该做到：
1. 提案摘要可视化
不要只给一个链接让社区自己看 50 页文档。应该提供：
提案摘要卡片：
┌──────────────────────────────────────┐
│ 提案 #42: 调整 ETH 抵押率 │
├──────────────────────────────────────┤
│ 当前值: 150% │
│ 建议值: 175% │
│ 影响: 更高抵押率意味着更安全的系统 │
│ 但也会降低借款人的杠杆 │
├──────────────────────────────────────┤
│ 支持理由: 3 条 │
│ 反对理由: 2 条 │
│ 专家意见: Risk Group 建议通过 │
├──────────────────────────────────────┤
│ [赞成] [反对] [弃权] │
└──────────────────────────────────────┘
2. 委托投票机制
让专业的人替不专业的人投票：
// 委托投票合约示意
contract Delegation {
mapping(address => address) public delegates;
// 用户可以将投票权委托给任何人
function delegate(address delegatee) external {
delegates[msg.sender] = delegatee;
}
// 获取最终投票权
function getVotes(address account) internal view returns (uint256) {
address delegate = delegates[account];
if (delegate != address(0)) {
return BalanceOf[delegate]; // 委托人的投票权加到被委托人
}
return BalanceOf[account];
}
}
MakerDAO 的大多数 MKR 持有者都选择了委托投票给治理委员会，这实际上是一种”代议制民主”。
策略三：建立”执行闭环”——投票结果必须有回响
这是最容易被忽视的一点。投票完之后必须有人执行，而且要让社区看到执行结果。
完整的治理闭环：
提案提交 → 社区讨论 → 投票 → 结果公示 → 链上执行 → 效果评估
↑ │
└──────────────────────── 反馈循环 ←───────────────────────┘
Uniswap 早期的问题就是缺少这个闭环。很多投票通过后，没有人跟进执行，社区慢慢就不信任这个流程了。
具体的执行机制可以是：
// 执行跟踪合约
contract GovernanceExecution {
struct ExecutionRecord {
uint256 proposalId;
uint256 executedAt;
address executor;
bytes32 txHash;
bool success;
}
mapping(uint256 => ExecutionRecord) public executions;
function executeProposal(uint256 proposalId) external {
require(isPassed(proposalId), "Proposal not passed");
require(!executions[proposalId].executedAt > 0, "Already executed");
// 执行提案逻辑
bytes memory callData = getProposalCallData(proposalId);
(bool success, ) = targetContract.call(callData);
// 记录执行
executions[proposalId] = ExecutionRecord({
proposalId: proposalId,
executedAt: block.timestamp,
executor: msg.sender,
txHash: block.hash,
success: success
});
emit ProposalExecuted(proposalId, success);
}
}
策略四：用激励机制引导参与，但要小心副作用
正向激励：
激励类型：
├── 投票奖励：参与投票获得代币
├── 提案奖励：提出并被通过的提案获得奖励
├── 声誉系统：长期参与者获得更高地位
└── 治理岗位：关键角色获得定期报酬
但要警惕”治理套利”：
治理套利行为：
- 短期买入代币 → 参与投票 → 投票后卖出
- 结果：投票率"看起来"很高，但参与者不是真正的社区成员
- 影响：治理被投机者主导，长期社区利益受损
如何防范：
// 快照机制防止治理套利
contract SnapshotGovernance {
// 在投票开始前确定投票权
uint256 public snapshotBlock;
function setSnapshot() external {
snapshotBlock = block.number - 100; // 提前100个区块确定
}
// 投票时检查快照时的余额
function vote(uint256 proposalId, uint8 support) external {
require(block.number <= snapshotBlock + 1000,
"Snapshot period expired");
uint256 votes = getBalanceAtSnapshot(msg.sender, snapshotBlock);
require(votes > 0, "No voting power");
// 记录投票
recordVote(proposalId, msg.sender, support, votes);
}
}
Snapshot 机制让投票权基于某个时间点的持仓，而不是投票时的持仓。这样治理套利者无法通过”买入-投票-卖出”来影响结果。
策略五：接受”不完美治理”，保持迭代
没有一个 DAO 的治理是完美的。Uniswap 和 MakerDAO 都在不断调整自己的机制。
关键心态：治理是一个持续迭代的过程，不是一劳永逸的设计。
迭代循环：
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 实施 │ → │ 观察 │ → │ 反馈 │ → │ 调整 │
│ 治理 │ │ 效果 │ │ 收集 │ │ 机制 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
↑___________________________________________│
六、 常见陷阱：这些坑我帮你趟过了
陷阱一：过度民主——什么都要投票
很多 DAO 的创始人一开始想做一个”完全去中心化”的系统，于是把所有事情都放到投票上。结果：
- 投票频率过高，社区疲劳
- 重要提案被淹没在琐碎提案中
- 决策效率极低，错失机会
正确做法：区分”必须投票”和”可以决策”的事项，建立清晰的治理边界。
陷阱二：代币集中——少数人控制一切
如果代币过度集中在少数钱包（比如团队、投资人、巨鲸），那么”社区治理”就是名义上的。
代币集中度指标：
- 前10大持有者控制 > 50% → 高风险
- 前10大持有者控制 30-50% → 中等风险
- 前10大持有者控制 < 30% → 相对健康
防范措施：
- 合理的代币分发设计
- 长期解锁机制
- 对巨鲸投票权设置上限（如 Voting Escrow 机制）
陷阱三：治理疲劳——提案太多，没人看得完
很多 DAO 的治理平台堆满了提案，真正重要的被埋没。
解决思路：
- 设立提案审核门槛（需要一定数量支持者才能进入投票）
- 定期清理过期提案
- 用标签和分类帮助社区快速定位重要提案
陷阱四：执行脱节——投票了但不执行
这是最致命的陷阱。一旦社区发现投票结果不会被执行，信任就彻底崩塌了。
防范机制：
- 链上自动执行（通过智能合约）
- 明确的执行时间表
- 执行失败的应急方案
陷阱五：忽视法律风险——治理合规性
不同司法管辖区对 DAO 的法律地位认定不同。忽视这一点可能导致：
- 治理决策被认定为非法
- 核心贡献者面临法律责任
- 平台被封禁
建议：
- 了解所在地区的法律框架
- 考虑设立法律实体（如瑞士基金会、新加坡协会）
- 咨询专业律师
七、 写在最后：DAO 治理没有标准答案
回到最初的问题：为什么有的 DAO 投票冷场、成员出走，有的却能持续运转？
答案不是某一个神奇的设计，而是一系列持续优化的结果。
MakerDAO 用了十年时间，经历了多次危机和改革，才形成了现在的治理结构。Uniswap 也在几年的试错中逐渐找到了自己的节奏。
可持续的 DAO 治理有几个共同特征：
- 分层决策——不是所有事都要投票
- 降低门槛——让普通人也能参与
- 执行闭环——投票结果有回响
- 持续迭代——接受不完美，持续改进
- 利益绑定——让参与治理的人有长期激励
最后，用一个简单的类比来总结：
DAO 治理不像建造一座桥——设计好蓝图，按图施工，完工。
DAO 治理更像培育一座花园——你需要持续浇水、施肥、修剪、除草。没有一劳永逸的设计，只有日复一日的维护。
那些”冷场”和”出走”的 DAO，往往是在某个环节停止了维护。而那些持续运转的 DAO，不是因为起点有多高，而是因为有人一直在浇水。
如果你正在构建或参与一个 DAO，不妨问自己几个问题：
- 我的社区里，有多少人在真正参与治理？
- 投票结果有没有被认真执行？
- 普通持有者能理解并参与决策吗？
- 我们的代币分发是否过于集中？
这些问题没有标准答案，但诚实地回答它们，比复制任何”最佳实践”都更有价值。
毕竟，DAO 的本质是人，不是代码。代码可以部署，但信任需要经营。