OAK — OnChain Attack Knowledge

Worked example · 2022-01

Arbix Finance audit-scope-mismatch rug pull — Binance Smart Chain — 2022-01-04

Loss
approximately $10M aggregate exit across multiple BSC token positions deposited by users into Arbix Finance's "depositor contract." Per CertiK's January-04 alert and contemporaneous reporting (BleepingComputer, Cointelegraph, Cryptopolitan, BankInfoSecurity, Infosecurity Magazine), the asset-side breakdown was approximately: ~$2.25M BSC-USD, ~$1.7M BUSD, ~$1.4M CAKE, ~$1.0M BSC-USDC, ~$920K Binance-pegged ETH (BETH), plus smaller balances of ADA, DOT, DOGE, LINK, XRP, and WBNB.
Recovery
none. The operator drained the deposits to "unverified pools," converted the BSC-side proceeds to ETH via cross-chain bridges, and routed the resulting ETH through Tornado Cash. The website, Twitter, and Telegram presence were deleted within hours of the drain. CertiK and CoinGecko confirmed the ARBX token price collapse to near-zero. No public-record law-enforcement action or recovery proceeding is associated with the case at the v0.4 reference cutoff.
OAK Techniques observed
OAK-T6.003 (Audit-of-Different-Bytecode-Version) — primary; the load-bearing evasion pattern was that Arbix Finance held a real CertiK audit on the ARBX token contract published in November 2021, but the user-deposit-routing contract (the "depositor contract" that received user-deposited stablecoins, BETH, CAKE, etc., and routed them to yield-pool destinations) was not in the audit scope. The deposited assets were directed to "unverified pools" (per CertiK's public callout) controlled by the operator-side. The audit-scope-vs-deployed-system gap is the canonical T6.003 anti-pattern: the audit certificate was real and registry-verifiable, but the audited contract was not the contract holding user funds at risk. OAK-T2.001 (Single-Sided Liquidity Plant — the operator deployed unverified depositor-contract pools that received user-deposited assets and routed them to operator-controlled yield pools; the pools appeared to be legitimate single-asset vaults but were structurally operator-controlled from deployment, constituting a liquidity-establishment trap where all deposited value was accessible to the deployer). OAK-T1.001 (Modifiable Tax Function) — not applicable here in the canonical sense. OAK-T5.003 (Hidden-Mint Dilution) — composing sub-pattern: the ARBX contract had eight mint() functions guarded by onlyOwner; ~10M ARBX were minted to 8 addresses controlled by the operator and ~4.5M ARBX were minted to a single key address (0x161262d172699cf0a5e09b6cdfa5fee7f32c183d), then dumped on-market. The mint()-functions-on-the-token-side combine with the unverified-depositor-pool routing on the system side to produce the dual-extraction pattern. OAK-T5.001 (Hard LP Drain) — composing sub-pattern: the unverified pools were drained directly by the operator-side (the operator was the deployer of the unverified pools and retained owner-side authority over their drain function). OAK-T7.001 (Mixer-Routed Hop) — laundering: BSC-side proceeds were converted to ETH and routed through Tornado Cash on Ethereum.
Attribution
pseudonymous. The operator cluster was identified at the funder-graph level (deposit-routing addresses, ARBX-mint-recipient cluster 0x161262d172699cf0a5e09b6cdfa5fee7f32c183d, depositor-contract deployer key) by CertiK's on-chain analysis and corroborated by independent forensic write-ups (BleepingComputer, BankInfoSecurity, Quadriga Initiative case study). No real-world identification has been published. The operator-side of the project (founders, developers, marketers) has not been linked to a named individual at the public-record layer.
Key teaching point
Arbix Finance is the canonical worked example of T6.003 (Audit-of-Different-Bytecode-Version) in the OAK corpus — the cleanest anchor for the audit-scope-mismatch anti-pattern where a real, registry-verifiable audit on one contract is leveraged as defensive-baseline marketing while the user-funds-at-risk contract is unaudited. The case demonstrates four structural lessons. First, audit-claim verification at the registry-lookup layer is necessary but insufficient — confirming the audit's existence in CertiK's published audit registry would have returned a confirmatory result, but would not have revealed that the depositor contract (where user funds went) was outside the audit scope. The load-bearing user-side mitigation is audit-scope verification — confirming that every authority-holding contract in the deployed system is in the cited audit's scope, not just the headline token contract. Second, the audit-firm-side public callout was the load-bearing defender response — CertiK's January 4 public alert (citing the unverified-pool routing as the canonical T6.003 signal) preceded the operator's website-deletion / social-media-takedown by hours, demonstrating that audit-firm post-deployment monitoring is a real-time defender capability when the firm has the contract-graph trace material. Third, T6.003 + T5.003 + T5.001 + T7.001 compose into the canonical "audited yield-farming rug" attack chain — the audit-scope mismatch creates the entry surface; the hidden mint inflates supply; the hard LP drain executes the extraction; the Tornado Cash routing executes the laundering. Future T6 contributions documenting yield-farming rugs should explicitly check for all four composing Techniques. Fourth, the "audited" defensive-baseline marketing claim is itself a load-bearing trust-substrate that adversaries actively target — the case demonstrates that adversaries in the 2022-era yield-farming surface deliberately obtain real audits on a non-load-bearing contract to leverage the audit-firm-brand-affiliation as marketing cover for the unaudited extraction surface.

Summary

Arbix Finance was a Binance Smart Chain-based yield-farming protocol that launched in late 2021 and marketed itself as an "arbitrage-focused yield platform" allowing users to deposit single-asset positions (BUSD, BSC-USD, BSC-USDC, BETH, CAKE, and other BEP-20 tokens) into single-asset vaults, with claimed returns sourced from arbitrage strategies executed across BSC venues. The project obtained a CertiK audit on its ARBX token contract in November 2021 — a real, registry-verifiable audit that covered the ERC-20 / BEP-20 token contract behaviours of ARBX (transfer, approval, ownership). The audit was used in the project's marketing materials as a defensive-baseline credibility signal.

The deployed system, however, consisted of multiple contracts beyond the audited ARBX token: a "depositor contract" that received user-deposited BEP-20 tokens and BNB, a routing layer that directed deposits to "yield pools," and the yield pools themselves. None of these contracts beyond the ARBX token were in the CertiK audit scope. The depositor contract directed user deposits to unverified pools — pool contracts whose source was not published on BscScan and whose deployer key was the operator-side. The unverified pools held the user-deposited assets and exposed an owner-side drain function that was reachable by the operator's deployer key.

On 2022-01-04, beginning at approximately 03:00 UTC, the operator-side executed three coordinated actions. First, the operator invoked the eight mint() functions on the ARBX token contract (each onlyOwner-guarded), minting approximately 10M ARBX tokens to eight operator-controlled addresses — with approximately 4.5M ARBX minted to a single key address 0x161262d172699cf0a5e09b6cdfa5fee7f32c183d. The minted ARBX was then dumped on-market, extracting realised value from any liquidity-provision counterparties. Second, the operator drained the unverified pools' user-deposited assets — approximately $10M aggregate across the BEP-20 token positions (~$2.25M BSC-USD, ~$1.7M BUSD, ~$1.4M CAKE, ~$1.0M BSC-USDC, ~$920K BETH, plus smaller positions). Third, the operator deleted the project website, Twitter account, and Telegram channel.

Within hours of the drain, CertiK published a public alert flagging Arbix Finance as a rug pull, citing the unverified-pool routing of user deposits as the canonical signal — the first independent forensic record at the audit-firm-side public-callout layer. CertiK's alert preceded the operator's full social-media takedown, demonstrating that audit-firm post-deployment monitoring at the contract-graph level is a real-time defender capability against the audit-scope-mismatch anti-pattern.

The drained BEP-20 assets were converted to ETH via cross-chain bridges (BSC → Ethereum, common bridge-routing infrastructure of the period). The resulting ETH was routed through Tornado Cash on Ethereum to break the on-chain trace. CertiK and partner forensic analysts (BleepingComputer, BankInfoSecurity) tracked the laundering route to the Tornado Cash deposit boundary; post-mixer recovery of the proceeds was not achieved.

Timeline (UTC)

When Event OAK ref
2021 (late) Arbix Finance launches on BSC; markets itself as arbitrage-focused yield platform; obtains CertiK audit on ARBX token contract published November 2021 (T6.003 setup — audit scope = token contract only)
2021-late to 2022-01-03 User deposits accumulate in the depositor contract; depositor contract routes deposits to unverified pools (operator-controlled, source not published on BscScan) (T6.003 standing surface — audited token contract is non-load-bearing for user-funds custody)
2022-01-04 ~03:00 UTC Operator invokes the eight mint() functions on the ARBX token contract; mints ~10M ARBX to 8 operator-controlled addresses (~4.5M to 0x161262d172699cf0a5e09b6cdfa5fee7f32c183d) T5.003 (hidden-mint dilution)
2022-01-04 ~03:00 UTC Operator-controlled addresses dump the freshly-minted ~4.5M ARBX on-market, extracting realised value from liquidity-provision counterparties T5.003 (mint-and-dump extraction)
2022-01-04 ~03:00 UTC Operator drains the unverified pools' user-deposited BEP-20 assets via owner-side drain functions; ~$10M aggregate extracted T5.001 (hard LP drain)
2022-01-04 ~hours after drain Operator deletes Arbix Finance website, Twitter account, Telegram channel (operator response — full takedown)
2022-01-04 ~hours after drain CertiK publishes public alert flagging Arbix Finance as a rug pull, citing unverified-pool routing as the canonical signal; CertiK clarifies that its audit covered the ARBX token contract only and did not cover the depositor / unverified-pool contracts (audit-firm-side public callout — load-bearing T6.003 defender response)
2022-01-04 to 2022-01-05 Drained BEP-20 assets converted to ETH via cross-chain bridges; resulting ETH routed through Tornado Cash on Ethereum T7.001 (mixer-routed hop)
2022-01-05 Cointelegraph, BleepingComputer, BankInfoSecurity, Cryptopolitan, Infosecurity Magazine publish contemporaneous reporting; CoinGecko confirms ARBX price collapse to near-zero (defender record)
ongoing No public-record law-enforcement action; no recovery proceeding; operator-side identity not publicly attributed (cohort context)

What defenders observed

  • Pre-event (audit-scope-vs-deployed-system gap): the CertiK audit covered the ARBX token contract published in November 2021. The user-funds-at-risk contracts (depositor contract + unverified pools) were not in scope. Per-firm registry verification of the audit (the CertiK Skynet lookup) returned a confirmatory result for the existence of the audit but did not surface the scope of the audit at a granularity sufficient to alert users that the depositor contract was outside coverage. The canonical T6.003 mitigation is audit-scope verification — confirming that every authority-holding contract in the deployed system is in the cited audit's scope, not just the headline token contract. The Arbix case demonstrates that "is there an audit?" is a structurally insufficient question; "does the audit cover the contracts holding user funds?" is the load-bearing question.
  • Pre-event (unverified-pool routing as canonical signal): the depositor contract routed deposits to pool contracts whose source was not published on BscScan. Source-not-verified pools holding user-deposited assets is the canonical T6.003 signal at the deployed-system layer — the audit-coverage-of-record cannot extend to contracts whose source the audit firm has not seen. CertiK's public callout cited this signal explicitly. Future yield-farming users should treat unverified pool contracts holding user-deposited assets as a hard rejection signal regardless of the project's audit-claim status.
  • Pre-event (multi-contract scope surface): Arbix's deployed system was a multi-contract architecture (ARBX token + depositor contract + unverified pools). The audit covered one contract. Multi-contract systems where a single-contract audit is cited as full-system coverage is a recurring T6.003 anti-pattern documented at the class level in the T6.003 page's "Multi-contract scope review" detection signal. Defenders evaluating multi-contract deployments should map the contract graph (factory, router, treasury, governor, depositor, pool) and confirm each authority-holding contract's audit-coverage status before extending economic trust to the system.
  • At-event (mint-and-dump combined with pool drain): the operator-side executed three coordinated actions in close temporal succession — token mint, market dump, pool drain — within hours. A real-time mint-event monitor combined with a per-token-cluster trade-flow monitor would have produced a high-confidence T5.003 + T5.001 signature in real time. CertiK's post-event public alert identified the pattern correctly within hours; the structural mitigation is real-time monitoring at the token-mint-event layer integrated with cluster-attribution analysis.
  • At-event (audit-firm public callout as defender response): CertiK's public alert preceded the operator's full social-media takedown by hours. The audit-firm-side post-deployment monitoring capability is a real-time defender response when the firm retains the contract-graph trace material from the audit engagement. Future T6.003 contributions should track the audit-firm public callout latency (time from drain to firm's first public alert) as a defender-side metric — Arbix's T+hours latency is the v0.1 reference benchmark, and improvements at this metric correspond to faster user-side warning before social-media-takedown obscures the project's trace material.
  • Post-event (Tornado Cash routing as laundering): the BSC → ETH → Tornado Cash routing is the canonical 2022-era T7.001 laundering pattern. The cross-chain bridge layer is the load-bearing laundering surface — once the proceeds reached the Tornado Cash deposit boundary, post-mixer recovery was not achieved. The cross-chain attribution layer (Chainalysis / TRM / Elliptic forensic capability) tracked the route to the Tornado boundary; recovery requires regulatory cooperation that did not materialise in this case.

What this example tells contributors writing future Technique pages

  • T6.003 has its canonical worked example at v0.4 with Arbix Finance. Prior to Arbix, T6.003 lacked a per-incident named case with public forensic disclosure of the audit-vs-deployed-system gap (per the T6.003 page's "Per-incident named cases" subsection). Arbix is the cleanest anchor at v0.4: real CertiK audit + multi-contract deployed system + unverified-pool routing of user funds + audit-firm-side public callout citing the scope-gap as the canonical signal. Future T6.003 contributions should structure their write-ups against the Arbix template.
  • Audit-scope verification is the load-bearing user-side mitigation, not audit-existence verification. The Arbix case demonstrates that confirming "is there an audit?" via registry-lookup returns confirmatory but non-load-bearing information when the audit's scope does not cover the user-funds-at-risk contract. T6.003 contributions should explicitly document the scope axis of audit verification, distinct from the existence axis.
  • Audit-firm post-deployment monitoring at the contract-graph layer is a real-time defender capability. CertiK's public callout within hours of the drain demonstrates that audit firms with retained contract-graph trace material from the audit engagement can perform real-time post-deployment monitoring at a granularity that exceeds the user-side registry-lookup capability. Future T6.x mitigations should explicitly track audit-firm post-deployment monitoring as a discrete defender capability and document the audit-firm-public-callout-latency metric.
  • T6.003 + T5.003 + T5.001 + T7.001 is the canonical "audited yield-farming rug" attack chain. The four-Technique composition (audit-scope mismatch + hidden mint + hard LP drain + mixer routing) is the canonical attack chain for the 2022-era yield-farming rug surface. Future contributions documenting yield-farming rugs should map all four composing Techniques explicitly and treat any sub-pattern absence as a structural variation worth noting.

Public references

Citations

  • [bleepingcomputerarbix2022] — contemporaneous press; canonical for the $10M figure and the laundering-route description.
  • [cointelegrapharbix2022] — contemporaneous press; CertiK public-callout framing.
  • [infosecmagarbix2022] — contemporaneous press; per-asset breakdown.
  • [bankinfosecuritarbix2022] — contemporaneous press; operator-side drain mechanic.
  • [cryptopolitarbix2022] — contemporaneous press; on-chain mint-recipient address.
  • [quadrigaarbix2022] — independent case-study aggregator.
  • [bscscanarbix2022] — block-explorer tagged address.
  • [certikfakeaudit] — companion T6.002 cohort citation; cited here for the broader audit-firm-brand-misuse pattern context.
  • [chainalysis2025rug] — market-aggregate reference; rug-pull cohort scale.

Discussion

Arbix Finance is the canonical T6.003 (Audit-of-Different-Bytecode-Version) worked example in the OAK corpus at v0.4. It is structurally distinct from the T6.002 (Fake Audit-Claim) cohort documented at the class level — the audit was real, registry-verifiable, and the audit firm (CertiK) confirmed the engagement on inquiry; the failure mode was scope drift between what was audited (ARBX token contract) and what held user funds at risk (depositor contract + unverified pools). The case is the cleanest 2022 anchor for the audit-scope-mismatch sub-shape and pairs with the T6.002 cohort documented in [certikfakeaudit] as the complement failure mode in the audit-trust-failure triangle.

The four-Technique composition (T6.003 + T5.003 + T5.001 + T7.001) is the canonical "audited yield-farming rug" attack chain for the 2021-2022 era. Each composing Technique is a load-bearing component: removing T6.003 (the audit) eliminates the user-trust-substrate that brought deposits to the platform; removing T5.003 (the hidden mint) eliminates the mint-and-dump realised-extraction channel; removing T5.001 (the hard pool drain) eliminates the bulk extraction; removing T7.001 (the Tornado Cash routing) makes the proceeds attributable. Future contributions documenting yield-farming rugs should map all four composing Techniques explicitly.

Audit-firm post-deployment monitoring at the contract-graph layer is the load-bearing T6.003 defender capability surfaced by this case. CertiK's public alert preceded the operator's full takedown by hours, demonstrating that audit firms with retained contract-graph trace material can perform real-time monitoring at a granularity that exceeds user-side registry-lookup capability. The T6.003 mitigation surface should formalise this as a discrete capability — audit-firm post-deployment contract-graph monitoring — distinct from the general audit-firm-side mitigations of public registries and machine-readable attestations.

Attribution-strength is pseudonymous-cohort at the funder-graph-cluster level. The operator cluster is identifiable at the on-chain layer (deposit-routing addresses, ARBX-mint-recipient cluster, depositor-contract deployer key) but no real-world identification has been published. The case demonstrates that 2022-era BSC yield-farming rugs operated with effective pseudonymity even at multi-million-dollar extraction scales, and that the cross-chain (BSC → ETH → Tornado Cash) laundering route was sufficient to break post-event recovery efforts in the absence of regulatory cooperation.

The case is the third 2022-Q1 BSC-side rug pull in the OAK corpus alongside the broader 2022 BSC rug-pull cohort context ([chainalysis2025rug]) and pairs with the T6.002 fake-audit cohort documented in [certikfakeaudit] as the complement T6 failure-mode. The cross-class observation: T6.002 (no audit) and T6.003 (audit of different bytecode) are equally damaging at the user-side outcome layer; the difference is purely in which mitigation surface defeats the evasion (registry-lookup defeats T6.002 but not T6.003; audit-scope verification defeats T6.003 but is operationally costlier than registry-lookup).

False-positive considerations: legitimate multi-contract deployed systems routinely include contracts that are not in the headline audit's scope — auxiliary contracts (proxies, factories, peripheral routers) commonly fall outside the per-engagement audit boundary. The T6.003 detection signal is not "the deployed system contains contracts outside the audit scope" but specifically "authority-holding contracts (treasury authority, upgrade authority, drain authority, user-funds-custody authority) outside the audit scope." Cohort-level analysis distinguishes load-bearing audit-scope drift (T6.003) from non-load-bearing peripheral-contract scope-omission (commonly accepted in audit engagements).

Techniques demonstrated (6)