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

# Mempool

> Stream speculative pending Polymarket transactions before they are confirmed onchain.

Every channel has a [pending feed](/websockets/channels/overview#mempool-channels). Set `confirmed: false` on the subscribe message to get pending Polygon transactions to Polymarket contracts, before they land in a block. Use it for early visibility — alerts before confirmation, low-latency feeds, and checking pending against confirmed events.

<Warning>
  Mempool messages are guesses, not facts. A pending transaction can be dropped,
  replaced, reordered, or reverted. Use confirmed channels like `trading` as the
  real, final onchain truth.
</Warning>

## Mempool frame

```json theme={null}
{
  "type": "event",
  "id": "pending-trades",
  "channel": "trading",
  "confirmed": false,
  "data": {
    "seen_at_ms": 1782027489000,
    "transaction_hash": "0x...",
    "from": "0x...",
    "to": "0x...",
    "contract_kinds": ["exchange"],
    "method_selector": "0x...",
    "call": {
      "method": "fillOrder",
      "market_ids": [],
      "token_ids": ["713210..."],
      "wallets": ["0x...", "0x..."],
      "notional_usd": 1000,
      "orders": [
        {
          "maker": "0x...",
          "taker": "0x...",
          "token_id": "713210...",
          "side": "buy",
          "maker_amount": "200000000",
          "taker_amount": "100000000"
        }
      ]
    },
    "input": "0x...",
    "value": "0"
  }
}
```

`confirmed` sits on the envelope (next to `type`, `id`, `channel`), and is `false` on pending frames. The `channel` is the bare name (`trading`), the same as the confirmed feed — tell them apart by `confirmed`, and route by your subscription `id`.

| Field              | Description                                                                                                    |
| ------------------ | -------------------------------------------------------------------------------------------------------------- |
| `seen_at_ms`       | When Radion first saw the pending transaction (Unix ms).                                                       |
| `transaction_hash` | The pending transaction hash. Use it to match the pending one to the confirmed event.                          |
| `from` / `to`      | The sender and the Polymarket contract that was called.                                                        |
| `contract_kinds`   | The contract type of `to`: `exchange`, `oracle`, `lifecycle`, `ctf`, `combos`, `wallet_factory`, or `unknown`. |
| `method_selector`  | The 4-byte function selector, or `null` if the calldata is shorter than 4 bytes.                               |
| `call`             | Decoded fields (see below), or `null` if the calldata is not a known Polymarket call.                          |
| `input`            | The raw calldata. Always there, so you can decode more yourself.                                               |
| `value`            | The native POL value sent with the transaction.                                                                |

### The `call` object

Radion reads each pending transaction's calldata and turns it into a `call` object. It holds the fields the channel filters use, plus the decoded orders:

| Field          | Meaning                                                                 |
| -------------- | ----------------------------------------------------------------------- |
| `method`       | The decoded function name (e.g. `fillOrder`, `redeemPositions`).        |
| `market_ids`   | Condition/market ids found in the arguments.                            |
| `token_ids`    | Trade token ids and position ids found in the arguments.                |
| `wallets`      | Addresses found in the arguments.                                       |
| `notional_usd` | Intended fill notional in USD (exchange trades only); `null` otherwise. |
| `orders`       | Per-order detail for exchange trades; empty for non-trade calls.        |

Each entry in `orders` carries `maker`, `taker` (`null` for v2 exchange orders), `token_id`, `side` (`"buy"` or `"sell"`), `maker_amount`, and `taker_amount`. Amounts are decimal strings in base units, the same format as `token_ids`. There is no derived price yet — compute it from the amounts if you need one.

`call` is `null` when the selector is not a known Polymarket state-changing call. Transactions whose calldata cannot be decoded still stream on their contract-type channel with `confirmed: false`. They just have no `call` to filter on.

## Filter reach

Mempool [filters](/websockets/filters) run against the `call` fields above. A filter only works where the field is a real calldata argument, because the blockchain limits what you can read before a transaction runs:

* **`market_ids`** — matches trades (v2), splits, merges, redemptions, and conversions that pass a `conditionId`/`marketId` argument. It cannot match ids the contract builds at run time (`prepareCondition`/`prepareMarket`), combos modules (which use a different `bytes31`/`bytes29` id), or oracle calls (which carry only a `questionId`).
* **`token_ids`** — matches the token ids in trade orders and the position ids in redemptions, bridge, and combos calls.
* **`min_usd`** — exchange trades only. Same filter name on both feeds, but they measure different things: confirmed measures the **filled** amount; pending measures `call.notional_usd`, the **intended fill** of the pending order, which may only partly fill or never land.
* **`wallets`** — the sender and recipient (`from`/`to`), plus any wallet read from the calldata.

## Reconcile with confirmed streams

Use the pending and confirmed feeds together:

<Steps>
  <Step title="Subscribe to a channel with confirmed: false">
    Set `confirmed: false` on `trading` (or any channel) when you want to see
    things early, before block confirmation.
  </Step>

  <Step title="Subscribe to the same channel confirmed">
    Subscribe to the same channel (default `confirmed: true`) to get the final
    decoded event after the transaction lands in a block. Give it a different
    `id`.
  </Step>

  <Step title="Reconcile by transaction hash">
    Match `data.transaction_hash` from the pending frame with the confirmed
    event's transaction hash, when your client keeps both streams.
  </Step>
</Steps>