Skip to content
Pilot
Launch Pilot

The Agentic DeFi Terminal for XRPL

A unified agentic harness for multi-venue discovery and execution. Pilot is model-agnostic and its memory learns your trading style.

Launch Pilot Explore markets

Product preview: a simulated Pilot conversation on Testnet

Pilot Testnet fixture

Swap 500 RLUSD for XRP, max 1% slippage.

I compared the XRP/RLUSD order book with the AMM pool, built the exact swap and simulated it within your limits.

Sell 500 RLUSD · receive XRPvenues.compare
  • Order bookBestXRPL DEXImpact 18 bps · 12 drops963.84 XRP
  • Path paymentXRPL pathsImpact 24 bps · 12 drops962.95 XRP
  • AMM poolXRPL AMMImpact 95 bps · 0.30% pool956.20 XRP

Best vs worst +7.64 XRP · simulated quotes

  1. ✓ Account
  2. ✓ Research
  3. ✓ Propose
  4. Approve
  5. Confirm

Owner approval required

Review this exact summary before opening your wallet.

Awaiting approval

Sell 500 RLUSD · RLUSD/XRP

Action
Swap RLUSD for XRP
Amount
500 RLUSD → ≈ 963.85 XRP
Destination
XRPL DEX
Max fee
12 drops
Policy checks4 of 4 passed
Network
Testnet fixture · allowed
Issuer
RLUSD · allowlisted
Slippage
1% · max 1%
Size
$500 · owner signs
XRPL operations
64
Interfaces
MCP + REST
Delegate permissions
7
Venues catalogued
23

The problem

Builders rebuild the same risky steps. Traders juggle four tools.

Moving money on the XRP Ledger takes the same sequence every time. Developers write it from scratch, and traders stitch it together by hand.

The builder problem

Developers rebuild the same risky infrastructure from scratch.

  1. 1Fetch prices and balancesStale or outdated prices
  2. 2Write the transactionWrong amount or token
  3. 3Check the user's limitsLimit gets skipped
  4. 4Approve and signWrong trade gets signed
  5. 5Send and confirmSent twice, or result lost
The solution

Pilot handles all five steps through one MCP server or REST API.

Pilot MCP server · REST API

  1. 1Live ledger reads require an explicitly configured provider
  2. 2Exact trade built and simulated
  3. 3Your limits enforced every time
  4. 4Approval tied to the exact trade
  5. 5Sent once, confirmed and recovered

The trader problem

Traders juggle four disconnected tools for every trade.

  1. 1Check priceson a charts websitePrices copied by hand
  2. 2Ask what to tradein an AI chatbotCan't see your limits
  3. 3Retype the tradeinto your wallet appEasy to mistype the trade
  4. 4Check if it went throughon a ledger lookup siteNo record of what or why
The solution

Pilot runs all four steps in one workspace, and remembers why.

  1. 1Agent reads fixtures until live market access is configured
  2. 2Proposes a trade within your limits
  3. 3You approve the exact details
  4. 4Confirmed and recorded on the ledger

What we built

AI can already read the XRP Ledger. Pilot enables it to act safely.

Traders use the Pilot workspace. Agents connect over MCP. Apps connect over REST. All three reach the same 64 operations and the same checks.

  • For traders

    Pilot workspace

    An AI trading harness. The model never holds a signing key.

  • For agents

    MCP server

    search · execute

    Runs in a sandbox with no internet access.

  • For apps

    REST API

    POST /api/ops/{op}

    The same 64 operations.

27Read

  • 14Market reads

    Balances, order books, quotes, AMM pools

  • 8Research

    Token risk flags, yield, docs, XRP perps

  • 5Venues & skills

    23-venue catalog, safety playbooks

16Build

  • Transaction builders

    • Swaps
    • Offers
    • Payments
    • Trust lines
    • AMM
    • Vaults
    • Escrow
    • Checks
    • Simulation

21Execute

  • 8Execution

    Submit, track, permissions and limits

  • 13Payments & infra

    Mastercard agent mandates, RPC health

Same operation, either door.

An agent asks the MCP server to run a typed call from its sandbox. A backend posts the same arguments to the REST endpoint. Both return the same envelope: data, the ledger it came from, and any caveats.

// tools/call → Pilot MCP server
{
  "name": "execute",
  "arguments": {
    "code": "return await harbor.venues.compare({
      network: 'testnet',
      sell: { currency: 'XRP' },
      buy: { currency: 'RLUSD', issuer: 'rQhWct2fv4Vc4KRjRgMrxa8xPN9Zx9iLKV' },
      amount: '100', side: 'sell'
    })"
  }
}

Agents call the MCP server's execute tool from a sandbox with no internet access

Inside one trade

From market research to a confirmed transaction.

The engine runs every step the same way, whether the request comes from the Pilot workspace, an agent or an app. You only step in to approve.

  1. 01Connect

    App
    • AI agents use the MCP server
    • Regular apps use the REST API

  2. 02Read the market

    Engine
    • Prices, balances, order books
    • 64 operations over MCP and REST

  3. 03Build the trade

    Engine
    • Writes the unsigned transaction
    • Swaps, orders, payments, pools

  4. 04Check limits

    Engine
    • Reserves the spending limit
    • Guards against duplicate execution

  5. 05Approve

    User
    • Approval matches the exact trade
    • Signed trade is checked again

  6. 06Confirm

    Engine
    • Reads the result from the ledger
    • Recovers it if the connection drops
