The Tokenization Tech Stack - How It Works

When tokenizers choose a blockchain, they evaluate multiple factors:

CRITICAL FACTORS FOR RWA TOKENIZATION:

- Finality time: How quickly is a transaction irreversible?
- Throughput: Transactions per second capacity
- Cost: Transaction fees
- Reliability: Uptime, network stability

- Consensus mechanism: How is the chain secured?
- Attack resistance: Cost to attack
- Track record: Historical security incidents
- Audit status: Code review history

- Smart contracts: Fully programmable (Ethereum) vs. native features (XRPL)
- Standards support: Available token standards
- Composability: Ability to interact with other protocols

- Compliance features: Built-in vs. smart contract-based
- Privacy options: Transaction privacy capabilities
- Regulatory acceptance: How regulators view the chain
- Enterprise support: Tooling, documentation, SLAs

ETHEREUM:

- Finality: ~15 minutes (probabilistic)
- Throughput: ~15-30 TPS (base layer)
- Cost: $5-50+ per transaction (varies widely)
- L2s: Arbitrum, Optimism offer cheaper execution

- Proof of Stake since 2022
- $60B+ staked
- Battle-tested smart contracts
- Numerous audit firms specialized

- Full smart contract capability (Solidity)
- ERC-20, ERC-721, ERC-3643, etc.
- Massive DeFi ecosystem
- Composability champion

- Most familiar to institutions
- Largest ecosystem of service providers
- Compliance via smart contracts (not native)
- Requires careful gas management

VERDICT: Dominant for flexibility, ecosystem; challenged on cost, native compliance

---

XRPL:

• Finality: 3-5 seconds (absolute)

• Throughput: ~1,500 TPS

• Cost: ~$0.0002 per transaction

• Consistent, predictable fees

• Unique Node List (UNL) consensus

• Operating since 2012

• Zero smart contract exploits (no smart contracts)

• $0 lost to protocol bugs

• No smart contracts (by design)

• Native features: DEX, AMM, tokens, escrow

• Hooks: Adding programmability (limited)

• Trade-off: Security vs. flexibility

• Native compliance features (freeze, clawback)

• Ripple as enterprise partner

• Ripple Custody (Metaco) integration

• Regulatory engagement history

VERDICT: Strong for speed, cost, compliance; limited programmability

STELLAR:

• Finality: 3-5 seconds

• Throughput: ~1,000 TPS

• Cost: ~$0.00001 per transaction

• Designed for payments

• Stellar Consensus Protocol

• Operating since 2014

• Simple, audited codebase

• Payment-focused (less attack surface)

• Limited smart contracts (Soroban, new)

• Native assets with control flags

• Payment-centric design

• Less DeFi composability

• Franklin Templeton chose Stellar for BENJI

• Compliance flags on assets

• Foundation focused on financial inclusion

• Strong in remittance/payment use cases

VERDICT: Excellent for simple tokens, payments; limited for complex DeFi

PROVENANCE:

• Cosmos-based

• Fast finality

• Low cost

• Purpose-built for finance

• Permissioned validators (banks)

• Less decentralized, more controlled

• Smart contracts available

• Figure-specific tooling

• Focused on loan lifecycle

• Built by/for institutions

• Figure dominates usage

• Most compliant by design

• Less public ecosystem

