Короткий ответ
Если самохранение в основном кошельке (Feather, Cake, Monerujo, Monero GUI) — сейчас ничего не делать. Прочитайте changelog, когда кошелёк отметит FCMP++/Carrot, обновитесь вовремя — готово. Если вы публиковали view key для донатов или view-only доступа бизнеса, спланируйте разовую ротацию после форка на ограниченный Carrot-key. Если держите ноду — спланируйте бамп версий до высоты форка. Дальше читать тем, кто делает что-то сверх обычного хранения.
1. Проверка кошелька — у меня отслеживаемый клиент?
Все активные Monero-кошельки следят за форком; вопрос лишь в скорости релиза. По состоянию на 2026-05-18:
- Monero GUI / CLI — каноническая референсная реализация. FCMP++ + Carrot пойдут в релизе с протокольным форком. Берите, если хотите быть на референсе в первый день.
- Feather Wallet — десктоп, Qt, Tor-friendly. Идёт близко к референсу; обычно релиз в течение дней после форка.
- Cake Wallet — мобильный + десктоп. Кросс-чейн, поэтому FCMP++ выходит вместе с их более широким релиз-планом. Ждите Carrot-aware сборку.
- Monerujo — только Android. История быстрого выпуска под форки; PayJoin-стайл фичи продолжат работать после FCMP++ (нет архитектурного конфликта).
- Stack Wallet — мобильный, multi-coin. Каденция близкая к Cake.
- MyMonero — лайтовый кошелёк (сервер-вспомогаемое сканирование). Потребуется обновление серверной части тоже; лайт-кошельки получают ускорение view-tag Carrot рано, потому что сканирование — их основная работа.
- Аппаратные (Ledger, Trezor) — обычно отстают от mainnet-форков на 2–4 недели, пока выходит прошивка. Не планируйте расход с hardware-кошелька в окне сразу после форка.
Если кошелёк не выпускал релиз 6+ месяцев — мигрируйте seed на активно поддерживаемый клиент заранее, до окна форка.
2. Гигиена view-key — самая важная пред-форк задача
Carrot переделывает работу view-only кошельков. Сегодняшние view keys — это одностороннее раскрытие, показывающее все входящие транзакции к вашему адресу — навсегда. Carrot view-keys можно ограничивать (например, видеть только балансы после форк-высоты) и ротировать, не компрометируя остальную историю.
Если вы где-то публиковали view keys — донат-страницы, доступ для бухгалтера, view-only для бизнес-партнёра, watch-only мобильное приложение — составьте список сейчас:
- Инвентаризация: у кого сегодня ваш view key, и что им реально нужно видеть?
- Спланируйте Carrot-scoped ключ для каждого получателя, когда кошелёк выпустит поддержку Carrot. Большинству нужно видеть только текущие балансы, не полную историю.
- Ротируйте проактивно после форка — не ждите инцидента. Пред-форк view key всё ещё показывает пред-форк историю; Carrot не шифрует ничего задним числом.
Если вы держите XMR только лично и никогда не публиковали view key — пропустите эту секцию.
3. Гигиена ноды (если хостите сами)
Для операторов self-hosted monerod:
- Подпишитесь на релизы monero-project. Hard-fork релизы помечены высотой активации.
- Протестируйте релиз на stagenet или testnet до mainnet, особенно если у вас RPC-клиенты (кошельки, blockexplorer, payment processor).
- Запланируйте короткое окно простоя на высоте форка для апгрейда. Старые бинарники не валидируют новые FCMP++ proofs и сразу отстанут от верхушки.
- Если публикуете remote node (например, в monero.fail) — дайте пользователям 1–2 недели предупреждения «скоро апгрейд» на странице статуса. Некоторым клиентам придётся менять ноду, если ваша отстанет.
4. Гигиена субадресов — лёгкая уборка
FCMP++ не инвалидирует ни один субадрес. Но форк — естественный момент общей гигиены:
- Публично опубликованные субадреса (донат-страницы, «шлите сюда» бизнеса) — ежегодная ротация полезна вне зависимости от FCMP++. Форк — нормальный анкер.
- Долгоживущие субадреса с контрагентами — то же. Если контрагент годами шлёт на один и тот же субадрес, новый ограничит long-tail наблюдение.
- Не перекладывайте средства между субадресами «на всякий» — это просто пре-форк churn, который ничего не даёт после форка. Не нагружайте сеть впустую.
5. Готовность бирж и мерчантов
Кастодиальные биржи и крипто-мерчанты в основном переживут FCMP++ молча. Что знать:
- Задержки выводов возможны в окне 24–48 часов вокруг высоты форка. Биржи обычно ставят выводы на паузу для апгрейда узлов. Запланируйте чувствительные ко времени операции вне этого окна.
- Депозиты в полёте на высоте форка не под угрозой — их держат правила mempool/цепочки. Просто ждите задержки подтверждений.
- Payment processors (BTCPay Server, GloBee, Coinremitter и т.п.) тоже потребуют обновлений. Если принимаете XMR коммерчески — подпишитесь на release notes вашего процессора.
- Swap-агрегатор kyc.rip переживёт форк, обновив SDK движков; пользователи видимого изменения не заметят.
6. Не пере-готовьтесь
Чего не стоит делать до форка:
- «Churn-ить» весь баланс, чтобы нарастить эффективный anonymity set. Тратит комиссии и пропускную способность; FCMP++ делает set максимальным независимо от пред-форк churn.
- Переводить на новый seed. Текущий seed форкнётся чисто. Новый ничего не покупает.
- Запасать старые версии кошельков «на случай, если апгрейд сломает». Референсная реализация прошла несколько хард-форков без инцидентов; откат хуже апгрейда.
- Покупать/продавать XMR конкретно из-за FCMP++. Это апгрейд приватности, не событие предложения.
Короткий чек-лист
- Опознайте кошелёк → подтвердите, что был хотя бы один релиз за 6 месяцев → подпишитесь на changelog.
- Перечислите, где публиковали view key. Спланируйте ротацию на Carrot-scoped после форка.
- Если хостите monerod: подпишитесь на релизы; запланируйте окно апгрейда на высоте форка.
- Ежегодно ротируйте долгоживущие опубликованные субадреса (форк — нормальный якорь).
- Если принимаете коммерческие XMR-платежи: подпишитесь на release notes процессора.
- Не делайте превентивный churn, sweep или запас.
См. также
- FCMP++ объяснение — что апгрейд реально делает.
- FCMP++ vs другие privacy-tech — сравнение с Zcash, Bitcoin CoinJoin, Mimblewimble, Lelantus-Spark.
- Выбор Monero-кошелька — текущие рекомендации.
- Свой Monero-узел — руководство для операторов.