XRPL Multi-Purpose Tokens (MPTs) Explained in 2026: Supply, Permissions, Transfers, and Costs

By XORA · Published 2026-09-07

Multi-Purpose Tokens are live on XRP Ledger Mainnet, but the precise 2026 model is narrower than “next-generation token standard” suggests. MPTokensV1 lets an issuer define one token issuance, cap integer supply, require holder approval, permit or block holder-to-holder transfers, charge up to a 50% transfer fee, lock balances, and optionally claw them back. Every holder opts in through an MPToken object. Direct Payments work today; native DEX and AMM trading does not under the Mainnet amendments verified on 7 September 2026.

An issuance is a definition, not a pre-minted pile

An issuer starts with MPTokenIssuanceCreate. A successful transaction creates one MPTokenIssuance ledger entry and returns a 192-bit issuance ID derived from the creation sequence and issuer account. That ID, rather than a reusable currency code, identifies the asset in later transactions.

The definition can include AssetScale, MaximumAmount, a transfer fee, up to 1,024 bytes of metadata, and capability flags. Under MPTokensV1, issuance does not mint a fixed inventory into the issuer's wallet. The issuer cannot hold its own MPT. Instead, OutstandingAmount starts at zero and rises when the issuer pays a non-issuer. Sending units back to the issuer reduces outstanding supply and restores capacity beneath the cap.

Supply math uses integers and a display scale

MPT accounting uses non-negative integers from zero through 2⁶³ − 1, or 9,223,372,036,854,775,807. MaximumAmount caps the amount simultaneously in circulation. It is not a lifetime mint counter. If the field is omitted, the same 2⁶³ − 1 value is the current default maximum, so omission does not mean infinite supply.

AssetScale tells applications where to display the decimal point. With scale 2, 100 base units display as 1.00 token. The ledger still adds, subtracts, and caps integers. For a concrete issuance with MaximumAmount = 100000000 and scale 2, the visible cap is 1,000,000.00 tokens. If OutstandingAmount = 73250000, 732,500.00 are circulating and 267,500.00 can be issued before the cap binds.

Holder permission has two distinct gates

Every non-issuer account must signal willingness to hold a particular MPT. The holder submits MPTokenAuthorize, which creates a zero-balance MPToken entry. A holder can delete that object with tfMPTUnauthorize only after its public and locked balances are zero.

If Require Auth is off, holder opt-in is sufficient. If it is on, the issuer must submit a separate MPTokenAuthorize naming that holder. Unlike classic authorized trust lines, MPT issuer authorization can later be revoked. Revocation controls permission, while locking controls movement of an existing balance. They are separate operational decisions.

Transfer, lock, clawback, and fee controls

The Can Transfer capability decides whether one holder can pay another. Without it, holders can only return MPTs to the issuer. With it, a direct Payment can move one MPT between opted-in, permitted accounts. Can Lock lets the issuer lock an individual balance or the whole issuance. A locked holder's balance cannot increase or decrease except when value is sent directly back to the issuer. Can Clawback separately lets the issuer recover value from a holder.

A transfer fee can range from 0% through 50% in 0.001 percentage-point increments. It requires Can Transfer, does not apply to payments directly to or from the issuer, and is charged on top of the delivered amount. The fee is burned rather than paid into an issuer balance. If Alice sends Bob 10,000.00 tokens with a 0.5% fee, Alice needs 10,050.00, Bob receives 10,000.00, and 50.00 are removed from circulation. Integer rounding can reduce the fee, even to zero for small payments.

What MPT issuance and holding actually cost

We queried a validated Mainnet server_info response at ledger 106,820,689 on 7 September 2026. It reported a 1 XRP base reserve, 0.2 XRP owner reserve, and 10-drop minimum reference transaction cost. Network load, queue conditions, and multisigning can raise a submitted fee, so the figures below are floors rather than quotes.

Creating an issuance increases the issuer's OwnerCount by one, ordinarily adding 0.2 XRP to its reserve requirement. Each holder's MPToken also adds one owned item. The current rippled implementation only enforces the incremental reserve for an unsponsored holder once the account already owns at least two items, matching the “first two free” pattern for trust lines. The object still increments OwnerCount. Sponsorship changes who covers reserve, so applications must inspect the actual ledger entries and account state.

These rows assume one success per step, single signatures, no load scaling, no reserve sponsor, already funded accounts, and no retries. “MPT fee” means burned token units, not XRP. The Require Auth path counts holder opt-in, issuer approval, and issuer Payment after the one-time issuance creation.

MPTs versus classic trust line tokens

Trust line tokens use a bidirectional RippleState relationship. Their balances can appear positive or negative depending on perspective, use 15 significant decimal digits with an exponent, and can ripple across connected lines. Issuer settings such as transfer rate apply at the account level, which is one reason separate issuing accounts are often recommended for separate assets.

An MPT issuance is one-directional: one declared issuer, positive integer holder balances, no rippling, and per-issuance settings. Its unique issuance ID avoids currency-code ambiguity. Both models require holder consent and can support authorization, freeze-like controls, clawback, and transfer fees, but their mechanics differ. Trust line tokens are already usable in XRPL order books, AMMs, and path payments. MPTokensV1 supports direct MPT Payments only.

Mainnet status: live v1, not future v2

The official known amendments registry identifies MPTokensV1 by amendment ID 950AE2EA…1F5EC38. A validated Mainnet feature response at ledger 106,820,689 reported it enabled and supported on 7 September 2026. That is the basis for calling issuance and direct transfer live.

The same dated check reported DynamicMPT disabled. Therefore this guide does not assume post-creation changes to metadata, transfer fees, or capability flags, even though current documentation describes those operations behind the amendment. MPTokensV2, which is intended to add native DEX and AMM integration, was also not enabled or supported by the queried server. Software should query a validated ledger before relying on either feature; amendment state can change after publication.

Operational checklist before issuing an MPT

• Fix the unit model first: choose AssetScale and MaximumAmount together, then test every displayed amount as integer math.
• Minimize issuer powers: enable transfer, lock, clawback, and authorization only when the asset's legal and operational model requires them.
• Model both onboarding gates: every holder opts in; Require Auth adds a separate issuer transaction and approval state.
• Budget objects at scale: count issuance and holder objects, query current reserve values, and do not assume the free tier or sponsorship applies.
• Verify delivered amounts: transfer fees burn extra units and MPT Payments can use partial-payment behavior, so reconcile validated metadata rather than trusting the requested amount.
• Gate future features: query validated amendment state before offering mutable settings or DEX trading.

Put XRP to work instead of leaving it idle

MPTs are an on-ledger token standard, not an XRP yield source. XORA's separate proposition is up to 22% APY value (15% native subsidised + XORA reward value). That value is variable, depends partly on reward valuation, and is not guaranteed. Custody, liquidity, operational, counterparty, market, and reward-value risks remain. Review the security model and test assumptions with the XRP yield calculator.

xora.finance is where to put your XRP to work and earn up to 22% instead of leaving it idle on an exchange.