WETH and Multicall3 are also OP Stack predeploys/preinstalls — they are listed under Core above. For full details, see the OP Stack predeploys documentation.

OP Stack Preinstalls

These contracts come preinstalled on OP Stack chains at their standard addresses. The addresses are the same on both MegaETH Mainnet and Testnet.

Contract

Address

Description

Safe

0x69f4D1788e39c87893C980c06EdF4b7f686e2938

Gnosis Safe multisig wallet.

SafeL2

0xfb1bffC9d739B8D520DaF37dF666da4C687191EA

Gnosis Safe optimized for L2.

MultiSend

0x998739BFdAAdde7C933B942a68053933098f9EDa

Batch multiple Safe transactions.

MultiSendCallOnly

0xA1dabEF33b3B82c7814B6D82A79e50F4AC44102B

Batch multiple read-only calls via Safe.

Safe Singleton Factory

0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7

Deterministic deployment for Safe contracts.

create2Deployer

0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2

Deploy contracts to deterministic addresses.

CreateX

0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed

Advanced deterministic contract deployment.

Deterministic Deployment Proxy

0x4e59b44847b379578588920cA78FbF26c0B4956C

Arachnid's CREATE2 factory.

Permit2

0x000000000022D473030F116dDEE9F6B43aC78BA3

Uniswap's universal token approval contract.

ERC-4337 EntryPoint v0.6

0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

Account abstraction entry point (v0.6).

ERC-4337 SenderCreator v0.6

0x7fc98430eAEdbb6070B35B39D798725049088348

Creates sender contracts for ERC-4337 v0.6.

ERC-4337 EntryPoint v0.7

0x0000000071727De22E5E9d8BAf0edAc6f37da032

Account abstraction entry point (v0.7).

ERC-4337 SenderCreator v0.7

0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C

Creates sender contracts for ERC-4337 v0.7.

For full details, see the OP Stack preinstalls documentation.

L1 Contracts (Ethereum)

Name

Address

Notes

L1StandardBridgeProxy (Canonical Bridge)

0x0CA3A2FBC3D770b578223FBB6b062fa875a2eE75

Send ETH here to bridge from Ethereum to MegaETH

OptimismPortalProxy

0x7f82f57F0Dd546519324392e408b01fcC7D709e8

Entry point for deposits and withdrawals

DisputeGameFactoryProxy

0x8546840adf796875cd9aacc5b3b048f6b2c9d563

Creates dispute games for fault proofs

SystemConfigProxy

0x1ED92E1bc9A2735216540EDdD0191144681cb77E

On-chain system configuration

L1CrossDomainMessengerProxy

0x6C7198250087B29A8040eC63903Bc130f4831Cc9

Cross-domain message passing

L1ERC721BridgeProxy

0x3D8ee269F87A7f3F0590c5C0d825FFF06212A242

Bridge ERC-721 tokens between L1 and L2

OptimismMintableERC20FactoryProxy

0xF875030B9464001fC0f964E47546b0AFEEbD7C61

Create bridgeable ERC-20 tokens on L1

SuperchainConfigProxy

0x5d0ff601bc8580d8682c0462df55343cb0b99285

Superchain-wide configuration

ProtocolVersionsProxy

0x150355311f965af4937fcca526f9df0573fd5b85

Protocol version tracking

USDM

0xEc2AF1C8B110a61fD9C3Fa6a554a031Ca9943926

MegaETH's L1 contracts are from OP Stack's op-contracts/v3.0.0 release. See OP Stack docs for descriptions of these contracts.

Adding a Token to the Registry

To get your token listed, submit a pull request to the mega-tokenlist repository.

Create a token folder

Create data/YOUR_TOKEN/ in the repository.

Add token metadata

Create a data.json file with your token's name, symbol, decimals, root-level verification, and per-chain addresses. The generator rejects records with missing verification or a mismatched status and method.

Choose the verification pair that describes the submission:

Status

Required method

When to request it

issuer

source-submission

The issuer or its official organization supplied or approved the token relationship; include supporting evidence in the PR

community

maintainer-review

A community asset submitted for maintainer review; default for new permissionless factory submissions

infrastructure

official-infrastructure

Official MegaETH protocol infrastructure

The submitter proposes the verification level. Merging the PR is the registry maintainer's attestation that the selected level satisfies registry policy.

This illustrative native-token template requests community verification. Replace the placeholder addresses and metadata in these templates with your token's deployed values, and select the appropriate verification pair before submitting.

{
  "name": "My Token",
  "symbol": "MTK",
  "decimals": 18,
  "verification": {
    "status": "community",
    "method": "maintainer-review"
  },
  "tokens": {
    "megaeth": {
      "address": "0xYourTokenAddress",
      "isOrigin": true,
      "mechanism": "native"
    }
  }
}

For a token locked on Ethereum and minted on MegaETH, include both chains as in this illustrative template:

{
  "name": "My Token",
  "symbol": "MTK",
  "decimals": 18,
  "verification": {
    "status": "community",
    "method": "maintainer-review"
  },
  "tokens": {
    "ethereum": {
      "address": "0xEthereumAddress",
      "isOrigin": true,
      "mechanism": "lock",
      "bridge": "0xBridgeOrLockboxAddress"
    },
    "megaeth": {
      "address": "0xMegaETHAddress",
      "isOrigin": false,
      "mechanism": "mint",
      "bridge": "0xMintEndpointAddress"
    }
  }
}

For a MegaETH Testnet deployment, use tokens.megaeth_testnet with that deployment's address and origin/mechanism fields. Use the same root-level verification requirements for testnet submissions. The registry generates separate lists:

Chain keys

Generated output

ethereum, megaeth

megaeth.tokenlist.json (mainnet)

megaeth_testnet

megaeth.testnet.tokenlist.json (testnet only)

Add a logo

Add a logo.svg or logo.png (256×256 recommended) to the same folder.

Submit a PR

Open a pull request using the token submission template. Specify the proposed verification status and matching method, and link to the official source, discussion, or documentation supporting the request when applicable. Only request issuer verification with evidence of issuer or official-organization submission or approval.

For routine token submissions, change only metadata and logos under data/, following the registry contribution guidelines. Do not commit changes to the generated tokenlists. After maintainer review and merge, the generation workflow publishes the token to the appropriate list.

EVM addresses must be checksummed (EIP-55). For the full data schema and bridge mechanism types (native, lock, mint, burn), see the mega-tokenlist README.

Reading verification and source relationships

In generated tokenlists, extensions.verification contains the approved root-level verification object. For non-origin entries with a recorded origin/source, the generator also emits:

Field

Meaning

extensions.sourceChain

Source chain key, such as ethereum or solana

extensions.sourceAddress

Token address on that source chain

These are generated fields derived from the per-chain entries in data.json, not additional submission fields. They cover EVM sources as well as non-EVM sources. A solana entry provides source tracking only and is not emitted as a standalone tokenlist entry.

For the bridged template above, the MegaETH entry's source is ethereum and its source address is the value of tokens.ethereum.address. The source address identifies the token, not the bridge or lockbox contract. Use the source chain and token address together for exact relationship matching rather than inferring a relationship from names or symbols. These fields can be absent when no origin/source is recorded; do not assume every non-origin entry has them.

PreviousSend Transaction

NextGas Estimation

Last updated 20 days ago