[RFC] 治理流程升级：为温度检查设立时效法规

作者: @Eren_Targ5 (Daoplomats)

摘要

本提案旨在为 Uniswap 治理提案设立正式的“时效法规”。具体而言，它规定任何通过“温度检查”（Snapshot 投票）的提案必须在 90 天内进入链上投票。

如果提案未能在 90 天窗口期内进入链上投票，则其温度检查状态将被宣布为“已过期”（或“失效”）。若想继续推进，提案发起人必须重新启动治理流程，发起新的温度检查，以确保社区共识的时效性。

目前，Uniswap 治理在一个连续的周期中运行。与 Optimism 或 Arbitrum 等协议不同，后者利用特定的“治理季度”或“周期”，在周期结束时自然淘汰过时的提案，而 Uniswap 的提案在通过 Snapshot 投票后，理论上可以无限期地保持“待定”状态。

这带来了关键的风险和低效问题：

通过实施 90 天的有效期，我们将使 Uniswap 与行业最佳实践（例如 Sky）保持一致，并确保每一次链上投票都反映 DAO 当前的意愿。

我们建议在官方的 Uniswap 社区治理流程中添加以下条款：

“温度检查的有效性：一次成功的温度检查（Snapshot 投票）自投票结束之日起 90 天内有效。如果未在此 90 天窗口期内提交链上治理提案，则该温度检查被视为已过期。提案发起人必须发布新的温度检查并获得新的社区批准，然后才能进入链上投票。”

状态	定义	所需行动
活跃中	在过去 90 天内通过 Snapshot 投票的提案。	可立即进入链上投票。
失效/已过期	在超过 90 天前通过 Snapshot 投票但尚未提交到链上的提案。	必须重新运行温度检查阶段以验证当前共识。

我们认识到，重大的协议升级或大规模倡议通常需要超过 90 天的开发时间线。然而，治理授权不应是无限期的。

如果提案已通过温度检查，但技术实施时间超过 90 天，提案发起人必须遵循“再确认流程”：

“刷新”投票：提案发起人无需从新的 RFC 重新开始。他们只需发布一个包含最终代码/参数的“再确认 Snapshot”（温度检查）。
为何必要：在 DeFi 领域，6 个月是很长的时间。如果市场条件发生变化（例如跨链桥被黑、新法规出台），1 月份授予的授权在 7 月份执行可能具有风险。
结果：这确保了当最终按下链上投票的“发布”按钮时，社区的同意是新鲜且及时的。

此项变更将使 Uniswap 与其他成熟 DeFi 协议的卫生标准保持一致。

我们已经看到“僵尸提案”混淆了治理流程。

本提案消除了这种模糊性。我们不再依赖提案作者的善意来“重新检查”共识，而是强制执行严格的 90 天有效期，以确保每一次链上执行都代表 DAO 当前的意愿。