Worked example · 2022-03

Cashio infinite-mint via missing input validation — Solana — 2022-03-23

Loss: approximately $48M extracted from Cashio, a Solana-based stablecoin protocol that minted CASH against Saber-LP-token collateral. The drain was a single-block / short-burst event in which the attacker minted 2 billion CASH against valueless fake collateral and immediately redeemed the inflated CASH for real underlying assets across Cashio's redemption surface and adjacent Saber pools.
Recovery: approximately $28M of the ~$48M was returned by the attacker to wallets holding less than ~$100k each, in a self-described "Robin Hood" framing. Larger holders received nothing. The recovery was organised on-chain via a public attacker statement specifying the cutoff. This is one of the earliest Solana-ecosystem cases where the attacker conditioned a partial return on victim-wealth bracketing rather than on a flat percentage bug-bounty negotiation.
OAK Techniques observed: OAK-T9.004 (Smart-Contract Logic Flaw — input-validation sub-class) — primary. The Cashio mint instruction accepted a Saber LP token account but failed to validate that the LP token's underlying basket was the basket Cashio's collateral model required. The attacker constructed a fake LP token account presenting the right surface signature but an attacker-controlled underlying, and Cashio's mint logic credited it as legitimate collateral. Downstream OAK-T7 outflow patterns observed in the off-Cashio routing of the proceeds (no canonical bridge / mixer leg in OAK v0.1 terms is broken out separately for this case beyond same-chain laundering).
Attribution: pseudonymous. No public named-individual attribution. The attacker posted a return-conditions message via on-chain memo and to a Twitter account before going dark. There is no FBI / DOJ / Treasury attribution as of the OAK v0.1 cut.
Key teaching point: input-validation failure on collateral provenance is the foundational T9.004 sub-class on Solana. Cashio's bug was not in any of its arithmetic; the math was correct given the inputs. The bug was that the protocol did not check whether the inputs themselves were legitimate Saber-LP tokens of the expected basket. The Solana account model — where any program can pass any account into any instruction unless the receiving program explicitly validates the account's origin, owner, and contents — places the burden of provenance checks on the receiving program. Cashio's mint instruction failed this check. The Cashio incident is OAK's foundational Solana T9.004 case for that reason: the failure is structurally tied to Solana's account-passing model, not to a quirk of Cashio's specific design.

Summary

Cashio was a stablecoin protocol on Solana that minted CASH (a USD-pegged stablecoin) against Saber-LP-token collateral. Saber is a Solana stable-swap AMM; its LP tokens represent shares in baskets such as USDC-USDT. Cashio's design accepted specific Saber LP tokens as the collateral basis for CASH minting, with the intent that one CASH would be backed by approximately one dollar of underlying basket value held in the Saber pool.

On 2022-03-23, an attacker exploited a missing input-validation check in Cashio's mint instruction. The instruction accepted an account purporting to be a Saber LP token but failed to verify two upstream chained properties: (i) that the LP token's mint authority was the Saber AMM program owning the basket Cashio expected, and (ii) that the chain of accounts establishing the LP token's underlying basket actually terminated in the legitimate Saber pool. The attacker constructed a fabricated chain of accounts that presented the surface shape Cashio's mint instruction inspected, but whose underlying was attacker-controlled and held no real assets. Cashio's mint instruction credited the fake LP tokens as collateral and minted approximately 2 billion CASH against them.

The attacker then redeemed the freshly minted CASH against Cashio's redemption surface and against adjacent Saber pools, extracting approximately $48M in real underlying assets (primarily USDC and UST, with the latter still solvent in March 2022 pre-Terra collapse). The CASH peg collapsed to near zero immediately upon recognition of the inflated supply.

Several days after the event the attacker issued a public statement announcing that funds belonging to wallets holding less than approximately $100k worth of CASH-related exposure would be returned, while larger holders' shares would be retained. Approximately $28M was subsequently returned across small-holder addresses; the remaining ~$20M was retained. The attacker's identity is unknown.

