Estándares de seguridad DeFi de Stellar y mejores prácticas

DeFi en Stellar ya no es experimental: los protocolos ya están disponibles, bloquean cientos de millones de dólares en valor y operan a una escala que impacta a miles de usuarios. Ese es un hito digno de reconocer. También es un momento que exige más de muchos equipos en el ecosistema.

Esta publicación define un conjunto de prácticas que SDF considera deberían ser estándar para cualquier protocolo DeFi en Stellar que custodie, preste, haga swaps o de otro modo toque fondos de usuarios. Algunos equipos ya hacen la mayoría de esto. Otros están trabajando para lograrlo. Lo ponemos por escrito porque los creadores nos han dicho que quieren una imagen más clara de cómo luce lo bueno, y porque el ecosistema es más saludable cuando las expectativas son explícitas y no asumidas.

Ninguna de las sugerencias es novedosa. La mayoría reflejan lo que los equipos DeFi maduros ya hacen en otros ecosistemas, adaptado a las realidades de construir en Stellar. Lo publicamos para que la conversación pueda ser más concreta: esto es lo que queremos decir cuando hablamos de DeFi responsable en Stellar.

Tres cosas han cambiado en el último año.

Primero, el ecosistema DeFi de Stellar está en un lugar diferente al de hace doce meses. Más usuarios están activos onchain, más valor está en pools de préstamos y AMM, y más protocolos se componen entre sí. Prácticas que eran razonables para un pool experimental en etapa temprana no funcionan para un protocolo de producción que custodia decenas de millones de dólares de fondos de usuarios.

Segundo, el lado del atacante se ha vuelto más rápido, más barato y más capaz. El descubrimiento de vulnerabilidades, la generación de código de exploit, la ingeniería social a escala y el reconocimiento contra contratos desplegados han pasado de "especialista calificado con semanas de tiempo" a "operador competente con una buena cadena de herramientas". Ahora se ejecuta análisis asistido por IA contra informes de auditoría publicados para encontrar lo que los auditores señalaron pero los equipos no remediaron por completo, y contra código de contratos open-source para aflorar patrones que han sido explotados en otros lugares. El resultado es que las manipulaciones de oráculos, nuevos patrones de préstamos flash, tomas de control de gobernanza y compromisos de claves de administrador ya no son eventos raros en la frontera de DeFi: son un riesgo operativo base para cualquier protocolo de tamaño significativo. Un equipo que lanza sin pensar estas posibilidades no está innovando; está externalizando el riesgo a sus usuarios.

Tercero, el ecosistema DeFi de Stellar ahora tiene suficiente interconexión como para que la falla de un protocolo se propague a varios otros. Un oráculo comprometido, un pool de liquidez drenado o una cascada de liquidaciones forzadas no se quedan contenidos. Los estándares son en parte una herramienta para proteger a los usuarios de un protocolo individual, pero también son una herramienta para proteger al resto del ecosistema del error de un único protocolo.

No creemos que la respuesta sea una vigilancia restrictiva. Stellar es sin permisos y debería seguir así. Pero el acceso sin permisos no significa que los protocolos que custodian fondos de usuarios deban operar sin prácticas maduras de seguridad y riesgo. Estos son los estándares que SDF espera que los equipos DeFi serios trabajen por alcanzar, y lo que sigue es lo que nos gustaría que se vuelva normal.

Una auditoría de seguridad de terceros por una firma reconocida es un requisito básico para cualquier protocolo que maneje fondos de usuarios. Lo básico:

Una auditoría completada antes de aceptar cualquier fondo significativo de usuarios, realizada por una firma con un historial comprobado en la primitiva relevante (préstamos, AMM, derivados, puentes, etc.). El informe de auditoría debe publicarse, no solo resumirse en un tuit, e incluir un resumen completo de hallazgos, el estado de remediación de todas las vulnerabilidades descubiertas y la versión específica del código que se revisó.

