Blog de Stakely
23 de Marzo de 2026

Cómo hacer due diligence de un proveedor institucional de staking

23 de Marzo de 2026

Cuando una institución delega activos en staking, no está eligiendo solo una fuente de rendimiento. Está seleccionando un operador cuya seguridad, disciplina operativa e infraestructura pueden afectar directamente a su exposición al riesgo técnico, reputacional y de gobernanza.

Por eso, una evaluación sobre la elección del mejor validador no debería quedarse en la comisión, el APR anunciado o el material comercial del proveedor. El análisis debe centrarse en la capacidad real de ejecución: cómo opera, cómo gestiona incidentes, qué evidencias puede aportar y cómo delimita sus responsabilidades frente al cliente y, en su caso, frente al custodio.

Esta guía resume los criterios que conviene revisar en una due diligence institucional. No todos pesan igual en todos los protocolos, pero sí ayudan a distinguir a un operador maduro de otro que compite principalmente por precio.

Antes de comparar proveedores: 

* **Compara siempre por red y por modelo de servicio**: no es lo mismo operar staking nativo, infraestructura dedicada o una integración con custodio. 
* **No bases la decisión en una única métrica**: la comisión, el uptime o una certificación aislada no sustituyen una revisión de conjunto. 
* **Solicita evidencias verificables**: un operador institucional debe poder explicar y documentar cómo trabaja, no solo afirmarlo.

1. Estructura económica y alineación de incentivos

La comisión sigue siendo relevante, pero por sí sola dice poco. Lo que una institución necesita entender es qué sostiene esa comisión: monitorización, personal on-call, seguridad, reporting, redundancia, soporte y capacidad real de respuesta ante incidentes.

La comisión sigue siendo relevante, pero por sí sola dice poco. Lo importante es entender qué servicios financia y si el modelo económico es sostenible. Una comisión agresiva puede ser atractiva a corto plazo, pero también puede indicar una operación infra-dimensionada o una política comercial pensada para captar volumen sin construir una relación duradera.

La pregunta útil no es solo cuánto cobra el proveedor, sino qué incluye realmente: monitorización 24/7, soporte técnico, reporting, gestión de incidentes, integración con custodios, cobertura contractual y capacidad de respuesta ante contingencias.

2. Performance operativa: mide la participación efectiva, no solo uptime

Un validador puede estar “online” y, aun así, rendir por debajo de lo esperado. Lo que interesa es su participación efectiva en consenso y el impacto de esa ejecución en las recompensas netas del delegador. Las métricas concretas cambian según la red, así que conviene evitar comparaciones superficiales entre protocolos distintos.

En Ethereum, por ejemplo, suele ser más informativo revisar la calidad de las attestations, proposals y sync committee duties que limitarse a un porcentaje genérico de disponibilidad. En Solana, las recompensas están ligadas al comportamiento de voto del validador y a su comisión, por lo que el análisis debe apoyarse en métricas de participación en consenso y en datos verificables de la red.

Un operador serio tampoco esconde los incidentes. Haber tenido alguno no es necesariamente una mala señal; lo relevante es si hubo recurrencia, pérdida sostenida de rendimiento o falta de explicación técnica.

3. Seguridad: protocolo sólido no equivale a operador sólido

En staking, una parte importante del riesgo no está en el protocolo, sino en la operación diaria. Gestión de claves, accesos, cambios en producción, segregación de funciones y respuesta a incidentes son factores que marcan diferencias reales entre operadores.

Las instituciones no deberían conformarse con escuchar que el proveedor “sigue buenas prácticas”. Lo exigible es una explicación concreta del modelo de control: quién puede hacer qué, cómo se protegen las claves, qué mecanismos reducen el error humano y qué trazabilidad existe sobre cambios críticos.

Además, no todas las redes comparten el mismo modelo de riesgo. Un proveedor maduro debe poder explicar cómo adapta su arquitectura y sus controles al protocolo concreto en el que opera.

4. Slashing, penalizaciones e inactividad: riesgos distintos, respuestas distintas

Un análisis institucional debe distinguir entre slashing, penalizaciones operativas e inactividad. Mezclar estas categorías lleva a decisiones pobres y a una comprensión incompleta del riesgo.

En Ethereum, por ejemplo, el slashing está asociado a conductas slashable en consenso, mientras que estar offline suele traducirse en pérdida de recompensas y, en escenarios extremos, en inactivity leak; no son eventos equivalentes.

Por eso conviene evaluar dos planos distintos: la prevención técnica, por ejemplo, slashing protection y diseños de alta disponibilidad seguros, y la respuesta económica y operativa, incluyendo historial, límites contractuales y cualquier programa de cobertura o reembolso, con sus exclusiones claramente definidas.

5. Resiliencia de infraestructura y continuidad de negocio

La resiliencia no consiste en decir que hay “backup” o “alta disponibilidad”. Consiste en reducir puntos únicos de fallo y demostrar que la operación puede recuperarse sin improvisación. Para una institución, la pregunta clave es qué ocurre cuando falla un proveedor crítico, una región, un componente de red o un elemento de firma.

Eso exige revisar diversidad geográfica y de proveedores, segmentación, protección de endpoints, dependencias de terceros, estrategia de copias de seguridad y pruebas periódicas de recuperación. Sin ejercicios reales de continuidad, la resiliencia es solo una promesa.

