Grim Finance Disclosed $30 Million-Plus Vault Exploit

Grim Finance disclosed on December 19, 2021, that an attacker had exploited its yield vaults on the Fantom network. The protocol said the identified address held more than $30 million worth of stolen assets and announced that its vaults had been paused. The disclosure turned a contract-level failure into a broader warning about the security assumptions behind rapidly growing decentralized-finance products.

The attack itself preceded the announcement. A representative Fantom transaction associated with the exploit was recorded on December 18 at 17:39:15 UTC. The defensible event for the assigned archive date is therefore Grim Finance’s December 19 public confirmation, explanation and emergency response—not the initial execution of the transaction.

How the vault accounting was manipulated

Grim Finance operated as a yield optimizer. Users placed liquidity-provider tokens or other supported assets into vaults, and strategies attempted to compound the associated rewards. That structure required the vault contracts to accept tokens, calculate a depositor’s share of pooled assets and issue corresponding vault shares.

According to Grim Finance’s event-day explanation, the vulnerable path involved `depositFor`, a function that accepted a user-supplied token address. A malicious token contract could call back into the vault while `safeTransferFrom` was still executing. Grim described five nested reentrant calls. When those calls unwound, multiple levels treated the deposit amount as valid and minted shares, even though the attacker had not supplied proportionate assets at every level.

The result was inflated ownership of the affected vaults. Those excess shares could then be redeemed for genuine assets held for depositors. The identified transaction documents execution of this mechanism on Fantom, but one transaction alone does not establish the complete loss across every affected vault.

An audit had missed the exposed function

The incident was especially consequential because Grim’s token and vault contracts had been reviewed before the attack. An audit dated August 24, 2021, stated that a reentrancy guard was used in relevant locations and reported that no external-attacker issues had been identified.

On December 19, the auditor updated its published report. It acknowledged that arbitrary addresses could be called inside `depositFor`, allowing an attacker to use reentrancy to increase vault shares falsely and withdraw more than had been deposited. The function listing in the report showed a `nonReentrant` modifier on the ordinary `deposit` function but not on `depositFor`.

That distinction mattered beyond Grim Finance. A contract could contain a standard reentrancy guard and still remain exposed if the protection was not applied to every externally reachable path that transferred tokens or changed accounting. An audit designation was evidence of a review, not a guarantee that all reachable combinations of user-controlled contracts and vault logic had been tested.

What was known on December 19

Grim Finance said it had contacted Circle, the DAI ecosystem and AnySwap concerning the attacker’s address. That statement established outreach, not that any assets had been frozen or recovered. Contemporaneous reporting also confirmed that new deposits had been paused, but no complete victim ledger, independently valued loss schedule or recovery plan was available on December 19.

The reported figure of more than $30 million was the protocol’s contemporaneous estimate. Grim did not publish an asset-by-asset valuation table, pricing source, valuation timestamp or treatment of illiquid tokens. It should therefore be read as an attributed estimate rather than an independently verified dollar total.

The event-day conclusion was nevertheless clear: an unprotected vault entry point had allowed one attacker to manufacture claims on pooled assets. The episode demonstrated how composable token calls could convert a localized coding omission into losses spanning multiple vaults—and how a favorable audit could fail to capture the operational risk users actually faced.