Order Types and Execution - What XRPL Supports

The limit order (standard offer) is the foundation of XRPL DEX trading.

LIMIT ORDER MECHANICS

Transaction Type: OfferCreate

Basic Structure:
{
"TransactionType": "OfferCreate",
"Account": "rYourAddress",
"TakerGets": "100000000", // 100 XRP (in drops)
"TakerPays": { // What you want in return
"currency": "USD",
"issuer": "rBitstamp",
"value": "50" // 50 USD
}
}

This offer says: "I will give 100 XRP to anyone who pays me 50 USD"
Effective price: $0.50 per XRP
```

The naming can be confusing. Think from the taker's perspective:

OFFER PERSPECTIVE

- TakerGets: What the TAKER gets (what YOU give)
- TakerPays: What the TAKER pays (what YOU get)

Example: You want to SELL 100 XRP for $50 USD

- TakerGets: 100 XRP (taker gets your XRP)
- TakerPays: 50 USD (taker pays you USD)

- They get: 100 XRP
- They pay: 50 USD
- You get: 50 USD
- You give: 100 XRP

MEMORY TRICK:
"TakerGets" = What leaves your account
"TakerPays" = What enters your account

PRICE FROM OFFER FIELDS

Price = TakerPays / TakerGets

Example 1: Selling XRP for USD
TakerGets: 100 XRP
TakerPays: 50 USD
Price: 50/100 = $0.50 per XRP

Example 2: Buying XRP with USD
TakerGets: 50 USD
TakerPays: 100 XRP
Price: 100/50 = 2 XRP per USD
(Or equivalently: 1/2 = $0.50 per XRP)

Example 3: Trading issued currencies
TakerGets: 1000 EUR.Gateway
TakerPays: 1100 USD.Bitstamp
Price: 1.10 USD per EUR
```

Unlike some exchanges, XRPL supports partial fills by default:

PARTIAL FILL EXAMPLE

- Sell 1000 XRP for 500 USD ($0.50/XRP)

- Buy 300 XRP at $0.50

- 300 XRP filled at $0.50 = 150 USD received
- Your offer remains on book: 700 XRP for 350 USD
- Same price, reduced size

- Fully filled (all 1000 XRP sold)
- You cancel
- Offer expires

What happens when your limit order can execute immediately?

CROSSING OFFERS

Order book state:
Best bid: $0.49 (someone wants to buy at $0.49)
Best ask: $0.51 (someone wants to sell at $0.51)

You submit: Sell 100 XRP at $0.48 (below best bid)

