Pearl 1.5.7 adds node monitoring and fixes a testnet sync stall
Source report: 2026-11-12 · Editorial analysis published: 2026-11-13
The November 12 release gives pool operators optional node metrics and tightens how peers’ messages are handled. The change to proof validation concerns testnet.
A node release for pools and operators
Pearl Research Labs released v1.5.7 on November 12. It gives operators a way to monitor the Pearl node, strengthens the handling of messages from other nodes and fixes a point where a fresh testnet sync could get stuck. A node verifies and shares blocks; a mining program does the work used to find them. If a pool builds its jobs from its own node, the state of that node matters even when all the miners still show their normal speed.
The release notes describe changes to the node and its test network. They do not activate the proposed FP8 change on the main chain or add a new GPU requirement. If you run a miner through a pool, watch the pool’s separate compatibility instructions. If you run the node that supplies the work, the new features are relevant to how you monitor and maintain it.
There are two useful records to keep. The version of pearld tells you what software checked the blocks. The version of the miner tells you what produced the proof. Write both down when diagnosing a pool. A node release can make monitoring easier or reduce disruptions without changing the work a graphics card is expected to perform.
What the monitoring can show
The node program, pearld, can now serve metrics to Prometheus, a tool that collects measurements at regular intervals. These include the height and timestamp of the latest block, peer connections, block processing times and requests made to the node. Operators can compare those records across time. If workers are hashing as usual while the node is behind another independent source, it makes sense to check the node and its peers before changing miner settings.
The endpoint is off unless explicitly enabled and has no authentication of its own. Keep it on the host or in a private monitoring network, with access limited to the collector. You can decide which numbers deserve an alert once you have seen how they normally move. A low peer count or one slow request is a useful clue; neither by itself says the pool stopped issuing useful work.
For example, an operator could compare when the most recent block reached the node with when the pool issued its next job. If another independent node has already advanced and your node still shows the old height, that is a lead to follow. If your node sees the new block and miners still receive old jobs, follow the link between the node and the pool. The two events need their own records.
The measurements also include block processing time. A long processing time and a high chain tip are compatible: the node may have caught up after a slow block. An alert that combines a persistently old tip with other measurements can be more useful than an alert on a single slow block. Set the alert for the symptoms that actually interrupt the pool.
Why a new testnet node stalled
The project’s fix describes two blocks, 36,761 and 36,762, whose mining certificates used a rank of 64. Rank is a setting in the proof rules. The old testnet schedule required at least 128 from the first of those blocks, so a fresh node checking the old chain could reject block 36,761 and then ask for it again. The update moves the start of that rule to block 36,763. It lets a fresh sync pass both earlier blocks and keeps the rank floor afterward.
This fix is for the affected test network. It does not change the main chain’s proof rules. A pool testing a new build can check that a fresh testnet node gets past the two blocks. That exercise checks whether the sync fix works; it says nothing about how much a GPU earns on the main chain.
The developers also say they checked historical headers with the revised testnet parameters. That is evidence for this specific validation problem. If a test deployment still stalls elsewhere, record the last accepted height and the version before diagnosing it. A stall at another point can have a different cause, and a testnet rule change is not a reason to replace equipment on mainnet.
What changes in everyday operation
The release also limits how much memory some peer messages can make a node reserve before the data has arrived. It bounds some processing requested by lower-quality peers and stops using their timestamps to shift the node’s adjusted time. These changes address how the node handles outside traffic. For an operator, the most useful test after updating is to check both sides: whether the node continues to receive blocks and whether the pool keeps issuing fresh jobs and accepting work.
Record the node’s previous version and configuration before changing it. Check the published release and confirm the running version afterward. A dashboard can help show where an outage began, while a comparison with another source and the pool’s own accepted-work records tells you whether the problem reached the miners.
A straightforward deployment check is to take readings before and after the change under similar conditions. Compare whether block height keeps moving, peer connections stay available and the pool’s accepted work continues to rise. If one side stops first, save its log for the affected period. This gives the team an incident record it can reproduce without treating every short variation as a failure.
Source: Pearl Research Labs ↗ · Pearl — metrics implementation ↗ · Pearl — testnet sync fix ↗ · Pearl — network security changes ↗
Mining calculator ↗
