A user opens XMRWallet, composes a Monero transaction, and expects to see the estimated fee before confirming the send. The interface displays the amount, the recipient address, and the transaction priority setting, but no definitive fee estimate appears. This omission is not a design oversight or missing feature. It reflects a fundamental property of how Monero calculates fees at the moment of broadcast, which makes advance prediction unreliable and potentially misleading. Understanding why this happens requires examining the gap between user expectations shaped by Bitcoin and Ethereum interfaces, and the actual mechanics of Monero’s dynamic fee market.

The practical consequence is that users must make send decisions with incomplete cost information. Some wallets paper over this problem with guesses. XMRWallet takes a different approach: it prioritizes accuracy over comfort and places the responsibility for fee strategy on the user. That responsibility can feel foreign to anyone accustomed to wallets that show a dollar amount before clicking send, but it also removes a source of false confidence. The real question is not whether a fee estimate would be nice to have. It is whether a rough estimate would meaningfully help or just disguise uncertainty under a veneer of precision.

How Monero fees work at broadcast time, not preparation time

Bitcoin and most Ethereum-like networks calculate transaction size in advance because the spending pattern is known: a transaction with three inputs and two outputs will occupy a predictable number of bytes. Miners or validators then apply a fee rate (satoshis per byte, gwei per gas) to determine the total cost. The rate may fluctuate, but the calculation is deterministic once the transaction is constructed.

Monero’s approach is structurally different. A Monero transaction includes ring signatures and RingCT (Ring Confidential Transactions) constructs that hide the true input being spent and conceal amounts. The size of a ring signature depends on which outputs the wallet selects as decoys and which ring size is chosen. A transaction with a ring size of 16 (meaning 16 possible true inputs) creates different byte overhead than ring size 8. The wallet cannot reliably predict which decoy outputs will be available or what the final transaction size will be until the moment of broadcast, when the random selection and ring composition are finalized.

The fee calculation itself happens after the transaction structure is decided. Monero’s dynamic block size works differently from Bitcoin’s blocks or Ethereum’s gas limits. If the network is congested, median block size increases, which automatically raises the base fee to incentivize prioritization. The base fee can change between the moment the wallet estimates it and the moment the transaction is broadcast, especially during volatile periods. A wallet estimating a fee five minutes before sending cannot know whether median block size will have changed by the time the transaction arrives in the mempool.

This is not a limitation unique to XMRWallet. It is inherent to Monero’s protocol. Other Monero wallets have responded by showing a priority level (low, normal, elevated, urgent) rather than a specific fee amount. XMRWallet uses the same approach: the user selects a priority, and the wallet applies a multiplier to the current base fee when constructing the transaction. The fee is calculated only at broadcast time, when the transaction structure is final and the current network state is known.

Why priority levels are a signal, not a guarantee

XMRWallet’s priority options represent a strategy for fee adjustment, not a prediction. Setting the priority to “elevated” tells the wallet to multiply the calculated base fee by a certain factor, typically around 2.5×. This increases the chance that the transaction will be confirmed promptly, but it does not guarantee a specific confirmation time because block generation in Monero is probabilistic, and actual block times vary around the 2-minute average.

The relationship between fee and confirmation time is also weaker in Monero than in some other networks. With a ring size of 16, the transaction is larger than with ring size 8, so it occupies more block space for a given fee rate. Two transactions with identical priority settings may be confirmed in different times because one is larger. The wallet display does not usually show ring size selection as an explicit user choice; it may be automatic or preset, adding another hidden variable that affects the fee-to-confirmation relationship.

Miners (or mining pools) on the Monero network can also apply their own selection logic. A miner might prioritize by absolute fee, by fee rate, or by a combination including transaction size or other factors. There is no published specification that all miners follow, so the same priority setting across different wallets may result in different actual outcomes. A user sending with “normal” priority from XMRWallet cannot assume that a peer sending the same priority from a different implementation will experience identical confirmation times.

The practical implication is that priority levels are hints rather than contracts. Selecting “elevated” increases the likelihood of faster confirmation compared to “low,” but that likelihood is probabilistic and context-dependent. A wallet that displayed an exact fee estimate would create a false impression of precision. By showing only the priority choice, XMRWallet implicitly acknowledges that the user is choosing a strategy, not purchasing a specific service level.

Wallet synchronization timing and fee visibility trade-offs

Before a user can compose a transaction, XMRWallet must perform blockchain synchronization. This happens automatically after login when the wallet connects to a Monero node (either remote or local) and scans the blockchain for incoming transactions, outputs that belong to the wallet, and the current unspent output set. Until synchronization is complete, the wallet cannot accurately calculate the user’s balance or available outputs to spend.

