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

# Market Pages

> How to read the terminal workspace before placing an order.

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.

## Reading order

<CardGroup cols={2}>
  <Card title="1. Market state" icon="circle-dot">
    Confirm status, close time, selected child market, and outcome availability.
  </Card>

  <Card title="2. Price context" icon="chart-line">
    Compare chart movement, orderbook depth, midpoint, spread, and last activity.
  </Card>

  <Card title="3. Account context" icon="wallet">
    Check selected wallet, cash, positions, open orders, and funding state.
  </Card>

  <Card title="4. Action" icon="arrow-up-right">
    Use the ticket only after the market, price, and wallet context agree.
  </Card>
</CardGroup>

## Page contract

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

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

<Note>
  Resolved and closed states should be calm. They should not look like errors, and they should not keep active buy or sell controls visible.
</Note>

## Design rule

Market pages should feel like a terminal workspace: compact, aligned, and specific. Avoid provider jargon, oversized section titles, decorative charts, and repeated cards that do not help the trader decide what to inspect next.