Asset Types on {explorerName}: Native Asset, Issued Tokens, NFTs.
++ The {explorerName} has a fundamentally different asset architecture compared to smart-contract blockchains. + Understanding the distinction between the native asset and issued tokens is essential for risk assessment, + liquidity analysis, and infrastructure development. +
+This guide explains the core asset categories on {explorerName}.
+Native Asset: {nativeCurrency}
++ The only native asset (native coin) is {nativeCurrency}. {nativeCurrency} is built directly into the + protocol and has no issuer. +
+Technical properties
+-
+
- Used to pay transaction fees (fees are burned). +
- Required as base reserve for accounts and ledger objects. +
- Does not require a Trust Line. +
- Cannot be frozen or clawed back. +
- Can act as a bridge asset for auto-bridging in the DEX. +
- Can participate in AMM pools +
+ All other assets are issued tokens. +
+Issued Tokens (IOUs)
++ All non-{nativeCurrency} assets on {explorerName} are issued tokens, historically referred to as IOUs. An + issued token represents a balance issued by a specific account (the issuer). Holding such a token requires + establishing a Trust Line to that issuer. +
+Core mechanics
+-
+
- Created by an issuer account. +
- Transferable between accounts with trust. +
- Tradable on the built-in order book DEX. +
- Usable in AMM pools. +
-
+ May enable issuer-controlled features:
+
-
+
- Freeze (if configured) +
- Global Freeze (if configured) +
- Clawback (if configured) +
+
Issued tokens are not coins:
+-
+
- They are not used for transaction fees. +
- They depend on issuer configuration and counterparty risk. +
+ + 💡 + {' '} + View all {explorerName} Tokens +
+Non-Fungible Tokens (NFTs)
++ Non-fungible tokens (NFTs) represent unique digital or physical assets, such as artwork or in-game items. On + {explorerName}, NFTs are implemented as NFToken objects — indivisible, unique units not used for payments. +
+Characteristics
+-
+
- Don't require a Trust Line. +
- Cannot be frozen or clawed back. +
- Can be minted, held, bought, sold, transferred and burned. +
- + Traded using NFT SellOffer and BuyOffer transactions on NFT marketplaces, not through the ledger’s + standard order book DEX. + +
- Cannot participate in AMM pools. +
+ + 💡 + {' '} + Learn how to mint NFTs on {explorerName} +
++ + 💡 + {' '} + Learn more about our {explorerName} NFT explorer +
+Every token category below is a subtype of issued tokens.
+Stablecoins on {explorerName}
++ A stablecoin is an issued token designed to maintain a price peg (typically to fiat such as USD or EUR). +
+Characteristics
+-
+
- Implemented as a standard issued token. +
- Requires a Trust Line. +
- May include Freeze and Clawback features. +
- Trades on the native DEX. +
- Can participate in AMM pools. +
+ {explorerName} does not implement a special stablecoin standard. A stablecoin is economically defined, not + technically distinct. +
+Examples of {explorerName} stablecoins:
+ + {xahauNetwork ? ( + + EURQ issued by Quantoz + + ) : ( +-
+
- + + RLUSD issued by Ripple + + +
- + + USDC issued by Circle + + +
- + + USDB issued by Braza Bank + + +
- + + EurØp issued by Schuman Financial + + +
- + + XSGD issued by StraitsX + + +
Utility Tokens
++ A utility token on {explorerName} is an issued token that grants access to a service, platform, or + functionality. We should keep in mind: {explorerName} does not support protocol-level utility tokens. All + non-native assets derive their utility from application-layer logic. +
+Examples of utility models:
+-
+
- Access to platform features. +
- Discount mechanisms. +
- Governance voting (off-ledger or hybrid). +
- Payment token within an ecosystem. +
Technical properties are identical to other issued tokens:
+-
+
- Trust Line required. +
- Subject to issuer configuration. +
- Tradable on DEX unless restricted. +
+ There is no protocol-level distinction between a utility token and any other issued token. The difference is + purely functional. +
+ {!xahauNetwork && ( + <> +Examples of utility tokens:
+-
+
- + + UtiliteX issued by eolas + + +
- + + OXP issued by bidds + + +
- + + CSC issued by CasinoCoin + + +
- + + VVT issued by Virovita Token + + +
Memecoins
++ A memecoin on {explorerName} is an issued token driven primarily by community narrative rather than + fundamental utility. +
+Technical characteristics:
+-
+
- Standard issued token structure. +
- Often high supply concentration. +
- Liquidity may be shallow or volatile. +
From a protocol perspective, a memecoin is indistinguishable from any other issued token.
+The classification is social and market-driven, not architectural.
+Risk analysis should focus on:
+-
+
- Issuer account controls. +
- Distribution concentration. +
- Liquidity depth on DEX and AMM. +
- Historical transaction patterns. +
Examples of XRPL memcoins
+-
+
- + + FUZZY issued by Fuzzybear + + +
- + + Xoge + + +
RWA on {explorerName}
++ A Real-World Asset (RWA) token is an issued token that represents a legally enforceable claim on an + off-ledger asset. +
++ On {explorerName}, there is no special “RWA token standard.” An RWA is implemented as a standard issued + token, but its classification depends on the economic and legal structure behind it. +
+RWA tokens represent tokenized real-world assets such as:
+-
+
- Fiat deposits +
- Commodities +
- Securities +
- Real estate +
- Bonds +
{explorerName}’s design is particularly suited for RWA issuance because:
+-
+
- Settlement is fast (~3–5 seconds). +
- Fees are minimal. +
- The DEX and AMM are native to the protocol. +
- Counterparty relationships are explicit via Trust Lines. +
Key Takeaways
+-
+
- + {explorerName} has one native asset: {nativeCurrency}. + +
- All other assets are issued tokens. +
- + Stablecoins, utility tokens, memecoins, and RWA tokens are economic classifications, not protocol-level + asset types. + +
- Risk exposure in {explorerName} token ecosystems is primarily issuer-based, not protocol-based. +
- + Understanding this distinction is essential for accurate asset evaluation, custody decisions, liquidity + analysis, and infrastructure development within {explorerName}. + +