JuChain
zh
English
English
  • JuChain Documentation
  • What is JuChain?
  • Basics
    • Network Information
    • Start Using JuChain
    • Technical Architecture
    • Smart Contract
  • Ecosystem
    • On-Chain Ecosystem
    • Testnet Faucet
    • Cross-Chain Bridge
    • Decentralized Exchange
  • Price Oracle
  • Developer Guide
    • Getting Started
    • Tutorials and Examples: Building and Deploying a Simple dApp
    • Tutorials and Examples: Building a Simple DeFi Lending dApp
    • Technical Reference
    • Contract Source Code Verification Guide
      • Verifying Contract Source Code on JuScan Browser via GUI
      • Contract Verification on JuChain using the Hardhat framework
  • Community & Support
    • Community & Support
    • Brand Resources & Guidelines
Powered by GitBook
On this page
  • Prerequisites
  • Steps for Graphical Verification
  • Checking Verification Results
  • Common Issues and Troubleshooting
  1. Developer Guide
  2. Contract Source Code Verification Guide

Verifying Contract Source Code on JuScan Browser via GUI

PreviousContract Source Code Verification GuideNextContract Verification on JuChain using the Hardhat framework

Last updated 1 day ago

This guide provides a detailed walkthrough on how to verify a smart contract's source code using the graphical user interface (GUI) provided by JuScan. This approach is designed for users who are not familiar with command-line tools like Hardhat or Foundry, offering an intuitive and user-friendly method. Once verified, users can view the contract’s source code on the JuScan blockchain explorer, understand its functionality, and interact with it securely.


Prerequisites

Before starting the verification process, ensure you have the following information ready:

  1. Contract Address: The address of the smart contract successfully deployed on JuChain.

  2. Contract Source Code: The complete Solidity (.sol), Yul (.yul), or Vyper (.vy) source code file(s).

  3. Compiler Version: The exact version of the Solidity, Yul, or Vyper compiler used during deployment (e.g., 0.8.8).

  4. EVM Version (if non-default): The target EVM version specified during compilation.

  5. Optimization Settings: Whether optimization was enabled during compilation and the number of optimization runs (runs, typically 200 for Solidity by default).

  6. Constructor Arguments (ABI-Encoded): If the contract has a constructor, provide the ABI-encoded hexadecimal string (starting with 0x) of the parameters passed to the constructor during deployment. You can retrieve this from Hardhat/Foundry deployment logs or generate it using tools like ethers.js or web3.js.

  7. Library Addresses (if linked to external libraries): The names and deployed addresses of all libraries used by the contract.

  8. SPDX License Identifier (optional but recommended): The SPDX license identifier specified in your contract source code (e.g., MIT, GPL-3.0).

  9. JSON Input or Metadata File (if using specific verification methods): The standard JSON input file or metadata.json file generated by the compiler.


