OAK — OnChain Attack Knowledge

Document

OAK v0.1 — Taxonomy Gaps

This document explicitly enumerates what OAK v0.1 does not cover and why. It is published as part of the v0.1 release because a framework that quietly excludes large attack classes invites legitimate criticism, while a framework that documents its scope honestly invites contribution.

Candidates from this file that have been promoted from draft to emerging and now live as canonical Technique files under techniques/. Each entry retains a one-line audit-trail pointer to the new file; substantive framing has moved to the technique file.

The promoted entries' substantive framing (definition, sub-classes, detection signals, mitigations, discussion) has moved to the canonical technique files. The expanded prose for each candidate that previously lived in this file has been deleted; the gap inventory below has been trimmed accordingly.

What v0.1 does cover

OAK v0.1 covers six populated axes:

  • Tactics × Techniques (the matrix): 14 Tactics covering the operator-behaviour kill chain (T1-T8), smart-contract exploits (T9), bridge and cross-chain (T10), custody and signing infrastructure (T11), NFT-specific patterns (T12), account abstraction (T13), and validator/staking/restaking (T14). 62 Techniques across the matrix.
  • Mitigations (OAK-MNN): 40 reusable defences across five classes (detection, architecture, operational, venue, wallet-UX), each mapping many-to-many to Techniques.
  • Software (OAK-SNN): 40 named tools, kits, and malware families (drainer kits, DPRK macOS family, ransomware binaries, commodity loaders and post-exploitation, infostealers, crypto-specific tooling).
  • Threat Actors / Groups (OAK-Gnn): 18 tracked operator clusters with explicit attribution-strength language (DPRK clusters, Russian-cybercrime ecosystem, drainer-as-a-service, Iranian financially-motivated, affiliate-collectives).
  • Data Sources (OAK-DS-NN): 12 telemetry-input identifiers covering on-chain telemetry, mempool/pre-block telemetry, and off-chain CTI feeds.
  • Worked Examples: 142 per-incident and operator-profile write-ups spanning 2011-2025; every Tactic pillar has canonical worked-example anchors.

The relationship graph (mitigates, uses, targets, subtechnique-of edges; 416 edges at v0.1) connects entries across axes and is emitted machine-readably in tools/oak.json schema v2.

The largest classes of public crypto-theft losses are within v0.1 scope: T11 (custody compromise; the off-chain entry vector behind Bybit Feb 2025 ~$1.5B, DMM Bitcoin May 2024 ~$305M, Radiant Capital Sep 2024 ~$50M, Phemex Jan 2025 ~$73M, Indodax Sep 2024 ~$22M, Poloniex Nov 2023 ~$120M, WazirX Jul 2024 ~$235M); T9 (smart-contract exploits; Euler Mar 2023 ~$197M, Mango Markets Oct 2022 ~$117M, KyberSwap Nov 2023 ~$48M, Hedgey Apr 2024 ~$44.5M, Sonne May 2024 ~$20M, UwU Jun 2024 ~$20M, Cetus May 2025 ~$220M); T10 (bridge incidents; Wormhole Feb 2022 ~$325M, Ronin Mar 2022 ~$625M, Harmony Jun 2022 ~$100M, Nomad Aug 2022 ~$190M, BSC Token Hub Oct 2022 ~$586M, Multichain Jul 2023 ~$126M, HTX/HECO Nov 2023 ~$110M, Orbit Jan 2024 ~$81.5M).

Whole pillars still out of scope at v0.1

The following attack categories are not covered by any v0.1 Tactic.

1. Severity / loss scaling

OAK v0.1 has no formal severity dimension. Combining federal-record cases (Bybit ~$1.5B, Ronin ~$625M, Mt. Gox ~850k BTC, Plus Token ~$2B+) with per-victim drainer events (~thousands per victim at high volume) into a single matrix loses information. A severity: field with documented bands could be added in v0.x without breaking schema.

2. Timing dimension

When in a token's or protocol's lifetime does each Technique typically fire? Day 0? Day 30? Year 2? This is a useful predictive signal for defenders and is recoverable from the cited datasets but not encoded in the v0.1 schema.

3. Chain coverage

The Chains: header in each Technique covers EVM, Solana, Sui, Aptos, and cross-chain at v0.1. Not yet covered: Bitcoin (especially Ordinals, BRC-20, Runes), Cosmos chains beyond bridge cases, Tron beyond passing references, TON, Polkadot ecosystem beyond Acala. Each will need at minimum a chain-specific Technique mapping pass when the framework expands.

Sub-Techniques missing inside already-covered Tactics

These are Techniques that fit cleanly inside an existing v0.1 Tactic but are flagged as v0.x targets.

