何时审计智能合约：2026年安全时间线

大多数团队将审计视为日历上的一个日期。一份在主网上线前两周交付的 PDF 文件，就能把未经审计的代码库变成经过审计的代码库。复选框勾选。推文发布。交付上线。

这种思维模式正是协议被掏空的原因。

智能合约审计 不是一个里程碑，而是一系列贯穿整个生命周期的决策——关于何时引入对抗性审查、审查频率以及审查深度。时机把握不当，你可能会为一个 6 万美元的审计买单，审查的却是你早已删除的代码；或者，你会在无法推迟的上线前 72 小时发现一个严重问题。

以下是我们在非公开场合会告诉创始人的时间线，供他们思考何时开始考虑安全问题。它偏向于 Web3，因为那是我们的工作领域，但其底层逻辑——深度防御，分散在时间线上——与指导任何严肃软件工程的同一套安全 SDLC 传统（NIST SSDF、Microsoft SDL、OWASP SAMM）一脉相承。

生命周期六大阶段

每个协议都会经历相同的六个阶段，无论团队是否为此做了规划。

架构与设计。白皮书、机制规范、代币经济学、威胁模型、信任假设、可升级性策略。此阶段的风险是设计层面的：被破坏的经济不变量、未经认证的信任边界、尚未意识到的预言机依赖。

开发。Solidity、Rust、Cairo 或 Move；内部库；集成脚手架。风险转向实现层面：遗漏检查、偏离规范、单独看没问题但组合起来却可能灾难性爆发的 bug。

测试与内部审查。单元测试、模糊测试框架、不变量测试套件、内部审查、开发网暴露。危险在于你未测试的部分——没人走过的分支，没人写下的不变量。

上线前与外部审计。代码冻结、手动审计、修复审查、形式化验证（如适用）、测试网、公开悬赏。这是发现关键问题的阶段，同时也是日程压力成为“无论如何都要上线”决策最大促成因素的阶段。

上线。主网部署，设有上限、多重签名、时间锁的保护性启动。风险是操作层面的：部署错误、密钥管理、上线第一天的预言机暴露。

上线后。监控、事件响应、漏洞奖励、升级、定期审计、治理。新的漏洞来自环境变化、MEV、预言机变更，以及——最常见的是——来自你自己后续的代码变更。

智能合约协议承载着普通软件所没有的三种压力。不可变性：大多数 bug 无法静默修复。可组合性：当集成方以你未曾预料的方式使用你时，你的假设就会被打破。承载资产价值风险：攻击者能在成功利用的几分钟内在链上获得现金回报。这三个属性决定了以下每个阶段都比其 SaaS 对应阶段更紧凑、更昂贵。

做什么，以及何时做

正确的框架是分散在时间轴上的深度防御。没有单一活动能保护一个协议。每项活动都有一个阶段，在该阶段执行比在任何其他阶段都显著更具成本效益。

在架构与设计阶段，你需要进行威胁建模——针对通用组件采用 STRIDE 方式；针对特定 Web3 场景（如桥、预言机、MEV 暴露和治理攻击路径）采用 Web3 特有方式。你需要进行一次架构审查，由资深研究员阅读白皮书和合约布局，而非代码，并生成信任边界图、不变量目录和攻击树草图。对于 DeFi，你需要进行经济和博弈论审查——借贷曲线、AMM 数学、清算机制、重基础资产和激励代币都有其失效模式，这些模式在代码中看起来正常，但在市场压力下却可能灾难性爆发。并且，你需要写下你的不变量。提前阐明“必须始终为真”的条件，是后续进行形式化验证和不变量模糊测试的基础。

在开发阶段，静态分析在 CI 中运行。对于 Solidity 使用 Slither 和 Aderyn，对于 Solana 使用 Soteria，配置为在发现关键问题时阻止合并请求。同行评审使用以安全为中心的检查清单。面向属性的单元测试针对你在第一阶段写下的不变量。扫描依赖项，固定 OpenZeppelin 版本，并关注编译器公告——Curve 7300 万美元的 Vyper 编译器漏洞利用 是一个永久提醒，表明你的工具链（而不仅仅是你的源代码）也在审查范围内。CI 中的多工具覆盖可将检测率从（单一工具的）大约 40-60% 提高到 75-90%。

