Immutable zkEVM
Badges
About
Immutable zkEVM is a sidechain focused on gaming and powered by Polygon stack. It plans to eventually transition to a ZK Rollup.
Badges
About
Immutable zkEVM is a sidechain focused on gaming and powered by Polygon stack. It plans to eventually transition to a ZK Rollup.
Why is the project listed in others?
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
Funds can be stolen if
- validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum,
- validators relay a withdraw request that wasn't originated on the source chain,
- a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
Users can be censored if
Sequencer failure
No mechanismThere is no mechanism to have transactions be included if the sequencer is down or censoring.
State validation
NoneCurrently the system permits invalid state roots. More details in project overview.
Data availability
ExternalProof construction and state derivation rely fully on data that is NOT published onchain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
No state validation
Immutable zkEVM bridge makes use of Axelar network (a Cosmos chain) to transfer assets between Ethereum and Immutable zkEVM. As in any standard Cosmos chain, validators are bonded by staking tokens and can be slashed by social consensus for misbehaviour.
A deposit starts by a user depositing tokens on the Bridge contract and then the tokens are minted on the destination chain.
Withdrawals to Ethereum can be delayed by a predefined time with a flow rate mechanism that controls outflows of the bridge escrow. The ProxyAdmin or an address with the rate_control role can define so-called buckets for each token: Each bucket has a capacity and a refill rate. All withdrawals that exceed the tokens bucket capacity trigger the withdrawal queue, which delays subsequent withdrawals of any of the bridges’ assets for a time defined in withdrawalDelay (currently 1d).
Users can be censored if validators on Axelar decide to not mint tokens after observing an event on Ethereum.
Funds can be stolen if validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum.
Funds can be stolen if validators relay a withdraw request that wasn't originated on the source chain.
The system uses the following set of permissioned addresses:
A Gnosis Safe with 4 / 6 threshold. Multisig controlling the ProxyAdmin, potentially stealing all locked funds.
Used in:
Contract allowed to upgrade the Bridge, its flow rate control and the Axelar adaptor.
The system consists of the following smart contracts on the host chain (Ethereum):
Main escrow for tokens. This contract stores the following tokens: IMX, USDC, ETH, USDT, GOG.
Upgrade delay: No delay
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).