XRPLs Native NFT Standard Xls 20 Deep Dive

May 2021: David Schwartz (Ripple CTO and XRPL co-creator) and Aanchal Malhotra published XLS-20, formally "Non-Fungible Tokens on the XRP Ledger."

The Design Philosophy:

1. Enable native NFT support without smart contracts
2. Minimize ledger bloat from potentially millions of NFTs
3. Provide efficient storage and transfer mechanisms
4. Support creator royalties (transfer fees) at protocol level
5. Integrate with existing XRPL DEX functionality

• Programmable NFT logic (like ERC-721 extensions)
• On-chain metadata storage (too expensive at scale)
• Gaming logic execution (not what XRPL is designed for)

The proposal acknowledged XRPL's limitations and designed around them rather than trying to make XRPL something it wasn't.

Why the Long Timeline Matters:

The extended development period wasn't slow execution—it was intentional caution. Unlike smart contracts (which can be deployed by anyone), native protocol changes affect the entire network. XRPL's approach required:

1. Community consensus (validator voting)
2. Extensive testing (potential network stability impacts)
3. Bug fixing before mainnet deployment
4. Documentation and tooling preparation

This conservative approach means XLS-20 launched relatively bug-free, but it also means XRPL can't rapidly iterate on NFT features like smart contract platforms can.

Alongside XLS-20 development, Ripple announced:

• Focus on NFTs, gaming, and metaverse

• 4,000+ applications received

• Multiple grant recipients in gaming/NFT space

• Distributed over 10-20 years

• Includes developer grants, hackathons, infrastructure

Honest Assessment: The Creator Fund represented significant capital commitment, but outcomes have been mixed. Some funded projects launched; others have gone quiet. The XRPL gaming ecosystem remains small despite funding availability.

Every NFT on XRPL is an NFToken object with a unique 256-bit identifier.

NFToken ID Composition:

NFToken ID = 256 bits total

Bits 0-15:   Flags (16 bits)
             - tfBurnable: Can issuer burn regardless of owner?
             - tfOnlyXRP: Can only be traded for XRP (not IOUs)
             - tfTrustLine: Related to transfer fee requirements
             - tfTransferable: Can be transferred after initial sale?

Bits 16-47:  Transfer Fee (32 bits)
             - Royalty percentage (0-50%, expressed as integer)
             - Automatically applied on secondary sales

Bits 48-79:  Flags + Reserved (32 bits)

Bits 80-255: Issuer Address + Taxon + Sequence
             - Issuer: Account that minted the NFT
             - Taxon: Collection identifier (up to 2^32 taxons)
             - Sequence: Incremented per mint from issuer

The combination ensures every NFToken ID is globally unique.

Practical Example:

