Skip to main content
Every channel has a pending feed. 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.
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.

​
Mempool frame

{
  "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.
FieldDescription
seen_at_msWhen Radion first saw the pending transaction (Unix ms).
transaction_hashThe pending transaction hash. Use it to match the pending one to the confirmed event.
from / toThe sender and the Polymarket contract that was called.
contract_kindsThe contract type of to: exchange, oracle, lifecycle, ctf, combos, wallet_factory, or unknown.
method_selectorThe 4-byte function selector, or null if the calldata is shorter than 4 bytes.
callDecoded fields (see below), or null if the calldata is not a known Polymarket call.
inputThe raw calldata. Always there, so you can decode more yourself.
valueThe 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:
FieldMeaning
methodThe decoded function name (e.g. fillOrder, redeemPositions).
market_idsCondition/market ids found in the arguments.
token_idsTrade token ids and position ids found in the arguments.
walletsAddresses found in the arguments.
notional_usdIntended fill notional in USD (exchange trades only); null otherwise.
ordersPer-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 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:
1

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.
2

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.
3

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.
Last modified on July 5, 2026