The synchronization process also determines which outputs are available for decoy selection in ring signatures. If the wallet has not scanned recent blocks, it may not know about newly mined outputs, which means ring composition could include stale decoys. More importantly, synchronization establishes the current blockchain state, including the median block size and current base fee. A wallet that showed a fee estimate before synchronization was complete would be using outdated network state information.

This creates a timing trade-off. XMRWallet could show a provisional fee estimate immediately after the user enters an amount and selects a priority, but that estimate would be based on the last known base fee, which could be minutes old if synchronization is slow or the device was recently turned on. A better approach is to defer showing any specific fee number until the synchronization is fresh and the transaction is being constructed. This reduces the window in which an estimate could mislead the user.

For users sending monero through the wallet dashboard, the absence of a fee display before final confirmation becomes less mysterious once synchronization is understood as an ongoing process. The wallet cannot show you what it does not yet know. By the time the transaction is actually sent, synchronization has completed, and the fee is calculated on current data. The user must trust that the priority level is appropriate and that the wallet is applying it correctly, but at least the calculation is based on actual network state, not a stale guess.

The decoy selection problem and its impact on final cost

Every Monero transaction’s size is affected by ring composition, and ring composition depends on which outputs are available to serve as decoys at the moment of broadcast. In principle, a wallet could predict ring composition in advance by examining the outputs it plans to use and selecting decoys from the current UTXO set. In practice, new outputs are mined continuously, and the optimal set of decoys may change between the time a user initiates a send and the time the transaction is broadcast.

A wallet that showed a fee estimate before ring composition was finalized would be making an assumption about transaction size. If the actual ring composition turns out to involve more or larger decoys, or if the output set changes substantially, the final size could differ. The fee rate is static (determined by priority), but the total fee is the rate multiplied by size. A 5 percent error in size prediction becomes a 5 percent error in fee prediction.

XMRWallet avoids this problem by not predicting at all. The fee is calculated only after the transaction is fully constructed, including ring composition. This means the fee shown at confirmation time (if the user reviews the transaction data) reflects the actual structure. The user cannot see the fee until the last moment, but when they do see it, they know it is accurate.

Some users find this frustrating because it prevents careful budgeting. If sending 1 XMR with a specific priority normally costs 0.002 XMR in fees, but the user cannot confirm that until after they have already committed to the send, they cannot easily calculate the total debit in advance. The alternative is to over-estimate fees (selecting a higher priority than necessary) or to structure transactions conservatively (avoiding scenarios where precision matters). Both approaches work, but they add cost or friction compared to an interface that shows fees before confirmation.

Strategies users employ to manage fee uncertainty

In practice, experienced Monero users develop heuristics to work within the absence of pre-send fee estimates. The first is to use priority levels consistently and observe the results. After sending several transactions with “normal” priority over days or weeks, a user builds intuition about confirmation time. They can estimate the typical range of fees and adjust priority accordingly. This is a slower feedback loop than a displayed estimate, but it produces knowledge grounded in actual outcomes rather than wallet predictions.

The second strategy is to use a separate fee calculator or reference, such as monitoring the current base fee rate through a block explorer. Some users check the median block size and base fee on a Monero block explorer before composing a transaction, then deliberately choose a priority level they expect to be sufficient. This converts fee management into a two-step process: gather information, then execute. It is less seamless than an integrated fee estimate, but it decouples wallet design from network state visibility.

A third approach is to intentionally select a higher priority when certainty matters. If the user needs the transaction confirmed within a specific timeframe, or if precision is important, selecting “elevated” or “urgent” provides a safety margin. The extra fee is the cost of removing uncertainty. This is analogous to buying a stamp or paying for overnight shipping instead of calculating the exact postage required. The user sacrifices some efficiency to avoid the risk of false estimation.

For users concerned about fee costs, a fourth strategy is to batch transactions or wait for periods when the network is less congested. Monero’s dynamic block size naturally congests during periods of high transaction volume. Sending during quieter times typically results in lower base fees and faster confirmation even at normal priority. This shifts the burden of fee optimization from the wallet interface to the user’s sending behavior, but it is feasible for transactions that do not require immediate confirmation.

XMRWallet’s focus on privacy and non-custodial control, as detailed on sites.google.com/xmrwallet.cfd/xmrwallet-official/, means that advanced fee management would require exposing more information about the transaction structure, which could undermine the privacy that the wallet prioritizes. Showing ring size, decoy selection details, or real-time network metrics could help users understand fees, but it would also create an interface cluttered with technical details most users do not need.

