RIP-7875: Canonical ERC-7802 token bridge address

Standardize the ERC-7802 token bridge address on rollups that support it natively

Metadata

Status: DraftStandards Track: CoreCreated: 2025-02-09

Authors

Yoav Weiss (@yoavw), skeletor (@skeletor-spaceman)

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This proposal sets a standard address for the ERC-7802 token bridge address trusted by ERC-20 tokens that support ERC-7802 Crosschain minting/burning

Motivation

Permisionless cross-ecosystem same-address ERC20s

ERC-7802 is a minimal interface for crosschain minting/burning of ERC-20 tokens. The token is requires to trust a bridge address and allow it to call crosschainMint/crosschainBurn. The bridge address would typically be immutable and affect the token's address as determined by CREATE2.

EIP-7587 reserved a range for standardized precompiles/predeploys used by rollups. The proposal makes use of this range to reserve the token bridge address.

By standardizing the bridge address we gain two advantages:

Tokens can be deployed in a future-proof manner on every chain. If/when a rollup adds native ERC-7802 capability to their canonical bridge, existing immutable tokens can benefit from the improved interoperability even though they were deployed earlier.
Tokens can deploy to the same CREATE2 address if they wish. Having the same bridge address means they don't need to pass a different argument during deployment.

Shared security across rollup clusters

Standardizing TOKEN_BRIDGE_ADDRESS creates a simpler and more predictable cross-rollup experience:

One trusted address: Developers only need to work with one bridge address across rollups, making both on-chain and off-chain devx easier.
Future-proof deployments: Tokens can be deployed once and remain compatible as more rollups adopt the standard, without needing upgrades or redeployments.
Cross-chain composability: Tokens, deployable at the same CREATE2 address, work across rollups automatically, reducing custom bridge logic and deployment overhead.

By keeping things simple, scalable, and standardized, this approach makes cross-rollup token interactions more efficient for both developers and users.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

As of FORK_TIMESTAMP in the integrated EVM chain, add precompiled/predeployed contract which acts as an ERC-7802 token bridge at address TOKEN_BRIDGE_ADDRESS in 0x1ff (indicates 0x00000000000000000000000000000000000001ff).

The implementation is outside the scope of this proposal but it MUST implement a secure ERC-7802 bridge in TOKEN_BRIDGE_ADDRESS or not have anything in that address.

The rollup MAY implement a token bridge at another address in addition to TOKEN_BRIDGE_ADDRESS but MUST not deploy something other than a secure ERC-7802 bridge to TOKEN_BRIDGE_ADDRESS.

Constants

Name	Value
TOKEN_BRIDGE_ADDRESS	`0x00000000000000000000000000000000000001ff`

Rationale

The TOKEN_BRIDGE_ADDRESS is chosen as 0x1ff because it is an available address for precompile RIPs as defined in EIP-7587.

The implementation is deliberately out of scope because each rollup may choose different bridging methods, whether it's between L1 and L2, or across L2s within a cluster.

Rollups do not trust each other unless such trust has been established explicitly. Therefore tokens can safely trust TOKEN_BRIDGE_ADDRESS within each rollup.

Backwards Compatibility

No backward compatibility issues because TOKEN_BRIDGE_ADDRESS is currently empty in all rollups and shall remain so until standardized by a RIP, as per EIP-7587.

Security Considerations

The only trust assumption introduced by this proposal is that TOKEN_BRIDGE_ADDRESS will not contain a malicious implementation of an ERC-7802 bridge. This is no different from the trust assumption introduced by any other precompile address, e.g. that the ECRECOVER precompile at address 0x01 will not be backdoored.

No crosschain trust assumptions are made. Each rollup SHALL determine its trust model and decide whether it only trusts its own L1 canonical bridge or establishes trust relations with other rollups. Such trust relations should only be considered between rollups that share a trust model and can verify each other's soundness and finality.