What you get
- Identical event format to Dome — same 16 fields, same field names, same types
- Pre-chain delivery: events arrive 3-5 seconds before on-chain confirmation (and before Dome)
- All existing filters work:
condition_ids,wallets,tokens,slugs,side,min_size - One subscription type change:
"dome"instead of Dome’s"orders"
Quick start
1. Get an API key
Sign up at polynode.dev to get your API key.2. Connect
Replace your Dome WebSocket URL with polynode’s:3. Subscribe
The subscribe message changes slightly. Dome usedplatform and version fields that polynode doesn’t need:
4. Process events
No changes needed. The event format is identical:Event format
Every event is a flat object with 16 fields, matching Dome’s format exactly.Wrapper
Data fields
Example event
Order perspective
Each on-chain settlement produces multiple fill events, one perOrderFilled log. This is identical to how Dome works.
Maker fill events: user is the maker’s address, taker is the actual taker’s wallet address, order_hash is the maker’s EIP-712 order hash.
Taker fill events: user is the taker’s address, taker is the exchange contract address (not a real wallet). The order_hash is the taker’s EIP-712 order hash.
The exchange contract address depends on the market type:
This happens because the Polymarket CTF Exchange settles the taker’s order against itself as an intermediary. The on-chain
OrderFilled event reflects this, and both Dome and polynode pass it through as-is.
To find your order’s fills: Check if event.user === yourWallet. When it matches, event.order_hash is your order’s hash.
If you’re using polynode’s standard trade or settlement event subscriptions instead of the Dome-format feed, the same logic applies but the field is called maker instead of user. See Tracking a specific wallet’s trades on the Trade Event reference or the equivalent section on the Settlement Event page.
If you’re using polynode’s standard trade event subscription instead of the Dome-format feed, the same logic applies but the field is called maker instead of user. See Tracking a specific wallet’s trades on the Trade Event reference for the equivalent explanation.
Copy trading example
If you’re building a copy trading system that tracks orders by hash:Full migration example
Complete before/after showing the Dome to polynode migration:What changes
What stays the same
- All 16 data fields:
order_hash,user,taker,tx_hash,side,price,shares,shares_normalized,token_id,token_label,condition_id,market_slug,title,timestamp,block_number,log_index - One event per order fill (not bundled)
order_hashbelongs touser- Taker fills show exchange contract as
taker - All filter types:
condition_ids,wallets,tokens,slugs,side,min_size
Filters
The dome subscription supports all standard polynode filters:Differences from Dome
block_number and log_index are always null. polynode detects settlements from the Polygon mempool before they are included in a block. This is why events arrive 3-5 seconds before Dome. The tradeoff is that block-level fields aren’t available at detection time.
Minor floating-point precision differences on price and shares. polynode computes fill amounts from transaction calldata, while Dome reads from on-chain OrderFilled event logs. In rare cases (~1% of fills), this produces sub-penny price differences (e.g. 0.76 vs 0.7599999821) or shares off by 1 unit in millions. All other fields are byte-identical.
No subscription_id in event wrapper. Dome includes a subscription_id field in every event message. polynode does not include this field, consistent with all other polynode subscription types. If your code reads msg.subscription_id, it will be undefined but this should not affect event processing.
Order Placement
If you used Dome’s trading SDK to place orders on Polymarket, the polynode SDK is a drop-in replacement with two key improvements: your credentials stay on your machine (not on a third-party server), and wallet type is auto-detected so you don’t need to know if you’re EOA, Proxy, Safe, or deposit wallet.Requires Node.js 18 or later.

