Solv Protocol $2.5M Exploit: Double Mint Bug (Explained)

The Solv Protocol exploit resulted in approximately $2.5M in losses, caused by a logic flaw in the BitcoinReserveOffering contract that enabled double minting of BRO tokens. The issue arose from the interaction between the NFT transfer process and the onERC721Received callback during the mint flow. By triggering minting inside the callback and again when execution returned to the mint() function, the attacker created unbacked BRO tokens. Repeating this process within a single transaction allowed the attacker to massively inflate tokens and later convert part of them into 1211 ETH.
 

Hack Analysis

The attacker initially started with 135 BRO tokens. These tokens were burned through the reserve contract, and based on the exchange rate at that time, the attacker received 0.000031102085070226 GOEFS tokens in return.

The attacker then executed aminttransaction by sending those GOEFS tokens along with NFT ID 4932. This NFT transfer triggered theonERC721Receivedcallback, which internally called the_mintfunction and minted BRO tokens according to the current exchange rate.

After the callback finished, execution returned to themint()function, which again called the_mintfunction using the same exchange rate, resulting in another set of BRO tokens being minted for the attacker.

Atacker repeated this process 22 times and since the entire exploit occurred within a single transaction, the exchange rate remained constant throughout the process. This allowed the attacker to repeatedly perform the loop, effectively doubling the initial BRO tokens with each iteration.

In the end, the attacker accumulated 567M BRO tokens. Out of these, 165M BRO were converted into 1211 ETH by first swapping BRO to SolvBTC through the BRO - SolvBTC exchange, and then swapping the assets on Uniswap V3.

The diagram below summarizes the exploit flow, from the initial burn of BRO tokens and mint interaction with the NFT callback, to the double minting bug that allowed the attacker to inflate tokens and ultimately extract ETH through on-chain swaps.

Root Cause

In BitcoinReserveOffering.sol, when the mint function is called, the contract first transfers an NFT from the user’s account. During this transfer, the onERC721Received() callback is triggered. Inside this callback, tokens are minted for the user.

However, after the callback execution completes and the program counter returns to the mint function, the contract mints the tokens again for the same user. This results in double minting.

The attacker exploited this behavior by minting tokens through the callback and then receiving another mint when execution returned to the mint function. Later, when the attacker called the burnfunction, the protocol exchanged the inflated tokens and returned assets back to the attacker.

By repeatedly performing this loop 22 times, the attacker turned 135 BRO tokens into 567M BRO tokens, ultimately extracting 1211 ETH in profit.

Funds Flow After Attack

The attacker converted 135 BRO tokens into approximately 567M BRO tokens through this exploit. Out of these, 165M BRO were swapped to SolvBTC, which were then converted to WBTC, subsequently to WETH, and then to ETH through the BRO–SolvBTC Exchange and Uniswap V3. The remaining ~402M BRO tokens are still held in the attacker’s EOA (0xa407fe273db74184898cb56d2cb685615e1c0d6e).

The remaining 1211 ETH extracted from the exploit were transferred to other attacker-controlled EOAs and subsequently deposited into the RailGun protocol, a privacy protocol similar to Tornado Cash.

Post Attack Mitigation

Solv Protocol acknowledged the exploit, assured users that funds are safe, stated they will cover the losses of affected users, and offered the attacker a 10% white-hat bounty in exchange for returning the funds while the investigation continues.

Relevant Address and Transactions

Attacker EOAs:

• 0xa407fe273db74184898cb56d2cb685615e1c0d6e
• 0x9f7a6b16d0d9824197651f33506e3a2bb2f6f432
• 0xd17ddd34c414f666fc51e9fe04d32cf60eda78fe
   

RailGun Deposit Transactions:

• 0x4ad60378dc9a550cd7953613fed8299a570d1ec7d622d60572618a4757db43f2
• 0x1905824c6c83151bb4d627aedeb8f6b49e677d8124239f180a818cc966ca020b
• 0xe15cd6908ad15b3399b6fe5cf782621e0ed531d40287e7510b26a16d83cf8e2f
• 0x991128a016811f72febaa58afb7472ace55807fcf19c8163994bcfe32ad30bb5
   

Attack Transaction: 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d
 

Victim Contract: 0x014e6F6ba7a9f4C9a51a0Aa3189B5c0a21006869
 

BRO Token: 0x014e6F6ba7a9f4C9a51a0Aa3189B5c0a21006869
 

BRO - Solv BTC Exchange: 0x1E6101728fD9920465dfA1562c5e371850103da2
 

Conclusion

The Solv Protocol exploit highlights how subtle callback interactions can introduce critical logic flaws in smart contracts. A missing guard against double minting allowed the attacker to inflate tokens within a single transaction. This incident reinforces the importance of carefully handling external calls, callbacks, and state updates in DeFi protocols.