Skip to main content

The Ledger account

A Ledger account is a Predexon-managed entity that owns:
  • A USDC balance — fungible, denominated in standard USDC.
  • A position book — open positions across any prediction market Predexon trades on.
  • A single deposit address — Predexon-controlled, accepts USDC.
There is no per-venue wallet exposed to the user. The user never sees the underlying chains, tokens, or venue mechanics. From the user’s perspective there is one USDC balance and a unified list of positions.

Custody model

Both Trading API and Ledger are managed (Predexon controls keys). The difference is how those keys map to user state.
  • Trading API uses per-user, per-venue managed wallets. Each user has a dedicated wallet on each enabled venue, and Predexon signs transactions on their behalf. The on-chain position belongs to that user’s wallet; the user can verify holdings directly on the venue’s chain.
  • Ledger uses pooled treasury wallets. Predexon’s wallets hold positions across all venues; each user’s position is an entry in Predexon’s internal ledger that maps to those on-chain holdings.
PropertyTrading APILedger
Wallet modelPer-user, per-venuePooled treasury
Who holds the on-chain positionThe user’s per-venue walletPredexon’s pooled wallets
User’s view of a positionOn-chain token balance on the venue’s chainUnified Ledger entry
Withdrawal mechanismPer-venue, per-chainUSDC on Base → any address

Deposits

A Ledger account has one deposit address, controlled by Predexon. The same address accepts USDC on Base, Ethereum, and Polygon — all three are EVM-compatible, so users send USDC to the displayed address from whichever chain holds their funds. Internally, Predexon sweeps all incoming USDC to Base as the canonical chain using Circle’s CCTP V2 — burn-and-mint, no third-party bridges, no wrapped tokens, ~30s finality. The user’s Ledger balance is credited after the source-chain deposit reaches finality, regardless of which chain it arrived on. Deposits are denominated in native USDC — no other tokens are accepted.
ChainWhy we accept here
BaseCanonical chain. Cheapest gas, native USDC, direct Coinbase on-ramp for retail.
EthereumLargest native USDC supply (~$51B as of April 2026); where DeFi and institutional users hold USDC.
PolygonWhere existing Polymarket users hold USDC (native after April 2026 migration).
Solana support is on the roadmap — deferred at launch due to its distinct address format and separate deposit-monitoring infrastructure.

Order placement and routing

A Ledger order references a canonical outcome by predexonId — the cross-venue stable identifier — and does not specify a venue. Predexon’s router decides where to fill.
POST /orders
{
  "predexonId": "px-abc123def456",
  "side": "buy",
  "type": "market",
  "amount": 50.00
}

Liquidity sources

The router considers two kinds of fill sources:
  • Venue CLOBs — central limit order books at Polymarket, Predict, Opinion, Limitless, and Hyperliquid. The router reads depth on each book and fills against the best top-of-book.
  • RFQ market makers — firms that provide binding quotes on demand. The router issues quote requests in parallel; quotes returned within the deadline join the routing decision. RFQ is preferred for order sizes that exceed on-book depth and for thinly traded markets.
A single user order may split across multiple sources to get the best aggregate fill — e.g., 50 shares from a venue CLOB + 50 from a market maker. Internally, the router consumes the Trading API for venue fills and settles RFQ fills via atomic swap with the market maker (USDC and shares move in a single on-chain transaction). Either way, the result is real on-chain shares in Predexon’s pooled treasury wallet — see How positions are backed.

Transparency

Order and trade responses include a metadata.fills array. Each entry records its source ("venue" or "rfq"), size, price, fee, and (on trades) the on-chain txHash — enough for users to verify routing against the underlying chain.

Positions

A position in Ledger represents the user’s economic exposure, not a specific on-chain token. A user holding 100 “Trump 2028 Yes” shares in their Ledger account is backed by 100 real “Yes” shares held on a venue (or split across multiple venues) by Predexon’s pooled treasury wallet — see How positions are backed. See List Positions for the full shape.

Settlement and redemption

When a market resolves:
  1. Predexon redeems winning positions on each venue using its venue-side wallets.
  2. The redemption proceeds (native USDC on Polygon, USDT on BSC, native USDC on Base, USDH on HyperCore, etc.) are converted to canonical USDC on Base inside Predexon’s treasury.
  3. Each user’s Ledger balance is credited with their payout (= position size × per-share payout).
Users do not need to call a redeem endpoint. There is no equivalent of redeem-position in Ledger — resolution is automatic. Each resolution is recorded in the user’s resolutions history with the user’s payout, realized PnL, and the on-chain redemption transactions for independent verification.

Withdrawals

Users withdraw USDC on Base by specifying an amount and a destination address. Predexon’s treasury sends USDC. The user’s Ledger balance decreases by the withdrawal amount plus any withdrawal fee. Multi-chain withdrawal is not supported at launch.

How positions are backed

Every Ledger position is 1:1 backed by a real on-chain position on a venue. When a user buys 100 Yes shares on Ledger, Predexon’s router immediately acquires 100 Yes shares — by hitting one or more venue CLOBs and/or settling atomic swaps with market makers — into its pooled treasury wallet. The user holds a Ledger entry; Predexon holds the matching on-chain tokens. They match exactly, regardless of which sources filled the order. Implications:
  • Predexon never takes the other side of a user’s trade. Predexon’s net exposure to any prediction market is zero.
  • Revenue is fees-only — execution spread on routing plus withdrawal fees. Trading fees are venue-passthrough: whatever the underlying venue charges is what the user pays, with no Predexon markup. Predexon does not profit when users lose, and does not lose when users win.
This is a fully-collateralized backing model — no proprietary book, no internal netting, no warehoused risk.

Identity and ownership

Accounts are scoped to API keys (same model as Trading API) — one key can own many accounts; each account belongs to exactly one key.

Consistency and ordering

Balance updates are synchronous on POST /orders — market orders show the final filled amount; limit orders move USDC from balance.available to balance.locked. Fills on open limit orders arrive asynchronously as venue matches occur, typically within seconds. Resolutions settle asynchronously after a market resolves, with venue redemptions typically completing within minutes.