Key insight: You never get worse than your limit price.
You often get better (price improvement).
```

When you need execution now but accept partial fills:

IMMEDIATE-OR-CANCEL

- Execute whatever is available immediately
- Cancel any unfilled remainder
- Order never sits on the book

- Want quick execution
- Don't want lingering orders
- Okay with partial fills
- Market-taking strategy

Transaction:
{
  "TransactionType": "OfferCreate",
  "Account": "rYourAddress",
  "TakerGets": "100000000",    // 100 XRP
  "TakerPays": {
    "currency": "USD",
    "issuer": "rBitstamp",
    "value": "52"              // Willing to pay up to $0.52/XRP
  },
  "Flags": 131072              // tfImmediateOrCancel
}

Execution scenarios:

• 100+ XRP available at $0.52 or better

• Result: Full fill, order complete

• Only 60 XRP available at acceptable price

• Result: 60 XRP filled, 40 XRP cancelled

• No offers at $0.52 or better

• Result: Entire order cancelled, nothing filled

When partial fills are unacceptable:

FILL-OR-KILL

- Execute entire order or nothing
- No partial fills allowed
- Order never sits on the book

- Hedging (need exact size)
- Arbitrage (all-or-nothing economics)
- Position sizing requirements
- When partial would leave awkward remainder

Transaction:
{
  "TransactionType": "OfferCreate",
  "Account": "rYourAddress",
  "TakerGets": "100000000",    // 100 XRP
  "TakerPays": {
    "currency": "USD",
    "issuer": "rBitstamp", 
    "value": "52"
  },
  "Flags": 65536               // tfFillOrKill
}

Execution scenarios:

• 100+ XRP available at $0.52 or better

• Result: Complete fill

• Only 60 XRP available at price

• Result: ENTIRE order cancelled (not 60 filled)

• Result: Order cancelled

IoC vs FoK COMPARISON

IoC FoK
--- ---
Partial fills Yes No
All-or-nothing No Yes
Never on book ✓ ✓
Best for Quick execution Exact sizing
Failure mode Partial fill Complete rejection
Risk Unexpected size Missing opportunity

Passive orders only provide liquidity—they never take it:

PASSIVE ORDER BEHAVIOR

- Can immediately match crossing orders
- Can sit on book waiting for matches
- Acts as both maker AND taker

- NEVER immediately matches
- Always sits on book
- Only fills when someone else crosses you
- Pure maker behavior

Transaction:
{
  "TransactionType": "OfferCreate",
  "Account": "rYourAddress",
  "TakerGets": "100000000",    // 100 XRP
  "TakerPays": {
    "currency": "USD",
    "issuer": "rBitstamp",
    "value": "50"              // $0.50/XRP
  },
  "Flags": 65536 + 262144      // Can combine with tfPassive
}

Note: tfPassive = 65536... wait, that's tfFillOrKill.
Correct flag: tfPassive = 0x00010000 = 65536?

Let me recalculate:
tfPassive = 0x00010000 = 65536
tfFillOrKill = 0x00020000 = 131072?

Actually:
tfPassive = 0x00010000 = 65536
tfSell = 0x00020000 = 131072
tfFillOrKill = 0x00040000 = 262144
tfImmediateOrCancel = 0x00080000 = 524288

Let me correct the flags:

CORRECT FLAG VALUES

- Order won't cross existing offers

- Sell semantics for exchange rate

- All or nothing execution

- Execute immediately, cancel remainder

PASSIVE ORDER USE CASES

Example Scenario:

Current book:
Best bid: $0.50 (100 XRP)
Best ask: $0.51 (100 XRP)

You want to sell at $0.50 (cross the bid):

• Immediately sells 100 XRP at $0.50

• Takes the existing bid

• Does NOT cross the $0.50 bid

• Sits on the ask side at $0.50

• Waits for new buyer at $0.50

Passive can combine with other flags:

FLAG COMBINATIONS

- Sits on book, never crosses
- Can partially fill over time

- Doesn't make sense (FoK requires immediate execution)
- Passive prevents immediate execution
- Result: Order always fails

- Also doesn't make sense
- Passive prevents immediate matching
- IoC cancels anything not immediately matched
- Result: Order always cancelled

- Valid combination
- Passive behavior with sell semantics

Bottom line: Passive is for patient market makers,
not for immediate execution strategies.

The tfSell flag affects how exchange rates are calculated:

tfSell BEHAVIOR

- You might receive MORE than TakerPays
- But never LESS than TakerPays
- Exchange rate is maximum you'll accept

- You will give EXACTLY TakerGets (or less)
- You might receive more than TakerPays
- Focused on selling exact amount

Example:

You offer: Sell 100 XRP, want at least 50 USD

• Could sell up to 100 XRP

• Will receive at least 50 USD

• Might receive more if market is good

• Will sell exactly 100 XRP (or less if cancelled)

• Will receive at least 50 USD

• Focused on disposing exact XRP amount

• You need to sell exact amount (tax lots, position closing)

• You don't want to potentially sell more

• Specific inventory management

tfSell EXAMPLE

Order book: Someone wants to buy 150 XRP at $0.55

In this case: Same outcome, but tfSell guarantees
your selling exactly 100, not potentially adjusting.

More relevant with partial fills and rate variations.
```

Orders can have automatic expiration:

ORDER EXPIRATION

Transaction with expiration:
{
  "TransactionType": "OfferCreate",
  "Account": "rYourAddress",
  "TakerGets": "100000000",
  "TakerPays": {
    "currency": "USD",
    "issuer": "rBitstamp",
    "value": "50"
  },
  "Expiration": 750000000        // Ripple epoch timestamp
}

- Ripple epoch: Seconds since Jan 1, 2000 00:00:00 UTC
- Not Unix epoch (Jan 1, 1970)
- Conversion: Ripple epoch = Unix epoch - 946684800