在测试与内部审查阶段，你需要进行模糊测试。Echidna、Foundry 的不变量测试、Medusa。目标是达到 90% 以上的分支覆盖率，并且每个关键状态机至少有一个命名的不可变属性。对于数学密集型组件——AMM 曲线、借贷健康检查、ZK 电路、桥接会计——使用 Certora、Halmos 或 Kontrol 进行形式化验证是物有所值的。变异测试（Olympix）可以证明你的测试套件是否真的能捕获回归——这正是导致 Ronin 2024 年 8 月升级配置错误（损失 1200 万美元）得以部署的确切差距。然后运行内部红队：让不会进行外部审计的工程师以攻击者的身份审查代码。

在上线前的外部审计阶段，重头戏发生——由外部公司进行手动审查或竞争性审计竞赛。在适用的情况下叠加专业审查：预言机集成、MEV 暴露、治理、密钥管理、代理和可升级性。如果你有链下基础设施（前端、RPC、签名者设置、部署脚本），对其进行渗透测试。在完成修复后，在进入生产环境之前，运行一次修复审查或重新审计。

在上线阶段，你需要保护发布过程。存款上限、保守参数、应急开关、暂停守护者、管理操作的时间锁。每个构造函数参数、每个初始化器、每个代理管理员都要经过两次验证——Wormhole 的 3.26 亿美元和 Ronin 的 1200 万美元损失都源于未初始化的路径。实时监控从第一天开始，而不是第三周才启动。

上线后，你需要运行一个安全计划。持续链上监控，带有自动暂停 Hook。与 TVL 规模匹配的漏洞奖励。由升级、新抵押品、新链触发的定期审计。每六到十二个月进行一次红队演练。对任何涉及参数、预言机或资金库的提案进行治理审查。

外部审计时间线

这是大多数团队在日历方面犯错的地方。以下是 2026 年市场实际的情况。

前置时间

顶级私人审计公司——OpenZeppelin、Trail of Bits、Consensys Diligence、Spearbit、Cantina、Zellic、ChainSecurity、Halborn、Sigma Prime、Certora、Runtime Verification——从咨询到启动的预约队列通常为四到十二周。精英专属的审计任务经常需要数月时间。

实用的经验法则：在目标审计开始前大约三个月联系两到三家公司。在代码冻结前六到八周锁定一个时段，即使范围尚未 100% 确定。对于第四季度的主网上线，最迟在第二季度末开始与公司交谈。

竞争性平台——Code4rena、Sherlock、Cantina、CodeHawks——没有同样的队列概念。它们以固定的一到四周的竞赛窗口运行，你需要将项目安排进去。这对于那些通过惨痛教训才了解到审计前置时间的团队很有吸引力，但你仍然需要一到两周的赛前准备时间来划定范围、记录文档并让审核员（wardens）上手。

时长与定价

“按代码行数定价”的模式已经过时。现代审计师根据逻辑密度和工程师周数定价。来自治理资助项目的公开参考（Arbitrum 研发集体流程、保留服务披露）给出了相对一致的数字。

一个简单的 ERC-20 或代币锁仓合约（500 行以下）：一到两名审计师，三天到一周，一级费率约 5k−5k-5k−15k。一个标准的 DeFi 原语（一千到三千行）：两名审计师，一到两周，20k−20k-20k−60k。一个中等规模的 DeFi 协议（约 2500 行，包含新颖逻辑）：两名审计师，四到六周加一到两周的重新审计，200k−200k-200k−300k。一个复杂的多合约、跨链或 ZK 系统：三到四名审计师，四到八周加重新审计，100k−100k-100k−500k+。一个企业级桥或 L1 客户端：四名或更多审计师，两到六个月，500k−500k-500k−2M+。

