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

> Practical pre-fork checklist for the FCMP++ + Carrot Monero hard fork. Which wallets to track, what to do with published view keys, subaddress hygiene, migration timing. No urgency yet — but a few things to line up.

Canonical URL: https://xmr.club/guides/prepare-for-fcmp-plus-plus
Locales: https://xmr.club/llm/guides/prepare-for-fcmp-plus-plus.txt · https://xmr.club/zh/llm/guides/prepare-for-fcmp-plus-plus.txt · https://xmr.club/es/llm/guides/prepare-for-fcmp-plus-plus.txt · https://xmr.club/ru/llm/guides/prepare-for-fcmp-plus-plus.txt

## Overview

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.

## Body

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 Identify your wallet → confirm it has shipped at least one release in the last 6 months → subscribe to its changelog. List every place you've published a view key. Plan to rotate to Carrot-scoped view-keys after the fork. If self-hosting monerod: subscribe to the releases feed; plan a fork-height upgrade window. Annually rotate any long-lived publicly-published subaddresses (fork is a good cadence anchor). If you run merchant XMR payments: subscribe to your payment processor's release notes. Don't pre-emptively churn, sweep, or stockpile. See also FCMP++ explained — the explainer covering what the upgrade actually does. FCMP++ vs other privacy tech — side-by-side with Zcash, Bitcoin CoinJoin, Mimblewimble, Lelantus-Spark. Pick a Monero wallet — current recommendations. Run your own Monero node — node operator guide.

## License

CC-BY-4.0. Attribute "xmr.club".