大多数项目将智能合约审计视为橡皮图章——在发布前夕进行的，用于向投资者表明你已经做足功课。这种模式在 MiCA 下已经过时。当德国联邦金融监管局 (BaFin)、法国金融市场管理局 (AMF) 或荷兰金融市场管理局 (AFM) 审查你的 CASP 申请时，他们不是在寻找一份证书。他们正在寻找安全治理的证据。审计报告是这些证据的主要部分，如果其背后的代码库一团糟，报告将反映出这一点——或者审计根本就不会发生。
这是我们 MiCA 系列的第四篇文章。如果你还没有阅读 DeFi 协议如何受到 MiCA 影响，请从那里开始。本文将更深入一个层面：不是你是否需要审计，而是如何确保你已为此做好准备，以便审计能够经受住监管审查。
MiCA 为何改变了安全测试规则
MiCA 第 30 条强制要求加密资产服务提供商实施 ICT 风险管理框架。这意味着需要有文件化的政策、持续的测试以及运营韧性的证据——而不是一次性代码审查。于 2026 年 1 月生效的《数字运营韧性法案》(DORA) 在所有在欧盟运营的金融实体中强化了这一点。根据 DORA，威胁主导的渗透测试和 ICT 第三方风险管理不再是成熟安全程序的可选功能。它们是义务。
这实际上意味着：安全测试已从“最佳实践”变为“监管要求”。国家主管当局现在正在进行监督审查和现场检查。他们要求提供文档。他们要求提供审计历史。他们询问你的事件响应流程。如果你对其中任何一个问题的回答是“我们找人看了一下”，那么你就有问题了。
你随 CASP 申请提交的审计报告需要清晰、最新，并由一个实际为审查而准备的代码库支持——而不是审计员需要逐行逆向工程的代码库。
使代码库具备审计就绪的五件事
审计就绪不是一个复选框。它是一种代码库的状态。以下是它的实际表现。
你的头脑之外还能存在的文档。每个合约函数中的 NatSpec 注释。一份书面的协议意图文档，解释系统应该做什么，它做了哪些假设，以及有哪些边缘情况。显示组件如何连接的架构图。这不是官僚主义——这是审计师理解你的系统的方式，而无需花费 20 小时的计费时间来提问。高级审计师每小时收费超过 500 美元。他们花在弄清楚你的代码应该做什么的每一小时，都是他们没有花在发现漏洞上的时间。监管机构要求提供相同的文档也是出于同样的原因：他们需要理解你的系统以评估其风险。如果你的意图只存在于你的头脑中，那么它就无法审计。
证明你的假设的测试覆盖率。在审计员接触你的代码之前，你应该有 Foundry 或 Hardhat 单元测试覆盖你的核心逻辑路径，以及不变量和模糊测试，以证明你的协议在对抗条件下表现正确。在没有有意义的测试覆盖率的情况下进行审计，表明你没有严格思考自己的假设。审计师会发现这个漏洞，并且在审计过程中解决它会让你付出时间和金钱。根据 MiCA 的 ICT 要求，能够证明你已经测试过自己的系统是监管机构期望的证据链的一部分。
职责分离的代码。将业务逻辑、访问控制、会计和状态管理混合到单个 2,000 行文件中的单一合约更难审计和理解——这意味着漏洞在其中隐藏的时间更长。清晰、模块化的代码，具有单一职责的合约和清晰定义的接口，使审计师的工作变得可行。审查你的技术文档的检查员应该能够追踪用户操作在你的系统中的流程，而无需博士学位级别的 Solidity 知识。
诚实的已知问题日志。每个代码库都有团队已经知道的不完美之处——Gas效率低下、理论上可能但经济上不切实际的边缘情况、在时间压力下做出的设计权衡。记录它们。写下你知道什么，你为什么做出这个决定，以及剩余风险是什么样子。这与审计师和监管机构建立了信任，因为它表明你的团队对系统进行了批判性思考。在监督审查中，你可能做的最糟糕的事情是让检查员发现一个你已经知道但从未披露的问题。
在请求报价之前定义范围。在接触审计师之前，了解哪些内容在范围内。列出每个合约、每个外部依赖、每个集成点。提供确切的提交哈希。解释自上次审查以来发生了什么变化。未定义的范围会导致报价虚高，因为审计师会为不确定性定价。当范围蔓延将一个为期四周的审计变成一个为期六周的审计时，它也会导致时间浪费。对于 MiCA 而言，能够定义自己的范围告诉监管机构你了解自己的系统边界——这本身就是运营成熟度的标志。
没人讨论的时间线问题
MiCA 的全面实施不是即将到来——它已经到来。欧盟各国主管当局正在积极处理 CASP 许可证申请，发放有条件授权，并开始对已获许可的实体进行监督周期。你可以将合规性视为未来问题的窗口已于 2024 年末关闭。
现在才开始考虑审计的项目已经落后了。等待律师敲定申请后再与安全公司合作的项目正在犯一个将耗费数月时间的错误。对一个合理复杂的协议进行高质量审计需要四到八周——如果代码库尚未准备好，则需要更长时间。加上修复时间，加上重新审查。你现在距离拥有一份可靠的审计报告还需要三到四个月。如果你的 CASP 申请没有提供审计报告，你将收到国家主管当局的信息请求，这会暂停你的申请计时。这不是假设。
立即开始审计准备工作。整理你的文档，编写你的测试，定义你的范围。许可队列不会等你是否准备好。
为投资者审计 vs. 为监管机构审计
投资者希望从审计中获得的东西与监管机构希望获得的东西之间存在着有意义的差异。
投资者想要一份干净的报告。他们希望看到一家可信的公司审查了你的合约，并且没有发现任何灾难性的问题。报告主要是一个二进制信号。
监管机构想要过程证据。他们希望看到安全是你的组织内部持续的实践，而不是一次性事件。他们想知道谁拥有安全决策权，你如何处理事件，你如何管理对生产合约的更改，以及你的测试频率是怎样的。对于国家主管当局来说，一个只有一份干净审计报告但没有周围安全基础设施的项目，比一个有发现和修复报告但有文件化的治理流程的项目更令人担忧。
为符合 MiCA 要求的审计做准备，不仅仅是让代码正确。它还涉及建立实践和文档，以表明你拥有安全职能，而不仅仅是安全证书。审计是输出。其背后的过程才是监管机构实际评估的。
Zealynx 在完整审计前提供的服务
我们在完整审计开始前，作为一项独立的服务进行审计准备评估。我们会审查你的文档、测试覆盖率、代码结构和范围定义，并准确告诉你需要修复什么，以便审计能够为你的 CASP 申请生成你所需的清晰、可靠的报告。这并非第二次审计——它是让审计有效的准备工作。
如果你正面临 MiCA 许可截止日期，并且不确定你的代码库是否已准备就绪，那么你可能做出的最糟糕的决定就是在审计过程中才发现问题。现在就发现，修复它，然后做好准备进行审计。
在 zealynx.io 请求审计或准备评估。 许可队列不会等待任何人。
