XRPL Transaction Lifecycle Analysis - Where Time Goes

Every XRPL transaction passes through seven distinct stages:

Stage 1: Transaction Creation (Client-side)
    ↓ ~1-10ms
Stage 2: Network Submission
    ↓ ~50-200ms
Stage 3: Server Reception & Initial Validation  
    ↓ ~5-50ms
Stage 4: Transaction Propagation
    ↓ ~100-500ms
Stage 5: Consensus Proposal & Voting
    ↓ ~2,000-4,000ms
Stage 6: Transaction Execution
    ↓ ~10-100ms
Stage 7: State Finalization
    ↓ ~50-200ms
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total: ~2,200-5,000ms (typically ~4,000ms)

Let's examine each stage in detail.

What happens: Your wallet or application constructs the transaction object, serializes it, and signs it with your private key.

Components:

1. Object Construction: ~0.1ms

1. Serialization: ~0.5ms

1. Signing: ~1-10ms

1. Encoding: ~0.2ms

Total: 2-12ms (software wallet)
Total: 500-2000ms (hardware wallet)

• Entirely client-side (not network-dependent)

• Parallelizable (client can prepare multiple transactions)

• Hardware wallets are the bottleneck for high-volume submitters

• Not an optimization target for network performance

• Pre-compute and cache signatures for predictable transactions

• Use software keys for high-frequency automated operations

• Batch transaction construction

What happens: The signed transaction travels from client to an XRPL server (either public or your own node).

Network path:

Client (your app/wallet)
    ↓
DNS resolution: 1-50ms (cached: <1ms)
    ↓
TCP connection: RTT/2 (~25-100ms)
    ↓
TLS handshake: 1-2 RTT (~50-200ms for new connection)
    ↓
HTTP/WebSocket frame: ~5ms
    ↓
Server receives transaction

Total (new connection): 80-350ms
Total (existing WebSocket): 25-100ms

Geographic impact:

Client → Server latency by geography:

Same data center: <5ms
Same region: 10-30ms
Cross-continent (US→EU): 80-120ms
Global (US→Asia): 150-250ms
Satellite internet: 500-700ms

- Colocate with XRPL infrastructure
- Use regional endpoints
- Maintain persistent connections

- Network latency is physics-bound (speed of light)
- Can be optimized with connection pooling
- Not parallelizable (single transaction submission)
- First significant latency contributor

What happens: The receiving server performs preliminary validation before propagating the transaction to the network.

Validation steps:

1. Deserialization: ~1ms

1. Signature Verification: ~2-5ms

1. Format Validation: ~0.5ms

1. Sequence Check: ~1-2ms

1. Balance Check: ~1-2ms

Total: 5-15ms (simple payment)
Total: 10-50ms (complex transaction)

Why signature verification dominates:

ECDSA verification breakdown:

Modular exponentiation: ~1.5ms
Point multiplication: ~1.0ms
Hash computation: ~0.1ms
Comparison operations: ~0.1ms
─────────────────────────────
Total: ~2.7ms per signature

- 5 signature verifications: ~13.5ms
- Significantly slower than single-sign

- Signature verification is CPU-bound
- Currently single-threaded (optimization opportunity)
- State lookups require database access
- First point where transaction can be rejected

What happens: Valid transactions are broadcast to all connected peers, eventually reaching all validators.

Gossip protocol operation:

Server A receives transaction
    ↓
Broadcasts to peers (typically 10-50 connections)
    ↓
Each peer validates & broadcasts to their peers
    ↓
Exponential propagation until all nodes have transaction

- Hop 1: reaches ~50 nodes in ~100ms
- Hop 2: reaches ~500 nodes in ~200ms
- Hop 3: reaches ~1000+ nodes in ~300ms
- Full propagation: ~300-500ms

Network topology impact:

Node connectivity affects propagation:

- Receives transactions quickly
- Propagation adds ~100-200ms

- Multiple hops required
- Propagation adds ~300-500ms

- US-EU propagation: +80ms
- US-Asia propagation: +150ms
- Full global reach: +200-300ms

