The Real Story of the Solv Protocol Hack: What Happened Next

The vulnerability was in the BitcoinReserveOffering (BRO) contract. To understand the mechanics, two standard mechanisms need to be explained first.

Minting is the creation of new tokens. In this case, a user calls the mint() function to receive BRO tokens in exchange for deposited funds.

safeTransfer and callback. When a token is transferred to a contract address, the standard requires the receiving contract to confirm receipt through a dedicated function — onERC721Received(). This is called a callback: the protocol automatically notifies the recipient and waits for confirmation.

The vulnerability arose from an incorrect interaction between these two mechanisms. During the execution of mint(), the contract performed a safe token transfer, which triggered the onERC721Received() callback. That callback fired before the primary accounting in mint() had completed — and independently issued tokens. Once the callback finished, the main mint() flow reached its own token issuance step and issued them again. One deposit was counted twice within a single execution.

This is a callback-driven double mint — a double-accounting bug: not two independent calls, not a bypass of any protection, but two parts of the same execution, each doing its job correctly, neither aware the other had already done the same thing.

Think of it like this: you check a suitcase at the airport. The agent at the desk prints your baggage claim ticket — and at that exact moment, a colleague in the back room, unaware, prints a second ticket for the same suitcase. One bag, two valid tickets. That's exactly what happened with the BRO contract: one deposit generated two token issuance confirmations.

The attacker repeated this cycle 22 times within a single transaction. Because all iterations took place within one transaction, the internal exchange rate had no opportunity to update between them — the EVM (Ethereum Virtual Machine, the runtime environment for smart contracts) only commits state changes once a transaction completes in full. A starting balance of ~135 BRO was artificially inflated to ~567 million BRO.

The inflated 567 million BRO is not a direct loss to the protocol. It is an intermediate artifact of the attack: an unbacked mass of tokens existing only within the flawed contract logic. Real damage only materializes at the next stage — at the moment of conversion into liquid assets.

This distinction matters. Calling 567 million BRO "stolen" is misleading. The actual loss is recorded at the moment paper inflation becomes real value.

Investigator's note. Executing all 22 cycles within a single transaction was not accidental — it was a deliberate technical choice. It was precisely this that prevented the exchange rate from updating between iterations.

Of the ~567 million BRO, the attacker used approximately 165 million BRO (≈29% of the inflated balance) and swapped them for SolvBTC through the protocol's internal pool. The result — 38.0474 SolvBTC — is the confirmed loss.

The attacker converted only 29% of the inflated balance. The remaining ~402 million BRO were left untouched — the inflated balance existed only within the flawed contract logic and held no real value.

Investigator's note. The inflated 567 million BRO was not money that could simply be taken in full. It was an artifact of an accounting error in the contract. Real value can only be extracted through conversion — and only as much as the pool on the other side of the swap can provide.

After receiving SolvBTC, the attacker converted assets in sequence:

SolvBTC to WBTC to WETH

WBTC and WETH are "wrapped" versions of Bitcoin and Ether: ERC-20 tokens pegged 1:1 to the price of the original asset, but compatible with Ethereum's infrastructure.

Each conversion step served two purposes: moving away from a low-liquidity protocol-native token toward dominant network assets, and creating additional transaction layers, each of which requires separate tracing.

ETH is the standard currency for mixers. The entire conversion chain was building toward it. The final step — unwrapping WETH into native ETH — was made by the attacker during the laundering phase.

Investigator's note. This is where the exploit ends and the laundering begins. These are two separate operations with different goals, and they need to be analyzed separately. What follows is the most revealing part of the case.

Stage 1 — Layering. Funds were distributed across several intermediary addresses. Layering is the phase of money laundering in which funds are split and moved through multiple addresses to break the direct chain of origin and complicate tracing.

Stage 2 — Attempted RailGun entry (blocked). The attacker directed funds into RailGun — a privacy protocol based on ZK-proofs. ZK (zero-knowledge) is a cryptographic method that allows a transaction to be verified without revealing any of its details: no amount, no sender, no recipient. RailGun's built-in KYT/AML filters rejected the deposit and returned the funds to the sender. KYT (Know Your Transaction) and AML (Anti-Money Laundering) are transaction monitoring systems that automatically flag suspicious activity and connections to known addresses.

Stage 3 — Redistribution. After the funds were returned, the attacker split them across several addresses again and converted WETH into native ETH — the final total came to approximately 1,211 ETH.

Stage 4 — Tornado Cash. The final leg ended in Tornado Cash — a pool mixer that severs the link between sender and recipient by pooling deposits from many users together.

Full laundering chain for ~1,211 ETH:

1. Intermediary wallets (layering)
2. RailGun (rejected, funds returned)
3. Redistribution + WETH → ETH
4. Tornado Cash

The RailGun rejection is one of the most significant moments in this case. The block did not come from law enforcement. It did not come through exchange compliance procedures. The privacy protocol's own built-in filters autonomously rejected the transaction.

For the attacker, this meant rebuilding the route in real time. For the analyst, it reveals intent: the attacker deliberately chose the ZK layer as the primary concealment tool — Tornado Cash was the backup plan, not the original one.

Investigator's note. Attempting RailGun before Tornado Cash is a meaningful behavioral marker. The move to Tornado Cash after the rejection is not a sign of incompetence — it is adaptation.

An on-chain trail is not just a transaction route. It is a behavioral profile: the way an attacker moves at each stage reveals their skill level, experience, and operational approach. Here is what this case tells us.

Technical skill — high. Building a callback-driven double mint exploit with all cycles executed within a single transaction requires deep understanding of EVM mechanics.

Operational discipline — high. The attack was executed in two clearly separated phases, each a discrete operation with its own logic. When RailGun rejected the deposit, the attacker adapted and continued.

Awareness of privacy tools — high. RailGun was used first — a ZK-based protocol with a higher level of anonymization than Tornado Cash. Tornado Cash became the fallback only after the rejection.

Monetization efficiency — moderate. Only 29% of the inflated balance was converted — the rest remained trapped within the flawed contract logic.

The Solv Protocol exploit is a notable case not so much because of the size of the loss, but because of the architecture of the attack. A technically precise callback-driven double mint, a disciplined post-theft concealment operation, and an attempt to use ZK-privacy as the primary tool of concealment — together these form an attacker profile that deserves attention in its own right.

For the industry, a different conclusion matters more: RailGun blocked the transaction autonomously, without any regulatory involvement. This is a precedent that changes how we think about privacy protocols in compliance infrastructure — not in spite of their nature, but because of it.

This investigation is based on on-chain transaction data and publicly available reconstructions of the incident. All asset valuations are based on market prices at the time of the incident.