> ## Documentation Index
> Fetch the complete documentation index at: https://docs.counsel.markets/llms.txt
> Use this file to discover all available pages before exploring further.
# Market Types, Lifecycle Phases, and Pool Structure
> A complete reference for counsel's two market families, the five lifecycle phases, pool account structure, void conditions, and per-market betting caps.
Every market on counsel is a self-contained on-chain object: a signed JSON definition stored as a memo on the XRP Ledger, a dedicated pool account that holds all stakes, and a resolution source that determines the winning outcome. Understanding how these pieces fit together tells you what a market can do, when you can act, and what happens if something goes wrong.
## Market families
counsel supports two resolution families. The family is set at market creation and cannot change.
### Family A, Oracle-resolved (crypto price)
Family A markets resolve automatically against an on-chain XLS-47 price oracle. No human input is required at resolution time. These markets are defined by:
| Field | Description |
| ------------------ | ------------------------------------------------------------------------------ |
| `oracleAccount` | XRPL account that publishes the oracle |
| `oracleDocumentId` | XLS-47 `OracleDocumentID` |
| `baseAsset` | Asset being priced (e.g. `"XRP"`) |
| `quoteAsset` | Denomination (e.g. `"USD"`) |
| `strike` | Price threshold for the binary condition |
| `comparison` | `">="` or `"<="`, the direction of the condition |
| `freshnessSeconds` | Maximum allowed age (seconds) of the oracle value relative to `resolutionTime` |
**Example condition:** `XRP/USD >= 0.60` at resolution time. If the oracle reports 0.62 within the freshness window, outcome 0 ("Yes") wins. If it reports 0.58, outcome 1 ("No") wins. If no fresh value is available, the market voids.
Family A markets have `disputeWindowHours: 0` by default, resolution is fully automatic with no dispute period.
### Family B, Manual (real-world events)
Family B markets cover events with no on-chain data source: sports results, political outcomes, economic data releases, and so on. Resolution is operator-proposed and subject to a dispute window.
| Field | Description |
| -------------- | ---------------------------------------------------------- |
| `source` | Named authoritative source (e.g. `"FIFA official result"`) |
| `condition` | Exact, pre-committed condition text |
| `date` | ISO date the condition is evaluated |
| `evidenceHint` | Optional hint to the evidence URL used at resolution |
The default dispute window is 48 hours. Any account with a stake can challenge the operator's proposal within that window by posting a bond.
## Market lifecycle
A market moves through a fixed sequence of phases. The current phase is returned as `phase` in `GET /api/v1/markets/:id`.
```
open → closed → resolving → resolved
↘ void
(Family B only: closed → disputable → resolving → resolved)
```
Bets are accepted. The pool accumulates. Odds shift with every new stake. This is the only phase in which you can place a bet.
`bet_cutoff` has passed. No new bets are accepted. The pool is frozen. The market is awaiting `resolutionTime` before settlement runs.
After `resolutionTime`, the operator publishes a resolution proposal and the dispute window opens (`disputeWindowHours`, default 48 hours). Any staked account can post a challenge bond during this period. This phase does not appear for Family A markets, which have `disputeWindowHours: 0`.
The dispute window has closed (or does not apply for Family A). The committee multisig is in progress. No further challenges can be submitted.
The winning outcome has been determined and payouts have been distributed. A `status: "final"` record is on-chain.
The market cannot be resolved fairly. All stakes are refunded at face value. No fee is charged. See [Void conditions](#void-conditions) below.
The `status` field returned by `GET /api/v1/markets/:id` shows only `open`, `resolved`, or `void`. The `phase` field carries the granular phase value (`open`, `closed`, `disputable`, `resolving`, or `resolved`).
## Pool structure on XRPL
Each market has a dedicated `poolAccount`, an XRPL `r`-address that holds all funds staked on that market. Outcomes are separated by **DestinationTag**:
* Outcome 0 → DestinationTag `0`
* Outcome 1 → DestinationTag `1`
* Outcome N → DestinationTag `N`
When you place a bet, you send a native XRP Payment to `poolAccount` with the DestinationTag corresponding to your chosen outcome. The pool account's master key is disabled; funds can only leave via a committee multisig at settlement.
You can verify the pool balance independently at any time by querying the XRPL for the pool account's transaction history.
## Void conditions
The following conditions trigger a full void and refund:
If all bets land on a single outcome (no opposing stake exists), there is no pool to distribute to the other side. The market voids and all stakes are returned.
At `resolutionTime`, the XLS-47 oracle value must have been published within `freshnessSeconds` of that timestamp (with a 120-second post-close grace period). If no fresh value is available, the market voids automatically.
If the underlying event is cancelled, indefinitely postponed, or produces a result that does not map cleanly to the defined outcomes (e.g. a draw on a binary win/loss market), the market voids.
On a void, each bettor receives their original stake back via a native Payment. Market-maker seed stakes are house-neutral and are not refunded, they remain as pool residue.
## Betting caps
Markets can impose limits to manage pool concentration. These are defined in the `caps` object:
| Field | Description |
| --------------- | ------------------------------------------------------------------------------- |
| `perBettorXrp` | Maximum total XRP a single account can stake across all outcomes in this market |
| `perOutcomeXrp` | Maximum total XRP that can accumulate on any single outcome |
| `perMarketXrp` | Maximum total XRP the whole market pool can hold |
Any of these fields may be absent, in which case no cap applies. Caps are enforced at bet submission; a bet that would breach a cap is rejected before it is submitted to the ledger.
## Market identity and deduplication
Every market has a deterministic `id` computed as the first 16 hex characters of `sha256(question | resolutionTime)`. Recurring market templates (e.g. daily XRP price markets) share a `templateKey`; only the most recently created instance per `templateKey` is shown in the default listing. Markets with `hidden: true` are retired or superseded and are not returned by the public API.