Double-Minting Bug in Solv's Unaudited BRO Vault Drains $2.73 Million

An unaudited smart contract belonging to Solv Protocol let an attacker mint the same tokens twice from a single deposit, draining roughly $2.73 million in a single, tightly looped transaction on March 5.

What happened

The target was Solv's BitcoinReserveOffering contract, a vault that had gone live without a security audit and without bug-bounty coverage. According to the breakdown that first surfaced the incident, an attacker turned 135 BRO tokens into 567 million by repeating a double-mint sequence 22 times inside one transaction. The proceeds were converted into 38.0474 SolvBTC — about $2.73 million at the time — and moved out.

Solv's public statement described it as a "limited exploit," said fewer than 10 users were affected, and pledged to make those users whole after security partners flagged the issue. It's a familiar script for the protocol: the same measured tone followed a compromise of Solv's Twitter account in January 2025, which occurred the same month Rekt.News examined Solv's Bitcoin accounting practices. This marks the third security-related headline for Solv in fourteen months, and each time the messaging has arrived polished and fast.

Solv also posted an address and offered the attacker a 10% white-hat bounty in exchange for returning the funds. There was no reply. By the time that offer went out, the stolen assets were already being routed toward RailGun.

How the discovery unfolded

The first public alert came from DefimonAlerts on X on March 5, laying out the vulnerable contract, the flaw, and the transaction hash before most of the crypto world had started its day. The post attributed the catch to Decurity's automated monitoring system, which flagged the double-minting pattern and traced it to the BitcoinReserveOffering contract, internally labeled BRO-SOLV-20MAY2026. By that point the attacker had already completed the exploit.

Solv later credited Hypernative Labs, SlowMist, and CertiK with alerting the team promptly. The company's own statement followed shortly after, reading: "A limited exploit occurred in one of our BRO vaults, affecting a very small number of users (<10). The impacted amount is 38.0474 SolvBTC. All other vaults and user funds remain secure and unaffected."

Independent researchers moved quickly to confirm the mechanism. Pseudonymous analyst Pyro identified it as a self-reentrancy attack, a class of exploit that has been hitting DeFi protocols since 2016. Chris Dior, co-founder of CD Security, verified the loop count: 22 cycles, 135 BRO deposited, 567 million minted. Then researcher SherlockVarm added a detail that shifted the framing of the story: the exploited contract had never been audited, and Solv's bug bounty program covered only its Web2 infrastructure and its Solana contracts — not this one. Despite Solv's audit page listing five separate security firms, the vulnerable contract sat outside every one of those reviews.

The mechanism: a callback that minted twice

The flaw lived in the minting logic, not in any obscure cryptographic weakness. In the vault's intended design, a user deposits collateral and receives BRO tokens representing their position — straightforward in concept.

The problem traced back to how the vault handled NFT transfers during minting, which relied on the ERC-3525 standard. ERC-3525 is a semi-fungible token format built on top of ERC-721: each token carries a unique ID like a standard NFT, but also holds a numeric value that can be divided, combined, or transferred in fractional amounts — useful for representing partial ownership of a yield position. Notably, Solv co-founder Ryan Chow is a listed co-author of the ERC-3525 proposal itself, and Solv was the first protocol to put the standard into large-scale production use. The standard the team helped create ended up being the source of its own undoing.

Because ERC-3525 inherits ERC-721's transfer behavior, moving an NFT triggers the onERC721Received callback. In Solv's implementation, that callback fired — and minted BRO tokens — before the calling function had finished executing. When a user called mint() and included an NFT transfer as part of a deposit, the contract used doSafeTransferIn to move the NFT, which triggered onERC721Received. Solv's code used that callback to mint BRO tokens to the caller. Then, once execution returned back to the original mint() call, it minted BRO tokens again for the same deposit, at the same exchange rate — no custom exploit tooling required, just a callback firing ahead of the function it was nested inside.

In practice, the attacker started with 135 BRO tokens, burned them through the reserve contract, and received 0.000031102085070226 GOEFS tokens in return. They then called mint(), sending those GOEFS tokens back in together with NFT ID 4932. The callback fired and minted BRO; execution resumed in mint() and minted BRO a second time — two mints from one deposit. Because the whole sequence executed inside a single transaction, the exchange rate never had a chance to adjust between repetitions. The attacker burned the newly minted BRO for more GOEFS, called mint() again, and repeated the same double-mint at the same rate — 22 times total — turning 135 BRO into 567 million, recorded on-chain in transaction 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d.

Cashing out

From there the attacker moved quickly. 165 million of the 567 million BRO tokens were swapped for SolvBTC via the BRO-SolvBTC exchange contract, then routed through Uniswap V3 along the path SolvBTC → WBTC → WETH → ETH, ultimately converting 38.0474 SolvBTC into 1,211 ETH spread across several attacker-controlled wallets.

