Summary
This proposal schedules a coordinated software upgrade of Terra Classic (columbus-5) to v4.0.1-patch.3 at block height 30544730, estimated for Thursday, 24 September 2026, 15:00 UTC (17:00 CEST / 11:00 EDT).
The estimate uses the 30-day average block time of 5.917 s, measured on 14 September 2026. The actual halt can differ from it by up to about an hour. Operators should track the current height instead of relying on the estimated time.
What this upgrade fixes
wasmd and wasmvm are critical components of the Terra Classic smart contract platform. Both are affected by a critical security vulnerability, which is being handled through responsible disclosure. Cosmos Labs will publish the details of the fix on Monday, 28 September 2026, 14:00 UTC (10:00 ET). Chains need to upgrade before that date so they don’t become targets once the attack vector is public.
Until then, the source code of the fix is shared only in private channels. The Terra Classic core maintainers have applied the fix to terrad and published the patch release v4.0.1-patch.3.
The upgrade makes no state changes. There is no migration, no new store and no parameter change.
Why this upgrade is done through governance
The fix changes consensus behaviour, so every validator and node operator has to switch to the new binary at the same block height. Terra Classic has more than 80 active validators, so a halt arranged off-chain with --halt-height would not be reliable. An on-chain upgrade plan makes every node stop at the same height, four days before the vulnerability is disclosed publicly.
Release
Release notes and binaries: https://github.com/classic-terra/core/releases/tag/v4.0.1-patch.3
| File | sha256 |
|---|---|
| terra_4.0.1-patch.3_Linux_x86_64.tar.gz | 4b1428ace2f9c328a813ea0739104c3f506095d3849acdfc5e673fe2d22fd7b3 |
| terra_4.0.1-patch.3_Linux_arm64.tar.gz | 94cc1189902c4bc0c5b570c0c2cfedc90041ffeed510aa9e126e13953f0d93bf |
| checksums.txt |
Only download the release from the link above, and always check the checksum.
Who needs to upgrade
Everyone running a columbus-5 node: validators, RPC/LCD providers, exchanges, IBC relayers, explorers, bridges and wallets. Nodes that are not upgraded stop at 30544730 and cannot continue.
Validators hosted by a Validator-as-a-Service (VaaS) or white-label provider don’t need to do anything themselves. Your provider installs the upgrade on your node. If you’re unsure whether your provider has done this, check with them before the upgrade height.
How to upgrade
The full instructions are in the release notes. In short:
-
Download and verify. Use
arm64instead ofx86_64on ARM machines.BASE=https://github.com/classic-terra/core/releases/download/v4.0.1-patch.3 curl -fLO $BASE/terra_4.0.1-patch.3_Linux_x86_64.tar.gz curl -fLO $BASE/checksums.txt sha256sum -c --ignore-missing checksums.txt # must print: OK tar xzf terra_4.0.1-patch.3_Linux_x86_64.tar.gz ./terrad version # must print: 4.0.1-patch.3 -
Wait for the halt. At
30544730the node stops withUPGRADE "v14_3" NEEDED at height: 30544730. Don’t replace the binary earlier: a node that runs the new binary below the upgrade height stops withBINARY UPDATED BEFORE TRIGGER!. -
Replace and restart. Stop the node, replace
terradwith the new binary and start it again.
Do not use --unsafe-skip-upgrades. That keeps a node on the vulnerable software and splits it off from the upgraded network.
What to expect at the upgrade height
- At
30544730: every node on the network halts. - Restart: block production resumes once validators holding more than 2/3 of voting power run
v4.0.1-patch.3. No state rollback or export is needed. - Validators who have not upgraded: they miss blocks until they switch, and may be slashed for downtime under the usual rules.
Voting options
| Option | Meaning |
|---|---|
| YES | Schedule the v14_3 upgrade at height 30544730. |
| NO | Do not schedule the upgrade. |
| NO WITH VETO | Reject the proposal and burn the deposit. |
| ABSTAIN | Count towards quorum without taking a side. |
Thanks frag. Consider adding the actual binary hash.