Skip to main content
Polynode case studies test a concrete product claim against a defined denominator. Each study records its date, endpoints, subscription semantics, source versions, measurement clock, eligibility window, adverse observations, and limitations.

Polynode confirmation vs RTDS

Pending delivery, confirmation timing, confirmed-fill timing, and exact on-chain completeness measured on August 14, 2026.

Polynode vs Bravado

Pending latency, public-stream coverage, observed same-block copy execution, and product breadth measured on August 7, 2026.

Polynode vs Struct and RTDS

WebSocket latency, pending access, and confirmed-fill completeness measured on August 1 and retested on August 4, 2026.

Polygon block time and Polymarket

How Polygon’s move from 2.0-second to 1.5-second blocks compressed Polymarket’s pre-confirmation window without moving Polynode’s position in the transaction lifecycle.

​
Evidence standard

Every benchmark case study should:
  • define equivalent signals before measuring them;
  • timestamp all competitors from the same monotonic clock and process;
  • use an independent completeness denominator when one exists;
  • exclude partially observed boundary intervals;
  • preserve per-sample data, missing identifiers, source hashes, and connection lifecycle events;
  • report unfavorable windows and unavailable comparisons;
  • separate measured results from broader product claims;
  • publish code with credentials supplied only at runtime.
These are point-in-time measurements, not guarantees about every network location or future provider version.