Deduplication overhead:

• Each node receives same transaction from multiple peers

• Must detect and ignore duplicates

• Hash-based deduplication: ~0.1ms per check

• With 50 peers: ~5ms total deduplication overhead

• 1,000 transactions/second incoming

• 50 peers each

• 50,000 deduplication checks/second

• Becomes measurable overhead

What happens: Validators propose transactions for inclusion, vote across multiple rounds, and reach agreement on the ledger contents.

Consensus round structure:

Round 1 - Initial Proposals (50% threshold):
├── Validators propose their pending transactions
├── Exchange proposals with UNL peers
├── Include transactions seen by >50% of UNL
├── Time: 500-1000ms

Round 2 - Narrowing (60% threshold):
├── Re-evaluate based on Round 1 results
├── Discard transactions below 60% support
├── Time: 500-1000ms

Round 3 - Convergence (70% threshold):
├── Further narrowing
├── Most transactions now have clear status
├── Time: 500-1000ms

Round 4 - Finalization (80% threshold):
├── Final vote on remaining transactions
├── Achieve 80%+ agreement
├── Ledger contents determined
├── Time: 500-1000ms

Total consensus time: 2,000-4,000ms

Why consensus takes so long:

Consensus timing is bound by:

1. Network RTT between validators

1. Validator processing time

1. Safety margins

- Minimum = 4 × network_RTT + processing
- With 100ms RTT: 400ms minimum
- With safety margins: ~2000ms practical minimum

Consensus is the critical path:

Critical path analysis:

- Transaction creation (pre-consensus)
- Transaction propagation (concurrent)
- Some validation (between rounds)

- Consensus rounds (sequential by design)
- Must wait for agreement

- Amdahl's Law limits speedup to ~4x
- Consensus timing sets floor on latency
- More hardware doesn't help consensus speed

What happens: Once consensus determines ledger contents, transactions are executed in deterministic order.

Execution steps:

1. Transaction ordering: ~1ms

1. Balance updates: ~1-5ms per transaction

1. Fee burning: ~0.1ms

1. Object creation (if applicable): ~5-20ms

1. State transitions: ~1-10ms

Total execution: 10-50ms per ledger

Transaction type matters:

Execution cost by transaction type:

- Update two account balances
- Minimal state changes

- Pathfinding (pre-calculated)
- Multiple balance updates
- Order book interactions

- Order book insertion
- Possible matching and execution
- Multiple state updates

- Pool state updates
- LP token calculations
- Price curve evaluation

- Object creation
- URI storage
- Index updates

What happens: The new ledger state is committed, hashed, and propagated as the canonical chain state.

Finalization steps:

1. Merkle tree update: ~20-50ms

1. Database commit: ~10-30ms

1. Ledger propagation: ~50-100ms

1. Cleanup: ~5-10ms

Total finalization: 50-200ms

This is when finality is achieved:

Finality moment:

Transaction submitted → ... → Ledger validated
                              ↑
                         THIS IS FINALITY

- Transaction is irreversible
- No reorganization possible
- Safe to act on (release goods, etc.)

- Bitcoin: ~60 minutes for reasonable certainty
- Ethereum: ~15 minutes for reasonable certainty
- XRPL: ~4 seconds for absolute certainty

---

The critical path is the longest sequence of dependent operations—the minimum time even with perfect parallelization of everything else.

XRPL Critical Path:

Client signing          [====]        ~5ms
     ↓
Network submission           [====]   ~100ms
     ↓
Server validation                [==] ~10ms
     ↓
Propagation                       [======] ~300ms
     ↓
Consensus Round 1                         [==========] ~750ms
     ↓
Consensus Round 2                                     [==========] ~750ms
     ↓
Consensus Round 3                                                 [==========] ~750ms
     ↓
Consensus Round 4                                                             [==========] ~750ms
     ↓
Execution                                                                                 [==] ~30ms
     ↓
Finalization                                                                                  [===] ~100ms