Steps for Graphical Verification

  1. Access the Verification Page:

    • Recommended: Navigate directly to the contract address page of your deployed contract. On the contract details page, locate the Code tab and click the Verify & Publish button or link.

    • Alternatively, find the verification option in the JuScan browser’s main menu under More / Tools -> Verify Contract.

    • Or, access the verification URL directly: https://juscan.io/contract-verification (for testnets, use https://testnet.juscan.io/contract-verification).

  2. Enter the Contract Address:

    • If you didn’t navigate from the contract page, paste the contract address you wish to verify in the Contract Address to Verify field.

  3. Select the Contract License:

    • Choose the open-source license from the dropdown menu that matches the SPDX-License-Identifier declared in your contract source code (if applicable). Specifying a license is strongly recommended.

    • JuScan supports common licenses such as MIT, GPL series, Apache, Unlicense, etc.

    • If the code is not open-source or no license is specified, select No License (None).

  4. Select the Verification Method / Compiler Type:

    • The dropdown menu offers various verification input types. Choose the method that best matches your project and compilation output:

      • Solidity (Single file / Flattened source code): Suitable for a single .sol or .yul file. If your contract includes import statements, you must first flatten all dependent code into a single file. This is the most straightforward method but may require preprocessing for complex projects.

      • Solidity (Standard JSON input): Highly recommended. Upload the standard JSON input file generated by the Solidity compiler, which includes all source code, compiler settings, and other relevant information. This method has a high success rate.

      • Solidity (Multi-part files): Suitable for projects with multiple (at least two) .sol or .yul files (e.g., main contract, libraries, interfaces) that reference each other via import. You must upload all related source files individually.

      • Solidity (Hardhat) / Solidity (Foundry): Allows verification using compilation artifacts (e.g., build-info files) from Hardhat or Foundry projects. Follow the interface prompts.

      • Vyper (Contract): Suitable for a single Vyper contract file.

      • Vyper (Multi-part files): Suitable for projects with multiple Vyper files.

  5. Fill in Detailed Information (varies by verification method):

  • Depending on the selected verification method, different input fields will appear.

  • Common Fields:

    • Compiler Version: Select the exact compiler version used during deployment (e.g., 0.8.8). Avoid selecting Nightly Builds.

    • EVM Version: Select the target EVM version specified during compilation. If the compiler’s default was used, choose default or the corresponding default EVM for the compiler.

    • Optimization Enabled: If optimization was enabled during compilation, select Yes and specify the number of Optimization Runs (e.g., 200). If disabled, select No.

  • For Solidity (Single file / Flattened):

    • Is Yul contract?: Check this box if you are uploading Yul (.yul) code.

    • Enter the Solidity Contract Code: Paste the complete, flattened Solidity or Yul source code into the provided text box.

    • Constructor Arguments: If the contract has a constructor, paste the ABI-encoded parameter string (starting with 0x) here.

    • Contract Libraries: If the contract links to external libraries, click Add Contract Library and provide the name and deployed address of each library.

  • For Solidity (Standard JSON input):

    • Upload the .json file containing the standard JSON input.

  • For Solidity (Multi-part files):

    • Upload all .sol or .yul source files individually, including the main contract and all dependencies.

  1. Submit Verification:

  • Double-check all provided information, then click Verify and Publish or a similarly named button to submit the verification request.


Checking Verification Results

  • Success: If all information is correct and matches the on-chain bytecode, the page will display a success message. On the contract address details page, a green checkmark ✅ will appear next to the Code tab, indicating successful verification. Additionally, Read Contract and Write Contract tabs will become available, enabling user interaction.

  • Failure: If verification fails, an error message will be displayed, such as "There was an error compiling your contract", "Bytecode does not match", or "Compiler version mismatch". Carefully review the error message, as it will indicate the specific issue.


Common Issues and Troubleshooting

If verification fails, check for the following common issues:

  1. Compiler Version Mismatch:

    • Ensure the selected compiler version (including patch number, e.g., x.y.z) is exactly the same as the one used during deployment.

  2. Optimization Settings Mismatch:

    • Verify that the optimization enabled status (Yes/No) and the number of optimization runs (runs) match those used during deployment. This is a frequent source of errors.

  3. EVM Version Mismatch:

    • If a non-default EVM version was specified during compilation, ensure it is correctly selected here.

  4. Source Code Mismatch:

    • Confirm that the submitted source code (whether a single file, multiple files, or code within a JSON input) is identical to the version used during deployment, including spaces, comments, etc.

    • For Single file/Flattened mode, ensure all import statements have been properly inlined.

    • The SPDX-License-Identifier in the source code should match the license type selected in the form.

  5. Incorrect Constructor Arguments:

    • Ensure the ABI-encoded parameter string (starting with 0x) matches the one used in the deployment transaction exactly, including encoding method, parameter order, and values.

  6. Incorrect Library Addresses:

    • If external libraries are used, verify that the library names and deployed addresses are accurate.

  7. Incorrect Verification Method:

    • For example, using Single file mode for a multi-file contract without flattening the code.

  8. Yul Contract Misidentification:

    • If verifying a Yul contract, ensure the Yul contract checkbox is selected.

  9. Network or Browser Issues:

    • Try refreshing the page, clearing the browser cache, or using a different browser.