For OAK's purposes Cashio is the canonical foundational Solana T9.004 input-validation example. It pre-dates and structurally explains the cluster of Solana incidents that followed (Crema Finance July 2022, Nirvana July 2022, Cypher August 2023) by establishing the pattern that account-provenance validation is the load-bearing defensive surface on Solana, distinct from the EVM-side defensive surface where access control via msg.sender and address(this) checks dominates.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Cashio deploys CASH stablecoin minting on Solana; mint instruction accepts Saber-LP-token collateral but does not validate that the LP token's underlying basket terminates at the legitimate Saber pool	T9.004 surface (latent)
Pre-event	Attacker analyses Cashio's mint instruction and identifies the missing-provenance-check surface; constructs fabricated chain of accounts mimicking the expected Saber-LP shape	(off-OAK pre-event observation)
2022-03-23	Attacker submits Cashio mint transaction with fabricated LP-token collateral; receives ~2 billion CASH credited against zero-value inputs	T9.004 extraction
2022-03-23	Attacker redeems freshly minted CASH against Cashio's redemption surface and adjacent Saber pools; extracts ~$48M in real underlying assets (USDC, UST, others)	T9.004 monetisation
2022-03-23	CASH peg collapses to near zero; Cashio team and community detect the drain	(operator response)
2022-03-23 to 2022-03-26	Cashio team disables minting; community begins on-chain forensics with help from external Solana-ecosystem analysts	(post-incident triage)
2022-03-26	Attacker posts public on-chain memo and Twitter statement: funds return conditioned on victim wallet holding <~$100k CASH-related exposure	(attacker statement)
Days following	Approximately $28M returned to small-holder wallets meeting the bracket; ~$20M retained	(partial recovery)
Continuing	No named-individual attribution as of OAK v0.1; protocol does not recover; CASH stablecoin permanently depegged	(final state)

What defenders observed

