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

# Survival ladders

> A row of binary rungs that together encode a valuation distribution

Most markets on SOAR are not standalone questions. They come in **survival ladders**:
a row of binary markets on ascending valuation thresholds for the same company, each
asking *"is this company worth more than \$T?"* for a different `T`.

```
ANTHROPIC-VALUATION-26Q3-262.5B   yes @ 98¢
ANTHROPIC-VALUATION-26Q3-525B     yes @ 96¢
ANTHROPIC-VALUATION-26Q3-1.05T    yes @ 76¢
ANTHROPIC-VALUATION-26Q3-2.1T     yes @ 34¢
ANTHROPIC-VALUATION-26Q3-4.2T     yes @  5¢
```

Each rung is an ordinary [binary market](/concepts/binary-markets) with its own book.
What makes it a ladder is the relationship between them.

## Monotonicity

Exceeding a higher threshold is never more likely than exceeding a lower one:

```
P(>$262.5B)  ≥  P(>$525B)  ≥  P(>$1.05T)  ≥  P(>$2.1T)  ≥  P(>$4.2T)
```

So rung prices should descend as strikes rise. This holds by the structure of the
question, not by anyone enforcing it on the book — which means **you will sometimes
see it violated**, from thin liquidity or a stale quote on one rung.

<Tip>
  A pair of rungs quoted out of order is the most legible inefficiency on the venue,
  and finding it needs nothing but two prices from the same snapshot. It is where most
  ladder strategies start.
</Tip>

## The ladder is a distribution

Because each rung price is a survival probability, the *differences* between adjacent
rungs are the probability mass in each band:

| Band | Mass |
| - | - |
| under \$262.5B | `1 − 0.98` = 0.02 |
| $262.5B – $525B | `0.98 − 0.96` = 0.02 |
| $525B – $1.05T | `0.96 − 0.76` = 0.20 |
| $1.05T – $2.1T | `0.76 − 0.34` = 0.42 |
| $2.1T – $4.2T | `0.34 − 0.05` = 0.29 |
| over \$4.2T | 0.05 |

Five prices give you the market's whole view of where the company's valuation lands,
and you can compute an expected value from it directly. This is the reason to model a
ladder as one object rather than five unrelated markets: **a view about the valuation
is a view about the shape of that distribution**, and it usually implies trades on
several rungs at once.

Prices are not probabilities exactly — the spread and fees sit between them — so treat
this as the market's estimate, not an oracle.

## Addressing a ladder

Tickers nest by prefix, three levels:

```
series    ANTHROPIC-VALUATION
event     ANTHROPIC-VALUATION-26Q3        the series, for one resolution quarter
market    ANTHROPIC-VALUATION-26Q3-1.05T  one rung
```

So `series ⊂ event ⊂ market`, and two useful things follow:

* `GET /v1/events/{event_ticker}` returns every rung of that quarter's ladder,
  ordered by strike. One call, whole ladder.
* Passing the **series** ticker returns every quarter in the series.

Tenors are quarter-granular (`26Q3`, never `26`) because ladder events roll quarterly.
A year-only tenor would collide with the next roll.

<Warning>
  **Containment is a prefix guarantee, not a decomposition rule.**

  Every market ticker begins with its event ticker — that always holds. Splitting a
  market ticker back into event and strike does **not**: strikes contain dots
  (`212.5B` and `2125B` are different rungs) and nothing forbids a hyphen inside one.
  Cutting on the last `-` works on today's labels and is not part of this contract.

  Use the `event_ticker` field, which every market, order, and position carries. And
  never sanitize a ticker to alphanumeric — the dots are load-bearing.

  **The series segment is assigned, not derived.** It is usually the company symbol plus
  the category spelled out, as above — but an operator may name a series outright, and
  then it is simply whatever precedes the tenor: `STRP-PYPL-26Q4` has series
  `STRP-PYPL`, which is neither a symbol nor a category. Read `series_ticker` off the
  response instead of assembling it, and never infer one company's series from another's.
</Warning>

## Rungs trade independently

Each rung has its own book, its own order flow, and its own fills. A fill on the $500B
rung is not a fill on the $750B rung, and there is no single order that spans both — a
band view is two orders, placed and managed separately.

## Resolution

Each rung resolves against the same final valuation, independently: every rung whose
strike the valuation exceeded pays out `yes`, and the rest pay out `no`. Because the
thresholds are ordered, that is always a contiguous block of rungs settling `yes` from
the bottom.

See [Settlement](/concepts/settlement).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.