VERDICT: Winner in private credit; limited to specific use cases
```

USE CASE DETERMINES CHOICE:

For Maximum Ecosystem/DeFi:
→ Ethereum (or L2s)
Reason: Largest liquidity, most composability

For Regulated Securities (Compliance-First):
→ XRPL or Provenance
Reason: Native compliance features, institutional relationships

For Treasury/MMF Products:
→ Any major chain works
Reason: Simple structure, legal clarity more important than tech

For High-Volume Trading:
→ XRPL or Stellar
Reason: Low fees, fast settlement

For Private/Controlled Issuance:
→ Private chains or Provenance
Reason: Validator control, enterprise requirements

- Ondo: Ethereum, XRPL, Stellar, Solana
- OpenEden: Ethereum, XRPL, others
- BUIDL: 7+ chains

- Different investor bases per chain
- Risk diversification
- Reach DeFi on Ethereum, institutions on XRPL
- Hedge against chain-specific risks

---

Token standards specify how tokens behave: how they're created, transferred, stored, and what metadata they carry. Different standards serve different purposes.

TOKEN STANDARD COMPONENTS:

- Creation (minting): Who can create tokens?
- Transfer: How do tokens move between accounts?
- Balance query: How is ownership tracked?
- Destruction (burning): Can tokens be destroyed?

- Metadata: Name, symbol, decimals, URI
- Approval: Third-party spending rights
- Hooks: Actions triggered by transfers

- Freeze: Can transfers be stopped?
- Whitelist: Can holders be restricted?
- Clawback: Can tokens be recovered?
- Forced transfer: Admin override capability

ERC-20 (Basic Fungible Tokens):

- totalSupply(), balanceOf(), transfer()
- approve(), allowance(), transferFrom()

- No built-in compliance
- Anyone can hold if they have address
- No freeze or recovery mechanism
- Requires wrapping for restrictions

---

ERC-3643 (Security Token Standard):

• Identity registry (whitelist)
• Compliance checks on transfer
• Module system for rules
• Agent roles for administration

1. Investor submits identity for verification
2. Identity stored in on-chain registry
3. Each transfer checks:
4. Transfer succeeds only if compliant

• Programmable compliance

• Flexible rule modules

• Interoperable with ERC-20 ecosystem

• Added complexity

• Gas costs for compliance checks

• Smart contract risk

ERC-1400 (Hybrid Security Token):

• Partitioned balances (tranches)
• Document storage
• Transfer restrictions
• Operator privileges

Used by: Securitize, Polymath (legacy)

Status: Less common now; ERC-3643 gaining
```

XRPL takes a fundamentally different approach—compliance features are native to the protocol, not added via smart contracts.

TRUST LINE TOKENS (Original Standard):

1. Issuer creates account with settings
2. Holder establishes trust line to issuer
3. Issuer sends tokens to holder
4. Tokens trackable, tradeable on DEX

- Bidirectional: Can represent IOUs
- Explicit opt-in: Holder must trust issuer
- Account-level settings: Properties apply to all tokens from issuer
- Rippling: Tokens can flow through interconnected trust lines

- Require Auth: Only approved addresses can hold
- Freeze: Individual or global token freezing
- No Freeze: Permanent waiver of freeze capability
- Transfer Rate: Fee on transfers

- Native compliance (no smart contract)
- Simpler security model
- Built-in DEX trading
- Proven since 2012

- All tokens from issuer share settings
- Floating point math (rounding edge cases)
- No clawback in original design (added later)

---

MULTI-PURPOSE TOKENS (MPTs - New Standard):

• Trust lines have account-level properties

• MPTs allow token-level properties

• Better for issuers managing multiple distinct tokens

• Per-issuance settings (each token type independent)

• Fixed-point math (no rounding surprises)

• Unidirectional (cleaner model)

• No rippling (simpler)

• Token-level metadata

• Per-token freeze settings

• Per-token clawback (optional)

• Escrow compatible

• MPTokensV1 amendment active

• Growing adoption for new issuances

• Both standards supported long-term

XRPL COMPLIANCE FEATURES (Both Standards):

Freeze Capabilities:
┌─────────────────────┬─────────────────────────────────────┐
│ Feature │ Effect │
├─────────────────────┼─────────────────────────────────────┤
│ Individual Freeze │ One holder can't send (except back) │
│ Global Freeze │ No holder-to-holder transfers │
│ Deep Freeze (XLS-77)│ Can't send OR receive │
│ No Freeze │ Issuer permanently waives freeze │
└─────────────────────┴─────────────────────────────────────┘

• Issuer can retrieve tokens from any holder

• Must be enabled BEFORE any issuance

• Cannot be added to existing tokens

• Required for some regulated securities

• Only issuer-approved addresses can hold

• Enforces whitelist at protocol level

• Essential for securities compliance

STELLAR ASSET MODEL:

- Any account can issue assets
- Recipients establish trustlines (like XRPL)
- Control flags set by issuer

- Authorization Required: Whitelist-only
- Authorization Revocable: Can freeze
- Authorization Immutable: Cannot change settings

- Available with specific configuration
- Similar to XRPL approach

- Simple model
- Native compliance flags
- Designed for payments/remittances

- Less DeFi infrastructure
- Smaller ecosystem than Ethereum
- Limited programmability (Soroban changing this)

TOKEN STANDARD COMPARISON:

