How Deposit Addresses Work on EVM
The new Deposit Addresses feature in Allbridge Core is in the final testing stages. While we prepare for release, let’s take a closer look at how Deposit Addresses are designed and implemented on EVM blockchains.
This article continues the introduction available in the earlier post about Deposit Addresses.
The technical details differ across blockchains, as each chain has its own rules and behaviour. Here, we focus specifically on EVM chains such as Ethereum, BNB Chain, and Polygon.
Accounts vs. Contracts
On EVM blockchains, both accounts and smart contracts share the same address format, so it is impossible to tell them apart just by looking at an address. Their internal logic is different, though.
Regular accounts are controlled by private keys, just like your wallet. Whoever holds the private key can directly manage the funds. Smart contracts work differently: they do not have private keys, and any actions involving their balance are defined strictly by the contract’s code. 
Deposit addresses on centralized exchanges are usually regular accounts. The exchange holds the private keys and acts as the custodian of the funds, which introduces a trust element and various regulatory requirements.
Allbridge Core aims for a trustless model, so using regular accounts is not an option. Deposit Addresses must be implemented with smart contracts. The question then becomes how to create contract addresses in a way that reliably links each address to the correct user.
Contract Addresses
If regular accounts derive their address from a public key, how are smart contract addresses formed?
Originally, Ethereum (and other EVM chains) deployed contracts using the CREATE opcode. Under CREATE, the resulting contract address depends only on the deployer’s address and the deployer’s nonce (the number of successful transactions previously made by that address). This guarantees uniqueness within a chain, since a deployer cannot produce two transactions with the same nonce. The addresses look random and are unrelated to the code being deployed. 
A small fun fact: while contract addresses are unique within a single chain, it is entirely possible to deploy contracts with the same address on different EVM chains. You only need the same deployer address and the same nonce at the moment of deployment.
Deterministic Addresses
Some use cases require knowing the contract address beforehand and avoiding any dependency on the deployer’s transaction history. The Deposits Addresses feature in Allbridge Core is one of those cases.
To address this, Ethereum introduced the CREATE2 opcode in the Constantinople update in 2019. With CREATE2, the contract address still depends on the deployer, but instead of the nonce it uses:
- the contract’s initialization code
- an arbitrary salt, provided during deployment 
If the deployer, initialization parameters, and salt remain the same, the resulting address will always be the same. This makes CREATE2 ideal for situations where the contract address must be known in advance.
Allbridge Core Implementation
When you create a Deposit Address through the Allbridge Core UI, you provide:
- the destination blockchain and destination address
- the token you want to receive
- the minimum balance you want to auto-bridge from other chains 
This information forms the salt used for CREATE2.
The deployer address is fixed as the factory contract on each chain you want to bridge from. The initialization parameters are empty because we use a contract-cloning architecture to reduce gas usage. Since all components are known in advance, the resulting Deposit Address can be calculated without deploying anything yet. For that reason, a freshly generated Deposit Address has no on-chain history and you will not see any transactions for it until it is actually used. 
When tokens arrive at a Deposit Address, our indexer monitors the transaction. If the final balance passes the minimum threshold, the factory contract is triggered. No special authority is required for this call, it follows normal trustless contract interaction rules.
If the Deposit Address has no contract deployed yet, the factory deploys it using CREATE2. Because the address is predetermined, the only valid contract that can be created there is the one matching the correct user configuration. 
Once the contract exists and the deposit is registered, bridging is initiated using the destination chain and address encoded in the configuration. All calls remain trustless, and the funds always end up at the predefined address.
Outro
Deposit Addresses bring a more convenient and predictable way to interact with Allbridge Core. On EVM chains, making this work required deterministic deployment, a clone-factory design, and the ability to compute addresses before anything is deployed. The result is a trustless, user-linked contract address that triggers bridging automatically as soon as the conditions are met.
This architecture keeps Deposit Addresses simple to use while maintaining the security model at the core of Allbridge Core.
