Deploying Your First Smart Contract on ADI: Step-by-Step Developer Guide

ADI Chain is a modular, EVM-compatible Layer-2 blockchain secured by Ethereum. It is built on zkSync OS and the Airbender proving system: transactions are executed off-chain, verified with zero-knowledge validity proofs, and finalized on Ethereum. ADI uses the ADI token for gas.

For developers, this means you can deploy Ethereum smart contracts with minimal modifications and work with standard EVM tooling such as Foundry, Hardhat, MetaMask, ethers, and viem. You do not need a special compiler or ZK-specific plugins.

In this guide, you will write a storage contract, test it locally, deploy it to ADI Network AB Testnet, verify it on the block explorer, and interact with it from the command line.

Table of contents:

1. How to Deploy Smart Contract on ADI Chain: Requirements & Setup
2. How ADI Differs From Ethereum
3. How to Deploy a Smart Contract on ADI Chain: 6 Steps
4. Smart Contracts on ADI Chain: Next Steps
5. Common ADI Chain Smart Contract Deployment Errors & How to Fix Them
6. Conclusion

How to Deploy Smart Contract on ADI Chain: Requirements & Setup

You need basic familiarity with Solidity and the command line. Checklist:

• Foundry. Install it with curl -L https://foundry.paradigm.xyz | bash, then run foundryup. Check with forge –version.
• Node.js (optional). Needed only for the Hardhat path. Check the Hardhat documentation for the supported version.
• Code editor. Visual Studio Code with the Solidity extension by Juan Blanco flags syntax errors before compilation.
• Test wallet. Install MetaMask and create a separate wallet for testing. Never reuse a wallet that holds real funds.
• Blockchain basics. If gas, transactions, and addresses are unfamiliar, read the introductory guides on Ethereum.org.

Keep reading this ADI Chain developer guide to learn how to deploy ADI Chain smart contracts.

How ADI Differs From Ethereum

ADI behaves like Ethereum from a developer’s point of view, with a few differences worth knowing:

• Gas token. Fees are paid in ADI, not ETH. You need ADI on the network you deploy to.
• Separate chain IDs. Testnet and mainnet use different chain IDs. Using the wrong one makes transactions fail.
• Two-resource accounting. ADI tracks two resources per transaction. The first is Ergs, the execution-environment resource, which you see as ordinary EVM gas. The second is a native resource that models the off-chain cost of processing a transaction, mainly proving and publishing data. A useful intuition is how many RISC-V cycles it takes to prove the computation. If a transaction runs out of native resource, it reverts. The native limit is derived from the transaction’s gas limit and gas price, and standard eth_estimateGas already accounts for it, so in normal use you only deal with gas.
• Unsupported features. ERC-7702, ERC-4844, and debug_traceCall with custom tracers are not currently supported.

Always test on the testnet first. Mistakes there cost nothing, while mistakes on mainnet cost real funds.

How to Deploy a Smart Contract on ADI Chain: 6 Steps

Here are 6 steps you need to take to deploy a smart contract on ADI Chain.

1. Set Up Your Development Environment

Create a Foundry project:

bash

forge init adi-storage-project

cd adi-storage-project

Add the testnet to MetaMask (Add network manually) with these details:

• Network name: ADI Network AB Testnet
• RPC URL: https://rpc.ab.testnet.adifoundation.ai/
• Chain ID: 99999
• Currency symbol: ADI
• Block explorer URL: https://explorer.ab.testnet.adifoundation.ai/

Then request test tokens from the testnet faucet at http://faucet.ab.testnet.adifoundation.ai/ by pasting your wallet address.

Store your deployer key in an encrypted Foundry keystore instead of a plaintext file:

bash

cast wallet import adi-deployer –interactive

Paste the private key of your test wallet when prompted and set a password. If you prefer a .env file, add it to .gitignore before your first commit.

2. Write Your First Smart Contract

We will build a simple storage contract. It stores an integer, emits an event when the value changes, and lets anyone read the current value. Create src/SimpleStorage.sol:

solidity

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.24;

contract SimpleStorage {

    uint256 private storedData;

    address public owner;

    event DataUpdated(uint256 indexed oldValue, uint256 indexed newValue, address updater);

    constructor(uint256 initialValue) {

        owner = msg.sender;

        storedData = initialValue;

    }

    function set(uint256 x) public {

        uint256 previous = storedData;

        storedData = x;

        emit DataUpdated(previous, x, msg.sender);

    }

    function get() public view returns (uint256) {

        return storedData;

    }

}

