Skip to main content

Verify Smart Contracts on the C-Chain Explorer

The C-Chain Explorer supports verifying smart contracts, allowing users to review it.

The Mainnet C-Chain Explorer is here and the Tahoe Testnet Explorer is here.

If you have issues, contact us on Telegram.

Steps​

Scroll down on the transaction details page from your contract's address. Example: https://tahoe.metaltrace.io/tx/0x1bc4154cf3dc9efa3347ec805882f649b8c91f0782fb3491d3023de9d9f4fcb6

verify and publish

And click on the "here" link.

SRC

Here you can select an option suitable for you and click on the next button.

SRC

Here you can enter the contract code and select options suitable to you and click on the verify and publish button.

Libraries can be provided. If they are, they must be deployed, independently verified and in the Add Contract Libraries section.

The C-Chain Explorer can fetch constructor arguments automatically for simple smart contracts. More complicated contracts might require you to pass in special constructor arguments. Smart contracts with complicated constructors may have validation issues. You can try this online ABI encoder.

Requirements​

  • IMPORTANT Contracts should be verified on Testnet before being deployed to Mainnet to ensure there are no issues.
  • Contracts must be flattened.
    • Includes will not work.
  • Contracts should be compile-able in Remix.
    • A flattened contract with pragma experimental ABIEncoderV2 (as an example) can create unusual binary and/or constructor blobs. This might cause validation issues.
  • The C-Chain Explorer only validates solc JavaScript and only supports Solidity contracts.

Libraries​

The compile bytecode will identify if there are external libraries. If you released with Remix, you will also see multiple transactions created.

{
  "linkReferences": {
    "contracts/Storage.sol": {
      "MathUtils": [
        {
          "length": 20,
          "start": 3203
        }
        ...
      ]
    }
  },
  "object": "....",
  ...
}

This requires you to add external libraries in order to verify the code.

A library can have dependent libraries. To verify a library, the hierarchy of dependencies will need to be provided to the C-Chain Explorer. Verification may fail if you provide more than the library plus any dependencies (that is you might need to prune the Solidity code to exclude anything but the necessary classes).

You can also see references in the byte code in the form __$75f20d36....$__. The keccak256 hash is generated from the library name.

Example online converter: contracts/Storage.sol:MathUtils => 75f20d361629befd780a5bd3159f017ee0f8283bdb6da80805f83e829337fd12

Caveats​

SPDX License Required​

An SPDX must be provided.

// SPDX-License-Identifier: ...

keccak256 Strings Processed​

The C-Chain Explorer interprets all keccak256(...) strings, even those in comments. This can cause issues with constructor arguments.

/// keccak256("1");
keccak256("2")

This could cause automatic constructor verification failures. If you receive errors about constructor arguments they can be provided in ABI hex encoded form on the contract verification page.

Solidity Constructors​

Constructors and inherited constructors can cause problems verifying the constructor arguments.

example:

abstract contract Parent {
  constructor () {
    address msgSender = ...;
    emit Something(address(0), msgSender);
  }
}
contract Main is Parent {
  constructor (
          string memory _name,
          address deposit,
          uint fee
  ) {
    ...
  }
}

If you receive errors about constructor arguments they can be provided in ABI hex encoded form on the contract verification page.