Paridad entre auditoría y despliegue. El código que corre en producción debe ser el código que se revisó. Cuando los equipos desplieguen cambios significativos después de la última auditoría, esos cambios deben divulgarse, y debe iniciarse una re-auditoría (o como mínimo una revisión de seguimiento acotada) antes de empujar los cambios a mainnet.

Cadencia de auditoría ligada al cambio, no al calendario. Un protocolo que lanza con frecuencia necesita un socio de seguridad que revise con frecuencia. Un protocolo que es en gran medida estático tras el lanzamiento aún se beneficia de revisiones periódicas a medida que evoluciona el panorama de amenazas.

Cuando la ausencia de una auditoría sea inevitable —para experimentos tempranos, proyectos de hackathon o código genuinamente pre-producto— ese estado debe comunicarse de forma inequívoca a los usuarios, y el protocolo no debe comercializarse como listo para producción.

Una auditoría es una instantánea en un momento dado. Te dice que el código era sólido en una versión particular en una fecha particular, revisado por un conjunto particular de ojos. No dice nada sobre la vulnerabilidad descubierta seis meses después, o sobre el investigador que encuentra un bug la próxima semana y tiene que decidir qué hacer con él. Los protocolos en vivo necesitan una forma de recibir esa información de manera segura, y un protocolo en vivo sin una está confiando en que quien encuentre el próximo bug elija reportarlo en lugar de explotarlo o venderlo.

Lo básico:

Una política publicada de divulgación de vulnerabilidades que le diga a un investigador exactamente adónde enviar un reporte, qué está en alcance, qué esperar como respuesta y un compromiso de no perseguir a quienes reportan de buena fe. Esto debe ser trivial de encontrar—vinculado desde la documentación y el sitio, no enterrado en un canal de Discord.

Un programa permanente de recompensas por bugs, escalado de forma que la recompensa por un hallazgo crítico sea significativa en relación con lo que un atacante podría extraer explotándolo en su lugar. Una recompensa que paga una fracción del valor explotable no está realmente compitiendo por la decisión del investigador.

Un proceso de triaje y remediación con plazos comprometidos, para que los reportes no queden sin leer. Un investigador que no recibe acuse de recibo durante dos semanas es un investigador que deja de reportar—o reporta en algún lugar donde preferirías que no lo hiciera.

Las auditorías son necesarias pero no suficientes. Un protocolo que custodia decenas de millones de dólares en fondos de usuarios debe operar con una postura de seguridad y riesgo operativo acorde con la mera escala de los activos que gestiona. Cómo se ve esto en la práctica depende del tamaño, etapa y estructura de un protocolo, pero los componentes son en gran medida los mismos:

Procedimientos de riesgo por escrito que describan cómo el equipo identifica, evalúa y responde a riesgos de seguridad y operativos. Estos deben incluir una declaración de apetito de riesgo que describa qué está dispuesto a aceptar el equipo, qué no, y cómo se hacen cumplir esas líneas.

Política escrita de gestión de riesgos de proveedores y socios, incluyendo una visión clara de cada dependencia externa. De qué oráculos depende un protocolo, de qué puentes, qué servicios off-chain, qué pasa si cualquiera de ellos está equivocado o es comprometido, y qué haría el equipo en la primera hora después de una falla.

Procedimientos de seguridad para el propio equipo, incluyendo arreglos de custodia de claves, umbrales de multisig, prácticas de billetera de hardware, requisitos de revisión de código y controles de despliegue.

Para protocolos a escala, alentamos la validación independiente de estos controles—informes SOC 1 / SOC 2 o una atestación de terceros funcionalmente equivalente. El objetivo no es el certificado; es la disciplina de ser auditado por alguien que no está en el equipo.

No todo fallo en DeFi es un exploit de código. Algunas de las pérdidas más dañinas provienen de un diseño económico que era sólido bajo condiciones normales y se rompió bajo estrés: colateral que no pudo liquidarse lo suficientemente rápido en una caída abrupta, incentivos que se deshicieron en una dinámica de corrida bancaria, un parámetro que era seguro en aislamiento y peligroso en combinación con otro. Las auditorías de código rara vez detectan esto, porque el código hizo exactamente lo que estaba escrito para hacer. El diseño era la vulnerabilidad.