T1 — Token Genesis (additions for v0.x)

  • Hidden owner-equivalent functions implemented in assembly to evade source-level static analysis.
  • Maximum-wallet / maximum-transaction restrictions weaponised to prevent specific addresses from exiting.
  • Initial-liquidity-providing-and-removing patterns where the deployer operator-substrate provides initial liquidity then removes during specific market windows.
  • T1.006 Honeypot-by-Design — promoted to emerging; see techniques/T1.006-honeypot-by-design.md.
  • T1.007 Token-2022 Transfer-Hook Abuse — promoted to emerging; see techniques/T1.007-token-2022-transfer-hook-abuse.md.

T3 — Pump-and-Dump and Market Manipulation (additions for v0.x)

T4 — Access Acquisition (additions for v0.x)

  • T4.007 Native-app Social Phishing on Engagement-Weighted Platforms — promoted to emerging; see techniques/T4.007-native-app-social-phishing-engagement-weighted-platforms.md.

  • OAK-T4.008 Fake-DEX Clone-Frontend Phishing — promoted to emerging; see techniques/T4.008-fake-dex-clone-frontend-phishing.md.

  • Pre-token brand-anticipation phishing — promoted to emerging as OAK-T4.009; see techniques/T4.009-pre-token-brand-anticipation-phishing.md. Anchored: zkSync airdrop anticipation (2023–2024), EigenLayer token anticipation (2024–02), StarkNet STRK pre-token (2023–2024), Bera Chain fake airdrop (2024–06).

  • Voice / telephony impersonation of a custodial venue's support to an end user (forward candidate, and the largest unmapped retail surface in the corpus by realised loss). The attacker phones the holder, presents data-broker-sourced personal detail plus a manufactured drain-in-progress emergency, and walks them through the extraction. Field anchors: examples/2023-2026-coinbase-support-impersonation.md (~$300M/yr; named arrests — Ronald Spektor ~$6.5M, Christian Nieves $4M+, plus an Indian call-centre ring) and examples/2026-01-hardware-wallet-social-engineering.md ($282M+ from a single individual; targets selected by scanning the UTXO set for large dormant balances).

    Both examples are currently mapped to T4.007, and the mapping does not hold. T4.007's scope is a paid-for or engagement-weighted in-platform mechanic the attacker manipulates to occupy visibility (comment-pinning, reply-ranking); its Polymarket anchor and its "the attacker buys visibility through a legitimate platform mechanic" primitive do not reach a spoofed phone call, where there is no platform, no mechanic, and no visibility auction. No other v0.1 Technique reaches it either: T11.007.003 is parented under hardware-wallet compromise and scopes channel-counterfeiting of a vendor's communications (email, physical mail, companion apps, firmware flows — not voice, and not exchange support); T15.001 scopes operator-side personnel whose access gates a downstream signing surface, explicitly carving out the end-user case; T4.010's artefact is a counterfeit tool rather than a channel.

    The gap is load-bearing rather than cosmetic: it is the surface OAK-M45 exists to mitigate, and M45 currently under-declares its coverage because there is nothing correct to map to. Promotion needs a decision on scope — whether the Technique is voice-specific, or a channel-agnostic "impersonation of a custodial relationship the holder already has", which would also give the hardware-wallet-support case a home that T11.007.003 currently strains to hold.

  • QR-code phishing as an entry vector — relevant across T4 generally; merits a standalone Technique stub if the QR-specific surface (mobile-wallet UX, malicious WalletConnect QR codes) warrants one.

  • iOS / Android push-notification compromise — promoted to emerging as OAK-T4.011; see techniques/T4.011-push-notification-infrastructure-compromise.md. Anchored: CoinStats Jun 2024 (~$1M, ~1,590 wallets).

  • Clipboard-hijacker (clipper) address substitution — promoted to emerging as OAK-T4.012; see techniques/T4.012-clipboard-hijacker-clipper-address-substitution.md. Anchored: 2026-06 Microsoft CryptoBandits USB-worm clipper + 2026-06 Check Point Rust-clipper "Ghost Network" campaign (two independent same-week anchors); historical class precedents CryptoShuffler (2017) and the trojanised Tor Browser clipper (2023). Fills a long-standing gap — host-side real-time clipboard substitution is distinct from T4.003 (on-chain wallet-history poisoning) and from the Bybit-class sign-time signing-infra swap.

    • T4.012.001 Removable-media / worm-propagated clipper (forward candidate) — proposed sub-Technique of T4.012 for clippers delivered by a removable-media (USB) .lnk worm that auto-executes on drive insertion and re-propagates via scheduled tasks. Field anchor: 2026-06 Microsoft CryptoBandits (Trojan:Win32/CryptoBandits.A / ClipBanker.USB); see examples/2026-06-cryptobandits-usb-worm-tor-clipper.md. Promotion to emerging once a second independent USB-worm-propagated clipper is documented.
    • T4.012.002 Reputation-laundered fake-software clipper distribution (forward candidate) — proposed sub-Technique of T4.012 for clippers distributed through manufactured cross-platform reputation ("Ghost Networks": fake reviews, AI-narrated tutorial videos, manipulated VirusTotal votes, decoy GitHub/SourceForge repos, syndicated press releases) wrapping trojanised "trading tools." Field anchor: 2026-06 Check Point Rust clipper, operator @JoseCmanXD; see examples/2026-06-rust-clipper-fake-reputation-ghost-network.md. Promotion to emerging once a second independent reputation-laundered clipper-distribution campaign is documented.

  • Endpoint infostealer wallet-material & credential exfiltration — promoted to emerging as OAK-T4.013; see techniques/T4.013-endpoint-infostealer-wallet-credential-exfiltration.md. Anchored: 2026-06 Kaspersky Steam Workshop / Wallpaper Engine campaign (Lumma + Vidar infostealers); historical class anchor allInVain wallet.dat (2011); trusted-platform delivery precedent Chemia (2025-07). Fills a long-standing gap — commodity stealer malware harvesting wallet vaults / keystores / sessions off a consumer endpoint at rest had no clean home (T11.006 scopes third-party storage; T15.003/T15.004 scope operator endpoints; the 2011 allInVain case was forced into T15 "broadly construed"). Distinct from T4.012 (clipper substitutes one in-flight destination; T4.013 takes the standing keys) and T4.010 (counterfeit extension is itself the tool; T4.013 scrapes existing legitimate wallets).

    • T4.013.001 Trusted-platform content-channel malware distribution (forward candidate) — proposed sub-Technique of T4.013 for crypto-stealing malware delivered through a legitimate first-party platform's user-generated-content or game-distribution channel, so the payload inherits the platform's trust (e.g. Steam Workshop executable "application" wallpapers; trojanised Steam Early Access games). Field anchors: 2026-06 Kaspersky Steam Workshop / Wallpaper Engine (Lumma/Vidar), see examples/2026-06-steam-workshop-wallpaper-engine-infostealer.md; 2025-07 Prodaft Chemia (Vidar/Fickle/Hijack Loader) and the FBI's 2026 Steam-malware investigation (PirateFi, BlockBlasters). Promotion to a first-class sub-Technique once the Steam-platform anchors are consolidated into per-incident worked examples. Natural companion to T4.012.002 (synthetic reputation network) — here the trust channel is a single genuinely-trusted platform.

