OAK-M24 — Out-of-Band Audit-Engagement Verification

Description

Out-of-band audit-engagement verification is the operational practice of contacting the named audit firm directly, via a verified communication channel — the firm's published contact form, a known firm-side account-management contact, or a regulator-published firm address — to confirm that the cited audit engagement exists, is in scope of the cited contract, and (for forward-looking claims) is actually in progress with a documented engagement contract or quote behind it. M24 is the manual fallback at the venue / risk-team / trader layer when M23 (Audit-Attestation Public-Registry Verification) is unavailable because the cited firm has not yet implemented machine-readable attestation infrastructure.

From a defender's perspective, M24 directly addresses the asymmetry that T6.002 and T6.004 exploit: the project-self-claim is cheap to fabricate (a marketing-line assertion, a logo placement, a Discord-pinned message), and verification at the user-decision layer is structurally expensive (a per-project inquiry to the firm, with response latency measured in days). M24 does not close the asymmetry — it remains a costly per-project exercise — but it converts the asymmetry from "fabricate-vs-trust" into "fabricate-vs-verify", which is the binding lift in defensive posture for the venues and risk-teams who can absorb the verification cost on behalf of downstream traders.

The leverage from M24 concentrates at the venue tier. Individual traders rarely have the time or the firm-side contact infrastructure to execute M24 per project; venues, listing pipelines, and risk-team tooling can absorb the per-project cost once and surface the verified-or-unverified status to all downstream users. M24 at the venue is therefore a public-good contribution: a single venue performing M24 for a token's listing eligibility surfaces the answer to all traders trading that token at that venue. The structural complement is venue-level surfacing of M24 outcomes (e.g., "audit claim verified out-of-band with [firm]" vs. "audit claim not verified — project self-claim only") so that the verification cost is paid once and the signal is reused.

How it applies

• T6.002 (Fake Audit-Claim): the canonical M24 use case. The venue's listing pipeline issues a direct inquiry to the named audit firm asking whether the firm performed an audit on the cited project. A firm-side denial ("we are not affiliated with this project, no audit was performed") is the canonical T6.002 confirmation; firm-side confirmation of engagement-and-scope is the M24 success path. Where the firm exposes a registry (M23-precursor infrastructure), M24 reduces to the registry lookup; where it does not, the direct inquiry is the load-bearing artefact.
• T6.004 (Audit-Pending Marketing Claim): the canonical M24 use case for forward-looking claims. The asymmetry between completed-audit registry lookup (which T6.002's verification path exploits) and in-progress-engagement registry lookup (which most firms do not expose at v0.1) is precisely the gap M24 fills. The direct inquiry asks whether the firm has an active engagement, a finalised contract, or a published quote against the cited project; firm-side confirmation that no such engagement exists is the canonical T6.004 signal. Pair with timeline-slip analysis (archival snapshots of the project's marketing claims) where the engagement claim has been promoted across multiple project-launch phases without ever materialising.

Limitations