来自相同来源的公开费率卡：Trail of Bits 和 OpenZeppelin 均报价每工程师周 2.5 万美元（根据 ARDC 申请）。Runtime Verification 报价每周 2 万美元，并有文档化的质量底线，大约每 1000 行代码需要三周。Dedaub 收取每位工程师每天 3500 美元，最少两名审计师。Spearbit 根据团队组成，价格大约在每团队周 3.25 万至 4.8 万美元之间。Quantstamp 的保留服务价格为 13 万美元，对应十个审计周（400 小时，四名审计师）。Certora 2025 年为 Aave v4 进行形式化验证的合约金额为 239 万美元，约合 4.5 个全职人力年。OpenZeppelin 为 Venus 提供的保留服务价格为 55.44 万美元，为期 24 周。

Sherlock 的行业概览将实际价格范围定为：简单代币 5k−5k-5k−15k，标准 DeFi 20k−20k-20k−60k，跨链或 ZK 项目 10 万美元以上。大多数非琐碎的 DeFi 协议会为一次认真的初始审计支付 4 万至 10 万美元，外加 20-30% 的重新审计费用。 有关这些数字的更详细分解，请参阅我们的 2026 年审计定价指南 以及 智能合约审计实际成本 中的审计师工作日计算。

缓冲时间

一个常见且痛苦的错误：将审计安排在与上线同日结束。不要这样做。请预留缓冲时间：

• 对于典型范围，从审计启动到报告交付之间留出两到四周。
• 根据发现结果，从报告交付到修复之间留出一到三周。
• 由同一家公司进行修复审查或重新审计，需要三到七天。
• 使用最终代码（即将部署的版本）在测试网上暴露一到两周。
• 如果预算允许，在上线前的修补后代码上运行一到四周的公开悬赏或审计竞赛。

对于标准 DeFi 协议，计划从审计开始到主网上线之间花费四到八周；对于任何桥级别或财务复杂的项目，则需要八到十六周。如果你的上线推迟，那是正常的业务成本，而非失败。

代码冻结

审计师期望在审计开始时进行代码冻结：一个特定的提交哈希、记录在案的范围，以及团队在审计期间不会进行功能变更的公开承诺。冻结期间允许的操作：文档更新、注释、测试添加。不允许的操作：重构、新功能、范围变更或“顺手”调整。冻结后的每次变更要么会使现有发现无效，要么会浪费审计师的时间去重新审查已经审过的路径。如果你必须在审计期间更改某些内容，请立即沟通，并预期时间表会延误。我们的 审计前检查清单 涵盖了冻结开始前需要锁定的内容。

实际驱动成本的因素

除了代码行数之外的因素：逻辑密度（一个 500 行的 ZK 电路比 2000 行的代币样板代码更贵）、代码库大小、语言溢价（Rust、Move、Cairo 和 Vyper 通常有约 20-30% 的加价，因为审计师池较小）、紧急加价（复杂协议两周的周转时间通常会增加 20-50%）、公司声誉、范围（仅智能合约还是包括前端、RPC、桥中继器、治理用户界面的全栈）、以及文档质量（良好的规范和 90% 以上的测试覆盖率可将最终成本降低 15-25%）。

私人审计 vs. 竞赛审计

私人公司审计：前置时间 4-12 周，持续时间 1-8 周，按工程师周定价，一级费率约 2 万至 2.5 万美元/周，二至四位指定的审计师，深入而系统的覆盖，与工程师实时对话，正式报告。最适合架构敏感的代码、新颖的逻辑，以及任何需要与工程师交谈的场景。

竞赛审计：1-2 周的范围划定，然后是 3 天至 4 周的固定竞赛窗口，以奖池定价（2.5 万至 50 万美元以上），30 到 500 多名审核员（wardens），广泛且竞争性的覆盖，验证和评判后发布公开报告。最适合对已经成熟的代码进行实战测试、追求攻击者多样性、发现更难找的问题。

