L’essentiel : le 5 mars 2026, Solv Protocol subit un exploit ciblé sur son contrat BitcoinReserveOffering (BRO) vault. La cause : une vulnérabilité de reentrancy entre les standards ERC-3525 (semi-fungible tokens) et ERC-721 (NFT callback obligatoire). L’attaquant exploite la faille 22 fois en boucle, transformant 135 BRO en 567 millions de BRO (inflation de 4,2 millions x), qu’il échange ensuite pour 38,05 SolvBTC (~2,7 M$). Les fonds sont swappés en 37,99 WBTC puis 1 211 ETH, et blanchis via le mixer RailGun en quelques heures. Le détail le plus accablant : le contrat n’avait jamais été audité. Solv Protocol affichait pourtant 5 cabinets d’audit sur son GitHub, mais leur scope se limitait à l’infrastructure Web2 et aux contrats Solana. Le contrat critique BRO vault sur Ethereum a été déployé sans aucun audit. Moins de 10 utilisateurs affectés directement. Solv a couvert les pertes via sa réserve et a offert un white hat bounty 10 % infructueux.
Que s’est-il passé le 5 mars 2026 ?
Solv Protocol est une plateforme Bitcoin yield : elle permet aux détenteurs de Bitcoin (via WBTC, BTCB, cbBTC, etc.) de gagner du rendement en stakant leur BTC dans divers protocoles DeFi. Le protocole gère plus de 2 Md$ de TVL en 2026, principalement via son token SolvBTC qui représente une part de Bitcoin déposé.
Au-delà de SolvBTC, Solv expérimente différents produits, dont les Bitcoin Reserve Offerings (BRO). Un BRO est un token semi-fongible (standard ERC-3525) qui représente une « part » dans un vault de réserve Bitcoin. C’est un concept innovant qui combine la composabilité ERC-20 avec la flexibilité unique des NFT.
Le 5 mars 2026, un attaquant exécute une série de transactions sur le contrat BitcoinReserveOffering côté Ethereum. Selon l’analyse Halborn, l’exploit dure quelques minutes :
- Initial : l’attaquant possède 135 BRO légitimes.
- 22 itérations de l’exploit reentrancy : 135 BRO deviennent 567 472 522 BRO.
- Redeem des 567 M BRO contre 38,0474 SolvBTC sur le contrat de redemption.
- Swap des SolvBTC pour 37,99 WBTC via Uniswap.
- Swap WBTC → 1 211 ETH pour faciliter le blanchiment.
- Bridge vers RailGun (mixer privacy on-chain) en quelques heures.
Total des pertes : 2,7 M$. Moins de 10 utilisateurs affectés directement (les holders de BRO). Solv a annoncé immédiatement un plan de couverture des pertes via la trésorerie et a offert un white hat bounty de 10 % (~270 000 $) à l’attaquant en échange du retour des fonds. L’attaquant n’a pas répondu au délai 48h.
La vulnérabilité reentrancy ERC-3525 / ERC-721
Pour comprendre la faille, il faut regarder l’interaction entre deux standards de tokens Ethereum.
ERC-721 est le standard NFT classique. Une de ses caractéristiques : quand un token est transféré à un smart contract via safeTransferFrom, le contrat destinataire doit implémenter une fonction onERC721Received qui est appelée automatiquement. C’est un mécanisme de sécurité pour s’assurer que le contrat sait gérer le NFT.
ERC-3525 est un standard plus récent (2023) pour les Semi-Fungible Tokens (SFT). Un SFT combine les caractéristiques d’un NFT (identité unique) et d’un ERC-20 (fongibilité partielle, par exemple plusieurs « parts » d’un même type). Le standard ERC-3525 hérite des callbacks ERC-721 pour la rétrocompatibilité.
La faille Solv : la fonction mint() du contrat BitcoinReserveOffering avait le comportement suivant, simplifié :
- L’utilisateur appelle
mint()avec un dépôt de N BRO. - La fonction appelle
doSafeTransferIn()qui transfère le SFT au contrat. - Pendant ce transfert,
safeTransferFrom()du token ERC-3525 est appelée. - Le standard force l’appel de
onERC721Received()sur le contrat destinataire (BRO vault). - Dans ce callback, le contrat appelle
_mint()pour émettre les nouveaux BRO à l’utilisateur. - Le contrôle revient à la fonction
mint()originale, qui appelle à nouveau_mint()pour le même dépôt.
Conséquence : le contrat émet deux fois les BRO pour un seul dépôt. Si l’attaquant peut faire en sorte que le onERC721Received soit appelable à nouveau (en chaînant les transferts), il peut exploiter la faille en boucle.
L’attaquant a structuré son exploit pour boucler 22 fois, ce qui multiplie ses BRO par 2^22 = 4,2 millions x. De 135 BRO de départ, il termine avec 567 millions de BRO. Le fait que la valeur d’un BRO soit relativement faible (le pool BRO vault représentait ~3 M$) limite les pertes finales à 2,7 M$, mais sur un protocole avec 100 M$ dans le vault, le même mécanisme aurait drainé 100 M$.
Le détail technique complet est documenté dans l’analyse DEV.to et le post-mortem Verichains.
Le détail le plus accablant : aucun audit
Ce qui rend ce hack particulièrement frustrant : le contrat BitcoinReserveOffering n’a jamais été audité.
Solv Protocol affichait fièrement 5 cabinets d’audit sur son GitHub : Halborn, SlowMist, Quantstamp, etc. La page « Security » du site officiel listait ces audits, donnant l’impression d’un protocole correctement vérifié. Mais le scope des audits ne couvrait pas le BRO vault.
Selon l’analyse Olympix, les audits Solv portaient sur :
- L’infrastructure Web2 (API, backend).
- Les contrats Solana (Solv a une présence multi-chain).
- Certains contrats Ethereum core (SolvBTC mint/redeem).
- Mais pas le BitcoinReserveOffering déployé en production.
Le bug bounty Solv chez Immunefi avait également une couverture limitée : Web2 + Solana, pas Ethereum BRO. Aucun chercheur sécurité n’avait été incité à examiner ce contrat précis.
C’est exactement le même pattern que CrossCurve en février 2026 (cf. notre article dédié) : un protocole avec audits sur certains contrats, mais pas sur le contrat critique exploité. Les utilisateurs voyaient « audited by 5 firms » et présumaient une couverture complète, sans vérifier le scope.
L’analyse Rekt News titre simplement : « le contrat n’aurait jamais dû shipper sans audit ». La reentrancy ERC-3525/ERC-721 est un pattern documenté dans la littérature sécurité depuis 2023. Un audit Slither, Mythril ou Foundry invariant testing aurait quasi certainement détecté la faille en moins d’une heure.
Le blanchiment via RailGun
Détail technique intéressant sur la trajectoire des fonds : l’attaquant a utilisé RailGun plutôt que Tornado Cash pour le blanchiment.
RailGun est un protocole privacy on-chain Ethereum, conçu spécifiquement pour permettre des transferts confidentiels via zkSNARKs sans les implications réglementaires de Tornado Cash (sanctionné par l’OFAC depuis août 2022). RailGun se positionne comme « privacy on-chain compatible avec le compliance », avec des features comme le proof-of-innocence pour les utilisateurs légitimes.
Pour un attaquant, l’avantage de RailGun vs Tornado Cash :
- Pas de sanctions OFAC explicites sur RailGun (au moment des faits).
- Liquidité suffisante : RailGun avait ~50 M$ de pools privacy actifs en 2026.
- Pattern moins surveillé : la plupart des outils de monitoring sécurité crypto ciblent prioritairement Tornado Cash.
L’attaquant Solv a déposé ses 1 211 ETH dans RailGun en plusieurs transactions, brouillant la traçabilité. Les blockchain analytics peuvent suivre l’entrée, mais pas la sortie, sauf si l’attaquant fait l’erreur de lier sa sortie à une adresse KYC.
C’est une évolution comparable à 2024-2025, où les blanchiments étaient majoritairement Tornado Cash. En 2026, les attaquants diversifient : RailGun, THORChain (cf. hack IoTeX), Privacy Pools, autres mixers émergents.
Que retenir pour les utilisateurs Bitcoin tokenisé
Quatre conclusions pratiques pour un utilisateur retail français qui détient ou veut détenir du BTC tokenisé.
Vérifier le scope précis des audits. « Audited by Halborn » ne suffit pas. Demander spécifiquement : « le contrat où mes fonds vont être déposés est-il dans le scope ? » Si la réponse est floue ou refuse, c’est un drapeau rouge sérieux. Pour Solv, les holders BRO auraient pu identifier la zone non auditée en examinant attentivement le scope des audits publiés.
Privilégier les protocoles BTC tokenisé établis. WBTC (BitGo, depuis 2019) et cbBTC (Coinbase, depuis 2024) ont des architectures simples, audités, et battle-tested sur des milliards de TVL pendant des années. Pour des montants 10 K$+, privilégier ces options aux nouveaux entrants comme SolvBTC ou Lombard.
Limiter les expérimentations. Les produits expérimentaux comme les BRO vaults sont intéressants pour la composabilité DeFi, mais ils accumulent les risques. Tester avec des montants modestes (1-5 % du portfolio crypto max) et attendre 12-24 mois de track record avant d’augmenter.
Surveiller les annonces post-mortem. Quand un protocole subit un hack, sa réponse en dit beaucoup. Solv a réagi correctement (couverture des pertes, post-mortem détaillé, communication transparente), ce qui maintient la confiance pour le long terme. Une équipe qui essaie de cacher ou minimiser un hack est un signal alarmant.
Pour les bases sur le BTC tokenisé, voyez nos articles Qu’est-ce que le bitcoin emballé (Wrapped BTC ou WBTC) et Le bitcoin BTC est-il une valeur refuge ?.
Solv Protocol va-t-il survivre au hack ?
Très probablement oui. Solv gère ~2 Md$ de TVL et le hack ne représente que 0,135 % de cette TVL. La réserve protocol a couvert les pertes des utilisateurs touchés sans socialisation. La communication post-incident a été transparente et professionnelle. Le SolvBTC reste opérationnel et bien valorisé. Les BRO vaults seront repensés avec audit complet avant relance. Pas de risque existentiel comme on a vu pour Step Finance en janvier.
Mes SolvBTC sont-ils en danger ?
Non, les holders SolvBTC standard ne sont pas affectés par le hack. L’exploit a ciblé spécifiquement le BitcoinReserveOffering vault, un produit expérimental distinct. Le contrat SolvBTC principal n’a pas été compromis. Pour vérifier votre exposition : connectez votre wallet à app.solv.finance et regardez si vous avez des positions BRO actives. Si oui, attendre l’annonce officielle de remboursement.
Qu’est-ce qu’un ERC-3525 exactement ?
Un standard de Semi-Fungible Tokens (SFT) sur Ethereum, finalisé en 2023. Combine les caractéristiques NFT (chaque token a un ID unique) et ERC-20 (les tokens du même type sont fongibles entre eux). Use cases typiques : actions tokenisées (fongible mais avec différentes classes), bonds tokenisés (fongibles dans la même série), produits structurés DeFi. Le standard est puissant mais sa complexité crée des surfaces d’attaque comme la reentrancy ERC-721 démontrée par Solv.
Pourquoi RailGun et pas Tornado Cash ?
Tornado Cash est sanctionné par l’OFAC depuis août 2022, ce qui rend tous les transferts via TC traçables et signalés par les outils compliance. Les exchanges centralisés gèlent les fonds qui ont transité par Tornado Cash. RailGun n’a pas (encore) cette mauvaise réputation réglementaire et ses pools sont moins surveillés. C’est devenu le mixer privacy de choix pour beaucoup d’attaquants en 2026, malgré ses propres mécanismes anti-money-laundering (proof of innocence).
Comment vérifier qu’un contrat est correctement audité ?
Quatre vérifications. Un, demander la liste des audits avec dates et scopes spécifiques. Deux, vérifier que le contrat exact où vos fonds vont (par adresse Etherscan) est dans le scope publié. Trois, regarder l’âge du dernier audit (idéalement < 12 mois sur la version actuelle). Quatre, croiser avec les bases publiques : CertiK Skynet (skynet.certik.com), Halborn Skylight, OpenZeppelin Audits. Si l’un de ces quatre éléments manque, c’est un drapeau rouge sérieux.
L’exploit reentrancy ERC-3525 est-il connu de la communauté ?
Oui, depuis 2023-2024. Plusieurs auditeurs (OpenZeppelin, Trail of Bits) avaient publié des analyses sur les risques d’interaction ERC-3525/ERC-721. Le pattern « callback réentrant via doSafeTransferIn » est documenté dans la littérature sécurité Ethereum. Solv Protocol n’a pas pu invoquer une faille « inconnue ». C’est exactement le type de vulnérabilité qu’un audit standard aurait détectée. L’absence d’audit sur le BRO vault est donc une responsabilité directe de l’équipe.
Que retenir du hack Solv Protocol
Le hack Solv Protocol du 5 mars 2026 est moins remarquable par son montant (2,7 M$, modeste) que par sa leçon sur la nature des audits. Trois points à retenir.
« Audité par X cabinets » ne suffit pas. Le scope précis de l’audit compte autant que sa présence. Solv affichait 5 audits, mais le contrat exploité n’était dans aucun scope. Les utilisateurs qui ont fait confiance à la simple mention « audited » ont payé le prix d’une vérification superficielle. Le pattern se répète régulièrement (Solv, CrossCurve, IoTeX, Truebit) : les protocoles communiquent sur les audits sans préciser le scope, et les utilisateurs ne creusent pas.
Les contrats expérimentaux méritent une vigilance accrue. Le BRO vault était un produit expérimental, déployé rapidement pour saisir une opportunité de marché. Cette urgence a justifié de raccourcir les audits. C’est un trade-off business compréhensible mais qui retombe sur les utilisateurs. Pour des montants significatifs, privilégier les produits matures et bien audités.
Les white hat bounties ne sont pas une solution miracle. Solv a offert 10 % (270 K$) à l’attaquant en échange du retour des fonds. L’attaquant n’a pas répondu, sans doute parce que les 2,7 M$ via blanchiment RailGun valaient plus que le bounty. Sur les hacks 2025-2026, le taux de retour via white hat bounty reste autour de 25-35 %, pas une garantie.
Pour aller plus loin, voyez aussi nos articles sur le hack CrossCurve (autre cas d’audit incomplet), le hack IoTeX (cas clé admin compromise), le hack Foom Cash (cas trusted setup), et le hack Venus Protocol (cas donation attack).
