V1.1.0 software upgrade proposal


This is a summary and culmination of the discussions around the release v1.1.0. The release can be found at Release v1.1.0 · classic-terra/core · GitHub

This release contains governance approved features to the Terra Classic blockchain, including tax exemption list, burn tax split, no-reminting of the burn wallet, as well as mandatory security updates. This is the first major release that will utilize the upgrade governance proposal mechanism to upgrade the chain. This proposal will HALT the chain at block, 11,734,000, or approximately February 28th, 10PM UTC. If this proposal passes, at this time, all full nodes and validators will NOT be able to continue until they install and run the current upgrade version v1.1.0.

What is included


(build) #101 Upgrade test fix: add github action for upgrade testing by nghuyenthevinh2000 · Pull Request #101 · classic-terra/core · GitHub

(ante) #103 Add burn tax split logic v1.x backport: add burn tax split logic by nghuyenthevinh2000 · Pull Request #103 · classic-terra/core · GitHub

(ante) #107 Burn Tax Whitelist feat: add burn tax exemption list by nghuyenthevinh2000 · Pull Request #107 · classic-terra/core · GitHub

(ante) #137 Update burn tax exemption feat: tax exemption update by inon-man · Pull Request #137 · classic-terra/core · GitHub

(build) #118 localnet for Apple Silicon build: localnet for Apple Silicon by inon-man · Pull Request #118 · classic-terra/core · GitHub

(app) #128 Panic at InitChainer for the Columbus mainnet

Improvements feat: panic at columbus genesis by inon-man · Pull Request #128 · classic-terra/core · GitHub

(build) #93 Use golang 1.18 and fix ad-hoc security vulnerabilities Upgrade to golang 1.18 and fix ad-hoc security vulnerabilities by ZaradarBH · Pull Request #93 · classic-terra/core · GitHub

(build) #97 Change module path to classic-terra/core Change module path to classic-terra/core by inon-man · Pull Request #97 · classic-terra/core · GitHub

(build) #102 Snyk secops patches Snyk secops patches by ZaradarBH · Pull Request #102 · classic-terra/core · GitHub

(build) #105 Update docker assets

Bug Fixes Updated docker assets by ZaradarBH · Pull Request #105 · classic-terra/core · GitHub

(auth/client) #106 fix ungraceful error on failed client tax query fix ungraceful error on failed client tax query by fragwuerdig · Pull Request #106 · classic-terra/core · GitHub

(ante) #113 Fix burn tax split bug fix: burn tax split bug by inon-man · Pull Request #113 · classic-terra/core · GitHub

All changes from the v1.0.5-full-archive release

V1.0.5-full-archive…v1.1.0 Comparing v1.0.5-full-archive...v1.1.0 · classic-terra/core · GitHub

Discussion Threads around v1.1.0

Optional Feature # 1 - Wallet Exemption to On-chain Tax (Binance Request 1/2)

Summary: Add exemption to the burn tax between wallets on a tax exemption list. This applies to MsgSend, MsgMultiSend

Optional Feature # 2 - Separate Burn Wallet Exempt from Seigniorage (Binance Request 2/2)

Summary: In discussion with Binance and L1 senior devs, introduction of 2 burn wallets with different functionality was deemed confusing and introduces unnecessary redundancy. Accepted implementation is a single “new” burn wallet (with the same the old burn address) with seigniorage turned off at the L1 level.

Optional Feature # 3 - Burn Tax Split to Community Pool

Summary: Tax collected will be split directly with the community pool and the burn wallet. The split is initialized at 90/10 burn/cp and can be changed via parameter proposal.

Mandatory Upgrades

  • Ibc-go 1.1.5 → ibc-go 1.3.1
  • wasmvm v0.16.6 → wasmvm v0.16.7
  • cosmos-sdk v0.44.5 → cosmos-sdk v0.44.8
  • Other library “bumps” are dependencies around these library upgrades


Unit tests can be found at previous code discussions

Integration Testing can be found here

Additional Notes

The current recommended version of go 1.17 → 1.18. Go 1.19 is not supported yet and should not be used at this time.

Wallet exemption to on-chain taxes is a new type of proposal not available on the Station UI. This is similar to Software Upgrade Proposals (they are not available on Station). Caution should be used when performing these proposals on the command line. Station may have unexpected behaviors since these are not recognized. While a patch on testnet for the station UI has been made, please use caution until a patch can be incorporated onto various station wallets for mainnet.



1 Like

Yes yes yes,and let’s directly go to Parity and Repeg part :wink:

Thank you Ed! My validator JESUSisLORD will definitely be voting YES!

The 28th is just in time before Binance burn, excellent.


Hi @ek826, thanks for putting this discussion up. Can you expand on why Updated docker assets by ZaradarBH · Pull Request #105 · classic-terra/core · GitHub exists in the release and why work is being done on a Terra Operator?

I believe it is related LocalTerra. Install LocalTerra — Terra Classic Docs documentation. But I personally don’t use the docker tooling, so I’ll have to ask the others on the team how they utilize it.