Los protocolos cuya seguridad depende de parámetros económicos —mercados de préstamos, AMM, stablecoins, derivados— deben tratar ese diseño con el mismo rigor que el código:

Pruebas de estrés y modelado de escenarios contra movimientos bruscos de precio, crisis de liquidez y caídas correlacionadas, no solo condiciones de estado estable. La pregunta relevante no es si el sistema funciona en un día promedio sino si sobrevive a su peor día plausible.

Límites de concentración sobre el colateral, la liquidez y la exposición a contrapartes, para que un único activo, pool o actor no pueda poner en riesgo a todo el protocolo.

Simulaciones de liquidación que confirmen que las posiciones realmente pueden deshacerse a escala, bajo estrés, con la liquidez que estaría disponible de forma realista—no la liquidez presente en un día tranquilo.

Modelado de manipulación de oráculos que se pregunta qué podría hacer un adversario moviendo un feed de precios, y cuánto le costaría en relación con lo que ganaría.

Un proceso de revisión de cambios de parámetros. Los cambios a los parámetros de riesgo—factores de colateral, curvas de tasas de interés, umbrales de liquidación—deben pasar por una revisión documentada y, para cambios no urgentes, el mismo bloqueo temporal y disciplina de divulgación que cualquier otra acción privilegiada. Un ajuste de parámetro puede drenar un protocolo con la misma eficacia que un error de código.

Los protocolos DeFi que se recuperan de incidentes suelen ser los que planificaron financieramente para ellos antes de que ocurrieran. Esa planificación tiene dos partes.

Primero, un colchón de capital. Como referencia direccional, alentamos a los protocolos a reservar aproximadamente el 5% del total de pasivos frente al usuario como recurso de primera pérdida. Para un protocolo con $100M de TVL, eso es del orden de $5M en activos líquidos destinados a absorber choques antes de que lleguen a los usuarios. La cifra exacta es menos importante que el principio: el equipo debe saber, de antemano, cuánto puede absorber sin que los usuarios reciban el impacto y dónde reside ese capital. Para protocolos descentralizados, esto puede tomar la forma de una asignación de tesorería, un módulo de seguridad controlado por la gobernanza, o un mecanismo equivalente apropiado para la estructura del protocolo.

Segundo, seguros donde tenga sentido. No es un sustituto de la seguridad, pero sí una herramienta significativa, y nos gustaría ver a más protocolos de Stellar evaluándolo seriamente.

En conjunto, un colchón de capital y seguros son la forma en que un protocolo dice, por adelantado, que el costo de un mal día no recaerá por completo en sus usuarios.

Algunas de las mayores pérdidas en la historia de DeFi han resultado de dependencias comprometidas: oráculos manipulados, puentes hackeados, claves filtradas. Todo equipo debe prestar atención a la higiene de la infraestructura, que se ve así:

Para protocolos que consumen oráculos de precios: protecciones ante desviaciones de precio, promedios ponderados por tiempo, consenso de múltiples fuentes y cortacircuitos que pausen funciones sensibles cuando algo se ve mal. No confíes en una única fuente de precios para decisiones de liquidación si puedes evitarlo.

Para protocolos que operan puentes o lógica entre cadenas: supuestos documentados sobre cada cadena con la que interactúas, y un plan de respuesta por escrito para el día en que una cadena contraparte tenga un problema.

Para claves de administrador y gobernanza del protocolo: multifirma con umbrales significativos y firmantes distribuidos geográficamente; almacenamiento de claves en hardware; procedimientos claramente documentados y ensayados para acciones de emergencia. La comodidad de una sola clave no vale lo que cuesta cuando se ve comprometida.

Para cortacircuitos y pausas de emergencia: constrúyelos, pruébalos y ten claro quién puede tirar de la palanca. Un protocolo que no puede pausar un contrato comprometido es un protocolo que ve a sus usuarios perder fondos en tiempo real.

