Guía de Evaluación de Riesgos de DeFi v1 (EEA)
Compartimos un traducción de la EEA DeFi Risk Assessment Guidelines - Version 1 - EEA Technical Specification, 17 July 2024
1. Introducción
1.1 Resumen Ejecutivo
1.1.1 Propósito
Este documento se basa en la experiencia en diversas áreas de DeFi y contabilidad y busca proporcionar una guía amplia y respaldada por la industria sobre los riesgos involucrados en trabajar con DeFi, y cómo evaluarlos, gestionarlos, contabilizarlos y mitigarlos.
La necesidad de estas Guías se evidencia por la ambigüedad regulatoria y la falta general de normas y directrices contables para DeFi.
Este documento es producido y mantenido por el Grupo de Trabajo DRAMA de Ethereum Enterprise Alliance Inc.
Esta es la Versión 1 de esta Guía. Agradecemos sus comentarios para ayudarnos a mejorarla y para ayudar al Grupo de Trabajo a comprender cómo ha sido útil (o no) en casos específicos.
1.1.2 Público Objetivo
Si bien está escrito principalmente para usuarios de protocolos DeFi e inversores en protocolos, este documento también es relevante para operadores de protocolos y desarrolladores de protocolos que buscan minimizar los riesgos en su protocolo. Finalmente, esperamos que este trabajo sea util para reguladores y Organizaciones de Desarrollo de Estándares que crean estándares y regulaciones que afectan a DeFi.
1.1.2.1 Partes Interesadas del Ecosistema
Los usuarios de protocolos son personas u organizaciones que utilizan un protocolo DeFi como "clientes", ya sea mediante el intercambio de tokens, el staking, la inversión o el suministro de liquidez. El término también cubre a sus agentes que actúan en su nombre, incluidos contadores, asesores legales, etc.
Los inversores en protocolos son aquellos que participan en el gobierno de un protocolo. Pueden aspirar a desempeñar un papel en la gestión de su funcionamiento o comportarse como un inversor pasivo con la esperanza de que el valor de su participación aumente.
Los operadores de protocolos son aquellos que pueden tomar decisiones con respecto al funcionamiento de un protocolo. Esto puede incluir inversores en protocolos, desarrolladores de protocolos y cualquier otra persona que tenga la capacidad de tomar decisiones sobre cómo funciona el protocolo. Un subconjunto importante de operadores de protocolos son los operadores de contratos inteligentes: personas que tienen acceso privilegiado para administrar contratos inteligentes utilizados por el protocolo.
Los desarrolladores de protocolos contribuyen activamente al código de un protocolo.
1.2 Estructura de este documento
El contenido principal de este documento está (actualmente) estructurado en varias secciones:
3. Riesgos para los activos DeFi: Una descripción de los diferentes tipos de riesgo que pueden estar presentes en DeFi. Estos están vinculados a las mejores prácticas relevantes para la Evaluación y Mitigación según corresponda.
4. Información Clave para la Evaluación de Riesgos: Información Clave para la Evaluación de diversos riesgos, organizada por tipo y tema de la información.
5. Estrategias de Mitigación de Riesgos: Estrategias de Mitigación para diversos riesgos.
Las definiciones están en Negrita Mayúscula, generalmente la primera vez que se usa un término en el contenido principal. Otros usos del término definido se vinculan a la definición en cualquier lugar del texto.
Los apéndices incluyen resúmenes de Riesgos, Información Clave y recomendaciones de Mitigación, términos definidos en el documento, explicaciones de algunos conceptos fundamentales de DeFi e información administrativa sobre el estado del documento.
EJEMPLO 1: Un ejemplo
A veces se proporcionan ejemplos, con el formato que se muestra aquí.
Tienen fines ilustrativos o explicativos.
2. Métricas Clave de DeFi
Algunas métricas se usan comúnmente para describir aspectos de los protocolos DeFi que son relevantes para evaluar su valor. Si bien algunas de estas son más conocidas en general, otras son específicas de DeFi o se miden de formas específicas de DeFi. Los términos se enumeran alfabéticamente.
Valor Contable: Un término contable conocido que se refiere al valor registrado actualmente de un activo.
Capitalización de Mercado Circulante: El precio del token multiplicado por el Suministro Circulante.
Suministro Circulante: Mide la cantidad de tokens que están disponibles en el mercado, excluyendo los tokens que se sabe que se han quemado, se mantienen en custodia o que de otro modo claramente no están disponibles para la negociación.
Valor Justo de Mercado (Fair Market Value - FMV): Este es un término contable conocido, que significa el monto que se obtendría si un activo se liquidara en el mercado actual.
Capitalización de Mercado Totalmente Diluida: El precio del token multiplicado por el Suministro Total.
Uso de Gas: Cuánto gas, o tarifas de transacción, ha pagado el Contrato Inteligente de un protocolo durante un período fijo de tiempo, generalmente 24 horas.
Pérdida Impermanente: El costo de oportunidad de proporcionar liquidez, por ejemplo a un DEX, en comparación con mantener los activos en una billetera. La Pérdida por Divergencia es la medición de la pérdida impermanente, donde el punto de referencia es mantener los activos en una billetera; Pérdida vs Rebalanceo (o LVR) mide el déficit relativo a una estrategia de rebalanceo dinámico.
Relación Préstamo-Valor (Loan to Value - LTV): Cuanta garantía se requiere para un préstamo de un tamaño determinado, que se usa típicamente para activar la liquidación del préstamo. Esto también se conoce como LTR.
Oferta Máxima Posible: En algunos casos, existe un límite matemático para la cantidad de tokens que se pueden crear; esto es más conocido por ser el caso de Bitcoin. La Oferta Máxima Posible se refiere a este límite, donde exista.
MCAP/Tarifas: El resultado de dividir la Capitalización de Mercado entre las Tarifas pagadas durante un período de tiempo determinado. Esto se puede comparar a los Múltiplos de Ingresos en las finanzas tradicionales, que de manera similar comparan la valoración de una empresa con sus ingresos.
MCAP/TVL: La capitalización de mercado de un token, dividida por su Valor Total Bloqueado.
Tarifas del Protocolo: Una medida de los ingresos de un protocolo en forma de tarifas de uso cobradas durante un período fijo, generalmente 24 horas o 7 días.
Suministro Total: Este es el número total de tokens creados, menos los que se sabe que han sido destruidos.
Valor Total Bloqueado: Representa el valor de todos los activos mantenidos dentro de un protocolo DeFi. Tenga en cuenta que los activos no están necesariamente "bloqueados" de ninguna manera.
Valor de Tesorería: El valor de los tokens mantenidos en la tesorería de un equipo de protocolo, generalmente medido en términos de una moneda fiduciaria como dólares o euros.
A veces, los protocolos se evalúan en función de cuántas direcciones distintas han interactuado con un protocolo, ya sea durante un período fijo o durante toda la vida útil de un protocolo. Sin embargo, es trivial crear nuevas direcciones de billetera e interactuar con un protocolo, y algunos expertos han recomendado que los usuarios hagan esto para cada nueva transacción, para preservar el anonimato. Por lo tanto, puede ser muy difícil evaluar con precisión la cantidad de personas separadas que interactúan con un protocolo DeFi. Las direcciones únicas no son equivalentes a usuarios únicos, ni siquiera una buena medida aproximada. A menos que un protocolo implemente KYC, generalmente no es posible determinar el número de usuarios únicos.
3 Riesgos para los activos DeFi
3.1 Riesgos de Software
DeFi funciona con componentes de software. Los Riesgos de Software surgen cada vez que hay problemas que afectan el funcionamiento correcto o esperado del software, ya sea porque problemas o fallas en el diseño y la implementación producen resultados inesperados, o porque terceros maliciosos encuentran y explotan vulnerabilidades en el software.
Organizaciones como MITRE proporcionan documentación extensa sobre las debilidades de seguridad comunes [CWE] y las vulnerabilidades de software conocidas [CVE]. También hay documentación para tipos específicos de software, como la Especificación de Niveles de Seguridad EEA EthTrust [EthTrust] que cubre el código de Contrato Inteligente, y las Directrices de Seguridad Crosschain de EEA [xchain-sec] que cubren el software utilizado en puentes. Los procesos de desarrollo de software de calidad trabajarán para evitar tales vulnerabilidades.
A menudo hay muchos usuarios de una pieza de Software. El Software en sí, pero también sus usuarios, son ambos objetivos potenciales de ataque.
Falta de Estandarización: La falta de estandarización en formatos de datos, protocolos y API en DeFi plantea desafíos de interoperabilidad para el software DeFi. La integración y normalización de software o datos de diversos proveedores o fuentes puede ser compleja y propensa a errores.
Latencia: Cualquier software distribuido a través de una red tiene que lidiar con la Latencia, el tiempo que puede transcurrir mientras el sistema se sincroniza en la red. En un contexto DeFi, esto introduce el riesgo de actuar con información desactualizada o de que las acciones planificadas no se ejecuten de manera suficientemente oportuna.
En DeFi, cada tipo de componente de software puede implicar algunos riesgos específicos debido a su función en DeFi o a la naturaleza del software mismo:
Contratos inteligentes: Los Contratos inteligentes son el software "back-end" central que implementa la funcionalidad de un sistema DeFi. Los errores en el diseño, la implementación o el mantenimiento de los Contratos inteligentes pueden significar que el sistema no se comporte como se espera o se pretende.
Blockchains: Existen varias plataformas Blockchain en las que se pueden ejecutar Contratos inteligentes. Existen algunos riesgos que son relevantes para las blockchains en general, y en ocasiones existen riesgos específicos debido a las propiedades específicas de una determinada blockchain.
Interfaces de usuario: Los "front end" o interfaces de usuario del sistema DeFi suelen ser aplicaciones web. Las interfaces de usuario son un campo de riesgo bien conocido.
Oráculos y Puentes: Los Oráculos y Puentes, componentes comunes en los protocolos DeFi, son susceptibles no solo al Riesgo de Software sino también a otros riesgos.
Riesgo de Oráculos
Muchos Contratos inteligentes se basan en Oráculos: fuentes automatizadas de información que provienen de fuera de la blockchain donde se implementan. Sus fuentes de información y la forma en que se utilizan pueden introducir tipos adicionales de riesgo.
Riesgo de Puente
Los puentes permiten la operación entre dos o más blockchains. Además de los Riesgos de Software, están sujetos al Riesgo de Mercado que impacta la relación entre dos blockchains. Pueden contener o transferir un valor muy significativo, lo que los convierte en objetivos atractivos para los ataques de piratas informáticos.
3.1.1 Mejores prácticas para gestionar los riesgos del software
Esta sección se aplica a los riesgos del software en general. Las siguientes subsecciones brindan más información sobre las mejores prácticas específicas para varios tipos específicos de software importantes en DeFi.
Evaluación del riesgo del software:
Resultados de las pruebas de estrés
Incidentes de seguridad e informes de respuesta
Actualizaciones de seguridad del software
Estrategias de mitigación relevantes:
Canales de feedback de usuarios
Educación del usuario
Usar canales seguros
Cifrar el almacenamiento de datos
No almacenar datos privados en ubicaciones de acceso global
Revisar la seguridad de todos los componentes
Todas las actualizaciones de software
Tener programas de recompensas por errores
Establecer procedimientos de divulgación responsable
Tener respuesta de seguridad 24/7
Alinearse con los estándares de la industria
3.1.2 Riesgo de Contratos Inteligentes
Las vulnerabilidades en los Contratos Inteligentes pueden permitir que un atacante malicioso destruya o robe parte del valor administrado por el contrato, o permitir una situación en la que esto suceda como consecuencia accidental de una secuencia de acciones imprevista.
Diferentes blockchains ofrecen distintas posibilidades para crear y usar Contratos Inteligentes. Como software que forma parte fundamental del funcionamiento de los sistemas DeFi, los Contratos Inteligentes enfrentan los mismos Riesgos de Software que cualquier software conectado a Internet. Algunos riesgos se ven exacerbados por la naturaleza específica de los Contratos Inteligentes.
EJEMPLO 2
En 2016, un fondo de inversión basado en Contratos Inteligentes llamado The DAO fue hackeado, lo que resultó en el robo de aproximadamente $50 millones de dólares en Ether. El pirateo fue posible gracias a una falla en el código de la DAO, que permitió al atacante drenar fondos de la cuenta del fondo.
En cadenas basadas en EVM como Ethereum, el lenguaje más común para escribir Contratos Inteligentes es Solidity. Sin embargo, es posible utilizar otros lenguajes o incluso generar directamente bytecode para su procesamiento.
EJEMPLO 3
En julio de 2023, una debilidad de reentrada en ciertas versiones del compilador para Vyper (el segundo lenguaje más común utilizado para escribir Contratos Inteligentes para EVM, con aproximadamente un 15%), permitió ataques a varios pools de liquidez. Actores maliciosos robaron aproximadamente USD 50 millones, mientras que los intentos de tomar otros 20 millones fueron detenidos o revertidos por hackers de sombrero blanco.
El código del Contrato Inteligente es visible públicamente cuando el contrato se implementa en la blockchain. Esto permite a los piratas informáticos buscar errores o errores de configuración que puedan aprovechar para atacar el sistema DeFi y robar o destruir valor.
El código del Contrato Inteligente implementado apresuradamente con una revisión inadecuada o tiempo insuficiente dedicado a corregir los problemas descubiertos en una revisión de seguridad y nuevas pruebas, puede conducir a la explotación de Contratos Inteligentes Vulnerables.
En la mayoría de las Blockchains, cualquier persona puede leer las transacciones, por lo general es muy obvio cuando un Contrato Inteligente utilizado en DeFi está administrando una gran cantidad de valor. Esto facilita el cálculo de los posibles retornos de un ataque exitoso, atrayendo a más atacantes a objetivos de alto valor.
Los Contratos Inteligentes a menudo son inmutables cuando se implementan, por lo que las técnicas de seguridad convencionales basadas en la actualización de programas vulnerables no siempre están disponibles.
Los Contratos Inteligentes Actualizables introducen riesgos y complicaciones de seguridad adicionales.
La magnitud del riesgo se ve agravada por la velocidad a la que generalmente se pueden mover fondos en DeFi, la dificultad de revertir transacciones, la automatización de procesos y el pseudoanonimato de la blockchain.
Cualquier usuario puede interactuar directamente en la blockchain con un Contrato Inteligente. La documentación inexacta o insuficiente de los Contratos Inteligentes introduce el riesgo de que los usuarios que interactúan directamente lo hagan de una manera que provoque errores.
3.1.2.1 Mejores prácticas para gestionar los riesgos de los Contratos Inteligentes
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de Contratos Inteligentes:
Evaluación de Riesgos
Certificación EthTrust de Contratos Inteligentes [EthTrust]
Mecanismos de Gobernanza Sin Voto
Estrategias de Mitigación Relevantes:
Realizar una revisión de seguridad del Contrato Inteligente antes de implementar el código
Implementar las recomendaciones de la revisión de seguridad antes de la implementación
Tener Contratos Inteligentes con Certificación EthTrust [EthTrust]
3.1.3 Riesgo de Blockchain
El Riesgo de Blockchain es el riesgo de que la blockchain base no funcione correctamente durante las transacciones DeFi. Esto no incluye el Riesgo de Puente (transferir valor entre blockchains), que es un riesgo separado descrito en la sección 3.1.6 Riesgo de Puente.
En general, las blockchains funcionan según lo diseñado, y el Riesgo de Blockchain en el período 2019-2023 ha sido muy pequeño. La mayoría de las blockchains son confiables tanto en la ejecución como en el tiempo de actividad, y el registro de transacciones normalmente ha sido perfecto en las blockchains. De todos los riesgos dentro del ecosistema DeFi, el Riesgo de Blockchain se encuentra generalmente entre los más pequeños.
Hay cuatro formas clave en las que una blockchain puede comprometer la funcionalidad de un protocolo DeFi implementado en esa blockchain.
La blockchain deja de funcionar. Las blockchains por diseño se espera que ofrezcan un servicio "24/7/365". Este riesgo es real, pero generalmente pequeño en la práctica.
EJEMPLO 4: Paradas y ralentizaciones de la blockchain
Se han producido paradas reales en la red Solana y la Binance Smart Chain se cerró después de un hackeo.
En 2022, la blockchain Ethereum Classic se detuvo brevemente como resultado de un "ataque del 51%".
La blockchain Ethereum, cuando se usa mucho, nunca se detiene, pero puede volverse lenta y costosa de usar.
Una blockchain pierde registros de transacciones.
Fundamental para todo DeFi es la expectativa de que la blockchain conserve los registros de todas las transacciones. Estas transacciones prueban su propiedad de un artículo y que ocurrió una transacción. Los exploradores de blockchain generalmente proporcionan la información relevante a los usuarios finales. Solo en la blockchain Solana este riesgo ha sido evidente, donde a veces no se pueden encontrar nuevos registros de transacciones rápidamente, lo que lleva a un riesgo de alta latencia.
La blockchain no ejecuta el código de un contrato correctamente, lo que resulta en saldos incorrectos.
Esto sería catastrófico para la confianza en DeFi en esa blockchain. Sin embargo, no hay registros de que este riesgo se haya materializado.
Cuando una blockchain puede ser controlada por un actor malicioso o un grupo de actores, los activos digitales podrían ser robados o destruidos por la "fuerza bruta", como un ataque del 51%.
Si bien tales ataques se han producido en la práctica, por ejemplo, en la blockchain Ethereum Classic, la comunidad de usuarios de esa blockchain logró revertir los efectos del ataque.
3.1.3.1 Mejores prácticas para gestionar los riesgos de Blockchain
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de Blockchain:
Evaluación de Riesgos
Historial de la Blockchain Subyacente
Mecanismos de Gobernanza para la Blockchain
Estrategias de Mitigación Relevantes
Evaluar la seguridad de la Blockchain
3.1.4 Riesgos de la interfaz de usuario
Los proyectos DeFi a menudo ofrecen sistemas basados en la web para que los usuarios interactúen con ellos. Algunos proyectos también ofrecen aplicaciones específicas, o en su lugar. Todos estos están sujetos a riesgos conocidos, incluida la inyección de JavaScript, la suplantación de DNS y otros.
Un riesgo clave de todo el software orientado al usuario es que el diseño de la interfaz o la experiencia del usuario sea confusa, lo que lleve a los usuarios a realizar acciones que tengan consecuencias que no esperaban. Este riesgo puede amplificarse para los usuarios que confían en herramientas menos comunes para acceder a la interfaz, incluidos los usuarios con discapacidades que dependen de la tecnología de asistencia.
Tenga en cuenta que en muchas jurisdicciones, las interfaces que no son útiles para usuarios con discapacidad también son un Riesgo de Cumplimiento, como se describe en la sección 3.3 Riesgo de Cumplimiento y Legal.
3.1.4.1 Mejores prácticas para gestionar los riesgos de la interfaz de usuario
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de la Interfaz de Usuario:
Evaluación de Riesgos:
Evaluación de usabilidad y accesibilidad
Estrategias de Mitigación Relevantes:
Revisión de UX y Accesibilidad
Prueba previa de interfaces en Sandbox
Probar la seguridad del software y la API contra los estándares OWASP
Implementar las Guías de Accesibilidad para el Contenido Web del W3C (para aplicaciones web)
3.1.5 Riesgo de Oráculo
Los oráculos DeFi juegan un papel crucial en los ecosistemas financieros descentralizados al proporcionar datos e información externos a los Contratos Inteligentes, que de otra manera no tendrían acceso a la información fuera de la blockchain en la que están implementados. Sin embargo, también introducen riesgos únicos que deben considerarse cuidadosamente.
La velocidad a la que los oráculos DeFi proporcionan datos es fundamental para las transacciones urgentes y las fuentes de precios. Los retrasos o la alta latencia en la obtención y entrega de datos pueden afectar la precisión y la puntualidad de la ejecución del Contrato Inteligente. Esto puede generar pérdidas financieras u oportunidades de arbitraje para actores maliciosos.
Precisión y manipulación de datos: Los oráculos DeFi dependen de fuentes de datos externas a la blockchain para proporcionar información a los Contratos Inteligentes que pueden actuar automáticamente sobre la información. Los datos inexactos pueden llevar a que los Contratos Inteligentes produzcan resultados inesperados o no deseados.
Las fuentes de datos externas, como las API o los sitios web, de las que dependen los oráculos para obtener datos, son potencialmente vulnerables a brechas de seguridad, piratería o manipulación de datos. Si un atacante obtiene control sobre una fuente de datos, puede manipular los datos introducidos en los protocolos DeFi. Esto puede conducir a resultados inesperados y posibles pérdidas financieras, por ejemplo, activando liquidaciones maliciosamente.
Punto único de Falla: Los oráculos DeFi que dependen de muy pocas fuentes de datos o fuentes inseguras introducen el riesgo de que la manipulación o el mal funcionamiento de ese oráculo pueda tener efectos adversos significativos.
Gobernanza y Actualización: Los mecanismos de gobernanza de los protocolos de oráculos DeFi juegan un papel vital en la determinación de cómo se seleccionan, administran y actualizan las fuentes de datos. Una gobernanza inadecuada puede conducir a fuentes de datos sesgadas o comprometidas, lo que afecta la confiabilidad e integridad del protocolo que depende de dichos oráculos.
3.1.5.1 Mejores prácticas para gestionar los riesgos de los oráculos
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de los Oráculos:
Evaluación de Riesgos
Entrega y latencia de datos del oráculo
Tendencias de centralización de las redes de oráculos
Estrategias de Mitigación Relevantes:
Usar canales seguros
Múltiples oráculos o fuentes de datos múltiples
Usar TWAP (Time-weighted Average Pricing)
Actualizar o dejar de usar oráculos que funcionan mal
3.1.6 Riesgo de Puentes
Los puentes permiten la transferencia de tokens entre diferentes blockchains. Los puentes generalmente vienen en dos formas: puentes confiables (o centralizados) y puentes sin confianza (o descentralizados). Todos los puentes conllevan Riesgo de Software. Con puentes sin confianza, también existe un potencial riesgo de Gobernanza (3.2).
Los puentes confiables dependen de una entidad o sistema central para operar. El puente wBTC, por ejemplo, permite a los usuarios usar su Bitcoin para financiar operaciones en la blockchain Ethereum. Debido a que la blockchain de Bitcoin no tiene funcionalidad de contrato inteligente, una entidad externa toma la custodia de los depósitos de Bitcoin y acuña una cantidad equivalente de wBTC (un token encapsulado que representa Bitcoin) en Ethereum.
Los riesgos clave con un puente confiable son el Riesgo de Contraparte (3.6) : los usuarios confían en que los operadores del puente siempre procesarán sus transacciones (ver también Censura y MEV) y que no robarán ni perderán los fondos que controlan ( 3.2.2 Riesgo de Custodia).
Los puentes sin confianza operan usando contratos inteligentes, que se monitorean a través de software como Oráculos. Los usuarios comprometen fondos con un contrato inteligente en una cadena, lo cual es detectado por un Oráculo en la cadena de destino que acuña la cantidad equivalente allí.
Por lo general, los fondos comprometidos en la cadena de origen se mantienen allí en depósito, como garantía para los tokens en la cadena de destino. Se pueden utilizar para proporcionar liquidez para una transferencia de tokens de regreso desde la cadena de destino.
Una gran cantidad de fondos puede actuar como un honeypot, atrayendo ataques que intentan robar los fondos.
EJEMPLO 5
En un gran ataque a un puente, el ataque a Ronin Bridge, se estima que se robaron $624 millones del contrato del puente.
Un enfoque alternativo para la implementación de puentes quema los fondos en la blockchain de origen, confiando en el suficiente interés del mercado para proporcionar liquidez para una transferencia de regreso a esa blockchain. Esto aumenta el Riesgo de Liquidez para los usuarios que dependen de poder moverse entre blockchains.
3.1.6.1 Mejores prácticas para gestionar los riesgos de puentes
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de Puentes:
Evaluación de Riesgos:
Proveedores clave de servicios
Estructuras de Gobernanza
Monitoreo de puentes
Estrategias de Mitigación Relevantes:
Usar canales seguros
Seguir las Pautas de Seguridad Crosschain de EEA
Monitorear a usuarios potenciales que acumulan participaciones
Ver también https://ethereum.org/en/bridges/
3.1.7 Riesgo de MEV
El término MEV es común en el espacio blockchain. Cuando las transacciones propuestas están disponibles públicamente, por ejemplo, en el mempool de Ethereum, hay muchas formas en que los participantes en la red pueden interactuar con ellas. Algunos de estos son positivos, como permitir mercados de precios más claros para las transacciones.
Pero, entendido como Valor Extraído Maliciosamente (Maliciously Extracted Value), MEV se refiere al potencial para manipular transacciones, por ejemplo, bloqueando o retrasando ciertas transacciones (conocido como Censura), y utilizando la información contenida en esas transacciones Censuradas para obtener ganancias no deseadas a expensas del proponente de la transacción.
Las estimaciones del valor que se ha robado de esta manera van desde cientos de millones hasta miles de millones (medidos en USD).
NOTA
Inicialmente, esto lo hacían quienes determinaban qué transacciones se colocaban en un bloque (los Mineros en la cadena Bitcoin o la cadena Ethereum Proof of Work original ("pre-fusión")), por lo que el término originalmente era un acrónimo de "Miner Extracted Value" (Valor Extraído por Mineros).
Las formas comunes de ataque incluyen:
Front-Running
Donde un procesador de transacciones inserta su propia transacción antes de una que ha sido enviada, por ejemplo, para aprovechar una oferta, registrar una información importante o manipular el precio de un activo que se negocia a través de la transacción enviada.
Back-Running
Donde un procesador de transacciones agrega una transacción en un bloque directamente después de una que incorpora, por ejemplo, para capturar una oportunidad de arbitraje.
Ataques Sandwich
Donde un procesador de transacciones intercala ("sandwiches") una transacción entre dos de las suyas, por ejemplo, comprando una gran cantidad de un token que la transacción intercalada está comprando, suficiente para aumentar el precio de ese token, y vendiéndolo inmediatamente después de la transacción que se envió al precio más alto.
El riesgo creado por MEV es que un actor malicioso distorsione los precios en el protocolo para extraer valor de forma maliciosa.
Esto puede reducir la confianza en el funcionamiento justo del protocolo DeFi en cuestión, introduciendo el Riesgo de Mercado (3.7).
3.1.7.1 Mejores prácticas para gestionar los riesgos de MEV
Además de las mejores prácticas aplicables a todos los Riesgos de Software, las siguientes mejores prácticas son relevantes para evaluar y mitigar los Riesgos de MEV:
Evaluación de Riesgos
Medidas para mitigar el riesgo de MEV
Estrategias de Mitigación Relevantes:
Usar canales seguros
Usar Precio Promedio Ponderado por Tiempo
Usar Ordenamiento Claro de Transacciones
Establecer Límites de Slippage
3.2 Riesgo de Gobernanza
La gobernanza de un protocolo DeFi tiene dos partes.
Los Operadores del Protocolo actúan como un "equipo de gestión" e implementan decisiones sobre las operaciones del protocolo. Su nivel de control varía ampliamente dependiendo de cómo se implementó técnicamente el protocolo, así como de su modelo de gobernanza. Puede haber diferentes grupos de Operadores del Protocolo con diferentes poderes.
Para un Protocolo inmutable, los Operadores del Protocolo generalmente controlan el sitio web (utilizado por usuarios minoristas) y cobran tarifas de transacción, pero prácticamente no tienen control sobre los Contratos Inteligentes (o los fondos de los usuarios) porque los contratos no se pueden cambiar.
Para un protocolo actualizable, el Operador del Protocolo también podría ser capaz de pausar el protocolo, cambiar el software, retirar fondos, acuñar nuevos tokens, establecer nuevos parámetros operativos como tarifas, o iniciar pasos de emergencia.
También puede haber gobernanza automatizada, donde una votación, típicamente de aquellos que tienen tokens de gobernanza, votando en proporción a sus participaciones, es ejecutada automáticamente por un Contrato Inteligente.
El Riesgo de Gobernanza varía con el diseño de cada protocolo. Hay varios vectores de ataque comunes:
Si un pequeño número de actores tiene un control significativo sobre las votaciones de gobernanza, existe el riesgo de que ejecuten un Rug Pull, robando los fondos de los usuarios, incluyendo el tesoro del protocolo.
En casos menos graves de concentración de tokens, aquellos con una participación de control en la gobernanza pueden introducir cambios en el protocolo que perjudiquen a un grupo particular de titulares de tokens.
Por ejemplo, una gobernanza que requiere atención constante puede penalizar efectivamente a los inversores al trasladar repetidamente el valor mantenido en el protocolo a aquellos que tienen tiempo para mantener un cierto nivel de actividad.
Los Ataques a la tesoría son cuando un atacante intenta controlar las claves de la tesorería.
Este tipo de ataque generalmente no toma los fondos de los usuarios en el protocolo. El impacto directo suele ser una caída en el precio del token de gobernanza, sin embargo, esto puede aumentar significativamente el riesgo de, y puede ser un precursor de, otros ataques de gobernanza.
EJEMPLO 6
En abril de 2022, Beanstalk Farms, un protocolo de stablecoin basado en Ethereum, fue explotado por $182 millones. El atacante tomó un préstamo flash en la plataforma de préstamos Aave, que se utilizó para acumular una gran cantidad del token de gobernanza nativo de Beanstalk, STALK. Con el poder de votación otorgado por estos tokens STALK, el atacante pudo aprobar rápidamente una propuesta de gobernanza maliciosa que drenó todos los fondos del protocolo a una billetera privada de Ethereum.
La gobernanza también está sujeta a Riesgos de Custodia, por ejemplo, una clave crítica única que se pierde, lo que hace que el Protocolo sea inoperable, o múltiples claves que son robadas en ataques de phishing u otros ataques externos.
Si la gobernanza depende excesivamente de una sola cuenta, por ejemplo, porque tiene un papel clave como Operador del Protocolo, y la clave de esa cuenta se ve comprometida (por ejemplo, robada por hackeo u otros medios), un atacante puede controlar el protocolo.
Un atacante puede comprometer la computadora o el teléfono inteligente del propietario de la cuenta mediante phishing, y luego robar la clave del propietario.
EJEMPLO 7: Ataque de phishing contra un protocolo automatizado
El protocolo DeFi bZx perdió alrededor de USD $55 millones cuando una clave privada que controlaba los Contratos Inteligentes fue robada a través de un ataque de phishing.
Un riesgo similar puede surgir cuando los procesos de gobernanza requieren un conjunto complejo de aprobaciones, que hay incentivos insuficientes para participar en las decisiones de gobernanza, paralizando efectivamente la gobernanza porque se vuelve prácticamente imposible ejecutar incluso cambios necesarios en el protocolo.
3.2.1 Mejores prácticas para gestionar los Riesgos de Gobernanza
Evaluación de Riesgos
Proveedores de Servicios Clave
Incentivos en el Diseño de Tokenomics
Distribución de Tokens de Gobernanza
Actualizaciones de Tokenomics
Estructura de Gobernanza
Mecanismos de Gobernanza sin Votación
Medidas para proteger el Tesoro
Frecuencia de informes
Estrategias de Mitigación Relevantes:
Publicar políticas para bloquear, quemar y emitir tokens
Respuesta a incidentes disponible "24/7"
Desarrollar modelos de amenazas
Utilizar monitoreo en tiempo real automatizado
Usar aprendizaje automático e informes de incidentes
Utilizar canales seguros
Pruebas de estrés regulares
Descentralizar las Tenencias de Tokens de Gobernanza
Usar Multisig para la Toma de Decisiones
Equilibrar el Quórum de Votación contra el Suministro de Tokens de Gobernanza
Realizar la debida diligencia en los Operadores de Contratos Inteligentes
Evaluar si las personas que implementan y realizan los controles tienen las habilidades adecuadas
Controles internos para la contabilidad
Monitorear a posibles usuarios que acumulen participaciones
Evaluar decisiones judiciales, leyes y regulaciones potencialmente relevantes
Implementar procedimientos KYC/AML
Monitorear el desarrollo de los Protocolos
3.2.2 Riesgo de Custodia
Gestionar las Claves Privadas y acceder a las Carteras puede ser un proceso complejo. El Riesgo de Custodia surge porque los errores o comportamientos malintencionados pueden resultar en pérdida o robo si se pierde o se roba el acceso a una Clave Privada.
La mala gestión de las Claves Privadas por parte de todos los usuarios es un riesgo.
Ese riesgo puede verse agravado por el riesgo de contraparte (3.6) de un custodio irresponsable o malintencionado.
Usando la tecnología blockchain, hay 2 opciones generales para cómo mantener y acceder a tus activos digitales:
autocustodia, y
custodia por terceros.
La decisión de seleccionar la autocustodia o la custodia por terceros depende de múltiples factores, como el costo y la eficiencia para transaccionar, la capacidad para proteger los fondos de la pérdida o el robo, y potencialmente la regulación, como los requisitos de la SEC para que los asesores utilicen Custodios Calificados.
La autocustodia en el contexto de los activos digitales significa que tú controlas tus Claves Privadas, utilizadas para acceder y transferir tus activos en la blockchain.
EJEMPLO 8: Fallos en la Autocustodia
James Howells, un ingeniero de software, accidentalmente tiró el disco duro equivocado en 2013, perdiendo las claves privadas que controlaban cuentas de Bitcoin que supuestamente contenían varios miles de BTC. Pasó muchos años tratando de obtener permiso para excavar el vertedero donde cree que se llevó el disco duro, incluyendo ofrecer £50M a la autoridad que operaba la instalación si podían ayudarle a recuperar las claves.
La Custodia por Terceros en el contexto de DeFi se refiere a la práctica de confiar la custodia de una Clave Privada, y por lo tanto la capacidad de controlar los activos, a un tercero responsable de su seguridad y protección.
Los proveedores de Custodia por Terceros a menudo se denominan Custodios, y pueden ofrecer una variedad de servicios diseñados para asegurar los activos de los usuarios, como almacenar las claves privadas en almacenamiento en frío, proporcionar Carteras Multisig, e implementar varias medidas de seguridad para prevenir hackeos y robos.
El uso de la custodia por terceros en DeFi permite a los usuarios confiar en la experiencia y conocimientos de custodios profesionales para salvaguardar sus activos. Sin embargo, también implica confiar el control de los activos a otra entidad, lo que puede introducir el riesgo de contraparte y limitar la descentralización que es una característica clave de DeFi.
Pocos Custodios institucionales actualmente ofrecen "DeFi como servicio" a gran escala.
Ha habido varios fracasos de alto perfil de la Custodia por Terceros en el espacio de activos digitales.
EJEMPLO 9
Mt. Gox era un intercambio de Bitcoin que en un momento manejó más del 70% de todas las transacciones de Bitcoin. En 2014, el intercambio se declaró en bancarrota después de que se revelara que había perdido 850,000 Bitcoins, con un valor aproximado de $450 millones en ese momento, debido a un hackeo que explotó una debilidad en el sistema de seguridad del intercambio.
EJEMPLO 10
QuadrigaCX era un intercambio de criptomonedas canadiense que se declaró en bancarrota en 2019 después de la supuesta muerte de su CEO, Gerald Cotten. Se creía que Cotten tenía el control de las claves privadas del intercambio. Después de su desaparición, nadie se presentó reclamando tener control de las claves privadas. Como resultado, aproximadamente USD $190 millones en fondos de los clientes se cree que son inaccesibles.
3.2.2.1 Mejores prácticas para gestionar los Riesgos de Custodia
Evaluación de Riesgos:
Documentar los procedimientos de gestión de Claves
Implementar procedimientos CCSS para la gestión de Claves
Informes de tipo 2 de [SOC2] de los Custodios
Estrategias de Mitigación Relevantes:
Documentar los procedimientos de gestión de Claves
Implementar procedimientos CCSS para la gestión de Claves
3.2.3 Riesgo de Tokenomics
Tokenomics se refiere a los incentivos económicos proporcionados por un protocolo DeFi, DAO u otro sistema blockchain, a través de su distribución de tokens y otros incentivos. El riesgo de Tokenomics puede surgir de varios defectos en el diseño económico de un Protocolo, incluyendo la distribución de la oferta de tokens, los períodos de bloqueo, el grado de descentralización, las estructuras de incentivos y más.
Problemas de Tokens que resultan en distorsiones de la oferta pueden reducir la oferta circulante, impactar la liquidez o diluir el valor de los tokens, limitando potencialmente la participación en el mercado.
Algunos posibles ejemplos son cuando los inversores reciben e intentan vender un gran porcentaje de la oferta total, o una proporción muy alta de tokens están bloqueados o en staking. De manera similar, recompensar a los usuarios con nuevos tokens puede aumentar la oferta circulante, reduciendo potencialmente el valor de los tokens a través de la inflación.
Cabe destacar que, por ejemplo, en el período previo y durante algún tiempo después del "Merge" de Ethereum, todo el ETH en staking estaba efectivamente bloqueado, sin ningún efecto negativo aparente; el riesgo debe considerarse en función de la situación específica.
Los tokens con una utilidad limitada más allá de la especulación pueden enfrentar una demanda inestable y una mayor probabilidad de ser considerados un valor, con el consiguiente 3.3 Riesgo de Cumplimiento y Legal.
La incapacidad de ajustar la tokenomics a las condiciones cambiantes del mercado y las necesidades de los usuarios puede resultar en un rendimiento subóptimo.
3.2.3.1 Mejores prácticas para gestionar los Riesgos de Tokenomics
Evaluación de Riesgos:
Incentivos en el Diseño de Tokenomics
Distribución de Tokens de Gobernanza
Actualizaciones de Tokenomics
Estructura de Gobernanza
Estrategias de Mitigación Relevantes:
Publicar políticas para bloquear, quemar y emitir tokens
Documentar el proceso de conciliación
Producir información financiera precisa y oportuna
Desarrollar modelos de amenazas
Pruebas de estrés regulares
Equilibrar el quórum de votación contra el suministro de tokens de gobernanza
Controles internos para la contabilidad
Monitorear a posibles usuarios que acumulen participaciones
Monitorear el desarrollo de los Protocolos
3.3 Riesgo de Cumplimiento y Legal
Los riesgos inherentes a DeFi se agravan por la ausencia general de marcos regulatorios claros. La naturaleza descentralizada de DeFi puede dificultar la regulación de cualquier entidad individual y también dificulta identificar a las partes responsables o aplicar acciones regulatorias.
La ausencia de requisitos de divulgación obligatorios o estándar en las aplicaciones DeFi exacerba estos riesgos. Una mayor claridad regulatoria, adaptada para abordar la estructura de DeFi, podría eventualmente abordar algunos de estos riesgos.
Los riesgos regulatorios, legales y de cumplimiento se manifiestan para los usuarios y posibles usuarios de DeFi de varias maneras:
Los reguladores pueden considerar que es una violación de leyes y regulaciones interactuar con protocolos DeFi como una actividad, o con un protocolo DeFi dado o sus Operadores del Protocolo.
Los tokens considerados como valores, en lugar de utilidades, generalmente están sujetos a marcos regulatorios diferentes y más estrictos.
Las implicaciones fiscales poco claras para DeFi introducen un riesgo de que el tratamiento fiscal se considere una violación de leyes y recomendaciones.
Un Protocolo podría considerarse en violación de la regulación AML.
La gobernanza del Protocolo puede permitir bloquear a los participantes que han sido proscritos. Sin embargo, si las billeteras anónimas pueden interactuar con protocolos DeFi y solo se bloquean "a demanda", la falta de procedimientos KYC ("Conoce a tu Cliente") y AML (Anti-Lavado de Dinero) puede exponer a los participantes de DeFi al riesgo de interactuar con dinero proveniente de actividades ilícitas o participar en comercio con entidades sujetas a regímenes de sanciones locales como OFAC [ofac].
3.3.1 Mejores prácticas para gestionar los Riesgos de Cumplimiento
Evaluación de Riesgos:
Mecanismos y Medidas de cumplimiento regulatorio tomadas
Cambios relevantes en la regulación
Participación en organismos de establecimiento de estándares
Operaciones relevantes a los Impuestos
Estrategias de Mitigación Relevantes:
Monitorear el panorama legal y regulatorio, especialmente los requisitos fiscales
Participar en Grupos de la Industria
Implementar KYC, incluyendo para los Operadores del Protocolo
3.3.2 Riesgo Fiscal
En 2024, hay una falta de orientación sobre la tributación de activos digitales y aún menos orientación para las transacciones que utilizan protocolos DeFi. Esto requiere que los usuarios analicen cada etapa de la transacción para determinar cuál considerar un evento de reconocimiento (sujeto a impuestos) a efectos fiscales y potencialmente auto-reportar las transacciones fuera de la cadena.
EJEMPLO 11: Problemas fiscales: Préstamos Descentralizados
Una entidad que participa en una transacción con un pool de staking DeFi, un Pool de Liquidez o un AMM deberá considerar si:
ha habido un cambio en el dominio y control sobre los activos proporcionados de tal manera que se considere que ocurrió una venta o intercambio, y
los activos proporcionados se intercambian por nuevos activos que son materialmente diferentes.
Por lo tanto, los préstamos descentralizados podrían no considerarse préstamos a efectos fiscales.
Con la arquitectura variada de DeFi y la común falta de acuerdos legales entre las partes, los usuarios pueden verse relegados a tener que analizar las reglas establecidas en el código del software y los resultados de los litigios penales para determinar el tratamiento fiscal.
También puede haber incertidumbre en torno al carácter y origen del rendimiento, así como el momento en que se reconoce el rendimiento en ingresos.
El momento y la clasificación del reconocimiento de ingresos a efectos fiscales también pueden dictar la cantidad de ingresos a reconocer, dada la naturaleza volátil de las valoraciones de los activos digitales.
3.4 Riesgos de Conformidad con Estándares
Existen múltiples estándares que cubren los protocolos DeFi, desde aquellos mencionados en relación con 3.1 Riesgos del Software hasta estándares contables de amplio alcance como GAAP o IFRS.
En algunos casos, aplicar correctamente estos estándares es un requisito legal que puede impactar el 3.3 Riesgo de Cumplimiento y Legal, pero más a menudo los impactos potenciales están relacionados con la reputación, el costo de recaudar capital u otras áreas similares donde los riesgos son reales pero no conllevan el potencial de sanciones legales formales.
3.4.1 Riesgos de Conformidad Contable
Los elementos únicos de DeFi hacen que sea desafiante aplicar estándares contables como los Principios de Contabilidad Generalmente Aceptados (GAAP), el estándar utilizado en EE.UU. y mantenido por el Financial Accounting Standards Board (FASB), o las Normas Internacionales de Información Financiera (IFRS), mantenidas por el International Accounting Standards Board (IASB), que es el estándar legal en la mayoría de los países (incluida la Unión Europea y Rusia) excepto EE.UU. China también tiene su propio estándar contable.
A partir de septiembre de 2023, el IASB no ha abordado la contabilidad para DeFi, mientras que el FASB solo ha hecho algunas propuestas. Esto introduce el riesgo legal o de cumplimiento de que las prácticas contables más tarde se consideren no haber seguido los estándares aceptables.
En el corazón de la contabilidad está si una transacción con un protocolo DeFi se caracteriza como una transacción con un principal (es decir, de igual a contrato o igual a protocolo) o una transacción a través de un agente (es decir, de igual a igual facilitada por el protocolo).
EJEMPLO 12
Por ejemplo, cuando un usuario institucional contribuye un par de tokens a un DEX y recibe un token LP a cambio, ¿la contabilidad apropiada es:
Dar de baja los tokens contribuidos al contribuir al pool y reconocer el token LP? o
No dar de baja los tokens contribuidos al contribuir al pool, pero contabilizar la participación proporcional del proveedor de liquidez en cada transacción que ocurre en el DEX?
Hay dos elementos particulares a tener en cuenta:
3.4.1.1 Definición de instrumento financiero
Los modelos de baja contable pueden distinguir entre activos que son activos financieros y todos los demás activos. Por ejemplo, bajo las reglas GAAP aplicables en los Estados Unidos, la baja contable de instrumentos financieros requiere que los activos estén legalmente aislados del transferente.
Algunos activos digitales podrían cumplir con esta definición (por ejemplo, ciertas stablecoins emitidas por una parte central con activos fuera de la cadena que respaldan el canje) mientras que otros no.
3.4.1.2 Noción de control
Los modelos contables para dar de baja los activos transferidos se basan en si el control del activo ha sido transferido, o incluyen la transferencia de control como parte de un análisis más amplio de si los riesgos y recompensas han sido transferidos. Dado que muchos protocolos DeFi son "no custodiales", en los que los usuarios pueden solicitar su parte proporcional de activos en los pools del protocolo DeFi, no está claro si dichos protocolos pueden obtener "control" según lo definido en los estándares contables relevantes.
Las empresas de inversión también necesitan determinar cuál es la unidad de cuenta y cuál es su base de costo, ya que presentan ganancias/pérdidas realizadas por separado de las ganancias/pérdidas no realizadas.
3.4.1.3 Mejores prácticas para gestionar los Riesgos de Conformidad Contable
Evaluación de Riesgos:
Cifras Financieras Relevantes
Informes de tipo 2 de [SOC1]
Proveedores de Servicios Clave
Cambios relevantes en la regulación
Participación en organismos de establecimiento de estándares
Estrategias de Mitigación Relevantes:
Explicar clases de activos
Explicar la elección de tratamientos contables
Participar en organismos de establecimiento de estándares y asesoría regulatoria
3.4.2 Riesgos de Contabilidad Operacional
Los Riesgos de Contabilidad Operacional son los riesgos que surgen de inexactitudes en los procedimientos contables:
Pueden surgir desajustes entre las posiciones en la cadena y las posiciones financieras reportadas debido a no contabilizar posiciones abiertas como tokens de pools de liquidez que están en staking en un protocolo.
El fraude deliberado, o la incompetencia, por parte del personal contable o contratistas puede llevar a pérdidas directas, la falta de reconocimiento de problemas crecientes y sanciones legales.
Los estándares internos débiles para la contabilidad pueden dar lugar a inconsistencias.
La valoración fija de activos que en realidad pueden variar en precio, ya sean Stablecoins o clases de activos más volátiles, puede introducir oportunidades de arbitraje que pueden drenar el valor de un Protocolo. Este riesgo es más agudo para activos distintos a Stablecoins y puede verse agravado.
Las Stablecoins están destinadas a mantener un valor equivalente a alguna medida externa, como un Euro. Sin embargo, su valor de mercado a menudo varía ligeramente del anclaje y pueden "desanclarse" de varias maneras, lo que lleva a una diferencia significativa entre su Valor de Mercado Justo y su Valor Contable.
3.4.2.1 Mejores prácticas para gestionar los Riesgos de Contabilidad Operacional
Evaluación de Riesgos:
Cifras Financieras Relevantes
Informes de tipo 2 de [SOC1]
Proveedores de Servicios Clave
Estrategias de Mitigación Relevantes:
No asumir valoraciones fijas de tokens
Rastrear los datos de informes contra posiciones en la cadena
Documentar los procesos de conciliación
Proporcionar informes oportunos
Evaluar al personal
Establecer mecanismos de control interno
3.5 Riesgo de Crédito
El Riesgo de Crédito generalmente representa una probabilidad de pérdida para un prestamista debido a Deuda Incobrable, cuando un préstamo es liquidado y la garantía es insuficiente para reembolsar la deuda pendiente al prestamista, o el pago insuficiente hace que el flujo de caja y la liquidez del prestamista creen una situación que no puede sostener.
Muchos de los riesgos ya descritos en este documento contribuyen al Riesgo de Crédito: riesgo de software, riesgo de tokenomics y diseño de gobernanza, y el riesgo de colapso del mercado de liquidación.
Los bancos implementan la gestión del riesgo de crédito analizando el riesgo de crédito de cada uno de sus clientes (las 5 C's), están fuertemente regulados en torno al riesgo de crédito, brindan garantías a los prestamistas y, en muchos casos, están asegurados contra incumplimientos. Sin embargo, en las finanzas tradicionales (TradFi), los prestamistas aún enfrentan ciertos riesgos de actividades fraudulentas dentro del banco y externamente, así como la posible insuficiencia de reservas de capital durante eventos como una corrida bancaria.
En los préstamos descentralizados es posible que los prestamistas interactúen con prestatarios anónimos. Dado que los prestamistas como Proveedores de Liquidez invierten en un pool, la solvencia de los prestatarios individuales a menudo se considera relativamente poco importante.
En un mercado de rápido movimiento, como un colapso del mercado, la demanda insuficiente de los liquidadores puede significar que la liquidación no logra reembolsar al prestamista en su totalidad, en otras palabras, crea Deuda Incobrable. Este riesgo se ve agravado por la rehipotecación de la garantía o el alto apalancamiento.
3.5.1 Mejores prácticas para gestionar los Riesgos de Crédito
Evaluación de Riesgos:
Gestión de la liquidez
Medidas para gestionar el riesgo de crédito
Cobertura de seguro
Estrategias de Mitigación Relevantes:
Documentar el proceso de conciliación
Producir información financiera precisa y oportuna
Desarrollar modelos de amenazas
Pruebas de estrés regulares
Controles internos para la contabilidad
Monitorear a posibles usuarios que acumulen participaciones
Límites de riesgo apropiados
Monitorear el desarrollo de los Protocolos
3.6 Riesgo de Contraparte
El riesgo de contraparte es el peligro de que otra parte de una transacción te haga perder dinero.
El Riesgo de Contraparte más común en las finanzas tradicionales, como se describe en la sección anterior 3.5 Riesgo de Crédito, es que un prestatario no sea capaz de pagar su préstamo, ya sea un individuo que no puede hacer los pagos, o un banco u organización similar que no devuelve los depósitos.
Algunos podrían argumentar que un protocolo DeFi es en sí mismo una contraparte, porque un usuario transacciona con el Protocolo. Los Operadores del Protocolo y los Custodios relevantes son efectivamente contrapartes. En este documento, los riesgos que introducen se tratan respectivamente como 3.2 Riesgo de Gobernanza y 3.2.2 Riesgo de Custodia.
Si los Inversores y los Usuarios son contrapartes, hay riesgos de 3.3 Cumplimiento y Legales relacionados con los requisitos para que existan procedimientos KYC o AML para no tratar con individuos u organizaciones sancionadas.
3.6.1 Mejores prácticas para gestionar el Riesgo de Contraparte
Evaluación de Riesgos:
Proveedores de Servicios Clave
Procedimientos KYC / AML implementados por el Protocolo
Estrategias de Mitigación Relevantes:
Documentar el proceso de conciliación
Producir información financiera precisa y oportuna
Desarrollar modelos de amenazas
Pruebas de estrés regulares
Equilibrar el quórum de votación contra el suministro de tokens de gobernanza
Realizar la debida diligencia sobre los Operadores de Contratos Inteligentes
Controles internos para la contabilidad
Monitorear a posibles usuarios que acumulen participaciones
Implementar procedimientos KYC / AML
Monitorear el desarrollo de los Protocolos
3.7 Riesgo de Mercado
El Riesgo de Mercado es el riesgo de pérdidas debido a cambios inesperados en el valor de los activos subyacentes, como criptomonedas o tokens. Esto se debe típicamente a una pérdida de confianza en el Protocolo DeFi.
En DeFi, esto puede ser el resultado de fuerzas del mercado general como influencias económicas y monetarias y el sentimiento del mercado, pero también como consecuencia directa de la naturaleza digital y el diseño de los protocolos DeFi.
Los precios de los criptoactivos pueden ser altamente volátiles. Esto crea el riesgo de Pérdida Impermanente. Este riesgo generalmente se ve exacerbado por percepciones de Riesgo de Liquidez en un mercado.
Debido a que DeFi sigue siendo un espacio en gran parte no regulado, la ausencia de certeza legal puede aumentar el riesgo de mercado basado en las expectativas de cambios regulatorios que afectan la participación en proyectos DeFi.
Los hackeos, la explotación de vulnerabilidades descubiertas, o las acciones de los Operadores del Protocolo que se consideran poco éticas o dañinas, pueden socavar rápida y profundamente la confianza del mercado en un Protocolo o Activo Digital. En el caso más grave, estos también pueden literalmente drenar el valor de un Protocolo.
Las prácticas manipuladoras, como el wash trading, el spoofing o los pump and dump son un riesgo para los Protocolos DeFi. Generalmente, hay menos protección contra dicha manipulación que en TradFi, y la naturaleza seudónima de DeFi significa que puede ser más difícil identificar si un mercado está siendo manipulado.
Si el diseño de los creadores de mercado automatizados (AMM) en los DEX no puede gestionar adecuadamente la volatilidad a la que están expuestos, esto puede exacerbar el Riesgo de Mercado.
Muchos sistemas DeFi, particularmente las Plataformas de Préstamos Descentralizados, dependen de compartir el riesgo entre muchos participantes como una estrategia para minimizarlo.
En una situación donde el riesgo se distribuye demasiado estrechamente, o donde los efectos de un cambio de mercado no pueden ser sostenidos por demasiados inversores, esta estrategia se convierte en un riesgo sistémico.
3.7.1 Mejores prácticas para gestionar los Riesgos de Mercado
Evaluación de riesgos:
Participación en organismos de establecimiento de estándares
Inversores con participaciones significativas
Partes relacionadas conocidas
Profundidad del mercado y descubrimiento de precios
Hoja de ruta
Utilidad del token
Detectar y prevenir la manipulación del mercado
Competencia
Estrategias de Mitigación Relevantes:
Documentar el proceso de conciliación
Producir información financiera precisa y oportuna
Desarrollar modelos de amenazas
Pruebas de estrés regulares
Equilibrar el quórum de votación contra el suministro de tokens de gobernanza
Monitorear a posibles usuarios que acumulen participaciones
Monitorear el desarrollo de los Protocolos
Límites de riesgo apropiados
3.7.2 Riesgo de Liquidez
El Riesgo de Liquidez surge cuando una falta de liquidez disponible significa que los usuarios no pueden convertir tokens a su Valor de Mercado Justo.
Como se señaló en 3.5 Riesgo de Crédito, sin un intercambio centralizado o contraparte, los servicios DeFi a menudo dependen de incentivar a los creadores de mercado para liquidar préstamos subcolateralizados.
Los mecanismos de ajuste de liquidez fijos a menudo están codificados en la estructura del Protocolo DeFi. Esto limita la capacidad de las aplicaciones DeFi para responder a condiciones de mercado imprevistas o al comportamiento de los usuarios.
Esto, a su vez, puede dejar a los proveedores de liquidez y prestamistas con un riesgo de incumplimiento no anticipado derivado de la incapacidad para cumplir con sus propias obligaciones de liquidez.
La naturaleza descentralizada de estas aplicaciones también aumenta el riesgo de un desajuste de activos y pasivos, que típicamente sería gestionado en TradFi a través de intermediarios.
Aunque la sobrecolateralización en las aplicaciones de préstamo DeFi ayuda a mitigar el Riesgo de Liquidez, puede no funcionar como una barrera efectiva en ciertas situaciones como shocks de precios repentinos y mercados de rápido movimiento. Con una demanda insuficiente y oportuna de los liquidadores en el mercado, el mecanismo de liquidación puede fallar.
DeFi puede ser susceptible a un apalancamiento excesivo de criptomonedas o stablecoins utilizadas como garantía en plataformas de comercio DeFi.
Debido a que los activos utilizados como garantía en DeFi generalmente no están regulados y son de propiedad seudónima, pueden ser rehipotecados o de otro modo aumentar el apalancamiento a niveles que son insostenibles en situaciones como liquidación o cambios de precios importantes, aumentando el riesgo sistémico de una crisis de liquidez durante eventos adversos.
En los mercados DeFi, la liquidez generalmente está fragmentada, lo que plantea un mayor Riesgo de Liquidez en los pools de liquidez y préstamos individuales.
Esto puede significar que en cualquier mercado dado no hay necesariamente suficientes compradores y vendedores en un momento dado para proporcionar un mecanismo efectivo de descubrimiento de precios. Como resultado, los inversores pueden encontrar difícil entrar y salir de posiciones de manera oportuna y eficiente.
3.7.2.1 Mejores prácticas para gestionar los Riesgos de Liquidez
Evaluación de Riesgos:
Métricas Clave
Políticas de rehipotecación
Composición del Pool de Liquidez
Gestión de la liquidez
Volatilidad histórica
Estrategias de Mitigación Relevantes:
Publicar políticas para bloquear, quemar y emitir tokens
Reservas de capital adecuadas
Documentar el proceso de conciliación
Producir información financiera precisa y oportuna
Respuesta a incidentes disponible "24/7"
Desarrollar modelos de amenazas
Utilizar monitoreo en tiempo real automatizado
Usar aprendizaje automático e informes de incidentes
Pruebas de estrés regulares
Controles internos para la contabilidad
Monitorear a posibles usuarios que acumulen participaciones
Monitorear el desarrollo de los Protocolos
Demostrar reservas de capital adecuadas
Mantener una variedad de tokens
4. Información Clave para la Evaluación de Riesgos
Para evaluar y gestionar riesgos en DeFi, al igual que en TradFi, es necesario considerar información importante. Esto depende de la disponibilidad de ciertos tipos de información. Esta información puede ser proporcionada por los protocolos DeFi o, en muchos casos, por terceros. De hecho, uno de los beneficios de la relativa apertura de los protocolos DeFi es que a menudo los terceros especializados en análisis y reportes proporcionan la información más útil.
Dada la naturaleza automatizada de DeFi, mucha información importante puede y DEBE ser proporcionada en tiempo casi real, y la puntualidad de la provisión de información es en sí misma útil para evaluar el nivel de riesgo asociado con un Protocolo en particular.
Parte de la información necesaria para evaluar el riesgo es histórica, por lo que no estará disponible hasta que el Protocolo esté en funcionamiento. Otra información está relacionada con el diseño del Protocolo y DEBE estar disponible antes de que el Protocolo esté operativo.
La ausencia de cualquier informe clave puede implicar que la información no es conocida. Aunque esto hace que el riesgo sea más difícil de evaluar, también puede ser una indicación de que es mayor.
El reporte automatizado puede estar integrado en el diseño del Protocolo. Sin embargo, es importante considerar las Revisiones y Reportes del Protocolo producidos por terceros. En casos totalmente automatizados y descentralizados, es posible que no haya un Operador del Protocolo generando los reportes, como ocurriría en una empresa pública tradicional.
Los Reportes del Protocolo DEBEN estar disponibles públicamente.
Esto permite a las partes interesadas revisar las medidas de seguridad implementadas y asegurarse de que las vulnerabilidades conocidas hayan sido probadas. Ayuda a aumentar la confianza en los Operadores del Protocolo, lo que a su vez ayuda a mitigar el Riesgo de Mercado.
Este documento divide los informes importantes en:
Información Operacional: Indicadores clave de rendimiento y descripciones de consideraciones importantes sobre el Protocolo que pueden influir en su rendimiento futuro o capacidad de adaptarse a cambios en el entorno del mercado, y
Información Estructural: En DeFi, la estructura de un Protocolo, incluidos sus mecanismos de gobernanza y la Tokenomics subyacente, puede tener un impacto significativo en el potencial de riesgo. Es posible que los informes en esta categoría no cambien durante toda la vida útil de un Protocolo.
4.1 Informes Operacionales
Los informes históricos son importantes. Aunque no son una guía confiable para el rendimiento futuro, proporcionan una idea de cómo ha funcionado un protocolo bajo condiciones algo conocidas.
Como se describe con más detalle en esta sección, las Mejores Prácticas para los informes históricos incluyen documentar:
Información financiera
Hacks y ataques, ya sean exitosos o no, y las pérdidas resultantes
Liquidaciones
Auditorías, revisiones de seguridad y
Actualizaciones del sistema y cambios de software
Rendimiento de la blockchain
Decisiones y acciones de gobernanza
4.1.1 Informes Financieros
Los Reportes del Protocolo DEBEN cubrir cifras financieras relevantes y actualizadas (es decir, en la medida de lo posible, en vivo) similares a las de un negocio comparable en TradFi, cubriendo al menos:
Fuentes de ingresos (por ejemplo, emisión de tokens, préstamos, otras actividades)
Frecuencia y valor de las recompensas recibidas y distribuidas, por ejemplo, a los proveedores de liquidez
Gastos
Activos del Tesoro
Información de los Pools de Liquidez
Los ingresos pueden recibirse de muchas fuentes. Es importante describir las fuentes de rendimiento (por ejemplo, Emisión, Préstamos, Provisión de liquidez), tasas de rendimiento, la frecuencia o fechas de las recompensas con su valor total, e ingresos irregulares como los pagos de seguros recibidos.
Los gastos incluyen pagos directos relacionados con la operación de un Protocolo, tales como:
Tarifas de transacción pagadas en la blockchain,
Liquidaciones
Recompensas pagadas a los participantes, incluidos inversores y proveedores de liquidez,
Impuestos pagados.
Gastos relacionados con la operación
Pago por servicios prestados por terceros, incluidos los costos de auditorías y evaluaciones.
Información general importante incluye el valor de los activos mantenidos en el tesoro y las restricciones de liquidez, tanto externas como internas definidas como parte de la gobernanza general.
Los Reportes del Protocolo DEBEN detallar las métricas clave de DeFi.
Información importante incluye el Valor Total Bloqueado, el número de transacciones y número de tenedores, tasas de rendimiento y tasas de liquidación.
Los Reportes del Protocolo DEBEN proporcionar datos históricos de volatilidad de precios para los activos subyacentes.
Las criptomonedas y tokens pueden ser altamente volátiles. Proporcionar datos históricos de volatilidad, análisis de mercado y advertencias de riesgo ayuda a informar a los Usuarios del Protocolo sobre los riesgos potenciales para el Protocolo.
Los Reportes del Protocolo DEBEN cubrir la composición de los pools de liquidez, incluida la profundidad y diversidad de los proveedores de liquidez.
Las métricas relacionadas con la utilización de los pools, las reservas y los patrones históricos de liquidez brindan a los usuarios una idea de la salud general de la liquidez del protocolo.
4.1.2 Incidentes de Seguridad y Preparación
Los Reportes del Protocolo DEBEN detallar los resultados de las pruebas de estrés y análisis relacionados con choques de liquidez y condiciones adversas del mercado, incluidas las vulnerabilidades identificadas y las mitigaciones propuestas.
Los Reportes del Protocolo DEBEN incluir cualquier violación de seguridad o exploit que haya provocado la pérdida de fondos, así como cualquier ataque que haya sido detectado y neutralizado.
Un informe detallado de incidentes, que incluya el impacto, cómo funcionaron las medidas de mitigación existentes y los planes para prevenir incidentes similares en el futuro, es importante para comprender.
Los Reportes del Protocolo DEBEN proporcionar actualizaciones de seguridad técnica para todo el software utilizado por el Protocolo, incluyendo todos los siguientes:
Estándares técnicos cumplidos por el contenido revisado o el proceso de revisión
Problemas encontrados
Cómo se han solucionado las vulnerabilidades identificadas, y
Resultados de la evaluación realizada sobre el software corregido.
Es importante que la evaluación de seguridad cubra todo el software utilizado, incluidas las blockchains en las que opera el Protocolo, puentes y oráculos, y herramientas de terceros comúnmente utilizadas para interactuar con el Protocolo.
Igualmente, las revisiones de seguridad y los reportes deben cubrir el código que está realmente implementado, por lo que deben realizarse para cualquier actualización de software desplegada.
Requisitos adicionales de seguridad para tipos específicos de software se detallan en las subsecciones siguientes.
Para Smart Contracts, además de la Certificación EthTrust, esto puede incluir actividades como fuzzing o pruebas de penetración por white-hats.
Además de los resultados de las pruebas en sí, las medidas tomadas como resultado de las pruebas son un resultado muy importante.
Los Reportes del Protocolo DEBEN cubrir la evaluación de accesibilidad y usabilidad del software de frontend o interfaces regularmente, y específicamente para cualquier actualización o nuevo software implementado.
Los Reportes del Protocolo DEBEN cubrir las tendencias de centralización de las redes de oráculos de las que depende el Protocolo.
Resaltar los mecanismos de gobernanza, los modelos de consenso y los posibles riesgos asociados con la centralización.
Los Reportes del Protocolo DEBEN detallar el monitoreo de la infraestructura de puentes y Smart Contracts utilizados para transferencias de tokens entre blockchains.
Los Reportes del Protocolo DEBEN describir la historia de la blockchain subyacente para cualquier protocolo DeFi.
Puntos clave a incluir son si existen archivos confiables y exploradores de bloques que se mantengan para la blockchain, y si ha estado sujeta a cortes notables, por ejemplo, para responder a hacks u otros fallos.
4.1.3 Gobernanza y Asignación de Tokens
Los Protocolos DEBEN describir la distribución y concentración de tokens de gobernanza.
Esto es importante para evaluar preocupaciones como la posibilidad de un Rug Pull u otros ataques de gobernanza.
Los Reportes del Protocolo DEBEN describir lo que se sabe sobre los inversores con una tenencia significativa de tokens.
¿Qué retornos han obtenido los inversores privados y los miembros del equipo?
Los Reportes del Protocolo DEBEN detallar las partes relacionadas conocidas que realizan transacciones entre sí, cuya participación colectiva podría calificarlas como partes interesadas clave.
Esto está vagamente relacionado con las prácticas AML.
Los Reportes del Protocolo DEBEN describir cualquier actualización o ajuste realizado en el diseño de la tokenomics.
Los ajustes en la tokenomics, incluidos los cambios de parámetros por parte de los Operadores del Protocolo, son información importante para evaluar el rendimiento continuo de un Protocolo y de su gobernanza.
4.1.4 Investigación y Colaboración
Los Reportes del Protocolo DEBEN describir los esfuerzos de investigación en curso y las colaboraciones con socios de la industria, por ejemplo, en organizaciones de desarrollo de estándares, centrados en combatir riesgos.
4.1.5 Educación y Conciencia del Usuario
Los informes de los Protocolos DEBEN describir los esfuerzos de educación y concienciación del usuario.
4.1.6 Cumplimiento Regulatorio
Los inversores necesitan asegurarse de que entienden y cumplen con las leyes que se aplican a ellos, incluidas las regulaciones fiscales. En algunos casos, esto solo será posible si los protocolos DeFi proporcionan la información necesaria para hacer los juicios correctos.
Los Reportes del Protocolo DEBEN detallar las medidas tomadas para asegurar el cumplimiento de los estándares y directrices regulatorias relevantes, incluyendo al menos:
Requisitos de transparencia para la prevención del lavado de dinero (AML), conoce a tu cliente (KYC) y partes interesadas clave / internos,
Requisitos legales específicos para las jurisdicciones operativas
Cumplimiento contable con los requisitos locales (por ejemplo, GAAP, IFRS, etc.)
Las medidas para asegurar el cumplimiento, los planes para adaptarse a los requisitos regulatorios en evolución y las medidas para mitigar el riesgo legal y asegurar la protección adecuada del usuario permiten a los inversores asegurarse de que el protocolo opera dentro de un marco legal apropiado y aborda los posibles riesgos relacionados con actividades ilícitas.
Es importante que los informes proporcionen información suficientemente detallada para que sea útil para Usuarios e Inversores, quienes dependen de ella como parte de la información que necesitan para cumplir con la regulación respecto a sus propios asuntos financieros.
Una parte importante de un marco de alta calidad, y de la elaboración de informes sobre el mismo, es el monitoreo activo y continuo de su efectividad.
4.1.6.1 Informe de Cumplimiento Regulatorio
Los Reportes del Protocolo DEBEN proporcionar una visión detallada de los cambios en el panorama legal y regulatorio que gobierna las jurisdicciones específicas en las que opera el protocolo.
El análisis de leyes, regulaciones y directrices relevantes que pueden impactar el protocolo y sus usuarios, identificando posibles desafíos legales y vulnerabilidades, como el riesgo de violar leyes de valores, regulaciones AML o leyes de protección al consumidor, es toda información importante que ayuda a evaluar si los Operadores del Protocolo están gestionando efectivamente el Riesgo de Cumplimiento.
Los Reportes del Protocolo DEBEN proporcionar una visión detallada de las operaciones del protocolo relevantes a los impuestos que los Inversores del Protocolo o los Usuarios del Protocolo podrían estar obligados a pagar.
Abordar las implicaciones fiscales de usar el protocolo y participar en varias actividades DeFi, y proporcionar orientación clara y precisa a los usuarios sobre los flujos de control de activos digitales y sobre cómo sus cambios de valor ayudará a los inversores a evaluar las posibles obligaciones fiscales que podrían enfrentar, incluyendo la clasificación de transacciones, reconocimiento de eventos imponibles y requisitos de reporte.
4.2 Informes Estructurales
Muchos informes sobre la estructura de los Protocolos DeFi se asemejan a la información proporcionada para el 4.1 Informes Operacionales con información que describe las políticas implementadas, incluidas las proceduras automatizadas. En muchos casos, esta información puede estar disponible antes del lanzamiento del Protocolo. Excepto por los elementos actualizables del Protocolo, incluidas las decisiones de gobernanza tomadas por los Operadores del Protocolo, es poco probable que esta información cambie.
Los Reportes del Protocolo DEBEN describir la cobertura de seguros para la interrupción del negocio y/o la pérdida de activos.
Es importante describir cualquier cobertura de seguro disponible para los Operadores del Protocolo, Usuarios del Protocolo o Inversores del Protocolo, así como la cobertura para el propio Protocolo.
Los Reportes del Protocolo DEBEN detallar la frecuencia de los informes y qué tan actualizados están los informes.
Esta información es importante para todos los informes disponibles para un Protocolo. Dada la capacidad teórica y a menudo práctica de los Protocolos para operar a muy alta velocidad y los riesgos introducidos por la Latencia, es importante entender cualquier retraso en la información disponible.
Los Reportes del Protocolo DEBEN describir la profundidad del mercado y los mecanismos de descubrimiento de precios para el Protocolo.
4.2.1 Mecanismos de Gobernanza
4.2.1.1 Marco de Gobernanza
Los Reportes del Protocolo DEBEN describir la estructura de gobernanza en detalle, incluyendo:
procesos de toma de decisiones,
mecanismos para la participación de la comunidad,
procedimientos de emergencia,
cómo se deciden e implementan los cambios en el Protocolo,
el papel de los tokens de gobernanza,
terceros de los que depende el Protocolo, y
Mecanismos de Gobernanza sin Votación, como los privilegios que tienen los Operadores del Protocolo.
Los Reportes del Protocolo DEBEN detallar una hoja de ruta.
Los Reportes del Protocolo DEBEN describir la capacidad del protocolo para adaptar el diseño de la tokenomics.
Las condiciones cambiantes del mercado y las necesidades de los usuarios son comunes. El rendimiento óptimo puede depender de la realineación continua con las tendencias evolutivas de la industria.
Las buenas hojas de ruta incluyen hitos que, en la medida de lo posible, sean tangibles y rastreables.
Es importante describir cómo el protocolo crea un valor sostenible más allá de prácticas como recompras, quemaduras e impuestos, o una oferta muy limitada de emisión total en el TGE.
Los Reportes del Protocolo DEBEN describir las políticas para la emisión de nuevos tokens.
La claridad sobre la oferta continua y cómo se gobierna ayuda a los inversores y usuarios a mantener expectativas adecuadas sobre cuestiones como la inflación, así como la concentración o descentralización de la propiedad y la gobernanza.
Esto también está relacionado con la Distribución de Tokens de Gobernanza.
Los Reportes del Protocolo DEBEN describir mecanismos de gobernanza no basados en votación.
Esto cubre cualquier caso en el que cuentas específicas o los Operadores del Protocolo tengan control autónomo sobre las operaciones, y es especialmente importante para operaciones críticas como la capacidad de pausar un protocolo, censurar transacciones o actualizar software.
4.2.2 Evaluación del Riesgo de Contraparte
Realizar una evaluación exhaustiva de los riesgos de contraparte relacionados con transacciones seudónimas. Divulgar los esfuerzos de monitoreo continuo del protocolo, las colaboraciones con autoridades regulatorias y la implementación de herramientas de gestión de riesgos para abordar estos riesgos.
Los Reportes del Protocolo DEBEN detallar todos los terceros que realizan servicios importantes.
Además de los Operadores del Protocolo y los servicios contratados como contabilidad, monitoreo del Protocolo o entornos regulatorios, esto incluye dependencias importantes como operadores de Oráculos o Puentes y desarrolladores de software de terceros que es comúnmente utilizado por los Operadores del Protocolo, Usuarios del Protocolo e Inversores del Protocolo.
4.2.3 Plan de Monitoreo de Cumplimiento
Los Reportes del Protocolo DEBEN detallar mecanismos para asegurar el cumplimiento de los estándares y directrices regulatorias relevantes, incluyendo:
prevención del lavado de dinero (AML), conoce a tu cliente (KYC) y requisitos para Partes Interesadas Clave / Internos,
requisitos legales específicos para las jurisdicciones operativas,
cumplimiento contable con los requisitos locales (por ejemplo, GAAP, IFRS, etc.),
estrategias de tratamiento fiscal.
Las medidas para asegurar el cumplimiento, los planes para adaptarse a los requisitos regulatorios en evolución, las medidas para mitigar el riesgo legal y asegurar la protección adecuada del usuario y los controles internos, incluidas auditorías y evaluaciones de terceros para validar los esfuerzos de cumplimiento, permiten a los inversores verificar que el protocolo opera dentro de un marco legal apropiado y aborda los posibles riesgos relacionados con actividades ilícitas.
Es importante que los informes proporcionen información suficientemente detallada para que sea útil para los Usuarios del Protocolo e Inversores del Protocolo, para ayudarlos a cumplir con la regulación respecto a sus propios asuntos financieros.
Las asociaciones y colaboraciones con grupos de la industria o expertos legales centrados en el cumplimiento en el espacio DeFi pueden ayudar a aumentar la confianza en que un Protocolo está gestionando efectivamente los Riesgos de Cumplimiento.
4.2.4 Gestión de Amenazas de Seguridad
Los Reportes del Protocolo DEBEN describir las medidas implementadas por el protocolo para mitigar los riesgos de MEV, incluyendo al menos:
el uso de técnicas avanzadas de secuenciación de transacciones,
mecanismos anti-front-running, y
otras soluciones destinadas a reducir las oportunidades de extracción maliciosa de valor.
Los Reportes del Protocolo DEBEN describir los planes de respuesta a incidentes y recuperación para interrupciones o fallos relacionados con la blockchain.
Esto incluye las medidas tomadas para asegurar la detección, contención y resolución oportuna de incidentes, así como los procedimientos para restaurar las operaciones normales.
Los Reportes del Protocolo DEBEN detallar las medidas implementadas para proteger el tesoro del protocolo de ataques externos.
Esto incluye salvaguardias técnicas contra intentos de controlar las claves privadas del tesoro, como el uso de firmas múltiples, prácticas como la implementación de [CCSS] o estándares similares, capacitación en seguridad de la información para individuos y monitoreo de cualquier intento de concentrar la propiedad de tokens de gobernanza.
Los Reportes del Protocolo DEBEN describir las medidas de seguridad y las mejores prácticas implementadas, como cifrado, gestión segura de claves, autenticación multifactor y adhesión a estándares de seguridad de la industria.
Demostrar que se han seguido prácticas de desarrollo de software de alta calidad y que se implementan las mejores prácticas de la industria para la Seguridad en todo el protocolo, con una revisión y mantenimiento efectivos, los Proveedores del Protocolo DEBEN informar sobre las medidas de seguridad tomadas para asegurar la fiabilidad e integridad de las fuentes de datos utilizadas por los oráculos. Esto incluye revisiones y pruebas de seguridad, monitoreo y protección contra posibles brechas de seguridad o manipulación.
Los Reportes del Protocolo DEBEN cubrir la puntualidad y latencia de la entrega de datos de oráculos y las medidas implementadas para asegurar datos precisos y en tiempo real para transacciones sensibles al tiempo.
4.2.5 Gestión de Riesgo Crediticio y de Liquidez
Un informe integral que describa las prácticas de gestión del riesgo crediticio del protocolo es importante. Información clave incluye las medidas tomadas para mejorar la liquidez del mercado, como asociaciones con proveedores externos de liquidez o integración con intercambios descentralizados (DEX).
Los Reportes del Protocolo DEBEN describir medidas para gestionar el Riesgo Crediticio.
Información clave incluye los requisitos de LTV y políticas en torno a la colateralización, condiciones que desencadenan la liquidación y otros mecanismos diseñados para asegurar el reembolso de los préstamos.
Los Reportes del Protocolo DEBEN detallar la gestión de la liquidez.
Cómo el protocolo gestiona el Riesgo de Liquidez y se adapta a condiciones de mercado y comportamientos de usuarios imprevistos es información importante para entender cómo podría comportarse.
Es importante describir los mecanismos implementados para incentivar a los creadores de mercado, asegurar suficiente liquidez en los pools de préstamos y abordar el riesgo potencial de incumplimiento.
Los Reportes del Protocolo DEBEN divulgar cualquier práctica o política relacionada con la rehipotecación u otras formas de apalancamiento de colaterales.
Explicar cómo se monitorean y controlan estas prácticas para evitar un apalancamiento excesivo y mitigar los riesgos de crisis de liquidez ayuda a los Usuarios del Protocolo y a los Inversores del Protocolo a entender las expectativas sobre sus propios colaterales, así como a evaluar la posibilidad general de que un Protocolo en particular se vea expuesto a una crisis de liquidez en otro lugar.
4.2.6 Informes de Tokenomics
Los Reportes del Protocolo DEBEN explicar los mecanismos de incentivos en el diseño de la tokenomics.
Describir cómo se estructuran las recompensas, las tasas de inflación y los mecanismos deflacionarios para asegurar la viabilidad a largo plazo y evitar fallos económicos.
Abordar cualquier riesgo potencial de dilución y proporcionar información sobre los incentivos de participación en la gobernanza para los tenedores de tokens.
Los Reportes del Protocolo DEBEN articular la utilidad del token más allá de la especulación.
Describir su papel dentro del protocolo, posibles casos de uso futuro y cualquier plan para expandir su utilidad con el tiempo. Esto ayuda a establecer una base para la demanda estable y el valor a largo plazo.
4.2.7 Informes de Mercado
Es importante informar sobre el mercado general en el que opera un protocolo DeFi. Esto permite una comparación con productos similares y ayuda a otros Usuarios del Protocolo a juzgar qué tan bien entienden los Operadores del Protocolo el mercado en general.
Los Reportes del Protocolo DEBEN detallar las principales similitudes y diferencias con otros Protocolos bien conocidos.
Los Reportes del Protocolo DEBEN describir medidas para detectar y prevenir la manipulación del mercado.
El monitoreo en tiempo real puede ayudar a detectar manipulaciones como el comercio de lavado, el spoofing o los esquemas de pump and dump. Los proveedores externos de servicios de monitoreo pueden usar Machine Learning para analizar los resultados del monitoreo de múltiples Protocolos, lo que puede ayudar a detectar la primera ocurrencia de un tipo particular de manipulación del mercado en un Protocolo dado.
Las medidas para prevenir la manipulación del mercado pueden incluir mitigaciones directas impuestas por el Protocolo, como límites de negociación.
5. Estrategias de Mitigación de Riesgos
Existen varias buenas prácticas que pueden ayudar a mitigar tipos específicos de riesgo. Muchas buenas prácticas de mitigación de riesgos son relevantes para múltiples clases de riesgo.
5.1 Comunicación
Los Protocolos DEBEN mantener y monitorear canales de retroalimentación para abordar las preocupaciones e inquietudes de los usuarios.
La retroalimentación de los usuarios puede ayudar a identificar muchos tipos de problemas, desde deficiencias en el diseño del frontend que confunden a los usuarios hasta el punto de que crean riesgos, hasta un canal de advertencia adicional para la notificación de que alguien ha observado señales que sugieren que un protocolo podría estar bajo ataque.
Esto puede ayudar a proteger contra todos los tipos de riesgo.
Los Protocolos DEBEN proporcionar recursos educativos, directrices o mejores prácticas para que los usuarios se protejan y fomenten la participación responsable en el protocolo.
Los usuarios informados son usuarios más seguros. Ayudar a los Inversores del Protocolo y a los Usuarios del Protocolo a comprender los riesgos inherentes en DeFi, cómo funciona el Protocolo y cómo los usuarios pueden protegerse, es una inversión en un mejor rendimiento para los usuarios.
Esto puede ayudar a proteger contra todos los tipos de riesgo.
Los Protocolos DEBEN fomentar auditorías independientes de todos los aspectos del riesgo.
Existen muchas formas de fomentar la revisión independiente, desde proporcionar la información necesaria hasta incentivar directamente las revisiones que encuentren problemas. En el contexto del software, esto incluye recompensas por errores, pero también puede incluir solicitar activamente y enlazar a revisiones independientes.
Esto ayuda a asegurar la confianza en el Protocolo, así como a validar aspectos clave, desde la precisión y equidad de la implementación de la tokenomics hasta la estructura de gobernanza o la minimización del Riesgo de Cumplimiento.
Esto puede ayudar a proteger contra todos los tipos de riesgo.
El Software DEBE tener programas de recompensas por errores de terceros.
Esto permite a los investigadores de seguridad externos informar sobre cualquier vulnerabilidad identificada, asegurando un enfoque proactivo para la mitigación de riesgos.
El valor de las recompensas por errores en oferta puede influir en la elección entre informar las vulnerabilidades de manera responsable y venderlas a partes maliciosas o explotarlas directamente.
Esto es útil para todos los riesgos de Software.
El Software DEBE seguir las mejores prácticas estándar para la divulgación responsable de vulnerabilidades.
Existen muchas formas de gestionar la divulgación de vulnerabilidades. Para mejorar la probabilidad de que las vulnerabilidades se divulguen de una manera que permita solucionarlas antes de que se exploten, la industria del software ha adoptado durante mucho tiempo un conjunto de mejores prácticas para la divulgación.
En términos generales, estas piden que la divulgación se haga inicialmente de manera privada, permitiendo que se implemente una solución antes de que la vulnerabilidad se convierta en conocimiento común. A menudo permiten o mandan la publicación de la vulnerabilidad y las soluciones aplicadas después de que haya transcurrido cierto tiempo, para incentivar la corrección del software, permitir que el divulgador reciba crédito por su descubrimiento y demostrar que el proceso está activo y es efectivo en la protección de los usuarios.
Esto es útil para todos los riesgos de Software.
Los Protocolos DEBEN publicar políticas para bloquear, quemar y emitir tokens.
Debido a que la oferta de tokens tiene un impacto fundamental en el valor de cualquier token, y la insuficiente transparencia en las estructuras de tokenomics puede erosionar la confianza y dificultar la confianza del mercado, es importante demostrar cómo funcionan los procesos fundamentales.
Aunque el código en la cadena se puede leer en principio, es útil documentar cómo funciona, y es importante demostrar que las políticas publicadas que no se implementan automáticamente se siguen y que las decisiones de cambiar las políticas o desviarse de ellas están bien explicadas.
Esto puede ayudar a mitigar los riesgos de Gobernanza, el riesgo de Tokenomics y ayuda a comprender el riesgo de Liquidez relacionado con la tokenomics.
Los Protocolos DEBEN documentar el proceso de conciliación para cada período para servir como la pista de auditoría para su proceso contable.
La documentación de políticas ayudará a establecer una guía interna clara sobre los diversos tratamientos contables para las operaciones comerciales y los flujos de ingresos. Consideraciones para la metodología de base de costos seguida por la empresa, el mapeo del plan de cuentas y los contactos de transferencia interna/de terceros son algunos de los que impactarán la capacidad de las empresas para agilizar sus informes con precisión.
Cuando terceros están involucrados en la preparación de información financiera (por ejemplo, administradores de fondos o proveedores de software contable de activos digitales), las entidades DEBEN evaluar estas relaciones y obtener una comprensión completa de las responsabilidades de ambas partes con respecto al diseño e implementación de controles internos relevantes sobre la información financiera.
Dado que el software de terceros puede utilizarse para consumir y sintetizar información directamente de la blockchain y convertirla en entradas contables, las entidades DEBEN considerar si un tercero es reputado, regulado, asegurado y auditado, y también si proporciona un informe de control de la organización de servicios (SOC), según corresponda.
A medida que el espacio de criptoactivos y blockchain ha madurado en los últimos años, varias organizaciones de servicios, incluidos los custodios de claves privadas y los proveedores de datos de blockchain, han comenzado a proporcionar informes SOC 1 Tipo 2.
Los Proveedores del Protocolo DEBEN producir información financiera precisa y oportuna para fines de informe.
Esto ayuda a los Usuarios del Protocolo y a los Inversores del Protocolo a comprender y mitigar:
Riesgo de Tokenomics
Riesgo de Cumplimiento y Legal
Riesgo Fiscal
Riesgos de Conformidad Contable
Riesgos de Contabilidad Operacional
Riesgo Crediticio
Riesgo de Contraparte
Riesgo de Mercado
Riesgo de Liquidez
5.2 Detectar y Responder a Amenazas de Ataque
Los protocolos DEBEN tener respuesta a incidentes disponible "24/7".
Dada la potencial rápida explotación de vulnerabilidades descubiertas en DeFi, es importante que los Protocolos puedan responder muy rápidamente a cualquier anuncio o evidencia de una vulnerabilidad.
Esto puede ayudar a mitigar:
todos los riesgos de Software
Los Protocolos DEBEN desarrollar activamente modelos de amenazas.
Desde comprender los posibles impactos de los cambios en los mercados de liquidez hasta identificar vulnerabilidades de seguridad en el código, modelar las amenazas que un Protocolo puede enfrentar es una herramienta importante para asegurar que pueda evaluar adecuadamente el riesgo y así tomar medidas de mitigación apropiadas.
Esto ayuda a proteger contra varios tipos de riesgo, en particular:
Todos los riesgos de Software
Los Protocolos DeFi DEBEN usar monitoreo automatizado en tiempo real para detectar ataques o aumento del riesgo.
El monitoreo en tiempo real puede proporcionar una advertencia de ataques en curso, lo cual es importante para muchas estrategias de mitigación.
Los Smart Contracts, Bridges y Oracles pueden estar sujetos a una corriente constante de ataques, cuyo resultado puede ser una rápida y catastrófica pérdida de valor, pero también a una corriente constante de ataques muy pequeños, drenando cantidades significativas de valor durante un período de tiempo más largo.
El monitoreo automatizado también puede proporcionar información crucial relacionada con los ataques MEV y los cambios que aumentan el Riesgo de Liquidez. Comparar comportamientos estándar a través de un Bridge puede proporcionar una pista temprana de cuándo algo está saliendo mal, ya sea debido a un problema temporal como la latencia de la red o un ataque malicioso.
Los bots de monitoreo en tiempo real pueden enviar una alerta o realizar una acción predeterminada o una serie de acciones automáticamente en caso de emergencia.
Identificar cualquiera de los dos tipos de ataque y tomar medidas correctivas puede proteger una proporción significativa de la pérdida.
Este enfoque es particularmente útil para mitigar:
Los Protocolos DeFi DEBEN usar aprendizaje automático e informes de incidentes para identificar ataques en progreso o en preparación.
Las herramientas de aprendizaje automático y las bases de datos de ataques conocidos pueden ayudar a identificar comportamientos anómalos de los usuarios que pueden ser un ataque o la preparación para uno. Basado en el conocimiento adquirido en un Protocolo diferente, también pueden ayudar a identificar la primera ocurrencia de una nueva clase de ataque contra un Protocolo DeFi específico, aumentando la seguridad en comparación con la dependencia del conocimiento adquirido solo de ese Protocolo.
Los sistemas de aprendizaje automático se basan en un conjunto de datos de entrenamiento e inheredan limitaciones en sus capacidades de ese conjunto de datos, al igual que el valor de las bases de datos históricas está intrínsecamente relacionado con sus fuentes de contenido.
Esto es particularmente útil para proteger contra:
5.3 Seguridad de la Información y Endurecimiento
Existen prácticas de seguridad y estrategias de mitigación de riesgos que se aplican a todo el software, a menudo conocidas colectivamente como Infosec.
Los componentes del software DEBEN usar canales seguros para comunicarse.
Existen varias técnicas para interceptar la comunicación en internet. Cifrar la información intercambiada reduce la posibilidad de que un actor malicioso la intercepte y la utilice en un ataque. Esto puede ayudar particularmente a mitigar:
La mayoría de los tipos de riesgos de Software, particularmente
El software DEBE cifrar el almacenamiento de datos.
El software NO DEBE almacenar datos privados donde sean globalmente accesibles incluso si están cifrados.
El cifrado proporciona un cierto nivel de protección para los datos, pero todo cifrado conocido puede ser roto dado suficiente tiempo y recursos. Asegurar que los datos privados estén protegidos por medidas más allá del cifrado, como mantenerlos aislados, es importante para protegerlos a largo plazo, ayudando a mitigar el Riesgo de Custodia y el Riesgo de Cumplimiento y Legal.
Los Protocolos DEBEN someterse a una revisión de seguridad para todos los Componentes de Software implementados como parte de un protocolo DeFi.
Es importante que las revisiones de seguridad cubran el código exacto que se implementa. Existen muchos casos conocidos en los que cambios en solo una o unas pocas líneas de código previamente probado introdujeron una vulnerabilidad significativa.
En este contexto, integrar software efectivamente significa desarrollar software, y es una fuente común de vulnerabilidades. Cualquier trabajo de integración necesita una revisión específica para asegurar que no haya creado vulnerabilidades.
Existen especialistas en seguridad independientes para muchos tipos de software; donde sea relevante, estos se especifican para los componentes de software individuales como requisitos adicionales.
Muchos componentes de software comunes ya han pasado por una revisión de seguridad extensa. Aunque es razonable proporcionar enlaces a evaluaciones en lugar de repetirlas, es importante evaluar activamente esas evaluaciones, en lugar de simplemente asumir que su existencia demuestra su calidad.
En general, es una buena práctica usar software ampliamente utilizado y bien probado. Una excepción potencial es donde existe un riesgo considerable debido a la naturaleza pública del software como los Smart Contracts o mediante el uso de componentes de código abierto comunes que exponen un llamado Riesgo de Cadena de Suministro, donde un componente común incorporado en una pieza compleja de software está expuesto a comprometerse.
Esto ayuda a mitigar todos los riesgos de Software y también el Riesgo de Cumplimiento y Legal.
Los Protocolos DEBEN realizar Evaluaciones de Vulnerabilidades para cualquier actualización de componentes de software.
Cada vez que se actualiza cualquier software, existe el riesgo no solo de que la actualización en sí misma introduzca una vulnerabilidad, sino de que se introduzca una nueva vulnerabilidad a través de las interacciones del software actualizado con otras partes del sistema.
Esto ayuda a mitigar todos los riesgos de Software y también el Riesgo de Cumplimiento y Legal.
Los Protocolos que usan Oráculos DEBEN asegurar que sus Oráculos tengan múltiples fuentes de datos o usen múltiples Oráculos para asegurar que la redundancia permita la conmutación por error cuando sea necesario.
Esto ayuda a mitigar el Riesgo de Oráculo.
Los Oráculos DEBEN usar Promedios Ponderados por Tiempo para detectar y, si es necesario, suavizar picos repentinos.
El Promedio Ponderado por Tiempo (o TWAP) es una técnica común que utiliza una serie de puntos de datos para generar un precio suavizado o de tendencia a partir de una única fuente de datos.
Puede usarse tanto para establecer precios como como un punto de referencia para verificar si los precios se están desviando bruscamente de una tendencia, lo que puede indicar un comportamiento anómalo, incluida una brecha de seguridad en progreso.
Esto ayuda a mitigar no solo el Riesgo de Oráculo, sino que es una mitigación importante para el riesgo de MEV y el riesgo de Gobernanza.
Los Protocolos que usan Oráculos DEBEN asegurar que cada Oráculo pueda ser actualizado o eliminado cuando sea necesario.
Esto ayuda a mitigar el Riesgo de Oráculo.
Los Protocolos DEBEN proporcionar procedimientos de orden de transacciones que mitiguen la Extracción Maliciosa de Valor de las transacciones de otros usuarios.
Asegurar que las transacciones se procesen en el orden recibido puede ayudar a mitigar ataques de sincronización como el front-running.
Esto ayuda a mitigar el riesgo de MEV.
5.4 Pruebas
5.4.1 Revisiones de Protocolos DeFi
Las Revisiones de Protocolos DeFi pueden proporcionar a los usuarios una calificación de calidad simple que sea fácil de entender. Normalmente, evalúan los Protocolos DeFi según un estándar de calidad integral, cubriendo múltiples aspectos del Protocolo, como Smart Contracts, Controles de acceso, Oráculos, Documentación y Transparencia.
La práctica habitual es que el estándar utilizado y los informes resultantes estén disponibles públicamente.
5.4.2 Revisiones de Smart Contracts
Los Revisores de Smart Contracts, comúnmente conocidos en la comunidad blockchain como "auditores", son individuos o equipos de ingenieros de Smart Contracts que se especializan en evaluar la seguridad de los Smart Contracts, produciendo Revisiones de Seguridad. Una Revisión de Seguridad de Smart Contracts no es una auditoría según lo entendido por la comunidad contable, aunque ese es un nombre que a menudo se le da en las comunidades blockchain y de seguridad. Más bien, es una evaluación limitada en el tiempo del código del Smart Contract, intentando identificar cualquier vulnerabilidad de seguridad.
El resultado final de una Revisión de Seguridad de Smart Contracts suele ser un informe, que puede ser un documento altamente técnico que discute detalles del software, la documentación y posibles abusos. Su audiencia principal generalmente son los Desarrolladores del Protocolo responsables de los Smart Contracts que usa el Protocolo.
El formato y el contenido del informe pueden variar ampliamente entre revisores.
Las conciliaciones son una parte clave para establecer buenos controles contables operativos. Las verificaciones de integridad contra los datos fuente, como saldos de billeteras, saldos de pools de liquidez y protocolos de staking, son esenciales para garantizar la integridad de los datos.
Los Protocolos DEBEN realizar una revisión de seguridad de los Smart Contracts, y cualquier rectificación necesaria, antes de que el código se implemente en la blockchain.
Una vez implementado, el código de los Smart Contracts es visible públicamente. Dado que las vulnerabilidades a menudo pueden ser explotadas rápidamente, es importante asegurarse de que el código esté bien probado antes de que esté disponible para que los hackers lo analicen.
Esto ayuda a mitigar en particular el Riesgo de Smart Contracts.
Los Protocolos DEBEN evaluar la seguridad de la blockchain subyacente en la que se implementan.
Las evaluaciones de una blockchain pueden incluir Verificación Formal, evaluación de vulnerabilidades o debilidades identificadas y explicaciones de las mejoras realizadas como resultado de problemas identificados en una evaluación.
Esto ayuda a mitigar el Riesgo de Blockchain.
Los Protocolos DEBEN probar las aplicaciones frontend en un entorno controlado antes de la implementación o actualizaciones.
Es importante identificar posibles vulnerabilidades que puedan ser explotadas por actores maliciosos. Estas vulnerabilidades pueden variar desde el diseño de la interfaz que lleva a los usuarios a hacer cosas que no pretendían, hasta vulnerabilidades técnicas en trabajadores de servicio, webp, módulos de nodo y otros componentes, hasta la filtración de datos del usuario a terceros maliciosos que luego pueden explotarlos.
Gestionar estos riesgos para productos basados en blockchain es un paso esencial para asegurar la seguridad de extremo a extremo. Al probar las aplicaciones en un entorno controlado, las empresas pueden identificar posibles vulnerabilidades que puedan ser explotadas por actores maliciosos antes de implementarlas.
Esto ayuda a mitigar los riesgos de la Interfaz de Usuario en particular, pero también es relevante para otros riesgos de Software.
Los Protocolos DEBEN realizar pruebas de estrés regulares y análisis de escenarios para evaluar la resiliencia del protocolo a shocks de liquidez y condiciones adversas del mercado, e identificar posibles mitigaciones para las vulnerabilidades encontradas.
Esto es particularmente relevante para el riesgo de Mercado y el riesgo de Liquidez, pero también puede ayudar a mitigar:
todos los riesgos de Software
5.5 Implementar estándares apropiados
Varios estándares de la industria son relevantes para DeFi. Reflejando su naturaleza como finanzas mediadas por software, estos cubren múltiples áreas, incluidas Software e Interfaces de Usuario, cumplimiento regulatorio y estándares contables. Seguir los estándares de la industria ayuda a mantener la consistencia y la fiabilidad en la evaluación, y reduce los problemas que surgen cuando un nuevo revisor o Desarrollador de Protocolo comienza a trabajar con un protocolo.
Los Protocolos DEBEN aplicar los estándares relevantes, tal como se especifica en esos estándares.
Seguir de cerca el desarrollo de los estándares y la regulación ayuda a comprender la situación de un estándar dado en un momento dado. Participar en el desarrollo de esos estándares ayuda a profundizar esa comprensión y puede demostrar liderazgo en el campo. Ver también la participación en grupos de la industria en 5.7 Factores externos: Cumplimiento.
Esto puede ayudar a mitigar muchos tipos de riesgo.
Las Revisiones de Seguridad de Software DEBEN alinearse con los estándares de la industria.
Esto puede facilitar a los Revisores de Seguridad verificar que las Revisiones de Seguridad siguen las Mejores Prácticas y ayuda a mitigar todos los riesgos de Software.
Los Smart Contracts utilizados en un protocolo escritos en Solidity DEBEN tener una revisión de seguridad según la última versión publicada de la Especificación de Niveles de Seguridad de EEA EthTrust [EthTrust].
Existen muchas organizaciones que proporcionan revisiones de seguridad especializadas de Smart Contracts. La Especificación de Niveles de Seguridad de EEA EthTrust [EthTrust] es un estándar para revisiones de seguridad de Smart Contracts que asegura que las pruebas cubren vulnerabilidades conocidas.
A partir del 13 de junio de 2024, la última versión publicada de la especificación es la Versión 2. Sin embargo, también está disponible públicamente un Borrador de los Editores, que puede incluir algunas orientaciones más actualizadas.
Esto ayuda a mitigar en particular el Riesgo de Smart Contracts.
Los Desarrolladores de Protocolos DEBEN probar la seguridad del software y de las API contra los estándares de OWASP.
OWASP es una organización que desarrolla proyectos que la industria puede usar para identificar (y abordar) riesgos de diseño web y de otras aplicaciones:
Seguridad de Aplicaciones Web
Estándar de Verificación de Seguridad de Aplicaciones de OWASP [owasp-asvs]
Seguridad de Aplicaciones Móviles
Estándar de Verificación de Seguridad de Aplicaciones Móviles de OWASP [owasp-masvs]
Seguridad de API
Proyecto de Seguridad de API de OWASP [owasp-apis]
Esto es particularmente relevante para losriesgos de la Interfaz de Usuario, pero también puede mitigar otros riesgos de Software.
Las interfaces de front-end de DeFi DEBEN tener una evaluación de la Experiencia de Usuario que incluya una revisión de accesibilidad.
Es importante descubrir si la experiencia del usuario o la falta de accesibilidad puede exponer a los usuarios a una mayor probabilidad de errores debido a una falta de comprensión de las opciones que se les ofrecen.
Esto es particularmente valioso para mitigar los riesgos de la Interfaz de Usuario.
Las interfaces web DEBEN cumplir con el nivel AA o superior de [WCAG].
W3C proporciona las Pautas de Accesibilidad al Contenido en la Web [WCAG], un estándar global para garantizar el acceso a contenido y aplicaciones web para personas con discapacidades.
Esto es particularmente valioso para mitigar los riesgos de la Interfaz de Usuario. En muchas jurisdicciones, también es importante para el Riesgo de Cumplimiento y Legal.
Los Bridges DEBEN seguir las sugerencias de las Directrices de Seguridad Crosschain de EEA.
Las Directrices de Seguridad Crosschain de EEA [xchain-sec] describen algunos riesgos introducidos por operaciones entre blockchains y describen algunas posibles mitigaciones. No es un conjunto de requisitos tan detallado como [EthTrust], pero es útil para el caso específico de trabajar entre dos (o más) blockchains.
Esto es particularmente relevante para mitigar el Riesgo de Bridge.
Los Protocolos, Inversores y Usuarios DEBEN asegurarse de que los procedimientos de gestión de claves cumplan con los estándares relevantes para garantizar la robustez y la supervivencia.
Los procedimientos que pueden mitigar los Riesgos de Custodia se encuentran en estándares de propósito general como [SOC2], [ISO27001]. [CCSS] es un estándar específicamente para asegurar activos digitales e incluye requisitos escalonados para la gestión segura de claves por terceros, con un enfoque en la creación de claves, el almacenamiento de claves y el control de claves, así como la prueba de que los fondos son mantenidos por un tercero.
Esto ayuda a mitigar en particular el Riesgo de Custodia.
Los custodios de claves de terceros DEBEN cumplir con los requisitos de [CCSS], en el nivel más alto posible.
Los informes de incidentes DEBEN utilizar el formato STIX en la medida de lo posible para producir información interoperable.
[STIX] es un formato estandarizado para informar sobre incidentes de seguridad. Codificar la mayor cantidad de información posible sobre un incidente de seguridad en un formato interoperable legible por máquina permite comparaciones más eficientes y compilación de información.
Es importante tener cuidado con el uso de dicha información. El procesamiento automatizado ingenuo podría, si se implementa mal, introducir riesgos causados por la creación deliberada de informes engañosos o falsos para inducir una reacción como parte de una estrategia de ataque.
Esto ayuda a mitigar en particular el Riesgo se Software.
5.6 Actores Clave y Contrapartes
Si bien algunos Protocolos están completamente automatizados, en muchos casos hay personas que pueden influir en el rendimiento de un Protocolo. Estos incluyen Operadores de Smart Contracts, Operadores del Protocolo, aquellos involucrados en la gobernanza y aquellos que tienen suficientes participaciones para poder influir en la liquidez y el rendimiento del mercado de un Protocolo.
Los Protocolos DEBEN asegurarse de que la propiedad de los tokens de gobernanza esté distribuida entre partes independientes y sea resistente a la concentración.
Muchos protocolos incluyen alguna forma de gobernanza sin voto o gobernanza por un grupo especialmente limitado, donde una o más cuentas son designadas como propietarios o administradores con poderes especiales. Estos pueden incluir el poder de bloquear decisiones que no reflejen los objetivos de un Protocolo, pausar la operación de un Protocolo y otras acciones que tienen un impacto significativo en las operaciones del Protocolo.
En la práctica, esto es una limitación en cuán descentralizado está un Protocolo. Puede ayudar a mitigar una serie de riesgos de Gobernanza, aunque puede exacerbar otros.
Los Protocolos DEBEN usar Carteras de Firma Múltiple para decisiones de gobernanza, que requieren más de una pero menos de todas las partes elegibles para autorizar una transacción.
Para equilibrar los riesgos de un actor deshonesto, o de que una clave sea comprometida, por ejemplo, a través de un ataque de phishing, contra el riesgo de que algunas partes no estén disponibles de manera oportuna para la operación normal, es importante establecer parámetros de gobernanza en algún lugar entre permitir que cualquier signatario actúe y requerir la acción de todos los signatarios.
Los gobernadores sin voto, o los Operadores del Protocolo, probablemente estarán más disponibles que un grupo general de gobernanza de inversores, y esto es una consideración importante para determinar los mecanismos de votación y los umbrales para las decisiones de gobernanza.
Esto ayuda a mitigar el riesgo de Gobernanza.
Los Protocolos DEBEN equilibrar el quórum de votación con la oferta y distribución de tokens de gobernanza.
Asegurar que los requisitos de votación coincidan con la distribución y oferta real del token puede ayudar a proteger contra ataques que dependen de desequilibrar esos requisitos, como los ataques de flashloan.
Esto ayuda a mitigar el riesgo de Tokenomics, el riesgo de Gobernanza y otros riesgos de Contraparte que podrían abarcar el riesgo de Mercado.
Los inversores y usuarios DEBEN realizar la debida diligencia sobre los Operadores de Smart Contracts para los Smart Contracts que forman parte de un protocolo DeFi.
Si no hay servicios KYC que puedan avalar la identidad y antecedentes de los Operadores de Smart Contracts, es posible que haya un esfuerzo deliberado por evadir el escrutinio. En cualquier caso, dificulta mucho la evaluación del riesgo.
Esto ayuda a mitigar el riesgo de Gobernanza y otros riesgos de Contraparte.
Los Proveedores del Protocolo DEBEN evaluar si las personas que implementan y realizan los controles tienen las habilidades adecuadas para prevenir o detectar errores o fraudes que podrían resultar en declaraciones erróneas materiales en los estados financieros.
Estos controles pueden incluir la conciliación de lo que se presenta en un estado financiero con los datos en la cadena. Particularmente en casos donde se ha ingresado una posición en la cadena y aún no se ha cerrado (por ejemplo, tokens de pools de liquidez en staking en un protocolo), las herramientas para rastrear posiciones en la cadena pueden ser útiles para la conciliación.
Esto ayuda a mitigar el riesgo de Gobernanza y los Riesgos de Contabilidad Operacional.
Los Proveedores del Protocolo DEBEN establecer controles internos para los flujos de trabajo contables.
Estos incluyen la segregación de deberes, conciliaciones, documentación de políticas y controles de seguridad para los activos en su función contable.
La segregación de deberes incluye políticas internas claras sobre la autorización de diferentes individuos para supervisar la iniciación, ejecución y registro de transacciones. Las reglas de permisos adecuadas dentro del software ERP y subledger son una buena recomendación de mejores prácticas aquí junto con la documentación de signatarios autorizados.
Debido a la importancia de la contabilidad en la identificación de problemas, esto puede ayudar a mitigar una variedad de riesgos:
Los Protocolos DEBEN monitorear a los usuarios potenciales que acumulan participaciones en sus tokens.
Si bien reunir capital es un objetivo fundamental en el capitalismo y en DeFi, los usuarios que lo hacen, especialmente de forma anónima, pueden ser una señal de que están preparando un ataque a un protocolo DeFi. Esto puede ayudar a mitigar:
5.7 Factores externos: Cumplimiento
Es importante considerar cómo las transacciones corresponden a los patrones existentes que están cubiertos por los estándares contables relevantes. Aunque hay poca orientación establecida, hay un patrón notable de usar el Valor de Mercado Justo. Un Borrador de Exposición de FASB que sugiere direcciones para GAAP [fasb-expodraft] toma este enfoque, que coincide con los requisitos que cubren a las entidades consideradas Empresas de Inversión que ya deberían estar usándolo.
Identificar si los activos DeFi cumplen con los requisitos definidos para los estándares contables puede ayudar a garantizar que los procedimientos contables sean intentos razonablemente reconocibles de seguir los estándares aplicables.
Los Protocolos, inversores y usuarios DEBEN tener un proceso robusto en lugar para evaluar decisiones judiciales, leyes y regulaciones potencialmente relevantes, y monitorear la legislación y la creación de reglas pendientes.
La regulación de DeFi está en su infancia y, hasta cierto punto, en un estado de cambio. Monitorear el desarrollo continuo es importante para ayudar a mitigar los Riesgos de Gobernanza y los Riesgos de Cumplimiento y Legal, incluyendo:
Los usuarios, inversores y Protocolos DeFi DEBEN participar en grupos de la industria que se centran en la gestión del cumplimiento regulatorio y el riesgo legal.
Si bien la regulación de DeFi está en su infancia y en un estado de cambio, la participación directa en las discusiones que impactan la regulación puede ayudar a comprender los cambios probables. Ayudar a los reguladores a comprender la mecánica de los mercados DeFi es importante para asegurar que la regulación sea apropiada para cumplir sus objetivos de equilibrar equitativamente los requisitos para proteger a los Usuarios del Protocolo, que potencialmente incluyen tenedores de fondos públicos sustanciales e importantes, así como a los Inversores del Protocolo y a los Desarrolladores del Protocolo que hacen posible DeFi.
Esto ayuda a mitigar los Riesgos de Cumplimiento y Legal, incluyendo:
Los Protocolos DEBEN implementar procedimientos KYC/AML apropiados para las jurisdicciones relevantes para sus inversores y usuarios, incluidos los Operadores del Protocolo.
Esto ayuda a mitigar los Riesgos de Cumplimiento y Legal, así como el riesgo de Gobernanza, el riesgo de Custodia y otros riesgos de Contraparte.
Los Protocolos DEBEN explicar por qué se considera que un activo es un valor o no.
Con la continua incertidumbre sobre qué tipo de activos DeFi son valores y cuáles deben tratarse simplemente como utilidades, documentar una justificación clara para considerar un activo dado de una manera u otra ayuda a mitigar los Riesgos de Cumplimiento y Legal.
Los Protocolos DEBEN documentar sus prácticas contables y las justificaciones detrás de los métodos específicos elegidos para tratar clases de activos y eventos.
Esto ayuda a mitigar los Riesgos de Cumplimiento y Legal, incluyendo:
Ten en cuenta que múltiples firmas contables han adoptado la postura de que envolver y desenvolver tokens no es un evento imponible.
Los Protocolos DEBEN documentar la conciliación de los datos de informes con las posiciones en la cadena.
La mejor práctica es hacer esto a través de un producto de subledger o como un flujo de trabajo interno manual.
Los informes de recomendación de mejores prácticas incluyen el avance de activos, un informe del libro mayor general y un informe detallado de transacciones.
El FASB ha propuesto requerir que el avance de activos sea parte de todos los procesos contables digitales y ofrece una vista de alto nivel de los saldos de billeteras y activos [fasb-expodraft]. Las entradas del libro mayor ayudarán a conciliar que toda la actividad ha sido mapeada y categorizada correctamente, y el detalle de las transacciones asegurará la integridad a nivel granular en un período dado.
El monitoreo de transacciones a alto nivel puede complementar este proceso también, y la verificación por muestreo de transacciones inapropiadas o inusuales puede ayudar a detectar hackeos o fraudes.
Esto ayuda a mitigar los Riesgos de Contabilidad Operacional.
EJEMPLO 13: tokens envueltos: un desafío contable
No hay orientación específica ni en GAAP ni en IFRS sobre cómo tratar los Tokens Envuelto.
Uno podría potencialmente tratar el envoltorio y la quema como un evento imponible o no imponible. Ten en cuenta que múltiples firmas contables han adoptado la postura de que es un evento no imponible.
No un evento imponible - el argumento
El Requisito de Intercambio no se cumple cuando la propiedad del activo no se transfiere de una parte a otra. El Token Envuelto representa el interés continuo en el token nativo, y por lo tanto, el evento de envoltorio cae bajo una caracterización de mismo activo.
El requisito de Diferencia Material muestra un cambio significativo en la posición económica de las partes. Al envolver una moneda, en la mayoría de las situaciones, el Token Envuelto se comporta de manera idéntica al token subyacente. La intención no es comprar un nuevo activo, sino agregar una capa a la funcionalidad del activo.
Tanto el Token Envuelto como el token nativo se tratan como uno solo. El proceso de acuñación y quema no desencadena una disposición y adquisición de un activo.
Consideraciones adicionales:
Impactos en la base de costos: la base de costos solo se rastrea como un token combinado. La acuñación y quema de los Tokens Envuelto no impactan la base de costos, ya que los tokens se tratan como uno solo. La base de costos se transfiere hacia y desde el nuevo Token Envuelto.
Ganancias y pérdidas de capital: envolver y desenvolver no tienen impactos significativos en las ganancias o pérdidas realizadas. Solo la verdadera disposición del activo impacta las ganancias o pérdidas.
Evento imponible - el argumento
Cambiar tus tokens a la versión envuelta es una disposición de un activo y la adquisición de otro. Los precios del token y el Token Envuelto teóricamente tienen aproximadamente el mismo valor, pero durante períodos de alta volatilidad puede haber niveles aumentados de desvinculación. Por lo tanto, los activos deben ser rastreados por lotes para determinar las ganancias o pérdidas de capital asociadas con una disposición.
Consideraciones adicionales:
Impactos en la base de costos: un evento de envoltorio desencadenará una nueva base de costos para el Token Envuelto. El evento de quema también desencadenará una nueva base de costos para la compra del token original. Los costos se rastrean en cada moneda de manera independiente.
Ganancias y pérdidas de capital: Dependiendo de tu metodología de costos, el evento de envoltorio puede tener impactos significativos en tus informes fiscales y financieros. Cada evento de envoltorio representa una nueva disposición de un activo. Las ganancias o pérdidas deben rastrearse para cada activo.
Costos generales: Los costos fiscales de usar un Token Envuelto pueden superar sus beneficios. No se intercambia efectivo en un proceso de acuñación/quema. Cualquier responsabilidad fiscal deberá financiarse a partir de otras fuentes.
5.8 Gestión del Riesgo del Usuario
En cualquier sistema financiero, hay ciertas acciones que los usuarios pueden tomar para mejorar su comprensión y gestionar de manera efectiva su exposición a los riesgos inevitables.
Los Protocolos DEBEN permitir a los usuarios establecer límites de deslizamiento en las transacciones.
Limitar la cantidad de deslizamiento en comparación con el valor esperado de las transacciones y revertir cuando hay demasiado permite a los usuarios mitigar el riesgo de MEV.
Los Usuarios del Protocolo y los Inversores del Protocolo DEBEN monitorear de cerca su exposición y establecer límites de riesgo apropiados.
Establecer límites de riesgo a través del control de la exposición, la cobertura y similares es importante para asegurar que el valor en riesgo sea conocido y aceptable.
Esto ayuda a mitigar el riesgo Crediticio.
Los Usuarios del Protocolo y los Inversores del Protocolo DEBEN monitorear el desarrollo de los Protocolos, especialmente las decisiones de gobernanza.
Muchos Protocolos tienen la capacidad de cambiar, ya sea a través de decisiones de gobernanza o actualizaciones de software. Si los Usuarios del Protocolo o los Inversores del Protocolo no son conscientes de los cambios, pueden estar expuestos a riesgos adicionales.
Esto ayuda a mitigar:
Los Usuarios del Protocolo y los Inversores del Protocolo DEBEN tener acceso a la monitorización en tiempo real de los principales indicadores de salud del Protocolo.
Esto ayuda a mitigar la mayoría de los riesgos.
5.9 Reservas y Cobertura
Para mitigar el riesgo Crediticio, muchos sistemas DeFi dependen de préstamos sobrecolateralizados y liquidan automáticamente las posiciones basadas en condiciones de activación que generalmente están diseñadas para asegurar que haya suficiente colateral disponible para recuperar la deuda pendiente en su totalidad. Un mercado secundario saludable para el colateral mantiene el incentivo para que un liquidador opere, asegurando un nivel razonable de seguridad sin requerir tanta sobrecolateralización ni estableciendo valores de activación de liquidación tan altos que el propio mercado crediticio colapse.
Aunque la sobrecolateralización en aplicaciones de préstamos DeFi ayuda a mitigar el riesgo de Liquidez, puede no funcionar como un mecanismo de parada efectiva en ciertas situaciones, como shocks de precios repentinos y mercados que se mueven rápidamente. Con una demanda insuficiente y oportuna de los liquidadores en el mercado, el mecanismo de liquidación puede fallar, causando Deuda Incobrable y una pérdida de confianza en el Protocolo.
Los Protocolos DEBEN demostrar Reservas de Capital Adecuadas, incluidas reservas suficientes para la liquidez que no estén apalancadas.
Cuando las reservas mantenidas para gestionar la liquidez están apalancadas, es más probable que no estén disponibles precisamente cuando se necesitan. Mantener reservas demostrablemente no apalancadas es una importante mitigación para el riesgo de Liquidez y, en ciertos casos, ayuda a mitigar el riesgo de Cumplimiento y Legal.
Los usuarios, protocolos e inversores DEBEN mantener una gama de tokens u otras coberturas contra un problema de liquidez en un Protocolo determinado.
Esto es particularmente relevante para mitigar el riesgo de Liquidez.
A. Información Adicional
A.1 Estado de este Documento
A.1 Estado de este Documento
La Enterprise Ethereum Alliance (EEA) está publicando este Documento de Discusión que resalta las mejores prácticas observadas y aspiracionales para identificar, comprender y gestionar los riesgos derivados del uso de protocolos DeFi.
El grupo espera que este documento ayude a promulgar marcos robustos, especialmente para las instituciones que utilizan o desean utilizar e invertir en protocolos DeFi. Por lo tanto, el grupo espera recibir comentarios sobre mejoras que harán que el documento sea aún más útil para dichas audiencias.
El contenido de este documento ha sido aprobado por la Junta Directiva de la EEA. No representa la opinión de ningún miembro en particular de la EEA.
A.1.1 Cronograma de Desarrollo Esperado
Esta versión se publicó el 17 de julio de 2024.
El borrador del Editor se está actualizando a medida que el Grupo de Trabajo decide sobre las respuestas a los comentarios recibidos. Estas actualizaciones generalmente no serán más frecuentes que cada dos semanas.
El Grupo de Trabajo espera obsoletar este documento publicando una versión 2 como una especificación técnica de la EEA en algún momento de 2025.
A.1.2 Feedback Solicitados
El Grupo de Trabajo solicita comentarios sobre el documento en general. Las preguntas específicas sobre las que el grupo solicita comentarios incluyen:
¿Los evaluadores de contratos inteligentes deben ser independientes de los propietarios del protocolo/proyecto? Si es así, ¿a qué estándares de independencia deben adherirse? ¿Es necesario desarrollar un marco único de independencia?
¿Existe la necesidad de nuevos estándares comunes que los participantes del mercado puedan seguir?
¿Qué estándares comunes siguen los participantes del mercado, que deberían mencionarse en este documento?
¿Existen otros factores de riesgo relevantes para los usuarios de protocolos DeFi que no se hayan identificado?
¿Hay elementos de riesgo que no estén suficientemente descritos?
¿Existen posibles mitigaciones, incluidas las mejores prácticas aspiracionales, que no estén incluidas?
¿Qué más pueden hacer los desarrolladores de protocolos para facilitar la gestión de riesgos por parte de los usuarios en esta área?
¿La contabilidad de las actividades DeFi refleja la visión de que un protocolo DeFi es un principal en una transacción, o un agente para una transacción?
Por favor, envíe cualquier comentario sobre este trabajo a la EEA a través de https://entethalliance.org/contact/, usando [Defi Risks paper] como asunto, o planteando un problema o comentando sobre problemas existentes en el repositorio público de GitHub https://github.org/entethalliance/drama-public.
A.1.3 Términos de la Licencia de Derechos de Autor
Este documento está licenciado bajo los términos de la Licencia Apache, Versión 2.0 [Licencia]. A menos que la EEA lo autorice explícitamente por escrito, solo puede usar este documento de acuerdo con esos términos.
Este documento se distribuye "TAL CUAL", SIN GARANTÍAS NI CONDICIONES DE NINGÚN TIPO, ya sean expresas o implícitas.
Consulte la [Licencia] para conocer el lenguaje específico que rige los permisos y limitaciones otorgados automáticamente por la EEA.
A.2 Antecedentes: Conceptos Básicos de DeFi
Las Finanzas Descentralizadas (más comúnmente DeFi) son un sistema financiero basado en la tecnología blockchain. DeFi utiliza programas informáticos llamados Smart Contracts para automatizar muchos tipos de interacciones financieras. En principio, cualquier persona con una conexión a internet y el software necesario puede escribir un Smart Contract, implementarlo en una blockchain y, de la misma manera, invocar un Smart Contract. Esto elimina la necesidad técnica de un intermediario, como un corredor o un banco, para interactuar con un sistema de Finanzas Descentralizadas.
Los Smart Contracts son programas almacenados en la blockchain. Debido a que los Smart Contracts pueden ser invocados por otros Smart Contracts, es posible usarlos como componentes para construir un sistema complejo.
Los Smart Contracts implementan la funcionalidad central de DeFi, creando, manipulando, transfiriendo y destruyendo Tokens, que son artefactos digitales utilizados para representar valor en una blockchain. Los Smart Contracts también se utilizan para proporcionar y gestionar creadores de mercado automatizados, Intercambios Descentralizados, Préstamos Descentralizados, protocolos de seguros y otros instrumentos financieros automatizados.
Debido a que los contratos inteligentes pueden ser invocados por otros contratos inteligentes, es posible usarlos como componentes para construir un sistema complejo.
A.2.1 Billeteras
Las billeteras son programas que permiten a los usuarios almacenar y gestionar muchos tipos de tokens, como Ether, bitcoin y otros tokens, típicamente a través de una interfaz de usuario simple. Una billetera contiene las claves criptográficas privadas y públicas del usuario.
La Clave Pública del usuario actúa como un número de cuenta visible públicamente, una Cuenta Propiedad Externa (o EOA) que es controlada por un usuario, basándose en su capacidad para firmar con su clave privada como prueba de que tienen acceso a su propia dirección para validar transacciones realizadas desde esa cuenta.
La Clave Privada es un número muy grande, que solo debe ser conocido por el propietario de la billetera, que se combina con la Clave Pública para autorizar transacciones. Esto significa que cualquier persona que conozca o descubra la clave privada puede controlar la cuenta, realizando transacciones como transferencias a otra EOA o interactuando con un Smart Contract.
Las billeteras destinadas principalmente para uso personal suelen operar en una computadora personal o dispositivo móvil, con interfaces fáciles de usar, pero ofreciendo una protección limitada de las claves almacenadas en el dispositivo o en otro token físico. Estas billeteras generalmente no son utilizadas por instituciones excepto como parte de procedimientos de recuperación ante desastres.
Las billeteras de grado institucional para organizaciones que eligen la autocustodia comúnmente tienen motores de políticas de gobernanza, mayores controles de seguridad y gestión de riesgos, y pueden ofrecer interfaces web y API.
Por ejemplo, para prevenir puntos únicos de abuso, las Billeteras de Firma Múltiple requieren múltiples claves para realizar transacciones, lo que significa que ningún actor individual puede crear una transacción en nombre de la billetera. De manera similar, la Computación Multi-Party divide la clave en fragmentos distribuidos entre múltiples partes, donde solo la agregación de los resultados de la computación por un conjunto de esas partes con información que solo ellos poseen puede autorizar una transacción.
Las billeteras a menudo se denominan 'frías' o 'calientes'. Una Billetera Fría consiste en un pequeño dispositivo de almacenamiento que no está conectado a internet ni a ninguna máquina en funcionamiento (también conocido como Airgapped), que contiene las claves privadas del usuario y puede usarse para firmar. Los tokens no se almacenan en el dispositivo en sí, pero se considera que la seguridad de las claves privadas en este paradigma es más segura que las claves almacenadas en una computadora portátil u otro dispositivo. Una Billetera Caliente se almacena en una máquina en funcionamiento, como un teléfono móvil o una computadora portátil, y generalmente consiste en una aplicación para ayudar a los usuarios a firmar transacciones. Una billetera caliente generalmente se considera más vulnerable a comprometerse a través de hacking porque está conectada a internet.
Una Billetera de Custodia es una billetera cuyas claves privadas son gestionadas por un tercero. Esta es una práctica común para las instituciones DeFi más grandes (como los Intercambios Centralizados o CEXs) que tienen muchos tokens en nombre de sus usuarios. Un usuario accede a sus tokens a través de una cuenta con la institución, y las Claves Privadas están bajo la custodia de la institución. Aunque las grandes instituciones pueden convertirse en objetivos de ataque, generalmente emplean tácticas y tecnologías de seguridad avanzadas para hacer cumplir el almacenamiento seguro de estas claves más allá de lo que un usuario típico de billetera individual podría hacer.
A.2.2 Intercambios Descentralizados (DEXs)
Un Intercambio Descentralizado (o DEX) es una plataforma para intercambiar activos digitales que opera en una blockchain con capacidades de Smart Contract (por ejemplo, Ethereum). A diferencia de los intercambios centralizados, que dependen de una autoridad para gestionar las transacciones y centralizar la custodia de los activos, los intercambios descentralizados funcionan en una red peer-to-peer (P2P) sin intermediarios. Las transacciones, las reservas y las reglas de gobernanza son automatizadas por Smart Contracts, y los usuarios son responsables de la custodia de sus activos.
La liquidez para un DEX generalmente es proporcionada por Proveedores de Liquidez que depositan activos en un Pool de Liquidez mantenido por el software que ejecuta el protocolo. Los Proveedores de Liquidez usualmente reciben tokens LP, que representan una participación proporcional en los activos del pool. Los Proveedores de Liquidez también pueden ser recompensados compartiendo una porción de las tarifas de negociación en el pool y otras recompensas ofrecidas por el protocolo.
Los comerciantes intercambian activos disponibles en el Pool de Liquidez (y generalmente se les cobran tarifas de negociación por hacerlo). Estos procesos están gobernados por un Creador de Mercado Automatizado (o AMM), que consiste en un conjunto de Smart Contracts que codifican reglas y ejecutan transacciones. Un AMM generalmente ajusta las reservas en respuesta a la actividad de los comerciantes, basándose en relaciones matemáticas predeterminadas diseñadas para incentivar a los comerciantes a arbitrar cualquier diferencia entre el precio de los activos en el pool y en el mercado externo.
A.2.3 Protocolos de Préstamo Descentralizados
Los protocolos de Préstamo Descentralizados son plataformas basadas en blockchain que permiten a los usuarios prestar y pedir prestados activos digitales sin necesidad de intermediarios, como bancos o instituciones financieras.
Los protocolos se basan en Smart Contracts autoejecutables que codifican los términos del acuerdo entre el prestatario y el prestamista, por ejemplo, ajustando dinámicamente las tasas de interés en respuesta a la demanda. Los términos del préstamo se hacen cumplir automáticamente, con el colateral generalmente mantenido en custodia hasta que el préstamo sea reembolsado.
El Préstamo Descentralizado a menudo utiliza un Pool de Liquidez compartido para proporcionar los fondos para prestar. Las tasas de interés de préstamo y de endeudamiento generalmente se ajustan dinámicamente en respuesta a la oferta y la demanda de activos en el pool, basándose en reglas matemáticas codificadas en los Smart Contracts.
Los prestatarios generalmente proporcionan colateral para su préstamo depositando otro activo como colateral para ese protocolo de préstamo. Los préstamos a menudo están sobrecolateralizados, con colateral depositado para asegurar el préstamo que es de mayor valor que el préstamo, es decir, una LTV menor a 1. El grado de sobrecolateralización requerido (o LTV) generalmente depende de la volatilidad del activo prestado y del colateral.
Típicamente, la liquidación se activa automáticamente, ofreciendo el colateral para la venta en el mercado, a cambio de reembolsar el préstamo o en una subasta, si el nivel de colateralización cae por debajo del LTV.
A.2.4 Utilidades del Ecosistema DeFi
DeFi a menudo depende de un conjunto de utilidades que pueden facilitar la asignación eficiente de capital de riesgo:
A.2.4.1 Stablecoins
Una Stablecoin es un activo en la cadena diseñado para mantener una Paridad: un valor de mercado específico en comparación con un activo de referencia, como un Euro o un Dólar Estadounidense, y ser fácil de intercambiar por criptomonedas como ETH. Su valor de referencia generalmente estable, su compatibilidad con DeFi y el hecho de que generalmente es fácil intercambiarlas las han convertido en un componente clave del ecosistema.
Las Stablecoins pueden mantener su Paridad utilizando otros activos como colateral, similar a las políticas de Reserva de Oro que respaldaban muchas monedas en el siglo XX. Las Stablecoins respaldadas por Activos del Mundo Real ("RWA-backed") dependen de colateral mantenido en monedas "fiat", pero las Stablecoins también pueden estar respaldadas por criptoactivos u otras mercancías.
Las Stablecoins Algorítmicas (también conocidas como Stablecoins de Seignorage) utilizan un proceso automatizado para mantener su Paridad, por ejemplo, emitiendo nuevas monedas para reducir el valor de la Stablecoin a través de la inflación si está por encima de la Paridad y quemando monedas para reducir la oferta y aumentar el valor cuando está por debajo.
A.2.4.2 Tokens Envueltos
Los tokens de criptomonedas no funcionan en todas las redes blockchain. Por ejemplo, no se puede enviar BTC directamente a un protocolo DeFi. Los tokens envueltos representan otra criptomoneda y permiten mover activos entre diferentes blockchains. Pueden intercambiarse directamente dentro de una blockchain determinada.
Los Tokens Envueltos generalmente se crean pagando una cantidad dada del token subyacente a un servicio que lo mantendrá en custodia y proporcionará los Tokens Envueltos a cambio. Por lo tanto, los Tokens Envueltos en principio están respaldados por una cantidad igual del token subyacente. Para intercambiar el Token Envuelto por tokens subyacentes, la criptomoneda original se desbloquea y los Tokens Envueltos correspondientes se destruyen (o se queman). Es importante tener en cuenta que el valor puede no compararse exactamente con el activo subyacente (envuelto).
Cuando se realiza un pago en una blockchain y se proporcionan tokens en otra, el servicio se conoce como un Bridge.
En blockchains basadas en Ethereum, el token nativo de la cadena, ETH, no puede usarse en transacciones DeFi complejas sin primero convertirse en un token ERC-20, como Wrapped Ether (WETH). La mayoría de los contratos que toman ETH como entrada lo envolverán en WETH antes de transaccionar con él. Esto hace que envolver y desenvolver de nuevo en el token nativo sea una ocurrencia muy común en cadenas similares a Ethereum.
A.2.4.3 “Farming” de Rendimiento
El Yield farming permite a los individuos ganar recompensas depositando su criptomoneda o activos digitales en una aplicación descentralizada (DApp). Abarca dos tipos distintos: Rendimiento Subsidiado y Rendimiento Real.
El Rendimiento Subsidiado es cuando los protocolos incentivan a los usuarios a proporcionar liquidez o fomentar el uso ofreciendo recompensas de fondos controlados por el protocolo.
Por otro lado, el farming de Rendimiento Real implica asumir riesgos para proporcionar un servicio específico. Por ejemplo, los Proveedores de Liquidez para un DEX asumen el riesgo de Pérdida Impermanente a cambio de proporcionar liquidez y recibir compensación. De manera similar, los Proveedores de Liquidez para Protocolos de Préstamo Descentralizado asumen el riesgo de Deuda Incobrable a cambio de pagos de interés.
A.2.4.4 Derivados
El tamaño del mercado de derivados DeFi, apenas existente en 2020, ahora representa una gran y creciente participación de la actividad comercial en la cadena. Estos protocolos permiten a los usuarios exponerse al precio de un activo subyacente sin poseer realmente el activo. Hay muchas variaciones diferentes de estos protocolos, y los riesgos varían según el diseño del protocolo y los tokens disponibles.
Un derivado DeFi popular llamado opción perpetua permite a los comerciantes pagar una tasa de financiación para mantener una posición sintética abierta (larga o corta) que proporciona exposición apalancada al precio subyacente del token (apalancamiento de 1-100x).
A.4 Resumen de Riesgos
Esta sección proporciona un resumen de todos los requisitos en esta Especificación.
Falta de Estandarización: La falta de estandarización en formatos de datos, protocolos y APIs en DeFi plantea desafíos de interoperabilidad para el software DeFi. Integrar y normalizar software o datos de proveedores o fuentes diversas puede ser complejo y propenso a errores.
Cualquier software distribuido en una red tiene que lidiar con la latencia, el tiempo que puede transcurrir mientras el sistema se sincroniza a través de la red. En un contexto DeFi, esto introduce un riesgo de actuar sobre información desactualizada o de que las acciones planificadas no se ejecuten de manera suficientemente oportuna.
El código de los Smart Contracts es visible públicamente cuando se implementa en la blockchain. Esto permite a los hackers buscar errores o configuraciones incorrectas que puedan explotar para atacar el sistema DeFi y robar o destruir valor.
El código de Smart Contracts implementado apresuradamente sin una revisión adecuada, o con insuficiente tiempo dedicado a corregir los problemas descubiertos en una revisión de seguridad y retesting, puede llevar a que los Smart Contracts vulnerables sean explotados.
En la mayoría de las Blockchains, las transacciones pueden ser leídas por cualquiera; generalmente es muy obvio cuando un Smart Contract utilizado en DeFi está gestionando una gran cantidad de valor. Esto facilita calcular los posibles retornos de un ataque exitoso, atrayendo más atacantes a objetivos de alto valor.
Los Smart Contracts a menudo son inmutables una vez implementados, por lo que las técnicas de seguridad convencionales basadas en actualizar programas vulnerables no siempre están disponibles.
Los Smart Contracts actualizables introducen riesgos adicionales de seguridad y complicaciones.
Es posible que cualquier usuario interactúe directamente en la blockchain con un Smart Contract. La documentación inexacta o insuficiente de los Smart Contracts introduce un riesgo de que los usuarios que interactúan directamente lo hagan de una manera que cause errores.
La blockchain deja de funcionar. Las blockchains por diseño se espera que ofrezcan servicio "24/7/365". Este riesgo es real, pero generalmente pequeño en la práctica.
La blockchain pierde registros de transacciones.
La blockchain no ejecuta el código de un contrato correctamente, resultando en balances incorrectos.
Donde una blockchain puede ser controlada por un actor malicioso o un conjunto de actores, los activos digitales podrían ser robados o destruidos por "fuerza bruta", como un ataque del 51%.
Un riesgo clave de todo software orientado al usuario es que el diseño de la interfaz o la experiencia del usuario sea confuso, llevando a los usuarios a tomar acciones que tienen consecuencias inesperadas. Este riesgo puede amplificarse para los usuarios que dependen de herramientas menos comunes para acceder a la interfaz, incluyendo usuarios con discapacidades que dependen de tecnología asistiva.
Precisión de Datos y Manipulación: Los oráculos de DeFi dependen de fuentes de datos fuera de la blockchain para proporcionar información a los Smart Contracts que pueden actuar automáticamente sobre la información. Los datos inexactos pueden llevar a que los Smart Contracts produzcan resultados inesperados o no deseados.
Punto Único de Fallo: Los oráculos de DeFi que dependen de muy pocas fuentes de datos o de fuentes de datos inseguras introducen un riesgo de que la manipulación o el mal funcionamiento de ese oráculo puedan tener efectos adversos significativos.
Gobernanza y Actualización: Los mecanismos de gobernanza de los protocolos de oráculos DeFi juegan un papel vital en la determinación de cómo se seleccionan, gestionan y actualizan las fuentes de datos. Una gobernanza inadecuada puede llevar a flujos de datos sesgados o comprometidos, afectando la confiabilidad e integridad del protocolo que depende de tales oráculos.
Un gran pool de fondos puede actuar como un Honeypot, atrayendo ataques que intentan robar los fondos.
El riesgo creado por MEV es que un actor malicioso distorsione los precios en el protocolo para extraer valor de manera maliciosa.
Si un pequeño número de actores tiene un control significativo sobre los votos de gobernanza, existe el riesgo de que ejecuten un Rug Pull, robando los fondos de los usuarios, incluyendo el tesoro del protocolo.
En casos menos graves de concentración de tokens, aquellos con una participación controladora en la gobernanza pueden introducir cambios en el protocolo que desventajen a un grupo particular de tenedores de tokens.
Si la gobernanza depende excesivamente de una sola cuenta, por ejemplo, porque tiene un papel clave como Operador del Protocolo, y la clave de esa cuenta se ve comprometida (por ejemplo, robada mediante hacking u otros medios), un atacante puede controlar el protocolo.
Un riesgo similar puede surgir donde los procesos de gobernanza requieren un conjunto complejo de aprobaciones, que no hay suficientes incentivos para participar en las decisiones de gobernanza, paralizando efectivamente la gobernanza porque se vuelve prácticamente imposible ejecutar incluso cambios necesarios en el protocolo.
La mala gestión de Claves Privadas por parte de todos los usuarios es un riesgo.
Los problemas de tokens que resultan en distorsiones de suministro pueden reducir la oferta circulante, impactar la liquidez o diluir el valor de los tokens, potencialmente limitando la participación en el mercado.
Los tokens con utilidad limitada más allá de la especulación pueden enfrentar una demanda inestable y una mayor probabilidad de ser considerados como valores, con el consecuente (3.3) Riesgo de Cumplimiento y Legal.
La incapacidad de ajustar el diseño de tokenomics a las condiciones cambiantes del mercado y las necesidades de los usuarios puede resultar en un rendimiento subóptimo.
Los reguladores pueden considerar que interactuar con protocolos DeFi como una actividad o con un protocolo DeFi dado o sus Operadores del Protocolo viola leyes y regulaciones.
Los tokens considerados valores, en lugar de utilidades, generalmente están sujetos a marcos regulatorios diferentes y más estrictos.
Las implicaciones fiscales poco claras para DeFi introducen un riesgo de que el tratamiento fiscal pueda considerarse en violación de leyes y recomendaciones.
Un Protocolo podría considerarse en violación de la regulación AML.
El fraude deliberado o la incompetencia por parte del personal contable o los contratistas pueden llevar a pérdidas directas, fallos en reconocer problemas crecientes y sanciones legales.
Los estándares internos débiles para la contabilidad pueden dar lugar a inconsistencias.
La valoración fija para activos que en realidad pueden variar en precio, ya sean Stablecoins o clases de activos más volátiles, puede introducir oportunidades de arbitraje que pueden drenar el valor de un Protocolo. Este riesgo es más agudo para activos distintos a las Stablecoins y puede agravarse.
En un mercado en rápido movimiento, como un colapso del mercado, la demanda insuficiente de los liquidadores puede significar que la liquidación no reembolsa completamente al prestamista, en otras palabras, crea Deuda Incobrable. Este riesgo se ve exacerbado por la rehipotecación del colateral o el alto apalancamiento.
Los precios de los criptoactivos pueden ser altamente volátiles. Esto crea el riesgo de Pérdida Impermanente. Este riesgo generalmente se ve exacerbado por las percepciones de Riesgo de Liquidez en un mercado.
Debido a que DeFi sigue siendo un espacio en gran medida no regulado, la ausencia de certeza legal puede aumentar el riesgo de mercado basado en las expectativas de cambios regulatorios que afectan la participación en proyectos DeFi.
Los hackeos, la explotación de vulnerabilidades descubiertas o las acciones de los Operadores del Protocolo que se consideran poco éticas o perjudiciales pueden socavar rápida y profundamente la confianza del mercado en un Protocolo o Activo Digital. En el caso más grave, estos también pueden literalmente drenar el valor de un Protocolo.
Las prácticas manipulativas, como el wash trading, el spoofing o los esquemas pump and dump son un riesgo para los Protocolos DeFi. En general, hay menos protección contra tal manipulación que en TradFi, y la naturaleza seudónima de DeFi significa que puede ser más difícil identificar si un mercado está siendo manipulado.
Si el diseño de los creadores de mercado automatizados (AMMs) en DEXs no puede gestionar adecuadamente la volatilidad a la que están expuestos, esto puede exacerbar el Riesgo de Mercado.
Muchos sistemas DeFi, particularmente las Plataformas de Préstamo Descentralizado, dependen de compartir el riesgo entre muchos participantes como una estrategia para minimizarlo.
Los mecanismos de ajuste de liquidez fijos a menudo están codificados en la estructura del Protocolo DeFi. Esto limita la capacidad de las aplicaciones DeFi para responder a condiciones de mercado o comportamientos de usuarios no anticipados.
DeFi puede ser susceptible al exceso de apalancamiento de criptomonedas o stablecoins utilizadas como colateral en plataformas de trading DeFi.
En los mercados DeFi, la liquidez generalmente está fragmentada, lo que plantea un mayor Riesgo de Liquidez en pools de liquidez y préstamo individuales.
A.5 Resumen de Recursos e Reportes de Información
Esta sección proporciona un resumen de las recomendaciones para la presentación de informes en esta Especificación.
Los Informes del Protocolo DEBERÍAN estar disponibles públicamente.
Los Informes del Protocolo DEBERÍAN cubrir cifras financieras actualizadas (es decir, en la medida de lo posible, en tiempo real) relevantes (similares a las de un negocio TradFi comparable), cubriendo al menos:
Fuentes de ingresos (por ejemplo, emisión de tokens, préstamos, otras actividades)
Frecuencia y valor de las recompensas recibidas y distribuidas, por ejemplo, a proveedores de liquidez
Gastos
Activos del Tesoro
Información de los pools de liquidez
Los Informes del Protocolo DEBERÍAN detallar las Métricas Clave de DeFi actuales.
Los Informes del Protocolo DEBERÍAN proporcionar datos históricos sobre la volatilidad de precios de los activos subyacentes.
Los Informes del Protocolo DEBERÍAN cubrir la composición de los pools de liquidez, incluyendo la profundidad y diversidad de los proveedores de liquidez.
Los Informes del Protocolo DEBERÍAN detallar los resultados de las pruebas de estrés y análisis relacionados con shocks de liquidez y condiciones adversas del mercado, incluyendo cualquier vulnerabilidad identificada y las mitigaciones propuestas.
Los Informes del Protocolo DEBERÍAN incluir cualquier brecha de seguridad o explotación que haya llevado a la pérdida de fondos, así como cualquier ataque que haya sido detectado y neutralizado.
Los Informes del Protocolo DEBERÍAN proporcionar actualizaciones de seguridad técnica para todo el software utilizado por el Protocolo, incluyendo:
Estándares técnicos cumplidos por el contenido revisado o el proceso de revisión
Problemas encontrados
Cómo se han solucionado las vulnerabilidades identificadas, y
Resultados de la evaluación realizada sobre el software reparado
Los Informes del Protocolo DEBERÍAN cubrir la evaluación de accesibilidad y usabilidad del software de frontend o interfaces de manera regular, y específicamente para cualquier actualización o nuevo software implementado.
Los Informes del Protocolo DEBERÍAN cubrir las tendencias de centralización de las redes de oráculos en las que el Protocolo confía.
Los Informes del Protocolo DEBERÍAN detallar la monitorización de la infraestructura de puentes y los contratos inteligentes utilizados para las transferencias de tokens entre blockchains.
Los Informes del Protocolo DEBERÍAN describir la historia de la blockchain subyacente para cualquier protocolo DeFi.
Los Informes del Protocolo DEBERÍAN describir la distribución y concentración de los tokens de gobernanza.
Los Informes del Protocolo DEBERÍAN describir lo que se conoce sobre los inversores con una tenencia significativa de tokens.
Los Informes del Protocolo DEBERÍAN detallar las partes relacionadas conocidas que transaccionan entre sí, cuya tenencia colectiva podría calificarlas como un actor clave.
Los Informes del Protocolo DEBERÍAN describir cualquier actualización o ajuste realizado al diseño de tokenomics.Los Informes del Protocolo DEBERÍAN describir los esfuerzos de investigación en curso y colaboraciones con socios de la industria, por ejemplo, en organizaciones de desarrollo de estándares, enfocados en combatir riesgos.
Los Informes del Protocolo DEBERÍAN describir los esfuerzos de educación y concienciación del usuario.
Los Informes del Protocolo DEBERÍAN detallar las medidas tomadas para asegurar el cumplimiento con los estándares y directrices regulatorios relevantes, incluyendo al menos:
Requisitos de anti-lavado de dinero (AML), conocimiento del cliente (KYC) y transparencia de actores clave/insider,
Requisitos legales específicos de las jurisdicciones operativas
Cumplimiento contable con los requisitos locales (por ejemplo, GAAP, IFRS, etc.)
Los Informes del Protocolo DEBERÍAN proporcionar una visión detallada de los cambios en el panorama legal y regulatorio que gobiernan las jurisdicciones específicas en las que opera el protocolo.
Los Informes del Protocolo DEBERÍAN proporcionar una visión detallada de las operaciones del protocolo relevantes a los impuestos que los Inversores del Protocolo o los Usuarios del Protocolo podrían tener que pagar.
Los Informes del Protocolo DEBERÍAN describir la cobertura de seguro para la interrupción del negocio y/o pérdida de activos.
Los Informes del Protocolo DEBERÍAN delinear la frecuencia de los informes y la actualización de los informes.
Los Informes del Protocolo DEBERÍAN describir la profundidad del mercado y los mecanismos de descubrimiento de precios para el Protocolo.
Los Informes del Protocolo DEBERÍAN describir la estructura de gobernanza en detalle, incluyendo:
Procesos de toma de decisiones,
Mecanismos para la participación de la comunidad,
Procedimientos de emergencia,
Cómo se deciden e implementan los cambios en el Protocolo,
El papel de los tokens de gobernanza,
Terceras partes de las que depende el Protocolo, y
Mecanismos de Gobernanza no basados en votos, como los privilegios que tienen los Operadores del Protocolo.
Los Informes del Protocolo DEBERÍAN delinear una hoja de ruta.
Los Informes del Protocolo DEBERÍAN describir la capacidad del protocolo para adaptar el diseño de tokenomics.
Los Informes del Protocolo DEBERÍAN describir las políticas para la emisión de nuevos tokens.
Los Informes del Protocolo DEBERÍAN describir mecanismos de gobernanza no basados en votos.
Los Informes del Protocolo DEBERÍAN detallar todas las terceras partes que realizan servicios importantes.
Los Informes del Protocolo DEBERÍAN detallar los mecanismos para asegurar el cumplimiento con los estándares y directrices regulatorios relevantes, incluyendo:
Requisitos de anti-lavado de dinero (AML), conocimiento del cliente (KYC) y transparencia de actores clave/insider,
Requisitos legales específicos de las jurisdicciones operativas
Cumplimiento contable con los requisitos locales (por ejemplo, GAAP, IFRS, etc.)
Estrategias de tratamiento fiscal
Los Informes del Protocolo DEBERÍAN describir las medidas implementadas por el protocolo para mitigar los riesgos de MEV, incluyendo al menos:
El uso de técnicas avanzadas de secuenciación de transacciones,
Mecanismos anti-front-running, y
Otras soluciones destinadas a reducir las oportunidades de extracción maliciosa de valor.
Los Informes del Protocolo DEBERÍAN describir los planes de respuesta a incidentes y recuperación para interrupciones o fallos relacionados con blockchain.
Los Informes del Protocolo DEBERÍAN delinear las medidas implementadas para proteger el tesoro del protocolo de ataques externos.
Los Informes del Protocolo DEBERÍAN describir las medidas de seguridad y las mejores prácticas implementadas, como el cifrado, la gestión segura de claves, la autenticación multifactor y la adhesión a los estándares de seguridad de la industria.
Los Informes del Protocolo DEBERÍAN cubrir la puntualidad y latencia de la entrega de datos de oráculos, y las medidas implementadas para asegurar feeds de datos precisos y en tiempo real para transacciones sensibles al tiempo.
Los Informes del Protocolo DEBERÍAN describir medidas para gestionar el Riesgo de Crédito.
Los Informes del Protocolo DEBERÍAN detallar la gestión de la liquidez.
Los Informes del Protocolo DEBERÍAN divulgar cualquier práctica o política relacionada con la rehypothecation o otras formas de apalancamiento de colateral.
Los Informes del Protocolo DEBERÍAN explicar los mecanismos de incentivos en el diseño de tokenomics.
Los Informes del Protocolo DEBERÍAN articular la utilidad del token más allá de la especulación.
Los Informes del Protocolo DEBERÍAN delinear las principales similitudes y diferencias con otros protocolos bien conocidos.
Los Informes del Protocolo DEBERÍAN describir medidas para detectar y prevenir la manipulación del mercado.
A.6 Resumen de Estrategias de Mitigación
Esta sección proporciona un resumen de las recomendaciones para mitigar riesgos proporcionadas por esta Especificación.
Los protocolos DEBERÍAN mantener y monitorear canales de retroalimentación para abordar las preocupaciones e inquietudes de los usuarios.
Los protocolos DEBERÍAN proporcionar recursos educativos, directrices o mejores prácticas para que los usuarios se protejan y fomenten la participación responsable en el protocolo.
Los protocolos DEBERÍAN fomentar auditorías independientes de todos los aspectos del riesgo.
El software DEBERÍA tener programas de recompensas por errores de terceros.
El software DEBERÍA seguir las mejores prácticas estándar para la divulgación responsable de vulnerabilidades.
Los protocolos DEBERÍAN publicar políticas para bloquear, quemar y emitir tokens.
Los protocolos DEBERÍAN documentar el proceso de reconciliación para cada período para servir como la pista de auditoría para su proceso contable.
Proveedores de Protocolos DEBERÍAN producir información financiera precisa y oportuna para fines de reporte.
Los protocolos DEBERÍAN tener respuesta a incidentes disponible "24/7".
Los protocolos DEBERÍAN desarrollar activamente modelos de amenaza.
Los protocolos DeFi DEBERÍAN utilizar monitoreo automatizado en tiempo real para detectar ataques o riesgos aumentados.
Los protocolos DeFi DEBERÍAN usar aprendizaje automático e informes de incidentes para identificar ataques en progreso o preparación.
Los componentes de software DEBERÍAN usar canales seguros para comunicarse.
El software DEBERÍA cifrar el almacenamiento de datos.
El software NO DEBERÍA almacenar datos privados donde sean accesibles globalmente incluso si están cifrados.
Los protocolos DEBERÍAN someterse a una revisión de seguridad para todos los componentes de software implementados como parte de un protocolo DeFi.
Los protocolos DEBERÍAN realizar Evaluaciones de Vulnerabilidad para cualquier actualización de componentes de software.
Los protocolos que usen Oráculos DEBERÍAN asegurarse de que sus Oráculos tengan múltiples fuentes de datos, o usar múltiples Oráculos, para asegurar que la redundancia permita fallos cuando sea necesario.
Los oráculos DEBERÍAN usar Precios Promediados Ponderados por el Tiempo para detectar y, si es necesario, suavizar picos repentinos.
Los protocolos que usen Oráculos DEBERÍAN asegurarse de que cada Oráculo pueda ser actualizado o eliminado cuando sea necesario.
Los protocolos DEBERÍAN proporcionar procedimientos de orden de transacciones que mitiguen la Extracción Maliciosa de Valor de las transacciones de otros usuarios.
Los protocolos DEBERÍAN realizar una revisión de seguridad de Smart Contracts, y cualquier rectificación necesaria, antes de que el código se implemente en la blockchain.
Los protocolos DEBERÍAN evaluar la seguridad de la blockchain subyacente en la que implementan.
Los protocolos DEBERÍAN probar aplicaciones frontend en un entorno controlado antes de la implementación o actualizaciones.
Los protocolos DEBERÍAN realizar pruebas de estrés y análisis de escenarios regularmente para evaluar la resiliencia del protocolo ante choques de liquidez y condiciones adversas del mercado, e identificar posibles mitigaciones para vulnerabilidades encontradas.
Los protocolos DEBERÍAN aplicar estándares relevantes, según lo especificado en esos estándares.
Las Revisiones de Seguridad de Software DEBERÍAN alinearse con los estándares de la industria.
Los Smart Contracts usados en un protocolo escrito en solidity DEBERÍAN tener una revisión de seguridad de acuerdo con la última versión de la Especificación de Niveles de Seguridad EthTrust de la EEA [EthTrust].
Los desarrolladores de Protocolos DEBERÍAN probar la seguridad de software y API contra los estándares de OWASP.
Las interfaces frontend de DeFi DEBERÍAN tener una evaluación de Experiencia de Usuario que incluya una revisión de accesibilidad.
Las interfaces web DEBERÍAN conformarse al nivel AA o superior de [WCAG].
Los bridges DEBERÍAN seguir las sugerencias de las Guías de Seguridad Crosschain de la EEA.
Los protocolos, Inversores y Usuarios DEBERÍAN asegurarse de que los procedimientos de gestión de claves cumplan con los estándares relevantes para asegurar la robustez y la supervivencia.
Los custodios de claves de terceros DEBERÍAN cumplir con los requisitos de [CCSS], al nivel más alto posible.
Los informes de incidentes DEBERÍAN usar el formato STIX en la medida de lo posible para producir información interoperable.
Los protocolos DEBERÍAN asegurarse de que la propiedad de los tokens de gobernanza esté distribuida entre partes independientes y sea resistente a la concentración.
Los protocolos DEBERÍAN usar Wallets de Firma Múltiple para decisiones de gobernanza, que requieran más de una pero menos de todas las partes elegibles para autorizar una transacción.
Los protocolos DEBERÍAN equilibrar el quórum de votación contra el suministro y la distribución de tokens de gobernanza.
Los inversores y usuarios DEBERÍAN realizar la debida diligencia sobre los Operadores de Smart Contracts para los Smart Contracts que son parte de un protocolo DeFi.
Los proveedores de Protocolos DEBERÍAN evaluar si los individuos que implementan y realizan los controles tienen las habilidades adecuadas para prevenir o detectar efectivamente errores o fraudes que podrían resultar en declaraciones financieras materialmente incorrectas.
Los proveedores de Protocolos DEBERÍAN establecer controles internos para los flujos de trabajo contables.
Los protocolos DEBERÍAN monitorear a los usuarios potenciales acumulando participaciones en sus tokens.
Los protocolos, inversores y usuarios DEBERÍAN tener un proceso robusto para evaluar decisiones judiciales potencialmente relevantes, leyes y regulaciones, y monitorear la legislación y elaboración de normas pendientes.
Los usuarios de DeFi, inversores y Protocolos DEBERÍAN participar en grupos de la industria que se enfoquen en la gestión del cumplimiento regulatorio y el riesgo legal.
Los protocolos DEBERÍAN implementar procedimientos KYC/AML apropiados a las jurisdicciones relevantes para sus inversores y usuarios, incluyendo la cobertura de los Operadores del Protocolo.
Los protocolos DEBERÍAN explicar por qué un activo se considera un valor o no.
Los protocolos DEBERÍAN documentar sus prácticas contables y las razones detrás de métodos específicos elegidos para tratar clases de activos y eventos.
Los protocolos DEBERÍAN documentar la reconciliación de datos de informes contra posiciones on-chain.
Los protocolos DEBERÍAN permitir a los usuarios establecer límites de slippage en las transacciones.
Los usuarios de Protocolos e Inversores DEBERÍAN monitorear de cerca su exposición y establecer límites de riesgo apropiados.
Los usuarios de Protocolos e Inversores DEBERÍAN monitorear el desarrollo de Protocolos, especialmente las decisiones de gobernanza.
Los usuarios de Protocolos e Inversores DEBERÍAN tener acceso a monitoreo en tiempo real de métricas clave de salud del Protocolo.
Los protocolos DEBERÍAN demostrar Reservas de Capital Adecuadas, incluyendo suficientes reservas para liquidez que no estén apalancadas.
Los usuarios , protocolos e inversores DEBERÍAN mantener una gama de tokens u otros coberturas contra un problema de liquidez en un Protocolo dado.
A.7 Agradecimientos
La EEA reconoce y agradece a las muchas personas que contribuyeron al desarrollo de esta versión de la especificación, y a las organizaciones que los apoyaron para hacer sus contribuciones. Por favor, infórmenos de cualquier error u omisión.
Este trabajo también se ha basado en el trabajo de DeFiSafety sobre los procesos para revisar Protocolos DeFi.
Este trabajo fue posible gracias al generoso apoyo inicial de Consensys Software.
B. Referencias
B.1 Informative references
[CVE]CyberSecurity Vulnerabilities. MITRE. URL: https://www.cve.org
[CWE]Common Weakness Enumeration. MITRE. URL: https://cwe.mitre.org/
[EthTrust]EEA EthTrust Security Levels Specification v1. Enterprise Ethereum Alliance. URL: https://entethalliance.org/specs/ethtrust-sl/v1
[fasb-expodraft]Proposed Accounting Standards Update — Intangibles — Goodwill and Other — Crypto Assets (Subtopic 350-60): Accounting for and Disclosure of Crypto Assets. Financial Standards Accounting Board. URL: https://www.fasb.org/Page/ShowPdf?path=Prop+ASU%E2%80%94Intangibles%E2%80%94Goodwill+and+Other%E2%80%94Crypto+Assets+%28Subtopic+350-60%29%E2%80%94Accounting+for+and+Disclosure+of+Crypto+Assets.pdf&title=Proposed+Accounting+Standards+Update%E2%80%94Intangibles%E2%80%94Goodwill+and+Other%E2%80%94Crypto+Assets+%28Subtopic+350-60%29%3A+Accounting+for+and+Disclosure+of+Crypto+Assets&acceptedDisclaimer=true&IsIOS=false&Submit=
[License]Apache license version 2.0. The Apache Software Foundation. URL: http://www.apache.org/licenses/LICENSE-2.0
[ofac]Office of Foreign Assets Control. U.S. Department of Treasury. URL: https://ofac.treasury.gov/
[owasp-apis]OWASP API Security Project. The Open Worldwide Application Security Project. URL: https://owasp.org/www-project-api-security/
[owasp-asvs]OWASP Application Security Verification Standard. The Open Worldwide Application Security Project. URL: https://owasp.org/www-project-application-security-verification-standard/[owasp-masvs]OWASP Mobile Application Security Verification Standard. The Open Worldwide Application Security Project. URL: https://mas.owasp.org/MASVS/
[SOC1]SOC 1® - SOC for Service Organizations: ICFRa. The American Institute of CPAs. URL: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-1
[SOC2]SOC 2® - SOC for Service Organizations: Trust Services Criteria. The American Institute of CPAs. URL: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
[WCAG]Web Content Accessibility Guidelines 1.0. Wendy Chisholm; Gregg Vanderheiden; Ian Jacobs. W3C. 5 May 1999. W3C Recommendation. URL: https://www.w3.org/TR/WAI-WEBCONTENT/
[xchain-sec]EEA Crosschain Security Guidelines 1.0. Enterprise Ethereum Alliance. URL: https://entethalliance.github.io/crosschain-interoperability/crosschainsecurityguidelines.html
Last updated