Please do and get back to us. We want to know what exactly Terra Operator is and what’s planned for it.

Hi guys. I am new here. How can I monitor the voting process for 11367? It is not visible on terra station

Hey @ek826 thanks for keeping us in the loop! Did you ever figure out what exactly in this update is causing the chain halt?

Shalom! :pray:

hi this is just the designed mechanism of chain upgrades in newer versions of cosmos. We were on the old version, which is why we had to do it the other way before. With the modifications of v1.0.5, we are able to follow the proper procedures now.

excerpt from this article (Cosmos Dev Series: Cosmos Blockchain Upgrade | by zeroFruit | Web3 Surfers | Medium),
For the old version of the application, it just panic and self-killed its process . Every time the block is created x/upgrade module checks the Plan whether it’s time to run the upgrade procedure. It is normal that the old version application to panic and be killed when reaches the target block height because it has not UpgradeHandler. The old version application just writes the Plan data into the $DAEMON_HOME/data/upgrade-info.json file and exits the process when reaches the block height. So don’t panic about the panic message of the application.


Strongly yes!!! Thank you!

FYI the LUNC chain is temporarily halted. The L1 team and validators are working to make the upgrade to v1.1.0, but are encountering some technical difficulties. I or another person will update when there is more information.


The chain is upgraded successfully to v1.1.0 thanks to all the validators working together and the L1 team in the validator discord. Great work!

Terra Station is still not working though.

1 Like

Hey. A full node still broken here. Can you advise which version to use starting from 11734000 or above? Has anything changed in v1.1.0 repo after the chain restart? Can’t sync using v1.1.0 (nor v1.0.5).

You need to use v1.1.0. Here are the instructions:

How to update (compile):

$ git clone https://github.com/classic-terra/core.git
$ cd core
$ git checkout v1.1.0
$ make install

Update instructions if you already have the repository:

$ git fetch --all --tags
$ git checkout v1.1.0
$ make install

Then check for correct binary version:

$ terrad version --long
name: terra
server_name: terrad
version: 1.1.0
commit: 70d118b0ab38c5c2b61288a090177fdfa33dfe76
go: go version go1.18.1 linux/amd64

You can restart your binary using the command

$ sudo systemctl restart terrad

If you have problems, then check to make sure the consensus module is working:

curl localhost:26657/consensus_state

If it does not return back anything, then you will need to resync from the following (my suggestion is to backup everything in the config folder, and the data folder too just to be safe):

sudo systemctl stop terrad
cp $HOME/.terra/data/priv_validator_state.json $HOME/.terra/priv_validator_state.json.backup
rm -r $HOME/.terra/data

cd $HOME/.terra
wget -O - https://www.dropbox.com/s/d1z3k1l1misn05x/columbus-5-Mar-01.tar.lz4 | lz4 -d | tar -xvf -

mv $HOME/.terra/priv_validator_state.json.backup $HOME/.terra/data/priv_validator_state.json
sudo systemctl start terrad

Note: Always double/triple check priv_validator_state.json

If the address book is corrupted (has phoenix-1 information), then this was the suggested address book (although the address book in TR guides should still work I would think, but this is the one that got everyone up and running):


Hope that helps out, and that you have a great day today :slight_smile:

1 Like

Thanks for your reply aeuser999. Unfortunately this is exactly what I’ve been doing. No luck ser. Some pruned state snap after 11734002… anyone? Thanks

panic: Failed to process committed block (11734002:2567013EB5E4ED5D538672B668B57A276F30129952572150C4FEE00F62E9E727): wrong Block.Header.LastResultsHash. Expected 658EC57B453249685F1074BC1F6CE5C56C04730BD850F0F05DFAAD41BF02B3B1, got AFE97BD368F0D6B92206B83EB89A1CBC8DED4B9EE1596F4A819C6817F53F47C9

terrad version --long
name: terra
server_name: terrad
version: 1.1.0
commit: 70d118b0ab38c5c2b61288a090177fdfa33dfe76
build_tags: netgo,ledger
go: go version go1.18.1 linux/amd64

We had one other person report the same issue. The above process worked for them. Just wondering… can you check sudo ps -e u | grep terrad and see if it shows any other instances of terrad running? If so, you may want to stop them.

Other than that, if you are upgrading, you may want to start with a fresh folder and git clone and build (although you have the right commit hash and golang version, so it should be ok). The only other thing I can think of is to make sure the snapshot is extracting correctly, in the right directory, and make sure the priv_validator_state.json file is copied back into the directory.

Just a few thoughts…

One other helpful comment was this:

if you use systemd and you’ve put wasm libraries in chain-specific folders, and if you build terrad on a different machine… make sure you actually copy over the wasm lib and set the LD_LIBRARY_PATH or risk an app hash error

Thanks for the last tip. Can you please give me your ldd output of the working binary (regarding libwasmvm.so ver) ? BTW positive, no other instances running and yep I tried from scratch.