La mayoría de los protocolos DeFi en Stellar conservan algún poder privilegiado: una clave de administrador que puede pausar el sistema, un proceso de gobernanza que puede cambiar parámetros, una vía de actualización que puede reemplazar la lógica del contrato en la que confían los usuarios. Estas capacidades suelen ser necesarias. También son, en las manos equivocadas, la forma más rápida de drenar un protocolo—una toma de control de la gobernanza o una clave de administrador comprometida no necesita encontrar un error, porque ya tiene las llaves. El estándar aquí es que el poder privilegiado esté restringido, documentado y sea observable:

Documentación pública de cada rol privilegiado —lo que puede hacer, quién lo posee y cómo está restringido. Los usuarios e integradores deberían poder ver el conjunto completo de poderes que existen sobre un protocolo sin leer el código fuente ni confiar en una garantía verbal.

Multifirma con umbrales significativos y firmantes distribuidos geográficamente, almacenamiento de claves en hardware, y un proceso definido y ensayado para la rotación de firmantes cuando alguien se une, se va o se ve comprometido. La comodidad de una sola clave no vale lo que cuesta cuando se ve comprometida.

Bloqueos temporales en cambios privilegiados no urgentes, para que los usuarios puedan ver venir un cambio y salir si no están de acuerdo. Un protocolo que puede alterar las reglas sin demora les pide a los usuarios que confíen en que nunca lo hará.

Poderes de emergencia claramente acotados. Las acciones de emergencia—pausar, congelar, detener—deben definirse de forma estricta y limitarse a lo necesario para frenar un incidente, no ser una puerta trasera para un control arbitrario. Documenta qué poderes de emergencia existen, quién puede invocarlos y qué pueden y no pueden hacer.

Requisitos de quórum y mitigaciones frente a ataques de gobernanza para la gobernanza onchain: umbrales sensatos para propuestas, demoras y periodos de votación, y defensas contra capturas de voto financiadas con préstamos flash y otras manipulaciones de gobernanza. Una gobernanza que puede alquilarse por una tarde no es una salvaguarda.

El peor momento para definir la respuesta a incidentes es durante un incidente. Los equipos que manejan bien los exploits—los que recuperan la confianza y a veces los fondos—son los que tenían un manual antes de que llegara la llamada. Como mínimo, eso significa:

Monitoreo y alertas onchain en tiempo real. No puedes responder a lo que no detectas. Los protocolos deben vigilar activamente sus propios contratos en busca de actividad anormal—retiros anómalos, movimientos inesperados de precios o balances, patrones de llamadas inusuales, desviaciones de oráculos, caídas repentinas en las reservas—con alertas automatizadas que lleguen rápido a la persona de guardia. Ya sea desarrollado internamente o a través de un proveedor de monitoreo, el objetivo son minutos hasta la detección, no horas, y la capacidad de activar una pausa con la fuerza de una alerta. Muchos de los peores desenlaces en DeFi no fueron causados solo por el exploit sino por las horas que pasaron antes de que alguien se diera cuenta.

Un líder de incidente designado y una ruta de escalamiento documentada antes de que algo salga mal. Cada miembro del equipo debe saber a quién llama a las 3 a. m. y qué está facultada esa persona para hacer.

Un informe preliminar del incidente dentro de unas 48 horas desde la detección, documentando direcciones afectadas, pérdidas estimadas y la causa raíz preliminar. Esto es para los usuarios, para el ecosistema más amplio y para cualquier socio que necesite tomar decisiones basadas en lo ocurrido.

Un post-mortem completo, publicado, con suficiente detalle técnico para que otros creadores en Stellar puedan aprender de ello. La tentación de enterrar un incidente es real y la entendemos; el costo a largo plazo de hacerlo es mucho mayor que la vergüenza a corto plazo de ser transparente.

Cooperación activa con firmas de analítica de blockchain y, cuando corresponda, autoridades. Los fondos se recuperan cuando las personas adecuadas ven las transacciones correctas a tiempo.

