Rhea Finance $18.4M Slippage Exploit (Explained)

On April 16, 2026, Rhea Finance (previously Burrow Finance), one of NEAR Protocol's largest lending protocols, was hit by an $18.4M exploit. This wasn't a random flash loan attack. The attacker spent two days building 423 wallets, deploying fake token contracts, and seeding manipulated liquidity pools before exploiting a logic flaw in the protocol's slippage protection mechanism to drain the entire reserve pool through forced liquidations. It stands as the sixth-largest DeFi exploit of 2026. In an unusual turn, approximately $18M of the stolen funds have since been recovered or frozen through a combination of voluntary returns by the attacker, Tether's USDT freeze, and coordinated ecosystem response leaving a remaining shortfall of only ~$0.4M, which RHEA Finance has unconditionally committed to covering in full.

What is Margin Trading Slippage Protection, and How Does Rhea Finance Work?

Rhea Finance is a NEAR Protocol lending and margin trading protocol where users deposit assets to earn yield or borrow against collateral. Its margin trading feature lets users open leveraged positions by borrowing assets from the reserve pool and swapping them into position tokens through an on-chain router.

Slippage protection is the safety gate on that swap. When a margin position is opened across multiple swap steps, the protocol sums all min_amount_out values the minimum acceptable output at each step to verify the user receives fair value. The flaw was in that summation. When the output token of one swap step is reused as the input of the next, the protocol counted the same token value twice. The check passed. The reality was far worse.

Hack Analysis

Between April 13 and 15, the attacker quietly staged the infrastructure. They created a subject wallet funded through cross-chain transfers via intents.near, then distributed approximately 71,000 NEAR across 423 unique intermediary wallets in rapid automated succession.

In parallel, they deployed purpose-built fake token contracts deployed on implicit account addresses and exposing no standard NEP-141 metadata methods, confirming they were never meant to be legitimate tokens. These fake tokens were then paired with USDC, USDT, wNEAR, and ZEC in eight newly created pools on Ref Finance (pool IDs 8528–8538), seeded with liquidity at controlled, artificial price ratios.

On April 15 at 22:08–22:49 UTC, the attacker coordinated a campaign to finalise the infrastructure. Twenty-one intermediary accounts were deleted within 30 seconds at 22:48–22:49 UTC, all designating the subject wallet as sole beneficiary, covering their tracks before the main event.

The exploit itself ran on April 16 from 08:22 to 09:42 UTC. The attacker opened a large number of margin trading positions on Burrow Protocol using the fake token swap router. Here is why the slippage check failed:

The protocol's slippage check saw the sum of 999 and 1 and passed. What it missed was that AttackerToken the output of step 1 was immediately spent as the input of step 2. The 999 USDC equivalent never reached the protocol. It sat in the attacker's controlled pool. Each margin position opened this way was worth far less than its debt, triggering immediate forced liquidations.

Root Cause

The root cause was a single logic error in burrowland/margin_trading.rs#L102. The slippage protection algorithm summed all min_amount_out values across swap actions to derive a final expected output, but did not account for swap actions where the output token of one step is reused as the input of the next.

In a standard single-step swap, this check works correctly. In a multi-step route where intermediary tokens loop back as inputs, the check double-counts. The attacker constructed a chain of swaps that deliberately exploited this behaviour the real token output reaching the protocol was negligible, while slippage protection reported everything as within bounds. No code was executed that wasn't supposed to run. The logic was the vulnerability.

The issue was specific to the margin trading execution path. Standard lending and borrowing operations in Rhea Finance were unaffected. The protocol's reserve pool, which backs the entire lending market, was the victim of the cascading forced liquidations that followed.

How QuillAudits Smart Contract Audit Could Have Prevented This

QuillAudits smart contract audit process includes thorough review of slippage protection logic, multi-step swap validation, and token reuse patterns exactly the class of vulnerability that made this exploit possible.

Multi-step swap token reuse analysis. The flaw was that the protocol treated each step's min_amount_out as independent value, without checking whether the output of one step was consumed as the input of the next. An audit would have identified that intermediary tokens in a swap chain should not be counted toward the cumulative slippage guarantee and would have flagged the missing deduplication logic in the aggregation function.

Attack path simulation against margin trading. Margin trading execution paths are high-value, complex code surfaces where the interaction between the swap router, slippage checks, and liquidation mechanics creates compounding risk. An audit would have simulated adversarial swap routes including those using attacker-controlled intermediary tokens to verify that the slippage guarantee held against manipulated inputs.

