xmr.club
guides EN 中文 ES RU
← all guides

Prepare for FCMP++ — wallet, view-key + on-chain housekeeping checklist

FCMP++ is a hard fork: every node upgrades, every wallet has to ship a release that knows the new proof system. Nothing breaks for users who do nothing — your XMR forks through automatically. But a small set of things benefit from light preparation, especially if you publish a view key, run business integrations, or maintain a long list of subaddresses. Here's the checklist, in priority order.

Quick answer

If you self-custody in a major wallet (Feather, Cake, Monerujo, Monero GUI), do nothing now. Read the changelog when your wallet flags FCMP++/Carrot, update on time, you're done. If you publish a view key for donations or business view-only access, plan a one-time rotation post-fork to a Carrot-scoped key. If you operate a node, plan to bump versions before the fork height. Read the rest of this guide if you do anything beyond casual holding.

1. Wallet check — am I on a tracked client?

Every active Monero wallet is tracking the fork; the question is just how fast the release lands. As of 2026-05-18:

  • Monero GUI / CLI — canonical reference. Will ship FCMP++ + Carrot in the protocol-fork release. Use this if you want to be on the reference implementation day one.
  • Feather Wallet — desktop, Qt, Tor-friendly. Tracks the reference closely; usually ships within days of a hard fork.
  • Cake Wallet — mobile + desktop. Cross-chain wallet, so FCMP++ ships alongside their wider release schedule. Watch for the Carrot-aware build.
  • Monerujo — Android only. Long history of shipping fast for forks; the PayJoin-style features will continue working post-FCMP++ (no architectural conflict).
  • Stack Wallet — mobile, multi-coin. Similar cadence to Cake.
  • MyMonero — light wallet (server-assisted scanning). Will need server-side updates too; light wallets get the Carrot view-tag speedup early because scanning IS their job.
  • Hardware wallets (Ledger, Trezor) — typically lag mainnet forks by 2-4 weeks while their firmware ships. Don't plan a hardware-wallet spend in the immediate post-fork window.

If you're running a wallet that hasn't shipped a release in 6+ months, migrate seed to an actively-maintained client well before the fork window.

2. View-key hygiene — biggest pre-fork task

Carrot reworks how view-only wallets work. Today's view keys are a one-way disclosure that reveals all incoming transactions to your address — for the rest of time. Carrot view-keys can be scoped (e.g. only see balances post-fork height) and rotated without compromising the rest of your history.

If you have published view keys anywhere — donation pages, tax accountant access, business "view-only" partner access, watch-only mobile app — make a list now:

  • Inventory: who has your view key today, and what do they actually need to see?
  • Plan a Carrot-scoped key for each consumer once your wallet ships Carrot support. Most consumers only need ongoing balances, not full history.
  • Rotate proactively after the fork — don't wait for an incident. The pre-fork view key still leaks pre-fork history; Carrot doesn't retroactively encrypt anything.

If you only hold XMR personally and have never published a view key, ignore this section.

3. Node hygiene (if you self-host)

For self-hosted monerod operators:

  • Subscribe to the monero-project releases feed. Hard fork releases are tagged with the fork-height activation.
  • Test the release binary on stagenet or testnet before mainnet, especially if you run RPC clients (wallets, blockexplorer, payment processor).
  • Plan a brief downtime window at fork height to upgrade. Old binaries refuse to validate new-style FCMP++ proofs and will fall behind on the chain tip immediately.
  • If you publish a remote node (e.g. listed on monero.fail), give your users 1-2 weeks of "upgrading soon" notice in your status page. Some clients will need to switch nodes if yours lags.

4. Subaddress hygiene — light cleanup

FCMP++ doesn't invalidate any subaddresses. But the fork is a natural moment to do general subaddress hygiene:

  • Publicly-published subaddresses (donation pages, business "send here" links) — annual rotation is healthy regardless of FCMP++. The fork is a fine excuse.
  • Long-lived counter-party subaddresses — same. If a counter-party has been sending to the same subaddress for years, generating a fresh one limits long-tail observation.
  • Don't move funds between subaddresses "to be safe" — that just generates pre-fork churn that adds nothing post-fork. Save the network the throughput.

5. Exchange + merchant readiness

Custodial exchanges and crypto merchants will mostly handle FCMP++ silently. A few things to know:

  • Withdrawal delays are possible in the 24-48h window around fork height. Exchanges typically pause withdrawals to upgrade nodes and re-test. Plan time-sensitive moves outside that window.
  • Deposits in flight at fork height are not at risk — they're held by mempool / chain rules. Just expect confirmation delays.
  • Merchant payment processors (BTCPay Server, GloBee, Coinremitter, etc.) will need updates. If you accept XMR commercially, subscribe to your processor's release notes.
  • The kyc.rip swap aggregator will handle the fork by upgrading its engines' SDKs; users see no visible change.

6. Don't over-prepare

A few things are not worth doing pre-fork:

  • "Churning" your full balance to grow effective anonymity set. Wastes fees + chain throughput; FCMP++ makes anonymity set maximal regardless of pre-fork churn.
  • Sweeping into a new seed. Your existing seed forks through FCMP++ cleanly. New seed buys you nothing.
  • Stockpiling old wallet versions "in case the upgrade breaks". The reference implementation has run multiple hard forks without incident; rolling back is a worse position than running the upgrade.
  • Buying or selling XMR specifically because of FCMP++. It's a privacy upgrade, not a supply event.

Concise checklist

  1. Identify your wallet → confirm it has shipped at least one release in the last 6 months → subscribe to its changelog.
  2. List every place you've published a view key. Plan to rotate to Carrot-scoped view-keys after the fork.
  3. If self-hosting monerod: subscribe to the releases feed; plan a fork-height upgrade window.
  4. Annually rotate any long-lived publicly-published subaddresses (fork is a good cadence anchor).
  5. If you run merchant XMR payments: subscribe to your payment processor's release notes.
  6. Don't pre-emptively churn, sweep, or stockpile.

See also