T5 — Value Extraction (additions for v0.x)

T6 — Defense Evasion (additions for v0.x)

T7 — Laundering (additions for v0.x)

T8 — Operational Reuse (additions for v0.x)

  • Off-chain operator fingerprinting (TLS, hosting, code-style, social-handle-pattern reuse).
  • Time-of-day / geographic operator profiling.

T9 — Smart-Contract Exploit (additions for v0.x)

  • Cross-contract logic flaws / re-initialisation attacks — promoted to stable as OAK-T9.009; see techniques/T9.009-cross-contract-reinitialization-attack.md.
  • Diamond-pattern-specific facet-audit-incomplete cases — promoted to emerging as OAK-T9.008; see techniques/T9.008-diamond-pattern-facet-audit-incomplete.md. Anchored: Li.Fi Jul 2024.
  • Fork-substrate-vulnerability-not-mitigated-at-fork-time — promoted to stable as OAK-T9.007; see techniques/T9.007-fork-substrate-vulnerability-not-mitigated.md. Anchored: Hundred → Midas → Sonne → Onyx → Resupply cohort.
  • Protocol-client consensus bug — promoted to emerging as OAK-T9.014, then to stable on 2026-09-07; see techniques/T9.014-protocol-client-consensus-bug.md. Anchors: 2010-08 Bitcoin value overflow bug (block 74638, CVE-2010-5139); 2026-06 Zcash Orchard circuit under-constraint disclosure; 2026-09 Liquid Network unbacked L-BTC peg-out (~$320M / 3,996 BTC), the second full-exploit anchor and the first outside Bitcoin Core. Promotion basis is the VERSIONING.md bar of ≥ 3 anchored worked examples plus multi-source attestation, read as in the T11.004 precedent — the forensic chain is attested independently, not the existence of a runtime detector, which T9.014 still lacks. Liquid also widened the class's understood shape from arithmetic to any consensus-critical validation short-cut: its defect was a verification cache whose key omitted the asset commitment and output script, so a correct proof was reused in a context where it did not hold. Pipeline targets (now strengthening rather than gating): Bitcoin CVE-2018-17144; Bitcoin 2013 LevelDB hard-fork incident.
  • Degenerate-input signature-verification bypass — promoted to emerging as OAK-T9.015; see techniques/T9.015-degenerate-input-signature-verification-bypass.md. Anchored: 2026-07 Bonzo Lend / Supra on-demand oracle verifier (~$9.05M on Hedera), where an all-zero signature field against a zero-point public-key reference satisfied the pairing equation trivially and was accepted as a committee signature. Fills a real gap: T9.001 describes only the outcome (an inflated price consumed as collateral) and implies an oracle-resilience mitigation family that assumes the attacker moved a real market — nobody moved SAUCE, so TWAP/multi-venue are irrelevant and only the deviation breaker (M09) helps, and it bounds rather than closes. T10.002 captures the mechanism honestly but sits under T10 (Bridge / Cross-Chain) and its examples are uniformly application-layer logic defects at a bridge boundary. The distinction OAK preserves: application-layer check missing (T10.002) vs. cryptographic primitive returning true on degenerate input (T9.015) — different owners, different audit scopes, different fixes. Promote to stable on a second independent on-chain anchor. Pipeline target / forward candidate: T9.015.001 degenerate inputs to zero-knowledge proof verifiers (identity or off-subgroup elements in a Groth16/PLONK proof or verifying key) — same defect class, different primitive. Anchored 2026-09-12: Veil Cash (2026-02-20, Base, 2.9 ETH), whose deployed Groth16 verifying key had delta2 equal to gamma2 — both left as the BN128 G2 generator, the template default — collapsing pairing soundness so that proofs for arbitrary public inputs verified with no witness; 29 withdraw() calls in one transaction emptied the pool, and FoomCash was drained through the identical misconfiguration days later. See examples/2026-02-veil-cash-groth16-verifying-key-delta-gamma-forgery.md. The anchor sharpens the definition before minting: Bonzo's degenerate element was in the message (attacker-supplied, rejectable by input validation), Veil's is in the key (supplied once at deployment, validated by nobody, and exploitable by everyone from that moment). Record which element was degenerate and who supplied it — that field decides whether the mitigation is input validation, ceremony verification, or a deployment assertion.
  • T9.004.001 Standing-authorisation residue in periphery contracts (forward candidate, proposed 2026-09-12) — proposed sub-Technique of T9.004 for the case where a helper, bundler, router or settlement contract that spends standing user approvals fails to derive authority from the caller, so anyone can direct it to move a third party's assets. The corpus holds three anchors spanning three years and three asset classes: Exactly Protocol (2023-08-18, ~$7.3M, Optimism — DebtManager.leverage() took a market address and a permit as arguments and validated neither); Gondi (2026-03-09, ~$230K, Ethereum — a PurchaseBundler shipped seventeen days earlier did not check the caller against the NFT, and 78 NFTs left wallets whose loans had already closed); ether.fi / Veda AtomicQueue (2026-09-11, 15.45 ETH, Ethereum — solve() accepted the solver address from the caller, against a contract that had been deprecated and still held approvals). Why it is not just T9.004: that Technique's other anchors are permission defects in core protocol logic where the victim is the protocol. Here the victim is a user who has stopped transacting, the exposure is an approval set rather than a balance, and the detection surface is grants rather than holdings — enumerable by anyone from Approval / ApprovalForAll logs, including by the protocol, before an attacker does it first. Distinct from T4.004 / T4.005, where approvals are obtained by deception; nothing here is phished. Distinct from T11.013, which covers the legacy-version decision — the residue overlaps only in the ether.fi case, and Gondi shows the class does not need a deprecated contract, just a new one that ships without the check. Mitigation is structural: re-derive authority from msg.sender, prefer scoped or per-transaction authorisation over standing approvals, and make revocation part of shipping a new version rather than advice issued after an incident. Promotion to emerging is justified on anchor count; held as a candidate pending a scope decision on whether it sits under T9.004 or beside T4.004 as an authorisation-lifecycle class.
  • T9.011.001 Split-invariance violation in size-dependent pricing (forward candidate) — proposed sub-Technique of T9.011 for the case where executing a position in n small calls extracts more value than executing it in one, because the price a user receives is path-dependent. Distinct from the T9.011 anchors, whose defect is rounding direction under integer division: here the arithmetic is exact and the flaw is the shape of the pricing function — typically an arithmetic mean over start and end price, which charges a single large trade for its full impact while charging each fragment of a split trade for a slice of its own. The shared T9.011 primitive holds (accounting-math defect whose value accrues across many small transactions), which is why it is proposed as a sub-class rather than a peer. Field anchor: 2026-08 USM Protocol (~$136K / 70.83 ETH; a flash-loaned fund() moved internal pricing, then the same FUM amount redeemed through 64 small defund() calls paid more than one large call would have); see examples/2026-08-usm-defund-split-arithmetic-mean-redemption-pricing.md. The mitigation is a property test, not a runtime control: for any position X and split X = x₁ + … + xₙ, the parts must never out-pay the whole net of fees. Surface is broad and growing — bonding curves, AMM redemptions, vault share pricing, mint/burn pairs, any redemption path with size-dependent pricing. Promotion to emerging once a second independent anchor is documented; small individual losses are expected in this class because the defect surfaces first on protocols too small to have been fuzzed.
  • T9.006 Subjective-Oracle Resolution Manipulation (parent) — promoted to emerging; see techniques/T9.006-subjective-oracle-resolution-manipulation.md. Sub-Techniques:

T10 — Bridge and Cross-Chain (additions for v0.x)

  • T10.002.001 Off-chain Observer Source-Event Forgery — promoted to emerging on its second independent anchor (2026-08-09 Coreum–XRPL); see techniques/T10.002.001-off-chain-observer-source-event-forgery.md. Renamed at promotion from the draft title "Off-chain observer event-parse forgery": the second anchor does not fail at the parse step at all, so a parse-specific name would have excluded it. The promoted Technique carries two sub-shapes — (a) parse-level, where the observer reconstructs an event from raw chain data and never checks that the data is that event (Across: the 8-byte Anchor discriminator), and (b) semantic / custody-level, where the observer validates a well-formed message's fields but never the fact it asserts (Coreum: memo amount and recipient checked, actual XRP receipt never checked). Fix differs by shape — a type-identity check for (a), a custody-state read for (b) — while the shared control is release on state, not on events. Promotion to stable awaits a third independent anchor, ideally from the intents/solver population. Original candidate framing retained below for audit trail. Proposed sub-Technique of T10.002 for the case where the verification predicate that fails sits in an off-chain observer (relayer, filler, solver, indexer) that decides a source-chain event occurred, rather than in deployed on-chain bytecode. The shared T10.002 primitive holds — value is released against a message that should have been rejected — but the failing check is in Rust/TypeScript infrastructure that receives indexer-grade review while carrying contract-grade authority, which is why it is proposed as a distinct sub-class rather than folded into the existing anchors. All three current T10.002 anchors are on-chain contract predicates: Wormhole's unvalidated guardian account (2022-02), Nomad's 0x00 trusted root (2022-08), and Verus's missing source-amount conservation check (2026-05). Field anchor: 2026-07 Across / Risk Labs on Solana (~$4.5M; the off-chain relayer did not verify the 8-byte Anchor event discriminator when reconstructing deposit events from transaction traces, so transactions that moved no funds emitted data parsing as valid deposits — 1,627 forged deposits across 18 destination chains at ~$41.7M face value, 581 filled); see examples/2026-07-across-solana-relayer-anchor-event-discriminator-forgery.md. Substrate note: Solana has no canonical event system, events are reconstructed from transaction traces, and failed transactions still emit data — so every Solana event consumer shares this hazard and the discriminator check is the mitigation. Promotion to emerging once a second independent off-chain-observer anchor is documented; expect them, given how fast the population of intents-based fillers and solvers making value decisions from parsed chain events has grown. (Realised in 23 days: the second anchor arrived 2026-08-09.)

  • T10.009 Cross-Chain Token Configuration-Role Capture — promoted directly to emerging on two independent anchors already in the corpus; see techniques/T10.009-cross-chain-token-configuration-role-capture.md. Anchored: 2026-05 Stake DAO vsdCRV (OFT peer redirect) and 2026-08-22 The Sandbox SAND (OFT delegate hijack via approveAndCall; ~14.9B unbacked SAND minted, ~$675K realised). Three months apart, no shared application code, no shared chain pair, no shared entry path — only the standard. Promoted rather than parked as a candidate because the second-anchor bar was already met at proposal time, and both examples were carrying mappings that misdescribe them: T10.006 requires a governance action approved on one chain and relayed to another, and in neither case was anything relayed or any proposal created. Both were remapped as part of the promotion. The class is separated from T9.004 (which describes only how the role becomes reachable) because the consequential fact is what the role is — the token's cross-chain identity, i.e. the authority to declare what a legitimate peer is or who may reconfigure messaging — which converts directly into unbacked issuance on remote chains while the canonical deployment stays untouched. Generalises beyond LayerZero to Wormhole NTT manager/transceiver roles, CCIP token-pool administration, and Hyperlane warp-route ownership. Detection spec shipped alongside (specs/T10.009-*.yml); its PATH A is a genuine rare-event signal, since these values are set at deployment and legitimately change a handful of times in a token's life. Promotion to stable awaits a third anchor, ideally from a non-LayerZero standard, which would confirm the class is a property of omnichain token wiring rather than of one implementation.

