# How Snap Sync Works in Base and How to Enable It > Discover how Snap Sync in Base dramatically cuts down sync time by downloading compressed state snapshots. Learn to enable this experimental Geth sync mode easily. - Repository: [Base/node](https://github.com/base/node) - Tags: how-to-guide - Published: 2026-03-03 --- **Snap Sync is an experimental Geth synchronization mode in Base that downloads a compressed state snapshot instead of replaying every historical block, drastically reducing sync time when enabled by setting `OP_GETH_SYNCMODE=snap` in your environment file.** Base nodes run the **Geth** execution client, which supports multiple synchronization strategies for joining the network. While the default configuration performs a full sync by replaying every block from genesis, operators can optionally enable **Snap Sync** to initialize their node from a recent state snapshot. This guide explains the technical implementation of Snap Sync in the `base/node` repository and provides exact configuration steps to activate it. ## What Is Snap Sync in Base? Snap Sync is an alternative synchronization strategy available in the Geth client that Base utilizes. Instead of processing every transaction from the genesis block forward, the node downloads a **compressed state snapshot** representing the current world state. This allows the node to become operational in hours rather than days. ### How Snap Sync Differs from Full Sync The default Base node configuration uses `full` sync mode. In this mode, Geth re-executes every block since genesis to verify the entire chain history. While this provides maximum verification, it requires significant time and computational resources. Snap Sync bypasses historical replay by downloading the state trie directly. According to the source implementation in `base/node`, when `OP_GETH_SYNCMODE` is set to `snap`, the entrypoint script passes this value to Geth's `--syncmode` flag at line 74 of `geth/geth-entrypoint`: ```bash --syncmode="$OP_GETH_SYNCMODE" # defaults to "full" ``` ### The Experimental Nature of Snap Sync Snap Sync remains marked as **experimental** in the Base documentation. During synchronization, if the node encounters missing state pieces, it may fall back to fast-sync mechanisms to fill gaps. This hybrid behavior means stability is not guaranteed for production workloads requiring absolute consistency. ## How to Enable Snap Sync in Base Enabling Snap Sync requires modifying your environment configuration and restarting the node. The process takes less than five minutes but requires a node restart. ### Step 1: Configure the Environment Variable Locate your environment file. For mainnet nodes, edit `.env.mainnet`; for Sepolia testnet nodes, edit `.env.sepolia`. Find the commented section around lines 91–96 in `.env.mainnet`: ```dotenv # SNAP SYNC (OPTIONAL EXPERIMENTAL FEATURE - UNCOMMENT TO ENABLE) # OP_GETH_SYNCMODE=snap ``` Uncomment the variable by removing the `#`: ```dotenv OP_GETH_SYNCMODE=snap ``` Save the file. The `geth/geth-entrypoint` script will read this variable and append `--syncmode=snap` to the Geth startup command. ### Step 2: Adjust Snapshot Cache Settings (Optional) Snap Sync utilizes Geth's cache-snapshot layer for state management. The default configuration allocates **24 MiB** for snapshot caching via the `GETH_CACHE_SNAPSHOT` variable defined in the entrypoint. If your hardware has additional RAM available, you can increase this value in your environment file: ```dotenv GETH_CACHE_SNAPSHOT=512 ``` Higher values improve snapshot processing speed during the initial sync phase. ### Step 3: Restart the Node Apply the configuration by restarting your container or service: ```bash docker compose up -d ``` Or for systemd-managed nodes: ```bash sudo systemctl restart base-node ``` Upon restart, Geth will detect the `snap` sync mode and begin downloading the latest state snapshot from the official snapshot service (links provided in the repository README). Monitor logs with: ```bash docker logs -f ``` You should see snapshot download progress rather than block-by-block import messages. ## Technical Implementation in base/node The Snap Sync functionality is implemented through environment variable injection in the `base/node` repository's container architecture. The `geth/geth-entrypoint` script acts as the initialization layer. At line 74, the script constructs the Geth command: ```bash exec geth \ --datadir="$GETH_DATA_DIR" \ --syncmode="$OP_GETH_SYNCMODE" \ # ... additional flags ``` When `OP_GETH_SYNCMODE` is unset, the default value `full` applies. Setting it to `snap` triggers Geth's snapshot protocol, which connects to peers serving compressed state tries rather than historical block bodies. The Docker Compose configuration in [`docker-compose.yml`](https://github.com/base/node/blob/main/docker-compose.yml) passes these variables through the `env_file` directive, ensuring no manual command-line edits are required to switch sync modes. ## Summary - **Snap Sync** allows Base nodes to synchronize by downloading a compressed state snapshot instead of replaying every historical block, reducing sync time from days to hours. - Enable Snap Sync by uncommenting `OP_GETH_SYNCMODE=snap` in `.env.mainnet` (lines 91–96) or `.env.sepolia`, then restarting the node. - The `geth/geth-entrypoint` script passes this value to Geth's `--syncmode` flag at line 74. - Snap Sync remains **experimental** and may fall back to fast-sync for missing state pieces; revert to `full` sync if stability issues occur. - Optional tuning of `GETH_CACHE_SNAPSHOT` (default 24 MiB) can improve snapshot processing performance on high-RAM systems. ## Frequently Asked Questions ### What is the difference between Snap Sync and Full Sync in Base? Full Sync replays every transaction from genesis to the current block, verifying the entire chain history and state transitions. This provides maximum security but requires significant time and computational resources. Snap Sync downloads a recent compressed snapshot of the state trie, allowing the node to become operational quickly without processing historical blocks. However, Snap Sync trusts the snapshot data and is marked as experimental in the Base node implementation. ### How do I know if Snap Sync is working correctly? After enabling `OP_GETH_SYNCMODE=snap` and restarting, monitor your node logs using `docker logs -f `. During Snap Sync, you will see messages indicating snapshot download progress and state healing rather than the "Importing block" messages typical of full sync. If the node successfully downloads the state snapshot and begins importing new blocks near the chain head, Snap Sync is functioning correctly. If you see repeated fallback to fast-sync or persistent state errors, revert to full sync mode. ### Can I switch from Snap Sync to Full Sync after the initial sync? Yes, but the process requires careful handling. Once your node has completed Snap Sync and is fully operational, you can stop the node, change `OP_GETH_SYNCMODE` back to `full` (or comment out the line to use the default), and restart. However, switching modes after the initial sync does not retroactively validate historical blocks; it only affects how the node maintains state going forward. For full historical validation, you must start a fresh sync with `full` mode from genesis. ### Is Snap Sync safe for production Base nodes? Snap Sync is currently marked as **experimental** in the Base node repository. While it significantly reduces synchronization time, the implementation may fall back to fast-sync mechanisms if state pieces are missing, which can introduce instability. For production environments requiring high availability and absolute state consistency, the default `full` sync mode remains the recommended approach. Only use Snap Sync in production if you accept the experimental risks and have monitoring in place to detect sync failures.