# Verifying Contract Source Code on JuScan Browser via GUI

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

<figure><img src="/files/Y79ouhcbGWyezyuj1WS3" alt="" width="375"><figcaption></figcaption></figure>

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):

<figure><img src="/files/ywolV7RMlaNBxVfszaXz" alt="" width="563"><figcaption></figcaption></figure>

* 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.

6. **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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://juchain.gitbook.io/juchain-docs/developer-guide/contract-source-code-verification-guide/verifying-contract-source-code-on-juscan-browser-via-gui.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
