Skip to content

exploit

DeFiTuna suspends Solana lending after $580K USDC pool drained via zero-round

DeFiTuna disclosed on July 16 that an attacker used a self-created illiquid TUNA/USDC pool routed through Jupiter to round a position's asset value to zero, bypassing the solvency check.

by 6 min read

DeFiTuna, a Solana-native protocol that stacks concentrated-liquidity AMM pools, on-chain lending and up to 5x leverage in a single contract set, disclosed on July 16, 2026 that an attacker drained roughly $580,000 in USDC from its lending vaults around seven hours before the team's own notice. The USDC lending pool is left with a matching deficit of the same size; withdrawals for lenders are paused pending recovery. Primary disclosure is the DeFiTuna team's own X account statement; independent write-ups include Crypto Briefing and The Crypto Times.

What happened

DeFiTuna's public message, quoted verbatim by the disclosing outlets, states: "the attacker managed to exploit DeFiTuna lending pools and extract $580,000 which means that the USDC lending pool is currently at a $580,000 deficit." The team says it has "identified and mitigated the attack vector" and is "working on trying to recover the funds," with the investigation still active and a formal post-mortem yet to be published.

Two things about the disclosure matter for how to read the number. First, the loss is stated in USDC — no ETH-equivalent maths and no ambiguous "up to" range that later gets revised. Second, the framing — "pool is at a deficit" — is deliberate: the pool contract still shows those balances as owed to lenders on paper, but the underlying assets are gone. That deficit becomes a real haircut on lenders unless DeFiTuna can recover, backstop or socialise the shortfall.

Mechanism — a self-made illiquid pool that rounded to zero

The most technical account of the attack path comes from Crypto Briefing's reconstruction, which the team has not disputed. Three steps:

  1. Spin up a captive pool. The attacker created a highly illiquid TUNA/USDC concentrated-liquidity pool that they controlled the liquidity range on.
  2. Route a borrow through Jupiter. Using DeFiTuna's leveraged-lending flow, the attacker borrowed USDC and routed it through Jupiter into the captive TUNA/USDC pool. Because the pool was almost dry on the other side, the swap returned a negligible amount of TUNA.
  3. Break the solvency check by rounding. DeFiTuna's position-valuation logic converted that negligible TUNA balance back into a USDC-equivalent asset value — and rounded the result down to zero. With the position's asset side calculated as zero, the health check treated the leveraged loan as fully collateralised on the borrower side rather than under-water, and the withdraw path on attacker-controlled liquidity positions moved the borrowed USDC out.

The failure isn't in Solana's runtime and isn't in Jupiter's routing — both did exactly what they're built for. It's in DeFiTuna's assumption that a valuation returning zero must correspond to a fully-collateralised position, when it actually corresponds to an attacker who has drained one side of a permissionless pool they created.

Numbers block

- Chain                     : Solana
- Protocol                  : DeFiTuna (concentrated-liquidity AMM + lending
                              + up to 5x leverage)
- Loss                      : ~$580,000 USDC
- Affected pool             : DeFiTuna USDC lending pool (deficit)
- Disclosure                : 2026-07-16, ~7h after the incident
- Attack path               : attacker-created illiquid TUNA/USDC pool →
                              borrow routed through Jupiter → target pool
                              returns negligible TUNA → valuation rounds
                              position assets to zero → solvency check
                              bypassed → USDC withdrawn on attacker LPs
- Team status               : attack vector patched, investigation ongoing,
                              "working on trying to recover the funds"
- Post-mortem               : not yet published
- Attacker attribution      : no wallet publicly disclosed by DeFiTuna
                              or third-party security firms at time of writing

Impact

The loss falls on DeFiTuna's lenders — the depositors on the USDC side of the lending contract. Until the team makes a treasury or backstop statement, that $580K deficit is a claim the pool cannot pay in full. Users who had non-USDC deposits, non-lending positions, or funds outside the affected pools are outside the direct blast radius of the shortfall, but withdrawal availability across the platform depends on how DeFiTuna operationally pauses and rebalances during the recovery.

DeFiTuna's stack — AMM + lending + leverage in one perimeter — means a bug in the leverage/valuation surface can drain the lending vault via a route that only exists because the same protocol owns both sides. That's not a Solana-scoped risk; it's an architectural surface any protocol with the same shape (Kamino's earlier iterations, Marginfi-style bundles, cross-margin perpetuals stacks on Ethereum L2s) has to defend against.

Action checklist

  1. If you deposited on DeFiTuna's USDC lending pool, wait for the team's treasury statement before assuming a specific recovery percentage. The disclosure is explicit that the pool is at a deficit, not that lenders are made whole.
  2. If you hold other DeFiTuna positions (concentrated-liquidity, leveraged), monitor DeFiTuna's own X for the reopening schedule rather than relying on secondary outlets — the primary source has been the fastest to publish.
  3. If you build a leveraged-lending protocol, audit the specific case that broke DeFiTuna: an attacker-controlled destination pool with a valuation that can round to zero. Add a strict per-pool liquidity floor to any collateral-asset conversion, and treat "asset value converted to zero" as an alarm state rather than as "collateral fully backs the loan."
  4. If you route swaps through Jupiter for internal accounting, verify your integration doesn't inherit third-party pool liquidity assumptions. Jupiter did its job; the accounting sitting on top did not.

Context — the July 2026 DeFi exploit run continues

DeFiTuna joins a compressed run of DeFi exploits on the Layer-1 and Layer-2 DeFi surface this month. On the same Arbitrum weekend, an attacker with a compromised oracle-signer key drained the Ostium OLP vault of roughly $18–24M — covered here in our Ostium write-up. Days earlier, the Polychain-and-Variant-backed Cascade perpetuals platform lost $1.34M of pre-launch, invite-only USDC from its CLS vault, detailed in our Cascade write-up. Summer.fi wound down after a $6.04M share-price manipulation earlier in the month, and BonkDAO lost about $20M in a governance attack on Solana at the start of the month.

The through-line isn't a single primitive. Ostium was a signer-key perimeter failure; Cascade was a vault-strategy exploit against a not-yet-launched product; Summer.fi was an NAV donation attack; Bonk was a governance-buy. DeFiTuna is a valuation-round-to-zero bug against a self-created illiquid pool. What they share is not a common bug but a common posture: each protocol trusted a downstream computation to hold under conditions its designers didn't fully model. The next protocol to lose money this month will almost certainly do so through a fourth distinct primitive.

DeFiTuna's post-mortem — when it lands — should name the exact valuation function that rounded to zero and describe the fix. Until then, the $580K deficit is the record, and lender-side withdrawal availability is the ongoing story.

Sources:

Related stories