OAK — OnChain Attack Knowledge

Worked example · 2024-09

Solana Token-2022 PermanentDelegate burn-on-buy cohort — Solana — 2024-09 onward

Loss
undisclosed at cohort scale; per-victim losses typically in the $50–$5,000 band per buyer (the dominant operator profitability shape per Slorg's published observation: "scammers don't need more than $50 in profit to make it worthwhile"). Cohort prevalence: PermanentDelegate-bearing mints have constituted a meaningful fraction of new Solana Token-2022 launches from Q3 2024 onward per RugCheck and Jupiter pre-trade telemetry, with the burn-on-buy variant the dominant malicious sub-pattern.
OAK Techniques observed
OAK-T1.002 (Token-2022 Permanent Delegate Authority) as the primary genesis-time enabling Technique. OAK-T6 (Defense Evasion) as a layered modifier — the malicious mints commonly co-deploy MintCloseAuthority, freeze authority, or transfer-hook extensions alongside the PD authority to compound the operator surface. The class is a clean per-incident anchor for T1.002 because the failure mode is binary (PD-extension presence + delegate-clustered-with-deployer + post-mint burn against non-deployer holder = confirmed malicious) and the public reporting pattern names specific tokens (RED is the canonical early example surfaced by Jupiter Core Working Group member Slorg in early September 2024).
Attribution
pseudonymous Individual deployer wallets are observable on-chain but rarely publicly named beyond mint address and delegate authority address. Cohort-scale attribution to a single operator group has not been publicly established at v0.1; the templated re-deployment pattern is consistent with multiple distinct operator clusters reusing the same primitive rather than a single operator scaling.
Key teaching point
PD-extension presence is a one-shot RPC-call detection signal — getAccountInfo on the mint, parse the extension TLV, check for PermanentDelegate (extension type 12) — and yields a deterministic boolean rather than a heuristic. The cohort exists at scale because the detection signal is unambiguous and the wallet / venue UX surface that would block trading on PD-bearing mints was not uniformly deployed across the Solana retail surface in Q3-Q4 2024. Detection-tooling exists; UX-side blocking is the binding constraint.

Summary

The Solana Token-2022 program's PermanentDelegate extension grants a designated address standing authority to move or burn any holder's balance without holder consent or per-call delegation. The semantics are well-defined and documented in the SPL Token standard and were intended to support legitimate use cases such as compliance-gated stablecoins, regulated securities, and refund / clawback flows for KYC-bound tokens.

Beginning in approximately Q3 2024, the cohort of malicious Token-2022 mints exploiting the PD extension as a "burn-on-buy" rug-pull primitive expanded substantially. The dominant operator pattern, surfaced publicly by Jupiter Core Working Group member Slorg in early September 2024 via the named example of the RED token, follows three steps:

  1. Deploy a Token-2022 mint with the PermanentDelegate extension; assign the PD authority to a deployer-controlled address (frequently the same EOA as the mint authority, or a wallet funded from the same source).
  2. Seed a Raydium / Meteora / Orca pool with the mint and an SOL or stablecoin pair; promote the token across Solana memecoin discovery surfaces (pump.fun adjacent, Telegram channels, X memecoin trader accounts).
  3. As retail buyers swap into the token through the pool, the PD authority signs BurnChecked instructions against the buyers' associated token accounts within seconds of purchase. The buyer's tokens vanish; the LP-side SOL / USDC remains under operator control. Slorg's documented case shows a burn transaction firing 7 seconds after the swap.

The economic shape per Slorg: "If someone can't sell, the price won't decrease. Many of the times scammers snipe most of the initial supply and the thing is they don't need more than $50 in profit to make it worthwhile." The cohort is therefore high-volume / low-per-incident, which makes it visible at the aggregate prevalence layer (RugCheck dashboards, Jupiter pre-swap warnings, GoPlus token-security API output) but rarely the headline framing in any individual-incident write-up.

The class-level forensic surface is well-developed: Neodyme's Token-2022 advisory ([neodyme2024token2022]) documented the PD extension's misuse class pre-incident; Solana Foundation's official extension documentation ([solana2024permdelegate]) names the misuse failure mode explicitly; and Q3 2024 onward saw a wave of secondary-source coverage (Coinspeaker, Cointelegraph via TradingView News, Bitdegree, Coinpaper, Voice of Crypto) anchoring the cohort to the RED example and the broader pattern.

Why this is structurally significant

T1.002 is OAK's first chain-specific Technique whose detection surface is not a heuristic. The PD extension's presence on a mint is a deterministic boolean readable from one RPC call. The technique should in principle be defeatable at the wallet / venue UX layer with near-zero false positives — yet the cohort exists at scale through Q3-Q4 2024 and into 2025. The structural reason is that detection is solved; UX-side blocking and listing-time gating are the binding constraints.

Three structural features distinguish the cohort:

  1. The detection signal is binary, not gradient. Unlike T1.001 (Modifiable Tax) or T1.005 (Hidden Fee-on-Transfer) where the operator surface is mutable arithmetic and detection requires simulation matrices, T1.002 detection is a single RPC call against the mint config. The operator cannot mutate the extension list post-mint without the existing delegate authority, so the static check is also temporally stable.

  2. The UX surface is the binding constraint. Jupiter's pre-swap warning UI for PD-bearing mints is the canonical defender-side intervention pattern; it surfaces the extension presence and requires explicit user acknowledgement before allowing a swap. RugCheck publishes the same signal at its risk-attribute layer. The cohort persists because (a) not all wallets and aggregators surface the warning, (b) some users dismiss the warning under FOMO conditions, and (c) the launch-and-discovery surface (memecoin Telegram channels, X memecoin accounts) routes around the wallet UX entirely.

  3. The legitimate-use overlap is structurally narrow. Compliance-gated stablecoins (USDC variants, regulated securities tokens) and KYC-bound tokens are the only well-defined legitimate uses of PD. The legitimate-use cohort is small enough that a vetted-delegate allowlist (analogous to the timelock allowlist for T1.001 and the issuer allowlist for T1.004) is operationally tractable. v0.1 lacks a published allowlist schema; v0.x should formalise one.

The cohort is the Solana-side analogue of the EVM honeypot cohort (T1.004 + T1.005) but with a structurally cleaner detection surface and a different binding constraint (UX-side blocking rather than detection-tooling maturity). The framing matters because OAK's defender-practice guidance for the two cohorts diverges: for EVM honeypots the operator's leverage is in evading detection; for Solana PD honeypots the operator's leverage is in bypassing UX warnings.

Timeline (UTC)

When Event OAK ref
Pre-2024-Q3 SPL Token-2022 program ships PermanentDelegate extension as part of the broader Token Extensions feature set; legitimate compliance / refund use cases documented in Solana Foundation guides (genesis surface)
2024-09 (early Sep) Slorg (Jupiter Core Working Group) publishes the RED token observation: PD-bearing mint burns buyer's tokens 7 seconds after swap; Coinspeaker covers the disclosure T1.002 cohort surface
2024-09 onward Cohort expansion: Cointelegraph (via TradingView News), Bitdegree, Coinpaper, Voice of Crypto, Altcoin Buzz, CryptoTimes secondary-source coverage anchors the burn-on-buy pattern to additional named tokens T1.002 cohort recurrence
2024-Q4 Jupiter aggregator deploys pre-swap warning UI for PD-bearing mints; RugCheck surfaces PD presence as a discrete risk attribute (defender response — UX-layer mitigation)
2025 onward Cohort persists; per RugCheck dashboards, PD-bearing mints continue to constitute a meaningful fraction of new Token-2022 launches; per-incident named cases beyond the cohort scale remain thinly reported in forensic write-ups (continuing surface)

What defenders observed

  • Pre-event (mint-extension layer): PD presence is detectable at mint creation via the standard Token-2022 program's extension TLV layout. A streaming indexer can flag every new PD-bearing mint within the same block as creation. Helius, Triton, and standard Solana RPC providers all support this pattern. Defender lesson: detection is not the gap; the gap is what to do with the detected mint at the wallet / venue layer.
  • At-event (buy-side layer): the buy-side leg is structurally observable on-chain — a swap into the PD-bearing mint produces a Raydium / Meteora swap log followed by a BurnChecked instruction signed by the PD authority within seconds. The transaction-pair signature is the canonical post-incident confirmation; for the next victim, scanning the mint's recent transaction history for this pair pre-trade confirms hostile intent before exposure.
  • At-event (UX-layer signal): Jupiter's pre-swap warning surfaces the PD-extension presence to the user before the swap. The warning is conditioned on the wallet routing through Jupiter; direct Raydium / Meteora swaps via wallet-native UIs that do not surface the warning have higher victim conversion. The UX gap is the canonical 2024-Q3-Q4 defender-tooling shortfall surfaced by the cohort.
  • Post-event: burned tokens are not recoverable. The PD authority's BurnChecked is a destructive operation against the holder's associated token account; there is no on-chain reversal pathway. Operator-side response is limited to publishing the mint address as a known-bad and propagating the signal across wallet / venue blocklists. Recovery on the LP-side SOL / USDC requires the operator to be identified and prosecuted, which is rare at the per-incident scale.

What this example tells contributors writing future Technique pages

  • T1.002 detection is binary; the hard part is UX-layer enforcement. Future T1.002 contributors should focus on the enforcement surface (which wallets surface the warning, which aggregators block the swap, which venues delist the mint at listing time) rather than re-deriving the detection signal. The Jupiter pre-swap warning is the canonical pattern; the Raydium / Meteora wallet-native swap path is the canonical evasion surface.
  • The legitimate-use overlap is structurally narrow. A vetted-delegate allowlist (regulated-stablecoin issuers, KYC-bound-securities issuers) is operationally tractable and would resolve the false-positive concern without weakening the malicious-cohort detection. v0.x T1.002 work should formalise the allowlist schema.
  • Cross-extension stacking is a recurring sub-pattern. PD frequently co-occurs with MintCloseAuthority (operator can close the mint and reclaim rent), unrenounced freeze authority, and operator-controlled TransferHook. A multi-extension malicious mint compounds the operator surface and tends to appear in deliberately-malicious deployments rather than misconfigured legitimate-issuer mints. Future T1.002 examples should document the extension stack, not just PD presence.
  • The "$50 profitability" economic shape generalises. Slorg's observation that operator profitability per victim can be sub-$100 is an important defender-modelling input: the cohort is not bounded by per-incident size and will not be deterred by per-incident enforcement. The defender intervention surface is necessarily cohort-scale UX-layer blocking, not per-incident prosecution.
  • Distinction from accidental burns is structurally important. SLERF (March 2024) was not a PD-misuse incident — the developer accidentally burned ~50,000 SOL of presale-LP tokens via standard Burn calls after mint authority had been revoked. Future T1.002 contributors must preserve this distinction: PD-misuse and accidental-burn-by-revoked-authority are structurally different mechanisms with the same surface-level outcome.

Public references

Discussion

The Solana PermanentDelegate burn-on-buy cohort is the cleanest cohort case for T1.002 at v0.1. The named-incident shortfall — public forensic write-ups rarely name individual mints beyond contract addresses, and per-incident loss figures are typically too small to attract investigative-journalism coverage — is itself a structurally informative observation: the cohort is the unit of analysis, not the incident.

The cohort sits at an intersection that v0.x taxonomy work will eventually need to articulate explicitly: T1.002 is a Genesis-time Technique whose detection surface is structurally different from T1.001 / T1.004 / T1.005. The detection is binary and one-shot; the operator's leverage is in UX-layer enforcement gaps, not in evading detection tooling. Pairing this case with the EVM honeypot cohort (OAK-T1.006, see examples/2024-02-honeypot-token-cohort-cross-chain.md) forces the framework to grapple with the enforcement-surface axis: detection-tooling maturity does not directly translate into cohort suppression unless the wallet / venue / aggregator UX layer enforces the detected signal.

For OAK's broader cohort coverage, this case + the EVM honeypot cohort + the Hyperbridge counterfeit-mint case (examples/2026-04-hyperbridge-merkle-proof-counterfeit-mint.md) collectively establish that the fake / honeypot / malicious-by-design smart contract cohort is a cross-chain pattern with structurally distinct sub-surfaces per chain ecosystem. The cohort is the v0.x-priority gap that motivates the T1.006 (Honeypot-by-Design), T1.007 (Token-2022 Transfer-Hook Abuse), T6.005 (Proxy-Upgrade Malicious Switching), and T6.006 (Counterfeit Token Impersonation) sub-Technique proposals in TAXONOMY-GAPS.md.

Techniques demonstrated (2)