Critical path total: ~3,545ms (typical 4 seconds)

What can be parallelized:

Operations that can run concurrently with the critical path:

- Other clients submitting other transactions ✓
- Server preparing for validation ✓

- Multiple transactions propagating simultaneously ✓
- Validators receiving multiple transactions ✓

- Transaction validation (between rounds) ✓
- Next batch preparation ✓

Key insight: 
Individual transaction latency is fixed by critical path.
System throughput improves by parallelizing across transactions.

Let's quantify where the 4 seconds actually goes:

Time Budget Allocation:

1. Creation        |     5     |    0.1%    | Yes (client)
2. Submission      |   100     |    2.5%    | Partially
3. Validation      |    10     |    0.3%    | Yes
4. Propagation     |   300     |    7.5%    | Yes
5. Consensus       | 3,000     |   75.0%    | No (serial)
6. Execution       |    30     |    0.8%    | Partially
7. Finalization    |   100     |    2.5%    | Partially

Consensus dominates at 75% of total time.

Despite consensus taking 75% of time, consensus is not the bottleneck for throughput.

Here's the counterintuitive insight:

Bottleneck analysis:

- Each round can include thousands of transactions
- Time is fixed regardless of transaction count
- More transactions = higher throughput at same latency

- Signature verification: 2.7ms per transaction
- 1,500 TPS = 4,050ms of verification per second
- Exceeds available CPU time on single core

The bottleneck is validation, not consensus.

- If we could validate infinitely fast:

- With current validation speed:

- 8 cores validating in parallel
- 8 × 375 = 3,000 TPS potential
- Consensus can handle this easily

**Investment Implication:** Optimization effort should focus on signature verification parallelization, not consensus acceleration. Parallel validation can double or triple effective throughput without protocol changes.

---

The baseline case:

Simple XRP Payment:
A sends 100 XRP to B

Processing breakdown:
├── Signature verification: 2.7ms
├── Balance check: 0.5ms
├── Sequence check: 0.5ms
├── Fee deduction: 0.1ms
├── Balance update (2 accounts): 0.5ms
└── Total execution: ~4.3ms

Network overhead: ~400ms (propagation + consensus share)
───────────────────────────────────────────────
Total processing cost: ~4.7ms
Effective throughput: ~212 simple payments/core/second

Creating or modifying trust lines:

Trust Line Creation:
A establishes trust to B's issued currency

Processing breakdown:
├── Signature verification: 2.7ms
├── Trust line check (exists?): 1.0ms
├── Reserve calculation: 0.5ms
├── Object creation: 5.0ms
├── Index updates: 2.0ms
├── Balance updates: 0.5ms
└── Total execution: ~11.7ms

2.7x more expensive than simple payment.
Effective throughput: ~85 trust lines/core/second

Order book interactions:

DEX Offer Create:
A offers to sell 1000 XRP for 500 USD

Processing breakdown:
├── Signature verification: 2.7ms
├── Balance verification: 0.5ms
├── Order book query: 3.0ms
├── Matching check: 5.0ms
├── Object creation: 5.0ms
├── Index updates: 3.0ms
└── Total execution: ~19.2ms

With matching (offer crosses existing):
├── All above: 19.2ms
├── Match execution: 10.0ms
├── Additional balance updates: 2.0ms
└── Total: ~31.2ms

4.4-7.2x more expensive than simple payment.
Effective throughput: ~32-52 DEX ops/core/second

Automated Market Maker interactions:

AMM Swap:
A swaps 100 XRP for equivalent USD via AMM pool

Processing breakdown:
├── Signature verification: 2.7ms
├── Pool state query: 2.0ms
├── Price calculation (constant product): 1.0ms
├── Slippage check: 0.5ms
├── Pool balance updates: 3.0ms
├── User balance updates: 1.0ms
├── LP share recalculation: 2.0ms
├── Fee distribution: 1.0ms
└── Total execution: ~13.2ms

LP operations (add/remove liquidity):
├── Additional share calculations: 5.0ms
├── Multiple token transfers: 4.0ms
└── Total: ~22.2ms

