What caused the DeFiTuna exploit on July 16, 2026?

The attackers created a highly illiquid TUNA/USDC pool and routed borrowed USDC through it. The swap returned only a tiny amount of TUNA, and when DeFiTuna's is_healthy() function calculated the position value, rounding down the result to zero made the position appear empty and healthy. This allowed attackers to bypass the solvency check and withdraw the USDC.

How much money was stolen in the DeFiTuna attack?

Approximately $569,601 USDC was exploited from DeFiTuna on Solana.

How did the attackers manipulate the DeFiTuna pool price?

The attackers set the initial price of their nearly empty TUNA/USDC pool close to the legitimate oracle price, so DeFiTuna's pre-swap price-deviation checks passed. Then they placed limit-order positions at an abnormally high tick to receive the USDC entering the pool.

What was the main vulnerability that allowed the exploit?

The vulnerability was in DeFiTuna's is_healthy() solvency check. The compute_total_and_debt() function rounded down the position's total asset value using to_num:: (), which discarded the fractional part. Since the attackers engineered the swap to return a negligibly small amount of TUNA, the total rounded to zero, causing the protocol to treat the position as healthy.

How did the attackers withdraw the stolen USDC?

After the swap, the USDC belonged economically to two malicious limit-order positions the attackers controlled. Each attacker called DecreaseLimitOrder to withdraw 284,280.483231 USDC per position, effectively draining the funds.

DefiTuna Incident Analysis

Incident Summary

On 16 July 2026, DeFiTuna was exploited for $569,601 USDC on Solana. The attackers created a highly illiquid TUNA/USDC pool and used it as the destination for borrowed USDC routed through Jupiter. Because the swap returned only a negligible amount of TUNA, DeFiTuna’s value calculation rounded the position’s total assets down to zero. The protocol then incorrectly treated the position as healthy, allowing the attackers to bypass the solvency check and withdraw the USDC through attacker-controlled liquidity positions. defituna1

Key Addresses

Address	Label
9ytGWP8tCRF1keREJ5VHqBpSuM9MZYwm3oFQQa1SvESb	Attacker 1
917DKTphW3rhBG5gsJpwKsNGisNV2dx74uUFd8HBEjtg	Attacker 2
7hiHL8AgDuLNVDQLfN3GHdLAEeCN1F7uz6nSANRvFJst	Attacker 3
BK9aTnKfPNnnj45Me5ACrky2vexzUrZHRzr4BjmQpH3c	Attacker 4
8P3H7Hy98LWhw5QhuXdoigVdAzPCYRTYjdtQQKhGwvqD	Attacker 5
GrXBhM6Ty6YxubFp8zubtJF12WXmKj1dhMyakRPeaDpo	Attacker 6
F4xUroPaHro4gb2JAqa3e93E7DdZytRQJ4L2cHT5E53p	Attacker 7
ETGhosPrFApbiiKXDpxrhBz7J2MdTA3dxnL2Nkio9vEX	Attacker 8
4ZKkGZuoXqgSHbmsJXUib3dgn5WNhzbPEXrxuMYJ5oQ3	Attacker 9
tuna4uSQZncNeeiAMKbstuxA9CUkHH6HmC64wgmnogD	DefiTuna
D76dDcSU5HnAGqVEZCDLyGgLpTp4xZuqeZyVDtUdDv55	Damaged USDC vault
917DKTphW3rhBG5gsJpwKsNGisNV2dx74uUFd8HBEjtg	Fake Pool

Attack Flow

Jul-16-2026 05:48:12 - Txn

The attackers created a nearly empty TUNA/USDC Fusion pool. They set its initial price close to the legitimate oracle price, so DeFiTuna’s pre-swap price-deviation checks passed.
Then placed two attacker-controlled limit-order positions in that pool at abnormally high tick 208,640, adding 0.000526 + 0.000526 = 0.001052 TUNA. These positions were owned by 7hiH…FJst and BK9a…QpH3c. They were designed to receive the USDC entering the pool.
Call DefiTuna: Open_and_increase_tuna_spot_position_jupiter Decoding the Instruction Data referencing tuna.json get That the attacker opened the opened a DeFiTuna spot position with zero collateral The 570K USDC borrowed from lending pool minus fee were routed through Embedded Jupiter Router, and the 47 bytes instruction specified the swap path. The path is to swap 569,601 USDC, which is all USDC borrowed minus the fees, for TUNA through the prepared thin pool The exact swap is at tick 208640 as they are the only non-empty ones, considering 0.1% fee, the output amount is 569601/(1.0001)^208640*(1-0.001) = 0.000494845, rounded down to 0.000494 TUNA.

After receiving those 494 raw units, DeFiTuna valued the position at its pre-swap/oracle price 0.001837534 in is_healthy() -> compute_total_and_debt() (tuna_position.rs). defituna6 At line51, 494 × 0.0018375338 = 0.9077417.

At line 53, to_num:() converts the positive fixed-point value to an integer by discarding the fractional part, so the result is zero.

defituna8 Then the zero ‘total’ was evaluated under the assumption that “the leverage of an empty position is always 1.0x.” and the position is considered healthy.

The USDC now belonged economically to the two malicious limit-order positions. So each attacker called DecreaseLimitOrder to withdraw 284,280.483231 USDC each.

Vulnerability

In TunaPosition.ishealthy() solvency check, the zero ‘total’ value was evaluated under the assumption that “the leverage of an empty position is always 1.0x.” and the position is considered healthy. defituna10 The self.compute_total_and_debt() uses a reference sqrt_price and round down the result in its calculation at line 53. defituna11 The attacker engineered a very skewed pool that after routing USDC assets to the pool through an arbitrary swap path, the returning asset value is so small that the rounding in to_num::() reduced the total to zero, effectively bypassing the solvency check.