严肃的答案是两者结合。先进行私人审计以获得深度和对话。再进行竞赛以获得广度和对抗多样性。然后是漏洞奖励以获得持续覆盖。以太坊基金会最近在 Sherlock 上进行的 Fusaka 压力测试——一个 200 万美元的竞赛，有 510 多名研究人员参与，发现了四个高严重性问题——是“我们已经在内部审计过了，现在公开试试能不能攻破它”的教科书式案例。

持续性与里程碑式：成熟团队的实际运作方式

一次性审计在安全性上相当于一位六十岁的马拉松运动员每年只做一次体检。它漏掉了两次就诊之间发生的一切变化。

对于一个严肃的 DeFi 协议，推荐的节奏涉及五个接触点。编写大量代码之前的架构审查，生成信任模型、威胁模型和不变量目录（一到两个工程师周）。开发中期检查点，当大约 60-70% 的代码已编写且接口稳定时，尽早发现设计偏差（一到三个工程师周）。冻结代码上的最终上线前审计（重头戏）。修复完成后一到四周内的修复审查或重新审计。部署后的实际部署字节码和配置审计——通常是列表中最便宜的审计，也是大多数团队跳过的那一个。

这种分阶段结构正是 SAMM 的验证实践和 SSDF 的“生产良好安全的软件”组所指出的。这也是 OpenZeppelin 的安全智能合约开发路线图所规定的。我们已将这一思路扩展为一个工程工作流程，详见我们的 深度防御审计手册。

从“事件”到“项目”的转变正在全行业发生。OpenZeppelin 孵化了 Forta，推出了 Defender 作为端到端开发者安全平台；Sherlock 将审计视为一项持续投资而非一次性成本——所有这些都指向同一件事。一个安全项目看起来像这样：CI 集成的静态分析和每次 PR 的模糊测试；将属性测试和不变量作为活文档维护；与安全公司签订每月或每季度的保留合同；从主网上线第一天起就启动漏洞奖励；持续链上监控并自动响应；对任何触及价值承载代码的变更触发审计。

“左移”是将安全检查提前到 SDLC 早期的纪律。在 Web3 中，这意味着 Slither、Aderyn 和 Mythril 在 CI 中作为 PR 检查运行；Echidna 和 Foundry 的不变量测试在合并前测试套件中运行；威胁建模审查作为任何新合约模块的必需步骤；形式化验证与代码编写同步进行，而非事后添加。

经济论点众所周知。NIST 估计，在生产环境中修复漏洞的成本大约是在开发期间修复成本的三十倍。IBM 的“100 倍法则”——设计修复 1 倍，实现 6 倍，测试 15 倍，发布后 100 倍——被广泛引用，同时也因其原始来源薄弱而受到广泛批评，但其定性模式得到了所有现代类似案例的支持。Veracode 发现平均修复时间从 2010 年的 59 天增长到 2019 年的 171 天。HackerOne 的案例研究表明，合并前修复通常需要 30 分钟，而生产环境中则需要 15 小时。在智能合约领域，乘数效应更为显著，因为生产环境是不可变的、对攻击者可见且通常持有承载资产。在设计中修复的 bug 只需花费研究人员数小时的成本。同样的 bug 在被利用后修复，可能让整个协议付出代价——请参阅我们 2025 年漏洞利用教训 文章中的案例研究。

而审计只是其中一个层面。一个现代的 Web3 安全堆栈包含：默认安全的库（OpenZeppelin Contracts、Solady、Solmate）；CI 中的静态分析（Slither、Aderyn）；基于属性和不变量的测试（Foundry、Echidna、Medusa）；形式化验证（Certora、Halmos、Kontrol、K）；手动外部审计（私人及竞赛）；漏洞奖励（Immunefi、Cantina、HackenProof）；运行时监控（Forta、Defender、Hypernative、Hexagate）；自动事件响应（暂停守护者、断路器、时间锁）；以及治理加固（多签、时间锁、链下签名方案）。跳过其中任何一项，你的“已审计”协议仍然防御不足。我们在 审计 vs. DeFi 保险 中详细比较了审计和保险层面。