┌────────────────┬───────────┬───────────┬───────────┬───────────┐
│ Feature        │ ERC-20    │ ERC-3643  │ XRPL TL   │ XRPL MPT  │
├────────────────┼───────────┼───────────┼───────────┼───────────┤
│ Smart Contract │ Yes       │ Yes       │ No        │ No        │
│ Native Freeze  │ No        │ Yes(code) │ Yes       │ Yes       │
│ Native Clawback│ No        │ Yes(code) │ Yes*      │ Yes       │
│ Whitelist      │ No        │ Yes(code) │ Yes       │ Yes       │
│ Built-in DEX   │ No        │ No        │ Yes       │ Yes       │
│ Metadata       │ Limited   │ Moderate  │ Limited   │ Good      │
│ Composability  │ High      │ Moderate  │ Limited   │ Limited   │
│ Security Risk  │ Contract  │ Contract  │ Protocol  │ Protocol  │
│ Gas Costs      │ Variable  │ Higher    │ ~$0.0002  │ ~$0.0002  │
└────────────────┴───────────┴───────────┴───────────┴───────────┘

*Clawback added via Clawback amendment

Tokenization platforms handle the complexity between the asset and the blockchain:

ISSUANCE PLATFORM FUNCTIONS:

- Legal structure setup (SPVs, trusts)
- Documentation preparation
- Investor qualification (KYC/AML)
- Token design and configuration

- Smart contract deployment / token creation
- Initial distribution
- Cap table management
- Regulatory filing support

- Corporate actions (dividends, votes)
- Ongoing compliance
- Transfer agent services
- Investor relations

- Marketplace operation (some platforms)
- Transfer validation
- Trade settlement

SECURITIZE:

- SEC-registered transfer agent
- Broker-dealer (through affiliates)
- Multiple jurisdictions

- BlackRock (BUIDL)
- KKR, Hamilton Lane (funds)
- Ondo Finance

- Ethereum-first (ERC-3643)
- Multi-chain deployment
- DS Protocol

- Largest by institutional AUM
- ~$1B+ in issuances
- Gold standard for US securities

---

ARCHAX:

• FCA-regulated (UK)

• Digital exchange, broker, custodian

• EU/UK focused

• Ripple (close collaboration)

• abrdn (money market fund)

• Multiple asset managers

• Multi-chain (including XRPL)

• Proprietary tokenization engine

• Integrated custody

• Leading UK platform

• First tokenized MMF on XRPL

• Growing institutional adoption

TOKENSOFT:

• US transfer agent

• Multiple licenses

• Various smaller issuers

• DeFi protocols

• Multi-chain

• Various standards supported

• Mid-tier platform

• Good for smaller issuances

• More flexible than Securitize

CENTRIFUGE:

• Trade finance, real-world receivables

• DeFi-native approach

• Own chain (Centrifuge Chain)

• Ethereum integration

• Tinlake pools (legacy)

• ~$1B TVL

• Leader in trade finance

• MakerDAO integration (RWA collateral)

FIGURE (Provenance):

• HELOCs (dominant use case)

• Loan origination to tokenization

• Provenance blockchain (Cosmos)

• Purpose-built for loans

• Integrated origination

• $12B+ tokenized

• Single largest tokenization use case

• Vertically integrated

CHOOSING AN ISSUANCE PLATFORM:

- Licensed in your jurisdiction(s)?
- Experience with your asset class?
- Track record with regulators?
- Legal support quality?

- Supports your preferred blockchain(s)?
- Token standard flexibility?
- Integration capabilities?
- Secondary market options?

- Setup fees: $50K-500K typical
- Ongoing fees: 0.1-0.5% of AUM
- Transaction fees
- Hidden costs (customization, support)

- Transfer agent services?
- Investor relations tools?
- Corporate action handling?
- Customer support quality?

- Existing investor base?
- Distribution relationships?
- Brand credibility?
- Ecosystem partnerships?

---

Tokenized assets face unique custody requirements:

CUSTODY LAYERS:

- Physical assets (gold): Vault storage
- Securities: Traditional custodian
- Real estate: Title/deed custody
- Private credit: Loan documentation

- Private keys securing on-chain tokens
- Hot wallets (connected, higher risk)
- Cold wallets (offline, more secure)
- Multi-signature requirements

THE CHALLENGE:
Both layers must be secured, reconciled, and audited.
Traditional custodians know underlying assets.
Crypto custodians know keys.
Bridging both is non-trivial.

