Verify Smart Contract Source Code is what is Deployed to the Terra Blockchain

According to what has been said on Terra’s Discord, it is not possible to verify the byte code of smart contracts uploaded and deployed to the Terra Blockchain matches a given rust cosmwasm source code. If this is true, it would have huge implications.

This would go against the principle of a trustless blockchain. How can anyone trust the source code uploaded by TFL, Anchor or Mirror on GitHub matches what the user actually interacts with on-chain? It also defeats the purpose of audits done on those projects because they all reference the source code uploaded to GitHub (i.e. Anchor Audit page 5).

This is a huge security concern. A malicious actor could write a new smart contract and publish it to GitHub having done audits. Only to upload a completely different compiled smart contract to the blockchain that steals people’s assets.

There currently is not even a way to view contract code on Terra Finder unlike Etherscan. I understand that this is because Solidity can be decompiled differently than cosmwasm which compiles down to bytecode. However, you still should have the ability to see the bytecode and from there compile what was uploaded to GitHub to verify they match.

Discord says this is all because the rust compiler is non-deterministic. Although according to the cosmwasm discord, rust-optimizer is deterministic and it’s a uniquely Terra problem. As a developer myself, I can’t imagine a compiler being non-deterministic.

Apologies if this is not true. I would love to get to the bottom of this and be able to verify the smart contracts myself as a user of the blockchain.


Whoever told you that didn’t read the docs carefully.

From CosmWasm/rust-optimizer repository:

Sometime you want many contracts to be related and import common functionality. […] In such a case, we often not just compile from root, as the compile order is not deterministic […]

For this use-case we made a second docker image, which will compile all the contracts/* folders inside the workspace and do so one-by-one in alphabetical order.

To compile all contracts in the workspace deterministically, you can run […]

Using workspace-optimizer compilation should be deterministic, always producing the same binaries from the same source code.

1 Like

Thanks for the answer @larry. Yes, that makes sense to me and matches what was said in the cosmwasm discord.

Do you know how you would go about verifying a smart contracts source code matches what is uploaded to the Terra chain?

Like I wish it were as easy as Etherscan’s verify contract. Right now, you can’t even see the contract’s binary on Terra finder. For example, this is Anchor’s Market Contract on Terra finder. All you see is Code ID 163. How do you know it matches Anchor’s Market Contract Github? 🤷

There should be more tooling around this. This should be encouraged especially as more projects launched by teams outside of TFL start popping up on Terra.


You can find the hash of the binary on-chain and compare with the binary you compiled from source code. Finder does not support this but it’s possible to retrieve the on-chain binary programmatically. I believe I’ve heard this feature is being worked on.

1 Like

You can hash the wasm binary stored on chain for a particular code ID like this:


curl "${CODE_ID}/byte_code" \
  | jq ".byte_code" \
  | tr -d \" \
  | base64 -d \
  | shasum -a 256

Or you can access the hash stored as metadata on chain like this:


curl "${CODE_ID}" \
  | jq ".code_info.code_hash" \
  | tr -d \" \
  | base64 -d \
  | hexdump -v -e '/1 "%02x"'

This should return 1cca9c6dbfcb876212ee21250b1352df6e0041a5a13b7c1bc562f0f001455977 for code ID 610.