Beaucoup de gens voient qu'un protocole a été hacké et leur première réaction est de le rayer de la liste. Je ressens de plus en plus que l'historique des incidents d'un protocole est l'une des informations les plus facilement mal interprétées que j'ai à ma disposition.
Concernant Bedrock, je regarde les choses de manière transparente. Avant qu'ils ne mettent en place leur version 2.0 avec multi-actifs et le flywheel PoSL, ils ont connu deux incidents : en septembre 2024, le contrat uniBTC a présenté une faille d'émission excessive, entraînant une perte d'environ deux millions de dollars ; en juin 2025, ils ont subi un retrait de liquidité, avec plus de vingt adresses qui ont retiré environ quarante-sept millions en une centaine de secondes, faisant chuter le prix de la cryptomonnaie. Mis ensemble, ces deux incidents sont effectivement laids, quiconque dit "peu importe" est en train de masquer la réalité.
Mais ce que je veux vraiment dire, c'est comment les lire. Avoir été hacké une fois et ce que cet incident dit réellement sont deux choses différentes. Je vais d'abord voir si ces deux incidents sont de la même catégorie de problèmes — l'un est une faille d'émission au niveau du contrat, l'autre est un événement de marché au niveau de la liquidité, ce n'est pas la même chose, ce qui signifie qu'ils ne tombent pas dans le même piège à plusieurs reprises. Ensuite, je vais examiner comment l'équipe a réagi à l'époque : lors de l'incident de juin, l'équipe a rapidement rendu publics les adresses LP impliquées et a fourni une couverture de liquidité, sans faire l'autruche. Ces actions en disent plus que "avoir eu ou non des problèmes". Un protocole qui n'a jamais été hacké n'est parfois qu'un protocole qui n'a pas encore été attaqué sérieusement.
Donc, les cicatrices @Bedrock me permettent de développer un outil pour lire les incidents : ne considérez pas "avoir été hacké" comme une croix à rayer, mais regardez trois choses — si les deux incidents sont de la même catégorie de problèmes, si l'équipe a fait face de manière proactive, et si les types de failles ont été comblés à la source. Si ces trois points sont bien répondus, l'historique des incidents est le coût de l'apprentissage ; si ce n'est pas le cas, alors ce sont les véritables mines à éviter. Quant à savoir si $BR vaut le coup d'être touché, ces deux incidents ne sont pas une conclusion, mais un ensemble d'échantillons qui vous permettent de mieux comprendre la qualité de l'équipe. La capacité à ne pas répéter les mêmes erreurs est beaucoup plus importante que le fait qu'ils aient déjà chuté, #bedrock $BR .
Concernant Bedrock, je regarde les choses de manière transparente. Avant qu'ils ne mettent en place leur version 2.0 avec multi-actifs et le flywheel PoSL, ils ont connu deux incidents : en septembre 2024, le contrat uniBTC a présenté une faille d'émission excessive, entraînant une perte d'environ deux millions de dollars ; en juin 2025, ils ont subi un retrait de liquidité, avec plus de vingt adresses qui ont retiré environ quarante-sept millions en une centaine de secondes, faisant chuter le prix de la cryptomonnaie. Mis ensemble, ces deux incidents sont effectivement laids, quiconque dit "peu importe" est en train de masquer la réalité.
Mais ce que je veux vraiment dire, c'est comment les lire. Avoir été hacké une fois et ce que cet incident dit réellement sont deux choses différentes. Je vais d'abord voir si ces deux incidents sont de la même catégorie de problèmes — l'un est une faille d'émission au niveau du contrat, l'autre est un événement de marché au niveau de la liquidité, ce n'est pas la même chose, ce qui signifie qu'ils ne tombent pas dans le même piège à plusieurs reprises. Ensuite, je vais examiner comment l'équipe a réagi à l'époque : lors de l'incident de juin, l'équipe a rapidement rendu publics les adresses LP impliquées et a fourni une couverture de liquidité, sans faire l'autruche. Ces actions en disent plus que "avoir eu ou non des problèmes". Un protocole qui n'a jamais été hacké n'est parfois qu'un protocole qui n'a pas encore été attaqué sérieusement.
Donc, les cicatrices @Bedrock me permettent de développer un outil pour lire les incidents : ne considérez pas "avoir été hacké" comme une croix à rayer, mais regardez trois choses — si les deux incidents sont de la même catégorie de problèmes, si l'équipe a fait face de manière proactive, et si les types de failles ont été comblés à la source. Si ces trois points sont bien répondus, l'historique des incidents est le coût de l'apprentissage ; si ce n'est pas le cas, alors ce sont les véritables mines à éviter. Quant à savoir si $BR vaut le coup d'être touché, ces deux incidents ne sont pas une conclusion, mais un ensemble d'échantillons qui vous permettent de mieux comprendre la qualité de l'équipe. La capacité à ne pas répéter les mêmes erreurs est beaucoup plus importante que le fait qu'ils aient déjà chuté, #bedrock $BR .