Cómo seleccionamos protocolos DeFi
Los seis criterios detrás de Curve, Pendle, Balancer, Beefy, Aave y StakeDAO — y lo que excluimos.
Curve 
Pendle 
Balancer 
Aave Protocolos sin custodia · Sin claves de clientes retenidas · Selección a partir de septiembre de 2026
La versión corta
- Seis protocolos llevan la asignación: Curve, Pendle, Balancer, Beefy, Aave y StakeDAO. Todos son sin custodia y ninguno retiene claves de clientes.
- Las mismas seis pruebas deciden la entrada: tiempo en producción, auditorías independientes públicas, diseño de oráculos, gobernanza y actualizabilidad, profundidad de liquidez y elegibilidad de cobertura.
- La selección es por pool, no por marca. Aprobar un protocolo no aprueba todos los mercados en los que opera.
- Se excluyen el apalancamiento, el looping, la exposición a activos volátiles, los forks no auditados y cualquier cosa que no sea USD o USDC — lo que reduce el techo de la tasa, deliberadamente.
- Superar los criterios no hace que un protocolo sea seguro. El riesgo de los contratos inteligentes permanece, por lo que la cobertura organizada a través de OpenCover se sitúa detrás de la asignación.
Nuestros seis criterios de selección.
Las mismas seis pruebas se aplican a cada pool antes de que cualquier fondo corporativo llegue a él. Son deliberadamente aburridas: ninguna de ellas trata sobre la tasa anunciada, porque la tasa es el resultado de una decisión de riesgo, no una razón para tomar una.
Tiempo en producción
Un protocolo entra en la asignación solo después de que sus contratos principales hayan funcionado en producción a un tamaño material a través de más de un ciclo de mercado. Los despliegues recientes, los forks sin auditar y los códigos base reescritos quedan excluidos, independientemente de la tasa que anuncien.
Auditorías independientes públicas
Los contratos en los que desplegamos deben tener informes de auditoría públicos de firmas independientes y un programa activo de recompensas por errores. Leemos los hallazgos y cómo se resolvieron, no la insignia en una página de destino. Una auditoría que precede a una reescritura sustancial se considera caducada.
Diseño del oráculo
La forma en que el protocolo valora los activos determina cómo falla. Analizamos de qué fuentes de precios depende, si un precio puede manipularse dentro de un bloque, si existen límites o interruptores automáticos, y qué hace el protocolo cuando una fuente de precios queda obsoleta.
Gobernanza y capacidad de actualización
Quién puede cambiar el contrato, bajo qué mayoría, y cuánto aviso recibe el cambio. Los bloqueos de tiempo, los umbrales de multifirma y los poderes de emergencia son parte del riesgo, porque un protocolo que puede actualizarse al instante puede actualizarse en contra de los depositantes.
Profundidad de liquidez y vía de salida
Una posición solo es tan buena como la forma de salir de ella. Dimensionamos cada asignación en función de la profundidad del pool en el que se encuentra, de modo que deshacerla no dependa de condiciones favorables, y que la ventana de retiro de 48 horas se mantenga sin forzar una salida desfavorable.
Elegibilidad de cobertura
El pool debe estar dentro del alcance de la cobertura organizada a través de OpenCover. Un protocolo que no podemos cubrir para los eventos enumerados no se utiliza para fondos corporativos, incluso si por lo demás está bien considerado.
Lo que los seis criterios no hacen
Superarlos no hace que un protocolo sea seguro. Contratos auditados han fallado, la gobernanza ha sido capturada y los oráculos han sido manipulados en protocolos que cumplían todos los criterios de esta lista. Las pruebas reducen las formas en que una posición puede salir mal e informan el tamaño de cada asignación. Lo que no pueden hacer es eliminar el riesgo de los contratos inteligentes, por eso la cobertura organizada a través de OpenCover se sitúa detrás de ellos y por eso la página de cobertura indica los riesgos residuales que siguen siendo suyos.
Curve — por qué, qué pools, qué riesgos.
Curve es un creador de mercado automatizado construido para activos que están destinados a negociarse al mismo precio. Esa especialización es la razón por la que está en la asignación: un pool de stablecoin a stablecoin es lo más parecido en DeFi a una posición cuyo comportamiento previsto es mantenerse estable y cobrar comisiones.
Curve · pools utilizados, y los tres riesgos que conllevan
Los depósitos proporcionan liquidez a los pools donde USDC se intercambia contra otro activo denominado en dólares. La posición gana una parte de las tarifas de swap pagadas por los traders, más los incentivos distribuidos a ese pool. Utilizamos pools cuyo otro lado estaríamos dispuestos a mantener directamente, porque eso es exactamente lo que sucede si los dos activos dejan de negociarse a la par.
- Rol en la asignación: Provisión de liquidez en stablecoins
- De dónde proviene el rendimiento: Tarifas de swap e incentivos de gauge
- Pools utilizados: Pools de estables a estables con USDC en un lado
- Custodia: Sin custodia, no se poseen claves de clientes
Naturaleza del riesgo — Riesgo de desequilibrio del pool. Un pool de intercambio estable absorbe el activo más débil. Si una stablecoin emparejada con USDC pierde su paridad, el pool termina reteniendo más de ella, y la posición refleja ese resultado. Este es el riesgo que determina qué pools utilizamos, y es por eso que nos mantenemos en pools cuyo otro lado estamos dispuestos a mantener.
Naturaleza del riesgo — Riesgo de contrato en el pool y el gauge. Depositar implica interactuar con el contrato del pool y, cuando se reclaman incentivos, también con el contrato del gauge. Cada uno es una pieza de código separada y un punto de fallo separado. Los errores de código son el evento en torno al cual se construye la póliza OpenCover, sujeta a sus términos.
Naturaleza del riesgo — Dependencia de incentivos. Parte del rendimiento en un pool incentivado proviene de emisiones en lugar de comisiones de swap. Las emisiones son establecidas por la gobernanza y pueden reducirse o redirigirse, por lo que la tasa realizada en un pool no es una propiedad fija de ese pool.
La selección es por pool, no por marca. Que Curve aparezca en esta página no significa que se utilicen todos los pools de Curve, y los pools de la asignación actual son los que se muestran en tu panel y se enumeran durante la incorporación.
Pendle, Balancer, Beefy, Aave y StakeDAO.
Cada uno está en la asignación para un trabajo específico, y cada uno aporta un modo de fallo específico. Ambos se indican a continuación. Dos de ellos — Beefy y StakeDAO — son capas sobre otros protocolos, lo que significa que su riesgo es aditivo en lugar de alternativo.
Protocolo · rol en la asignación, y naturaleza del riesgo
Rol en la asignación. Pendle separa una posición que genera rendimiento en su principal y su rendimiento futuro, lo que permite fijar una tasa conocida para una fecha conocida. Esa estructura de vencimiento es a lo que corresponde un nivel de plazo: una tasa acordada por adelantado en lugar de una flotante.
Naturaleza del riesgo. La posición se valora con una fecha. Salir antes del vencimiento significa vender al mercado, no a la par, y el mercado para un vencimiento puede ser poco líquido. Además, se suma el riesgo de contrato de la capa de tokenización y el riesgo del activo subyacente del que se deriva el rendimiento — Pendle no lo elimina, lo reempaqueta.
Rol en la asignación. Balancer proporciona otra arquitectura de pool para la liquidez de stablecoins. Su valor en la asignación no es una tasa nominal más alta, sino la diversificación del código base: dos plataformas construidas por equipos diferentes fallan por razones distintas, que es el punto de dividir una asignación entre ellas.
Naturaleza del riesgo. Riesgo de contrato a nivel de pool, además de los proveedores de tasas de los que depende un pool cuando mantiene un token que genera rendimiento en lugar de una stablecoin simple. La componibilidad añade conveniencia y añade dependencias; cada activo envuelto en un pool es un contrato más que debe comportarse correctamente.
Rol en la asignación. Las bóvedas de Beefy cosechan y reinvierten recompensas de una posición subyacente según un cronograma, sin intervención manual. La ganancia es operativa: menos acciones discrecionales, menos ciclos de capitalización omitidos y un menor costo por cosecha que hacerlo posición por posición.
Naturaleza del riesgo. Es una capa sobre otro protocolo. Usarlo implica asumir el riesgo del vault y del contrato de estrategia, además del riesgo del protocolo subyacente, no en lugar de este. Las estrategias también pueden ser modificadas por el protocolo, por lo que la posición se monitorea como un mandato activo, no como un depósito estático.
Rol en la asignación. Suministrar USDC a un mercado de préstamos genera el interés pagado por los prestatarios sobrecolateralizados. Es el instrumento más simple en la asignación y generalmente el más líquido, lo que lo convierte en el lugar natural para la parte que debe permanecer más fácil de deshacer.
Naturaleza del riesgo. Los retiros dependen de la utilización: cuando una gran parte de la liquidez suministrada es prestada, la salida espera a los reembolsos o a una nueva oferta. Más allá de eso, se encuentran las deudas incobrables de liquidaciones que no se ejecutan como se diseñó, la dependencia de los oráculos para valorar la garantía y el control de gobernanza sobre los parámetros de riesgo.
Rol en la asignación. StakeDAO se basa en la mecánica de voto-escrow del ecosistema Curve para mejorar la tasa obtenida en las posiciones de gauge y para gestionar el trabajo de reclamación y bloqueo que requieren esas posiciones. Su rol es la eficiencia en una exposición que ya mantenemos, no una nueva exposición.
Naturaleza del riesgo. Otra capa de contrato apilada sobre el protocolo subyacente, por lo que ambos conjuntos de código deben mantenerse. También hereda la dinámica de gobernanza de los sistemas de voto-escrow, y la liquidez de cualquier token de bloqueo líquido involucrado es una restricción real sobre la rapidez con la que se puede deshacer la posición.
Por qué seis y no uno
Concentrar una asignación corporativa en un solo protocolo hace que todo el saldo dependa de un único código base, un único órgano de gobierno y una única configuración de oráculo. Dividirla entre plataformas creadas por diferentes equipos significa que un fallo en una no arrastra la posición consigo. También implica más contratos en juego, que es el coste de esa elección y uno que declaramos en lugar de ocultar. Cómo funciona el despliegue paso a paso se detalla en la página de cómo funciona.
Qué excluimos y por qué.
Una política de selección se define tanto por lo que rechaza. Estas son las categorías que quedan fuera del alcance de los fondos corporativos, con la razón por la que cada una está excluida.
| Excluido | Por qué |
|---|---|
| Cualquier cosa excepto USD y USDC como activo base | Las stablecoins algorítmicas, con rendimiento y de baja liquidez no se utilizan como activo depositado. El producto está denominado en USD o USDC y el activo base no es donde asumimos el riesgo. |
| Estrategias de apalancamiento y de bucle | El préstamo recursivo aumenta la tasa al incrementar la probabilidad de liquidación. Una asignación de tesorería no debe mantener una posición que pueda ser cerrada en su contra por un movimiento de precios. |
| Exposición direccional a activos volátiles | No hay pools donde la posición asuma exposición al precio de un activo volátil. Si el valor en dólares del saldo puede moverse con el precio de un token, no es un producto de ahorro. |
| Nuevos despliegues y forks no auditados | Un fork hereda la reputación del original y ninguna de sus pruebas. Sin una auditoría independiente pública del código desplegado, no califica, sea cual sea la tasa. |
| Contratos de actualización instantánea y claves de administrador sin restricciones | Cuando una clave de administrador puede cambiar el comportamiento del contrato sin bloqueo temporal ni aviso, los depositantes no tienen ventana para reaccionar. Ese es un riesgo de gobernanza que rechazamos en lugar de valorar. |
| Posiciones fuera del alcance de la cobertura | Si un pool no puede ser incluido dentro de la cobertura arreglada a través de OpenCover para los eventos listados, no se utiliza para fondos corporativos. El rendimiento no es una razón para mantener una posición sin cobertura. |
La consecuencia de esta lista es un límite más bajo en la tasa de lo que mostraría una estrategia sin ella. Ese es el intercambio previsto: la cuadrícula de tasas
Cadencia de revisión y condiciones de salida.
La selección es una decisión que debe tomarse de nuevo. Un pool permanece en la asignación porque aún cumple los requisitos, y sale cuando deja de cumplirlos — no cuando la pérdida ya ha ocurrido.
- 01
Revisión de entrada
Un pool se revisa según los seis criterios antes de cualquier asignación. La unidad de la decisión es el pool, no la marca: aprobar un protocolo no aprueba todos los mercados en los que opera.
- 02
Monitoreo continuo
Las posiciones, la composición de los pools y las condiciones del protocolo se monitorean de forma continua. Las actualizaciones de contratos, las propuestas de gobernanza y los cambios de oráculos se tratan como eventos para reevaluar, no como ruido.
- 03
Revisión periódica
Cada pool en la asignación se reexamina según los mismos seis criterios de forma recurrente, de modo que una posición permanece en la asignación porque sigue cumpliendo los requisitos, no porque los cumplió una vez.
Qué desencadena una salida
Lo que un proceso de revisión no puede prometer
Salir de un pool es una decisión de asignación y no cambia tu nivel. Tus propios términos de retiro no cambian: los fondos están disponibles dentro de 48 horas, y salir temprano de un nivel bloqueado devuelve el capital y pierde los intereses acumulados.
Auditorías públicas referenciadas.
Cada protocolo en la asignación publica sus propios informes de auditoría. Hacemos referencia a esos informes publicados — no producimos nuestro propio resumen de ellos en esta página, y no reafirmamos sus conclusiones como nuestras.
De dónde provienen los informes
Cada protocolo publica sus propios informes de auditoría y programa de recompensas por errores en su documentación pública y repositorios. Esos informes publicados son los que revisamos y a los que hacemos referencia — no los encargamos ni los revendemos.
Lo que leemos en ellos
El alcance de la auditoría y el commit que cubre, la gravedad de los hallazgos, cómo se resolvió cada uno y si el código desplegado sigue coincidiendo con el código auditado después de actualizaciones posteriores.
Lo que proporcionamos a petición
Durante la incorporación, la lista de los pools en la asignación actual con sus direcciones de contrato y enlaces a los informes públicos que los cubren, para que un equipo de revisión pueda verificar la cadena por sí mismo.
Lo que no publicamos aquí
No reafirmamos conclusiones de auditoría, publicamos nombres de firmas y fechas, ni resumimos hallazgos en una página de marketing. Un resumen de auditoría escrito por la parte que asigna los fondos no es evidencia. Cuando una referencia no tiene fuente, no se menciona.
Dónde continuar con esto
Esta página explica cómo un protocolo entra en la asignación y cómo sale. Las dos páginas que una revisión financiera suele solicitar a continuación son los términos de cobertura detrás de estas posiciones y los requisitos de incorporación con la entidad contratante.
Solicite acceso o haga primero las preguntas difíciles.
Abre una cuenta directamente. Si tu equipo de finanzas necesita los términos de cobertura y los requisitos de KYB antes de eso, una llamada es la vía más rápida.