Where the data comes from
XRP Ledger
Balances, orders, XRP/RLUSD price
XRPL.to · XRPSCAN · Bithomp
Tokens, accounts, history
XRPL docs
Transaction rules
Hyperliquid
XRP perps context

The workspace

Pilot connects AI research and guardrailed trading into one workspace.

An AI trading agent built for XRPL. Ask about your account and the market; it proposes a trade with the exact details, follows your limits, confirms the result and remembers your choices.

  1. 01AccountConnect a wallet and set limits

    Permissions you can revoke

    Pilot never holds your owner key. Owner actions are signed in your own wallet, and any permission you grant can be revoked at any time.

  2. 02ResearchAsk about your account and the market

    An AI trading agent built for XRPL

    Ask from any page about your account and the market. The public preview uses bounded fixtures; quotes, order books and AMM pools use live ledger reads only after a provider profile is explicitly configured and accepted.

  3. 03ProposeIt drafts the exact trade

    Proposals with the exact details

    Choose one-time, recurring or autonomous. Every proposal arrives as a card with the asset, amount, route, fee and policy result.

  4. 04ApproveYou sign what you see

    Trades follow your limits

    Approvals show the exact details, and you sign that transaction, not a summary of it. Per-trade caps, a daily budget and an issuer allowlist are checked every time.

  5. 05ConfirmResult read from the ledger

    Confirms and remembers

    Pilot reads the result back from the ledger, then remembers your choices for the next trade.

Inside the app

Other apps · One engine, many apps

Developers can build any XRPL app on Pilot's MCP and API.

DEX, AMM and ledger-read contracts are available through one API. The public runtime uses bounded fixtures; live reads require an explicitly configured provider. The same limits and approvals remain built in, and dashed boxes are examples—no outside apps use them yet.

Architecture: the Pilot workspace, built by us, calls the Pilot MCP and REST API through a typed client. Example applications that do not exist yet, such as a payments app, a trading website, a trading bot, a portfolio tracker and a research assistant, would connect over REST or MCP. The engine reads from and submits to the XRP Ledger, and reads token and account data from XRPL.to, XRPSCAN and Bithomp, transaction rules from the XRPL docs, and XRP perps context from Hyperliquid.

QuickNode RPC, confirmation and key-monitoring contracts · provider calls default-off

Self-improving memory

Pilot learns from every trade, and saves nothing without you.

After each trade, Pilot compares what it expected with what happened and suggests a better preference. It only keeps what you approve, and the next trade reads it.

Learns from every trade

  1. 1TradeValidated on the ledger
  2. 2ReflectExpected vs actual fill, slippage and result
  3. 3RememberSaved to your journal, trades and token notes
  4. 4ProposeThe agent suggests a better preference
  5. 5ApproveSaved only if you accept. The next trade reads it

  • An Obsidian vault you own

    Linked Markdown notes, versioned in Git

  • Any model, same memory

    Switch models through OpenRouter anytime

  • New chats keep context

    The agent searches your vault on every run

  • Nothing saved without you

    Preferences apply only after you approve

Built on ideas from
Google Harness²
Improves its own prompts, skills and memory
Hermes Agent · Nous Research
Learns skills, remembers across sessions
Obsidian vault
Memory as linked Markdown notes

Follow one message through the loop.

From your question to the XRP Ledger and back: where Pilot checks your limits, where it asks you to sign, and how it learns what you prefer.

Watch one message run the whole loop

Step 01 of 12

Paused

You send a message

You ask Pilot for a swap and mention how you like answers. That second part is what Pilot can learn from.

Swap 500 RLUSD for XRP. I prefer risk caveats first.

Highlighted: a preference Pilot can offer to remember

Privacy and control

What the loop never does.

  • Only your own notes, for this wallet and network, are ever searched.
  • Nothing is remembered until you accept it, and you can correct or forget it later.
  • Preferences change how answers are written, never your limits, amounts, approvals or signing.
  • The AI model never gets a way to sign or send money.
  • Remembering helps answers fit you. It doesn't promise better returns.

Integrations

Integration contracts, with live provider access off by default.

Open one to inspect its bounded explainer or fixture flow. The current public runtime makes no provider calls or transactions.

Built on AWS

Trust you can inspect, not just assume.

Pilot carries structured screening, model, and signer provenance from the engine into each action receipt.

See how it works

  • Bedrock Guardrails

    Screens untrusted ledger and tool text before it reaches the model, with fail-closed redaction.

  • Amazon Bedrock models

    Keeps model provenance visible on every supported intent receipt, including explicit mock labels.

  • AWS KMS

    Protects the engine's signing key material and records the signer mode without exposing credentials or key ARNs.

How a request travelsFrom untrusted text to an approved action on the ledger

