Mucha gente al ver que un protocolo ha sido hackeado, su primera reacción es descartarlo. Cada vez estoy más convencido de que la historia de accidentes de un protocolo es una de las informaciones más fácilmente malinterpretadas que puedo obtener.
En cuanto a Bedrock, estoy analizando las cosas con transparencia. Antes de que lanzara su sistema 2.0 de múltiples activos y el efecto de PoSL, tuvo dos incidentes: en septiembre de 2024, el contrato de uniBTC presentó una vulnerabilidad de sobreemisión, con pérdidas de aproximadamente dos millones de dólares; en junio de 2025, sufrió una extracción masiva de liquidez, donde más de veinte direcciones sacaron alrededor de cuarenta y siete millones en unos cien segundos, lo que hizo que el precio se desplomara instantáneamente. Juntas, estas dos situaciones son poco atractivas, y cualquier persona que diga "no importa" está maquillando la realidad.
Sin embargo, lo que realmente quiero decir es cómo interpretarlo. Haber sido hackeado una vez y lo que esta última falla te indica son dos cosas distintas. Primero, mirar si estos dos incidentes son del mismo tipo: uno fue una vulnerabilidad en el contrato, y el otro un evento de mercado relacionado con la liquidez, lo que indica que no están tropezando en el mismo agujero una y otra vez. Luego, analizar cómo reaccionó el equipo en ese momento: en el incidente de junio, el equipo rápidamente hizo público el LP problemático y ofreció un respaldo de liquidez, no se hicieron los desentendidos. Estas acciones dicen más que el simple hecho de "haber tenido un problema". Un protocolo que nunca ha sido hackeado, a veces solo significa que simplemente no ha sido atacado de manera seria todavía.
Así que las cicatrices @Bedrock me han ayudado a afinar mi capacidad para leer accidentes: no confundas "haber sido hackeado" como una marca para descartar, sino que observa tres cosas: si los dos incidentes son del mismo tipo, si el equipo reaccionó de manera proactiva, y si han cerrado las vulnerabilidades de raíz. Si estas tres preguntas tienen buenas respuestas, la historia de accidentes es solo el costo de su aprendizaje; si no, ahí es donde realmente deberías tener cuidado. Si $BR vale la pena, estos dos incidentes no son la conclusión, son un conjunto de muestras que te permiten ver más claramente la calidad del equipo. Lo que importa más es si pueden evitar caer en el mismo error nuevamente, más que si han caído antes, #bedrock $BR .
En cuanto a Bedrock, estoy analizando las cosas con transparencia. Antes de que lanzara su sistema 2.0 de múltiples activos y el efecto de PoSL, tuvo dos incidentes: en septiembre de 2024, el contrato de uniBTC presentó una vulnerabilidad de sobreemisión, con pérdidas de aproximadamente dos millones de dólares; en junio de 2025, sufrió una extracción masiva de liquidez, donde más de veinte direcciones sacaron alrededor de cuarenta y siete millones en unos cien segundos, lo que hizo que el precio se desplomara instantáneamente. Juntas, estas dos situaciones son poco atractivas, y cualquier persona que diga "no importa" está maquillando la realidad.
Sin embargo, lo que realmente quiero decir es cómo interpretarlo. Haber sido hackeado una vez y lo que esta última falla te indica son dos cosas distintas. Primero, mirar si estos dos incidentes son del mismo tipo: uno fue una vulnerabilidad en el contrato, y el otro un evento de mercado relacionado con la liquidez, lo que indica que no están tropezando en el mismo agujero una y otra vez. Luego, analizar cómo reaccionó el equipo en ese momento: en el incidente de junio, el equipo rápidamente hizo público el LP problemático y ofreció un respaldo de liquidez, no se hicieron los desentendidos. Estas acciones dicen más que el simple hecho de "haber tenido un problema". Un protocolo que nunca ha sido hackeado, a veces solo significa que simplemente no ha sido atacado de manera seria todavía.
Así que las cicatrices @Bedrock me han ayudado a afinar mi capacidad para leer accidentes: no confundas "haber sido hackeado" como una marca para descartar, sino que observa tres cosas: si los dos incidentes son del mismo tipo, si el equipo reaccionó de manera proactiva, y si han cerrado las vulnerabilidades de raíz. Si estas tres preguntas tienen buenas respuestas, la historia de accidentes es solo el costo de su aprendizaje; si no, ahí es donde realmente deberías tener cuidado. Si $BR vale la pena, estos dos incidentes no son la conclusión, son un conjunto de muestras que te permiten ver más claramente la calidad del equipo. Lo que importa más es si pueden evitar caer en el mismo error nuevamente, más que si han caído antes, #bedrock $BR .