Qué cambia cuando el activo es un RWA tokenizado, no simple ETH
La cuestión de la custodia parece idéntica a primera vista: tienes una clave privada, quieres mantenerla segura y quieres firmar transacciones. Los activos del mundo real tokenizados (RWA), como OUSG de ONDO, BUIDL de BlackRock o los productos de tesorería denominados en MNT de Mantle, no cambian la criptografía. Lo que cambian es la carga de trabajo que se coloca encima de ella.
Un fondo monetario tokenizado o un fondo de tesorería suele emitir y reembolsar según un calendario. OUSG, por ejemplo, liquida reembolsos en T+1. BUIDL distribuye rendimiento de forma continua y admite transferencias a nivel de token, además del reembolso a través del emisor. Ese ritmo significa que un equipo de tesorería no puede dejar una única transacción sin firmar durante una semana como puede hacerlo un holder de BTC a largo plazo. La cola de firmantes tiene que despejarse dentro de un día hábil, a menudo dentro de una hora si se está cerrando una ventana de reembolso.
El segundo cambio es la auditabilidad. Con ETH estándar, el registro on-chain suele bastar para un equipo financiero interno. Con un RWA regulado, la parte off-chain tiene auditores, agentes de transferencia y, a veces, un regulador que exigirá pruebas de que un reembolso fue autorizado por personas identificadas bajo una política documentada. Ese requisito remodela la custodia, porque "quién firmó" importa tanto como "la firma es válida".
El tercer cambio es que la clave operativa rara vez es la única clave. La mayoría de los productos RWA separan una clave de políticas, una clave de operaciones diarias y una clave de guardián, y cada una vive bajo controles distintos. Tratarlo como un único problema de firma es donde muchos diseños de tesorería se equivocan.
La latencia operativa frente al equilibrio del coste para el atacante
La custodia no es una sola decisión, es un equilibrio entre dos cifras. La primera es cuánto se tarda en producir una firma válida cuando el negocio la necesita. La segunda es cuánto tiene que gastar un atacante, o cuántos fallos independientes tiene que provocar, antes de poder producir una firma fraudulenta.
El almacenamiento en frío, en sentido estricto, eleva mucho la cifra de coste para el atacante y también la de latencia. La clave vive en un dispositivo que nunca ha tocado internet, idealmente en una cámara acorazada, y firmar implica recuperarla físicamente. Eso es magnífico para una tesorería de BTC a largo plazo, y pésimo para un fondo que debe reembolsar ONDO o BUIDL cada día hábil. El coste de ser lento no es abstracto: las ventanas de reembolso perdidas pueden activar comisiones de penalización, colocarte en la cola del siguiente ciclo o, en casos extremos, bloquear la posición hasta el siguiente corte del emisor.
Multisig desplaza el equilibrio distribuyendo la confianza entre firmantes y dispositivos. Una configuración 3 de 5 significa que un atacante necesita comprometer a tres firmantes independientes, lo cual es significativamente más difícil que comprometer a uno, mientras que la latencia es la velocidad de tus tres firmantes más rápidos. El problema es que "independientes" carga con mucho peso. Si tres de tus firmantes están gestionados por la misma persona, en el mismo sistema operativo y con el mismo esquema de copia de seguridad, el multisig no te ha comprado la dificultad equivalente a tres atacantes. Te ha comprado una.
MPC, es decir, esquemas de firma por umbral como GG20, GG20+, Lindell17 o las implementaciones FROST más recientes, traslada el cálculo del coste para el atacante al propio protocolo. La clave de firma nunca existe en un solo lugar. Cada participante conserva un fragmento, y un umbral de ellos produce conjuntamente una firma sin reconstruir nunca la clave completa. La latencia puede ser muy baja, comparable a la de un monedero caliente de un solo firmante, y el atacante tiene que comprometer a un umbral de participantes dentro de una ventana de firma estrecha.
Lo que MPC también hace, y esta es la parte de la que no se habla lo suficiente, es reducir el coste de los errores operativos. Con multisig, perder un firmante es molesto, pero recuperable siempre que sigas por encima del umbral. Con MPC, la historia de recuperación depende por completo de cómo se generaron los fragmentos, quién los conserva y si el custodio sigue existiendo. Si borras un portátil y el fragmento solo estaba en ese portátil, la política puede ser sencillamente irrecuperable, y el activo queda efectivamente congelado hasta que la ceremonia de fragmentos de clave subyacente pueda volver a ejecutarse con los participantes restantes.
Por qué los custodios institucionales de RWA usan HSM, no monederos hardware de consumo
Un monedero hardware de consumo, ya sea Ledger, Trezor, GridPlus o Keystone, es un pequeño dispositivo con elemento seguro que almacena una seed y firma transacciones sin conexión. Para una posición personal de BTC o una posición de cinco cifras en ETH, es excelente. Para una tesorería que firma operativamente reembolsos en un libro institucional de RWA, las carencias empiezan a acumularse.
La primera carencia es la exportación y clonación de claves. Los monederos hardware están diseñados para que el usuario, no el fabricante del dispositivo, controle la seed. Desde una perspectiva institucional, eso es un pasivo: un empleado que se marcha con la frase semilla y una copia de seguridad en una caja de seguridad es un riesgo de persona clave que no puedes remediar fácilmente. Los custodios institucionales quieren claves que puedan rotar, poner en escrow o destruir según una política escrita, y quieren que ese proceso sea auditable de extremo a extremo.
Para eso sirven los HSM, módulos de seguridad hardware. Dispositivos como AWS CloudHSM, Thales Luna, Utimaco o YubiHSM 2 están validados por FIPS, admiten acceso basado en roles y se integran con motores de políticas que registran cada intento de firma, quién lo inició y bajo qué regla. Las claves nunca salen del dispositivo en texto claro, la rotación de claves es un flujo de trabajo documentado y un auditor puede ver un rastro limpio.
La segunda carencia está relacionada con lo que se firma. Un monedero hardware de consumo te muestra una transacción en una pantalla diminuta y te pide que la apruebes. Un equipo de tesorería que opera con OUSG o BUIDL necesita aplicar políticas antes incluso de que el firmante vea la transacción: límites por activo, contrapartes incluidas en lista blanca, topes diarios de reembolso, doble control para cualquier importe por encima de un umbral. Esa lógica pertenece a un motor de políticas de transacción o a una capa de cuenta inteligente como Safe (antes Gnosis Safe) con módulos, no a una persona mirando una pantalla de 128x64 píxeles.
La tercera carencia es el rendimiento operativo. Un monedero hardware está construido para un uso ocasional, no para las decenas de aprobaciones que puede generar un flujo diario de RWA cuando incluyes barridos de rendimiento, pagos de comisiones, atestaciones de oráculos y asientos de conciliación. La ergonomía se rompe mucho antes que la seguridad.
Escollos de recuperación en multisig que parecen correctos hasta que dejan de serlo
El multisig en ETH se despliega más comúnmente como un monedero Safe (antes Gnosis Safe), con firmantes mantenidos en monederos hardware y una historia de recuperación documentada. En teoría, es robusto. En la práctica, aparecen tres escollos de forma recurrente.
El primero es la homogeneidad de los firmantes. Un 5 de 9 parece seguro hasta que te das cuenta de que los nueve firmantes ejecutan el mismo software de monedero, la misma versión de firmware, el mismo procedimiento de copia de seguridad, y tres de ellos fueron configurados por la misma persona la misma tarde. La seguridad del multisig escala con la independencia de los firmantes. El número 9 es decorativo. El número que importa es el recuento de vectores de compromiso verdaderamente independientes.
El segundo es la disponibilidad de los firmantes. Un multisig solo funciona si puedes alcanzar el umbral. Si tus firmantes son una mezcla de contratistas en tres zonas horarias, un directivo que viaja y un monedero que vive en una cámara acorazada que requiere dos días para acceder, puedes encontrarte sin poder firmar un reembolso de ONDO sensible al tiempo porque tres de tus cinco firmantes más rápidos están en aviones. La solución suele ser una combinación de firmantes fríos y templados, con una política que diga que los firmantes calientes solo pueden aprobar importes pequeños. Eso funciona, pero añade otro multisig que gestionar, y vuelves al problema de la recursión.
El tercero es la custodia de la clave de recuperación. Cada Safe tiene una historia de recuperación, normalmente en función de cómo se generaron los firmantes. Si la recuperación depende de una frase semilla escrita en papel dentro de una caja fuerte, ahora tienes una sola hoja de papel cuyo compromiso da a un atacante un firmante funcional. Si la recuperación depende de recuperación social mediante guardianes, has trasladado la confianza a los guardianes, que quizá no sean quienes crees que son dentro de cinco años. Nada de esto es un obstáculo insalvable, pero cada punto es un lugar donde el 3 de 5 de aspecto impecable se convierte silenciosamente en un 2 de 5 con un firmante en un cajón.
El riesgo de desaparición de participaciones de clave en MPC, en términos sencillos
La característica definitoria de MPC, que la clave completa nunca existe en un solo lugar, es también su riesgo definitorio. La política de firma vive en los participantes, y los participantes pueden desaparecer.
La desaparición del proveedor es el riesgo más citado. Si custodias con Fireblocks, Anchorage, BitGo, Fordefi o un proveedor MPC similar, tus participaciones se dividen entre tú y ellos. Si el proveedor es adquirido, sale del mercado, sufre una interrupción grave o simplemente deja obsoleto tu nivel de servicio, quizá puedas migrar tus activos, pero solo si la herramienta de migración está disponible y tienes tiempo. En el peor de los casos, tú tienes una participación, el proveedor tiene una participación, y el umbral ya no es alcanzable porque el lado del proveedor está desconectado o no está dispuesto.
La pérdida de dispositivos de participantes es el siguiente riesgo. Las participaciones MPC suelen mantenerse en HSM, nodos de firma dedicados o portátiles endurecidos. Cada dispositivo tiene su propia historia de custodia de claves, incluido cómo se respaldan las participaciones y dónde. Pierde dos de esos dispositivos y tendrás un problema de recuperación entre manos, no solo una molestia. La mitigación es la copia de seguridad de participaciones, pero la copia de seguridad de participaciones es en sí misma una decisión de custodia: dónde viven las participaciones de respaldo, quién puede descifrarlas y cómo demuestras a un auditor que ninguna persona por sí sola puede reconstituir la clave a partir de las copias de seguridad.
El riesgo de protocolo e implementación es el tercer riesgo. Los esquemas de firma umbral son criptografía compleja, y las implementaciones han tenido errores. La divulgación de 2022 sobre una vulnerabilidad en ciertas implementaciones de GG20, los hallazgos más recientes en torno a threshold EdDSA y un goteo constante de problemas en SDK de monederos recuerdan que "la clave nunca existe" es una afirmación más fuerte que "la clave nunca existe y el código de firma no tiene errores". Para una operación de tesorería de RWA, el movimiento correcto es exigir auditorías de seguridad independientes de la pila del proveedor MPC y mantener la opción de migrar a un esquema diferente, aunque sea caro.
Un matiz que merece la pena nombrar: la seguridad de MPC es por evento de firma. Una vez que un umbral de participantes firma, la firma es válida para siempre, aunque las participaciones de los participantes se destruyan más tarde. Así que el riesgo de desaparición se refiere a la capacidad de firma futura, no a las firmas pasadas. Ese es el encuadre correcto para llevar a un consejo: no corremos el riesgo de que se falsifique una transacción pasada, corremos el riesgo de no poder operar la posición.
Una pila de custodia práctica para RWA con reembolso diario
Dada la carga de trabajo, una configuración viable para un fondo o una tesorería de protocolo que mantiene RWA tokenizados parece en capas, no pura.
La capa base es un custodio institucional con HSM validados por FIPS para la reserva a largo plazo. Aquí es donde se encuentra la mayor parte de la posición, bajo firma controlada por políticas con separación de roles. Para una asignación en OUSG o BUIDL que no necesita moverse a menudo, este es el lugar adecuado, porque el coste de latencia de entrar en una cámara acorazada se paga rara vez y el coste para el atacante es muy alto.
La capa de trabajo es un Safe multisig o un clúster MPC usado para operaciones rutinarias: pequeños reembolsos, barridos de rendimiento, pagos de comisiones, atestaciones de oráculos. La elección entre multisig y MPC aquí depende del volumen de firmas, la distribución de firmantes y la tolerancia del equipo al riesgo operativo. Multisig es más fácil de auditar y más fácil de recuperar. MPC es más rápido y gestiona mejor volúmenes altos de firma. Muchos equipos usan ambos: un Safe para gobernanza y un clúster MPC más pequeño para ejecución.
La capa de políticas se sitúa por encima de ambas. Un motor de políticas de transacción aplica límites por activo, contratos incluidos en lista blanca, topes diarios y reglas de doble control. Los firmantes no ven transacciones en bruto; ven intenciones preaprobadas, y el motor construye y envía las transacciones reales. Aquí es donde se controla realmente la mayor parte del riesgo operativo, y donde los monederos hardware de consumo se quedan cortos para uso institucional, ya que no pueden aplicar esa política delante del firmante.
La capa de reserva fría es un multisig aislado de la red para gobernanza y cambios de política: cambiar firmantes, rotar claves, actualizar el motor de políticas, sacar grandes importes de la capa de trabajo. La latencia aquí es aceptable porque estos eventos son raros, y el coste para el atacante es muy alto porque las claves viven en una cámara acorazada.
El resumen honesto es que "almacenamiento en frío frente a multisig frente a MPC" es el marco equivocado para RWA institucionales. El marco correcto es qué carga de trabajo va en qué capa, y cuál es la historia de recuperación cuando desaparece una participación, un firmante o un proveedor.
Cómo seguir de forma inteligente la evolución de la custodia de RWA
La custodia de RWA avanza con rapidez porque los productos, los custodios y los reguladores cambian todos a la vez. Hacer un seguimiento manual de los reembolsos de OUSG, los mecanismos de distribución de BUIDL, las migraciones de proveedores de MPC y los avisos sobre firmware de HSM es una batalla perdida. Zippfeed muestra titulares sobre RWA tokenizados con puntuación de sentimiento (bullish, neutral o bearish) y una calificación de importancia, para que puedas centrarte en los eventos que realmente afectan a tu diseño de custodia en lugar de ahogarte en ruido.
TheBlock
CoinDesk
Crypto News
CryptoSlate
