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 in addition to upgrading various off-chain infra like the indexers. Discussion has already informally started on discord here.
A full list of upgrade instructions for operators is currently contained in this hackMD 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.
Please discuss and vote on the incoming governance proposal to signal social consensus for stopping the chain and upgrading at height 2,176,000!
$ 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
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
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.
Hard-fork instructions for operators (pre-Phase 4)
Namada is upgrading to 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)
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.
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
Make sure you build or download the v101.0.0 binaries and pre_phase4_migration.json ahead of time.
Configure your node to stop at the hard fork height H with
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
Replace all binaries with new versions v101.0.0 for upgrading.
Restart your node with the new namadan v101.0.0 and perform the scheduled migration:
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
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:
Configure your node to stop at the hard fork height H with
namadan ledger run-until --block-height H --suspend
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.
[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.
[Opt MASP Idx + RPC provider] Run the Namada MASP events migration software over the CometBFT home directory cometbft within the Namada base directory. Further instructions are provided in the README of the linked migration software.
Run the namada-indexer until height H-1 and kill the service once this is reached.
Kill your node and replace all binaries with new versions for upgrading.
Restart your node with the new namadan v101.0.0 to perform the scheduled migration:
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.
Stop the MASP indexer’s webserver service that had been running v1.2.X
Upgrade to the new MASP indexer software version and run all associated services.
Upgrade to the new namada-indexer software and run all associated services.
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.
