Predeployed Contracts

Some contracts are present on SupraEVM from its first block, placed there by SupraEVM’s genesis rather than deployed by anyone. This page lists the ones a developer calls: five third-party contracts that hold the same address on every EVM network that deploys them, and Wrapped SUPRA, the ERC-20 form of the native currency. It then names the system contracts genesis also deploys.

These are ordinary contract accounts. They are not precompiles, they are outside the reserved range described in SupraEVM Precompiles, and they execute as any deployed contract does.

Third-party contracts

The first is the CREATE2 factory Foundry deploys through by default, and the one hardhat-deploy uses in its deterministic mode. The ERC-2470 SingletonFactory and CreateX are the other two general CREATE2 factories in common use. Multicall3 is what wallets, indexers and frontends batch eth_call through. The ERC-1820 registry is what ERC-777 requires.

Addresses and bytecode match other networks

Each contract is deployed here from the same deployer address and nonce as its canonical deployment elsewhere, using the init code of that deployment byte for byte. The address a CREATE produces depends on nothing but the deployer and the nonce, so each contract lands where it does on every other chain, and the code stored there is the code that deployment produced.

Two things follow. A contract deployed through one of the CREATE2 factories gets the same address here as it would on any other network, because the factory’s address and its behaviour are the same. And a script that looks for one of these contracts before using it — forge script checking for the CREATE2 factory, hardhat-deploy checking the same address — finds the code and proceeds.

The init code is taken from each project’s own published deployment rather than compiled from source. A difference in compiler version, optimizer settings or metadata would produce bytecode that is not what the same address holds elsewhere.

Why they are placed at genesis

Each of these contracts is distributed as a single fixed, signed transaction that declares no chain id, so that anyone can submit it to a new network and reproduce the address. Supra refuses a transaction that declares no chain id: such a transaction is valid on every network at once, so the identical bytes replay anywhere the sender holds funds. The rule and its reasoning are in Gas and Fees.

That leaves genesis as the only route by which these contracts can reach the chain, and it is the route the chain takes. The deployment scripts that would otherwise submit the bootstrap transaction find the code already in place and skip that step.

A contract of your own is unaffected by this. An ordinary deployment declares the chain id, as every current library does by default.

Wrapped SUPRA (WSUPRA)

Wrapped SUPRA is an ERC-20 token backed one to one by native SUPRA, as WETH is by ether. Sending native SUPRA to it mints the same amount of WSUPRA to the sender; burning WSUPRA returns the same amount of native SUPRA. A contract that takes ERC-20 tokens but not native value — a DEX pool, a lending market, an escrow — takes SUPRA in this form.

The interface is ERC-20 plus two functions:

• deposit() — payable. Mints msg.value WSUPRA to the caller and emits Deposit(address indexed from, uint256 amount). A plain transfer of native SUPRA to the contract with no call data does the same.
• withdraw(uint256 amount) — burns amount WSUPRA from the caller, emits Withdrawal(address indexed to, uint256 amount), then sends amount of native SUPRA to the caller.

The contract is built on OpenZeppelin’s ERC20 and ERC20Permit, so it also implements EIP-2612 permit, with the EIP-712 domain name Wrapped Supra and version 1. It has no owner, no account that can mint other than through deposit, and no proxy: its code cannot be changed.

Code written against WETH9 works with it, with these differences:

• deposit with no value and withdraw(0) revert with InvalidAmount(). WETH9 accepts both.
• A call carrying call data that matches no function reverts. WETH9’s fallback treats any such call as a deposit; here only a transfer with empty call data does.
• withdraw sends the native SUPRA with all remaining gas, and reverts if the recipient’s code reverts. WETH9 uses transfer, which forwards 2,300 gas.
• transferFrom(from, …) with from equal to the caller spends the caller’s allowance for itself, as OpenZeppelin’s ERC20 does for every transferFrom. WETH9 skips the allowance in that case.
• Reverts use custom errors — InvalidAmount(), and OpenZeppelin’s ERC20InsufficientBalance, ERC20InsufficientAllowance and the like — rather than WETH9’s bare require.

The Deposit and Withdrawal events have the same signatures as WETH9’s, so an indexer matching WETH9’s event topics matches these.

Native SUPRA reaches SupraEVM by crossing from SupraMVM; see Funding an account.

Finding the address

Wrapped SUPRA and the system contracts below are deployed at genesis from the VM signer address, 0x0000000000000000000000000000000053555000 (see SupraEVM Precompiles), in a fixed order. Each one’s address is therefore fixed by the position of its deployment in that order, and is the same on every network whose EVM genesis deploys the same set of contracts in the same order. It is not fixed across node releases: a release that adds or removes a genesis contract ahead of another one moves that one’s address.

The chain records the address of every genesis contract in the 0x1::evm_config::EvmContractsDetails resource. Read it through the REST API:

curl -s 'https://rpc-devnet.supra.com/rpc/v4/accounts/0x1/resources/0x1%3A%3Aevm_config%3A%3AEvmContractsDetails' \
  | jq '.data.details.data'

The result is a list of key/value pairs, one per contract. Wrapped SUPRA’s key is WrappedSupra; the five third-party contracts are listed as well, under Create2Factory, Multicall3, SingletonFactory, CreateX and Erc1820Registry. Each value is the EVM address written as a Move address, with leading zero digits omitted: left-pad the hex digits after 0x with zeros to 40 to read it as an EVM address.

Addresses on Devnet

Read from Devnet’s EvmContractsDetails on 2026-10-12. A Devnet reset deploys the same contracts in the same order, so these addresses hold until a node release changes the genesis set; the resource is authoritative.

System contracts

Genesis also deploys contracts that the chain itself calls. Each is listed in the resource above under the key given here.

• BlockMetadata (implementation BlockMetadataImpl) — the contract the block-metadata transaction at the start of every block calls; see System pseudo-transactions. Its interface is documented in BlockMeta.
• FoundationWallet (implementation MultisigWalletImpl, beacon MultisigBeacon) — a multisig wallet that owns the upgradeable system contracts. Its interface is documented in MultiSignatureWallet.
• AutomationRegistry (with DiamondCutFacet, DiamondLoupeFacet, OwnershipFacet, ConfigFacet, RegistryFacet, RegistryViewFacet, CoreFacet and DiamondInit) — the EVM automation registry, deployed at genesis. Its interface is documented in AutomationRegistry.

The node’s EVM genesis configuration builder adds a test contract at 0xBd770416a3345F91E4B34576cb804a576fa48EB1, used by Supra’s own tests, to the genesis of every chain it builds, not only Devnet’s. It is not listed in the resource and is not part of the chain’s interface.