The bug was strictly upstream of any arithmetic. Cashio's CASH-mint math was correct: it credited collateral in proportion to the LP-token amount as designed. The defect was that the collateral itself was not what the protocol assumed. This is the prototypical T9.004 input-validation failure: the program accepted attacker-controlled inputs as if they were trusted-source inputs because the validation that would have rejected them was not present. The general Solana-side defender lesson is that account-provenance validation is the load-bearing pre-arithmetic surface; the math assumes the inputs are real.
The Solana account model is what makes this class possible. On Solana, any program can pass any account into any instruction unless the receiving instruction explicitly checks the account's owner, the account's contents, and (where applicable) the chain of authorities upstream of the account. This is a more-permissive default than EVM-side msg.sender-driven access control: on EVM, an attacker calling a function passes only their own address as msg.sender, and the function can validate it against an allowlist; on Solana, an attacker passing a fabricated chain of accounts through an instruction's argument list is the normal calling convention, and rejection requires explicit checks. Cashio failed to perform the explicit chain-of-authority check that would have caught the fabrication. Anchor (the Solana-side smart-contract framework) introduced macros to make these checks easier to specify, but the macros must be used; absent them, the default is "accept whatever the caller passes."
The drain pattern is single-burst, not a slow drain. Once the attacker identified the missing-validation surface, the actual extraction was effectively single-block: mint, redeem, repeat across redemption venues until the underlying pools were drained. There is no incremental defender-detection window once the surface is identified — the time between first-mint and pool-empty is bounded by transaction latency, not by drain pacing. Mitigation must therefore be pre-event (audit-stage validation of all collateral-input chains) rather than at-event (real-time anomaly detection cannot catch a same-block drain).
Partial recovery via on-chain attacker memo, conditioned on victim-wealth brackets, is unusual and worth preserving. The Cashio attacker's "return to wallets <~$100k" framing was structurally different from the percentage-bounty negotiation pattern (Mango: ~60% return, Crema: ~10% bounty, Euler: ~100% return). The wealth-bracketed return introduces a self-curated victim-class boundary that the protocol team had no role in setting and has no enforcement leverage over. Defenders writing recovery-framework documentation should treat wealth-bracketed return as a distinct category from bounty-style return: the former is governed entirely by the attacker's stated conditions, with no downstream legal or contractual structure; the latter is at least nominally a bilateral negotiation with the protocol team.
The teaching record was rapidly absorbed by Solana-ecosystem auditors. Within months of Cashio, Anchor-framework macros for account-provenance validation became the de-facto baseline pattern, and Solana-side audit firms (OtterSec, Neodyme, Halborn's Solana practice) began treating "all account inputs validated for owner and chain-of-authority" as a per-program audit checklist item. Cashio is therefore the foundational case for the Solana-side T9.004 audit-baseline: the case that established what the audit checklist needed to look like.

What this example tells contributors writing future Technique pages

T9.004 needs explicit Solana-side framing. The Solana-side input-validation surface is not symmetric with the EVM-side input-validation surface. EVM-side T9.004 examples (Beanstalk governance / proposal validation, etc.) tend to be about validating function-argument values against expected ranges or invariants. Solana-side T9.004 examples — Cashio is the foundational case, with Crema Finance July 2022 and Cypher August 2023 as later instances — tend to be about validating account-input provenance: who owns the account, what authority chain produced it, whether its declared role matches its actual role. T9.004 pages should explicitly cover both sub-surfaces and cite Cashio as the canonical Solana-side foundational case.
The Anchor framework's account-validation macros are the canonical Solana-side mitigation. Writing T9.004 mitigations for the Solana ecosystem should anchor on Anchor's Account / Program / Signer / custom-constraint type-system, which makes account-provenance checks declarative and audit-visible. Cashio pre-dated the maturation of these patterns; subsequent Solana-side T9.004 cases (Crema, Cypher) occurred against the backdrop of these patterns being available, with the failure mode being incomplete or incorrect application of the pattern. Mitigation pages should make the difference clear.
Wealth-bracketed partial-return is a recovery sub-class worth tracking. Most worked-example recovery records collapse partial-return into "negotiated bounty." Cashio is the cleanest case where the recovery framework was not a negotiation but an attacker-stated brightline. Recovery-framework pages should treat this as a distinct sub-class — there are not many cases, but they exist, and they have different properties (no negotiation channel, no enforcement, no legal scaffolding, conditioned entirely on attacker's self-set rule).
Pseudonymous attribution is the realistic attribution status. The Cashio attacker's identity is unknown. The on-chain forensic detail is high; the off-chain attribution is zero. Contributors writing the worked-example layer should not over-claim attribution simply because the on-chain reconstruction is detailed.

Public references

[cashiopostmortem2022] — Cashio post-incident communication (community + team) describing the missing-validation root cause and the recovery framework.
[rektcashio2022] — Rekt News forensic write-up of the Cashio incident, including the on-chain trace and the wealth-bracketed return framing.
[ottersecsolana2022cashio] — OtterSec / Solana-side post-incident analysis emphasising the account-provenance validation gap and the Anchor-framework lesson.
[halbornsolana2022cashio] — Halborn analysis of the Cashio missing-input-validation pattern as an audit-checklist baseline for Solana programs.
[neodyme2024token2022] for adjacent Solana-program-design defender context (Token-2022 extension authority risk; same Solana-account-model framing applies).
[solrpds] for category-level Solana-ecosystem context.

Discussion

Cashio is OAK's foundational Solana T9.004 example. The bug — accepting attacker-fabricated collateral as if it were legitimate Saber LP tokens — is the prototype for a class of failures that recurs across the Solana ecosystem because it is structurally tied to Solana's account-passing model. Programs receive accounts as instruction arguments; the burden of validating that those accounts are what they claim to be is on the receiving program. Cashio failed this validation. Crema Finance failed an analogous validation (with a flash-loan-funded fake-tick-array account) four months later. Cypher failed an analogous logic-isolation check the following year. The Solana T9.004 cluster is real and well-attested.

The recovery framework — wealth-bracketed return, attacker-set, no negotiation channel — is also worth preserving as a worked-example artefact. Most recovery records in OAK collapse to "negotiated bounty" or "no recovery"; Cashio is the cleanest case where the recovery rule was unilateral and conditioned on victim-wealth brackets the protocol had no input into. The $28M / $48M recovery rate is a real outcome, but it is not a negotiated outcome, and the framework documentation should preserve that distinction.

For OAK's broader credibility, including Cashio in v0.1 closes a foundational gap: it is the earliest Solana-ecosystem T9.004 case at non-trivial scale, it pre-dates the maturation of Anchor-framework account-validation patterns, and it explains why Solana-side audit checklists evolved the way they did. Subsequent Solana T9.004 worked examples (Crema July 2022, Cypher August 2023) cite Cashio as the foundational case in their own discussions; the v0.1 corpus should make that lineage explicit.