El exploit de Drift acabó con Carrot: por qué tu yield farm sigue en riesgo

Llevo unos años viendo cómo la gente persigue el porcentaje de rendimiento más alto, ignorando casi siempre las tuberías que hay debajo del protocolo. El reciente colapso de Carrot después del exploit de Drift es el ejemplo perfecto de por qué esto es peligroso. Si quieres aprender a identificar yield farms riesgosas, tienes que dejar de mirar el APY y empezar a mirar las dependencias.

La respuesta corta

El colapso de Carrot pasó por un efecto de contagio. No es que Carrot tuviera necesariamente un error en su propio código, sino que dependía de Drift para generar sus rendimientos. Cuando Drift fue vulnerado, el valor que respaldaba a Carrot desapareció. En DeFi, si el Protocolo B usa el Protocolo A para ganar dinero, el Protocolo B es tan seguro como lo sea el Protocolo A.

Cómo funcionó el contagio en realidad

Para entender esto, hay que dejar de pensar en los protocolos DeFi como islas aisladas. Son más bien como un castillo de naipes. Muchos optimizadores de rendimiento o "bóvedas" no generan su propio rendimiento. Lo que hacen es tomar tus depósitos y moverlos a otros protocolos para buscar la mejor tasa.

En este caso, Carrot dependía muchísimo de Drift. Cuando ocurrió el exploit, no solo sufrieron quienes tenían fondos directamente en Drift. Se creó un vacío. Como el rendimiento de Carrot venía básicamente del ecosistema de Drift, en el momento en que Drift falló, los activos subyacentes de Carrot o el valor de sus tokens de recompensa se desplomaron.

Ya he visto este patrón antes. Es la misma lógica que impulsó la caída de Terra Luna, solo que a menor escala. Tienes una capa de riesgo y luego apilas otra capa encima. Si la base se rompe, todo lo que está arriba cae.

Donde la gente se equivoca

El error más grande que veo es la "ceguera del rendimiento". La gente ve un APY del 20% o 50% y deja de hacer preguntas. Asumen que el protocolo es seguro porque tiene un panel bonito o muchos seguidores en Twitter.

Otra idea falsa es que, si un protocolo está "auditado", entonces es seguro. Una auditoría es solo una foto del código en un momento dado. No te protege del contagio. Una auditoría de Carrot pudo haber dicho que su código estaba bien, pero eso no evitaría que Carrot colapsara si el protocolo donde depositaba el dinero era hackeado.

Cómo identificar yield farms riesgosas

Si quieres evitar el próximo Carrot, tienes que hacer un poco de trabajo de detective antes de depositar tus fondos. Esto es lo que yo busco.

Revisa la fuente del rendimiento

Pregúntate: ¿de dónde viene realmente este dinero? Si el protocolo dice que usa "estrategias avanzadas", normalmente significa que están anidando tu dinero en otros protocolos. Si no encuentras una lista clara de dónde están los fondos, el riesgo es demasiado alto.

Cuidado con los bucles recursivos

Huye de los protocolos que usan su propio token como colateral para pedir prestado más del mismo token y así farmear más rendimiento. Esto crea un bucle de retroalimentación. Cuando el precio cae, se dispara una cascada de liquidaciones que puede borrar todo el sistema en minutos.

Analiza la cadena de dependencias

Siempre intento dibujar el "árbol de dependencias". Si pongo dinero en el Protocolo X, y el Protocolo X lo pone en el Protocolo Y, y el Protocolo Y usa un puente para moverlo al Protocolo Z, ahora estoy expuesto a tres puntos de fallo distintos. Yo prefiero estrategias más simples.

Llevándolo a la práctica

Si ya te cansaste de perseguir rendimientos y solo quieres mantener tus activos principales a salvo, lo mejor es sacarlos de los exchanges y llevarlos a un almacenamiento frío. Yo uso la Ledger Nano X porque me deja gestionar mi cartera por Bluetooth desde el móvil sin perder la seguridad de una firma de hardware. Es mucho más difícil perder los ahorros de tu vida en un evento de contagio cuando tus claves privadas no están en una hot wallet o en una granja arriesgada.

Si aun así quieres hacer farming, usa solo dinero que realmente no te importe perder. En mi experiencia, un rendimiento "seguro" del 5% siempre es mejor que un "quizás" del 50% que termina siendo un 0% después de un exploit.