审计报告能证明什么:通过审计和不会被黑是两回事
审计报告记录的是审计方在指定范围和版本下查到或没查到的问题,不是"项目安全"的保证——管不了范围外的代码,也管不了私钥握在谁手里。Euler Finance 被黑1.97亿美元、Merlin 过审当天被清空,两案例拆开审计边界,附自查表。
先说结论
6 条- 审计报告记录的是审计方在指定范围、版本和方法下查到或没查到的问题,不是"这个项目安全"的保证——范围外的功能、审计之后的代码变更,报告完全管不到。
- 2023 年 3 月 13 日,Euler Finance 被黑 1.97 亿美元,问题出在 donateToReserve 函数:这段代码不在 Omniscia 早期审计的范围内,但已由 Sherlock 在 2022 年 7 月的 eIP-14 专项审计里查过,双方都没查出它漏了一次关键的健康检查,隐患在系统里躺了约 8 个月。
- 2023 年 4 月 26 日,zkSync 生态 DEX Merlin 通过 CertiK 审计后,公售开启约 12 小时即被清空约 182 万美元 LP 资产;问题出在团队可控的 feeTo 地址能把 LP 代币提到近乎清空的权限设置上——这项权限其实写进了 CertiK 的报告,据 crypto.news 报道,CertiK 事后承认自己没有把它摆到足够显眼的位置。
- 审计费由项目方一方付给审计机构,公开渠道通常没法确认项目方是否还委托过其他机构、是否只挑了结论更有利的一份对外发布——这道信息缺口本身就是审计报告的局限之一。
- 链上能核对的是报告写的合约地址、commit hash是否对得上当前部署的字节码;核对不了的是私钥和多签背后是不是同一伙人、团队有没有真按建议修复、有没有另一份没被公开的报告。
- 拿到一份审计报告,先翻到"范围"(scope)那一页,不看结论页——报告说了什么不重要,报告没说什么,才是要紧的部分。
钱从哪来到哪去
FLOW- 钱从哪来
- 项目方主动付费购买审计服务,费用没有统一标准——代码量、是否叠加自动化扫描或竞赛制审计、机构本身的定价差异都很大,一般在合约上线前打给审计机构
- 钱到哪去
- 钱进审计机构的账户;换来的报告展示给潜在用户和投资人看,用来换取上线后的资金流入与信任
审计费是项目方一方出的,为这份报告买单的却是后来看着"已通过审计"这几个字做决策的用户——公开渠道通常没法排除项目方还委托过别的机构、只是没挑那份不好看的结论公开这种可能性。这道信息缺口,是审计报告局限性的一部分。
链上能看到什么,看不到什么
CHAIN能看到
- 报告里写的合约地址和 commit hash(或版本号),能不能对上链上当前部署的字节码——用区块浏览器的"Verify & Publish"页面自己比对即可
- 报告"范围"(scope)章节列出的文件和合约清单,列表之外的部分默认没被审查过
- 报告发布日期和合约最后一次升级、迁移的时间,谁先谁后,这两个时间戳都公开可查
- 如果合约是可升级代理,当前的实现(implementation)合约地址是不是报告里写的那一个
看不到
- 项目方是不是同时找了几家机构审计、是不是只挑了结论更有利的那份公开——链上和报告都不会告诉你有没有一份"落选"的报告
- 私钥、多签签署人背后是不是同一伙人控制,这类操作安全通常不在审计范围内,链上更看不到
- 团队有没有真按审计建议修复,还是发完报告之后代码又悄悄改回去——除非逐笔比对每一次升级的 diff,很难第一时间发现
- 审计员本身有没有认真读代码、跟项目方有没有利益关联,这类审计机构自身的可信度不写在报告里,得看这家机构过去的历史战绩
本页目录
2023 年 3 月 13 日,Euler Finance 的合约代码已经被审计机构检查过、拿到了”通过”的结论。同一天,一个函数被人用闪电贷调用了一次,十几分钟内,1.97 亿美元从协议里消失。审计报告(audit report),是第三方安全机构对智能合约代码做的一次专业审查,输出一份写明检查范围、发现问题与严重程度的文档。它记录的是审计方在指定范围、版本和方法下查到或没查到的问题,不是”这个项目往后都安全”的保证。这两句话中间的落差,才是真正该看懂的部分。
审计报告本来想回答什么问题?
审计报告要回答的问题很窄:审计方在这份代码里、用这套方法,查到过什么、没查到什么。不是这个项目靠不靠谱,不是团队会不会跑路,甚至不是这份代码明天会不会被改——把它当成后面这几件事的答案,从一开始就问错了问题。
审计员实际读的是什么
审计员拿到的是项目方指定的一份代码,通常是某个 commit(代码提交记录)或某个版本号锁定的快照。工作内容是逐行读这份代码,对照重入攻击、整数溢出、权限校验缺失、逻辑漏洞这几类已知手法去找问题,有的机构还会用自动化工具扫描已知的漏洞模式做补充。查完之后,把发现的问题按严重程度分级——严重、高、中、低——写进报告,项目方修复后再复核一遍,最终报告里会标注哪些问题”已修复”、哪些”项目方确认接受风险、不修复”。
报告最后写的是”通过”还是”发现问题”
多数审计报告不会写”通过”或”不通过”这种二元结论,写的是”发现 X 个严重问题、Y 个高危问题,均已修复”这类清单。市场上流传的”过审”,其实是营销团队把这份清单简化成的一句话——报告本身很少这么说。一份写着”零严重问题”的报告,记录的仍然是”在这个范围、这个版本、这套方法下没查到已知类型的严重漏洞”,范围之外的代码,这份报告一个字都没提。
审计费谁出的,这笔钱怎么影响报告?
审计费由项目方一方出,买的是审计员的时间和一份带机构署名的报告——这笔钱怎么花、报告要不要公开,决定权都在付钱的一方手里。
项目方付钱,买的是审计员的时间和署名
审计不是免费服务。项目方主动联系审计机构,谈好检查范围和费用,一般在代码审查开始前或完成后打给对方。费用没有统一标准,代码量、是否叠加自动化扫描或竞赛制审计、机构本身的定价都会拉开差距。这笔钱买到的是审计员在约定时间内的工作,和最后那份报告上的机构署名。
**审计员的客户是项目方,不是后来看报告做决策的用户。**这不必然导致审计员放水——多数审计机构靠专业信誉吃饭,砸招牌的代价很高。但客户关系决定了一件事:要不要把报告公开、公开哪一份,决定权在付钱的那一方手里。
有没有另一份没公开的报告,你判断不了
项目方理论上可以同时委托两三家机构审计,只挑对自己结论更有利的那份对外发布,其余的不公开。公开渠道既证实不了、也排除不了这种可能——审计报告要不要发布,本来就由付钱的一方决定。你能看到的这一份,判断不了背后是不是还有别的版本没被拿出来。
报告说”过审”,两个真实案例告诉你这三个字兑现了多少
这三个字通常只能说明”审计方在特定范围和版本下没查到已知漏洞”,说明不了”以后不会出事”——下面两起真实损失,都发生在”已通过审计”之后。
Euler Finance:审计查过的代码里,一次没接住的健康检查,1.97 亿美元
Euler Finance 是以太坊上的一个借贷协议,上线前做过多轮审计。触发这次损失的 donateToReserve 函数,是协议 2022 年 7 月做治理升级 eIP-14 时新加的代码。据审计机构 Omniscia 自己发布的事件复盘,这段新增逻辑不在 Omniscia 早期审计的范围内。
但它并非从未被审计过:审计平台 Sherlock 在 2022 年 7 月对 eIP-14 做了专项审计,同样没查出这个函数缺了一次关键的健康检查。
具体缺在哪:账户可以先靠自己借款给自己建一个抵押仓位,再调用 donateToReserve 把其中一部分资产”捐”给协议储备。这一步不会触发健康检查,于是负债和抵押品之间被人为拉开一个大缺口。攻击者随后把这个严重资不抵债的仓位”清算”给自己,赚走清算能拿到的钱和缺口之间的差额。这个隐患在系统里躺了大约 8 个月。
2023 年 3 月 13 日,攻击者用一笔闪电贷完成了上面这套操作,十几分钟内卷走约 1.97 亿美元,其中约 1.35 亿美元是质押以太坊代币 stETH(金额据 Chainalysis 记录)。
Sherlock 后来承认自己漏判了这个问题。据 The Block 2023 年 3 月 14 日报道,Sherlock 投票通过 450 万美元理赔金,当时已支付其中 330 万美元——这是理赔金额,不是事件造成的损失总额,也不是最终追回的金额。据 Chainalysis 记录,几周后攻击者以”Jacob”的身份通过链上留言道歉,分批把资金基本全部退还,Euler 协议随后恢复运行。这起事件里,审计不是完全没碰过这段代码——Sherlock 查过,只是没查出这个具体漏洞。
Merlin:过审当天就被清空,报告标了权限却没说重
Merlin 是 zkSync 生态上的一个去中心化交易所,2023 年 4 月 24 日拿到 CertiK 出具的审计报告。据 Decrypt 报道,2023 年 4 月 26 日,Merlin 开放公售约 12 小时后,池子里约 182 万美元的 LP(流动性)资产被转走;问题出在合约初始化时写的两行代码,把几乎能提走全部 LP 代币的权限,授予了一个由团队控制的 feeTo 地址。这类把关键权限攥在部署者手里的写法,和貔貅盘合约里常见的开关是同一类手法,只是这次开在了 DEX 的流动性池上。
这份权限并不是审计报告完全没提过的东西。据 crypto.news 报道,CertiK 事后承认,报告里其实写出了后端团队保留的中心化权限,只是没有把这一项单独摘出来、写清楚它到底意味着什么——用户读报告时很容易划过去,没意识到这是一个能被单方面拿走全部资金的开关。CertiK 官方的原话是:没有把这项风险摆到足够显眼的位置,本该更明确地提示用户注意这类中心化权限;该机构随后表示,此后会把中心化风险列为审计总结里优先强调的内容。
Merlin 团队在事发后于社交媒体确认,资金流出涉及”后端团队的多名成员”。CertiK 通过合作方冻结了约 16 万美元被盗资金,并公布了一项约 200 万美元的社区赔付计划;据现有公开报道,这笔赔付在 2023 年 5 月仍处于推进阶段,没有查到完成全部赔付的后续公开确认。这起事件和撤池子跑路是同一种结构——钱被握有单方面权限的人转走,区别只在这次握着开关的是合约里的 feeTo 地址,不是 LP token。
这两起事件其实是同一类问题的两种走法——donateToReserve 进过审计范围,Sherlock 查过但漏判;feeTo 的中心化权限也写进了 CertiK 的报告,只是没被摆到足够显眼的位置。审计既受范围和版本的限制(管不到没被纳入的代码),也可能把已经查到、写进报告的问题描述得太轻:“通过审计”这三个字,回答的是过去某一份特定代码、按某种方法查过一遍、写进了报告的问题,不回答”这份报告有没有把要紧的事说重、这个项目会不会出事”。
审计报告和链上代码,能核对上什么、核对不上什么?
链上能核对报告里的合约地址、commit hash 是否对得上当前部署的代码;核对不了私钥归属、审计后新增的代码,以及有没有另一份没公开的报告。
链上能核对的
- 报告里写的合约地址和 commit hash(或版本号),能不能对上链上当前部署的字节码——打开区块浏览器的”Verify & Publish”页面,把已验证的源码和报告里标注的版本对一下,这一步任何人都能做。
- 报告”范围”章节列出的文件和合约清单,清单之外的部分默认没被审查过,这是报告正文写明的,不用猜。
- 报告发布日期和合约最后一次升级、迁移的时间,谁先谁后,两个时间戳都公开可查——升级晚于报告,说明报告没覆盖到当前代码。
- 如果合约是可升级代理,当前的实现合约地址是不是报告里写的那一个,代理合约的存储槽里就能读到。
这几项只是起点,想再往下核对活跃地址、持仓集中度这类数字,可以按链上数据怎么看的核对顺序接着查。
链上核对不了的
- 项目方是不是同时找了几家机构审计、是不是只挑了结论更有利的那份公开——链上和报告都不会主动告诉你有没有一份”落选”的报告。
- 私钥、多签签署人背后是不是同一伙人控制,这类操作安全通常不在代码审计的范围内,链上更是完全看不到。
- 团队有没有真按审计建议修复,还是发完报告之后代码又悄悄改回去——除非逐笔比对每一次升级的 diff,很难第一时间发现这类”回退”。
- 审计员本身有没有认真读代码、跟项目方有没有利益关联,这类审计机构自身的可信度不写在报告里,得看这家机构过去查出过什么、漏判过什么。
拿到一份审计报告,你自己怎么拆开看?
先看范围页确认这份报告查的是哪个版本,再按下面六项逐条核对——能自己核实的现在就核实,核实不了的记下来当未知项。
先看范围,不看结论
大多数人翻开一份审计报告,第一眼找的是”发现 0 个严重问题”这行字,其实该先翻到”Scope”(范围)那一页。范围写的是这次审计具体查了哪些文件、哪个 commit、哪个版本——结论只对范围内的东西负责,范围没写到的合约、后续升级的代码,报告的结论一个字都不管。看范围比看结论更花时间,但只有这一步能告诉你,这份”通过”到底通过了什么。
自查表:六项拆开看
拿到一份具体的审计报告,可以按下面这张表逐项过一遍,每一项都对应一个能不能自己核对的问题:
| 检查项 | 报告通常答得了 | 报告通常答不了 | 你还要自己查什么 |
|---|---|---|---|
| 代码有没有常见漏洞(重入、溢出、权限校验缺失) | 能,这是审计的核心工作 | — | 报告里列出的问题是不是都标了”已修复”,还是留了几条”低风险,项目方确认接受” |
| 报告里的合约地址是不是链上实际部署的那一份 | 部分能,如果报告写清了 commit hash 或版本号 | 范围外新增、变更的代码不会被覆盖 | 自己在区块浏览器上核对当前地址的已验证源码,跟报告里的版本是不是同一份 |
| 有没有后门函数、隐藏的特权地址(如 feeTo、owner) | 能,如果这个函数在审计范围内且没被伪装成正常逻辑 | 如果审计偏”模板化扫描”,没被标注过的新手法可能漏判 | 自己查一遍 mint、owner、feeTo、upgrade 这几个关键权限当前归属谁 |
| 私钥、多签是不是真的分散在多人手里 | 不能,这是运营安全,不是代码审计的范畴 | 完全不能 | 查多签合约的签署人数量和门槛,但地址背后是不是真的不同人,链上查不出来 |
| 项目会不会按审计建议修复 | 不能,报告是发布那一刻的快照 | 完全不能 | 定期看合约有没有新的升级或迁移,新版本有没有重新审计 |
| 团队有没有同时找几家审计、只公开好看的一份 | 不能 | 完全不能 | 没有直接核查方法,只能当成一句提醒:一份报告不是全部信息 |
六项里,前两项能自己核对,中间两项要靠自己去查链上权限,后两项报告和链上都给不出答案——这道分界线,比”通过还是没通过”更值得记住。这张表只覆盖审计能不能查出问题;至于骗局本身按手法怎么分类、每一类该去哪核对,币圈骗局的全景归档里按合约层、资金层、社交层拆得更细。
下次看到”已通过审计”,先翻到报告哪一页?
翻到”Scope”那一页,看清这次查的是哪份代码、哪个版本,再对照当前链上部署的是不是同一份。这一个动作花不了几分钟,能戳破大半句”已通过审计”背后被简化掉的信息。审计报告不是安全认证书,它是一次有时间戳、有范围边界的技术核查——把它当成一份需要自己核对边界的文件去读,比把它当成一句可以直接采信的广告语,更接近它本来的样子。
以上内容不构成投资建议;加密资产价格波动剧烈。境内的规则是:法定货币与虚拟货币兑换、代币间兑换、作为中央对手方买卖虚拟货币等相关业务活动,属于非法金融活动,一律禁止;个人参与虚拟货币投资若违背公序良俗,相关民事法律行为无效,损失由个人自行承担(人民银行等八部门《关于进一步防范和处置虚拟货币等相关风险的通知》银发〔2026〕42号,2026 年 2 月 6 日发布,截至 2026-09 为现行规定,具体以官方最新发布为准)。
常见问题
Q: 审计机构越有名,报告是不是就越可信?
答: 机构知名度和这一次具体审计做得细不细,是两件事。知名机构的报告同样只覆盖约定范围内的代码,Merlin 案例里出具报告的正是行业内知名度很高的机构。可信度更多要看这份报告本身的范围写得清不清楚、发现的问题有没有被认真修复,而不是只看机构的名气。
Q: 一个项目被审计了好几次,是不是就更安全?
答: 审计次数多说明团队在这件事上投入了预算,是加分项,但每一次审计各自对应一份特定版本的代码。如果最新一次升级没有被纳入最近一次审计的范围,之前审计过再多次也覆盖不到这次新加的代码——次数本身不能替代范围。
Q: 审计报告里写着”低风险,项目方确认接受”,这是什么意思?
答: 意思是审计员找到了一个问题,但项目方权衡后决定不修复,双方都在报告里留了记录。这类条目不算”没查出来”,而是一个被公开承认、暂时留着的已知风险——值得点进去看具体写的是什么问题,而不是跳过。
Q: 怎么知道一份审计报告是不是真的,没被伪造?
答: 正规审计机构一般会在自己官网的项目列表或报告库里列出发布过的报告,可以直接去审计机构官网核对这份报告是否在列,而不是只看项目方自己贴出的 PDF 或徽章图片。徽章可以被复制粘贴,机构官网的记录不太容易伪造。
Q: 没有审计的项目是不是一定不能碰?
答: 没有审计意味着少了一层代码核查,连”范围内没有已知类型漏洞”这一句都拿不到,风险暴露面更大是客观事实;但反过来,有审计也不等于没有风险,本文列的两个案例都是通过审计之后出的事。两者是需要分别核实的事,不能用一个换算另一个。
Q: 已经投了一个后来被曝出问题的”已审计”项目,能找审计机构追责吗?
答: 多数审计报告在末尾都附有免责条款,明确审计不构成担保、机构对使用报告造成的损失承担有限责任。能不能实际追责,取决于具体合同条款、免责范围和所在法域的法律,需要由具备相应资质的法律专业人士结合材料判断。境内的规则同样适用:个人参与虚拟货币相关投资若违背公序良俗,相关民事法律行为无效,损失需自行承担(依据同上)。
参考资料
- Chainalysis:Euler Finance 闪电贷攻击事件解析 —— 事件金额、攻击手法与资金追回过程
- Omniscia:Euler Finance 事件复盘 —— 审计机构官方说明 donateToReserve 函数不在 Omniscia 审计范围内
- The Block:Sherlock 就 Euler Finance 审计漏判向其赔付 —— donateToReserve 函数实际经过 Sherlock 的 eIP-14 专项审计,及后续理赔金额
- Decrypt:Rogue Developers 清空 Merlin DEX 182 万美元 —— 事件经过、feeTo 权限代码细节、Merlin 团队关于”后端团队成员”的表态
- crypto.news:CertiK 冻结 Merlin DEX 内部 rug pull 中的 16 万美元被盗资金 —— CertiK 承认审计报告未充分强调中心化权限风险,及后续冻结、赔付计划
- CertiK:什么是智能合约审计 —— 审计机构自述审计不是”通过/不通过”的认证,而是范围内代码的客观复核
- 以太坊官方文档 · 智能合约安全 —— 常见漏洞类型的标准解释
- 中国人民银行等八部门:关于进一步防范和处置虚拟货币等相关风险的通知(银发〔2026〕42号) —— 境内虚拟货币相关业务活动与个人参与风险的现行规定
版本 1.0 · 更新于 2026-09 · 文中 Euler Finance、Merlin 两起事件均引用自公开报道与审计机构自身说明;Merlin 事件的赔付进展信息截至 2023 年 5 月的公开报道,此后是否有新进展未再核实。
接着看
Rug pull:撤池子跑路的技术前提是 LP 没锁
撤池子不是漏洞或攻击,而是持有 LP token 的地址调用正常函数。这里拆清它的技术前提、换过的名字、链上能看到的信号、「LP 已锁」为什么仍不够,以及出事后怎样更稳妥地核对和留证。
假空投:骗的不是私钥,是你那一次授权
多数钱包被搬空的案例里,受害者并没有交出私钥,而是在页面上确认了一次授权。approve 给了什么权限、空投投毒怎样引流、签名前如何分清转账和授权,以及发现异常后的止损顺序。
貔貅盘:只能买不能卖是怎么写进合约的
貔貅盘不是行情差到卖不出去,而是合约把卖出能力交给了部署者。五种常见写法、历次换过的马甲、买入前能核对的七项和仍然看不见的三项,以及卖不出去时该怎样留证。