Example:
Unix timestamp: 1700000000 (Nov 14, 2023)
Ripple epoch: 1700000000 - 946684800 = 753315200

- Order automatically removed from book
- Reserve XRP returned to account
- No action required from you

EXPIRATION USE CASES

EXPIRATION BEST PRACTICES

NOT NATIVELY SUPPORTED ON XRPL

IMPACT OF MISSING ORDER TYPES

IMPLEMENTING MISSING FEATURES

Stop-Loss Workaround:

1. Off-chain monitoring:

2. Bot implementation:

3. Third-party services:

OCO Workaround:

1. Place both orders
2. Monitor for fills
3. When one fills, cancel the other
4. Can be automated via bot

Trailing Stop Workaround:

1. Track highest price since entry
2. Calculate stop level (high - X%)
3. If current price < stop, execute sell
4. Update high and stop as price rises
5. Requires continuous monitoring

• XRPL Hooks may enable on-chain logic
• Could implement stops, OCO, etc.
• Still in development
• Watch for amendments

CANCELLING OFFERS

OfferCancel Transaction:
{
"TransactionType": "OfferCancel",
"Account": "rYourAddress",
"OfferSequence": 12345 // Sequence number of offer to cancel
}

MODIFYING OFFERS

XRPL doesn't have native "modify" transaction.

{
"TransactionType": "OfferCreate",
"Account": "rYourAddress",
"TakerGets": "100000000",
"TakerPays": {...},
"OfferSequence": 12345 // Offer to replace
}

This cancels offer 12345 and creates new offer atomically.
```

QUERYING OPEN OFFERS

account_offers Request:
{
"command": "account_offers",
"account": "rYourAddress"
}

✅ Basic order types work reliably - 12+ years of consistent execution

✅ Partial fills handled correctly - No bugs in fill logic

✅ Flags behave as documented - Predictable, verifiable behavior

✅ Atomic execution - Orders execute completely within single ledger close

✅ Low cost order management - Trivial fees for placement and cancellation

⚠️ Hooks future - May add conditional order capabilities, timeline unclear

⚠️ Third-party stop-loss services - Various quality and trust levels

⚠️ Optimal workarounds - Best practices still evolving

🔴 No native stop-losses - Must monitor positions manually or trust external systems

🔴 Forgotten orders - Without expiration, orders persist indefinitely

🔴 Sleep-time exposure - Can't protect positions while away from market

🔴 Complex strategy execution - Requires significant manual work or automation

XRPL's order types are simple, reliable, and sufficient for most trading. The deliberate simplicity has contributed to the DEX's perfect security record. However, the lack of stop-losses and conditional orders is a genuine limitation that requires different risk management approaches. If you need automated stop-losses, either build your own monitoring system, trust a third party, or accept that XRPL DEX trading requires active position management.

Assignment: Create a comprehensive decision framework for selecting order types on XRPL DEX.

Requirements:

Part 1: Decision Tree Diagram

• Entry point: "What are you trying to accomplish?"
• Decision nodes: Key questions about urgency, size, risk tolerance
• Endpoints: Specific order type recommendations with flags

Part 2: Scenario Matrix

Create a table mapping 15 trading scenarios to order types:

• Market making
• Urgent exit
• Patient accumulation
• Hedging exact position
• Profit taking
• Stink bid placement
• Large order execution
• Day trading
• Swing trading
• Event-driven trading

Part 3: Missing Feature Workarounds

• Stop-loss: How will you implement?
• OCO: How will you manage?
• Trailing stop: How will you track?

Include time requirements and trust assumptions.

Part 4: Personal Order Management Protocol

• When to use expiration (and what duration)

• How often to review open orders

• When to cancel vs modify

• How to track order status

• Decision tree clarity and completeness: 30%

• Scenario coverage and accuracy: 30%

• Workaround practicality: 20%

• Personal protocol thoughtfulness: 20%

Time investment: 1.5-2 hours

For Next Lesson:
Lesson 5 covers liquidity analysis—how to read order books, assess market depth, calculate slippage, and determine if a market is tradeable before committing capital.

End of Lesson 4

Total words: ~4,600
Estimated completion time: 60 minutes reading + 1.5-2 hours for deliverable