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

# Receipts and cancels

> What a trade returns and how the SDK explains a keeper cancel.

Every trading call returns a `TradeReceipt` once the keeper has acted:

**requestKey** `Hex`

The PositionRouter request key, the value `getRequestKey` returns. Opens and closes are numbered separately, so an open and a close can share a key.

**submitTx, keeperTx** `Hash`

Your transaction and the keeper's.

**status** `'executed' | 'cancelled'`

**market, side, sizeDelta, collateralDelta** `string`

What changed, in USD.

**fillPrice, fees** `string`

From the Vault event of the execution.

**executionMs** `number`

Wall time from your confirmed transaction to the keeper outcome.

**timeGapSec** `number`

Request to execution, as the contract measured it.

**cancelReason, cancelDetail** `string`

Why the keeper cancelled: `slippage`, `capacity`, `paused` or `unknown`, with the contract's revert reason.

## How a cancel is explained

The keeper's Execute and Cancel events do not say why. When a request is cancelled, the SDK replays the keeper's call on the block before and reads the revert: `Vault: buffer` or a cap becomes `capacity`, a price past your limit becomes `slippage`, a pause becomes `paused`. The `trade.*` calls throw `RequestCancelled` with this receipt; `zeus.track` returns it.

## How the receipt is matched

Execute and Cancel events carry no request key. The SDK reads the request's create block from the event's `blockGap`, and among identical requests from the same account created in that block, the n-th one by index owns the n-th outcome, the order the keeper runs them. Matching is exact even for identical orders and across processes.


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