T
iTokenly

Solv Protocol (BRO Vault) hack — March 2026

Verified — 4 sourcesLast checked August 1, 2026

Incident facts

Date of incident
Publicly disclosedMarch 6, 2026
Target typeOther
Loss$2,700,000Price at time of incident
Recovered$2,700,000
MethodOther or undisclosedA callback-driven double mint, described by the cited analyses as a double-accounting bug rather than classic reentrancy. In the BitcoinReserveOffering wrapper, transferring an entire ERC-3525 position with safeTransferFrom() triggered onERC721Received(), which independently minted BRO while the outer mint() call was still executing; mint() then minted again for the same deposit at the end of the call. The outer mint() carried a nonReentrant guard, but the callback was unguarded and carried no context flag, so the same underlying value was credited twice. The attacker ran 22 burn-and-mint cycles, inflating 135.36 BRO into 567,758,681 BRO.
ChainsEthereum
OutcomeUsers reimbursed

What happened

On 5 March 2026 an attacker drained 38.0474 SolvBTC, about $2.7 million, from a single Bitcoin Reserve Offering (BRO) vault operated by Solv Protocol on Ethereum.

Solv's post-incident review describes the vault as a standalone, one-time, limited-scope and non-public deployment created in connection with the Solv token listing rather than one of its public products, and says it had not been subject to the same level of operational process and security rigour as the established products. Two participants were associated with the vault, and Solv says no other product or public offering was affected.

Independent analyses by DarkNavy, Halborn and Taichi Audit identify the flaw as a double mint reachable through a callback. The BRO wrapper handles ERC-3525 positions; when an entire position was transferred using safeTransferFrom(), the onERC721Received() callback minted BRO while the outer mint() call was still executing, and mint() then minted again for the same deposit on completion. Although mint() itself carried a nonReentrant guard, the callback was unguarded and carried no context flag, so the same value was credited twice. Taichi Audit is explicit that this is not technically a reentrancy exploit but a double-accounting bug, and DarkNavy describes the guard being bypassed through parallel execution rather than direct reentrancy. DarkNavy records that the attacker deployed two contracts and ran 22 burn-and-mint cycles, inflating 135.36 BRO into 567,758,681 BRO, redeeming part of it for 38.047 SolvBTC and realising about 1,211 ETH, while retaining some 402 million illicit BRO.

Reported dates differ by a day. Solv's own review and DarkNavy give 5 March 2026, while Taichi Audit and some news coverage date it 6 March, the day it was widely reported. The loss figure is consistent at roughly $2.7 million across Solv's accounting and the third-party analyses.

Halborn reports that Solv offered the attacker a 10 percent white-hat bounty in exchange for return of the remaining funds; no source confirms the offer was accepted or that any funds were returned. Solv said that as of 9 March 2026 all losses associated with the incident had been fully compensated and affected users made whole, and that future vault deployments would require external audit review.

Sources

  1. Solv ProtocolPrimary · retrieved 2026-08-01
  2. DARKNAVYSecondary · retrieved 2026-08-01
  3. HalbornSecondary · retrieved 2026-08-01
  4. Taichi AuditSecondary · retrieved 2026-08-01

Official post-mortem: https://insights.solv.finance/post-incident-review-bro-vault-incident-and-strengthened-security-commitments/

Cite this

This data is published under CC BY 4.0. You may reuse it, including commercially, as long as you credit iTokenly and link back.

iTokenly Hack Registry, "Solv Protocol (BRO Vault) hack — March 2026", iTokenly, accessed 2026-08-01, https://itokenly.com/hacks/solv-protocol-bro-vault
https://itokenly.com/hacks/solv-protocol-bro-vault

Permalinks never change. If an entry is renamed, the old address keeps working.

Spotted an error? Write to [email protected]. Corrections to published figures are logged on this page. See the methodology for how entries are checked.