T11 — Custody and Signing Infrastructure (additions for v0.x)

T12 — NFT-Specific Patterns (additions for v0.x)

  • ✅ RESOLVED 2026-07-17 — T12.004 and T12.005 were misfiled and are now deprecated tombstones. The deprecate-and-supersede decision recorded below as "blocked on a maintainer call" was taken: T12.005 → OAK-T16.001 (duplicate) and T12.004 → OAK-T16.006 (new T16 sub-Technique, content carried across intact). Both IDs remain in-repo marked Maturity: deprecated with pointers, per CONTRIBUTING.md, and are never reused — so the next free T12 IDs are T12.006 onward. Consequence for anyone reading coverage tooling: the two files legitimately have no example backlinks and no detection specs, which is correct for a tombstone and is not a coverage gap. T12's real Technique count is five (T12.001–T12.003, T12.006, T12.007). Original framing retained below for audit trail. ⚠ MISFILED, pending a deprecate-and-supersede decision: T12.004 and T12.005 are not NFT Techniques. T12's scope is attack classes structurally tied to non-fungible token semantics; T12.004 (Timelock-Free Protocol Upgrade Execution) and T12.005 (Flash-Loan Governance Vote Manipulation) contain nothing NFT-specific. Their correct parent is T16 (Governance / Voting Manipulation). Both files declared their parent as "OAK-T12" under the label "Governance / Protocol Management" — a Tactic name that exists nowhere in the taxonomy, and which is precisely what kept the misfiling invisible to review. The names are now corrected to T12's real name so the mismatch is legible in the files themselves.

    T12.005 is additionally a probable duplicate of T16.001 (Vote Takeover via Flash-Loan): same mechanism (same-block flash-borrow of governance tokens to carry a proposal, repaid in the same transaction), overlapping alias sets (both list "flash-loan governance attack"), and the same canonical anchor (Beanstalk, April 2022). T12.005 additionally cites Fortress Protocol and Elephant Money. If confirmed, the corpus currently carries one Technique under two IDs, one of them parented under NFTs — which also means the T16.001 and T12.005 example counts are splitting a single population.

    T12.004 appears unique but misparented — T16 has no timelock sub-Technique today, so this is not a duplication, only a wrong parent.

    Resolution is blocked on a decision, not on research: CONTRIBUTING.md fixes that published IDs are never reused and that superseded entries stay in-repo marked Maturity: deprecated with a pointer. So the fix is deprecate-and-supersede (T12.005 → T16.001; T12.004 → a new T16.00x), which moves the Technique count and the SPECS coverage denominator, and is therefore a maintainer call rather than a cleanup. Not covered by TAXONOMY-AUDIT.md — that audit closed at 93 sub-Techniques and these were added afterwards.

  • NFT-collateral lending exploits — promoted to emerging as OAK-T12.006; see techniques/T12.006-nft-collateral-lending-manipulation.md. Anchored: XCarnival (2022-06, 3,087 ETH / ~$3.8M — collateral-state desynchronisation: the borrow path never re-checked whether the pledged NFT was still in custody, so one BAYC backed unbounded borrowing) and Omni Protocol (2022-07, 1,300 ETH / ~$1.4M — ERC-721 safeTransferFrom callback re-entered across two unguarded functions). Pipeline anchors for stable: ParaSpace (2023-03, valuation shape), Astaria (2024, proxy surface), BendDAO (2022-08, auction-design failure with no attacker).

  • Mint-outcome reroll (revert-until-rare) — promoted to observed as OAK-T12.007; see techniques/T12.007-mint-outcome-reroll-revert-until-rare.md. Single field anchor: Meebits / Larva Labs (2021-05, 200 ETH single-sale realisation) — observed rather than emerging per VERSIONING.md, since the pattern is field-confirmed at one anchor and awaiting cross-vendor attestation. The class attacks distribution fairness, moves no assets, and is closed structurally by delayed reveal; retained because novel issuance mechanics keep re-introducing its precondition (outcome knowable and priceable inside the minting transaction).

  • T12.008 Hybrid fungible / non-fungible standard accounting divergence — promoted to observed; see techniques/T12.008-hybrid-fungible-non-fungible-accounting-divergence.md. Minted at observed rather than held as a candidate because VERSIONING.md defines that tier as exactly this state — field-confirmed at a single anchor, awaiting cross-vendor attestation — and because an example cannot reference a top-level candidate ID that has no parent Technique file to resolve through (tools/check_tags.py). Original candidate framing follows. Proposed sub-class for protocols that maintain two representations of the same asset in one contract — an ERC-20 balance and per-tokenId ownership — as ERC-404 / BT404-style hybrids and NFT fractionalisation designs do by construction. The exploitable surface is the seam, not either representation: the two views must agree, and packed-storage implementations create identifier readings that satisfy one view while resolving differently in the other. Field anchor: 2026-06 Flooring Protocol V2 / BitmapPunks (initial reporting >$900K, 68 NFTs worth >$500K rescued by Yuga Labs-linked white hats; a malicious high-bit token-ID alias produced "ghost ownership" past an ownership check, and an unchecked balance underflow then turned a small WETH deposit into a near-unlimited fpToken balance used to drain pools and redeem locked NFTs); see examples/2026-06-flooring-protocol-bt404-ghost-ownership-underflow.md. Contagion note: the fork Asterix was exploited on the same unfixed logic after disclosure (T9.007). Weak second data point pending write-up: the ERC-404 project Rugged Art (reentrancy, ~11 ETH). Promotion to emerging once a second independent hybrid-standard anchor is documented; the controlling mitigation is a runtime cross-representation invariant (Σ fungible supply ⟷ escrowed token count), not better arithmetic.

  • Marketplace listing manipulation beyond OpenSea front-running stale-listing — still open. A 2026-02 forum listing advertised an alleged OpenSea zero-day exploit chain (claimed forced zero-ETH NFT transfers via signature malleability, bypassing listing approvals); no matching on-chain thefts surfaced and OpenSea issued no confirmation, so OAK does not treat it as an incident and it is recorded here only as an unverified capability claim.

  • Real-world-asset (RWA) NFT bridge surfaces — still open, no anchor.

