Skip to main content
The network status page watches the Parallax network continuously: who is mining, how evenly, whether the largest miner is publishing its blocks, and every reorganization its nodes see. Everything it shows is available as JSON, so your deposit policy can read the same figures. Confirmations explains what they mean; this page is the reference for reading them.

Endpoint

No key or account is needed. Responses are JSON, uncached (Cache-Control: no-store) and allowed from any origin. Each address may make 60 requests a minute; past that the API answers 429 with Retry-After: 60. Polling every 30 to 60 seconds is plenty: the figures change with each block, and blocks are 10 minutes apart. Units: times are Unix milliseconds unless a field name says seconds. Shares are fractions from 0 to 1. Difficulties are decimal strings.

Fields for a deposit policy

The API does not apply the hold rule for you: levels keep their values while watch.level is "critical". Check watch yourself.

Alerts

There is no alert for a long gap between blocks. Compute serverTime − bestBlock.timestamp yourself, and check your own nodes’ head.

What the status page can and cannot tell you

The status page is a strong second opinion, not a replacement for your own nodes.
  • It sees the nodes that report to it. Its chain data comes from a set of verified nodes run by known operators; anyone else’s reports affect only their own rows and a few medians. It does not itself check proof of work.
  • Miners are identified by payout address. One operator mining to many addresses looks like many miners unless the status page knows its addresses. The largest miner’s share is therefore a lower bound on the largest operator’s.
  • It is one service. If it is unreachable, your policy should fall back to your own figures, not stop working and not drop its safeguards.
Compute the largest miner’s share from your own node too, and use the larger of the two:

A policy in code

A sketch in Python that combines the fields above with the rules in Building a policy. It is a starting point to adapt, not a drop-in risk engine: set FLOOR, MARGIN and the confidence tiers from your own risk appetite.
Run it at the moment of crediting, after your own checks from Tracking confirmations: the block hash is still the one you recorded, and your nodes are healthy and agree.