INSTITUTIONAL CUSTODY PROVIDERS:

- Acquired 2023
- Enterprise-grade security
- Multi-signature support
- Policy engine
- HSM integration
- XRPL native integration
- Clients: HSBC, Standard Chartered

- ~$8B valuation
- Multi-chain support
- MPC (Multi-Party Computation)
- Leading institutional choice
- No XRPL native (requires integration)

- First federally chartered crypto bank (US)
- Full-service custodian
- Insurance coverage
- Regulatory gold standard

- Traditional custodian adding digital
- Massive institutional relationships
- Conservative, trust-building

- Exchange-affiliated
- Strong US presence
- Retail to institutional

SELF-CUSTODY OPTIONS:

• Up to 32 signers

• Configurable quorum

• No third-party reliance

• Requires operational sophistication

• Ledger, Trezor support XRPL

• Air-gapped security

• Manual process for institutions

SECURITY APPROACHES:

MULTI-SIGNATURE (MULTISIG):
How it works: N-of-M signatures required
Example: 3-of-5 executives must sign
Pros: No single point of failure
Cons: Key management complexity, recovery challenges

MULTI-PARTY COMPUTATION (MPC):
How it works: Key shards distributed, never assembled
Example: 3 parties each hold key fragment
Pros: No complete key exists anywhere
Cons: Complex, vendor lock-in, newer technology

HARDWARE SECURITY MODULES (HSM):
How it works: Keys stored in tamper-resistant hardware
Example: Keys never leave physical device
Pros: Military-grade security
Cons: Expensive, physical access required

- MPC for hot wallet operations
- HSM for cold storage
- Multi-sig for governance
- Insurance for additional protection

---

THE ORACLE PROBLEM:

- Asset prices (NAV, market value)
- Interest rates
- Corporate actions
- Compliance status
- Reserve attestations

- Token prices can diverge from asset values
- Compliance cannot be verified on-chain
- Automated processes break down

ORACLE APPROACHES:

- Dominant oracle network
- Decentralized node operators
- Price feeds, proof of reserves
- Cross-chain capability
- Used by most DeFi protocols

- Native oracle standard
- Validators can provide price data
- Simpler than Chainlink
- Limited to XRPL ecosystem
- Still developing

- Single provider (e.g., Bloomberg)
- Simpler, faster
- Single point of failure
- Trust in provider required

- Proof of reserves (Chainlink POR)
- Auditor attestations on-chain
- Regular vs. real-time updates
- Example: PAXG gold reserves

RWA-SPECIFIC REQUIREMENTS:

• Daily NAV updates

• Distribution announcements

• Regulatory filings

• Loan status updates

• Payment confirmations

• Default notifications

• Property valuations

• Rental income data

• Occupancy status

XRPL ORACLE STATUS:

- XLS-47 Price Oracle standard exists
- Limited adoption so far
- Most RWAs use off-chain data

1. Off-chain data maintained by issuer
2. Regular attestations published
3. Smart contract (Hooks) can read oracle data
4. Limited automation compared to Ethereum

- Native oracle support improving
- Integration with external providers possible
- Ripple-sponsored development ongoing

Practical Reality:
Most XRPL RWAs today update off-chain.
On-chain verification through attestations.
Less automated than Ethereum DeFi.
Adequate for current institutional use cases.

COMPLIANCE REQUIREMENTS:

- Identity verification
- Document collection
- Sanctions screening
- PEP (Politically Exposed Person) checks

- Transaction monitoring
- Suspicious activity reporting
- Source of funds verification
- Ongoing due diligence

- Accredited investor verification
- Geographic restrictions
- Investment limits
- Suitability assessment

- Lock-up periods
- Volume limits
- Jurisdiction blocks
- Whitelist enforcement

- Regulatory filings
- Tax reporting
- Audit trails
- Investor communications

COMPLIANCE IMPLEMENTATION MODELS:

ETHEREUM MODEL (Smart Contract-Based):
┌─────────────────────────────────────────┐
│ ERC-3643 Token Contract                 │
│   │                                     │
│   ├── Identity Registry (on-chain)      │
│   │     └── Verified investor list      │
│   │                                     │
│   ├── Compliance Module (on-chain)      │
│   │     └── Transfer rules coded        │
│   │                                     │
│   └── Agent Roles (on-chain)            │
│         └── Admin permissions           │
└─────────────────────────────────────────┘
Pros: Automated, transparent, auditable
Cons: Gas costs, immutable bugs, complexity