3-5x more expensive than simple payment.
Effective throughput: ~45-75 AMM ops/core/second

Token minting and transfer:

NFT Mint:
A creates NFT with URI and metadata

Processing breakdown:
├── Signature verification: 2.7ms
├── NFT ID generation: 1.0ms
├── Object creation: 8.0ms
├── URI storage: 5.0ms (depends on length)
├── Index updates: 3.0ms
├── Collection linkage: 2.0ms
└── Total execution: ~21.7ms

With large metadata:
├── Extended URI processing: +10-50ms
└── Total: 30-70ms

5-16x more expensive than simple payment.
Effective throughput: ~14-46 NFT mints/core/second

Real-world performance depends on transaction mix:

Example workload compositions:

- 95% simple payments
- 5% trust line operations
- Weighted cost: 4.3×0.95 + 11.7×0.05 = 4.67ms
- Effective throughput: ~214 TPS/core

- 20% simple payments
- 70% DEX operations
- 10% trust lines
- Weighted cost: 4.3×0.2 + 19.2×0.7 + 11.7×0.1 = 15.5ms
- Effective throughput: ~64 TPS/core

- 10% simple payments
- 30% NFT mints
- 60% NFT transfers
- Weighted cost: 4.3×0.1 + 21.7×0.3 + 8×0.6 = 12.1ms
- Effective throughput: ~82 TPS/core

Workload mix can cause 3x variation in effective throughput.

---

Location affects end-to-end timing:

Client location impact on submission latency:

- Submission: 50ms
- Propagation advantage: -50ms
- Effective latency: 3.9 seconds

- Submission: 80ms
- Propagation: normal
- Effective latency: 4.0 seconds

- Submission: 100ms
- Cross-Atlantic propagation: +50ms
- Effective latency: 4.1 seconds

- Submission: 200ms
- Trans-Pacific propagation: +100ms
- Effective latency: 4.3 seconds

Global variation: 3.9-4.3 seconds (10% range)

When the network is busy:

• Validation queuing: 0ms

• Propagation queuing: 0ms

• Total: ~4.0 seconds

• Validation queuing: 5-10ms

• Propagation bandwidth: adequate

• Total: ~4.0-4.1 seconds

• Validation queuing: 50-200ms

• Propagation congestion: 50-100ms

• Total: ~4.2-4.5 seconds

• Validation queuing: 200-500ms

• Some transactions delayed to next ledger

• Total: ~4.5-8.0 seconds (spans ledgers)

• Transactions rejected

• Fee-based prioritization kicks in

• Unpredictable latency

Transaction fees affect prioritization:

• Processed normally at low load

• May be deprioritized at high load

• Priority processing during congestion

• Guaranteed inclusion if technically valid

• Highest priority

• Used for urgent transactions

Fee escalation during congestion:

Load	Min Fee for Guarantee
<50%	10 drops
50-70%	15-20 drops
70-90%	50-100 drops

90% | 500-1000+ drops

Applications should implement dynamic fee adjustment.

---

For capacity planning, model expected latency:

Latency model:

E[Latency] = T_fixed + T_queue + T_propagation + T_consensus

Where:
T_fixed = 500ms (minimum processing overhead)
T_queue = f(utilization) from queuing theory
T_propagation = g(geography) + network_jitter
T_consensus = ~3000ms (relatively stable)

Example calculations:

Scenario: US East client, normal load
T_fixed = 500ms
T_queue = 0ms (low utilization)
T_propagation = 100ms
T_consensus = 3000ms
E[Latency] = 3,600ms

