La tokenización de activos del mundo real (RWA, por sus siglas en inglés) ha dejado de ser una promesa experimental. A mediados de 2026, el valor distribuido en RWA ronda ya los 26.000 millones de dólares, repartidos en más de treinta redes distintas. Inmuebles, bonos, deuda privada, materias primas: todo lo que antes vivía en un registro notarial o en un depósito bancario empieza a tener una representación digital negociable en segundos.
Pero esa promesa de liquidez instantánea esconde una pregunta que la mayoría de emisores prefiere no hacerse en voz alta: cuando algo falla, ¿quién responde? Y sobre todo, ¿falla el activo, el token, o el puente entre ambos?
El problema de fondo: el token no es el activo
En un protocolo DeFi convencional, el contrato inteligente es el producto. Se audita el código, se aseguran las claves privadas y, en gran medida, el sistema se sostiene solo. Con los RWA la situación es distinta: el token en cadena es solo una reclamación sobre algo que existe fuera de ella —un bono en la bóveda de un custodio, un préstamo en el balance de un deudor, una escritura en un registro de la propiedad—. La superficie de ataque ya no es solo el código Solidity. Ahora incluye documentos legales, custodios, oráculos y flujos de aprobación humana que ninguna auditoría de contratos inteligentes está diseñada para revisar.
Esta brecha entre lo técnico y lo legal es precisamente el terreno donde el arbitraje debería jugar un papel central, y donde hoy existe más incertidumbre que certezas.
Dos maneras distintas de que el sistema falle
Vale la pena distinguir dos tipos de fallos, porque las respuestas —técnicas, legales y de responsabilidad— son completamente diferentes.
Cuando falla el oráculo. En febrero de 2026, el protocolo de préstamos Moonwell sufrió una configuración incorrecta en uno de sus oráculos desplegados en Base: el feed reportaba el precio de cbETH usando la tasa cruda cbETH/ETH sin multiplicarla por el precio de ETH en dólares, valorando el activo en 1,12 dólares en lugar de sus aproximadamente 2.200 dólares reales. Bots de liquidación drenaron más de mil cbETH en cuestión de minutos, generando pérdidas de 1,78 millones de dólares. No fue un hackeo en el sentido clásico —nadie explotó una vulnerabilidad de reentrancy ni robó una clave privada—: fue un dato de precio incorrecto que el contrato ejecutó exactamente como estaba programado para hacer. El «código como ley» funcionó a la perfección; el problema es que la ley estaba mal escrita.
Cuando falla el activo subyacente, no el código. El caso de RealT, la plataforma que tokenizó unas 700 viviendas de alquiler mayoritariamente en Detroit por un valor cercano a 140 millones de dólares, es el ejemplo inverso y quizá más instructivo. En julio de 2026 la plataforma entró en liquidación voluntaria con apenas 640.000 dólares en depósito frente a entre 14.000 y 22.000 inversores afectados. Lo relevante no es un exploit: la estructura legal y técnica funcionó exactamente como se diseñó durante todo el proceso. El problema fue que decenas de propiedades quedaron vacías, con impuestos, facturas de agua y multas por deterioro sin pagar, hasta que la ciudad de Detroit presentó una de las mayores demandas de su historia por incumplimiento de normativa urbana. Un tribunal obligó a que las rentas de los inquilinos fueran directamente a una cuenta de depósito en garantía, y meses después la propia plataforma reconoció que «el modelo ya no funciona». El token nunca fue hackeado. El activo simplemente dejó de generar el valor que el token prometía representar.
Por qué esto es, en el fondo, un problema de responsabilidad y no solo de código
Ambos casos ilustran el mismo vacío desde ángulos opuestos: la auditoría de un contrato inteligente puede certificar que el código hace lo que dice que hace, pero no puede certificar que lo que dice representar sea cierto, ni que quien lo mantiene tenga capacidad —o incentivos— para sostenerlo.
Cuando el oráculo de Moonwell falló, ¿quién debía responder: el equipo que desplegó el wrapper, el proveedor del feed, o la gobernanza que aprobó el cambio sin una alerta en tiempo real sobre roles administrativos? Cuando RealT colapsó, ¿la responsabilidad recae en el auditor de contratos inteligentes, en el gestor de las propiedades, en el vehículo que emitió los tokens, o en un marco legal que nunca anticipó ese escenario?
Estas no son preguntas que un análisis forense en cadena pueda resolver por sí solo. Son preguntas de responsabilidad contractual, de diligencia debida y, en última instancia, de arbitraje.
Lo que audita hoy un contrato RWA (y lo que se le escapa)
Para entender dónde queda el vacío, ayuda mirar por dentro un contrato RWA típico. La mayoría de los proyectos serios en 2026 construyen sobre estándares como ERC-3643 (también conocido como T-REX). El diseño es, en esencia, un token conectado a otros dos contratos: un Registro de Identidad y un Módulo de Cumplimiento. Antes de que cualquier transferencia se ejecute, el contrato consulta ambos: ¿está el receptor verificado?, ¿cumple la operación con las restricciones regulatorias del emisor? Solo entonces el traspaso se completa.
Es una arquitectura sólida para resolver un problema muy concreto —impedir que un token de valores llegue a manos no autorizadas—, y una auditoría de seguridad puede verificar con bastante certeza que esa lógica de permisos funciona como se espera. Pero fíjese en todo lo que ese perímetro deja fuera: el registro de identidad certifica quién puede tener el token, no si el activo que representa sigue existiendo o conservando su valor. El módulo de cumplimiento verifica reglas de transferencia, no si el custodio del bono ha dejado de pagar, si el inmueble está ocupado ilegalmente, o si el gestor del fondo ha desviado los fondos.
Esa capa —la que conecta la ficción jurídica del token con la realidad física o financiera del activo— normalmente descansa en un tercero cuya solvencia y buena fe ninguna auditoría de Solidity puede certificar.
Aquí conviene ser preciso con el vocabulario, porque en el sector se mezclan con demasiada facilidad tres cosas distintas: la seguridad del código (¿tiene el contrato una vulnerabilidad explotable?), la seguridad operativa (¿están las claves de administración protegidas con multifirma y bloqueo temporal, o puede una sola persona pausar o vaciar el contrato?) y la integridad del vínculo legal-técnico (¿lo que dice el folleto que el inversor posee coincide con lo que el contrato inteligente efectivamente le da derecho a reclamar?).
Un informe de auditoría que solo cubre la primera capa —que es, hoy, la norma en el mercado— puede dar una falsa sensación de seguridad completa a inversores y, potencialmente, a un tribunal arbitral que no tenga el contexto técnico para distinguir entre las tres.
El terreno regulatorio, en movimiento pero fragmentado
La respuesta regulatoria va, como suele pasar, un paso por detrás de la innovación, y el resultado es un mosaico difícil de navegar incluso para equipos con buena fe.
En la Unión Europea conviene empezar deshaciendo una confusión frecuente. El Reglamento (UE) 2023/1114, MiCA, no está pendiente de entrar en vigor: es plenamente aplicable desde 2024, y en España el periodo transitorio para los proveedores que ya operaban terminó el 1 de julio de 2026. Lo que sigue abierto no es su aplicación, sino su revisión, cuya consulta pública cerró el 30 de septiembre de 2026.
Y hay un matiz que afecta de lleno a los RWA. MiCA regula a los proveedores de servicios de criptoactivos —custodia y administración incluidas— y la emisión de determinadas categorías de criptoactivos, pero deja fuera de su ámbito los tokens que, por su configuración, sean instrumentos financieros: esos quedan bajo MiFID II y, en su caso, bajo el régimen piloto de infraestructuras de mercado basadas en tecnología de registro distribuido.
Para un inmueble o una deuda tokenizados, determinar en cuál de los dos lados cae el token es la primera pregunta que hay que responder, y de ella depende todo lo demás: qué autorización se necesita, qué obligaciones de custodia se aplican y ante quién responde el emisor.
Fuera de la Unión, el mosaico se amplía. En Oriente Medio, la Autoridad Regulatoria de Activos Virtuales de Dubái y el DIFC han impulsado iniciativas específicas de tokenización inmobiliaria que incluyen la representación de títulos de propiedad en cadena. Singapur, por su parte, ha avanzado con el Proyecto Guardian hasta publicar guías operativas.
El problema no es la falta de marcos, sino su fragmentación. Un token inmobiliario legal para un inversor en Singapur puede ser inaccesible —o directamente ilegal— para uno en Francia, y las restricciones de transferencia codificadas en el contrato no siempre reflejan con precisión la ley de cada jurisdicción donde reside cada tenedor. La ejecución transfronteriza de los derechos de los tenedores de tokens sigue, en la práctica, prácticamente sin poner a prueba en los tribunales.
Este es, precisamente, el vacío que el arbitraje institucional está mejor posicionado para llenar que la litigación tradicional: un mecanismo neutral, elegido de antemano por las partes, que no dependa de decidir primero en qué jurisdicción se litiga.
Una recomendación práctica
La industria RWA está adoptando cada vez más estándares que conectan el contrato del token con un registro de identidad y un módulo de cumplimiento normativo antes de cada transferencia. Es un paso necesario, pero insuficiente si se trata como una casilla técnica más que marcar.
La auditoría de seguridad de un proyecto RWA debería integrarse en el propio proceso de diligencia legal previo a la emisión —no como un sello opcional que tranquiliza a los inversores, sino como una pieza más del marco de responsabilidad que se define en el folleto—. Eso implica auditar no solo el contrato, sino la arquitectura de oráculos, los roles administrativos con privilegios y si están protegidos con multifirma y bloqueos temporales, y sobre todo dejar por escrito qué ocurre —y quién responde— cuando el activo real y su representación en cadena dejan de coincidir.
En términos muy concretos, esto se traduce en cláusulas de arbitraje que ya no pueden limitarse a la fórmula genérica de «cualquier disputa se resolverá mediante arbitraje». Deberían especificar, como mínimo, tres cosas: qué informes técnicos —auditorías, registros de oráculos, trazas de gobernanza en cadena— se aceptan como prueba y bajo qué estándar de autenticidad; qué ocurre cuando la disputa involucra tanto una falla de código como un incumplimiento del custodio del activo subyacente, es decir, si se trata como una sola disputa o como dos procedimientos paralelos; y quién asume el coste de un peritaje técnico cuando ninguna de las partes tiene, de entrada, la capacidad de leer o verificar lo que ocurrió en la cadena.
Sin esa especificidad, el arbitraje corre el riesgo de heredar exactamente la misma ambigüedad que hoy existe en el terreno técnico.
Ninguna auditoría sustituye un marco de responsabilidad
Mientras esa integración —entre auditoría técnica, diligencia legal y cláusulas de arbitraje bien diseñadas— no sea la norma, cada nuevo RealT o cada nuevo incidente de oráculo seguirá planteando la misma pregunta incómoda:
tokenizamos el activo, ¿pero tokenizamos también la responsabilidad?
Fuentes
coinpaprika.com (análisis de RealT, septiembre de 2026); codezeros.com y getfailsafe.com (incidente de Moonwell, febrero de 2026); documentación pública sobre el estándar ERC-3643.
