Solv BRO Vault Exploit: How a Double Mint Drained SolvBTC

Solv BRO vault exploit was a mint-path failure on Ethereum, not a cross-chain bridge breakdown. On March 5, 2026, one attacker turned about 135 BRO into roughly 567 million BRO, redeemed part of that inflated balance into 38.0474 SolvBTC, and exited into ETH in a single transaction flow worth about $2.7 million.

The attacker did not need a complex bridge path to extract value

The on-chain unwind was direct. Etherscan shows transaction 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d on March 5, 2026 at 15:09:35 UTC swapping 38.0474051381 SolvBTC for 37.99001493 WBTC on Uniswap V3, then swapping that WBTC into 1,211.0543769655 ETH. The same transaction page shows the sender as 0xA407fE273DB74184898CB56D2cb685615e1C0D6e, which Rekt and QuillAudits both identify as part of the attacker flow.

Solv’s own incident update, surfaced via X search results, said the exploit was limited to one BRO vault, affected fewer than 10 users, and totaled 38.0474 SolvBTC. Halborn’s post says Solv promised to compensate affected parties and offered the attacker a 10% white-hat bounty in exchange for the return of funds. Public reporting after the event did not show recovery.

That matters because the exploit did not depend on draining a cross-chain liquidity pool or corrupting SolvBTC’s reserve logic. The attacker first created a fake claim on BRO inside the vault logic, then used the protocol’s own redemption path to convert that fake claim into a real reserve-linked asset and finally into WBTC and ETH. The monetization leg was ordinary DeFi routing. The break happened earlier, at issuance.

Rekt’s Solv post-mortem

Halborn’s Solv incident analysis

The BRO mint path failed because the same deposit minted twice

The core flaw was a callback-driven double mint. Halborn says the BitcoinReserveOffering contract used doSafeTransferIn while ingesting an ERC-3525 NFT deposit, which triggered the ERC-721 receiver callback onERC721Received. That callback minted BRO tokens, and then, once execution returned to mint(), the contract minted again for the same deposit. QuillAudits describes the same sequence and says the attacker repeated it 22 times within one transaction while the exchange rate remained effectively constant.

Rekt’s write-up sharpens the operational point: this was not exotic cryptography or a novel bridge exploit. It was a self-reentrancy-style accounting failure around when state was updated relative to a callback. Rekt says a check-effects pattern or a reentrancy guard on the mint function would have closed the window, and QuillAudits’ reconstruction shows why: the contract let the callback mint before the outer mint path had finished bookkeeping.

The attacker’s gain came from repeating that broken loop, not from moving across chains. QuillAudits says 165 million of the inflated BRO were converted into SolvBTC and then into ETH, while the remaining roughly 402 million BRO stayed in the attacker EOA at the time of its analysis. The transaction trace on Etherscan independently confirms the value-extraction leg into ETH.

QuillAudits’ exploit breakdown

Etherscan transaction trace

The audit story is worse than “an audited vault got hacked”

The project brief calls the vault “previously audited,” but the public record is more troubling. Solv’s own audit page lists key reports for ERC-3525 reference implementation, Solv Protocol V3, Open-Fund, SolvBTC and SolvBTC LST, and Vault Guardian. That page does not list a BRO-vault-specific audit report. Separately, Rekt reported that the BitcoinReserveOffering contract “shipped without an audit” and that Solv’s active bug bounty scope covered Web2 infrastructure and Solana contracts, not the EVM contract that failed here.

That does not mean Solv had no audits anywhere. It means the protocol had enough public security material to look broadly audited while the exact live mint path that failed does not appear on the public audit list and, according to Rekt, sat outside bounty coverage. For operators and depositors, that distinction is huge. “The protocol is audited” and “this contract path was audited” are not the same claim.

This is the more durable lesson from the incident. Security posture fails when teams treat audit pages as brand proof instead of scope documents. A protocol can legitimately say it has audits and still leave a newly introduced or product-specific mint path under-reviewed. In this case, the missing question was not whether Solv had security partners in general. It was whether this exact BRO issuance path had independent review and whether the bounty program gave researchers anywhere paid and legitimate to report it before an attacker did.

Solv supported blockchains documentation

Solv audit page

SolvBTC’s cross-chain design shaped perception, not the root cause

Solv’s documentation says SolvBTC is available on multiple chains, including Ethereum and Solana, and that its supported-blockchains matrix uses burn-and-mint bridges for both Ethereum and Solana. That makes cross-chain risk a fair question in general. But the exploit evidence here points somewhere narrower: the broken contract lived on Ethereum, the attack transaction executed on Ethereum, and the extraction route ran through Ethereum DeFi venues.

So the cross-chain angle is secondary, not causal. The stolen asset was SolvBTC, a multi-chain reserve token, which naturally makes people ask whether chain mappings or wrapped-asset abstractions added hidden risk. The records reviewed here do not support that conclusion. The problem was not that SolvBTC existed on Solana or that Solv used multi-chain issuance. The problem was that one Ethereum-side vault contract could mint BRO claims twice and redeem them into a valuable reserve-linked asset before anyone stopped it.

That distinction matters for readers because it changes what needs fixing. If the failure had been a bridge bug, the response would center on cross-chain message validation, reserve reconciliation, and chain-specific mint controls. Here the fixes are local to contract design: callback safety, mint sequencing, reentrancy assumptions, audit scope, and bounty scope. Cross-chain branding may have made the exploit sound more structurally complex than it was. The actual bug was simpler and more embarrassing.

The laundering trail adds one more governance lesson

Rekt reported that the attacker first tried Railgun and then routed the proceeds through Tornado Cash after the Railgun path failed. Public third-party summaries cited by search results repeat that Railgun’s compliance filters flagged the attempted deposit and returned the funds to the sender before the attacker moved to Tornado Cash. Even if that part of the trail comes from post-incident reporting rather than a protocol-authored post-mortem, the broad takeaway is clear: once the ETH exit happened, recovery odds fell sharply.

For builders, that means the economically relevant defense had to be pre-exploit, not post-exploit. Solv could pause the affected vault, promise to cover losses, and message the attacker with a 10% bounty offer, but none of that undid the fact that the core value had already been converted into a liquid asset and routed toward privacy infrastructure. The X snippets and Halborn’s summary both say Solv moved quickly on communications and compensation; the technical problem is that the attacker had already finished the profitable part.

The next question for protocols like Solv is not whether “other vaults were unaffected.” It is whether every live mint, redeem, and callback path is specifically audited, specifically bounty-covered, and specifically tested against standards-induced reentrancy. The BRO exploit did not expose a hidden cross-chain monster. It exposed a very ordinary contract mistake sitting inside a product that looked more reviewed from the outside than this one path actually was.