T13 — Account Abstraction Attacks (additions for v0.x)

  • Specific paymaster-vulnerability subclasses as the ERC-4337 deployment substrate matures.
  • Smart-wallet recovery-flow exploitation — covered by OAK-T13.003 (Session-Key Hijacking); see techniques/T13.003-session-key-hijacking.md. Loopring Jun 2024 and Argent 2023–2024 guardian-recovery cases are anchored under T13.003.
  • Cross-bundler MEV variants beyond T13.002.
  • T13.004 EIP-7702 Delegation Abuse — promoted to emerging; see techniques/T13.004-eip7702-delegation-abuse.md. Anchored: 2025-05 CrimeEnjoyor cohort (>$12M cumulative, 15,000+ wallets).

T14 — Validator/Staking/Restaking Attacks (additions for v0.x)

T15 — Off-chain Entry-Vector / Pre-Positioning (additions for v0.x)

  • OAK-T15.007 Fabricated Institutional Identity as Pretext Substrate (forward candidate) — a social-engineering approach whose credibility rests on a manufactured affiliation with a real organisation the target has no prior relationship with: a lookalike domain registered for the campaign, a mailbox that passes SPF because the attacker genuinely owns that domain, and a disposable platform account whose profile claims employment at a well-known firm. The impersonated organisation is never touched. It supplies borrowed credibility and absorbs reputational use without being breached, which is why it never appears in incident reporting as a party.

    No existing Technique reaches it. T15.006 requires compromise of a real verified account; here nothing was compromised and the account was created by the attacker days before use. T15.005 scopes takeover of an operator's own communication channel. The T4 / T5 / T6 / T11.005 impersonation family (T4.008 clone frontends, T4.009 brand-anticipation phishing, T5.007 brand-impersonation soft-rug, T6.006 counterfeit tokens, T11.005.x fake platforms) is uniformly victim-facing and transaction-seeking — a holder is asked to trust a brand and then to sign, deposit, or connect. Here no transaction is ever solicited, and the target is operator-side personnel rather than a holder. T15.001 does name credibility-laundering in its Observed indicators, but as a property of a pretext rather than as a surface with its own detection and mitigation, so the identity layer currently maps nowhere.

    The gap is load-bearing rather than cosmetic. The detection surface is distinct and unusually cheap to work: domain age measured against first contact, platform-account age measured against first contact, and out-of-band confirmation that the claimed employee exists at the claimed employer — all checkable before any payload is offered, and all independent of whether the eventual payload is detectable. The mitigation surface is distinct too, and it has a second beneficiary: the impersonated organisation has standing to act (brand monitoring, registrar takedown, employee-verification endpoints) and at present OAK offers no home for what was done to it.

    Field anchors: examples/2026-08-onchainattack-maintainer-fake-assessment-lure.md — first-party collection, two organisations impersonated in one campaign at different stages: a genomics company's name on a recruiter domain registered 78 days before use, and a major Ethereum software firm claimed by a delivery account created 9 days before use whose profile was completed 70 seconds after creation and never touched again. Also examples/2025-06-pepe-creator-nft-contract-hijack.md (fake-IT-worker identity). Structurally adjacent but distinct: Radiant Capital 2024-10 impersonated a real former contractor the organisation already knew — trust transferred from an existing relationship rather than borrowed from an institution the target has never dealt with — and that sub-shape is already carried by T15.001.

    Promotion to emerging needs two things: a scope decision on whether borrowed-institution and impersonated-known-person are one Technique or two, and a second independent anchor documenting the fabricated-affiliation layer with primary-source evidence of the identity itself — registration dates, account age, claimed affiliation — rather than only of the payload it delivered. Most public reporting on this campaign class documents the malware and discards the persona, which is precisely why the surface has stayed unmapped.

