Proposed Extension to XLS-94D Jibreel Muhammad from @Accountabul @Beabulnow

[Accountabul]

Author: Jibreel Muhammad (@Accountabul)
Status: Draft (Discussion)
Category: XRPL Ledger Object Extension
Requires: XLS-33 (MPT), XLS-94 (Dynamic MPT)

This discussion proposes an extension to XLS-94 Dynamic Multi-Purpose Tokens (MPTs) that would introduce Token Sub-Classes. These are internal partitions within a single token issuance that each carry their own metadata, supply caps, and optional immutability locks.

The goal is to allow one ticker (e.g., $TOKEN) to host multiple internally differentiated categories such as vouchers, rewards, or lockup tranches without creating separate token issuances or NFTs.

Background
XLS-33 (MPT) defines how fungible Multi-Purpose Tokens are issued and tracked.
XLS-94 (Dynamic MPT) extends that with mutable metadata.
XLS-89 defines a metadata schema for classification and presentation (e.g., asset_class, asset_subclass).

However, all of these treat an issuance as one uniform supply. There’s currently no way I know to define verifiable sub-issuances or per-unit metadata inside a single token object.

I look at it as more of per-unit metadata- but it also seems to me it serves as here's a Scenario.

Scenario: Customer wants to redeem an $TOKEN, token for a store discount.
The customer’s wallet holds multiple $TOKEN subclasses:
voucher_2025Q1 – eligible for discount $TOKEN
general – standard $TOKEN

At checkout, the POS system queries the transaction:
If subClassId="voucher_2025Q1", proceed → apply discount → burn or mark redeemed.

If subClassId="general", reject → “Token not eligible for discount.”

Ledger enforcement:
Burn or clawback affects only that subclass balance.

Optional serial proof ensures each voucher is used once.
Result: users see one ticker ($TOKEN) but the ledger and applications know the functional type of each unit.

I began this as an attempt to introduce richer metadata fields into MPTs, but the intent has evolved into enabling functional sub-issuances within a single token object. Many real-world use cases require parts of that supply to behave differently — for example, reward tokens that accumulate yield, voucher tokens that burn on redemption, or general tokens used for standard payments under 1 token ticker/Issuance.

This Token Sub-Class model defines these internal partitions explicitly.
Each sub-class is recorded in the parent token’s metadata with its own id, cap, and optional mutability or serialization settings.
When tokens are minted, transferred, or burned, the transaction references a subClassId, allowing the ledger to apply supply limits and Hooks or contracts to enforce business logic specific to that sub-class.

In practice, this functions like an “issuance within an issuance”, the supply remains unified under one ticker and one issuer, but the ledger and applications can still tell what type of token each unit is and act accordingly.

This structure intent is to stay within the existing 1 KB metadata limit and may require minimal extensions to existing MPT logic, but it opens a path for on-chain token identification, redemption, and behavioral differentiation without fragmenting liquidity or spawning multiple assets.

[therealtauseef]

Love this direction subclass granularity under a single ticker could be a game changer for structured token ecosystems. It’s a clean way to combine behavioral logic, metadata, and supply discipline without spinning up multiple assets. Definitely opens room for on-chain compliance and redemption models.

[Alambdasystem]

I think this is a great idea.

[Accountabul]

I appreciate the responses. I am a solo Learner, I wouldn't consider myself a dev just yet, but I am building out a real estate tokenization business utilizing the XRPL. I got this Idea from experimenting with tokenization models, particularly for a Business with products-- to cooperate within a broader Token Ecosystem.

If there are any devs that want to help clean up this idea feel free to reach out to me on LinkedIn: https://www.linkedin.com/in/jibreel-muhammad-7336a82a7/

We are based in St. Louis, Mo.

[EnchStyle]

I struggle to see how this fits the XRPL model without creating deeper inconsistencies. Once different subclasses carry different rules, redemption behaviours, or restrictions, the asset is no longer fungible in a meaningful economic or technical sense. XRPL’s DEX, AMM, and payment logic assume uniform fungibility per asset. If subclasses behave differently, then applications must treat them as separate assets to avoid routing, pricing, and UX ambiguity. At that point the proposal doesn’t remove fragmentation, it simply hides it under a shared ticker.

There is also no deterministic enforcement layer here. Since XRPL has no native smart contracts or Hooks, subclass behaviour would not be enforceable at the ledger level. Without native enforcement, subclass logic becomes cosmetic and unreliable from a ledger integrity perspective.

The use-cases are valid, but stretching XLS-33 into “fungible partitions” undermines what fungibility means. I am not also not convinced that having simply another token would not be easier an easier option. Plus you can mint a new token under the same issuer account.

[Alambdasystem]

His is a great direction for extending XLS-94. The idea of introducing token sub-classes or partitions within a single MPT issuance makes a lot of sense — especially for structured tokenization use cases like multi-tier equity, fractional assets, or compliance-segmented distributions.

Building on Dynamic MPTs feels like the right foundation since it already supports flexible on-ledger behavior. The sub-class concept could help streamline token management and reduce fragmentation across multiple issuances.

I’m particularly interested in how this might integrate with existing ledger object structures — for example, whether sub-classes would live as child objects under a parent MPT, or whether attributes like transfer rules and metadata could inherit or override parent-level logic.

Great work surfacing this idea early. It’s one of those small architectural evolutions that could really broaden how institutions and developers design with XRPL tokens.

[Accountabul]

I understand the reason for the pushback/feedback on this idea more clearly now.

Even though the concept is useful for certain real-world scenarios, implementing true subclasses inside a single MPT issuance would require significant changes to XRPL’s native architecture. It would alter how the ledger handles fungibility, DEX routing, and deterministic validation, which means this feature is much larger than a metadata extension.

Given that smart contracts have now been introduced, we can experiment with many of the same behaviors using the approach that @EnchStyle suggested.

Instead of attempting to force multiple behavioral classes under one issuance, we can issue multiple tokens and design contract logic that defines how each token type interacts, converts, burns, or unlocks value within the ecosystem.

This achieves the same functional outcomes without breaking XRPL’s fungibility model or requiring protocol-level changes.

Thank you for the feedback and support from everyone, I will continue to keep offering ideas to start discussions well also learning more about the technicalities of how the ledger works.

Maybe in the future, I can revisit this idea, my plans with this was to create a more robust token economy under 1 issuance class.

[Accountabul]

@Alambdasystem it would act as a child in this relationship.
One ticker symbol, multiple -
Assets-- multiple functionality within that one ticker symbol.

A lot of this has to do with programmability, if we wanted to implement some type of design like this to a token economy.

I think the idea is great, but it doesn't technically work from what we have available currently at a native Level.

It may completely change a lot of core Code which probably doesn't need to be changed.

I think a smart contract may be able to resolve an issue like this, maybe if we Collab on how we could get this to work and what would have to technically change on the ledger to get this to Work that would be cool spending a couple of hours to figure out even if it's not feasible.

I'm coming over from the content creation, Side to the technical side so I have more learning to do. I appreciate the feedback brother.

[Accountabul]

Also as I thought more and started to study the new smart contract proposal XLS101. I was thinking potentially this feature if refined correctly could also give us some programmable options
At a native Level.

I don't know what All would have to go into that, but it could spark a good conversation for the no smart contract versus smart contract People on the XRPL. If we find correctly.