How Ethereum Contract Addresses Are Calculated (With Source Code Implementation)

Understanding how Ethereum contract addresses are generated is crucial for developers working with smart contracts, especially when leveraging advanced deployment techniques like CREATE2. This article dives deep into the mechanics behind Ethereum address computation, explains the role of CREATE2, and provides a complete Solidity implementation to demonstrate how deterministic contract addresses can be precomputed before deployment.

Whether you're building decentralized exchanges like Uniswap or designing upgradeable contract systems, knowing how to predict a contract’s address beforehand opens up powerful architectural possibilities.

👉 Discover how blockchain developers use predictable contract addresses to build scalable DeFi applications.

Understanding Ethereum Address Generation

Ethereum uses cryptographic hashing and specific opcodes to determine where a contract will reside on the blockchain. There are two primary methods for deploying contracts: CREATE and CREATE2. Each generates addresses using different formulas.

The Default Method: CREATE

When a contract is deployed using the standard CREATE opcode (via the new keyword or create in inline assembly), the address is calculated based on:

The deployer's address
The nonce of the deployer account at the time of transaction

The formula is:

keccak256(rlp.encode([sender, nonce]))[12:]

This means the address cannot be predicted in advance unless you know exactly how many transactions the sender has executed — which makes it non-deterministic in most real-world scenarios.

The Predictable Alternative: CREATE2

CREATE2 changes the game by allowing developers to compute a contract’s address before deployment. This is essential for use cases such as:

Counterfactual deployments (deploying only if needed)
Smart wallet recovery mechanisms
Pre-addressing liquidity pools, as seen in Uniswap V2

The address is computed using:

keccak256(0xff ++ address ++ salt ++ keccak256(init_code))[12:]

Where:

0xff — A constant prefix to prevent collisions
address — Deployer's address (the factory contract)
salt — A user-defined 32-byte value (can be random or deterministic)
init_code — The creation bytecode of the contract (constructor + code)

Because all these inputs can be known ahead of time, the resulting contract address is fully predictable.

Solidity Implementation: Building a Factory Contract

Below is a complete Solidity example that demonstrates how to calculate and deploy a contract using CREATE2.

pragma solidity ^0.8.0;

contract Factory {
    event Deployed(address addr, uint256 salt);

    // Generate initialization bytecode for TestContract
    function getBytecode(address _owner, uint _foo) public pure returns (bytes memory) {
        bytes memory bytecode = type(TestContract).creationCode;
        return abi.encodePacked(bytecode, abi.encode(_owner, _foo));
    }

    // Compute the future contract address using CREATE2 formula
    function getAddress(bytes memory bytecode, uint256 _salt) public view returns (address) {
        bytes32 hash = keccak256(
            abi.encodePacked(
                bytes1(0xff),
                address(this),
                _salt,
                keccak256(bytecode)
            )
        );
        return address(uint160(uint256(hash)));
    }

    // Deploy the contract via CREATE2
    function deploy(bytes memory bytecode, uint256 _salt) public payable {
        address addr;
        assembly {
            addr := create2(
                callvalue(),
                add(bytecode, 0x20),
                mload(bytecode),
                _salt
            )
        }
        require(addr != address(0), "Deployment failed");
        emit Deployed(addr, _salt);
    }
}

contract TestContract {
    address public owner;
    uint public foo;

    constructor(address _owner, uint _foo) payable {
        owner = _owner;
        foo = _foo;
    }

    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

Step-by-Step Workflow

Get Initialization Bytecode: Call getBytecode(_owner, _foo) to pack constructor arguments with the contract’s creation code.
Calculate Predicted Address: Use getAddress(bytecode, salt) to compute where the contract will be deployed.
Deploy with CREATE2: Execute deploy(bytecode, salt) to instantiate the contract at the precomputed address.

This pattern is widely used in DeFi protocols like Uniswap V2, where the router can compute pair addresses without querying storage — improving gas efficiency and enabling off-chain discovery.

👉 See how leading DeFi platforms leverage deterministic contract deployment for seamless user experiences.

Real-World Use Case: Uniswap V2 Pair Address Prediction

In Uniswap V2, the factory contract uses CREATE2 to ensure that any two-token pair has a unique and predictable address. This allows users and interfaces to:

Compute pool addresses off-chain
Interact directly without calling the factory
Reduce transaction costs and improve UX

For example, given two tokens (tokenA and tokenB), sorted by address, the pair address is computed as:

address pair = factory.pairFor(tokenA, tokenB);

Internally, this uses a constant salt derived from the token pair hash, ensuring idempotent deployments.

Frequently Asked Questions (FAQ)

How does CREATE2 make contract deployment more efficient?

CREATE2 enables off-chain address prediction, meaning dApps can interact with contracts before they exist on-chain. This reduces the need for on-chain lookups, lowers gas costs, and supports counterfactual logic — where actions assume a contract will be deployed only when necessary.

Can I reuse the same salt for multiple deployments?

No. Using the same salt with the same deployer and init code will result in only one successful deployment. Subsequent attempts will fail unless the existing contract is destroyed. Unique salts are required for multiple deployments.

What happens if two different bytecodes produce the same hash?

While theoretically possible, finding two different bytecodes with the same Keccak-256 hash would require a collision attack, which is computationally infeasible with current technology. The security of this mechanism relies on the cryptographic strength of Keccak-256.

Is CREATE2 safe to use in production?

Yes. CREATE2 has been part of Ethereum since the Constantinople hard fork (2019) and is extensively used in production-grade protocols like Uniswap, Gnosis Safe, and EIP-1167 minimal proxies. Always validate inputs and handle deployment failures gracefully.

Why is the 0xff prefix used in the address calculation?

The 0xff prefix prevents potential collisions between addresses generated by CREATE and CREATE2. Since CREATE doesn’t use this prefix, it ensures that no externally owned account or legacy contract can accidentally occupy a CREATE2-derived address.

Can I change the salt after computing the address?

The salt must remain consistent between computation and deployment. Changing it will result in a completely different address. For predictable deployments, both the salt and init code must be identical during calculation and actual deployment.

Conclusion

The ability to compute Ethereum contract addresses before deployment unlocks powerful design patterns in decentralized systems. By leveraging CREATE2, developers gain control over contract placement, enabling innovative solutions in DeFi, identity management, and scalable smart contract architectures.

Understanding this mechanism isn’t just theoretical — it’s foundational for building next-generation blockchain applications.

👉 Explore developer tools that simplify contract deployment and blockchain interaction.