What We Built on XRPL

A prediction market MVP using native XRPL primitives.

No smart contracts. No sidechains. No bridges.

We use what XRPL already has:

• EscrowCreate / EscrowFinish — native escrow with crypto-conditions
• PREIMAGE-SHA-256 — condition-based release (RFC 5565)
• CancelAfter — built-in safety net (funds auto-return on timeout)
• 2-of-3 Multisig — SignerListSet across 3 SGX instances

XRPL's native escrow is the most underutilized primitive in crypto.
We're building on it.

Why XRPL Is Ideal for Prediction Markets

XRPL is the only L1 with all six properties natively.
Bitcoin needs script tricks (P2WSH, Taproot). Ethereum needs smart contracts.
XRPL has it all at the protocol level.

No Prediction Markets on XRPL — Until Now

There are no production prediction markets on XRPL mainnet today.

Why not?

1. No smart contracts on mainnet — traditional PMs (Polymarket, Augur) require EVM: AMM, order books, conditional tokens. Not possible on XRPL.
2. Ecosystem focus — XRPL community has been focused on payments, remittances, RWA tokenization. Prediction markets are an unexplored niche.
3. DEX exists, PM does not — XRPL has a native DEX (Offers/AMM), but that's token trading, not event-based markets.

Phoenix is potentially the first prediction market on XRPL using native primitives.

We don't need smart contracts — XRPL's Escrow + Crypto-Conditions + CancelAfter already provide everything a prediction market needs at the protocol level.

This expands the XRPL narrative beyond "payment network" — proving that native primitives can power new financial instruments without EVM complexity.

Architecture: TEE + XRPL Escrow

Participant (standard XRP wallet)
    │
    ▼  EscrowCreate (PREIMAGE-SHA-256)
┌─────────────────────────────┐
│   TEE (SGX enclave)         │  ← preimages sealed in hardware
│   • generate conditions     │
│   • hold fulfillments       │
│   • sign payouts            │
│   • 2-of-3 multisig keys    │
└─────────────────────────────┘
    │                    │
    ▼                    ▼
 EscrowFinish        On-chain Commitment
 + Payouts           (Merkle root → EVM)

Key insight: preimages never leave the enclave.
Operator sees only the condition (hash) — cannot front-run.

How It Works — Step by Step

1. Market created — TEE generates PREIMAGE-SHA-256 conditions (YES / NO)

• Only conditions (hashes) stored in DB — preimages sealed in SGX

2. Participants bet — EscrowCreate with condition + CancelAfter

• Standard XRP wallet, native transaction, no bridge

3. Deposits scanned — XRPL ledger monitored for escrows to market address

4. Event resolves — UMA Oracle determines outcome

5. TEE releases fulfillments — EscrowFinish collects ALL escrows (both sides)

6. Payouts sent — losers' funds redistributed pro-rata to winners in native XRP

7. If market NOT resolved — CancelAfter triggers, ALL funds auto-return (safety net)

MVP: XRPL + Merkle Proof on Testnets

Full E2E cycle — real transactions, real escrows, real XRP.

Demo video available. Standard, oracle-resolved, multisig modes.

Demo: Full Cycle with 2-of-3 Multisig

XRPL Native Multisig

2-of-3 threshold across 3 independent SGX instances.

SGX Instance 1 (port 8085) ─┐
                             ├──→ SignerListSet (2-of-3)
SGX Instance 2 (port 8086) ─┤    on intermediary wallet
                             │
SGX Instance 3 (port 8087) ─┘

• Each instance generates its own XRPL keypair inside hardware
• SignerListSet combines 3 public keys with quorum = 2
• Any 2 instances can sign transactions — kill 1, system continues
• Uses XRPL's native multisig — no smart contracts

Same trust model as FROST on Bitcoin, but using XRPL's built-in primitives.

On-Chain Oracle Resolution

Real markets like Polymarket — settled in native XRP.

Any on-chain question source (Polymarket, Azuro, Gnosis) can feed Phoenix:

On-chain question source          Phoenix (XRPL)
    │                              │
    ▼  Question published          │
UMA Optimistic Oracle ────────→  Create XRP escrows
    │                              │
    ▼  getExpectedPayouts()        │
UMA Oracle ────── resolve ──→  EscrowFinish + Payouts (XRP)

• Import questions from any on-chain prediction market or custom source
• UMA Optimistic Oracle resolves outcomes — trustless, decentralized
• Phoenix is not dependent on any single market — oracle-agnostic settlement

Security Hardening (Audited)

46 issues identified in self-audit. All implementable fixes done.

CancelAfter: if anything fails, funds auto-return. No Bitcoin escrow has this natively.

Agent Economy: x402 on XRPL

x402 protocol (Coinbase, t54 Labs — backed by Ripple + Franklin Templeton)

x402 (access) → XRPL escrow (settlement) → SGX enclave (trust)

Phoenix = "hardware wallet for AI agents" on XRPL.

Multi-Chain: XRPL Is Not Alone

The pattern "escrow + isolated signer + oracle" is universal.

XRPL has the cleanest implementation — native escrow + conditions + multisig
at the protocol level. No script gymnastics needed.

What Bonds XRPL Commons and Phoenix

We're building real infrastructure on XRPL — not just a PoC.

What we bring:

• Working MVP with native XRPL primitives (escrow, conditions, multisig)
• TEE-secured key custody (SGX)
• UMA Oracle integration — trustless resolution from on-chain sources
• Agent economy readiness (x402-compatible architecture)

What we'd value from XRPL Commons:

• Ecosystem visibility, developer community access and infrastructure support
• Feedback on XRPL primitives usage and grant programs

Why This Team

Focus: infrastructure, security, keys, signing, execution isolation.

• Olas — entire on-chain ecosystem (EVM / Solana / Near): token, governance, staking, AI marketplace
• Secure signing (SGX, TPM), key management, cross-chain logic
• Contract and protocol auditing
• Three EVM hackathons — first place in each

We chose an extremely careful architecture, even at the cost of centralization at an early stage.