Technology Infrastructure Requirements | Market Making with XRP | XRP Academy - XRP Academy
XRPAcademy
Course Progress0/12
3 free lessons remaining this month

Free preview access resets monthly

Upgrade for Unlimited
Skip to main content
advanced•50 min

Technology Infrastructure Requirements

Learning Objectives

Specify connectivity requirements for different venues and strategies

Design an order management system appropriate for your scale

Implement essential risk monitoring and controls

Evaluate build vs. buy tradeoffs for each component

Budget technology costs as a percentage of expected revenue

In market making, technology isn't just operational infrastructure—it's competitive advantage. The market maker with faster execution, better risk monitoring, and more reliable systems will outperform one with inferior technology, all else equal.

But technology also costs money and time. Over-engineering destroys returns just as surely as under-investing. The key is matching your technology investment to your strategy and scale.

Different strategies require different connectivity levels:

CONNECTIVITY TIERS

- REST API for orders and data
- WebSocket for market data streaming
- Latency: 100ms-1s
- Cost: Free (within rate limits)
- Suitable for: XRPL DEX, low-frequency CEX strategies

- Premium WebSocket feeds
- Higher rate limits
- Latency: 10-100ms
- Cost: $0-500/month (exchange dependent)
- Suitable for: Active CEX market making

- Servers physically near exchange matching engines
- Direct network connections
- Latency: <1ms
- Cost: $2,000-20,000/month
- Suitable for: HFT strategies on major CEXs

- FPGA-based execution
- Dedicated network infrastructure
- Latency: Microseconds
- Cost: $50,000+/month
- Suitable for: Top-tier HFT firms

XRPL CONNECTION OPTIONS
  • Endpoints: wss://xrplcluster.com, wss://s1.ripple.com
  • Latency: 50-500ms
  • Rate limits: 10-100 requests/second
  • Reliability: Good but not guaranteed
  • Cost: Free
  • Suitable for: Testing, low-volume production
  • Examples: QuickNode, Infura (where available)
  • Latency: 20-100ms
  • Rate limits: Higher (plan dependent)
  • Reliability: SLA-backed
  • Cost: $50-500/month
  • Suitable for: Production market making
  • Run your own rippled instance
  • Latency: Network dependent, typically 10-50ms
  • No rate limits
  • Reliability: Self-managed
  • Cost: $50-300/month (server) + maintenance
  • Suitable for: Serious operations

CEX CONNECTIVITY

  • Standard API: Free, rate-limited
  • VIP API: Higher limits with volume thresholds
  • Co-location: Available at major venues
  • WebSocket: Essential for market data
  • CEX: Standard or VIP API (Tier 1-2)
  • XRPL: Self-hosted node or provider (Tier 2)
RECOMMENDED NETWORK ARCHITECTURE

Simple setup (single venue):
┌──────────────┐ ┌──────────────┐
│ Your Server │────▶│ Exchange │
│ (Cloud/VPS) │◀────│ API │
└──────────────┘ └──────────────┘

Multi-venue setup:
┌──────────────┐ ┌──────────────┐
│ │────▶│ Binance API │
│ │◀────│ │
│ │ └──────────────┘
│ Your Server │ ┌──────────────┐
│ │────▶│ Kraken API │
│ │◀────│ │
│ │ └──────────────┘
│ │ ┌──────────────┐
│ │────▶│ XRPL Node │
│ │◀────│ │
└──────────────┘ └──────────────┘