2023 年 3 月的 Euler Finance 漏洞利用（1.97 亿美元损失）是一个典型案例。Euler 在上线前曾经过六家公司的审计。但 donateToReserves 函数——在发布一年后作为修复另一个错误的补救措施添加的——仅由 Sherlock 的审计师（WatchPug）在 2022 年 7 月审查过一次。导致 1.97 亿美元闪电贷攻击得以发生的缺失健康检查未被发现。教训不是“Euler 跳过了审计”。教训是：没有对后续代码变更进行持续覆盖的审计会让你暴露在风险中。我们的 审计后安全手册 详细介绍了哪些控制措施可以弥补这一差距。

时机不当的审计：日历错误的真实成本

审计过早。症状：审计期间代码大量变动，审计师标记已不存在的代码中的问题，团队每隔一天就要重新解释上下文，最终报告引用了你已删除的函数。成本：为远低于正确定时审计所能提供的保证程度支付了全部审计费用。重新审计变得不可避免。净浪费约 30-60% 的审计投入。

审计过晚。症状：关键发现结果在上线前几日才到，创始人施加压力要求无论如何先上线再打补丁，仓促修复，重新审计被压缩到周末。成本：要么带着已知的未修复关键问题上线（生存风险），要么推迟上线并承担市场营销和声誉损失。Ronin Bridge 在 2024 年 8 月的升级损失了 1200 万美元，原因是未初始化的 _totalOperatorWeight。静态分析（Olympix）和变异测试本可以捕获它。两者都存在，但均未集成。这 1200 万美元的损失远远超过他们本应在工具上花费的 5k−5k-5k−10k。

一次性心态。症状：协议在上线时被审计，然后运行了 18 个月，期间发布了新的抵押品类型、新的链和新的预言机集成，所有这些都没有经过审计。最终被利用。这种模式是上线后 DeFi 损失的一个重要原因。Euler 是典型案例。

审计表演。症状：选择最便宜的审计，在网站上添加“由 ___ 审计”的徽章，报告中看不到任何修复，范围刻意排除风险最高的合约。真实成本：虚假信心。投资者和用户假设风险已被管理，而实际并未。2024 年超过 22 亿美元的 DeFi 被盗资金中，不均衡地集中在那些审计范围狭窄或浅薄的“已审计”项目上。关于这个故事的投资者视角，请参阅 智能合约审计对投资者尽职调查的投资回报率。

一些时间或范围至关重要的漏洞利用案例：

• Ronin Bridge（6.24 亿美元，2022 年 3 月）：验证者密钥泄露。本身不是智能合约 bug，但多签阈值（5/9）以及未撤销的 Axie DAO 白名单是治理和密钥管理问题，持续的运营安全审查本可以标记出来。“只在上线时检查了一次合约”的心态无法捕捉到这一点。
• Wormhole（3.26 亿美元，2022 年 2 月）：Solana sysvar 账户上缺少签名验证。现代的 Solana 审计实践——Soteria 静态分析、详尽的账户验证清单、对抗性模糊测试——可以捕获这类 bug。当时的审计没有包含这些步骤。我们在 Solana 2026 安全指南 中写了现代检查清单。
• Nomad Bridge（1.9 亿美元，2022 年 8 月）：初始化错误（零默克尔根被接受为有效）在一次常规升级中部署。任何人都可以通过复制攻击交易来重放消息。这是“首次众筹式黑客攻击”。
• BadgerDAO（1.2 亿美元，2021 年 12 月）：前端供应链攻击，不是智能合约 bug。纯智能合约审计无法捕捉到这一点。包含前端、部署管道和操作实践在内的端到端审查本可以发现这个问题。有关更广泛的模式，请参见 Web3 中的供应链攻击。
• Curve Finance（7300 万美元，2023 年 7 月）：Vyper 编译器的一个 bug，破坏了已部署字节码中的 @nonreentrant 功能。再次提醒，你的工具链，而不仅仅是你的源代码，也在审查范围内。

