Skip to main content

​
What is Ledger?

Ledger is a broker-style execution layer for prediction markets. Users deposit USDC to a single Predexon-managed address, submit orders against a canonical predexonId (a stable cross-venue outcome identifier sourced from the Data API), and Predexon handles routing, settlement, redemption, and unified position management on their behalf. The Trading API remains available for integrators that require per-venue managed wallets and direct on-chain visibility. Ledger provides equivalent execution behind a single, unified interface.
1:1 backing. Every Ledger position is fully collateralized by a corresponding on-chain position held by Predexon. Predexon does not take the opposing side of any user trade — execution occurs against external liquidity sources: venue order books, or market makers via request-for-quote (RFQ). See How positions are backed.

​
The problem

The current Trading API exposes the underlying market structure faithfully — which is great for sophisticated integrators and terrible for everyone else. To trade across all venues today, a user must:
  • Provision a separate wallet on each venue (Polymarket, Predict.fun, Opinion, Limitless, Hyperliquid)
  • Bridge funds to four different chains (Polygon, BSC, Base, HyperCore)
  • Hold four different stablecoins (USDC.e on Polygon, USDT BEP-20 on BSC, native USDC on Base, USDH on HyperCore)
  • Pick the right venue when placing an order, even when the same market exists in multiple places at different prices
  • Track positions separately on each venue and reconcile them by hand
  • Manage redemptions themselves when markets resolve
This is fine for a quant team. It is a non-starter for a fintech app, a consumer wallet, or anyone who just wants exposure to “will X happen.”

​
How Ledger fixes it

SurfaceTrading APILedger
WalletsOne per venue, exposed to the userOne deposit address
CurrenciesFour stablecoins across multiple chains (USDC.e, USDT BEP-20, USDC, USDH)USDC only
Order routingUser picks the venuePredexon routes to best price across venue books and RFQ market makers
PositionsSeparate positions per venue, scattered across chains and tokensOne unified entry per market — no venues or chains to track
RedemptionUser must redeem winning positionsAuto-redeemed; user’s USDC balance is credited
WithdrawalPer-venue, per-chainOne USDC withdrawal to a user-supplied address

​
Lifecycle of a trade

  1. User creates a Ledger account → receives a USDC deposit address.
  2. User deposits USDC. Balance becomes available.
  3. User places an order: POST /orders referencing a canonical outcome by predexonId (e.g., a market BUY with a USDC amount). No venue field.
  4. Predexon routes the order across the best available sources — venue order books, RFQ market makers, or both — and fills from its pooled treasury.
  5. The position appears in the user’s unified position list — one entry per market, no venue or chain shown. The actual on-chain tokens live in Predexon’s pooled venue-side wallets.
  6. On resolution: Predexon redeems on each venue holding the position, credits the user’s USDC balance, and records the event in the user’s resolutions history (with payout, realized PnL, and on-chain redemption transactions).
  7. User withdraws USDC to any Base address.

​
Where this fits with the rest of Predexon

Ledger sits above Predexon’s existing trading infrastructure — the router consumes the Trading API for venue fills and integrates directly with market makers for RFQ fills. From a product standpoint, the surfaces are tiered:
  • Data API — read-only market data, pricing, and analytics. (Unchanged.)
  • Trading API — per-venue managed wallets with direct on-chain visibility, for integrators that require venue-level control.
  • Ledger — unified, venue-abstracted execution, for applications and end-users that require a single execution interface.

​
Next Steps

Concepts

Custody, routing, settlement, and the mental model

API Reference

Endpoints and request/response shapes