Production setup with redundancy:
┌──────────────┐ ┌──────────────┐
│ Primary │────▶│ │
│ Server │◀────│ │
└──────────────┘ │ Exchanges │
│ │ + │
│ Failover │ XRPL Node │
│ │ │
┌──────────────┐ │ │
│ Backup │────▶│ │
│ Server │◀────│ │
└──────────────┘ └──────────────┘
```

ORDER MANAGEMENT SYSTEM REQUIREMENTS
  1. Order creation and submission
  2. Order status tracking
  3. Position tracking across venues
  4. Fill reconciliation
  5. Cancel/modify capabilities
  1. Order queuing during disconnection
  2. Duplicate order prevention
  3. Sequence number management (XRPL)
  4. Rate limit compliance
  5. Error handling and retry logic
  1. Smart order routing
  2. Cross-venue order coordination
  3. Execution analytics
  4. Audit logging
OMS COMPONENT ARCHITECTURE

┌─────────────────────────────────────────────────────┐
│ Strategy Layer │
│ (Quote calculation, inventory management, etc.) │
└────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Order Management System │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Order │ │ Position │ │ Risk │ │
│ │ Router │ │ Tracker │ │ Checks │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Fill │ │ State │ │ Audit │ │
│ │ Processor │ │ Manager │ │ Log │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ Exchange Connectors │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Binance │ │ Kraken │ │ XRPL │ ... │
│ │ Adapter │ │ Adapter │ │ Adapter │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
```

CRITICAL STATE TO TRACK
  • Order ID (internal and exchange)
  • Status (pending, open, partial, filled, cancelled)
  • Side, price, size (original and remaining)
  • Venue
  • Timestamps (created, submitted, acknowledged, filled)
  • Fill history
  • Net position by asset
  • Average entry price
  • Unrealized P&L
  • Position age
  • Connection status
  • Open order count
  • Available balance
  • Recent latency
  • Total P&L (realized + unrealized)
  • Total exposure
  • Risk metric status

STATE PERSISTENCE

Minimum: In-memory with periodic snapshots
Better: Database-backed with transaction log
Best: Event-sourced with full replay capability

For market making, in-memory with hourly snapshots
is usually sufficient. Full persistence adds complexity
without proportional benefit for most operations.
```

PRE-TRADE RISK CONTROLS

Before every order submission, verify:

  1. Position limit check

  2. Order size check

  3. Price sanity check

  4. Rate limit check

  5. Balance check

IMPLEMENTATION

def pre_trade_check(order):
if would_breach_position_limit(order):
return REJECT, "Position limit"
if order.size > MAX_ORDER_SIZE:
return REJECT, "Order too large"
if abs(order.price - reference_price) / reference_price > 0.02:
return REJECT, "Price too far from reference"
if would_breach_rate_limit(order):
return QUEUE, "Rate limit"
if available_balance < order.required_margin:
return REJECT, "Insufficient balance"
return ACCEPT, None
```

REAL-TIME MONITORING REQUIREMENTS
  • Position size vs. limits
  • P&L vs. loss limits
  • Connectivity status
  • Order acknowledgment latency
  • Spread vs. target
  • Fill rate
  • Inventory age
  • Quote quality scores
  • API rate limit usage
  • Error rates
  • Data freshness

ALERTING THRESHOLDS

  • Position > 90% of limit
  • P&L loss > 50% of daily limit
  • Connectivity lost
  • Order rejection spike
  • Position > 70% of limit
  • P&L loss > 30% of daily limit
  • Elevated latency
  • Fill rate anomaly
  • Position > 50% of limit
  • Any manual intervention
  • Configuration changes
KILL SWITCH REQUIREMENTS
  1. Cancel all open orders immediately
  2. Prevent new orders from being submitted
  3. Optionally flatten positions
  4. Work even if main system is unresponsive

IMPLEMENTATION APPROACHES

  • Function in main application
  • Fast but vulnerable to application crashes
  • Minimum viable for small operations
  • Independent process watching main system
  • Can act if main system hangs
  • Better reliability
  • Some exchanges offer auto-cancel timers
  • Orders cancelled if not refreshed
  • Doesn't require your system to function

KILL SWITCH TRIGGERS

  • P&L loss exceeds limit (e.g., -$X in a day)
  • Position exceeds limit
  • Connectivity loss > threshold duration
  • Error rate exceeds threshold
  • Emergency button in UI
  • Command line tool
  • Mobile app notification action
