Building on XRPL - The Developer Perspective
Learning Objectives
Understand hybrid architecture patterns required for XRPL gaming (on-chain + off-chain)
Evaluate developer tooling maturity and its impact on project execution
Identify technical red flags in gaming project architecture claims
Assess team technical capability based on architecture decisions
Compare XRPL development experience to competing platforms
Native XRPL Capabilities:
What XRPL Handles Natively:
✅ NFT ownership records (XLS-20)
✅ NFT transfers and trading
✅ Payment settlement (XRP and tokens)
✅ Offer management (buy/sell orders)
✅ Account management
✅ Multi-signature transactions
✅ Escrow (time-locked payments)
What XRPL Cannot Handle:
❌ Arbitrary computation (no smart contracts)
❌ On-chain game logic
❌ Dynamic NFT attributes (can't update on-chain)
❌ Complex conditional logic
❌ Randomness generation
❌ State machines beyond payments
Since XRPL can't run game logic, all XRPL games use hybrid architecture:
┌─────────────────────────────────────────────────────────┐
│ GAME LAYER (Off-Chain) │
│ - Battle logic and calculations │
│ - Player progression tracking │
│ - Real-time game state │
│ - Database (MySQL, PostgreSQL, etc.) │
└─────────────────────────────────────────────────────────┘
↕ Synchronization
┌─────────────────────────────────────────────────────────┐
│ BLOCKCHAIN LAYER (XRPL) │
│ - NFT ownership verification │
│ - NFT transfers and trades │
│ - XRP payments (rewards, purchases) │
│ - Royalty enforcement │
└─────────────────────────────────────────────────────────┘The Honest Reality:
You must trust the game operator
Game logic is not verifiable on-chain
Server shutdown = game death
True asset ownership (can trade outside game)
Transparent ownership history
Guaranteed royalties for creators
- Performance: Game logic runs at database speeds
- Flexibility: Can update game logic without blockchain changes
- Cost: Most operations are free (off-chain)
- Centralization: Game servers are single point of failure
- Trust: Players trust operator to run fair game logic
- Permanence: If servers shut down, game is gone
Official Libraries:
Most commonly used
Full XRPL functionality
NFT operations supported
npm install xrpl
Full functionality
pip install xrpl-py
Enterprise applications
Basic NFT Operations:
// Connect to XRPL
const client = new xrpl.Client('wss://xrplcluster.com/')
await client.connect()
// Check NFT ownership
const nfts = await client.request({
command: 'account_nfts',
account: playerWalletAddress
})
// Mint new NFT
const mintTx = {
TransactionType: 'NFTokenMint',
Account: issuerAddress,
NFTokenTaxon: gameItemCategory,
TransferFee: 500, // 5% royalty
URI: xrpl.convertStringToHex('ipfs://QmMetadata...')
}
| Tool Category | XRPL | Ethereum | Solana |
|------------------|---------------|---------------|---------------|
| Main SDK | xrpl.js | ethers.js | @solana/web3 |
| Documentation | Good | Excellent | Good |
| Tutorials | Limited | Extensive | Good |
| Game SDKs | None | Several | Some |
| Unity Plugin | Community | Official | Community |
| Unreal Plugin | None | Available | Available |Flow:
1. Player connects wallet (XUMM, Crossmark)
2. Game server queries XRPL for player's NFTs
3. Server verifies ownership of required items
4. Player granted access based on holdingsFlow:
1. Player completes game action
2. Game server determines reward amount
3. Server signs XRP payment transaction
4. Player receives XRP in wallet (3-5 seconds)Flow:
1. Player lists item for sale
2. Game creates NFTokenOffer transaction
3. Another player accepts offer
4. NFT transfers, payment settles automatically
5. Royalties enforced at protocol levelGame state (off-chain) must match blockchain state (on-chain):
- Player owns "Sword #123" (on-chain)
- Player sells sword during gameplay
- Game state now inconsistent
- Lock items during gameplay
- Periodic sync checks
- Real-time XRPL monitoring
NFT attributes can't change on-chain, but games want progression:
Solution: Off-chain stats
- NFT is ownership proof only
- Stats stored in game database
- Most common approach- XUMM (Xaman): Mobile-first, good UX
- Crossmark: Browser extension
- GemWallet: Browser extension
Reality: Wallet friction limits mainstream adoption
```
🔴 "Fully on-chain game logic"
- XRPL can't do this
🔴 "Decentralized gameplay"
- Game servers are centralized
🔴 "Dynamic NFTs with on-chain attributes"
- XLS-20 attributes set at mint, can't change
🔴 "Smart contract-powered game"
- XRPL doesn't have smart contracts
✅ Clear hybrid architecture explanation
✅ Open source or verifiable code
✅ Acknowledged tradeoffs
✅ Realistic scope matching XRPL capabilities1. Why do all XRPL games use hybrid architecture?
A) It's cheaper
B) XRPL has no smart contracts to run game logic
C) Players prefer it
D) Regulations require it
Correct Answer: B
2. Can NFT stats improve on-chain as you play on XRPL?
A) Yes, XLS-20 supports dynamic updates
B) Yes, through smart contracts
C) No, attributes are set at mint and cannot change on-chain
D) Yes, using Hooks
Correct Answer: C
3. If an XRPL game's servers shut down, what happens to NFTs?
A) NFTs are destroyed
B) NFTs persist but lose gameplay utility
C) NFTs continue working normally
D) NFTs transfer to backup
Correct Answer: B
End of Lesson 8
Key Takeaways
Hybrid architecture is mandatory
: All XRPL games use off-chain servers for gameplay with XRPL for ownership/payments.
Developer tooling is functional but limited
: xrpl.js works well, but gaming-specific SDKs lag behind competitors.
Technical red flags reveal misunderstanding
: Claims of on-chain game logic on XRPL indicate problems.
Server dependency is unavoidable
: Server shutdown stops gameplay even though NFT ownership persists.
Evaluation should focus on architecture honesty
: Good projects clearly explain what's on-chain vs. off-chain. ---