OAK-M23 — Audit-Attestation Public-Registry Verification

Description

Audit-attestation public-registry verification is a venue-side defensive control in which the audit firm publishes signed attestations — binding the audit firm's public key to the audited bytecode hash and to a stable engagement identifier — to a public registry, and venues, aggregators, and risk-team tooling verify, at listing time and at recurring monitoring intervals, that the attestation's audited bytecode hash matches the bytecode currently deployed at the cited contract address. M23 is the canonical venue-side mitigation for the audit-trust failure modes (T6.001–T6.004) that the user-facing assertion "this contract has been audited" exposes when the assertion is a project-self-claim rather than a cryptographically-verifiable attestation.

From a defender's perspective, M23 closes the gap that T6.002–T6.004 collectively exploit: T6.002 (fake audit-claim) succeeds because there is no canonical lookup surface for "did Firm X audit Project Y?"; T6.003 (audit of different bytecode version) succeeds because there is no canonical lookup surface for "did Firm X audit this exact bytecode?"; T6.004 (audit-pending marketing claim) succeeds because there is no canonical lookup surface for "is Firm X currently engaged with Project Y?". M23 is the infrastructure layer that converts each of these questions from a manual inquiry to the firm into a deterministic signature check at the venue's listing pipeline. T6.001 (source-verification mismatch) is partially covered by M23 as a side-effect: the audit-attestation includes the bytecode hash, which the venue compares to the deployed bytecode, surfacing source-bytecode mismatch as a downstream signal even where the explorer-side Sourcify check has not been performed.

The structural model M23 implements is analogous to Sourcify-style cryptographic source-verification but operates at the audit-attestation layer rather than the source-verification layer. The audit firm's role shifts from "publisher of PDF reports" to "issuer of cryptographic attestations that bind audited artefacts to firm identity"; the venue's role shifts from "echoer of project-self-claims" to "verifier of attestations against deployed bytecode at the listing-pipeline boundary". The trader's role shifts from "trust the venue's audit label" to "trust the venue's attestation-verification pipeline" — a meaningfully smaller trusted-computing-base.

How it applies

• T1.001 (Modifiable Tax Function): the canonical T1 underlying Technique that T6 evasion modifiers most frequently combine with. M23 at the venue side surfaces audit-claim verification at listing time, which raises the cost of pairing T1.001 with a fabricated or scope-drifted audit claim. A venue running M23 cannot list a tax-modifiable token under an "audited" label without a verifiable attestation; the project must either obtain a real audit binding the deployed bytecode (which exposes the modifiable-tax surface to audit-firm review and likely audit-finding disclosure) or list under an explicit "no verified audit" label.
• T6.001 (Source-Verification Mismatch): M23 partially covers as a side-effect — the audit-attestation includes the audited-bytecode hash, which equals the deployed-bytecode hash if the source is properly verified and the deployed bytecode matches the audited version. M23 is the canonical mitigation for T6.003 (audited code differs from deployed code); the T6.001 coverage is incidental but useful at the venue's listing pipeline.
• T6.002 (Fake Audit-Claim): the canonical M23 use case. The venue's listing pipeline queries the audit-firm registry for the cited engagement; non-existence of the engagement in the registry is the canonical T6.002 signal. M23 makes this lookup deterministic and machine-readable rather than requiring direct firm inquiry per project.
• T6.003 (Audit-of-Different-Bytecode-Version): the canonical M23 use case at the bytecode-comparison layer. The venue's listing pipeline retrieves the audit-attestation's bytecode hash, retrieves the deployed bytecode at the cited contract address, compares. Non-match is the canonical T6.003 signal. This is the failure mode for which M23 is most clearly load-bearing — T6.003 evades T6.002-style registry-existence checks (the engagement exists), but does not evade M23's bytecode-binding check.
• T6.004 (Audit-Pending Marketing Claim): M23 covers if the audit firm extends the registry to in-progress engagements. The forward-looking variant of M23 — engagement-attestation rather than completed-audit-attestation — converts T6.004 verification from a direct firm inquiry into the same deterministic signature check. Where the firm has not extended the registry, M23 closes T6.002 / T6.003 but leaves T6.004 to manual inquiry; the v0.x roadmap is explicit at the audit-firm community layer.

Limitations

