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

# Hedge venue exposure

> Measure a venue's customer-book exposure and place a separate hedge in a venue-owned provider account.

Venue hedging keeps two books separate:

1. Customers trade on the TRDRS-held venue book. Their fills, balances and P\&L stay there.
2. The venue measures the net exposure of an account group.
3. A hedge policy creates a target in a separate provider account owned by the venue.
4. TRDRS sends and reconciles that hedge as its own order.

It does not forward a customer's order to a liquidity provider or rewrite a customer fill after the
fact. A hedge failure changes the hedge report, not the customer's trading result.

## Before you activate a policy

* Connect and validate a provider under the venue.
* Discover an account with both read and trade permission.
* Bind it with `mode: "hedge"`. A hedge account cannot be invited or shown to a trader.
* Activate the instruments you will hedge, including their mapping to the provider connection.
* Create the customer account group whose net exposure the policy will measure.
* Issue a Venue key with `hedge:read`, `hedge:manage` and `hedge:execute` as needed.

Production activation also requires a qualified provider. Sandbox may use a provider that has passed
the sandbox checks.

## Publish and activate

```bash theme={null}
curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/policies" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hedge-policy-standard-v1" \
  -d '{
    "groupId": "standard",
    "name": "Standard 100% hedge",
    "destinationAccountId": "00000000-0000-0000-0000-000000000001",
    "ratio": "1",
    "quantityCap": null,
    "notionalCap": null,
    "residualThreshold": "0.001"
  }'
```

Publishing changes nothing by itself. Activate the returned policy with compare-and-swap:

```bash theme={null}
curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/activation" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: activate-standard-v1" \
  -d '{"policyId":"POLICY_ID","state":"active","expectedRevision":null}'
```

## Calculate, dispatch and reconcile

`POST /api/partner/venues/{venueId}/hedges/calculate` reads the durable customer book and stores one
target. The target records customer exposure, desired hedge, confirmed provider position, already
pending amount and rounding residual separately. Repeating a calculation against the same source
checkpoint returns the same target and intent.

Set `dryRun: true` on that request to preview the same calculation without saving a target, creating
an order, writing an audit event or sending a webhook.

Dispatch the returned intent through
`POST /api/partner/venues/{venueId}/hedges/intents/{intentId}/dispatch`. A provider refusal removes the
pending amount. A lost or uncertain reply stays `unknown`; it still counts as pending so a retry
cannot double the hedge. Resolve it with the matching `/reconcile` call.

Read the full state with:

```bash theme={null}
curl "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY"
```

The report also returns aggregate execution count, adverse slippage in basis points, fees grouped by
currency and a `complete` flag. Missing fee data, unresolved commands and open incidents make the
report incomplete instead of silently reading as zero.

## Webhooks

The venue's existing signed webhook endpoints may subscribe to `hedge.target`, `hedge.intent`,
`hedge.fill`, `hedge.failure`, `hedge.drift` and `hedge.halt`. They use the same signature and retry
log as account and risk events. A hedge event always names a venue-owned hedge action; it never
claims that a customer order was routed externally.

## Emergency controls

Emergency stop pauses all policies, cancels additions that have not been dispatched and opens an
incident. It deliberately does not flatten the provider account.

Flattening is a separate explicit call:

```bash theme={null}
curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/flatten" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: flatten-incident-42" \
  -d '{"destinationAccountId":"DESTINATION_ACCOUNT_ID"}'
```

The reducing command remains available during a halt. It only targets an account bound to this
venue with hedge purpose and never closes a customer account.

## What can block a target

* the policy is not active
* provider state or its stream proof is stale
* the active instrument has no mapping for the destination connection
* the mark is older than the instrument's configured maximum age
* the customer book is incomplete
* an incident is open
* a previous command still has an unknown outcome

Treat these as incomplete operating state. Do not turn one into a zero exposure or a successful
hedge in your own reporting.