LCX Logo

    Verify Smart Contracts

    Contract verification links your deployed bytecode to its original source code on the block explorer. Once verified, anyone can read the contract's logic, audit its behavior, and interact with its functions directly through the explorer interface. Verification is a critical step for building transparency and trust with users of your protocol.

    Why Verify Your Contracts?

    • Transparency — Users and auditors can read the exact source code that produced the deployed bytecode, confirming that the contract does what it claims.
    • Trust — Verified contracts display a green checkmark on the explorer, signaling to users that the code is open and auditable.
    • Interaction — The explorer provides auto-generated read and write interfaces for verified contracts, allowing users to call functions without writing code or using a separate frontend.
    • Decoded transactions — When a contract is verified, the explorer can decode transaction input data and event logs into human-readable format, making it much easier to understand on-chain activity.

    Compiler Version Must Match

    The most common verification failure is a compiler version mismatch. Make sure the Solidity compiler version you specify during verification matches exactly the version used to compile the contract. This includes patch versions — for example, 0.8.24 will not match 0.8.23.

    Method 1: Via the Blockscout UI

    The simplest way to verify a contract is directly through the explorer's web interface. This method requires no additional tooling — just your source code and compiler settings.

    1. Navigate to your contract's address on the Liberty Chain Block Explorer.
    2. Click the "Contract" tab, then click "Verify & Publish".
    3. Select the verification method: "Solidity (Single file)" for contracts without imports, or "Solidity (Standard JSON Input)" for projects with multiple files or imports.
    4. Paste your contract source code, select the exact compiler version, set the optimization parameters (must match your deployment settings), and provide constructor arguments if applicable.
    5. Click "Verify & Publish". If the compilation output matches the on-chain bytecode, verification will succeed.

    Method 2: Via Hardhat

    If you deployed your contract with Hardhat, you can verify it from the command line using the hardhat-verify plugin (included in @nomicfoundation/hardhat-toolbox). First, configure Blockscout as a custom chain in your Hardhat config:

    hardhat.config.ts — Verification configuration
    typescript
    etherscan: {
      apiKey: {
        libertyChain: "abc",
      },
      customChains: [
        {
          network: "libertyChain",
          chainId: 76847801,
          urls: {
            apiURL: "https://testnet-explorer-api.lcx.com/api",
            browserURL: "https://testnet-explorer.lcx.com",
          },
        },
      ],
    },

    Then run the verify command:

    Verify with Hardhat
    bash
    npx hardhat verify --network libertyChain <contract-address>

    If your contract's constructor accepts arguments, append them after the address:

    Verify with constructor arguments
    bash
    npx hardhat verify --network libertyChain <contract-address> "arg1" "arg2"

    For the full Hardhat deployment and configuration guide, see Deploy with Hardhat.

    Method 3: Via Foundry

    Foundry's forge verify-contract command supports Blockscout verification natively. No API key is required.

    Verify with Foundry
    bash
    forge verify-contract <contract-address> src/MyContract.sol:MyContract \
      --chain-id 76847801 \
      --verifier blockscout \
      --verifier-url https://testnet-explorer-api.lcx.com/api

    If your contract was deployed with constructor arguments, add them with the --constructor-args flag:

    Verify with constructor arguments
    bash
    forge verify-contract <contract-address> src/MyContract.sol:MyContract \
      --chain-id 76847801 \
      --verifier blockscout \
      --verifier-url https://testnet-explorer-api.lcx.com/api \
      --constructor-args $(cast abi-encode "constructor(uint256)" 42)

    For the full Foundry deployment guide, see Deploy with Foundry.

    Method 4: Via the Blockscout API

    You can also verify contracts programmatically using the Blockscout verification API. This is useful for CI/CD pipelines or custom deployment scripts.

    Verify via API
    bash
    curl -X POST "https://testnet-explorer-api.lcx.com/api?module=contract&action=verify" \
      -H "Content-Type: application/x-www-form-urlencoded" \
      -d "addressHash=<contract-address>" \
      -d "name=MyContract" \
      -d "compilerVersion=v0.8.24+commit.e11b9ed9" \
      -d "optimization=true" \
      -d "optimizationRuns=200" \
      -d "contractSourceCode=<url-encoded-source-code>"

    The API will return a JSON response indicating whether verification succeeded or failed, along with any error details if the source code does not match the deployed bytecode.

    Multi-File Verification

    If your contract imports other files (libraries, interfaces, or base contracts), you have several options for verification:

    • Standard JSON Input — Export the Standard JSON Input from your build tool (Hardhat or Foundry both produce this) and upload it through the Blockscout UI. This is the most reliable method for complex projects with many dependencies.
    • Flattened source — Use hardhat flatten or forge flatten to combine all files into a single source file, then verify using the single-file method.
    • CLI tools — Both Hardhat and Foundry verification commands handle multi-file projects automatically. They resolve imports, package the correct source files, and submit them to the explorer. This is the recommended approach for most developers.

    Optimization Settings

    If your contract was compiled with the Solidity optimizer enabled, you must specify the same optimization settings during verification. This includes whether optimization was enabled and the number of runs. A mismatch will cause verification to fail even if the source code is correct.