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

# Parse Onchain Trades

> How to parse prediction market trades, detect order fills, and calculate volume and fees onchain

This page explains how to parse prediction market trades onchain using the
Prediction Markets program IDL. The program account is:
`pReDicTmksnPfkfiz33ndSdbe2dY43KYPg4U2dbvHvb`.

Use this approach when you need:

* **Real-time fill detection**: detect order fills with minimal latency by
  watching onchain events directly instead of polling the REST API.
* **Onchain analytics**: compute volume, fees, and fill rates from raw
  program events.

If you only need user-facing trade history, use the
[Trades API](/resources/metadata-api/trades/trades).

## Event Format

Events are emitted via the `EmitEvent` instruction. The discriminator is
`0xF0`, zero-padded to 8 bytes: `0xf000000000000000`.

The first byte after the discriminator (byte 8) is the `EventType`, which
tells you what kind of event was emitted:

| Value  | EventType  | Description                |
| ------ | ---------- | -------------------------- |
| `0x01` | Market     | Market-level event         |
| `0x02` | UserOrder  | User order lifecycle event |
| `0x03` | UserRedeem | User redemption event      |

The remaining bytes after `EventType` are the event-specific data.

<Warning>
  Decode the `UserOrderEvent` and `UserRedeemEvent` to determine order related info. Do not rely on raw instruction data, instruction formats can change without notice, but the event schema is stable.
</Warning>

## Order Lifecycle

When a user places an order, the program emits a `UserOrderEvent`
(`EventType` = `0x02`). The next byte (byte 9) is the
`userOrderEventType` field, which tracks the order lifecycle:

| Value  | Type   | Description                                |
| ------ | ------ | ------------------------------------------ |
| `0x01` | Open   | Order placed and pending fill              |
| `0x02` | Fill   | Order (partially or fully) filled          |
| `0x03` | Cancel | Order cancelled (e.g., FOK/IOC not filled) |
| `0x04` | Revert | Order reverted (e.g., slippage exceeded)   |

The first event for a new order is always `Open`. Subsequent events (Fill,
Cancel, or Revert) are emitted in later block slots.

When a user redeems an outcome token, the program emits a `UserRedeemEvent`
(`EventType` = `0x03`) instead.

### Byte Layout Summary

| Byte(s) | Field                     | Description                                                                 |
| ------- | ------------------------- | --------------------------------------------------------------------------- |
| 0–7     | Instruction discriminator | `0xf000000000000000`                                                        |
| 8       | `EventType`               | `0x01`=Market, `0x02`=UserOrder, `0x03`=UserRedeem                          |
| 9       | `userOrderEventType`      | UserOrderEvent only: `0x01`=Open, `0x02`=Fill, `0x03`=Cancel, `0x04`=Revert |
| 10+     | Event fields              | Remaining event-specific data                                               |

## Detecting Order Fills

To detect whether a specific order has been filled, follow this flow:

1. **Parse the Open event** from the transaction the user signed and submitted.
   Extract the `userOrder` field, which is the onchain address of the order.
2. **Watch for subsequent transactions** that reference the same `userOrder`
   address and emit a `UserOrderEvent` with `userOrderEventType` = `0x02` (Fill).
3. **Handle terminal states**: if you see `userOrderEventType` = `0x03` (Cancel)
   or `0x04` (Revert), the order did not fill.

<Info>
  As long as you output to the user's wallet (rather than using the
  `destinationWallet` parameter), the fill transaction will appear in the user's
  transaction history. You can subscribe to a transaction stream for the user's
  address and parse each transaction to detect fills in near real-time.
</Info>

### Matching Opens to Fills

Use the `userOrder` field in `UserOrderEvent` to link related events.

* The Open event and its Fill event(s) share the same `userOrder` value.
* A single Open can have multiple Fill events (partial fills).

## Volume Calculation

In `UserOrderEvent`, use:

* `inputMint` / `inputAmount`
* `outputMint` / `outputAmount`

One of the mints will be a settlement mint (USDC or CASH), so you can sum the
corresponding amounts across Fill events to compute volume.

## Fee Calculation

`UserOrderEvent` includes:

* `feeMint`
* `feeAmount`

Fees are paid in the settlement mint, so summing `feeAmount` across Fill events
gives total fees.

## Relevant IDL Fields

From the IDL:

**UserOrderEvent**

| Field                | Description                                                              |
| -------------------- | ------------------------------------------------------------------------ |
| `userOrderEventType` | Lifecycle stage (`0x01`=Open, `0x02`=Fill, `0x03`=Cancel, `0x04`=Revert) |
| `userOrder`          | Onchain address of the order (links Open to Fill events)                 |
| `inputMint`          | Mint of the token the user sent                                          |
| `inputAmount`        | Amount of input token                                                    |
| `outputMint`         | Mint of the token the user received                                      |
| `outputAmount`       | Amount of output token                                                   |
| `feeMint`            | Mint used for fees (settlement mint)                                     |
| `feeAmount`          | Fee amount in the fee mint                                               |

**FillInstructionParams**

| Field                  | Description                     |
| ---------------------- | ------------------------------- |
| `consumedInputAmount`  | Input consumed in this fill     |
| `producedOutputAmount` | Output produced in this fill    |
| `platformFeeAmount`    | Platform fee taken in this fill |

## Related Pages

* [Prediction Market Data Model](/prediction-markets/prediction-market-data-model)
* [Prediction Market Fees and Rebates](/prediction-markets/prediction-market-fees)
* [Trades API](/resources/metadata-api/trades/trades)