tempoxyz · emmajam · Apr 22, 2026 · Apr 16, 2026 · Apr 17, 2026 · Apr 17, 2026
diff --git a/src/pages/cli/node.mdx b/src/pages/cli/node.mdx
@@ -37,7 +37,7 @@ Flags grouped by function:
 | `--consensus.datadir <path>` | Separate volume for consensus data |
 
 :::warning
-`--consensus.fee-recipient` is deprecated as of `v1.5.2` and will be removed in an upcoming release. See [Validator Config V2](/guide/node/validator-config-v2).
+`--consensus.fee-recipient` is deprecated as of `v1.5.2` and will be removed in an upcoming release. See [updating the fee recipient](/guide/node/validator-lifecycle#update-the-fee-recipient).
 :::
 
 ### Observability

diff --git a/src/pages/guide/node/installation.mdx b/src/pages/guide/node/installation.mdx
@@ -44,9 +44,27 @@ docker run -d --name tempo ghcr.io/tempoxyz/tempo:<version> --version
 docker logs tempo
 ```
 
+## Snapshots
+
+Downloading a snapshot lets your node skip syncing from genesis and start participating much faster. This is recommended for both RPC nodes and validators.
+
+::::code-group
+```bash [Minimal (validators)]
+tempo download --chain mainnet --minimal
+```
+```bash [Full (RPC / dApp backends)]
+tempo download --chain mainnet
+```
+```bash [Archive (indexers / RPC providers)]
+tempo download --chain mainnet --archive
+```
+::::
+
+For testnet, replace `mainnet` with `moderato`. See [snapshots.tempoxyz.dev](https://snapshots.tempoxyz.dev/) for detailed component sizes and download options.
+
 ## Verifying Releases
 
-All release artifacts are cryptographically signed starting after **v1.1.1**. We recommend verifying signatures before running any binary.
+All release artifacts are cryptographically signed. We recommend verifying signatures before running any binary.
 
 ### Binary Signatures (GPG)
 

diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx
@@ -27,7 +27,7 @@ For detailed release notes and binaries, see the [Changelog](/changelog).
 | [v1.2.0](https://github.com/tempoxyz/tempo/releases/tag/v1.2.0) | Feb 13, 2026 | Mainnet only | Fixes validation bug rejecting transactions with gas limits above ~16.7M, blocking large contract deployments | <Badge variant="red">Required</Badge> |
 
 :::warning
-`--consensus.fee-recipient` is deprecated as of `v1.5.2` and will be removed in an upcoming release. Validators should migrate fee-recipient management to [Validator Config V2](/guide/node/validator-config-v2).
+`--consensus.fee-recipient` is deprecated as of `v1.5.2` and will be removed in an upcoming release. Validators should migrate fee-recipient management to [update the fee recipient](/guide/node/validator-lifecycle#update-the-fee-recipient).
 :::
 
 ---

diff --git a/src/pages/guide/node/security.mdx b/src/pages/guide/node/security.mdx
@@ -0,0 +1,52 @@
+---
+title: Node Security
+description: Security best practices for Tempo node operators, covering key management, network configuration, release verification, and data integrity.
+---
+
+# Node Security
+
+This page covers security best practices for Tempo node operators. Following these recommendations helps protect your validator from impersonation, unauthorized access, and operational mistakes.
+
+## Key management
+
+Your signing key is the most sensitive asset on your validator. Anyone with access to it can impersonate your node in consensus.
+
+- **Restrict file permissions** — set `chmod 600` on key files so only the node process user can read them.
+- **Never share your private key** — the Tempo team will never ask for it.
+- **Rotate keys periodically** — use [key rotation](/guide/node/validator-lifecycle#rotate-validator-identity) to swap to a new ed25519 key without leaving the committee.
+- **Separate the operator address** — the Ethereum address that controls on-chain operations (IP updates, rotation, ownership transfer) should be a dedicated address, not a general-purpose hot wallet.
+
+See [Managing validator keys](/guide/node/validator-keys) for the full key hierarchy and generation instructions.
+
+## Network configuration
+
+Tempo's networking layer includes built-in protections, making a cloud firewall or NAT gateway unnecessary in most setups. The node:
+
+- Only accepts consensus connections from validators that can prove their identity
+- Only accepts connections from trusted IP addresses (active validators on-chain)
+- Rate-limits connections and messages in both consensus and execution layers
+
+### Recommendations
+
+- **Expose only the required ports** — see [Ports](/guide/node/system-requirements#ports) for which ports need public access vs. internal-only.
+- **Keep ingress addresses unique** — the on-chain contract enforces uniqueness, but verify your registered `IP:port` is correct after infrastructure changes.
+- **Use a dedicated machine** — avoid running other internet-facing services on the same host as your validator.
+
+## Release verification
+
+Always verify release artifacts before running them. Tempo signs all binaries and Docker images — see [Verifying Releases](/guide/node/installation#verifying-releases) for GPG, Cosign, and SHA256 verification instructions.
+
+## Time synchronization
+
+An unsynchronized clock can cause your node to reject valid blocks or produce blocks that other validators reject. Use `chrony` or `ntpd` — not `systemd-timesyncd`. See [Time Synchronization](/guide/node/system-requirements#time-synchronization) for setup instructions.
+
+## Data integrity
+
+- **Never delete the data directory and re-sync with the same signing key** — this risks double-signing and will require [rotating to a new identity](/guide/node/validator-lifecycle#resetting-your-validators-data). Deleting only the `consensus` subdirectory is safe; the signing share will be [automatically recovered](/guide/node/validator-keys#signing-share-recovery).
+- **Back up your signing key** — if the key file is lost and no backup exists, you will need to rotate to a new key and coordinate with the Tempo team.
+
+## Staying up to date
+
+- Subscribe to [Tempo GitHub releases](https://github.com/tempoxyz/tempo/releases) for security patches and upgrade announcements.
+- Review the [Upgrade Cadence](/guide/node/upgrade-cadence) to understand notification timelines.
+- Apply <span style={{color: 'var(--vocs-color_red)'}}>Required</span> upgrades before the activation block — failing to do so will fork your node off the network.
diff --git a/src/pages/guide/node/system-requirements.mdx b/src/pages/guide/node/system-requirements.mdx
@@ -43,12 +43,42 @@ These dedicated servers meet or exceed the recommended specs for both RPC and va
 Cloud instances with network-attached storage (e.g., AWS EBS) do not provide sufficient I/O performance. Use dedicated servers or instances with local NVMe storage.
 :::
 
-## Security measures
+## Time Synchronization
 
-We do not recommend using a cloud firewall / NAT gateway as it can introduce additional complexity and performance issues. Instead, we've implemented security measures in the networking layer of the node, including:
-- only accepting connections from trusted IP addresses (active validators on-chain)
-- ratelimiting connections and messages in consensus and execution to prevent abuse
-- only accepting consensus connections from validators that can prove their identity
+Tempo validates that block timestamps are not in the future. If your system clock drifts even slightly, your node may reject valid blocks or produce blocks that other validators reject — leading to consensus errors and missed proposals.
+
+:::warning
+`systemd-timesyncd` (the default on many minimal VMs) is **not sufficient**. Use `chrony` or `ntpd` for reliable sub-millisecond synchronization.
+:::
+
+### Install and enable chrony (recommended)
+
+```bash
+sudo apt install chrony
+sudo systemctl enable --now chronyd
+```
+
+### Verify synchronization
+
+```bash
+chronyc tracking
+```
+
+Check that **System time** offset is under a few milliseconds and **Leap status** is `Normal`. You can also verify with:
+
+```bash
+timedatectl
+```
+
+Confirm `System clock synchronized: yes` and `NTP service: active`.
+
+### Cloud providers
+
+Most cloud providers (AWS, Hetzner, OVH) pre-configure NTP, but minimal VM images may ship without a proper NTP daemon. Always verify that `chrony` or `ntpd` is installed and running after provisioning a new machine.
+
+## Security
+
+For network configuration, key management, release verification, and other security best practices, see the dedicated [Node Security](/guide/node/security) page.
 
 ## Network Tuning
 

diff --git a/src/pages/guide/node/upgrade-cadence.mdx b/src/pages/guide/node/upgrade-cadence.mdx
@@ -0,0 +1,67 @@
+---
+title: Upgrade Cadence
+description: How Tempo schedules and communicates network upgrades, including timelines, notification windows, and what to expect as a node operator.
+---
+
+import { Badge } from '../../../components/Badge'
+
+# Upgrade Cadence
+
+Tempo ships protocol upgrades on a **monthly cadence**. Each upgrade bundles one or more protocol changes ([TIPs](/protocol/tips)) into a named hardfork (T1, T2, T3, …).
+
+## Rollout timeline
+
+Every upgrade follows the same two-stage rollout:
+
+| Stage | Lead time | Details |
+|-------|-----------|---------|
+| **Testnet** (Moderato) | Announced at least **3 days** before activation | The upgrade activates on the Moderato testnet first so operators and integrators can validate. |
+| **Mainnet** (Presto) | Announced at least **7 days** before activation | After a successful testnet activation, the same release is scheduled for mainnet — typically one week later. |
+
+Operators should use the window between testnet and mainnet activation to upgrade their testnet node, verify it syncs past the activation block, and confirm their applications work against the new protocol rules.
+
+## Patch releases
+
+Between hardforks, Tempo publishes patch releases (e.g. v1.5.1, v1.5.2) for security fixes, performance improvements, and non-consensus bug fixes. Patch releases do not require a hardfork and can be adopted at your own pace, subject to the priority level.
+
+## Upgrade priority levels
+
+Each release on the [Network Upgrades and Releases](/guide/node/network-upgrades) page carries a priority badge:
+
+| Badge | Meaning |
+|-------|---------|
+| <Badge variant="red">Required</Badge> | Consensus-breaking change — nodes **must** upgrade before the activation block or they will fork off the network. |
+| <Badge variant="yellow">Recommended</Badge> | Non-consensus improvement (performance, hardening, bug fixes). Nodes continue to function without upgrading, but the update is strongly encouraged. |
+| <Badge variant="amber">RPC only</Badge> | Only affects RPC-serving nodes (e.g. security patches for public endpoints). Validators without public RPC exposure can skip. |
+
+## How you will be notified
+
+- **GitHub releases** — every release is published to [tempoxyz/tempo releases](https://github.com/tempoxyz/tempo/releases) with a full changelog.
+- **Operator channels** — the Tempo team shares activation timestamps and migration checklists in dedicated operator channels ahead of each upgrade.
+- **Docs** — the [Network Upgrades and Releases](/guide/node/network-upgrades) page is updated with dates, TIP references, and priority badges as soon as an upgrade is scheduled.
+
+## Operator checklist
+
+:::::steps
+
+### Review the release
+
+Read the changelog and upgrade page to understand what is changing and whether any migration steps are required.
+
+### Upgrade your testnet node
+
+Update your Moderato node to the new release and confirm it syncs past the testnet activation block.
+
+### Validate your integration
+
+Run your application or test suite against the upgraded testnet to catch any breaking changes before mainnet.
+
+### Upgrade your mainnet node
+
+Update your mainnet node **before** the mainnet activation timestamp.
+
+### Monitor after activation
+
+Watch logs and metrics after the activation block to confirm normal operation.
+
+:::::