What each part does:

• pragma solidity ^0.8.24; sets the allowed compiler versions.
• storedData is a state variable kept permanently in on-chain storage.
• owner records who deployed the contract. Solidity generates a public getter for it automatically.
• event DataUpdated writes a log entry. Off-chain apps watch these logs instead of polling storage.
• constructor runs once, at deployment.
• set changes state, so calling it needs a signed transaction and costs gas.
• get only reads state. Reads run against a node’s local state and are free.

Compile the contract:

bash

forge build

The compiler writes the ABI (the JSON description of callable functions and events) and the bytecode (the instructions deployed to the network) into the out/ directory.

3. Test Before Deployment on ADI Chain

A deployed contract cannot be edited. If you find a bug later, you have to deploy a new contract, unless you planned for upgrades with a proxy. Test before you deploy.

Foundry runs tests on a local in-memory EVM, so they are fast and free. Create test/SimpleStorage.t.sol:

solidity

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.24;

import {Test} from “forge-std/Test.sol”;

import {SimpleStorage} from “../src/SimpleStorage.sol”;

contract SimpleStorageTest is Test {

    SimpleStorage internal store;

    event DataUpdated(uint256 indexed oldValue, uint256 indexed newValue, address updater);

    function setUp() public {

        store = new SimpleStorage(42);

    }

    function test_InitialValue() public view {

        assertEq(store.get(), 42);

    }

    function test_SetEmitsEventAndUpdatesValue() public {

        vm.expectEmit(true, true, false, true);

        emit DataUpdated(42, 88, address(this));

        store.set(88);

        assertEq(store.get(), 88);

    }

    function testFuzz_Set(uint256 x) public {

        store.set(x);

        assertEq(store.get(), x);

    }

}

Run the suite:

bash

forge test

Always check three things:

1. Execution logic. Do state updates produce the right values?
2. Access boundaries. If a function should be restricted, can an outsider call it? In this example, set is intentionally open to everyone.
3. Edge cases. How does the contract behave with zero, the maximum uint256, or unusual inputs? The fuzz test above covers many such values automatically.

Verifying these 3 aspects is a must when testing smart contracts on ADI Network AB Testnet.

4. Deploy Smart Contract to ADI Network AB Testnet

Once the tests pass, deploy and verify in one command:

bash

forge create src/SimpleStorage.sol:SimpleStorage \

  –rpc-url https://rpc.ab.testnet.adifoundation.ai/ \

  –account adi-deployer \

  –broadcast \

  –constructor-args 50 \

  –verify –verifier blockscout \

  –verifier-url https://explorer-api.ab.testnet.adifoundation.ai/api \

  –chain 99999

The output includes the contract address and the transaction hash. Open the testnet explorer, search for the address, and check the deployment transaction, gas used, and block confirmation. On the Contract tab, you should see the verified source code. Verification requires the exact compiler version, optimizer settings, and constructor arguments used at deployment. Blockscout does not need an API key.

If you only want to deploy, remove the –verify, –verifier, and –verifier-url lines. You can also verify later through the explorer’s Verify & Publish option.

Prefer Hardhat? Hardhat 3 works with a standard network entry and no ZK-specific plugins. Add this to hardhat.config.ts:

typescript

ignition: {

  requiredConfirmations: 1,

},

networks: {

  adiTestnet: {

    type: “http”,

    chainType: “generic”,

    url: “https://rpc.ab.testnet.adifoundation.ai”,

    accounts: [configVariable(“TESTNET_PRIVATE_KEY”)],

  },

},

Save your key to the Hardhat keystore with npx hardhat keystore set TESTNET_PRIVATE_KEY, then deploy your Ignition module:

bash

npx hardhat compile

npx hardhat ignition deploy ignition/modules/SimpleStorage.ts –network adiTestnet

5. Interact with Your Deployed Contract

There are two kinds of calls:

• Read calls (view functions) query a node directly. They send no transaction and cost no gas.
• Write calls change state. They need a signed transaction, are included in a block, and cost ADI.

Replace <CONTRACT_ADDRESS> with your address:

bash

# Read the current value

cast call <CONTRACT_ADDRESS> “get()(uint256)” \

  –rpc-url https://rpc.ab.testnet.adifoundation.ai/