Un plan de restitución a usuarios que el equipo pueda ejecutar de verdad, incluyendo direcciones verificadas, canales de comunicación y un cronograma claro.

Todo lo anterior es más fácil de confiar cuando los usuarios pueden verificarlo. Gran parte de DeFi todavía les pide a los usuarios que tomen la seguridad de un protocolo por fe—o que la reconstruyan ellos mismos a partir de exploradores de bloques y GitHub. Un protocolo que acepta fondos de usuarios significativos debería poder señalar un único lugar donde una persona común, o un protocolo que se integra con él, pueda ver qué es cierto. Nos gustaría ver una página pública de riesgos—enlazada desde la documentación y la app—que consolide:

El historial de auditorías, con enlaces a los informes completos publicados y a las versiones de código que cubrieron.

Riesgos conocidos y limitaciones actuales, expuestos claramente. Todo protocolo los tiene; los confiables lo dicen.

Los roles privilegiados y las vías de actualización que existen sobre el protocolo, en consonancia con la documentación de gobernanza anterior.

Dependencias externas —los oráculos, puentes y servicios off-chain de los que depende el protocolo—y lo que significaría para los usuarios que cualquiera de ellos esté equivocado o comprometido.

El estado de los respaldos financieros, incluyendo el colchón de capital y cualquier cobertura de seguro, para que los usuarios sepan qué protección existe realmente en lugar de asumir.

Historial de incidentes, incluidos enlaces a post-mortems anteriores. Un protocolo que haya pasado por un incidente y lo haya manejado bien se ha ganado el derecho a demostrarlo.

Nada de esto es exótico; es la información que los usuarios necesitarían para tomar una decisión informada, reunida en un solo lugar en lugar de estar dispersa o retenida. La transparencia no es solo una buena práctica—es la forma en que un ecosistema construye el tipo de confianza que sobrevive a un mal día.

Parte de lo anterior supone un equipo que pueda ser identificado y hecho responsable. Muchos de los mejores protocolos de Stellar son, o aspiran a ser, más descentralizados que eso. Vemos la tensión, y no creemos que sea un motivo para bajar el listón.

Para los protocolos descentralizados, la pregunta es si existen controles funcionalmente equivalentes. Procesos de gobernanza que produzcan una rendición de cuentas real. Salvaguardas técnicas que no dependan de que una persona esté de guardia. Acuerdos de tesorería que sobrevivan a la rotación de colaboradores. Mecanismos de transparencia que permitan a los usuarios ver lo que es cierto sin tener que tomar la palabra de nadie. La forma del control puede diferir; la sustancia no debería.

Nada de esto es una lista de verificación que esperemos que todo protocolo cumpla el primer día. La madurez lleva tiempo. Los equipos nuevos estarán más al inicio de esta curva que los establecidos, y eso es apropiado. Lo que nos gustaría ver es movimiento: cada protocolo en Stellar trabajando visiblemente hacia un estándar más alto, y una comunidad donde los equipos hablen entre sí sobre cómo llegar allí.

SDF seguirá contribuyendo a esto de las formas en que podamos: convocando mesas redondas de seguridad, brindando soporte para el acceso a auditores reconocidos para equipos en etapas tempranas a través de nuestro Audit Bank, publicando lo que aprendemos de los incidentes que el ecosistema ha vivido e interactuando con la comunidad más amplia de seguridad DeFi en estándares que funcionen. Nos encantaría construir estas prácticas junto contigo. También creemos que cualquier protocolo que acepte fondos significativos de usuarios debería poder explicar qué controles están implementados, cuáles faltan, qué riesgo crea eso para los usuarios y cuándo se cerrarán las brechas.

Si eres un creador en Stellar y te gustaría hablar sobre cómo esto se aplica a lo que estás trabajando, por favor, contáctanos. El ecosistema DeFi más fuerte es aquel donde estas prácticas son normales, no excepcionales. Y sabemos que Stellar está bien posicionada para llegar allí.