Aiying 艾盈是一家专注于传统金融及Web3的合规咨询服务机构，本文为团队原创，转载需授权。
香港金融管理局《稳定币条例》发牌制度下首个落地的港元稳定币 HKDAP，在 2026 年 8 月 12 日上线后次日，即遭到区块链安全公司 BlockSec 的公开链上审计。审计对象为 Anchorpoint（渣打银行香港牵头、HKT 与 Animoca Brands 合资）部署于以太坊主网的合约，结论是”已上线、已获牌照、尚未准备就绪”。从合规视角看，这份审计的价值不在于发现了几处代码 bug，而在于它用可验证的方式揭示了一个结构性命题：在公链上，持牌发行人的合规义务，最终要落到可被第三方逐条核验的合约实现上，而非书面的制度承诺。
审计对象与方法
BlockSec 沿两个维度展开检查：其一，将 HKDAP 视为软件，判断其是否达到生产级质量；其二，将其视为受监管的稳定币，判断其链上行为是否符合 HKMA《持牌稳定币发行人监管指引》（下称”指引”）。审查基于公开部署的代码与链上可见事实，所有权限关系均通过读取存储槽、调用链上 view 函数核实，而非仅凭源码推断。对于链上无法证实的事项（储备是否完全支持、私钥是否存放于 HSM 或气隙环境等），BlockSec 明确表示不下结论——这划定了本次审查的证据边界。
合规控制的实质失效：fail-open 的 KYC 与撤销机制
指引的生命周期模型预设黑名单、冻结、白名单、KYC 四类控制”有效”。而审计显示，最核心的 KYC 门控与撤销机制在部署代码中并不工作，构成实质性缺口而非形式瑕疵：
- 提供方级撤销是死代码（fail-open）：
isActive(address)中用于”当担保某钱包的身份提供方被注销后收紧其状态”的循环，条件写反（entryCount > entryCount恒为假），且误用比较运算符==替代赋值=，其结果被直接丢弃。净效果是：注销被攻破的 KYC 提供方，无法让其担保过的钱包停止转账，而unregisterVerifier又不触碰计数器，被撤销提供方名下钱包状态仍为激活。 - 验证方注销在另一端同样失效：
_unregisterVerifier仅移动链表节点、未将提供方状态置为 INACTIVE，导致被注销验证方仍可继续登记持有人，且二次注销触发下溢回退。 - KYC 证据从未在链上校验：
_checkKYCProof对传入的 proof 参数完全忽略、径直返回 true，链上对 KYC 证据零校验，可信性完全依赖链下验证方的诚信。 - 免检额度可拆单绕过：
freeTransferLimit仅按单笔金额判断、不累计地址或周期的总额，将大额拆分为多笔即可规避。
治理集中与指引 6.5 条的正面冲突
BlockSec 把链上六个签名角色记为 A–F（部署配置中仅为 32 字节哈希，无一对应具名角色常量）。逐条读取授权矩阵的结果，与指引第 6.5 条形成多处直接冲突：
- 指引 6.5.3（高风险操作不得单方执行）：增发（mintToDeposit）、销毁（burnFrom）、冻结（freeze）、KYC 停用均为角色 C 单签；暂停、销毁黑名单资金、验证方登记为角色 D 单签；拉黑、解冻为角色 F 单签。仅升级与配置修改需第二签名，且系统无时间锁、操作与最终签名原子完成。合约虽实现了供应速度限制（whenWithinRiskThresholds），但不能替代操作本身的多签控制。
- 指引 6.5.4（职责隔离与即时撤销）：一个 EOA 账户同时持有六个角色——发行、冻结、KYC 验证方管理及全部四个审计角色，执行与审计重叠；且签名者角色仅在签名时校验一次、早期签名者事后被吊销也不重新验证，已计入的批准在吊销后仍然有效，”可立即撤销”无法兑现。
- 指引 6.5.5（每次代码变更第三方审计）：当前实现即 7 月 10 日升级所安装的实现，Part 1 全部缺陷存活其中，且唯一一次升级仅在 12 秒的相邻区块内由 A+B 两签完成、无独立审查窗口，不符合”正确、一致、无漏洞”的确认标准。
此外，销毁黑名单资金函数将代币以 Transfer 事件发往 address(this)（而非 address(0)）、而合约自身从未持有该余额，会使索引器记账漂移、从事件重建的总供给与链上不符，并与指引 2.2.3″被冻结/销毁的稳定币保持完全支持且可对账”相悖。这一不对称还带来治理上的失衡：冻结与拉黑仅需一签，解除拉黑却需两签——限制账户比释放账户更容易。
根本成因与修复路径
BlockSec 指出，所有缺陷背后是一条共同主线：该合约以定制形式重新发明了生态早已提供并规模化审计的基元——自研审批引擎与角色层（本可用 Safe 多签 + OpenZeppelin AccessManager/TimelockController）、手写链表集合（本可用 EnumerableSet）、修改过的代理（本可用标准 TransparentUpgradeableProxy）、手写 ERC-20（本可用 OpenZeppelin ERC-20）。缺陷集中在定制机制而非复用标准组件的部分；每一层定制抽象，同时是 gas 开销、攻击面与升级风险。
据此，BlockSec 列出六项修复建议：恢复高风险操作的多签、执行与审计分离、修复 KYC 撤销逻辑、统一 transfer/transferFrom 的转账检查、移除调试代码、每次升级前引入第三方审计。审计同时肯定 Anchorpoint 在主网部署并验证源码是”正确的默认做法”，正是这一步使本次公开审查成为可能，并强调这些问题均可解决。
结论与合规启示
对持牌稳定币发行人而言，本案释放的信号清晰：牌照解决的是”准入”，代码解决的是”合规义务的实际履行”。在传统金融中，合规与否由内部制度与监管检查背书；在公链上，规范发行、转账、冻结的规则以代码形式公开、且严格按内容执行，任何第三方皆可验证其是否名副其实。”Beta Access”标签不改变风险画像——合约已在主网上线、由真实私钥管理、代表对港元的真实债权，理应达到生产标准。
对监管与市场而言，HKDAP 案例或将成为持牌稳定币引入”链上合规审计”作为第二道防线的起点：当发牌机构与第三方安全审计各自独立、互为印证时，公链稳定币的信任基础才能从”牌照宣称”升级为”可验证的实现”。对从业者的提示则更直接——受监管稳定币的成色，最终取决于部署代码是否经得起像 BlockSec 这样的公开逐条核验。
本文基于 BlockSec 官方审计报告（英文，2026-08-13）及其中文繁体版撰写，HKMA《持牌稳定币发行人监管指引》条款编号与 Anchorpoint 发行背景经公开报道交叉核对。队列源（吴说）为聚合来源，已按规则追至一手信源 BlockSec 官方博客。