成本曲线，用数字表示：NIST 认为生产环境后的修复成本约为开发期间修复成本的 30 倍。IBM 的“100 倍法则”将设计定位为 1 倍，实现 6 倍，测试 15 倍，发布后 100 倍。IBM 2023 年数据泄露成本报告将全球平均泄露成本定为 445 万美元，美国为 944 万美元。DeFi 特定数据：根据 OpenZeppelin 2024 年的统计，智能合约黑客攻击累计盗窃金额超过 90 亿美元；仅 2024 年就达 22 亿美元。审计定价：从代币的 5k 到复杂桥的 500k 以上——即使是最昂贵的审计通常也低于其保护价值的 1%。完整的 ROI 数学计算请参阅 审计如何提升 Gas 节省和市值。

这种不对称性令人震惊。一次 10 万美元的审计所捕获的问题，否则可能导致超过 1 亿美元的漏洞利用。这是 1000 倍的回报，也是为什么成熟的资金库将审计预算作为经常性运营支出，而非一次性资本支出。

主网上线后：真正重要的时间线

大多数安全文章将上线视为终点线。实际上，这是起跑线。主网是你的代码进入黑暗森林的第一天。

定期审计。 任何持有用户资金的合约变更都需要审查。新的抵押品、新的预言机集成、新的链部署、新的金库策略、新的治理模块——全部在范围之内。对于增量变更，轻量级审查（1-3 个工程师周）就足够了。对于协议版本升级，则需要全面审计。保留服务安排（Venus + OpenZeppelin：55.44 万美元/24 周；Aave + Certora：239 万美元/约 4.5 个全职人力年用于 v4）是严肃协议构建此结构的方式。

持续监控。 从第一天开始部署，而不是作为事后想法。Forta 在去中心化的扫描器网络上运行实时检测机器人，被 dYdX、Balancer 和 Compound 采用，提供免费的公共警报和私有机器人。OpenZeppelin Defender 提供 Sentinel（自定义条件监控器）、Autotask（自动响应）、Forta 集成以及用于交易执行的 Relayer——这是“警报 + 自动暂停”管道的首选集成。Hypernative 是一个基于机器学习的预测平台，涵盖网络、经济、治理和社区威胁。Hexagate 是企业级平台，具有强大的攻击模式检测能力。Chaos Labs 处理经济和参数风险。Tenderly Alerts、Phalcon 和 Spotter 是有用的辅助工具。

一个典型的设置：Forta 检测机器人触发警报 → Defender Sentinel 捕获 → Defender Autotask 通过具有预授权角色的 Relayer 调用受影响合约的 pause()。端到端暂停在几秒钟内完成。

漏洞奖励。 行业领先的平台包括 Immunefi（目前在 330 多个项目中保护着超过 1900 亿美元的用户资金）、Cantina、HackenProof，以及用于链下范围的 HackerOne。根据 Immunefi 框架的规模指导：严重漏洞奖励应与 TVL 成比例，建议将 TVL 的 10% 作为严重漏洞的 最高 赔付额。 理由：智能合约漏洞是一种资产，其公平市场价值是所涉资产价值的一个函数。奖励必须超过黑市价格，黑帽才会选择披露。现实世界的例子：Wormhole 对 Tier 1 提供高达 1000 万美元的 W 代币；大多数大型 DeFi 将严重漏洞上限设为 100 万至 250 万美元，通常采用“节省资金百分比”的公式；较小的协议设置 5 万至 50 万美元的上限，最低保证奖励为 5000 美元以上。运营 SLA：24 小时内响应，72 小时内分类，确认严重性后 14-30 天内支付。

事件响应计划。 在主网上线前就位，而不是在第一次事件之后。一份包含指定值班人员、密钥持有者、交易所联系人和社交媒体处理者的作战室手册。具有记录在册角色、由多签控制的暂停和应急开关权限。一个白帽救援策略：预定义的流程，用于“我们发现了 bug，我们是否要白帽抢跑我们自己的协议？”为 Twitter、Discord、治理论坛准备的沟通模板。用于冻结被盗资金的中心化交易所联系人。在 7-14 天内发布事后分析报告的承诺。

