The market page is the main decision surface in PolyChads Terminal. It should answer four questions quickly: is the market live, what is the current price, what changed recently, and what action is available from the selected wallet.Documentation Index
Fetch the complete documentation index at: https://docs.polychads.app/llms.txt
Use this file to discover all available pages before exploring further.
Reading order
1. Market state
Confirm status, close time, selected child market, and outcome availability.
2. Price context
Compare chart movement, orderbook depth, midpoint, spread, and last activity.
3. Account context
Check selected wallet, cash, positions, open orders, and funding state.
4. Action
Use the ticket only after the market, price, and wallet context agree.
Page contract
Header
Header
Shows: title, selected child market, status, volume, open interest, and close time.Good state: the trader can tell exactly which market is selected.Watch for: a closed child market making the whole event feel closed.
Chart
Chart
Shows: outcome price history and selected range.Good state: movement is readable without oversized typography.Watch for: a loading state that hides the ticket or lower rail.
Orderbook
Orderbook
Shows: price levels, shares, total USD, midpoint, and spread.Good state: depth and spread explain the current quote.Watch for: empty depth shown as a route failure.
Ticket
Ticket
Shows: side, price, amount, shares, balance, and disabled reason.Good state: button state tells the next valid action.Watch for: active controls on a resolved or unavailable market.
Lower rail
Lower rail
Shows: orders, positions, activity, alerts, holders, comments, related markets, and info.Good state: every tab uses one compact alignment system.Watch for: stale provider labels or tabs using different font scales.
Lower rail data display
Each tab should have a clear job. The lower rail is not a dumping ground for provider fields.| Tab | Display priority |
|---|---|
| Orders | Market or side first, then open order state and cancellation context. |
| Positions | Outcome first, then exposure, value, and wallet scope. |
| Activity | Trader first, then type, outcome, price, shares, amount, age, and Tx. |
| Alerts | Signal first, then reason, timing, market, and action path. |
| Holders | Wallet first, then concentration and distribution. |
| Comments | Author first, then message context without breaking the trading layout. |
| Related | Market first, then status, close time, and route to live alternatives. |
| Info | Status first, then rules, resolution, timing, and event structure. |
Activity format
Activity should read like a transaction sentence.| Column | Reason |
|---|---|
| Trader | Starts with the actor. |
| Type | Shows buy or sell before the outcome. |
| Outcome | Shows what was traded. |
| Price | Shows execution level. |
| Shares | Shows position size. |
| Amount | Shows dollar value. |
| Age | Shows freshness. |
| Tx | Opens the transaction when available. |
Repeated and multi-outcome markets
Some events contain several child markets with different expiry windows. A closed child market should not make the parent event feel closed when another child market is live. The terminal should handle these cases clearly:| Situation | Expected behavior |
|---|---|
| Current child is live | Keep the active ticket and live status visible. |
| Selected child is closed | Show the closed state, then make live siblings easy to select. |
| Rolling market has a live successor | Route traders toward the current interval. |
| Parent event has mixed statuses | Explain status at child-market level, not only event level. |
Resolved markets
Resolved markets need a compact result panel, not a dead trading ticket. The page should show winning outcome, resolution time, prior position state, and whether any post-resolution action is available.Resolved and closed states should be calm. They should not look like errors, and they should not keep active buy or sell controls visible.