When self-hosting an OKX X Layer node, the only officially supported path for now is running an RPC node, not a validator or sequencer node. OKX provides the xlayer-toolkit one-click deployment script, which uses the reth client with snapshot sync by default to spin up a usable RPC endpoint in a short time. But for the three key parts of sync, monitoring and operations, official documentation only covers the basics to get the node running. You need to figure out historical data gaps on chain, client fork boundaries and proper monitoring targets before deployment.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
First confirm what type of node you need to build
X Layer is an OP Stack based Layer 2, and its node types are at least divided into RPC nodes and sequencer/validator nodes. Public OKX tools and documentation only cover RPC node deployment. The RPC Setup module of xlayer-toolkit is positioned as a "self-hosted RPC node solution", and supports two execution clients: geth and reth. Sequencer node setup is not included in publicly available official toolchain descriptions. If you need to participate in block production or consensus layer operations, current public materials are not sufficient to support your operation.
So all the sync, monitoring and operations content below targets RPC nodes. The judgment criteria is: your goal is to provide a controlled JSON-RPC endpoint for dApps, indexers or your own query services, not to participate in X Layer block production.
Sync: Start with snapshots, and clarify where the historical data gap lies
The interactive mode of the one-click script will let you choose a sync method: snapshot sync or genesis block sync. Both methods are supported on mainnet, while testnet only supports snapshot sync. Snapshot sync uses pre-built data packages to skip the long full sync process from scratch, which is a more practical choice. Genesis block sync is only considered when you have specific historical data needs and are willing to wait for a long time.
But there is a more critical fact than choosing a sync method: X Layer completed a re-genesis at block 42,810,021, when the chain migrated from Polygon zkEVM to OP Stack. Historical data before the migration is not stored locally on new reth nodes, but is held by old legacy nodes. X Layer's reth implementation adds a transparent routing layer: RPC requests targeting blocks below the migration height will be automatically forwarded to old legacy nodes, and eth_getLogs queries that cross the migration height will be split into two sub-requests, which are sent to the new and old nodes respectively before merging the results.
This means your self-hosted node is fully complete for data above the migration height, but data below the migration height depends on the old node routing maintained by OKX. If your application needs to frequently query the historical state before migration, this dependency is a single point you need to take into account. The official RPC Setup documentation does not clearly state whether the one-click script of xlayer-toolkit automatically configures this routing. After deployment, you need to test eth_getBlockByNumber with a pre-migration block number to confirm it does not return an empty result.
If you use Flashblocks (pre-confirmation block stream), the execution client must be reth, geth will not work. Regular RPC nodes support both geth and reth, but if you plan to connect to the Flashblocks WebSocket (wss://xlayerws.okx.com/flashblocks) later, choosing reth from the start saves you the trouble of client migration later.
Monitoring: No official dashboard, track three core indicators
OKX's RPC Setup documentation does not provide a monitoring solution, and the README of xlayer-toolkit only writes basic service management commands such as make status and docker compose logs -f. You need to build your own monitoring after the node runs.
The three most direct verification points:
Sync progress. Use eth_syncing or eth_blockNumber to compare the return value of a public RPC (such as https://rpc.xlayer.tech). If your local eth_blockNumber keeps lagging behind the public endpoint, it means the sync is not keeping up. If eth_syncing returns false, it means the node considers itself synced, but you'd better cross-verify with block numbers, don't just trust this boolean value.
Service health. make status can check the container status, but a running container does not mean the RPC is responding correctly. Use a simple eth_blockNumber curl request to regularly probe your HTTP endpoint (default http://localhost:8545), which is more reliable than only checking the container status. If it returns an error or timeout, check the logs to locate whether the problem comes from the execution client or the op-node.
Disk usage. The disk usage of OP Stack nodes keeps growing continuously. Reth's MDBX storage has better disk efficiency than geth, but archived data will still accumulate. The hardware recommendation of xlayer-toolkit starts at 100GB SSD, and 500GB or more is recommended. If your node only serves recent data queries, you can configure pruning; if you need archive queries, disk consumption will be much higher. Your monitoring needs to cover the growth trend of disk usage, and expand storage before the disk is full.
Operations: Beyond basic service management, pay attention to the client fork boundary
Basic operation commands are clear: make status to check status, make stop to stop the service (retain data), make run to restart, docker compose logs -f to view logs. The advantage of Docker deployment is that upgrades and rollbacks are relatively controllable, but the upgrade path of xlayer-toolkit needs to follow the updates of its GitHub repository, and there is no automatic upgrade mechanism.
An easily overlooked operation detail is the match between client type and block height. According to QuickNode's documentation, X Layer used different node clients before and after re-genesis: blocks at and before the migration height require cdk-Erigon nodes, and blocks after migration require Geth nodes. Erigon nodes will return null when querying post-migration transactions, and Geth nodes will also return null when querying pre-migration historical transactions. X Layer's own reth implementation solves this problem through transparent routing, but if you do not use the official toolkit and build geth or erigon by yourself, this fork boundary will directly affect your query results. In the case of deploying a reth node with the official toolkit, the routing layer is built-in, but you should still run a test query for blocks before and after the migration to confirm the behavior meets expectations.
Judgments worth making before deployment
If you only need a reliable X Layer RPC endpoint to run dApps or indexers, the official one-click script + snapshot sync + reth client is the most hassle-free combination at present. The tradeoffs are less control over underlying configurations, and no local autonomy for pre-migration historical data (you rely on transparent routing). Prepare hardware with 16GB RAM and 500GB SSD to leave enough margin for disk growth.
If you need archive-level historical data integrity, or want to run a sequencer node, current public OKX documentation and toolchains can not provide actionable steps. Do not piece together the deployment process from scattered third-party descriptions, narrow your requirements to running an RPC node first, or wait for the official to supplement the sequencer documentation before you start.
After deployment, send an eth_blockNumber request to your local http://localhost:8545 via curl, then send the same request to the public endpoint https://rpc.xlayer.tech. If the two block numbers are close (the gap is within the normal block production interval), it means your node has connected to the network and is tracking the latest state. This check is more meaningful than only viewing the container status.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- OKX Wallet · Node Providers | Flashblocks | Build on X Layer, page update date not specified; Verification date: 2026-10-19.
- OKX Wallet · One-click Setup | Setup RPC | Build on X Layer, page update date not specified; Verification date: 2026-10-19.
- GitHub · okx/xlayer-toolkit, page publish date: 2026-09-09; Verification date: 2026-10-19.
- OKX · Migrate from geth to reth: The evolution of X Layer execution clients, page update date: 2026-06-02; Verification date: 2026-10-19.
- GitHub · xlayer-toolkit/rpc-setup/README.md, page update date not specified; Verification date: 2026-10-19.
- QuickNode · X Layer API Overview, page update date: 2026-04-29; Verification date: 2026-10-19.
