Building permissioned RWA infrastructure on XRPL

How three live XRPL mainnet primitives let institutions control who holds a tokenized asset without putting personal data on-chain, and what is not live yet.

Tokenizing a real-world asset for a regulated institution is less about minting a token and more about controlling who can hold it, proving why they can hold it, and doing both without putting personal data on a public ledger. Since February 2026, the XRP Ledger mainnet has three native building blocks that address exactly those questions: Credentials, Permissioned Domains and Multi-Purpose Tokens (MPT).

This article explains what each primitive does, how they fit together, and — just as important — what they do not do yet on mainnet today.

Why primitives matter more than smart contracts here

On many chains, eligibility rules for a tokenized asset live in custom contract code that every issuer writes, audits and maintains separately. On the XRP Ledger these rules are part of the protocol itself, identical for every issuer.

For an institution, that changes the risk profile. Instead of trusting a bespoke contract, a bank, trust company or SPV configures flags and ledger objects whose behaviour is specified in public standards (XLS-33, XLS-70 and XLS-80^[7]^[8]^[9]) and documented on xrpl.org.

All three amendments are live on mainnet. According to the EnableAmendment transactions recorded on the ledger, Credentials was enabled on 4 September 2025, MPTokensV1 on 1 October 2025 and PermissionedDomains on 4 February 2026. We confirmed all three as enabled on the validated mainnet ledger 107308442 on 29 September 2026.

Credentials: verifiable status without publishing personal data

An XRPL credential is, in the words of the documentation, a signed statement "that can be stored in the ledger and can attest to a user's identity, legal status, or other status"^[1]. Each credential links three things: an issuer account, a subject account and a credential type that the issuer defines, plus an optional expiration^[2].

The lifecycle is simple:

The issuer creates the credential with a CredentialCreate transaction; the sending account is the issuer^[2].
The subject accepts it with CredentialAccept. Until then the credential is not valid^[2].
Either side can remove it later: the issuer to revoke it, or the holder to discard it^[1].

The key design property for institutions is what stays off-ledger. The documents a user provides to be verified can include private information, but "this information is never published or stored on the blockchain"^[1]. The ledger only records that a given issuer vouches for a given account under a given credential type, optionally with an expiration.

What a credential means is not defined by the protocol. The qualifications behind it "are open-ended, and defined by their issuers"^[1]. That is why the identity of the issuer matters so much: a credential is exactly as trustworthy as the institution that signed it.

Permissioned Domains: one rule, many credentials

A permissioned domain is a ledger object that answers one question: which credentials grant access? It holds a list of one to ten accepted credentials, each described by issuer and credential type, and "any account that holds at least one matching credential automatically gains access to the domain"^[3].

Three details are worth highlighting:

No enrolment step. Users do not apply to join a domain. Holding an accepted, unexpired credential is enough^[3].
Domains do nothing on their own. They are an access list designed to be consumed by other features, such as permissioned DEXes and lending protocols^[3].
They depend on Credentials. The PermissionedDomains amendment is only usable together with the Credentials amendment^[3]^[9].

This composes well across institutions. A domain can accept credentials from several issuers, so one trust company can recognise investor checks performed by another without either of them sharing the underlying files.

Multi-Purpose Tokens: the asset itself

MPTs are "a form of fungible token on the XRP Ledger", designed "based on lessons learned from trust line tokens"^[4]. For a tokenized property, a fund share or a note, the issuance object carries the controls an institution expects^[5]:

Setting	What it controls
`lsfMPTRequireAuth`	Individual holders must be authorized by the issuer before they can hold the token.
`lsfMPTCanLock`	The issuer can lock an individual balance or all balances.
`lsfMPTCanClawback`	The issuer can claw back value from individual holders.
`lsfMPTCanTransfer`	Without it, holders can only send tokens back to the issuer.
`MaximumAmount`	Hard cap on the amount that can ever be issued.
`AssetScale`	Where the decimal point sits; 0 means the token cannot be split below one unit.
`TransferFee`	Issuer fee on transfers, from 0 to 50,000 in tenths of a basis point (up to 50%).

An issuance can also carry up to 1024 bytes of metadata, and the XLS-89 standard recommends a format for it, including an asset subclass for real estate^[5]^[4].

These flags are chosen when the issuance is created. Changing them afterwards depends on the DynamicMPT amendment, which is not enabled on mainnet (see below), so the configuration deserves the same review as the legal documents behind the asset.

How the three fit together

The pattern that emerges for regulated real-world assets looks like this:

Credential issuer, holder account, permissioned domain and MPT issuance, connected by the transactions described in the article — An institution issues credentials, a domain decides which credentials count, and an MPT issuance with RequireAuth decides who can hold the asset.

An institution — in Fractiona's model, each tenant, from a wallet the tenant controls — issues a credential to an investor account after completing its own verification off-ledger.
The investor accepts the credential in their own wallet.
A permissioned domain lists which issuers and credential types are accepted.
The asset is issued as an MPT with lsfMPTRequireAuth, so holding it requires explicit authorization, and the issuer can base that decision on the investor's on-ledger credentials.

Fractiona's target architecture follows the same separation: transactions that move value or change rights are prepared unsigned by the platform and signed by the account owner in their own wallet (Xaman). Credentials are issued by the tenant institution from its own wallet; when a tenant delegates that operation, Fractiona acts only as a technical relayer, never as principal.

What is not live on mainnet yet

Precision about current capability is part of institutional-grade engineering. As of the ledger we checked:

MPT trading on the DEX is not available. The MPT documentation itself notes that trading MPTs in the DEX "is not currently implemented"^[4], and the MPTokensV2 amendment is still listed as in development^[6].
Tying an MPT natively to a permissioned domain is not possible yet. An issuance's DomainID also requires the SingleAssetVault amendment^[5]^[10], which is not enabled on mainnet.
Changing MPT settings after issuance is part of the DynamicMPT amendment^[4], which is not enabled on mainnet either.

Until those amendments are enabled, access control for an MPT relies on lsfMPTRequireAuth plus the issuer's authorization decisions, informed by credentials.

Takeaways

Credentials give institutions a portable, revocable proof of status that keeps personal data off-chain.
Permissioned domains turn "which issuers do we trust" into a single ledger object.
MPTs carry the asset with protocol-level controls: authorization, locking, clawback and supply caps.
Each primitive is live on XRPL mainnet today; DEX trading of MPTs and native domain-gated MPTs are still future work.

At Fractiona we are building non-custodial infrastructure on top of these primitives, designed so that each institution keeps its own keys, issues its own credentials and decides its own access rules.