Monero Adds Wallet Protection Against Excessive Fees From Remote Nodes

Monero developers have merged wallet safeguards that limit fee parameters supplied by a node. Pull request #11295, submitted by selsta, entered the development branch on November 7, 2026, at 07:08 UTC. It reduces the scope for a dishonest or faulty daemon to influence a wallet with excessive fee estimates.

The change is currently available in development code. At our November 7 review, 0.18.5.4 remained the latest stable release, and its source did not contain these safeguards. The reviewed sources identify no confirmed exploitation or financial losses.

How remote nodes influence a wallet's fee

A wallet keeps its keys locally but asks a daemon for blockchain information. When preparing a transaction, Monero's wallet code requests get_fee_estimate. The response supplies fee rates for transaction priorities and a rounding parameter called the quantization mask. The wallet uses these values when calculating what to pay.

The node RPC code caches those estimates. A node does not need a wallet's private keys to answer the request, and choosing a remote node does not give its operator direct spending authority. The concern is the information entering the wallet's own transaction-building process.

A misleading estimate can affect a proposed transaction fee. That fee goes to the miner including the transaction, not automatically to the node supplying the estimate. The change should not be described as a remote node gaining access to wallet funds or redirecting a payment to itself.

Bounds on fee rates and rounding

The merged code introduces upper bounds for four fee-priority tiers. Their maximum rates are 1,200,000, 4,700,000, 19,000,000 and 240,000,000 atomic units per byte, respectively. Monero has one trillion atomic units per XMR.

These ceilings serve as safety checks. They are far above the rates a user would normally want to pay. The source derives them from maxima for the 2021 fee model, rounded upward. If a supplied value exceeds its limit, the wallet reduces it to that limit and records a warning.

The patch also bounds fee rounding. An oversized quantization mask could inflate a rounded fee even if the underlying rate looked reasonable. The maximum becomes 10,000 atomic units, or 0.00000001 XMR, with the calculation helper enforcing a minimum of one for that parameter. This is a rounding increment, not the transaction's total fee.

Older per-kilobyte calculation paths receive bounds too, with the relevant unit conversion and priority multiplier. Other changes pass the fee-unit choice consistently through transaction construction and estimation, and refresh the cached priority-rate vector when fetching the rounding parameter. Complete patch

The checks constrain inputs to fee calculation. Transaction weight and selected priority still affect the result.

Limits of the protection

The patch does not set a fixed total XMR fee for all transactions. Transaction weight matters, and a fee below the highest ceiling could still be expensive. Readers should still review the actual amount before approving a payment.

This change also does not certify a node's honesty, prevent every form of misleading RPC response or remove privacy concerns around remote-node requests. It protects the reviewed wallet code paths. A third-party wallet's protection depends on whether and when its developers incorporate the change.

The fix belongs in the wallet software doing the calculation. Updating a remote daemon alone cannot add these checks to an older wallet. Likewise, using Tor to reach a node can hide the connection's origin from that node, but it does not verify the accuracy of its fee estimates. Transport privacy and the reliability of RPC answers are separate concerns.

What wallet users should do now

Use current official software and follow release notes for a stable version containing the fix. A merge into the development branch is not a reason to install an arbitrary test build. Our signature-verification guide explains how to check official downloads.

Prefer your own synchronized node or an operator you trust. If a displayed fee is unexpected, stop before confirming, check the selected priority and compare through another independently operated node. Do not approve an implausible fee merely because the wallet produced it.

Our remote-node connection guide covers setup and privacy trade-offs. Running your own node reduces reliance on another operator's answers, while wallet-side bounds provide another check when outside information reaches the fee calculation.