Infraestructura RWA con acceso controlado en XRPL

Tokenizar un activo real para una institución regulada tiene menos que ver con emitir un token y más con controlar quién puede tenerlo, demostrar por qué puede tenerlo y hacer ambas cosas sin publicar datos personales en un ledger público. Desde febrero de 2026, la mainnet del XRP Ledger cuenta con tres piezas nativas que responden exactamente a esas preguntas: Credentials, Permissioned Domains y Multi-Purpose Tokens (MPT).

Este artículo explica qué hace cada primitiva, cómo encajan entre sí y, igual de importante, qué no hacen todavía hoy en mainnet.

Por qué aquí importan más las primitivas que los smart contracts

En muchas cadenas, las reglas de elegibilidad de un activo tokenizado viven en código de contrato propio que cada emisor escribe, audita y mantiene por separado. En el XRP Ledger esas reglas forman parte del propio protocolo y son idénticas para todos los emisores.

Para una institución, eso cambia el perfil de riesgo. En lugar de confiar en un contrato a medida, un banco, una fiduciaria o un SPV configura flags y objetos del ledger cuyo comportamiento está especificado en estándares públicos (XLS-33, XLS-70 y XLS-80^[7][8][9]) y documentado en xrpl.org.

Los tres amendments están activos en mainnet. Según las transacciones EnableAmendment registradas en el ledger, Credentials se activó el 4 de septiembre de 2025, MPTokensV1 el 1 de octubre de 2025 y PermissionedDomains el 4 de febrero de 2026. Confirmamos los tres como activos en el ledger validado de mainnet 107308442 el 29 de septiembre de 2026.

Credentials: estatus verificable sin publicar datos personales

Una credencial de XRPL es, en palabras de la documentación, una declaración firmada "que puede almacenarse en el ledger y puede acreditar la identidad, el estatus legal u otro estatus de un usuario"^[1]. Cada credencial vincula tres elementos: una cuenta emisora, una cuenta sujeto y un tipo de credencial que define el emisor, además de una expiración opcional^[2].

El ciclo de vida es sencillo:

1. El emisor crea la credencial con una transacción CredentialCreate; la cuenta que la envía es el emisor^[2].
2. El sujeto la acepta con CredentialAccept. Hasta entonces la credencial no es válida^[2].
3. Cualquiera de las dos partes puede eliminarla después: el emisor para revocarla o el titular para descartarla^[1].

La propiedad de diseño clave para las instituciones es lo que queda fuera del ledger. Los documentos que un usuario aporta para ser verificado pueden incluir información privada, pero esa información "nunca se publica ni se almacena en la blockchain"^[1]. El ledger solo registra que un emisor concreto respalda una cuenta concreta bajo un tipo de credencial concreto, opcionalmente con fecha de expiración.

Lo que una credencial significa no lo define el protocolo. Los requisitos que hay detrás "son abiertos y los definen sus emisores"^[1]. Por eso importa tanto la identidad del emisor: una credencial es exactamente tan confiable como la institución que la firmó.

Permissioned Domains: una regla, muchas credenciales

Un permissioned domain es un objeto del ledger que responde a una sola pregunta: ¿qué credenciales dan acceso? Contiene una lista de una a diez credenciales aceptadas, cada una descrita por emisor y tipo, y "cualquier cuenta que tenga al menos una credencial coincidente obtiene acceso al dominio automáticamente"^[3].

Tres detalles merecen atención:

• Sin paso de alta. Los usuarios no solicitan entrar en un dominio. Basta con tener una credencial aceptada y no expirada^[3].
• Los dominios no hacen nada por sí solos. Son una lista de acceso pensada para que la consuman otras funciones, como los DEX permisionados y los protocolos de préstamo^[3].
• Dependen de Credentials. El amendment PermissionedDomains solo es utilizable junto con el amendment Credentials^[3][9].

Esto compone bien entre instituciones. Un dominio puede aceptar credenciales de varios emisores, de modo que una fiduciaria puede reconocer las verificaciones de inversores realizadas por otra sin que ninguna comparta los expedientes de fondo.

Multi-Purpose Tokens: el activo en sí

Los MPT son "una forma de token fungible en el XRP Ledger", diseñados "a partir de lo aprendido con los tokens de trust line"^[4]. Para un inmueble tokenizado, una participación de fondo o una nota, el objeto de emisión incorpora los controles que una institución espera^[5]:

Una emisión también puede llevar hasta 1024 bytes de metadatos, y el estándar XLS-89 recomienda un formato para ellos, que incluye una subclase de activo para bienes raíces^[5][4].

Estos flags se eligen al crear la emisión. Cambiarlos después depende del amendment DynamicMPT, que no está activo en mainnet (ver más abajo), así que la configuración merece la misma revisión que los documentos legales que respaldan el activo.

Cómo encajan las tres

El patrón que surge para activos reales regulados es este:

1. Una institución —en el modelo de Fractiona, cada tenant, desde una wallet que controla el propio tenant— emite una credencial a la cuenta de un inversor tras completar su propia verificación fuera del ledger.
2. El inversor acepta la credencial en su propia wallet.
3. Un permissioned domain enumera qué emisores y tipos de credencial se aceptan.
4. El activo se emite como MPT con lsfMPTRequireAuth, de modo que tenerlo requiere autorización explícita, y el emisor puede basar esa decisión en las credenciales on-ledger del inversor.

La arquitectura objetivo de Fractiona sigue la misma separación: las transacciones que mueven valor o cambian derechos las prepara la plataforma sin firmar y las firma el titular de la cuenta en su propia wallet (Xaman). Las credenciales las emite la institución tenant desde su propia wallet; cuando un tenant delega esa operación, Fractiona actúa solo como relayer técnico, nunca como principal.

Qué no está activo todavía en mainnet

La precisión sobre la capacidad actual es parte de la ingeniería de grado institucional. A la fecha del ledger consultado:

• No se pueden negociar MPT en el DEX. La propia documentación de MPT indica que negociar MPT en el DEX "no está implementado actualmente"^[4], y el amendment MPTokensV2 sigue figurando como en desarrollo^[6].
• Todavía no se puede vincular un MPT de forma nativa a un permissioned domain. El campo DomainID de una emisión requiere además el amendment SingleAssetVault^[5][10], que no está activo en mainnet.
• Modificar la configuración de un MPT después de emitirlo forma parte del amendment DynamicMPT^[4], que tampoco está activo en mainnet.

Mientras esos amendments no se activen, el control de acceso de un MPT se apoya en lsfMPTRequireAuth más las decisiones de autorización del emisor, informadas por credenciales.

Conclusiones

• Las credenciales dan a las instituciones una prueba de estatus portable y revocable que mantiene los datos personales fuera de la cadena.
• Los permissioned domains convierten "en qué emisores confiamos" en un único objeto del ledger.
• Los MPT transportan el activo con controles a nivel de protocolo: autorización, bloqueo, clawback y límites de emisión.
• Cada primitiva está activa hoy en la mainnet de XRPL; la negociación de MPT en el DEX y los MPT restringidos por dominio de forma nativa siguen siendo trabajo futuro.

En Fractiona estamos construyendo infraestructura no custodial sobre estas primitivas, diseñada para que cada institución conserve sus propias llaves, emita sus propias credenciales y decida sus propias reglas de acceso.