Endpoint
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.
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: setFLOOR, MARGIN and the confidence tiers from your own risk
appetite.