The stolen ETH was then passed through two intermediary addresses en route to RailGun, a common laundering step. That attempt failed: RailGun's built-in KYT and AML screening flagged the deposit and returned it to the sender, the privacy protocol's compliance tooling working as designed. The attacker then pivoted to Tornado Cash — receiving the rejected funds back, redistributing them across several addresses, converting WETH to ETH, and depositing into the sanctioned mixer, which carries no equivalent compliance filter. The compliance-oriented privacy tool blocked the funds; the sanctioned one accepted them.

Key addresses

• Victim contract (BRO Token): 0x014e6F6ba7a9f4C9a51a0Aa3189B5c0a21006869
• Attack transaction: 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d
• BRO-SolvBTC exchange: 0x1E6101728fD9920465dfA1562c5e371850103da2
• Attacker EOAs: 0xa407fe273db74184898cb56d2cb685615e1c0d6e, 0x9f7a6b16d0d9824197651f33506e3a2bb2f6f432, 0xd17ddd34c414f666fc51e9fe04d32cf60eda78fe

The offered white-hat bounty address was 0x08259F9D1De695329b5a0FDF4703F72c7C2326A9; it went unused.

Why the fix should have been trivial

QuillAudits' post-mortem attributed the root cause to a missing guard against double minting, emphasizing the need for careful sequencing of external calls, callbacks, and state changes. SherlockVarm was blunter, stating that basic security best practices would likely have prevented the incident entirely. Specifically, either a checks-effects-interactions pattern or a reentrancy guard on the mint function would have closed the gap — neither was implemented. The fix would have amounted to a handful of lines of code; its absence cost $2.73 million.

A gap in the audit trail

Solv's published audit history lists five firms: Quantstamp, Salus, OpenZeppelin, Offside, and Paladin — legitimate reviews of real contracts by credible names in the space. None of them, however, ever examined the BitcoinReserveOffering contract. The BRO vault is a relatively recent product, under a year old, part of Solv's growing lineup of structured yield instruments, and it appears to have launched after the existing audits were already completed. Nobody scheduled a follow-up review for it — it simply never happened.

SherlockVarm's post-incident analysis pointed to the same conclusion from a different angle: the bug bounty program listed on HackenProof runs two active tracks, one for Web2 infrastructure and one for the Solana contracts — leaving the EVM-based BRO contract, the one actually drained, uncovered by either. Any researcher who might have found this bug ahead of the attacker would have had no official bounty channel to report it through.

A pattern going back to January 2025

This is not the first time Solv's security practices have drawn scrutiny. On January 1, 2025, user Godiex reported that 0.01 BTC disappeared from their SolvBTC.BBN position without any transaction they had signed. The funds resurfaced in two new wallets, still accruing Solv reward points, but no longer controlled by the original account — notable given that SolvBTC had been marketed as a self-custodial product.

In the days that followed, Solv came under public criticism over its TVL reporting methodology, with critics alleging the protocol used pre-signed transactions to count the same Bitcoin as reserves across multiple platforms simultaneously, without the underlying BTC actually moving. Solv rejected the characterization. Co-founder Ryan Chow responded on X: "For months we are aware competitors are out there smearing us to our partners and persuade them 'don't work with Solv, work with us instead.' We have so far chosen to ignore and continue doing us. But no more. Make no mistake. This is a smear campaign, coordinated and orchestrated, and going to great lengths in attempt to take Solv down. This. Is. War. But we will Solv it."

Days later, in the middle of that same controversy, Solv's official X account was compromised on January 5, with the attacker posting a fraudulent Ethereum address. Solv removed the post within 15 minutes and reimbursed affected users.

Aftermath

Taken together, the record shows a protocol first accused of double-counting the same Bitcoin across platforms through pre-signed transactions and TVL practices, and then, over a year later, shipping a vault where the same tokens really could be minted twice — this time proven on-chain rather than alleged. The audit roster reads impressively, with well-known firms each covering a defined scope, but the specific contract that got drained was never inside any of those scopes. A product name implying institutional-grade Bitcoin reserves invited an assumption of thorough review that turned out not to hold.

Market reaction was muted: SOLV's token price rose 3.5% on the day of the exploit. A swiftly issued "funds will be covered" statement, combined with a small affected-user count, appears to have been enough to keep the incident from denting sentiment.

The attacker walked away with $2.73 million, first attempted to launder it through RailGun, was blocked by that platform's own compliance screening, and then successfully moved the funds through Tornado Cash instead.

The underlying issue was not a failure of Solv's security program broadly — it was a contract that fell outside of it entirely, sitting unreviewed and effectively unmonitored until an attacker found it first.