eth_subscribe with newHeads) and measure when blocks arrive at the Portal versus when they appear at the RPC. Use this to monitor relative latency.
The watcher is a query-transformer combo that already includes the block query it needs. Pass it directly as the source’s outputs:
rpcUrl: Array of RPC WebSocket or HTTP URLs to compare against PortalresolveTimeoutMs: How long to wait for an endpoint to report a block before recording it asrpc-behind. Defaults to60_000
LatencySample[], holding the samples that became decidable in that batch, so iterate it. Each sample carries the observed block’s number and timestamp, portal.receivedAt (when the block arrived from the Portal), and an rpc array with one entry per configured endpoint.
An rpc entry that resolved carries url, hash, receivedAt, and portalDelayMs. The delay is signed: a negative value means the Portal delivered the block before that endpoint did.
An entry for an endpoint that did not report the block carries unresolved instead of receivedAt and portalDelayMs:
Count unresolved entries rather than charting them. A missing delay is not zero.
See the Data freshness monitoring guide for a complete example with Prometheus metrics.