OAK — OnChain Attack Knowledge

Worked example · 2021-20

Fake Audit Claims and Audit-Pending Marketing Cohort — 2021–2026 — Aggregate ~$50M+

Loss
Aggregate loss estimated at $50M+ across the full 2021–2026 cohort, though precise attribution of individual rug-pull losses to the audit-claim component (vs. the underlying T1/T2/T3 mechanism) is structurally difficult. The audit claim is a defence-evasion enabler that extends the victim-acquisition window rather than the extraction mechanism itself; the loss attributable to the claim is the incremental extraction that occurred because victims delayed scepticism based on the fabricated or never-materialising audit representation.
OAK Techniques observed
OAK-T6.002 (Fake Audit-Claim — projects falsely claiming completed audit coverage by recognised audit firms, either by fabricating certificates the firm did not issue or by claiming affiliation with a firm that has not engaged with the project.) OAK-T6.004 (Audit-Pending Marketing Claim — projects marketing an audit as "in progress", "forthcoming", "pending", or "being arranged with [firm]" without an engagement actually being in progress, contracted, or planned at the named firm. The temporal dimension distinguishes T6.004 from T6.002: the forward-looking claim is structurally unverifiable against a completed-audit registry, and the verification surface shifts from the registry to the firm's engagement-tracking layer, which most firms do not expose publicly.)
Attribution
unattributed — The cohort spans dozens of individual operators across Ethereum, BSC, Solana, Polygon, Arbitrum, Base, and PulseChain. No single operator dominates; the pattern recurs across independent launch venues because the audit-verification infrastructure gap is systemic rather than actor-specific.
Key teaching point
The audit-claim verification surface is the highest-leverage unsolved defender problem in the token-launch security stack. A project that falsely claims audit coverage (T6.002) or audit-in-progress status (T6.004) is not relying on a sophisticated exploit primitive — it is exploiting the structural gap between the marketing claim (which any project can make at zero cost) and the verification surface (which requires the user to navigate per-firm registries, engagement-tracking surfaces that may not exist, and cross-reference timelines that span multiple platforms). The two Techniques co-occur in practice because an operator who fabricates a completed-audit claim after the fact (T6.002) often laid the groundwork with forward-looking "audit pending" language during the launch window (T6.004). The defender lesson is that the temporal dimension of an audit claim — past (completed) vs. future (pending) — determines which verification surface is load-bearing, and the forward-looking verification surface is structurally weaker at v0.1 than the backward-looking one. T6.002 is defeated by registry lookup; T6.004 is defeated only by firm-side engagement acknowledgement, which is not machine-readable, not published at cohort scale, and not integrated into any wallet or block-explorer UX at v0.1.
T6.002 (Fake Audit-Claim)
The project claims a completed audit that does not exist. Sub-patterns include: (a) fabrication of a certificate bearing a real firm's branding, (b) citation of a real audit conducted for a different project as if it covered the current project, (c) claim of audit affiliation with a firm the project contacted but never contracted with. The canonical verification surface is the firm's published audit registry (CertiK Skynet, Halborn published audits, OpenZeppelin audit archive, Trail of Bits public audits). A registry lookup that returns zero results for the project is the detection signal. This verification is straightforward in principle but requires the user to know which registry to check and how to navigate it — a UX gap that the attacker exploits.
T6.004 (Audit-Pending Marketing Claim)
The project claims an audit is in progress, forthcoming, pending, scheduled, or being arranged with a named firm. The forward-looking temporal dimension defeats the completed-audit registry as a verification tool — the audit not being in the registry yet is consistent with both an honest pending engagement and a fabricated one. The verification surface shifts to the firm's engagement-tracking layer, which at v0.1 is not systematically published by any major audit firm. The canonical detection signal is a firm-side denial of engagement ("we are not conducting an audit for this project and have no engagement with them"), which arrives only if the firm is asked directly and chooses to respond publicly. Without systematic engagement-transparency infrastructure, T6.004 claims are structurally unverifiable for the retail user.
The cross-chain dimension
The pattern is chain-agnostic because the failure mode lives off-chain at the marketing-claim layer. The underlying T1/T2/T3 Techniques that the audit claim modifies may be on any chain. The PulseChain sub-cohort demonstrates that chain-startup phases are particularly vulnerable — a new chain's community infrastructure has not yet integrated the per-firm registry cross-referencing that more mature chain communities develop organically over time, creating a temporary verification vacuum that operators exploit.

Summary

The fake-audit-claim and audit-pending-marketing pattern is one of the most persistent and under-instrumented defence-evasion surfaces in on-chain crime. The primitive is simple: a token launch includes an audit claim — either "audited by [firm]" (T6.002) or "audit in progress with [firm]" (T6.004) — that, if believed, delays user-side scepticism through the critical holder-capture phase. The claim is typically embedded in the project's website, Telegram pinned message, Twitter bio, or CoinMarketCap/CoinGecko self-reported description. By the time the claim is disproven (firm denial, rug event, or simple non-materialisation), the extraction window has closed and the project has disappeared.

The cohort spans two distinct but co-occurring Technique classes:

The combined T6.002 + T6.004 playbook is the most common operational pattern: the operator launches with "audit pending" language (T6.004) to anchor early-adopter trust, then transitions to "audit completed" language (T6.002) as the holder-capture phase matures, fabricating a certificate or misrepresenting a preliminary review as a final audit. The temporal sequencing exploits both verification gaps in sequence: the early-phase forward-looking claim is unverifiable, and by the time the late-phase backward-looking claim is verifiable, the extraction may have already occurred or the project may have disappeared along with its marketing material.

Notable named cases within the cohort:

  • ATMA — 2024 — Project claimed it was undergoing CertiK audit; CertiK publicly clarified "not conducting an audit and are not affiliated with this project in any way." Project deleted its social media presence following the callout. T6.004 (audit-pending claim with firm-side denial).
  • Lymex — 2024 — ~$300K — Project falsely claimed CertiK audit coverage; CertiK stated no audit services were rendered (failed KYC verification at the engagement-attempt stage). Project subsequently exited. T6.002 (completed-audit claim with firm-side denial).
  • Hypervault Finance — August 2025 — Canonical T6.002 + T6.004 combined case. Project claimed "audits underway" with Spearbit, Pashov, and Code4rena; Pashov publicly denied any knowledge of Hypervault, and Code4rena listed no pending audits. The case is notable for spanning three named firms in a single claim set.
  • PulseChain ecosystem fake-audit token launches — November 2023–February 2024 — ~$4-7M — Aggregate across ~15-20 PulseChain-based projects citing "audit pending with CertiK" or "audit in progress with Hacken" with no engagement at either firm. The PulseChain sub-cohort is the canonical illustration of the ecosystem-startup-phase sub-pattern: a new chain's rapid-growth phase attracts projects exploiting the lesser-known audit-verification surface where the chain-local block explorer and community infrastructure have not yet integrated per-firm registry cross-referencing.
  • Compounder Finance — December 2020 — The protocol marketed a SourceHat PASS rating while a Timelock-queued malicious setStrategy() transaction sat publicly visible. The audit claim was literally true for the audited code but functionally misleading as an "audit pending" framing for the about-to-be-deployed malicious strategies — the canonical T6.004 boundary case where a completed audit is used to anchor a forward-looking trust expectation the protocol had no intention of fulfilling.

CertiK's public-denial pattern ([certikfakeaudit]) is the canonical firm-side detection signal at v0.1. CertiK has published multiple public statements disclaiming affiliation with projects misusing its brand, covering both backward-looking ("we did not audit this project") and forward-looking ("we are not conducting an audit and are not affiliated") framings. The denial template itself has become a recognisable genre: "CertiK is not conducting an audit and [is/are] not affiliated with this project in any way." The existence of a standardised denial template reflects the scale of the cohort — the firm-side brand-misuse surface is large enough that a template response has emerged.

The verification-infrastructure gap at v0.1 is the structural reason T6.002 and T6.004 remain effective. Major audit firms publish completed-audit registries (the T6.002 verification surface) but do not publish in-progress-engagement registries (the T6.004 verification surface). No wallet, block explorer, or DEX aggregator integrates per-firm registry verification at the user-warning layer. A token that claims "audited by CertiK" displays identically in every UI to a token that was actually audited by CertiK. The user bears the full burden of verification: knowing which firm the project claims, navigating to that firm's registry, performing the lookup, and interpreting the result. The UX asymmetry — the claim is zero-cost and surfaced in the primary UI; the verification is high-effort and buried in a separate system — is the load-bearing enabler for both Technique classes.

Timeline (UTC)

When Event OAK ref
2020-12 Compounder Finance: SourceHat PASS rating marketed while Timelock-queued malicious strategy swap sat publicly visible T6.004 (boundary case)
2021 Fake-audit-claim and audit-pending-marketing pattern becomes widespread across BSC and Ethereum token launches T6.002 + T6.004 (class emergence)
2023-11 to 2024-02 PulseChain ecosystem sub-cohort: ~15-20 projects citing fake or non-existent audit engagements with CertiK and Hacken; aggregate $4-7M lost T6.002 + T6.004
2024 ATMA: CertiK publicly denies audit engagement; project deletes social media presence T6.004
2024 Lymex: ~$300K exit scam with false CertiK audit claim; CertiK confirms no audit services rendered T6.002
2025-08 Hypervault Finance: combined T6.002 + T6.004 with claims spanning Spearbit, Pashov, Code4rena; Pashov publicly denies; Code4rena confirms no pending audits T6.002 + T6.004
2021–2026 Pattern persists across all major EVM chains and Solana; no systematic verification infrastructure deployed at wallet or explorer layer T6.002 + T6.004 (ongoing)

Public references

  • [certikfakeaudit] — CertiK's published documentation of brand-misuse patterns including fake audit certificates, phishing sites with counterfeit security-audit certifications, and impersonation of CertiK employees
  • Industry retrospectives: [chainalysis2025rug], [slowmist2024report] documenting the audit-claim-as-evasion pattern at cohort scale
  • Per-firm audit registries: CertiK Skynet, Halborn published audits, OpenZeppelin audit archive, Trail of Bits public audits, Code4rena audit reports, Spearbit published engagements
  • See techniques/T6.002-fake-audit-claim.md and techniques/T6.004-audit-pending-marketing-claim.md for Technique definitions

Discussion

The fake-audit-claim and audit-pending-marketing cohort is the canonical illustration of a broader OAK principle: defence-evasion Techniques that live at the marketing-claim layer are structurally persistent because the verification infrastructure that would defeat them is not on-chain and not automatable via existing on-chain monitoring tooling. A T6.002/T6.004 detector cannot be built by scanning contract bytecode or transaction traces — it requires integration between the project's marketing claim (off-chain, ephemeral, multi-platform) and the audit firm's engagement-tracking surface (off-chain, not systematically published, per-firm rather than unified). This is a coordination problem, not a detection-algorithm problem, and it explains why both Techniques remain at "stable" maturity with no systematic mitigation at the wallet or explorer layer at v0.1.

The highest-leverage intervention is audit-firm-side: machine-readable, cryptographically-verifiable engagement and completion registries, with wallet/explorer-integrated verification APIs. Until that infrastructure exists, the audit-claim verification gap will remain one of the largest unsolved surfaces in the token-launch security stack.

Techniques demonstrated (2)