La evolución de la custodia cripto
Wallet-as-a-Service permite gestionar claves criptográficas de forma segura sin el riesgo de pérdida física, conservando toda la funcionalidad para aplicaciones DeFi.
1. Autocustodia: La promesa frente a la realidad operativa
Las criptomonedas se basan en una promesa fundamental: la autocustodia (Self-Custody). Sin intermediarios, sin bancos, sin dependencias. En la práctica, este modelo a menudo fracasa ante los obstáculos operativos.
Perder una clave privada (Private Key) significa perder los activos de forma irreversible. No hay servicio de atención al cliente ni opciones de recuperación. Proteger la frase semilla (Seed Phrase) —la secuencia que da acceso a la wallet— exige salvaguardarla contra pérdidas, incendios, robos y errores humanos.
La solución práctica más común: guardarla en la caja fuerte de un banco. Con ello, la promesa de independencia del sistema bancario termina exactamente donde empezó.
2. Omni-Wallets: Cómo custodian bancos y exchanges
Los bancos y exchanges que ofrecen servicios con criptomonedas resuelven el problema de la custodia mediante las llamadas Omni-Wallets: una wallet compartida para los fondos de todos los clientes, segmentada internamente a nivel contable.
Ventajas:
- Menores costes de transacción (los traspasos internos no requieren transacciones en la blockchain).
- Reducción de la carga operativa.
Riesgo estructural:
Los activos pertenecen al cliente únicamente en los libros contables del proveedor, no en la blockchain. En caso de insolvencia, estos activos pasan a formar parte de la masa concursal.
El caso FTX (Noviembre de 2022):
- Los fondos de los clientes no estaban segregados en la blockchain (On-Chain).
- En el proceso de insolvencia, los criptoactivos se trataron como parte de la masa concursal.
- Los clientes se encontraron a la cola como acreedores.
3. Wallet-as-a-Service: Cómo funciona
Wallet-as-a-Service (WaaS) combina el nivel de seguridad de la custodia institucional con la usabilidad de las aplicaciones descentralizadas. Prescinde de la estructura de Omni-Wallet y no exige autocustodia.
Principio básico (Multi-Party Computation / MPC):
La clave privada nunca existe completa en un solo lugar. Se divide en fragmentos (Key-Shards) almacenados en sistemas separados: en el proveedor, en el usuario y, a veces, en terceros independientes.
Una transacción solo se ejecuta cuando interactúan suficientes fragmentos. Ninguna de las partes puede acceder a los activos por sí sola. Además, la clave nunca llega a reconstruirse; se utiliza exclusivamente para firmar.
Para el usuario, la interfaz es idéntica a la de una wallet convencional. Los protocolos DeFi, contratos inteligentes y transferencias de tokens se pueden utilizar sin restricciones, ya que la firma en la blockchain (On-Chain) es idéntica a la de la autocustodia.
4. Los tres riesgos centrales
4.1. Pérdida de acceso por caída del proveedor
Si el proveedor de WaaS deja de operar, el acceso a los activos depende del proceso de recuperación estipulado por contrato. La pregunta clave: ¿Puede el usuario recuperar el acceso a sus activos independientemente del proveedor?
En muchos proveedores este proceso no está definido, lo que representa el mayor riesgo operativo.
4.2. Insolvencia del proveedor
A diferencia de las Omni-Wallets, en un WaaS con estructura de wallet dedicada, los activos se asignan al usuario en la blockchain. Esto mejora significativamente la posición jurídica en caso de insolvencia.
Sin embargo, no ofrece protección automática. La formulación legal y contractual es más determinante que la propia tecnología.
4.3. Acceso por parte del proveedor
Que se utilice MPC no significa automáticamente que el proveedor carezca de acceso. Según la arquitectura, si el proveedor controla suficientes Key-Shards, teóricamente podría firmar transacciones sin la participación del usuario.
La pregunta relevante: ¿Cuántos fragmentos están en manos del proveedor y cuántos controla el usuario o un tercero independiente?
5. Resumen del mercado
La siguiente tabla compara a los proveedores no solo por su público objetivo, sino también por libertades operativas, viabilidad DeFi y comportamiento ante ataques.
| Criterio | Fireblocks | Tangany | Dfns / Web3Auth | Privy |
|---|---|---|---|---|
| Público objetivo | Gestores de activos, bancos | Actores regulados en la UE | Desarrolladores, Fintechs | Consumidores, usuarios dApp |
| Uso de DeFi | Sí, vía Policy Engine | Limitado (enfoque en custodia) | Sí, totalmente integrable | Sí, para interacciones básicas |
| Estructura Wallet | Dedicada por usuario | Dedicada por usuario | Configurable | Específica por usuario |
| Control de claves | MPC, fragmentos distribuidos | El proveedor custodia las claves | MPC, fragmentos configurables | Inicio de sesión social, clave en el proveedor |
| Protección contra ingeniería social | Policy Engine, listas blancas, retraso temporal | Procesos regulados, revisión manual | Depende de la implementación | Baja (inicio de sesión social como vector de ataque) |
| Comportamiento ante hackeos | Fragmentos en sistemas separados, sin punto de acceso único | Marco regulado, responsabilidad del proveedor | Variable según configuración | Mayor riesgo por autenticación centralizada |
Actores institucionales
Fireblocks es el líder del mercado para gestores de activos, bancos y exchanges. Arquitectura MPC, Policy Engine para reglas de transacción y certificación SOC 2 Type II. Exige altos volúmenes mínimos.
Los protocolos DeFi pueden utilizarse a través del Policy Engine. Las transacciones se protegen mediante listas blancas (direcciones destinatarias preaprobadas), límites de importe y procesos de aprobación en varias fases. En caso de ataques de ingeniería social, la combinación de Policy Engine y Key-Shards distribuidos impide transacciones no autorizadas.
SOC 2 Type II es un estándar de auditoría del Instituto Americano de Contadores Públicos Certificados (AICPA). Confirma que un proveedor cumple de forma demostrable con los controles de seguridad de datos, disponibilidad y confidencialidad durante un período mínimo de seis meses. A diferencia del Type I, que solo verifica la existencia de controles en un momento dado, el Type II evalúa su eficacia real en el día a día.
Custodia regulada con componente WaaS
Tangany posee una licencia de criptocustodia y está regulada como proveedor de servicios financieros. Relevante para actores europeos que deben garantizar el cumplimiento de MiCA (la normativa de la UE para criptoactivos).
El uso de DeFi es limitado. Su enfoque se centra en la custodia segura y la transferencia regulada, no en la interacción con contratos inteligentes. Ante un ataque de ingeniería social, entran en juego procesos regulados con revisión manual de transacciones. En caso de hackeo, el proveedor asume la responsabilidad en el marco de sus obligaciones regulatorias.
Fintech y desarrolladores
Dfns y Web3Auth se dirigen a empresas que integran WaaS en sus propios productos. Relevantes para la creación de infraestructura propia de wallets, no tanto para el uso interno directo.
El uso de DeFi es completamente integrable. El nivel de seguridad depende de la implementación. La responsabilidad de protegerse contra la ingeniería social y la resistencia frente a hackeos recae en la empresa integradora, no en el proveedor WaaS. Sin un Policy Engine propio y reglas de transacción, el riesgo es mayor.
Segmento de consumidores
Privy se dirige a usuarios finales de aplicaciones descentralizadas (dApps) sin formación técnica. No supone un estándar institucional, pero es útil para entender el espectro del mercado.
Se puede utilizar DeFi para interacciones sencillas. La autenticación se realiza mediante inicio de sesión social (correo electrónico, Google, Apple). Esto es cómodo, pero convierte a la ingeniería social en el principal vector de riesgo: quien consiga acceder a la cuenta de inicio de sesión, podría ejecutar transacciones. El control de las claves recae en gran medida en el proveedor.
6. Lista de diligencia debida (Due Diligence) para actores financieros
Antes de firmar un contrato con un proveedor WaaS, deben comprobarse cinco puntos:
- Estructura de la Wallet: ¿Wallet dedicada por usuario o Omni-Wallet? ¿Se puede verificar en la blockchain?
- Control de claves: ¿Cuántos fragmentos controla el proveedor y cuántos el usuario? ¿Puede el proveedor firmar por sí solo?
- Plan de recuperación (Recovery): ¿Qué ocurre en caso de insolvencia o caída del servicio? ¿Está el proceso regulado por contrato y es técnicamente ejecutable sin la participación del proveedor?
- Estatus regulatorio: ¿Está el proveedor licenciado como custodio o solo es un proveedor tecnológico? La distinción es relevante para la responsabilidad legal.
- Auditoría: SOC 2 Type II como estándar mínimo. ¿Se han realizado pruebas de penetración a cargo de terceros independientes?
7. Conclusión
La autocustodia y la custodia basada en Omni-Wallets representan dos extremos. WaaS se sitúa en medio, ofreciendo ventajas sobre ambos modelos, pero sin sus exigencias absolutas.
Ningún proveedor elimina por completo el riesgo de contraparte. Un sistema WaaS estructurado de forma limpia —con wallet dedicada, Key-Shard independiente y plan de recuperación contractual— es actualmente la solución operativa más sensata para los actores profesionales.
Es preferible a guardar la frase semilla en la caja fuerte de un banco. Y es estructuralmente más seguro que confiar a ciegas en una Omni-Wallet.
Las cuestiones verdaderamente decisivas no son de naturaleza técnica. Están escritas en el contrato.