LIMIT FRAMEWORK
  • Max long position: X XRP (or $Y)
  • Max short position: X XRP (or $Y)
  • Max gross exposure: Z XRP (or $W)
  • Max loss per trade: $A
  • Max loss per hour: $B
  • Max loss per day: $C
  • Max drawdown from peak: $D
  • Warning at 70% of limit
  • Restrict new exposure at 90%
  • Full stop at 100%
  • Review and manual reset required to resume

EXAMPLE LIMITS

Capital: $100,000
Risk per day: 2% = $2,000

  • Max position: $50,000 (50% of capital)
  • Warning: $35,000
  • Restrict: $45,000
  • Per trade: $200 (0.2% of capital)
  • Per hour: $500 (0.5% of capital)
  • Per day: $2,000 (2% of capital)
  • Drawdown: $5,000 (5% of capital)
MARKET DATA NEEDS
  • Best bid/ask prices
  • Order book depth (top 5-20 levels)
  • Recent trades
  • Your own order/fill updates
  • OHLCV candles
  • Historical order book snapshots
  • Your historical trades and P&L
  • Volatility calculations
  • Instrument specifications
  • Fee schedules
  • Trading hours
  • Rate limits

DATA SOURCES

  • Exchange WebSocket feeds (free with API)
  • Third-party aggregators (Kaiko, CryptoCompare)
  • Historical data providers
  • Direct node subscription
  • XRPL Data API
  • Third-party explorers (Bithomp, XRPScan)
DATA STORAGE TIERS
  • Current positions
  • Open orders
  • Recent market data
  • Technology: In-memory (Redis, local cache)
  • Today's trades
  • Recent P&L
  • Configuration
  • Technology: Local database (SQLite, PostgreSQL)
  • Historical trades
  • Historical market data
  • Audit logs
  • Technology: Time-series DB, cloud storage

STORAGE SIZING

  • ~1KB per snapshot
  • 1 snapshot per second = 86,400/day = ~86MB/day
  • 1 year = ~31GB
  • ~200 bytes per trade
  • 100 trades/day = ~20KB/day
  • Negligible storage needs