• Per-project cost. Each M24 verification consumes audit-firm-side response capacity and venue-side analyst time. At cohort-level (thousands of token listings per quarter at major aggregators), per-project M24 is structurally infeasible without firm-side automation. M24 in practice is calibrated to the high-stakes subset (large initial-liquidity tokens, named-firm audit claims, high-profile listings); commodity scam-token cohort scale falls back to project-self-claim or to T6.002-vulnerable static heuristics.
• Audit-firm response latency. Firm-side response to direct inquiry typically takes hours to days; the venue's listing pipeline must accommodate the latency or default-decline pending verification. Default-allow-pending-verification is structurally vulnerable to T6.002 / T6.004 launches that exploit the verification window.
• Channel-verification surface. "Verified channel" is a defensive predicate that itself requires verification: an attacker who has compromised the firm's published email address, contact-form handler, or account-manager LinkedIn account can answer the M24 inquiry adversarially. The structural complement is regulator-published firm-contact information (where regulatory frameworks expose audit-firm registration) and cross-channel confirmation (web-form + signed-email + phone) for high-stakes verifications.
• Firm-side engagement-confidentiality concerns. Audit firms in early-engagement phases may decline to confirm or deny engagement existence for legitimate commercial-confidentiality reasons (the prospective client has not authorised disclosure). M24 produces a "firm declined to confirm" signal in this case, which is structurally weaker than a positive engagement confirmation. Venues must decide whether "declined to confirm" is treated as elevated risk (false-positive cost on legitimate early-stage projects) or as not-yet-disqualifying (false-negative cost on T6.004 fabrications).
• No coverage of audit quality or scope. M24 confirms that the engagement exists and is in scope of the cited contract; it does not confirm that the audit found everything it should have, or that the audited contract is the deployed contract (which is M23's bytecode-bound attestation surface, not M24's engagement-existence surface). T6.003 (audit-of-different-bytecode-version) is structurally outside M24's scope — the firm will confirm engagement existence and the project will pass M24, but the deployed bytecode will not match the audited bytecode.
• Adversarial impersonation of the venue. Where the venue's M24 inquiry to the firm is itself spoofable (e.g., the venue's outbound email is not domain-authenticated), the attacker can intercept the verification chain. The complement is end-to-end signed inquiry-response infrastructure, which is in practice rarely deployed.

Reference implementations

• CertiK denial pattern: the canonical M24-by-firm-side reference. CertiK's public denial statements (covering both ATMA and Lymex T6.002 cases, and the broader engagement-impersonation T6.004 pattern) demonstrate the firm-side response to detected brand misuse. The denial is structurally an M24 output broadcast to the public rather than a per-inquiry response, but the inquiry-response pattern that ATMA / Lymex would have failed had M24 been performed at listing time is the same.
• Per-firm contact channels (v0.1 OAK observation): CertiK, Halborn, OpenZeppelin, Trail of Bits each publish a primary contact channel for engagement-verification inquiries. Response cadence and policy (will-confirm-engagement / will-not-confirm-engagement) varies per firm. M24 in practice requires a venue-side contact-channel inventory and per-firm inquiry-handling SOP.
• Listing-pipeline integration precedent: major CEX listing teams perform M24-class verification as part of due-diligence on tokens citing prominent audit firms; the practice is informal, not standardised, and not surfaced to traders. Surfacing M24 outcomes at the trader-facing listing UI ("audit claim verified out-of-band 2026-04-15 with [firm]") would convert M24 from a private listing-diligence step into a public defensive signal.
• Industry-shared verification cache: cross-venue sharing of M24 outcomes — a verification performed by Venue A is reusable by Venue B if the cited audit and engagement window are unchanged — would reduce per-project verification cost. The structural model is analogous to OCSP-stapling / certificate-transparency-log caching in the X.509 PKI ecosystem; v0.1 OAK observation is that no such cross-venue cache exists yet.

Citations

• [certikfakeaudit] — primary CertiK advisory; canonical M24-by-firm-side reference. Covers both T6.002 (completed-audit) and T6.004 (engagement-claim) denial patterns and is the public-record source for the ATMA and Lymex cases that M24 at venue listing time would have caught.
• [chainalysis2025rug] — cohort-scale context for fabricated audit claims as recurring components of rug-pull retrospectives; anchors the cohort-level case for venue-side M24 adoption.
• [slowmist2024report] — cohort-scale context for forward-looking audit claims in commodity-scam-token launch playbooks; anchors T6.004 as a recurring T1 / T2 / T3 modifier that M24 closes.
• [dlnewsswaprum2023] — adjacent case (real audit, post-audit rug); cited to anchor the M24-vs-T6.003 distinction. M24 would have passed Swaprum (the engagement was real); the failure mode lived elsewhere, which is the structural limitation of M24 covered above.