To boost node performance, operational stability and client ecosystem diversity across Gate Layer, we will smoothly migrate all network-wide execution clients from Geth to Reth.
Reth is a high-performance Ethereum execution client built in Rust. It supports the execution layer operating mode for OP Stack chains and interoperates with op-node via the Engine API.
This upgrade only affects node infrastructure. It will not alter Gate Layer's chain ID, account system, contract addresses, transaction formats, RPC API compatibility, or on-chain asset states. Users and dApp developers do not need to migrate assets or redeploy smart contracts.
Chain ID, block explorer data, contract addresses and historical states will remain unchanged;
All standard JSON-RPC methods remain compatible, including commonly used interfaces such as eth_sendRawTransaction, eth_call, eth_getLogs, eth_getBlockByNumber;
Temporary RPC fluctuations, delayed transaction confirmations or WebSocket reconnections may occur during the maintenance window;
Self-hosted node operators: Follow the operation guide in this announcement to switch your execution client to Reth;
Users relying on official RPC endpoints: No modifications to business code are required. We recommend implementing transaction retry logic and RPC health checks before and after the upgrade window.
Exact switch time: July 14, 2026, 03:00 (UTC)
Maintenance window: July 14, 2026, 03:00–04:00 (UTC)
Some nodes or RPC services may be temporarily unavailable during the maintenance window, which may lead to failed transactions, delayed on-chain confirmation and abnormal state queries;
Users and project teams are advised to avoid transfers, contract interactions and large-value asset operations within the window;
Do not submit transactions or resume automated business workflows until the window closes, RPC services return to stable status and node synchronization completes normally.
Gate Layer will adopt a blue-green deployment strategy to ensure network stability and enable emergency rollbacks: The existing op-node + Geth stack will continue handling production traffic, while op-reth paired with a shadow op-node will run in parallel to sync blocks and conduct validation. Once Reth nodes fully catch up and pass consistency checks covering RPC responses, transaction execution, block heights, and event logs, we will switch sequencer and RPC production traffic during the maintenance window. Geth data and services will be retained as rollback backups until the post-upgrade observation period concludes.
If you only utilize official RPC endpoints: Ensure your application supports RPC timeout retries, automatic WebSocket reconnection and transaction status polling mechanisms;
If you operate self-hosted RPC nodes:
Deploy Reth nodes and complete full synchronization via snapshots in advance. Do not start node synchronization from scratch during the maintenance window;
Do not delete the Geth datadir throughout the entire switch process and before the observation period ends;
Clear legacy Geth data only after full network stability is confirmed and the observation period has ended.
Do users need to migrate their assets?
No. This upgrade only replaces the execution client, and it is not a chain swap, state reset or contract migration.
Will contract addresses change?
No. Contract addresses are determined by chain state, and swapping the execution client will not modify existing on-chain states.
Are modifications required for RPC integration code?
Standard JSON-RPC calls generally require no code changes. We recommend applications implement timeout retries, idempotent transaction submission, automatic WebSocket reconnection and receipt polling logic.
Can I delete Geth data immediately after the switch?
We do not recommend this. Keep the data intact until the post-switch observation period ends, and only clean it up after confirming stable Reth production operation with no further rollback needs.
Can Reth reuse the Geth datadir directory?
No. Reth and Geth adopt incompatible database formats. You must use a separate datadir for Reth and perform full synchronization or import a dedicated snapshot.
Are Reth P2P peers identical to op-node P2P peers?
No. The enode addresses of Reth/Geth belong to execution-layer P2P, while op-node peer IDs run on libp2p. Tracking OP Stack unsafe payloads relies entirely on op-node P2P connections; adding execution-layer peers to Reth alone cannot achieve full block sync.
This client upgrade will further enhance cross-network node performance and stability for Gate Layer, consolidating Gate Layer 2's core advantages of low latency and seamless transaction execution.
For more Gate Layer technical documentation and ecosystem updates, visit Gate's official website and developer community.
Click to access Gate Layer Technical Documentation
Gate Team
July 13, 2026
Gateway to Crypto
Trade over 4,700 cryptocurrencies safely, quickly, and easily on Gate
Take Action Now
Sign up and claim up to $10,000 in welcome rewards
Invite friends and earn a 40% commission
Stay Connected
Visit Gate's official website
Download the Gate App | Desktop
Follow us on X (Twitter) to get more bonuses
Join our Telegram community to discuss trending topics
Engage with our global community for the latest insights
Transparency & Security
Check our 100% Proof of Reserves
Share Posts


Related Articles