Issuer: rGameDev123... (the game studio's XRPL account)
Taxon: 42 (representing "Sword Collection")
Flags: tfBurnable | tfTransferable
Transfer Fee: 5% (500 in protocol terms = 5.00%)
Sequence: 1234 (the 1234th NFT minted by this issuer)

- Who created it
- What collection it belongs to
- What rules govern it
- How royalties work

XRPL doesn't store each NFT as a separate ledger object. Instead, it groups NFTs into NFTokenPage objects.

NFTokenPage Structure:

Each NFTokenPage can hold up to 32 NFTokens
Pages are linked in a sorted structure
Owned by a single account

- Reduces ledger bloat (1 object vs. 32)
- Lower reserve requirements for holders
- Efficient enumeration of owner's NFTs

- More complex page management
- Page splits when adding >32 NFTs
- Slightly more complex indexing

Reserve Implications:

• Base reserve: 10 XRP (to activate account)

• Owner reserve: 2 XRP per owned ledger object

• First NFTokenPage: 2 XRP reserve

• Each additional page (every 32 NFTs): +2 XRP reserve

• Owning 1-32 NFTs: 2 XRP reserve

• Owning 33-64 NFTs: 4 XRP reserve

• Owning 100 NFTs: 8 XRP reserve (4 pages)

• No reserve requirement

• But: Each NFT transfer costs gas ($5-50+)

• Holding NFTs is "free" but using them is expensive

• Small ongoing reserve requirement

• But: Each transaction costs ~0.00001 XRP

• Holding costs something but using is nearly free

XLS-20 NFTs can include a URI field pointing to metadata.

NFToken Minting Transaction:
{
  "TransactionType": "NFTokenMint",
  "Account": "rIssuer...",
  "NFTokenTaxon": 42,
  "Flags": 8,  // tfTransferable
  "TransferFee": 500,  // 5%
  "URI": "68747470733A2F2F..."  // Hex-encoded URI
}

What the URI returns (JSON):
{
"name": "Sword of Fire #1234",
"description": "A legendary flaming sword",
"image": "ipfs://QmImage123...",
"attributes": [
{"trait_type": "Damage", "value": 50},
{"trait_type": "Element", "value": "Fire"}
]
}
```

Critical Point: The URI and metadata are NOT stored on the XRPL. Only the pointer (URI field, max 512 bytes) is on-chain. All the same metadata durability concerns from Lesson 2 apply.

Creating new NFTs on XRPL.

Transaction Structure:

const mintTx = {
  TransactionType: "NFTokenMint",
  Account: issuerAddress,
  NFTokenTaxon: 1,  // Collection identifier
  Flags: NFTokenMintFlags.tfTransferable,  // Allow secondary sales
  TransferFee: 500,  // 5% royalty
  URI: convertStringToHex("ipfs://QmMetadata123...")
}

// Submit to XRPL
const result = await client.submitAndWait(mintTx, { wallet: issuerWallet })

// NFToken ID returned in transaction metadata
const nftokenID = result.result.meta.nftoken_id

Minting Flags:

Cost: ~0.00001 XRP per mint (12 drops)

The XRPL has no separate marketplace contracts. Trading happens through native NFTokenOffer objects.

Sell Offer (Owner wants to sell):

Buy Offer (Buyer wants to purchase):

Offer States:

Offer Created → Stored on ledger as NFTokenOffer object
           → Consumes 2 XRP reserve from creator
           → Visible to anyone querying the ledger

Offer Accepted → NFT transfers, payment occurs
             → Royalty automatically deducted
             → Offer object deleted, reserve freed

Offer Cancelled → NFTokenCancelOffer transaction
              → Offer deleted, reserve freed
              → No transfer occurs

Completing trades by accepting existing offers.

Accept a Sell Offer:

Accept a Buy Offer:

Brokered Mode (matching buy + sell):

Destroying NFTs permanently.

This is XLS-20's killer feature: royalties that actually work.

How Transfer Fees Work:

Example: 5% transfer fee, NFT sold for 100 XRP

- Seller receives: 100 XRP (marketplace may or may not pay creator)
- Creator receives: 0-5 XRP (depends on marketplace honoring royalties)

- Transaction includes 100 XRP payment
- Protocol automatically calculates: 100 XRP × 5% = 5 XRP
- Creator (issuer) receives: 5 XRP (enforced at protocol level)
- Seller receives: 95 XRP
- NO WAY TO BYPASS THIS

The royalty is enforced by the ledger itself, not by marketplace choice.

Transfer Fee Constraints:

• Minimum: 0%

• Maximum: 50% (expressed as 50000 in protocol)

• Precision: 0.001% increments (expressed as integer from 0-50000)

• Applied on: Every transfer that includes payment

• Not applied on: Gifts/transfers with no payment

• Transfer fee must be paid in same currency as sale

• Issuer must have trust line for that currency

Why This Matters for Gaming:

Scenario: Game studio mints in-game items with 5% transfer fee

- Players trade on OpenSea-like marketplace
- Marketplace may or may not pay royalties
- Many marketplaces now allow royalty bypassing
- Creator revenue from secondary sales: uncertain

- Players trade on any XRPL marketplace or peer-to-peer
- Every sale automatically sends 5% to game studio
- No marketplace can bypass this
- Creator revenue from secondary sales: guaranteed

---

Transaction Costs Comparison:

Operation          | XRPL (XLS-20) | Ethereum (ERC-721) | Solana (Metaplex)
-------------------|---------------|--------------------|-----------------
Mint 1 NFT         | ~$0.000005    | $5-100+            | ~$0.00025
Transfer NFT       | ~$0.000005    | $2-50+             | ~$0.00025
Create offer       | ~$0.000005    | $5-50+             | ~$0.0001
Accept offer       | ~$0.000005    | $10-100+           | ~$0.0002
Burn NFT           | ~$0.000005    | $2-30+             | ~$0.0001

At scale (10,000 operations):
XRPL: ~$0.05 total
Ethereum: $50,000-500,000
Solana: $2.50

For gaming applications requiring frequent transactions, this cost difference is significant.

Transaction Finality:

XRPL: 3-5 seconds to full finality
      (Once confirmed, transaction cannot be reversed)

Ethereum: 12-15 seconds for inclusion
          + Wait for block confirmations (varies)
          + ~15 minutes for "safe" finality

Solana: ~400ms for inclusion
        But: 32 block confirmations recommended (~12 seconds)
        And: Network has had stability issues

- 3-5 second trades are acceptable for most games
- Real-time combat/gameplay needs off-chain solutions regardless
- Finality matters for high-value item trades

Built-in Trading Infrastructure:

• NFTs exist on-chain

• Trading requires:

• Multiple contracts, multiple fees, multiple attack surfaces

• NFTs and trading mechanism are both native

• NFTokenOffer is a first-class ledger object

• No external contracts needed

• Trading is peer-to-peer with protocol security

• Same security model as XRP itself

Security Model:

• Smart contract bugs (reentrancy, overflow, etc.)

• Malicious contracts masquerading as legitimate

• Upgradeable contracts changing behavior

• Complex interactions between contracts

• Historical exploits: $100M+ lost to NFT contract vulnerabilities

• No smart contracts = no smart contract bugs

• All NFT logic is protocol-level (audited, tested, consensus-approved)

• No upgradeable "surprise" behavior

• Simpler security model to understand

The tradeoff: no programmability means no custom features
```

As covered in Section 3.5, this is a genuine competitive advantage:

• OpenSea, Blur, and other major marketplaces now make royalties optional

• Creator earnings from secondary sales have collapsed on Ethereum

• Some creators seeing 90%+ drop in royalty revenue

• Solana marketplaces similarly don't enforce

• Protocol-level enforcement

• No marketplace can bypass

• Creators guaranteed their percentage forever

• Better aligned incentives for game developers

What You Can't Do:

• Dynamic NFT attributes (stats that change based on on-chain events)

• On-chain gameplay logic (battles resolved by contract)

• Complex royalty splits (multiple recipients, conditional logic)

• Breeding/combining mechanics (on-chain)

• Staking rewards (NFT + DeFi integration)

• DAO governance tied to NFTs

• Cross-contract composability

• NFT attributes are static (set at mint, never change on-chain)

• No on-chain game logic possible

• Royalties go to single issuer address

• No on-chain combining/breeding

• No native staking mechanism

• No on-chain governance

• Limited composability

The Hybrid Solution:

Most XRPL gaming projects use hybrid architecture:

- Asset ownership (who owns which NFTs)
- Trading (buy/sell with enforced royalties)
- Provenance (ownership history)

- Game logic (battles, crafting, leveling)
- Dynamic attributes (sword damage changes as you upgrade)
- Real-time gameplay
- State management

- Periodic or event-driven sync between on-chain ownership and off-chain game state
- Game reads XRPL to verify ownership
- Game writes metadata updates to storage (IPFS, Arweave)

This works, but it means game logic depends on centralized servers—the same metadata problem from Lesson 2.

Developer Tooling Comparison:

• Dozens of major SDKs and libraries

• Extensive documentation

• Thousands of tutorials

• Active StackOverflow, Discord communities

• Multiple IDEs with Solidity support

• Comprehensive testing frameworks

• Established auditing firms

• xrpl.js, xrpl-py, xrpl4j (core libraries)

• Growing documentation

• Limited tutorials (improving)

• Smaller community (but dedicated)

• Standard IDE support

• Basic testing tools

• Fewer auditing options (no smart contracts reduces need)

Marketplace Infrastructure:

Ethereum: OpenSea, Blur, Rarible, LooksRare, X2Y2, Foundation...
          (Billions in volume, extensive features)

Solana: Magic Eden, Tensor, SolSea...
        (Substantial volume, good tooling)

XRPL: xrp.cafe, OnXRP, Sologenic, Equilibrium...
      (Small volume, basic features, growing)

- Ethereum NFT daily volume: $10-100M+
- Solana NFT daily volume: $1-10M+
- XRPL NFT daily volume: $10K-100K (estimate)

Where Are Gaming Developers Building?

2023-2024 Blockchain Gaming Developer Survey Data:
(Various sources, approximate)

- Ethereum/EVM-compatible: ~40-50%
- Polygon: ~15-20%
- Solana: ~10-15%
- Gaming-specific (Immutable, Ronin): ~10-15%
- BNB Chain: ~5-10%
- XRPL: ~1-2%
- Others: ~5-10%

This is the core challenge: regardless of technical merits,
developers build where other developers are building.
Network effects in developer ecosystems are strong.

ERC-1155 Capability Missing:

• Token ID 1: "Gold Coin" with supply 1,000,000 (fungible)
• Token ID 2: "Legendary Sword #1" with supply 1 (NFT)
• Token ID 3: "Health Potion" with supply 10,000 (fungible)
• Token ID 4: "Rare Skin" with supply 100 (semi-fungible)

All in one contract, efficiently managed.

• Every NFToken is unique (supply = 1)
• No mechanism for "100 copies of same item"
• Would need to mint 100 separate NFTs with same metadata
• Less efficient for gaming use cases with duplicate items

Workaround:
Use XRPL issued tokens (IOUs) for fungible in-game currencies and XLS-20 for unique items. Hybrid approach works but adds complexity.

Despite protocol-level NFT support, XLS-20 has the same metadata problem as other chains:

On-Chain: NFToken ID, Owner, Flags, Transfer Fee, URI (pointer)
Off-Chain: Everything else (image, attributes, description)

XLS-20 doesn't solve the "what if metadata disappears?" problem.
It just makes trading and ownership tracking cheaper.
```

✅ XLS-20 works technically: Millions of NFTs minted, traded, and managed since October 2022 with no major protocol issues

✅ Cost advantage is real: Sub-cent transactions for all NFT operations, orders of magnitude cheaper than Ethereum

✅ Speed advantage is real: 3-5 second finality, fast enough for most gaming trading scenarios

✅ Royalty enforcement works: Transfer fees are automatically and reliably applied—no marketplace bypassing

✅ Security model is simpler: No smart contract vulnerabilities, same security as core XRP transactions

⚠️ Ecosystem growth trajectory: Will developer interest increase, or will XRPL remain niche for gaming?

⚠️ Hybrid architecture viability: Can off-chain game logic + on-chain ownership create compelling experiences?

⚠️ Tooling maturation: Will development tools reach parity with Ethereum/Solana ecosystems?

⚠️ Marketplace liquidity: Will secondary market depth improve enough for valuable in-game economies?

⚠️ Future protocol upgrades: Will features like Hooks add programmability that changes the equation?

🔴 Assuming technical merit equals adoption: XRPL is technically capable, but adoption depends on ecosystem factors beyond tech

🔴 Ignoring the smart contract limitation: Many gaming use cases genuinely need on-chain logic that XLS-20 cannot provide

🔴 Confusing potential with current state: XRPL gaming ecosystem is nascent; don't project based on what "could" exist

🔴 Underestimating network effects: Developers and users go where other developers and users are—this is hard to overcome

🔴 Assuming royalty enforcement is decisive: It's an advantage, but not sufficient to drive adoption alone

XLS-20 is a well-designed, functional NFT standard with genuine advantages in cost, speed, and royalty enforcement. It's also missing key features (smart contract logic, semi-fungible tokens) that many gaming use cases require. The technology works; the ecosystem is small. Success in gaming depends not on whether XLS-20 is technically capable (it is, within its scope), but on whether enough developers and players choose XRPL over better-established alternatives.

Assignment: Create a detailed feature matrix comparing XLS-20 to ERC-721, ERC-1155, and Solana's Metaplex NFT standard across 15+ parameters.

Requirements:

Part 1: Feature Matrix (Minimum 15 Parameters)

Create comparison table covering:

• Token identification system

• Metadata storage approach

• On-chain vs. off-chain data

• Smart contract integration

• Semi-fungible token support

• Batch operations

• Minting cost (typical)

• Transfer cost (typical)

• Storage/reserve requirements

• Gas/fee predictability

• Native marketplace support

• Royalty enforcement

• Offer/listing system

• Vulnerability surface

• Upgrade mechanisms

• Historical exploits

• Developer tools

• Marketplace options

• Documentation quality

Part 2: Gaming Suitability Analysis

• Trading card games (NFTs as cards)
• RPGs (NFTs as characters/items)
• Real-time games (frequent transactions)
• Play-to-earn models (economic integration)

Rate each: High/Medium/Low with justification.

Part 3: XRPL Advantage/Disadvantage Summary

• Where XLS-20 is clearly superior (with evidence)
• Where XLS-20 is clearly inferior (with evidence)
• Where it's roughly equivalent
• What type of game would benefit most from XLS-20?
• What type of game should definitely not use XLS-20?

Part 4: Technical Deep Dive (Choose One)

• Option A: NFTokenPage storage mechanics (how paging works, reserve implications)
• Option B: Transfer fee implementation (how royalties flow, edge cases)
• Option C: Offer system mechanics (sell vs. buy offers, brokered trades)

Include code examples or transaction references from XRPL explorers.

• XLS-20 specification: https://xrpl.org/docs/concepts/tokens/nfts" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://xrpl.org/docs/concepts/tokens/nfts">https://xrpl.org/docs/concepts/tokens/nfts

• ERC-721 spec: https://eips.ethereum.org/EIPS/eip-721" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://eips.ethereum.org/EIPS/eip-721">https://eips.ethereum.org/EIPS/eip-721

• ERC-1155 spec: https://eips.ethereum.org/EIPS/eip-1155" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://eips.ethereum.org/EIPS/eip-1155">https://eips.ethereum.org/EIPS/eip-1155

• Metaplex docs: https://docs.metaplex.com/" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://docs.metaplex.com/">https://docs.metaplex.com/

• XRPL transaction examples: xrpscan.com, bithomp.com

• Completeness (25%): All parameters covered with accurate data

• Technical accuracy (25%): Correct understanding of each standard

• Analytical quality (25%): Thoughtful suitability assessments with clear reasoning

• Deep dive quality (25%): Thorough exploration of chosen topic

Time investment: 4-5 hours
Value: This comparison matrix becomes your reference for evaluating whether any specific gaming project should use XRPL vs. alternatives. It forces engagement with actual technical specifications rather than marketing claims.

For Next Lesson:
Lesson 4 examines gaming economics fundamentals—how game economies work (sinks, faucets, inflation), what makes tokenomics sustainable, and case studies from major blockchain games. This provides the economic analysis framework needed to evaluate any gaming project, on XRPL or elsewhere.

End of Lesson 3

Total words: ~6,800
Estimated completion time: 60 minutes reading + 4-5 hours for deliverable exercise