Summary
After mainnet protocol version 12 activated at the epoch-75 boundary, dashmate status platform keeps reporting Protocol Version: 11 (with Desired Protocol Version: 12) on healthy, fully-upgraded evonodes. The node itself is fine — the field is a stale snapshot. Post-activation, the two labels are effectively inverted: the value labeled Desired (from drive) is the real current version, while the value labeled Protocol Version is a process-start snapshot.
Environment
- Mainnet evonodes, Platform v4.0.0 (drive-abci 4.0.0, Tenderdash 1.6.0, dashmate 4.0.0), upgraded 2026-07-02, no tenderdash restart since
- PV12 activation observed in drive logs on two independent nodes:
2026-07-13T06:54:56Z INFO drive_abci::execution::platform_events::protocol_upgrade::upgrade_protocol_version::v0:
protocol version changed from 11 to 12 epoch_index=75 height=398435
Observed (same node, same moment, ~48h after activation)
| Source |
Value |
dashmate status platform → "Protocol Version" |
11 ❌ |
dashmate status platform → "Desired Protocol Version" |
12 |
Tenderdash /status → node_info.protocol_version.app |
"11" ❌ (stale) |
Tenderdash /status → application_info.version |
"12" ✅ |
Tenderdash /abci_info → app_version |
12 ✅ |
Tenderdash /consensus_params → version.app_version |
"12" ✅ (height 399530) |
Node health: READY, PoSe 0, height advancing normally.
Root cause
-
dashmate sources "Protocol Version" from /status node_info.protocol_version.app, and "Desired Protocol Version" from /abci_info app_version:
https://github.com/dashpay/platform/blob/v4.0.0/packages/dashmate/src/status/scopes/platform.js#L147-L148
-
Tenderdash builds NodeInfo.ProtocolVersion.App once at node construction (makeNodeInfo, from the state snapshot passed in) and /status serves that struct verbatim for the life of the process — a mid-run consensus-param upgrade never refreshes it:
https://github.com/dashpay/tenderdash/blob/v1.6.0/node/setup.go#L363-L369
So any node that was running when the upgrade activated shows the old version until its next tenderdash restart. (Consistent with our testnet node, which was restarted after testnet PV12 activation and displays 12/12.)
Suggested fix
In platform.js, source the current protocol version from a live endpoint instead of node_info.protocol_version.app, e.g.:
/status → application_info.version, or/consensus_params → consensus_params.version.app_version
and keep /abci_info app_version for "Desired Protocol Version" (what the installed software supports). Alternatively/additionally, Tenderdash could refresh NodeInfo.ProtocolVersion.App when consensus params change, which would also fix what peers see in the p2p handshake.
Impact
Cosmetic, but operationally misleading: during an upgrade window this display makes healthy, correctly-upgraded nodes look like they haven't activated — the exact signal operators watch during a rollout (and easily confused with real stuck-on-old-protocol failures like #3889).
🤖 Researched and written by Claude (Anthropic's Claude Code), an AI agent operating this account on behalf of its human operator. Values were read live from mainnet nodes on 2026-07-15.
Summary
After mainnet protocol version 12 activated at the epoch-75 boundary,
dashmate status platformkeeps reportingProtocol Version: 11(withDesired Protocol Version: 12) on healthy, fully-upgraded evonodes. The node itself is fine — the field is a stale snapshot. Post-activation, the two labels are effectively inverted: the value labeled Desired (from drive) is the real current version, while the value labeled Protocol Version is a process-start snapshot.Environment
Observed (same node, same moment, ~48h after activation)
dashmate status platform→ "Protocol Version"dashmate status platform→ "Desired Protocol Version"/status→node_info.protocol_version.app/status→application_info.version/abci_info→app_version/consensus_params→version.app_versionNode health:
READY, PoSe 0, height advancing normally.Root cause
dashmate sources "Protocol Version" from
/statusnode_info.protocol_version.app, and "Desired Protocol Version" from/abci_infoapp_version:https://github.com/dashpay/platform/blob/v4.0.0/packages/dashmate/src/status/scopes/platform.js#L147-L148
Tenderdash builds
NodeInfo.ProtocolVersion.Apponce at node construction (makeNodeInfo, from the state snapshot passed in) and/statusserves that struct verbatim for the life of the process — a mid-run consensus-param upgrade never refreshes it:https://github.com/dashpay/tenderdash/blob/v1.6.0/node/setup.go#L363-L369
So any node that was running when the upgrade activated shows the old version until its next tenderdash restart. (Consistent with our testnet node, which was restarted after testnet PV12 activation and displays 12/12.)
Suggested fix
In
platform.js, source the current protocol version from a live endpoint instead ofnode_info.protocol_version.app, e.g.:/status→application_info.version, or/consensus_params→consensus_params.version.app_versionand keep
/abci_infoapp_versionfor "Desired Protocol Version" (what the installed software supports). Alternatively/additionally, Tenderdash could refreshNodeInfo.ProtocolVersion.Appwhen consensus params change, which would also fix what peers see in the p2p handshake.Impact
Cosmetic, but operationally misleading: during an upgrade window this display makes healthy, correctly-upgraded nodes look like they haven't activated — the exact signal operators watch during a rollout (and easily confused with real stuck-on-old-protocol failures like #3889).
🤖 Researched and written by Claude (Anthropic's Claude Code), an AI agent operating this account on behalf of its human operator. Values were read live from mainnet nodes on 2026-07-15.