Contract verification on Etherscan in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Contract verification on Etherscan

Write Smart Contract Code

↓

Compile Contract to Bytecode

↓

Deploy Contract on Blockchain

↓

Get Contract Address

↓

Go to Etherscan Verification Page

↓

Submit Source Code + Compiler Settings

↓

Etherscan Compiles and Matches Bytecode

Shows the step-by-step process from writing a smart contract to verifying it on Etherscan by matching compiled bytecode.

Execution Sample

Blockchain / Solidity

pragma solidity ^0.8.0;

contract SimpleStorage {
    uint storedData;
    function set(uint x) public {
        storedData = x;
    }
}

A simple Solidity contract storing a number, ready to be compiled and deployed.

Execution Table

Step	Action	Input/Condition	Result/Output
1	Write contract code	SimpleStorage contract code	Source code ready
2	Compile contract	Solidity compiler v0.8.0	Bytecode generated
3	Deploy contract	Bytecode on blockchain	Contract address assigned
4	Open Etherscan verification page	Contract address input	Verification form loaded
5	Submit source code + compiler settings	Source code + compiler version + optimization	Etherscan compiles source
6	Compare compiled bytecode with on-chain bytecode	Bytecode match?	Yes - verification success
7	Verification result	Success	Contract source code published on Etherscan

💡 Verification stops after bytecode matches on-chain bytecode or fails if no match

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
source_code	SimpleStorage code	Same	Same	Submitted to Etherscan	Published on Etherscan
bytecode	None	Generated by compiler	Deployed on blockchain	Recompiled by Etherscan	Matched on-chain bytecode
contract_address	None	None	Assigned after deployment	Used for verification	Used for verification

Key Moments - 3 Insights

Why must the compiler version and optimization settings match exactly during verification?

Because Etherscan recompiles the source code with the provided settings and compares bytecode. If settings differ, bytecode won't match, causing verification to fail (see execution_table step 5 and 6).

What happens if the bytecode does not match during verification?

Verification fails and the source code is not published. This is shown in the concept_flow where 'No Match' leads to 'Verification Failed'.

Why do we need the contract address for verification?

The contract address tells Etherscan which on-chain bytecode to compare against the compiled source code (see execution_table step 4 and 6).

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after step 3 (Deploy contract)?

A Contract address assigned

B Source code published

C Bytecode generated

D Verification failed

💡 Hint

Check the 'Result/Output' column for step 3 in the execution_table.

At which step does Etherscan compare the compiled bytecode with the on-chain bytecode?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look for the step mentioning 'Compare compiled bytecode' in the execution_table.

If the compiler version submitted to Etherscan is different from the one used to deploy, what will happen?

A Contract address will change

B Verification will succeed

C Verification will fail due to bytecode mismatch

D Source code will be automatically corrected

💡 Hint

Refer to key_moments about compiler version and optimization settings.

Concept Snapshot

Contract verification on Etherscan:
1. Write and compile smart contract.
2. Deploy contract to blockchain.
3. Get contract address.
4. Submit source code and compiler settings on Etherscan.
5. Etherscan recompiles and compares bytecode.
6. If matched, source code is published for transparency.

Full Transcript

Contract verification on Etherscan is the process of proving that the source code you wrote matches the code deployed on the blockchain. First, you write your smart contract code and compile it to get bytecode. Then you deploy this bytecode to the blockchain, which gives you a contract address. To verify, you go to Etherscan, enter the contract address, and submit your source code along with the exact compiler version and optimization settings you used. Etherscan recompiles your source code and compares the bytecode with the one on the blockchain. If they match, verification succeeds and your source code is published on Etherscan for anyone to see. This process helps users trust the contract by seeing its source code. If the bytecode does not match, verification fails. It is important to use the exact compiler settings to avoid mismatch. The contract address is needed so Etherscan knows which deployed code to compare against.

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