Euler 的事后分析报告（“战争与和平：Euler 2.4 亿美元漏洞利用恢复幕后”）是黄金标准的公开参考。最终从攻击者手中追回约 2.4 亿美元的资金，是链上谈判、公开奖励升级和执法压力相结合的结果。

红队与战争游戏。 对于持有可观 TVL 的在线协议，每六到十二个月进行一次。目标：压力测试 IR 手册，发现配置漂移，识别治理和密钥管理退化。Cyfrin、Trail of Bits、Halborn 和 SlowMist 都提供结构化的此类服务。

断路器。 对于任何 TVL 超过 1000 万美元的协议，这是不可协商的。对移动用户资金的函数应具备可暂停性。暂停守护者角色与升级管理员分离（最小权限原则）。参数变更和升级的时间锁——通常例常变更为 24-72 小时，资金库操作更长。用于管理操作的多签（Safe），配合场外密钥托管和轮换策略。提款限制（限速桥；Wormhole 的“Governor”将关键漏洞的提款上限设为 24 小时内可提取价值的 10%）。

治理。 令人惊讶的是，上线后的大量损失来自治理而非开发。选民冷漠导致治理攻击。闪电贷驱动的提案通过。多签签名者被攻破。参数变更缺少或不充分的时间锁。悄悄改变风险状况的预言机重新配置。像对待合约一样对待治理：审查提案，审计参数变更，监控委托。

一个实用的日历

对于一个计划在第四季度主网上线的典型中等规模 DeFi 协议，安全日历如下所示：

在 T-9 至 T-7 个月，完成白皮书、威胁模型和架构审查（与你的安全合作伙伴的第一次合作）。确立不变量。从 T-7 至 T-4 个月，持续开发，CI 运行 Slither 和 Aderyn，Echidna/Foundry 的不变量测试随着代码一起增长。在 T-5 个月，开始与审计公司对话并预订时段。在 T-4 个月，运行一次中期开发安全检查点和一次内部红队演习。在 T-3 个月，功能冻结；最终模糊测试活动；文档整理；审计前准备状态审查。在 T-2.5 个月，代码冻结和审计启动。从 T-2 至 T-1.5 个月，审计运行——开发人员可用，无功能变更。在 T-1.5 个月，收到审计报告，开始修复。在 T-1 个月，修复审查或重新审计；公开漏洞奖励上线（或对修复后代码进行审计竞赛）；最终测试网暴露。在 T-0 个月，主网上线——受保护发布。上限已设置。监控（Forta + Defender）已激活。作战室手册已在内部发布。

在 T+1 个月，对已部署的字节码和配置进行部署后审计。提高漏洞奖励上限。在 T+3 个月，第一次参数审查。如果无事件发生，放松上限。在 T+6 个月，第一次红队演习。对在此期间部署的任何升级进行定期审计保留或竞赛。持续进行：任何触及价值的代码变更都要审查。每季度调整监控。漏洞奖励随 TVL 扩展。

该时间线假设一切顺利。事情总会出错。在每个阶段都加入缓冲。审计和上线之间的缓冲时间至少要比你认为需要的多出一周。

审计是一个过程，而非一个产品

2026 年会被利用的团队，不会是那些没有审计的团队。他们将是那些审计过晚、审计范围过窄、只审计一次且再也不审计、或者将审计报告视为产物而非对话的团队。能够生存下来的团队将是那些将安全性视为一项贯穿整个生命周期的持续学科——为之设计、为之编码、为之测试、为之审计、为之监控、为之响应——的团队。

一个合理的预算经验法则：对于你计划在发布后 12 个月内持有的每 1000 万美元 TVL，计划在第一年花费大约 5 万至 15 万美元用于安全，分配在架构审查、开发工具、形式化验证（如适用）、手动审计、漏洞奖励和监控上。这比一次中等规模漏洞利用的成本便宜一到两个数量级。而且，它为你买到了比任何单个审计报告都更有价值的东西：一个能够在接下来出现意外时仍能保持安全态势的协议。

何时审计？比你想象的更早。比你想象的更频繁。并且在上线后永远持续。

