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 Fuji Testnet Explorer is here.

If you have issues, contact us on Discord.

Steps​

Navigate to the Contract tab at the Explorer page for your contract's address.

verify and publish

Click Verify & Publish to enter the smart contract verification page.

SRC

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

libraries

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

Examples​

SwapFlashLoan uses swaputils and mathutils:

SwapUtils requires mathutils:

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.

Was this page helpful?