Speculative Techniques pending field anchor

Techniques published in v0.1 with Maturity: speculative because the threat surface is well-characterised in academic / protocol-research literature but no field-confirmed external-attacker incident anchors the Technique. Each is held in this section until a primary-source-anchored externally-attributed incident is catalogued, at which point it is promoted to emerging or observed and removed from this list.

  • (empty at v0.x) — OAK-T14.001 was promoted to emerging via the operator-side correlated-self-slashing sub-case (e) anchor (2025-09 SSV-Network event). Adversarial sub-cases (a)–(d) within T14.001 remain forward-looking surfaces tracked in the Technique file's discussion section but the Technique as a whole is no longer speculative.

Missing methodological axes

Beyond Techniques themselves, OAK v0.1 lacks several first-class concepts that comparable frameworks treat as separate axes.

STIX 2.1 export

Tactics × Techniques × Mitigations × Software × Groups × Data Sources × Relationships are emitted as an OAK-native machine-readable bundle at tools/oak.json (schema v2). A STIX 2.1 export at tools/oak-stix.json is delivered at v0.1 (601 SDOs/SROs). Onward integration with TIPs, SIEMs, and threat-intel platforms is a v0.x adoption-paced work item.

Campaigns axis

A discrete first-class object class for multi-incident threads (an operator running a coherent operation across multiple targets in a discrete operational period). OAK Worked Examples cover individual incidents; cross-incident Campaign aggregation (e.g., the 2022-2024 OAK-G01 TraderTraitor cohort of exchange-vendor compromises) is documented in cross-references but not as a discrete first-class object. v0.x candidate.

