# Pearl v1.5 “Security hardening” and Wallet v3.0.0: what operators need to know

https://www.learnpearl.org/news/pearl-v1-5-security-hardening-wallet-v3/ · October 17, 2026 · Release

Every node operator was told to upgrade, miners and pools first. Wallet users get one important habit change.

## What shipped

- **v1.5.0 “Security hardening”:** Oct 13 · Security fixes across node, light client, wallet and services · _Live_
- **Pearl Desktop Wallet v3.0.0:** Oct 13 · Bundles v1.5.0; new handling of uncertain payments · _Live_
- **v1.5.1:** Oct 15 · Enforces transaction order inside a block (#438) · _Live_
- **v1.5.2:** Oct 17 · Keeps read-only lookups out of the UTXO cache (#440) · _Live_

The v1.5.0 notes thank twelve researchers who reported issues through GitHub security advisories, and the security firm Zellic for a report on how the light client counts peers.

## For node operators, miners and pools

- **Upgrade, miners and pools first.** v1.5.0 tightens a script validation rule: `OP_CHECKXMSSSIG` now fails a script on a wrong-length key or signature instead of returning false. Standard wallet spends are unaffected.
- **Long unconfirmed chains are capped** at 25 transactions (counting ancestors or descendants) and 101,000 vbytes of ancestors, and rejected beyond that.
- **Peers that fall behind are dropped**: a node disconnects a peer when more than 16 MiB or 1,000 messages are waiting to be sent to it, or when it reads less than 64 KiB in 30 seconds. RPC requests over 16 MB are refused.
- **Diagnostics stay local**: the profiler now listens on 127.0.0.1 only.

## For wallet users

> **Don’t pay twice.** In Wallet v3.0.0, a payment that may already be on the network stays pending, with its transaction ID, and the wallet points to Activity → Rebroadcast. Creating another payment can pay the recipient twice. A fresh retry is offered only when the send failed before signing because the wallet was offline.

The bundled node also ships a checkpoint at block 120,000, and the light client now checks peers against known filter headers.

## What the notes don’t say

Neither v1.5.1 nor v1.5.2 is labeled a fork, and Pearl hasn’t said whether the in-block ordering fix changes which blocks older nodes accept. If you run infrastructure, read the linked pull requests and stay on the current release.

## Sources

- [Pearl v1.5.0 “Security hardening” release notes](https://github.com/pearl-research-labs/pearl/releases/tag/v1.5.0) (Pearl Research Labs, primary)
- [Pearl Desktop Wallet v3.0.0 release notes](https://github.com/pearl-research-labs/pearl/releases/tag/pearl-wallet-v3.0.0) (Pearl Research Labs, primary)
- [Pearl v1.5.2 release notes](https://github.com/pearl-research-labs/pearl/releases/tag/v1.5.2) (Pearl Research Labs, primary)
- [PR #438: enforce in-block transaction ordering](https://github.com/pearl-research-labs/pearl/pull/438) (Pearl Research Labs, primary)
- [PR #440: keep read-only UTXO lookups out of the cache](https://github.com/pearl-research-labs/pearl/pull/440) (Pearl Research Labs, primary)