6. Reporting, compliance y capacidad de auditoría

Una institución no solo necesita que el proveedor opere bien. Necesita poder demostrar qué ocurrió, cuándo ocurrió, qué impacto tuvo y cómo se gestionó. Eso afecta a conciliación, auditoría interna, reporting a clientes, supervisión de riesgos y relación con terceros como custodios o equipos de compliance.

Aquí es donde un proveedor realmente institucional se diferencia de uno pensado para retail. No porque tenga más marketing, sino porque puede documentar mejor su operación.

7. Aislamiento operativo e infraestructura dedicada

No todas las instituciones necesitan un despliegue totalmente exclusivo, pero muchas sí exigen algún nivel de segregación técnica u operativa. La cuestión no es “tener un nodo propio” por sí mismo, sino reducir dependencias innecesarias y adaptar la arquitectura a requisitos de seguridad, custodia, auditoría o gobierno interno.

También conviene distinguir entre aislamiento real y simple personalización comercial. Una experiencia white-label no equivale a una infraestructura efectivamente segmentada. Desde una perspectiva institucional, importa saber qué se aísla exactamente: infraestructura, red, accesos, secretos, monitorización y operación.

8. Gobernanza: seguimiento del protocolo y madurez operativa

Para una institución, no basta con que un proveedor participe en el ecosistema. También es relevante que demuestre un seguimiento constante de la evolución del protocolo: actualizaciones técnicas, cambios en la estructura económica, decisiones de gobernanza y cambios en la hoja de ruta que puedan afectar al staking, al riesgo operativo o al modelo de servicio.

Un operador que está al día no solo entiende mejor la red que valida; también está en mejor posición para anticipar cambios, adaptar su infraestructura con tiempo y acompañar al cliente en momentos relevantes para la operación.

Esto no significa valorar solo su visibilidad pública, sino su capacidad real para seguir la evolución del protocolo y traducirla en preparación técnica, criterios de riesgo y comunicación clara hacia clientes institucionales.

9. Soporte, SLA y gestión de incidentes

Una relación institucional exige algo más que una integración inicial. Debe haber canales de soporte claros, tiempos de respuesta definidos, procedimientos de escalado y una política de comunicación de incidentes coherente con la criticidad del servicio. También conviene revisar cómo se gestiona la salida: migración, cambio de operador y offboarding ordenado.

Otro factor útil es preguntar qué ocurriría si el proveedor dejara de operar mañana. La calidad de la respuesta suele revelar mucho sobre su madurez. Un operador preparado debería poder explicar cómo se preserva la continuidad del servicio, cómo se comunica la incidencia y cómo se facilita la transición sin fricción innecesaria.

10. Modelo de servicio y delimitación clara de responsabilidades

En staking institucional, no todo el riesgo está en la infraestructura. También importa saber quién controla realmente qué: fondos, claves de firma, credenciales de retirada, parámetros de recompensa, procesos de salida y autorizaciones operativas. Esa delimitación cambia según la red, el custodio y el modelo de integración.

Por eso no basta con hablar de “custodia” o “no custodia” en abstracto. La due diligence debe aterrizar el flujo operativo y contractual: qué hace el operador, qué conserva el cliente, qué controla el custodio y qué puntos exigen autorización conjunta o segregación adicional.

Conclusión

Elegir un proveedor institucional de staking no consiste en encontrar la comisión más baja, sino en seleccionar un operador capaz de sostener el servicio con seguridad, disciplina operativa y evidencias verificables. La mejor decisión suele surgir de combinar análisis técnico, revisión documental y una conversación franca sobre límites, supuestos y responsabilidades.

Una due diligence bien hecha no elimina el riesgo, pero sí reduce la probabilidad de delegar capital en un operador que no pueda explicar, o demostrar, cómo trabaja cuando realmente importa.

Si buscas construir una estrategia de staking realmente segura, nuestro equipo puede ayudarte. Contacta con nosotros para diseñar una solución basada en una verdadera gestión de riesgos institucional.

¿Te gusta este artículo?

¡Compártelo con tus amigos!

Autor/a

Fátima Pereira

Índice

1. Estructura económica y alineación de incentivos
2. Performance operativa: mide la participación efectiva, no solo uptime
3. Seguridad: protocolo sólido no equivale a operador sólido
4. Slashing, penalizaciones e inactividad: riesgos distintos, respuestas distintas
5. Resiliencia de infraestructura y continuidad de negocio
6. Reporting, compliance y capacidad de auditoría
7. Aislamiento operativo e infraestructura dedicada
8. Gobernanza: seguimiento del protocolo y madurez operativa
9. Soporte, SLA y gestión de incidentes
10. Modelo de servicio y delimitación clara de responsabilidades

Artículos destacados

¡Suscríbete a nuestra newsletter!

Suscríbete para seguir de cerca las últimas novedades y anuncios de Stakely. Entérate antes que nadie de nuevas funciones, nuevas redes que validaremos y accede a los mejores consejos para optimizar tu staking

© Stakely 2026 | Stakely, S.L. | NIF B72551682

C/Ferraz 2, 2º Izq, 28008, Madrid, España