Contract verification on Etherscan in Blockchain / Solidity - Mini Project: Build & Apply

Contract verification on Etherscan

📖 Scenario: You have just deployed a smart contract on the Ethereum blockchain. To make your contract's source code public and allow others to verify it, you need to verify your contract on Etherscan.This project will guide you through the steps to prepare and submit your contract for verification on Etherscan.

🎯 Goal: Learn how to prepare your smart contract source code and metadata, and submit it to Etherscan for verification.

📋 What You'll Learn

Have a deployed smart contract address

Have the exact source code of the deployed contract

Know the compiler version used for deployment

Understand how to use Etherscan's contract verification interface

💡 Why This Matters

🌍 Real World

Verifying your smart contract on Etherscan makes your code public and trustworthy. It helps users and developers see exactly what your contract does.

💼 Career

Blockchain developers often need to verify contracts to ensure transparency and security. This skill is essential for roles involving smart contract deployment and auditing.

1

Prepare the contract source code

Create a string variable called source_code that contains the exact Solidity source code of your deployed contract. Use triple quotes to include multiple lines.

Blockchain / Solidity

# Your code here

Hint

Use triple quotes ''' to write the full Solidity code as a string.

2

Specify the compiler version

Create a string variable called compiler_version and set it to the exact Solidity compiler version used to deploy the contract, for example, "v0.8.0+commit.c7dfd78e".

Blockchain / Solidity

source_code = '''
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 public storedData;

    function set(uint256 x) public {
        storedData = x;
    }

    function get() public view returns (uint256) {
        return storedData;
    }
}
'''
# Your code here

Hint

Check your deployment logs or compiler settings to find the exact compiler version string.

3

Prepare the verification metadata

Create a dictionary called verification_data with keys "address", "sourceCode", and "compilerVersion". Set "address" to the deployed contract address "0x1234567890abcdef1234567890abcdef12345678", "sourceCode" to the source_code variable, and "compilerVersion" to the compiler_version variable.

Blockchain / Solidity

source_code = '''
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 public storedData;

    function set(uint256 x) public {
        storedData = x;
    }

    function get() public view returns (uint256) {
        return storedData;
    }
}
'''

compiler_version = "v0.8.0+commit.c7dfd78e"

# Your code here

Hint

Use a dictionary with the exact keys and values as described.

4

Print the verification data

Write a print statement to display the verification_data dictionary.

Blockchain / Solidity

source_code = '''
pragma solidity ^0.8.0;

contract SimpleStorage {
    uint256 public storedData;

    function set(uint256 x) public {
        storedData = x;
    }

    function get() public view returns (uint256) {
        return storedData;
    }
}
'''

compiler_version = "v0.8.0+commit.c7dfd78e"

verification_data = {
    "address": "0x1234567890abcdef1234567890abcdef12345678",
    "sourceCode": source_code,
    "compilerVersion": compiler_version
}

# Your code here

Hint

Use print(verification_data) to show the dictionary.

Practice

1. What is the main purpose of verifying a smart contract on Etherscan?

easy

A. To make the contract source code public and trusted

B. To increase the gas cost of contract deployment

C. To hide the contract's source code from users

D. To automatically upgrade the contract's functionality

Solution

1. Step 1: Understand contract verification purpose

   Verification publishes the source code so users can see and trust it.

2. Step 2: Eliminate incorrect options

   Increasing gas cost, hiding code, or auto-upgrading are not related to verification.

3. Final Answer:

   To make the contract source code public and trusted -> Option A

4. Quick Check:

   Verification = public and trusted code [OK]

Hint: Verification means sharing source code publicly [OK]

Common Mistakes:

• Thinking verification hides code
• Confusing verification with contract upgrades
• Assuming verification increases deployment cost

2. Which of the following is the correct step to verify a contract on Etherscan?

easy

A. Deploy the contract twice on the blockchain

B. Send ETH to Etherscan wallet to activate verification

C. Upload the source code and match compiler version exactly

D. Encrypt the source code before uploading

Solution

1. Step 1: Identify verification process

   Verification requires uploading source code and matching compiler settings exactly.

2. Step 2: Remove incorrect options

   Sending ETH, deploying twice, or encrypting code are not part of verification.

3. Final Answer:

   Upload the source code and match compiler version exactly -> Option C

4. Quick Check:

   Upload code + match compiler = verification [OK]

Hint: Match compiler version exactly when uploading code [OK]

Common Mistakes:

• Ignoring compiler version mismatch
• Thinking payment is needed for verification
• Trying to encrypt source code before upload

3. Given the following Solidity contract and verification attempt, what will happen if the compiler version used during verification does not match the deployed contract's compiler version?

pragma solidity ^0.8.0;
contract Simple { uint public x; constructor() { x = 10; } }

medium

A. Verification will fail due to compiler version mismatch

B. Verification will succeed and show the source code

C. Contract will be redeployed automatically

D. Verification will succeed but source code will be hidden

Solution

1. Step 1: Understand compiler version role in verification

   Etherscan requires exact compiler version match to verify source code.

2. Step 2: Analyze mismatch effect

   If versions differ, verification fails because bytecode won't match source code.

3. Final Answer:

   Verification will fail due to compiler version mismatch -> Option A

4. Quick Check:

   Compiler mismatch = verification fail [OK]

Hint: Compiler version mismatch causes verification failure [OK]

Common Mistakes:

• Assuming verification ignores compiler version
• Thinking contract redeploys automatically
• Believing source code hides after verification

4. You tried verifying your contract on Etherscan but got an error saying "Bytecode does not match source code." What is the most likely cause?

medium

A. Your contract has no constructor

B. You used a different compiler version than the one used to deploy

C. You uploaded the wrong contract address

D. You forgot to pay the verification fee

Solution

1. Step 1: Understand bytecode mismatch meaning

   Bytecode mismatch means the compiled source code does not match deployed bytecode.

2. Step 2: Identify common cause

   Using a different compiler version or settings causes bytecode mismatch errors.

3. Final Answer:

   You used a different compiler version than the one used to deploy -> Option B

4. Quick Check:

   Bytecode mismatch = compiler version difference [OK]

Hint: Check compiler version if bytecode mismatch error occurs [OK]

Common Mistakes:

• Thinking payment is required for verification
• Confusing contract address with bytecode mismatch
• Assuming constructor presence affects verification

5. You have a contract deployed with optimization enabled during compilation. When verifying on Etherscan, which of the following must you do to successfully verify the contract?

hard

A. Verify using a different contract address

B. Disable optimization and upload source code with any compiler version

C. Only upload the ABI without source code

D. Upload source code with optimization enabled and match compiler version

Solution

1. Step 1: Understand optimization effect on bytecode

   Optimization changes compiled bytecode, so verification must match optimization settings.

2. Step 2: Match compiler version and optimization settings

   To verify, upload source code with exact compiler version and optimization enabled as deployed.

3. Final Answer:

   Upload source code with optimization enabled and match compiler version -> Option D

4. Quick Check:

   Match optimization + compiler version = successful verification [OK]

Hint: Match optimization settings and compiler version exactly [OK]

Common Mistakes:

• Ignoring optimization settings during verification
• Uploading only ABI without source code
• Trying to verify with wrong contract address