Assets axis

A discrete first-class object class for what is being attacked: token contracts, AMM pools, oracle contracts, multisig wallets, bridge contracts, validator key sets, custody-vendor signing infrastructure. OAK Techniques reference assets in prose but not as a discrete first-class object. v0.x candidate.

Data-component decomposition

Sub-entities of Data Sources representing specific event types (e.g., DS "On-chain transaction" → "Token transfer event", "Approval event", "Pool-creation transaction"). OAK Data Sources are flat at v0.1; sub-component decomposition is a v0.x candidate.

False-positive characterisation

The per-Technique template includes "false-positive notes" but at v0.1 these are mostly placeholders. Real FP analysis (rates, root causes, mitigations) is a v0.x work item.

Detection-test corpus

The cited datasets ([solrpds], [tmrugpull2026], [frp2025], [xia2021mintdump], [victor2021washtrade]) collectively contain enough labelled examples that an evaluation harness could ship as a separate oak-eval/ repo. This is one of the highest-leverage post-v0.1 work items, because it operationalises every "Detection signal" claim across the framework.

Pre-launch verification debt

Tracked at the repository level rather than the per-axis level:

  • ~520 vendor-side citation stubs marked OAK v0.1 — pending verification — resolved at v0.1. Bulk URL audit completed via tools/verify_citations.py; all 964 entries now carry an explicit status (verified / verified-with-caveat / url-not-pinned / url-broken); 0 entries remain in pending verification. The residual url-not-pinned set (entries where the canonical URL was not findable at v0.1 audit) is community-paced post-launch sweep work.
  • Site MVP per-Technique detail page rendering the relationship graph — delivered at v0.1. See src/App.tsx.
  • README / CONTRIBUTING / COVERAGE / CHANGELOG kept current with each phase commit.

How this file evolves

When a v0.x update closes an item, that item is deleted from this file (not crossed-out — the document tracks current scope, not history; history lives in CHANGELOG.md). Items remaining are the live gap inventory at all times. Contributors are encouraged to file proposals against any item using the relevant template in .github/ISSUE_TEMPLATE/ (issue templates pending v0.x).