chore: Remove ValidatorConfigV1 references

src/pages/guide/node/operate-validator.mdx

@@ -7,12 +7,7 @@ description: Day-to-day operations for Tempo validators. Node lifecycle, monitor
 
 This guide covers day-to-day operations for running a Tempo validator in production.
 
-Validator management differs depending on which ValidatorConfig version is active:
-
-- **[ValidatorConfig V2](/guide/node/validator-config-v2)** (post-T2) — self-service key rotation, IP updates, and ownership transfers
-- **[ValidatorConfig V1](/guide/node/validator-config-v1)** (pre-T2, legacy) — all management operations require coordinating with the Tempo team
-
-For validator states and lifecycle transitions, see the respective V1 and V2 pages.
+- **[Validator Configuration](/guide/node/validator-config-v2)** — self-service key rotation, IP updates, and ownership transfers
 
 ## Checking your validator's state
 
@@ -109,14 +104,13 @@ The node will finish processing the current block before shutting down. Avoid us
 **You cannot reset a validator's data and continue with the same identity.** Doing so risks inconsistent voting, which can cause irrecoverable network safety failures.
 :::
 
-If you need to reset your validator's data, you must rotate to a new validator identity. See key rotation under [ValidatorConfig V2](/guide/node/validator-config-v2#rotate-validator-identity) or [ValidatorConfig V1](/guide/node/validator-config-v1#signing-key-rotation).
+If you need to reset your validator's data, you must rotate to a new validator identity. See key rotation under [Validator Configuration](/guide/node/validator-config-v2#rotate-validator-identity).
 
 ## Key Management
 
 For signing key rotation, IP address updates, signing share recovery, and ownership transfers, see:
 
-- **[ValidatorConfig V2](/guide/node/validator-config-v2)** (post-T2) — self-service operations
-- **[ValidatorConfig V1](/guide/node/validator-config-v1#key-management)** (pre-T2) — coordinated through the Tempo team
+- **[Validator Configuration](/guide/node/validator-config-v2)** (post-T2) — self-service operations
 
 ## Log Management
 

src/pages/guide/node/validator-config-v2.mdx

@@ -5,26 +5,21 @@ description: Manage your validator with ValidatorConfig V2. Self-service key rot
 
 # ValidatorConfig V2
 
-ValidatorConfig V2 ([TIP-1017](/protocol/tips/tip-1017)) is a new precompile for managing consensus participants. It replaces the original ValidatorConfig with stronger safety guarantees: ed25519 signature verification at registration, append-only history, and self-service operations for validators.
-
-V2 was [activated on mainnet](https://explore.mainnet.tempo.xyz/receipt/0x4716147e3c2bf5c8d014b8c27d6e2af0042d5a5f29bdead256d6f33038702d64) after the T2 hardfork.
+ValidatorConfig V2 ([TIP-1017](/protocol/tips/tip-1017)) is the precompile that manages consensus participants. This config was [activated on mainnet](https://explore.mainnet.tempo.xyz/receipt/0x4716147e3c2bf5c8d014b8c27d6e2af0042d5a5f29bdead256d6f33038702d64) after the T2 hardfork.
 
 ## Validator states
 
-With V2, the syncer warmup phase from V1 is removed. Once added, a validator immediately becomes a player in the next epoch.
+Once added, a validator immediately becomes a player in the next epoch.
 
 ```mermaid
 flowchart TD
     A[Inactive] -->|epoch ends| B["Player<br/>Receives signing shares"]
     B -->|"+1 epoch, receives share"| C["Player<br/>Dealer"]
     C -->|"once fully synced"| D["Voter ↔ Proposer"]
 ```
-
-Compare this to the [V1 validator states](/guide/node/validator-config-v1#validator-states), which required an additional syncer epoch before becoming a player.
-
 ## What changes for operators
 
-With V2, validators can perform several operations themselves without coordinating with the Tempo team:
+Validators can perform several operations themselves without coordinating with the Tempo team:
 
 - **Rotate your validator identity** — swap to a new ed25519 key without losing your committee slot
 - **Update IP addresses** — change ingress and egress endpoints independently (V2 supports asymmetric ingress/egress IPs)
@@ -144,8 +139,6 @@ tempo consensus set-validator-fee-recipient <address/pubkey/index>
 
 If your node's network endpoints change, update them on-chain. The change takes effect at the next finalized block.
 
-Unlike V1, V2 supports asymmetric ingress and egress IPs — they no longer need to share the same address. Both can be updated together or individually by supplying only `--ingress` or `--egress`. The values not supplied will pulled from the chain and left unchanged in the submitted transaction.
-
 ```bash
 tempo consensus set-validator-ip-address <address/pubkey/index>
   --ingress <NEW_IP>:NEW_PROT>
@@ -160,7 +153,7 @@ Ingress addresses must be unique across all active validators. The transaction w
 
 ### Rotate validator identity
 
-V2 lets you rotate to a new ed25519 key while keeping your validator index stable. This is useful for key rotation or recovery without leaving and re-joining the committee. [Generate a new signing key](#generating-a-signing-key) first.
+The ed25519 key can be changed while keeping your validator index stable. This is useful for key rotation or recovery without leaving and re-joining the committee. [Generate a new signing key](#generating-a-signing-key) first.
 
 The simplest way to rotate is using the `tempo` CLI, which handles signature creation and the on-chain transaction in one step:
 
@@ -219,15 +212,3 @@ tempo consensus deactivate-validator <address/pubkey/index>
   --rpc-url https://rpc.tempo.xyz \
   --private-key <PATH_TO_VALIDATOR_PRIVATE_KEY>
 ```
-
-## Differences from V1
-
-| | V1 | V2 |
-|---|---|---|
-| **Key ownership** | No verification | Ed25519 signature required |
-| **History** | Mutable, toggle active/inactive | Append-only, deactivate-once |
-| **Validator index** | Could change | Stable for lifetime |
-| **Self-service ops** | None (owner only) | IP updates, rotation, transfer |
-| **Historical queries** | Required warmup state, bloated snapshots | `addedAtHeight` / `deactivatedAtHeight` fields |
-
-

src/pages/guide/node/validator.mdx

@@ -86,7 +86,7 @@ INFO handle_propose{epoch=18 view=387213 parent.view=387212 parent.digest=0x4388
 ```
 
 If you do not see logs like these:
-- please check that your validator is part of the active set, and is both a player and a dealer (see validator states under [V2](/guide/node/validator-config-v2#validator-states) or [V1](/guide/node/validator-config-v1#validator-states))
+- please check that your validator is part of the active set, and is both a player and a dealer. See [validator states](/guide/node/validator-config-v2#validator-states)
 - please check that your node is synced up to the [latest block height](https://explorer.tempo.xyz/). 
 - please check that your outgoing IP address matches the one whitelisted on the validator smart contract:
 

vocs.config.ts

@@ -731,10 +731,6 @@ export default defineConfig({
                 text: 'ValidatorConfig V2',
                 link: '/guide/node/validator-config-v2',
               },
-              {
-                text: 'ValidatorConfig V1 (Legacy)',
-                link: '/guide/node/validator-config-v1',
-              },
             ],
           },
           {