Fake token and oracle manipulation resistance. The attacker deployed fake tokens with no NEP-141 metadata and seeded them into fresh liquidity pools to create artificial price histories. An audit would have assessed whether the protocol had sufficient token validation, oracle freshness requirements, and minimum liquidity thresholds to reject newly created tokens as valid swap intermediaries in margin positions.

Liquidation cascade risk assessment. Once margin positions were opened at a fraction of their debt value, forced liquidations triggered automatically and drained the reserve pool in a cascade. An audit would have modelled the conditions under which mass simultaneous liquidations could deplete reserves and recommended circuit breakers or per-block liquidation caps to limit the blast radius.

Intermediary account pattern detection. The attacker created 423 wallets and 8 fake pools over two days before the exploit. An audit recommendation for on-chain monitoring flagging newly created token contracts being used as swap intermediaries in margin trades before a minimum trading history would have caught the attack infrastructure before it was used.

With a QuillAudits smart contract audit in place, the token reuse flaw in the slippage aggregation logic would have been identified and patched before mainnet deployment.

Get Your Smart Contract Audited Now.

Funds Flow After Attack

Stolen assets were routed to three separate refund addresses across different chains: Ethereum mainnet (0x237e67d9cAcAD42b4aCE31d61f444d14BEA78E39), Zcash mainnet (t1KsyGrJMo6K6MJc2RSdZKXSuTozJ4M9iJ4), and NEAR. A large Ethereum transfer of approximately $3.49M in USDC-linked tokens was recorded on April 17 at 23:11 UTC from address 0xBb5Fa936469CaDb8907f3aEF80F5B53f55Bc11f6.

Recovery has been meaningful. By the time of the second incident report (April 22, 2026):

Aurora co-founder Alex Shevchenko publicly confirmed the attacker had been identified and later confirmed partial return of funds. RHEA Finance has unconditionally committed to covering any remaining deficit of approximately $0.4M in full.

Post Attack Mitigation

Upon identification of the exploit, Rhea Finance immediately paused the affected smart contracts to prevent further losses and preserve recoverable funds.

Tether moved swiftly to freeze 3.291M USDT directly in the attacker's wallet. A formal trace has been opened with centralised exchanges to identify the account owner. An external security team has been engaged for forensic investigation and recovery efforts. All fraudulent token contracts and liquidity pools identified in connection with the exploit have been removed from RHEA DEX, which has since reopened.

Following the incident, RHEA Finance permanently discontinued the Margin Trading feature on NEAR Protocol. The lending protocol is targeting a phased reopening starting from the first week of May 2026, contingent on full resolution of frozen funds, smart contract upgrades, deployment of real-time monitoring bots, and a comprehensive security audit of the full RHEA protocol product suite.

Relevant Address and Transactions

Attacker Accounts (NEAR)

• Subject Wallet - primary orchestrator (implicit NEAR account, funded via intents.near April 15 at 07:12 UTC)
• rhea000453.multica.near - MCA staging wallet
• rhea000462.multica.near - MCA staging wallet
• rhea000505.multica.near - MCA staging wallet

Attacker Refund Addresses

• 0x237e67d9cAcAD42b4aCE31d61f444d14BEA78E39 - Ethereum mainnet refund address
• t1KsyGrJMo6K6MJc2RSdZKXSuTozJ4M9iJ4 - Zcash mainnet refund address
• contract.main.burrow.near - NEAR (RHEA Lending contract, received returned funds)

Return Transactions

• 0xBb5Fa936469CaDb8907f3aEF80F5B53f55Bc11f6 - Ethereum return address (~$3.49M USDC)
• c4f64fd8c596c2a22c3f653de5c6bd45bf033c9a556faebc198360cedd00bce - Zcash return tx (13,500 ZEC)

Example Attack Transaction (NEAR)

• 44tWhQmmkTJgchgFVkYpPrgyKvaH7wRLu1jZWXD3Du1x

Vulnerable Contract

contract.main.burrow.near

Ref Finance Fake Token Pools

• Pool IDs 8528–8538 on v2.ref-finance.near

LST Contract

• lst.rhealab.near - called by staging wallets during pre-attack preparation

Conclusion

The Rhea Finance exploit is a clear example of how a single logic flaw in a complex execution path can bypass even well-intentioned safety mechanisms. The slippage protection worked perfectly in isolation the bug only appeared when multi-step swap routes reused intermediary tokens, a scenario the aggregation function never accounted for. Two days of preparation, 423 wallets, and eight fake token pools all to exploit one arithmetic assumption. The logic was the vulnerability. For protocols with margin trading or multi-step swap execution, adversarial audit coverage of slippage validation paths is not optional it is the difference between a secure launch and an $18.4M lesson.