# Update the value

cast send <CONTRACT_ADDRESS> “set(uint256)” 125 \

  –rpc-url https://rpc.ab.testnet.adifoundation.ai/ \

  –account adi-deployer

cast send prints the transaction hash. Open it in the block explorer and check the Logs tab to see the DataUpdated event with the old and new values. Run the read call again to confirm the value is now 125.

6. Deploy Smart Contract to ADI Mainnet

Mainnet uses real assets. Before deploying, go through this checklist:

• Remove debug leftovers. Delete mock logic, test accounts, and development backdoors.
• Protect your keys. Use a hardware wallet or a key management service for deployer keys. Never keep production keys in plaintext files.
• Pin versions. Lock the exact compiler version (for example, solc = “0.8.24” in foundry.toml) instead of floating ranges.
• Use the right network settings. Chain ID 36900, RPC https://rpc.adifoundation.ai/. Confirm them against the official ADI documentation before sending a transaction.
• Expect rate limits. The public mainnet RPC is rate-limited. For production traffic, use a provider such as Alchemy or NowNodes, which the ADI docs list as alternatives.
• Fund the deployer. You need ADI on mainnet. You can bridge ADI and ETH using the official bridge at https://bridge.adifoundation.ai/.
• Estimate costs. Large contracts need more gas to deploy, so check the estimate first.

Verification works differently on mainnet. At the time of writing, verification on the primary explorer (explorer.adifoundation.ai) is marked as broken in the ADI documentation. Use the BLS explorer’s API instead:

bash

forge create src/SimpleStorage.sol:SimpleStorage \

  –rpc-url https://rpc.adifoundation.ai/ \

  –account adi-deployer \

  –broadcast \

  –constructor-args 50 \

  –verify –verifier blockscout \

  –verifier-url https://explorer-bls.adifoundation.ai/api \

  –chain 36900

Check the ADI documentation’s “Verify smart contracts” page for the current status before you deploy, since explorer availability can change.

Smart Contracts on ADI Chain: Next Steps

With your first contract live on-chain, explore more patterns:

• Upgradeable contracts. Use a proxy pattern such as UUPS to change logic while keeping storage.
• Access control. Use OpenZeppelin roles instead of a single owner.
• Account abstraction. ADI supports ERC-4337 smart accounts and paymasters through external infrastructure such as Pimlico. EntryPoint v0.7 and v0.8 are deployed on the network. ADI does not ship an audited default paymaster, so you either integrate an existing stack or deploy and audit your own.
• Frontend. Connect your contract to a React or Vue app with viem or ethers so users can interact through their wallets.
• Security. Run static analysis tools such as Slither and get an external audit before handling significant funds.
• Documentation. See the official ADI documentation at docs.adi.foundation for network details, contract addresses, and updates.

These are the ways you can improve your ADI Chain smart contracts next.

Common ADI Chain Smart Contract Deployment Errors & How to Fix Them

Things go wonky sometimes. When deployments stall, look through these typical pain points:

• Insufficient funds. If the deployer wallet has no ADI, the node rejects the transaction at gas estimation. Request more tokens from the faucet. If the balance is sufficient and estimation still fails, the contract logic is probably reverting.
• Reverts. A transaction reverts when a require or custom error fails. Run the call with cast call or inspect the transaction in the explorer to see the reason.
• Constructor argument mismatch. Passing the wrong number or type of constructor arguments makes deployment fail immediately. Compare –constructor-args with the constructor definition.
• Wrong network or chain ID. If your tool reports a chain ID mismatch, check that the RPC URL and chain ID belong to the same network: 99999 for testnet, 36900 for mainnet.
• Verification fails. Check that the compiler version, optimizer settings, and constructor arguments match the deployment exactly, and that you are using the working explorer API for your network.
• RPC endpoint problems. Public nodes can lag or rate-limit requests. Test the endpoint directly.

Knowing these common errors will help you deploy a smart contract on ADI faster and more efficiently.

Conclusion

You wrote, tested, deployed, and verified a Solidity contract on ADI Network AB Testnet, then read and updated it from the command line and checked the transactions in the block explorer. Because ADI is EVM-compatible, you used standard Ethereum tooling throughout. A natural next step is a more complex contract, such as a token or an escrow.

We at IdeaSoft are official tech partners of ADI Chain. If you need help with your project, feel free to contact us.