# Coordinating the pre-Phase 4 Hard Fork Upgrade to namada v101 **URL:** \ **Category:** Network Operations\ **Created:** [19 May 2025 08:06 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670 "2025-05-19T08:06:23Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [19 May 2025 08:06 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/1 "2025-05-19T08:06:23Z")
Edit: if you are looking for the v201.0.7 upgrade happening Dec 2, 2025, that is [here](https://forum.namada.net/t/signalling-upgrade-to-v201-0-7-at-block-4514500/1899). * * * Formally starting a forum thread to coordinate upgrading the mainnet with a hard fork before the enactment of Phase 4. This thread will not be used for discussing the Phase 4 proposal itself, which will occur in a different forum post. The hard fork is needed to upgrade Namada to [v101.0.0](https://github.com/anoma/namada/releases/tag/v101.0.0) in addition to upgrading various off-chain infra like the indexers. Discussion has already informally started on discord [here](https://discord.com/channels/833618405537218590/1272977701224845465/1372674795891720204). A full list of upgrade instructions for operators is currently contained in [this hackMD](https://hackmd.io/@brentstone/H1It9Xykle) document. Clarifications and requests for amendment are welcome. At some point in the coming days, perhaps the instructions will be placed in this thread as well. This same hard fork has already been performed and tested on Campfire and Housefire testnets with success. From discord, there seems to be good support for targeting **Tuesday, May 27 @ 15:00 UTC** as the upgrade time. This about coincides with block height **[2,176,000](https://namada.valopers.com/blocks/2176000)**. Please discuss and vote on the incoming governance proposal to signal social consensus for stopping the chain and upgrading at height **2,176,000**! Onwards to Phase 4 and 5!! ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [19 May 2025 08:22 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/2 "2025-05-19T08:22:20Z")
Proposal #21 is now on-chain for this topic! ```auto $ namadac query-proposal --proposal-id 21 --node $RPC_MAINNET Last committed epoch: 666 Proposal Id: 21 Type: Default Author: tnam1qqgll8x8rz9fvtdv8q6n985za0vjvgyu0udxh7fp Content: {"details": "Gathering social consensus to coordinate a software upgrade of namada nodes at block 2,176,000. This block is expected to occur at about 15:00 UTC on Tuesday, May 27, 2025.", "discussions-to": "https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670", "title": "Signalling: coordinating mainnet software upgrade to namada v101.0.0 at height 2,176,000"} Start Epoch: 667 End Epoch: 680 Activation Epoch: 681 Status: pending ``` ---
**Author:** ![tonymarma](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/tonymarma/32/460_2.png) [@tonymarma](https://forum.namada.net/u/tonymarma)\ **Post date:** [19 May 2025 08:37 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/3 "2025-05-19T08:37:46Z")
We support the proposal 🚀 ---
**Author:** ![Spir](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/spir/32/561_2.png) [@Spir](https://forum.namada.net/u/Spir)\ **Post date:** [19 May 2025 08:51 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/4 "2025-05-19T08:51:08Z")
We support this proposal and are technically prepared. ---
**Author:** ![Owl\_Genesis](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/owl_genesis/32/683_2.png) [@Owl\_Genesis](https://forum.namada.net/u/Owl_Genesis)\ **Post date:** [19 May 2025 11:04 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/5 "2025-05-19T11:04:48Z")
I support this proposal 👍 ---
**Author:** ![BlockPro](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/blockpro/32/603_2.png) [@BlockPro](https://forum.namada.net/u/BlockPro)\ **Post date:** [19 May 2025 14:19 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/6 "2025-05-19T14:19:34Z")
BlockPro supports this proposal as it ensures Namada’s mainnet remains robust and ready for future phases, particularly Phase 4. ---
**Author:** ![Gavin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/gavin/32/16_2.png) [@Gavin](https://forum.namada.net/u/Gavin)\ **Post date:** [19 May 2025 14:44 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/7 "2025-05-19T14:44:13Z")
There can be variation in block time average from now until the designated block height. Reminder to operators that the **block height** (ie. 2,176,000) and _not the UTC target time_ is what’s being proposed for the upgrade time. Just a heads up to operators (most probably already know this). Block production times often vary, and the total variance tends to be greater the earlier the target is selected. My calc is that actual time will be **2h 47min different for every 0.1 second variance in blocktime average** from now (14:41 UTC Mon May 19) until Block Height 2,176,000. Maths 0.1s extra per block × 100,163 blocks = 10,016.3 seconds From seconds to hours and minutes: 10,016.3 ÷ 3600 ≈ 2.78 hours ≈ 2 hours, 47 minutes ---
**Author:** ![sirouk](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/sirouk/32/235_2.png) [@sirouk](https://forum.namada.net/u/sirouk)\ **Post date:** [19 May 2025 21:39 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/8 "2025-05-19T21:39:09Z")
@Gavin thanks for the heads up 👍 I’m not sure if anyone else noticed, but there are two links circulating to the same HackMD document: > **[\[Draft\] Hard-fork instructions for operators (pre-Phase 4) - HackMD](https://hackmd.io/Pv_8yyX_R-2RHnVHzGgMOA)** > **[\[Draft\] Hard-fork instructions for operators (pre-Phase 4) - HackMD](https://hackmd.io/@brentstone/H1It9Xykle)** > > Namada is upgrading to v101.0.0 in advance of activating Phase 4. Here are the steps: The second link is what you get when attempting to share the document. So really, NBD. ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [26 May 2025 06:03 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/9 "2025-05-26T06:03:01Z")
Going to repost the full instructions in its own post on this forum thread, taken right from the HackMD that was originally used to hold the instructions. Just figure it would be good to have in a forum post in addition to the HackMD for the future as well. HackMD: [Hard-fork instructions for operators (pre-Phase 4) - HackMD](https://hackmd.io/Pv_8yyX_R-2RHnVHzGgMOA) ---
**Author:** ![brentstone](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.namada.net/brentstone/32/464_2.png) [@brentstone](https://forum.namada.net/u/brentstone)\ **Post date:** [26 May 2025 06:08 UTC](https://forum.namada.net/t/coordinating-the-pre-phase-4-hard-fork-upgrade-to-namada-v101/1670/10 "2025-05-26T06:08:45Z")
# Hard-fork instructions for operators (pre-Phase 4) Namada is upgrading to [v101.0.0](https://github.com/anoma/namada/releases/tag/v101.0.0) in advance of activating Phase 4. Here are the steps: ### Mainnet params - `H` = 2176000 (~ May 27 15:00 UTC according to [here](https://namada.valopers.com/blocks/2176000)) - `M` = 2176020 - `E` = 175 ## Prerequisites Below are the things you need to know or have ahead of time before beginning the migration. Migration parameters will be chosen with community confirmation ahead of time. Migration files will be provided in a central location. - Parameters - Hard fork height `H` - Migration height `M` - Target MASP epoch `E` - Migration files - [pre\_phase4\_migration.json](https://github.com/anoma/namada/releases/download/v101.0.0/pre_phase4_migration.json) – from the `v101.0.0` release page - original raw file is [here](https://github.com/anoma/namada/raw/refs/heads/brent/mainnet-upgrade-pre-phase4/pre_phase4_migration.json) - Migration file hash `$MIGRATION_HASH` from `sha256sum pre_phase4_migration.json` - Mainnet: `83d7b4fc38f135adfae2f6219bf13c1bbf9022609fb61124be1ff0c5f79e1d7e` Additionally, if you are operating other services like indexers, then you will need to upgrade those too with new software as part of this process. See the **Node operator instructions** below in particular for this. ## Instructions - If you are running a validator or full node only, go to the **Validator-only instructions** - The instructions contain the minimal set of steps needed to upgrade your validator or full node - If you are a node operator that offers public services such as indexers, masp-indexers, and/or public RPCs, go to the **Node operator instructions** ### Validator-only instructions 1. Make sure you build or download the `v101.0.0` binaries and `pre_phase4_migration.json` ahead of time. 2. Configure your node to stop at the hard fork height `H` with ```auto namadan ledger run-until --block-height H --halt ``` Your node will avoid committing block `H` when it is reached and instead shut down. This must be done with the current `v1.1.x` 3. Replace all binaries with new versions `v101.0.0` for upgrading. 4. Restart your node with the new `namadan v101.0.0` and perform the scheduled migration: ```auto namadan ledger run --path pre_phase4_migration.json \\ --hash $MIGRATION_HASH --height M ``` You can keep your node running with this command for the rest of the procedure. The node will not stop at height `M` and will continue processing blocks. At some height in the future later than `M`, you can stop and restart your node with the simple `namadan ledger run` if desired. ### Node operator instructions 1. Make sure you build or download the new post-upgrade software ahead of time for all services you are running (node, namada-indexer, MASP indexer) described above. Do not start running the new software until the future steps. The indexer versions are: 2. Configure your node to stop at the hard fork height `H` with 3. `[Opt MASP Idx]` Allow your MASP indexer to run until height `H-1`. Once it reaches this height, stop all microservices except for the `webserver` and `postgres`. 4. `[Opt MASP Idx + RPC provider]` Run the [Namada MASP events migration software](https://github.com/heliaxdev/migrate-masp-events) over the CometBFT home directory `cometbft` within the Namada base directory. Further instructions are provided in the `README` of the linked migration software. 5. Run the namada-indexer until height `H-1` and kill the service once this is reached. 6. Kill your node and replace all binaries with new versions for upgrading. 7. Restart your node with the new `namadan v101.0.0` to perform the scheduled migration: 8. Stop the MASP indexer’s `webserver` service that had been running `v1.2.X` 9. Upgrade to the new MASP indexer software version and run all associated services. 10. Upgrade to the new namada-indexer software and run all associated services. 11. No more steps to perform for the upgrade. The conversion tree should reset at the very end of the MASP epoch `E`, at which point the upgrade will be completed. After this point, an operator would be free (but not required) to stop and restart their node with a simple `namadan ledger run`.