• Audit-firm adoption is the binding constraint. M23 requires audit firms to publish attestations in machine-readable, cryptographically-verifiable form. As of v0.1 OAK observation, most major firms publish PDF reports referencing commit hashes; few publish bytecode-hash-bound attestations in registry-API form. M23's effectiveness scales linearly with audit-firm adoption; until the major firms ship registries, M23 covers only the audited subset and falls back to project-self-claim (i.e., T6.002-vulnerable) for the rest.
• Attestation revocation surface. Audit firms must maintain attestation-revocation infrastructure for cases where post-audit findings, post-audit operator action, or audit-firm-side errors require an attestation to be invalidated. Without revocation, M23 freezes the audit-claim at audit time and does not capture post-audit drift. The post-Swaprum case illustrates that audit-coverage-of-record alone does not bound post-launch operator behaviour; M23 would not have caught Swaprum, and the limitation is structural, not implementation.
• Bytecode-hash comparison does not catch proxy-implementation drift. A proxy contract's audit-attestation may bind the audited implementation bytecode, but the proxy's runtime implementation address can change post-audit. M23's bytecode comparison must be performed against the resolved implementation address, not the proxy address itself, to catch this. Implementation-resolution at the venue's listing pipeline is the M23 calibration step.
• Multi-contract scope. A project's deployed system frequently includes multiple contracts (factory, router, treasury, governor); a single-contract audit-attestation does not cover the multi-contract surface. M23 requires the attestation format to expose the audited-scope graph (which contracts are in scope, which are not), and the venue's listing pipeline to traverse the deployed system's contract graph for unaudited authority-holding contracts.
• Cross-firm registry fragmentation. Each major audit firm publishes its own registry; venues must integrate against multiple registries. A canonical cross-firm attestation format (analogous to OCSP / CT-log infrastructure in the X.509 PKI ecosystem) would reduce integration cost. The standardisation problem is at the audit-firm-industry coordination layer.
• M23 does not bound audit quality. A registry-verified, bytecode-bound audit can still be shallow, narrow-scoped, or miss a critical finding. M23 covers the existence-and-coverage layer (the audit happened, on this code); audit-quality remains a qualitative editorial concern that M23 does not address.

Reference implementations

• Sourcify-style precedent: the closest existing infrastructure pattern is Sourcify's cryptographic source-verification (matching deployed bytecode against off-chain source artefacts via metadata hash). Sourcify operates at the source-verification layer and does not bind audit attestations; the M23 architectural model extends this pattern to the audit-attestation layer with audit-firm-issued signatures.
• Per-firm registry status (v0.1 OAK observation): CertiK Skynet, Halborn published-audit registry, OpenZeppelin Defender audit-trail, Trail of Bits public-audits archive each provide partial M23 coverage. Project name and audit date are typically published; audited-bytecode hash in machine-readable form is emerging rather than mature; cryptographic firm-key signatures over the attestation are not yet standard. The M23 v1.0 target state requires all three components.
• Venue-side integration precedent: major DEX aggregators and CEX listing pipelines increasingly query third-party security-rating services (Token Sniffer, GoPlus, RugCheck) at listing time. These services partially substitute for M23 by performing the audit-claim verification on the venue's behalf, but operate against project-self-claim signal rather than firm-issued attestation. M23 in mature form would replace the per-project static analysis with a single attestation lookup.
• Standardisation path: the audit-firm-industry community has discussed (without converging on) a cross-firm attestation format. Convergence would require either an industry coordinating body or a venue-side requirement (e.g., a major exchange refusing to surface "audited" labels without M23-format attestation) to force the coordination.

Citations

• [certikfakeaudit] — primary CertiK advisory documenting the brand-misuse pattern that M23 closes; covers both T6.002 (completed-audit) and T6.004 (engagement-claim) framings within the same denial pattern.
• [chainalysis2025rug] — cohort-scale context for audit-related marketing claims as recurring components of rug-pull retrospectives across 2024–2025.
• [dlnewsswaprum2023] — adjacent case (real audit, post-audit operator action) illustrating the audit-quality limitation of M23: the attestation would have verified, the rug still happened.
• [slowmist2024report] — cohort-scale context for forward-looking audit claims in commodity-scam-token deployment patterns; anchors T6.004 as a recurring component of T1 launch playbooks.