The security and privacy cost of fee visibility

One reason that some Monero wallets do not show detailed fee information is that the information itself can leak transaction context. A wallet displaying the exact ring size used, the current base fee, and the size of the transaction being composed creates additional data points that could potentially be correlated with timing or other metadata. If an observer (such as a wallet developer, network monitor, or compromised device) can see that a specific fee calculation happened at a specific time, combined with when a corresponding transaction appeared on the blockchain, the correlation could become easier.

This threat is not imminent for most users, but it exists in the design space. A wallet that hides fee details behind priority levels is also hiding information that could be observed. XMRWallet’s approach of deferring fee calculation until broadcast time, and then not prominently displaying the calculated fee, is consistent with a broader philosophy of minimizing disclosable transaction metadata during the composition phase.

A related consideration is that send receive monero operations should preserve the wallet’s privacy guarantees end-to-end. If the wallet calculates a fee and displays it before the transaction is sent, that information exists in the wallet’s local memory and potentially in logs or crash reports. By deferring the fee calculation and avoiding explicit storage or display of the amount, XMRWallet reduces the surface area of sensitive transaction data in the device’s system memory.

This is a trade-off between user convenience and attack surface. A wallet that shows everything is easier to understand but creates more observable state. A wallet that shows less is less transparent but potentially smaller in attack surface. Users choosing XMRWallet are implicitly accepting this trade-off, accepting that they will manage fee strategy through priority levels and observation rather than explicit estimates.

What happens when the user reviews the transaction at confirmation

XMRWallet does allow users to review transaction details before final confirmation. The interface shows the recipient address, the amount being sent, and the priority level. Some versions or advanced settings may display additional details such as transaction size or the calculated fee in absolute terms. At this stage, the fee has been calculated and is known, because the transaction structure is finalized.

The practical sequence is: the user enters the recipient and amount, selects priority, initiates the send, the wallet performs final synchronization and constructs the transaction (including decoy selection and fee calculation), and then the user reviews the details and confirms. The fee is not hidden; it is simply not available until the moment of final review. This design keeps the send flow relatively simple (the user sees the main details at each step) while ensuring that the fee shown is accurate.

Some users appreciate this clarity at confirmation time because it forces deliberation. The user cannot mindlessly approve a send without seeing the cost. Others find it awkward because any surprise at that late stage is hard to correct. If the calculated fee is higher than expected, the user must either accept it or cancel and restart, which requires new synchronization and a new transaction construction. There is no middle ground where the user sees an estimate, adjusts settings, and re-estimates without executing.

This limitation is specific to how Monero works, not to XMRWallet specifically. Any Monero wallet that wanted to show a fee before transaction construction was complete would have to guess, and the guess would be educated but imperfect. XMRWallet’s choice to avoid the guess altogether is defensible design, but it does place the responsibility on the user to understand that sending involves a two-stage process: priority selection, then confirmation with actual fee visibility.

How network congestion actually affects outcomes

When Monero’s network becomes congested, the median block size increases, which raises the base fee. A transaction sent with “normal” priority during high congestion will have a higher absolute fee than the same transaction with the same priority during a quiet period. The priority level is relative, not absolute. The wallet dashboard does not usually display current network congestion metrics, so the user cannot easily predict how much congestion will affect the fee.

This asymmetry between priority level and actual outcome is another reason that XMRWallet avoids showing estimates. An estimate based on current conditions could be stale if congestion changes before broadcast. An estimate based on a 1-hour or 24-hour average is even less reliable because it conceals volatility. The honest answer to “what will this cost?” is often “it depends on network conditions when the transaction is broadcast,” which is not a satisfying answer for a fee estimate field.

Users who care about controlling costs during congestion periods have a few options. They can use block explorers to monitor base fee and send during periods when it is lower. They can select a higher priority as a hedge against sudden congestion. They can batch transactions to reduce the total number sent and therefore the total fee burden. Or they can accept that some variability in fees is the price of using a decentralized network where conditions are not under their control.

For anyone planning larger transactions or movement of significant value, understanding this volatility is important. XMRWallet’s lack of a fee pre-estimate is not a bug that makes it unsuitable for serious use. Rather, it is an honest design that forces users to confront the reality that Monero fees are not fixed in advance and cannot be reliably predicted by the wallet. Acknowledging that reality is the first step to managing it responsibly.