Untrusted data passes through Bedrock Guardrails and a selected Bedrock model, then Harbor policy, before an approved action reaches XRPL Testnet.

  1. 01Untrusted data
  2. 02Guardrails
  3. 03Bedrock
  4. 04Harbor policy
  5. 05XRPL Testnet

Approve on Ledger

Bounded automation. Owner control beyond the boundary.

This mirrors Ledger Agent Intent's human-in-the-loop model for XRPL. Ledger Agent Intent does not support XRPL yet. Pilot uses Ledger's Device Management Kit (DMK), not legacy LedgerJS.

Simulated evidence only. Physical-Ledger and live-Testnet checks are still pending and are not claimed here.

See how it works

  1. 01Propose

    The agent proposes

    Pilot turns the request into a typed intent and an exact XRPL transaction. The agent never holds the owner key.

  2. 02Execute

    Harbor's bounded delegate executes

    Within the permissions granted on-ledger and the limits checked by Harbor, the delegate can execute without another owner signature.

  3. 03Approve

    The Ledger approves anything beyond it

    When an action exceeds that bounded authority, the owner reviews and signs the exact transaction on the Ledger.

Simulated Ledger

Set the RLUSD trust line

Recorded demo · no signing
Recorded Simulated Ledger screen

Keyboard: ← · Enter/↓ · →

Screen 1 of 9: Review transaction

Clear-signed TrustSet screen from the deterministic local simulated-device replay.

Blind-signing legend

DelegateSet is blind-signed

Ledger's XRP app 2.8.2 labels these fields as unknown. During onboarding, Pilot shows the full Harbor delegate address beside the device; this preview preserves every fixed permission instead of pretending the transaction is clear-signed.

Unknown [1] | 8
OfferCreate
Place DEX offers (swaps) within policy
Unknown [2] | 9
OfferCancel
Cancel its own offers
Unknown [3] | 21
TrustSet
Add or adjust trust lines
Unknown [4] | 37
AMMDeposit
Add liquidity to AMM pools
Unknown [5] | 38
AMMWithdraw
Remove liquidity
Unknown [6] | 3
EscrowFinish
Finish escrows
Unknown [7] | 18
CheckCash
Cash checks

When approving in onboarding, match the full delegate address shown there and all seven values, then disable blind signing after the delegation validates.

Use cases

One infrastructure layer for trading, payments and liquidity apps.

  • Compare swap prices

    Built · Pilot
    • The agent compares order book and AMM pool prices
    • The trader approves the exact swap
    • Pilot confirms the result on the ledger

  • Autonomous strategies

    Built · Pilot
    • Recurring buys, price triggers or rebalancing
    • You approve one signed mandate with hard limits
    • Pause, stop or kill it account-wide at any time

  • Payments app

    Example
    • Sends RLUSD and XRP within the user's limits
    • The user approves each payment
    • If the connection drops, the result is recovered from the ledger

  • Liquidity app

    Example
    • Reads the pool's size and fees
    • Prepares the deposit
    • Nothing moves until the user approves

Safety

Controls that hold even when an agent or a connection doesn't.

Agents make mistakes and networks drop. Pilot is built so that neither turns into a wrong, repeated or unsigned-for trade.

  1. 01No owner keys

    The model never holds a signing key. Owner-signed actions go to your wallet as sign-only requests.

  2. 02Revocable permissions

    Autonomous actions run only through delegate permissions you grant on-ledger, seven by default, and you can revoke them at any time. An account-wide kill switch stops them all.

    • Create offers
    • Cancel offers
    • Manage trust lines
    • Deposit liquidity
    • Withdraw liquidity
    • Finish escrows
    • Cash checks

  3. 03Limits enforced every time

    Spending limits are checked and reserved before anything is signed or sent to the ledger.

  4. 04Approval tied to the exact trade

    An approval is bound to one transaction. The signed trade is checked against it again before submission.

  5. 05Sent once

    Durable idempotency means a retried request cannot send the same trade twice.

  6. 06Confirmed and recovered

    Results are read back from the ledger, and recovered if the connection drops mid-flight.

Public runtime: explicit mock/default-off. Live Testnet execution and physical-wallet acceptance remain separate gates.

Roadmap and readiness

Core flows are implemented; live providers and transaction acceptance remain gated.

  1. Today · public preview

    Implemented, mock-first and open source

    • End-to-end transaction flows run with explicit fixtures; no live trade is claimed
    • 64 XRPL operation contracts over MCP and REST
    • Ledger, QuickNode, AWS and Mastercard adapters are default-off
    • Owner-reviewed memory flows use an Obsidian-format vault

  2. Next

    Complete live acceptance gates

    • Hardware-wallet and Testnet execution acceptance
    • Configured-provider smoke tests with no implicit fallback
    • Security review before any Mainnet decision
    • Publish verifiable Testnet evidence when those checks pass

  3. Later

    Optional live rollout

    • Enable reviewed providers only after account-specific acceptance
    • Consider Mainnet only after audit and explicit authorization
    • Hosted MCP and API for approved XRPL apps
    • Expand strategy templates behind the same limits and approvals

Explore the public preview

Research, approve and confirm your next XRPL trade, inside limits you set.

Launch Pilot Guided setup