> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise.predexon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ledger

> One address. One currency. Every prediction market.

## 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.

<Info>
  **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](/ledger/concepts#how-positions-are-backed).
</Info>

## 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

| Surface       | Trading API                                                               | Ledger                                                                 |
| ------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Wallets       | One per venue, exposed to the user                                        | One deposit address                                                    |
| Currencies    | Four stablecoins across multiple chains (USDC.e, USDT BEP-20, USDC, USDH) | USDC only                                                              |
| Order routing | User picks the venue                                                      | Predexon routes to best price across venue books and RFQ market makers |
| Positions     | Separate positions per venue, scattered across chains and tokens          | **One unified entry per market** — no venues or chains to track        |
| Redemption    | User must redeem winning positions                                        | Auto-redeemed; user's USDC balance is credited                         |
| Withdrawal    | Per-venue, per-chain                                                      | One 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

<CardGroup cols={2}>
  <Card title="Concepts" href="/ledger/concepts">
    Custody, routing, settlement, and the mental model
  </Card>

  <Card title="API Reference" href="/ledger/api-reference/overview">
    Endpoints and request/response shapes
  </Card>
</CardGroup>