Scenario: Asia client, high load
T_fixed = 500ms
T_queue = 200ms (80% utilization)
T_propagation = 300ms
T_consensus = 3200ms (slightly longer during load)
E[Latency] = 4,200ms
```

Beyond average, estimate distribution:

Latency distribution model:

p50 (median):    ~E[Latency]
p90:             ~E[Latency] × 1.2
p95:             ~E[Latency] × 1.4
p99:             ~E[Latency] × 2.0

Example for E[Latency] = 4000ms:

p50: 4,000ms (typical experience)
p90: 4,800ms (most users)
p95: 5,600ms (almost all users)
p99: 8,000ms (tail, rare cases)

During congestion (E[Latency] = 5000ms):

p50: 5,000ms
p90: 6,000ms
p95: 7,000ms
p99: 10,000ms

Plan for p99, not p50.
```

Based on latency analysis:

Recommended timeout settings:

- Default timeout: 15 seconds
- Retry after: 20 seconds
- Max retries: 3
- Total max wait: 60 seconds

- Default timeout: 30 seconds
- Retry after: 45 seconds
- Max retries: 3
- Total max wait: 135 seconds

- Default timeout: 8 seconds
- Retry after: 10 seconds
- Max retries: 5
- Total max wait: 50 seconds

Never set timeout < 6 seconds (minimum possible confirmation)

---

✅ Consensus dominates latency (75% of time) — but consensus throughput is not the bottleneck. The ~3 seconds of consensus rounds are relatively fixed regardless of transaction count.

✅ Signature verification is the throughput bottleneck — at 2.7ms per signature, single-threaded validation caps throughput around 370 TPS per core. Parallelization can multiply this.

✅ Transaction type significantly affects cost — NFT mints can be 16x more expensive than simple payments. Workload mix can reduce effective throughput by 3x.

⚠️ Exact timing under extreme load — XRPL has rarely operated near capacity for extended periods. The queuing models are theoretical; real behavior may differ.

⚠️ Future transaction type costs — Hooks (smart contracts) will add new transaction types with unknown performance characteristics.

⚠️ Validator hardware heterogeneity — timing estimates assume typical hardware. Some validators may be faster or slower, affecting consensus timing.

📌 Assuming simple payment performance for complex workloads — benchmark TPS numbers use simple payments. DEX-heavy or NFT-heavy applications should expect 2-5x lower throughput.

📌 Ignoring geographic distribution — clients far from validator concentration will experience 10-20% higher latency.

📌 Setting timeouts too aggressively — network congestion can temporarily push latency to 8-10+ seconds. Timeouts under 10 seconds risk unnecessary retries.

XRPL's 4-second latency is primarily set by consensus timing, which is difficult to reduce without protocol changes. Throughput, however, is limited by signature verification—a problem solvable with parallel processing. Understanding this distinction is essential for identifying realistic optimization opportunities.

---

Assignment: Instrument and analyze actual XRPL transaction timing across multiple transaction types and network conditions.

Requirements:

Part 1: Timing Instrumentation

• Submit 10 simple payments, recording timestamps at each stage
• Submit 5 trust line creations
• Submit 5 DEX offers
• Document: submission time, first server response, ledger inclusion, validation

Part 2: Latency Breakdown

• Calculate time in each stage (submission, propagation, consensus, finality)
• Identify which stage dominated latency
• Calculate mean, p50, p90, p99 for each transaction type

Part 3: Geographic Comparison

• Note submission endpoint location
• Compare latency to baseline
• Document propagation time differences

Part 4: Workload Mix Modeling

• Calculate expected throughput for 3 different workload mixes:

• Compare to published XRPL benchmarks

• Explain any discrepancies

• Accurate timestamp collection and calculation (30%)

• Statistical rigor in analysis (percentiles, not just averages) (25%)

• Insight quality from workload modeling (25%)

• Documentation clarity (20%)

Time investment: 3-4 hours
Value: Empirical data grounds theoretical models; you'll know actual performance, not just claimed performance.

Submission format: Report with timestamped transaction data, calculations, and analysis.

---

For Next Lesson:
Lesson 3 will deep-dive into consensus performance—examining why consensus rounds take 3 seconds, what the theoretical minimum is, and whether there's any path to faster consensus without sacrificing safety.

---

End of Lesson 2

Total words: ~6,500
Estimated completion time: 55 minutes reading + 3-4 hours for deliverable exercise