上面的日历是一个起点。你协议的具体细节——链、复杂性、TVL 轨迹、升级节奏——将塑造它。但是，如果你明确认识到审计是项目中的一个事件，而非项目本身，那么你已经领先于今年大多数会上头条的协议了。

联系 Zealynx

Zealynx Security 审计跨 Solidity、Solana 和新兴 VM 的 Web3 协议。如果你正在计划未来两个季度内上线，并希望讨论时间安排——无论我们最终是否是你审计的合适公司——请联系我们。我们将帮助你规划日历、确定正确的节奏，并避免那些代价高昂的时机不当的审计失败模式。

规划你的审计时间线 →

常见问题：何时以及多久审计一次

1. 我应该什么时候开始预订我的智能合约审计公司？ 对于第四季度的主网上线，最迟在第二季度末开始与公司交谈——大约在你目标审计开始前三个月。顶级公司（OpenZeppelin、Trail of Bits、Spearbit、Cantina、Zellic、ChainSecurity）的预订队列为四到十二周。在代码冻结前六到八周锁定一个时段，即使范围尚未 100% 确定。预订太晚意味着要么推迟上线，要么接受经验较少的公司。

2. 什么是代码冻结，为什么审计师要求这样做？ 代码冻结是对特定提交哈希的公开承诺，在审计窗口期间不会推送任何功能变更。允许文档更新、注释和测试添加；不允许重构、新功能和范围变更。审计师要求这样做是因为冻结后的每次变更要么会使现有发现无效，要么会浪费审计师时间重新审查已经审过的路径。如果你必须在审计期间更改某些内容，请立即沟通，并预期时间表会延误。

3. 私人审计和竞赛审计有什么区别？ 私人审计是来自单一公司的两名至四名指定审计师参与的为期数周的约定，按工程师周定价，一级费率约为 2 万至 2.5 万美元，提供深入系统的覆盖和与工程师的直接对话。竞赛审计（Code4rena、Sherlock、CodeHawks、Cantina）以固定的奖池（2.5 万至 50 万美元以上）运行，在 3 天至 4 周的窗口内吸引 30 至 500 多名审核员，产生广泛的对抗性覆盖。成熟团队会叠加使用它们：先私人审计以获得深度，再竞赛审计以获得广度，最后是漏洞奖励以获得持续覆盖。

4. 什么是受保护启动，为什么它在上线第一天很重要？ 受保护启动是主网部署，从第一个区块起就主动施加了操作约束：存款上限、保守参数、应急开关、暂停守护者和管理操作的时间锁。其目的是缩小任何在审计中幸存下来的 bug 的爆炸半径。Wormhole 的 3.26 亿美元和 Ronin 的 1200 万美元损失都源于初始化路径，而受保护启动本可以在暴露规模扩大之前捕获或至少控制住它们。

5. 上线后的协议应该多久重新审计一次？ 任何触及持有用户资金的合约的代码变更都需要审查。增量变更进行轻量级审查（1-3 个工程师周）；协议版本升级进行全面审计；新抵押品、新链或新预言机集成触发点式审查。成熟协议通过保留服务来构建此结构（Venus + OpenZeppelin：55.44 万美元/24 周；Aave + Certora：239 万美元用于 v4 形式化验证）。计划每 6-12 个月进行一次额外的红队演习，并在上线后一个月内对实际部署的字节码进行部署后审计。

6. 什么是“审计衰减”，我该如何防止？ 审计衰减是时间点审计报告与在线协议之间由于代码变更、依赖项升级、治理操作以及审计关闭后 EVM 层面的变化而逐渐产生的偏差。通过持续的链上监控（Forta、Defender、Hypernative）、运行时不变量强制执行（EIP-7265 断路器）、与 TVL 成比例的漏洞奖励、由升级触发的定期审计以及经过演练的事件响应手册来防止它。预先连接好这些控制措施的协议能从漏洞利用中追回 80-100% 的资金；仅依赖审计的协议几乎无法追回任何资金。

词汇表

查看完整词汇表 →

• 原文链接： zealynx.io/blogs/audit-t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～