# Markets (/docs/strategies/markets)



Market strategies are the **clearing-native** family: instead of the engine
*pushing* <Term name="Work" /> to a chosen <Term name="Worker" />, workers
**compete** for it, and the winner is chosen by market rules rather than a fixed
score. That competition can be a race to claim or a market session that records
<Term name="Bid" />s and settlement outcomes — the same primitives the whole
[clearing lifecycle](/docs/clearing-layer) is built on, exposed as strategies.

Two market primitives ship today: `shark_tank`, the broadcast-and-claim strategy
behind speed-to-lead, and the market-session assignment layer for recording
winners, prices, and <Term name="Settlement" /> receipts on a routing decision.
The same machinery carries **Agent RFQ**: typed bid terms, buyer-side clearing,
authenticated bid submission, and award-to-settlement all ship today — see
[Agent procurement](/docs/strategies/agent-procurement). What is not yet built is
the RFQ front door: publishing a task spec and having agents bid on it
autonomously.

| Strategy                                                     | Output          | Status    |
| ------------------------------------------------------------ | --------------- | --------- |
| [Shark tank](#shark-tank)                                    | session-based   | Available |
| [Market sessions & settlement](#market-sessions--settlement) | market-clearing | Available |

## Shark tank [#shark-tank]

**Capabilities:** stateful, explain · &#x2A;*Aliases:** `broadcast_claim`

Broadcasts an opportunity to **N candidates simultaneously** and assigns it to
the **first one to claim it**. It is the claim primitive behind
speed-to-lead and ping/post-style competition, driven by the ping/post service.

**Why use it.** When responsiveness is the selection criterion — you want the
recipient who is ready *right now*, not the one who scores best on paper. Instead
of guessing who will act fastest, you let them race. Classic uses: lead
distribution where the first agent to grab a lead works it, on-call escalation,
and any "whoever's available first" assignment.

**How it works.** It is `stateful` — it tracks the open broadcast and the claim
race — and produces a **session-based** output rather than an instant winner:
the decision resolves when a claim arrives (or the session times out and falls
back). It advertises `explain`, so the claim outcome is auditable. It is
registered by `builtin.RegisterBuiltins` with a fallback strategy (default
`smooth_weighted_round_robin`) for the no-claim case.

**Where it fits.** The `Select` stage, but unlike single-shot strategies its
result is a durable claim session. See
[idempotency](/docs/concepts/idempotency) for how claims commit exactly once.

## Market sessions & settlement [#market-sessions--settlement]

**Output:** market-clearing

The assignment and settlement layer supports a **multi-winner session**:
participants submit <Term name="Bid" />s, prices are set, and
winners are committed with a settlement receipt — and the outcome is recorded on
the <TechnicalName public="Route" api="Decision" /> as a `MarketDecisionRef`.

The reference captures the whole settlement, not just the winner:

| Field                 | Meaning                                                                                  |
| --------------------- | ---------------------------------------------------------------------------------------- |
| `SessionID`           | The market session that produced the decision.                                           |
| `ResultID`            | The clearing result.                                                                     |
| `PolicyHash`          | Hash of the clearing/disclosure policy in force.                                         |
| `WinnerCount`         | How many participants won (multi-winner markets).                                        |
| `SettlementReceiptID` | Proof the route, connector, and ledger commits happened together.                        |
| `Prices`              | Per-participant `MarketPriceRef` — `RecipientID`, `BidID`, `Amount`, `Currency`, `Rule`. |
| `BlockerReasons`      | Redacted reasons a session was blocked, if any.                                          |

**Lifecycle.** Close the market to stop accepting bids, then commit the winner
set and settle. Validation
on the ref rejects a missing `SessionID`, a negative `WinnerCount`, or a price with
a negative amount or missing `RecipientID`.

**Where it fits.** This is the durable record and commit path a market strategy
resolves to.

## Related [#related]

<Cards>
  <Card title="Ranked slates" href="/docs/strategies/ranked">
    Multi-winner clearing produces ordered slates of buyers.
  </Card>

  <Card title="Governance" href="/docs/strategies/governance">
    Custom and remote runtimes for bringing your own clearing logic.
  </Card>

  <Card title="Idempotency" href="/docs/concepts/idempotency">
    How claims and bids commit exactly once under concurrency.
  </Card>
</Cards>