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.
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 |
EventType are the event-specific data.
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.
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) |
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:
- Parse the Open event from the transaction the user signed and submitted.
Extract the
userOrder field, which is the onchain address of the order.
- Watch for subsequent transactions that reference the same
userOrder
address and emit a UserOrderEvent with userOrderEventType = 0x02 (Fill).
- Handle terminal states: if you see
userOrderEventType = 0x03 (Cancel)
or 0x04 (Revert), the order did not fill.
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.
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 / inputAmountoutputMint / 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:
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 |
| Field | Description |
|---|
consumedInputAmount | Input consumed in this fill |
producedOutputAmount | Output produced in this fill |
platformFeeAmount | Platform fee taken in this fill |
Related Pages