XRPL MODEL (Native Protocol):
┌─────────────────────────────────────────┐
│ XRPL Account + Trust Lines/MPTs         │
│   │                                     │
│   ├── Authorized Trust Lines (native)   │
│   │     └── Whitelist at protocol level │
│   │                                     │
│   ├── Freeze Capability (native)        │
│   │     └── Built into protocol         │
│   │                                     │
│   └── Issuer Account Settings           │
│         └── No smart contract needed    │
└─────────────────────────────────────────┘
Pros: Simpler, no contract risk, cheaper
Cons: Less flexible, binary (on/off)

HYBRID MODEL (Most RWA Projects):
┌─────────────────────────────────────────┐
│ Off-Chain                               │
│   ├── KYC/AML providers (Onfido, etc.)  │
│   ├── Investor databases                │
│   └── Compliance workflows              │
│                                         │
│ On-Chain                                │
│   ├── Whitelist of verified addresses   │
│   ├── Transfer restrictions             │
│   └── Freeze/clawback capabilities      │
│                                         │
│ Integration                             │
│   └── API connecting off-chain → on-chain│
└─────────────────────────────────────────┘
Most practical for current regulatory requirements.

WHY XRPL'S NATIVE APPROACH MATTERS:

- Ethereum compliance = smart contract code
- Smart contract bugs = compliance failures
- XRPL compliance = protocol features
- Protocol tested since 2012

- Auditing smart contracts expensive
- XRPL features are known, documented
- Regulators can understand native features
- No custom code to review

- Ethereum: Gas for every compliance check
- XRPL: Same low fee regardless of complexity
- At scale: Significant cost difference

- Banks prefer known, simple systems
- Smart contract complexity = risk
- Native features = less explanation needed

THE TRADE-OFF:
Less flexibility than smart contracts.
Can't implement arbitrary complex rules.
But: Most RWA compliance is simple whitelist + freeze.
XRPL's native features handle 90%+ of use cases.

The tokenization tech stack is maturing but not mature. Multiple workable approaches exist with different trade-offs. XRPL's native compliance features (freeze, clawback, authorized trust lines) provide genuine differentiation for regulated securities—simpler, cheaper, and lower risk than smart contract-based compliance. However, this simplicity comes at the cost of flexibility, and XRPL lacks the deep DeFi ecosystem that makes Ethereum attractive for composability. For institutional RWA use cases focused on compliance and settlement, XRPL's architecture is well-suited. For complex DeFi integration, Ethereum remains stronger. Most sophisticated issuers deploy multi-chain to access both capabilities.

Assignment: Create a decision framework for selecting the appropriate tokenization tech stack for different use cases.

Requirements:

• Asset class (treasury, credit, real estate, etc.)
• Regulatory requirements (US securities, EU, unregulated)
• Target investors (institutional, retail, DeFi)
• Composability needs (DeFi integration, standalone)
• Budget constraints

Part 2: Blockchain Evaluation (25%)
For three scenarios, recommend the optimal blockchain and justify:

Scenario A: Tokenized US Treasury fund for institutional investors, SEC-registered, $100M+ target
Scenario B: Trade finance receivables for DeFi yield, minimal regulation, global investors
Scenario C: Regulated security token for EU retail investors, MiCA-compliant

• Regulatory coverage

• Technology capability

• Cost structure

• Strategic fit for XRPL-focused projects

• Smart contract/protocol risk

• Custody/key management risk

• Oracle/data integrity risk

• Platform/vendor risk

• Interoperability risk

• Logical structure of decision framework (25%)

• Quality of blockchain recommendations (25%)

• Depth of platform assessment (25%)

• Thoroughness of risk analysis (25%)

Time Investment: 2 hours
Value: Reusable framework for evaluating any tokenization project's technical architecture

For Next Lesson:
Lesson 4 will examine the regulatory landscape for tokenization—the make-or-break factor that determines where tokenization can scale. We'll analyze US, EU, Asia-Pacific, and Middle East frameworks and their implications for XRPL adoption.

End of Lesson 3

Total words: ~5,800
Estimated completion time: 55 minutes reading + 2 hours for deliverable exercise