For most operations, a single VPS with SSD storage
is sufficient. Cloud storage for archival.
```

ANALYTICS CAPABILITIES
  • P&L calculation (realized, unrealized, total)
  • Position tracking
  • Fill rate and quality
  • Basic performance metrics
  • Adverse selection measurement
  • Spread capture analysis
  • Inventory aging
  • Market regime detection
  • Strategy backtesting
  • Parameter optimization
  • Predictive models
  • Correlation analysis

TOOLS

  • Works for daily/weekly analysis
  • Manual export from trading system
  • Adequate for small operations
  • More sophisticated analysis
  • Direct database connection
  • Visualization capabilities
  • Real-time dashboards
  • Automated reporting
  • ML model serving
  • Overkill for most XRP market making
BUILD VS. BUY ANALYSIS

Build Buy/Use Existing
──────────────────────────────────────────────────────────
Upfront cost High Low-Medium
Ongoing cost Medium Medium-High
Customization Complete Limited
Time to deploy Months Days-Weeks
Maintenance Your burden Vendor burden
Competitive edge Potentially Usually not
Dependency risk None Vendor dependency

  • Core competitive advantage
  • Unique requirements
  • Long-term commitment
  • Capable team available
  • Commodity functionality
  • Time to market critical
  • Limited technical resources
  • Standard requirements
BUILD VS. BUY BY COMPONENT
  • Recommendation: Build (using SDKs)
  • Reason: Simple, exchange-specific quirks, core to operation
  • Small operation: Build simple version
  • Larger operation: Consider commercial OMS
  • Reason: Complexity scales with operation size
  • Recommendation: Build
  • Reason: Specific to your limits and strategy
  • Real-time: Use exchange feeds (free)
  • Historical: Buy from data vendors
  • Reason: Real-time is free; historical is expensive to maintain
  • Recommendation: Build
  • Reason: This is your edge, not outsourceable
  • Recommendation: Buy (cloud services)
  • Reason: Not competitive advantage, expertise required
  • Recommendation: Buy (PagerDuty, Grafana Cloud, etc.)
  • Reason: Mature solutions, not worth building
RECOMMENDED STACK BY SCALE

Small operation (<$100K capital):

  • Libraries: ccxt (CEX), xrpl-py/xrpl.js (XRPL)
  • Database: SQLite
  • Hosting: Single VPS ($20-50/month)
  • Monitoring: Basic scripts + email alerts

Medium operation ($100K-$500K capital):

  • Libraries: Custom + ccxt + xrpl
  • Database: PostgreSQL
  • Hosting: Dedicated server or cloud ($100-300/month)
  • Monitoring: Grafana + PagerDuty

Larger operation (>$500K capital):

  • Libraries: Custom exchange connectors
  • Database: PostgreSQL + Redis + InfluxDB
  • Hosting: Multiple servers, possibly co-lo
  • Monitoring: Full observability stack
TECHNOLOGY COST BREAKDOWN
  • Server hosting: $20-5,000
  • Data feeds: $0-500
  • Monitoring services: $0-200
  • Development tools: $0-100
  • Cloud computing overages
  • Data storage growth
  • API overage fees (if any)
  • Initial development time
  • Hardware purchases
  • Software licenses
  • Developer time for maintenance
  • Operations monitoring time
  • Incident response time
TECH COST TARGETING

Rule of thumb: Tech costs should be <20% of gross revenue

Example calculations:

  • Expected gross revenue: $30,000/year

  • Max tech budget: $6,000/year = $500/month

  • Actual need: ~$100/month (well under budget ✓)

  • Expected gross revenue: $150,000/year

  • Max tech budget: $30,000/year = $2,500/month

  • Actual need: ~$500/month (well under budget ✓)

  • Expected gross revenue: $20,000/year

  • Max tech budget: $4,000/year = $333/month

  • Actual need: $200/month (56% of budget)

  • Warning: Tight margins, any cost increase problematic

If tech costs would exceed 20% of expected revenue,
the operation may not be economically viable.


---

Assignment: Create a detailed technology specification for your market making operation.

Requirements:

  1. Connectivity Specification: Define connection requirements for each venue
  2. OMS Design: Outline your order management approach and key components
  3. Risk Controls: Specify all limits, thresholds, and kill switch design
  4. Data Infrastructure: Define storage, analytics, and monitoring needs
  5. Build vs. Buy: Document decisions for each component with rationale
  6. Cost Budget: Itemize all technology costs and compare to expected revenue

Format: Technical specification, 2,000-3,000 words
Time Investment: 3-4 hours

Q1: What connectivity tier is appropriate for XRPL DEX market making?
A: Tier 2 (self-hosted node or infrastructure provider) - co-location doesn't help with 3-5 second ledger

Q2: What should trigger an automatic kill switch?
A: P&L loss exceeds limit, position exceeds limit, connectivity loss, or error rate spike

Q3: What percentage of gross revenue should technology costs target?
A: Less than 20%

Q4: When should you build rather than buy?
A: When it's core competitive advantage, you have unique requirements, and capable team available

Q5: What's the minimum viable infrastructure cost for small XRP market making?
A: ~$50-100/month (single VPS, basic monitoring)

End of Lesson 6
Total Words: ~6,200

Key Takeaways

1

Match infrastructure to strategy:

HFT needs co-location; XRPL DEX market making needs a $50/month VPS.

2

Risk controls are non-negotiable:

Kill switch, position limits, and loss limits are essential regardless of scale.

3

Buy commodities, build edge:

Use existing tools for standard functions; invest development time in what differentiates you.

4

Budget technology costs:

Keep under 20% of expected gross revenue. If you can't, the operation may not be viable.

5

Start simple, add complexity:

Begin with minimum viable infrastructure. Add sophistication only as strategy requires and revenue supports. ---