Skip to content

Commit 4568efd

Browse files
authored
T2 docs (#198)
Update docs for T2 including info for partners + validator config v2 docs
1 parent 48c360f commit 4568efd

7 files changed

Lines changed: 399 additions & 77 deletions

File tree

src/pages/guide/node/network-upgrades.mdx

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,8 @@ For detailed release notes and binaries, see the [Changelog](/changelog).
1515

1616
| Release | Date | Network | Description | Priority |
1717
|---------|------|---------|-------------|----------|
18+
| [v1.5.0](https://github.com/tempoxyz/tempo/releases/tag/v1.5.0) | Mar 26, 2026 | Moderato + Mainnet | Required for T2; implements compound transfer policies (TIP-1015), permit support for TIP-20 (TIP-1004), ValidatorConfig V2 (TIP-1017), and 14 audit-driven bug fixes (TIP-1036) | <Badge variant="red">Required</Badge> |
19+
| [v1.4.3](https://github.com/tempoxyz/tempo/releases/tag/v1.4.3) | Mar 18, 2026 | Moderato + Mainnet | Fixes gas price oracle poisoning that caused inflated fee estimates for wallet transactions | <Badge variant="yellow">Recommended</Badge> |
1820
| [v1.4.2](https://github.com/tempoxyz/tempo/releases/tag/v1.4.2) | Mar 16, 2026 | Moderato + Mainnet | Strict payment calldata validation in the transaction pool and block builder, rejecting malformed payment transactions earlier | <Badge variant="yellow">Recommended</Badge> |
1921
| [v1.4.1](https://github.com/tempoxyz/tempo/releases/tag/v1.4.1) | Mar 12, 2026 | Moderato + Mainnet | Transaction pool DoS-hardening, consensus resilience improvements (DKG recovery), hardfork-aware gas estimation, and payload builder enhancements | <Badge variant="yellow">Recommended</Badge> |
2022
| [v1.4.0](https://github.com/tempoxyz/tempo/releases/tag/v1.4.0) | Mar 5, 2026 | Moderato + Mainnet | Required for T1C; introduces keychain signature migration so only V2 signatures and hashes are accepted after activation | <Badge variant="red">Required</Badge> |
@@ -23,6 +25,19 @@ For detailed release notes and binaries, see the [Changelog](/changelog).
2325

2426
---
2527

28+
## T2
29+
30+
| | |
31+
|---|---|
32+
| **Scope** | Compound transfer policies, ValidatorConfig V2, and audit-driven bug fixes |
33+
| **TIPs** | [TIP-1015: Compound Transfer Policies](/protocol/tips/tip-1015), [TIP-1004: Permit for TIP-20](/protocol/tips/tip-1004), [TIP-1017: Validator Config V2](/protocol/tips/tip-1017), [TIP-1036: T2 Hardfork Bug Fixes](/protocol/tips/tip-1036) |
34+
| **Release** | v1.5.0 |
35+
| **Testnet** | Moderato: Mar 26, 2026 16:00 CET (unix: 1774537200) |
36+
| **Mainnet** | Mar 31, 2026 16:00 CEST (unix: 1774965600) |
37+
| **Priority** | <Badge variant="red">Required</Badge> |
38+
39+
---
40+
2641
## T1C
2742

2843
| | |

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

Lines changed: 10 additions & 74 deletions
Original file line numberDiff line numberDiff line change
@@ -1,51 +1,20 @@
11
---
22
title: Operate your validator node
3-
description: Day-to-day operations for Tempo validators. Node lifecycle, upgrades, key rotation, monitoring, and troubleshooting.
3+
description: Day-to-day operations for Tempo validators. Node lifecycle, monitoring, metrics, log management, and Grafana dashboards.
44
---
55

66
# Operate your validator
77

88
This guide covers day-to-day operations for running a Tempo validator in production.
99

10-
## Validator states
10+
Validator management differs depending on which ValidatorConfig version is active:
1111

12-
Your validator moves through different states during operation. The transitions will happen only once on your validator's creation. Every state transition will happen on epoch boundaries in the happy case.
12+
- **[ValidatorConfig V2](/guide/node/validator-config-v2)** (post-T2) — self-service key rotation, IP updates, and ownership transfers
13+
- **[ValidatorConfig V1](/guide/node/validator-config-v1)** (pre-T2, legacy) — all management operations require coordinating with the Tempo team
1314

14-
```mermaid
15-
flowchart TD
16-
A[Inactive] -->|epoch ends| B["Syncer<br/>The validator starts syncing"]
17-
B -->|+1 epoch| C["Syncer and Player"]
18-
C -->|"+1 epoch, receives share"| D["Syncer<br/>Player<br/>Dealer"]
19-
D -->|"once fully synced"| E["Voter ↔ Proposer"]
15+
For validator states and lifecycle transitions, see the respective V1 and V2 pages.
2016

21-
click A "#not-a-participant-e"
22-
click B "#syncer-epoch-e1"
23-
click C "#player-epoch-e2"
24-
click D "#dealer-epoch-e3"
25-
click E "#dealer-epoch-e3"
26-
```
27-
28-
Currently, on mainnet and testnet, the epoch length is around 3 hours, which means that your validator will transition through these states approximately every 3 hours. If the epoch length ever changes, the transition times will also change.
29-
30-
#### Not a participant (E)
31-
32-
Epoch E marks the addition of your validator to the on-chain validator configuration smart contract. Your validator isn't considered a peer by validators yet. This is because the validator hasn't been refreshed in the current epoch yet. It is normal that no height metrics progress during this period, your node has to be considered
33-
a syncer to receive blocks.
34-
35-
#### Syncer (epoch E+1)
36-
37-
Your validator is now considered a peer by validators. It's syncing with the network and will be considered a player in the next epoch.
38-
39-
#### Player (epoch E+2)
40-
41-
Your validator is receiving consensus signing shares from dealers during the ceremony.
42-
43-
#### Dealer (epoch E+3)
44-
45-
Your validator is distributing consensus signing shares to other validators during the ceremony. Once your node is fully synced up, it will also
46-
be able to propose blocks and vote for other validators' proposed blocks.
47-
48-
#### Checking your validator's state
17+
## Checking your validator's state
4918

5019
Monitor these metrics to track your validator's state:
5120

@@ -140,47 +109,14 @@ The node will finish processing the current block before shutting down. Avoid us
140109
**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.
141110
:::
142111

143-
If you need to reset your validator's data, you must rotate to a new validator identity. This requires coordinating with the Tempo team to deactivate your old identity and register a new one.
112+
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).
144113

145114
## Key Management
146115

147-
### Signing Key Rotation
148-
149-
To rotate your validator's signing key:
150-
151-
1. Generate a new keypair:
152-
153-
```bash
154-
tempo consensus generate-private-key --output <new-key-path>
155-
tempo consensus calculate-public-key --private-key <new-key-path>
156-
```
157-
158-
2. Contact the Tempo team to update your validator's public key on-chain
159-
160-
3. Once confirmed, update your node configuration to use the new key and restart. Once the node is running, your validator will go through the [validator lifecycle](/guide/node/operate-validator#validator-states).
161-
162-
:::warning
163-
The old validator identity must be deactivated before the new one is activated
164-
:::
165-
166-
### Signing Share Recovery
116+
For signing key rotation, IP address updates, signing share recovery, and ownership transfers, see:
167117

168-
:::danger
169-
**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.
170-
:::
171-
172-
If you lose your signing share (stored on the database in `<datadir>/consensus/`), you will need to rotate to a new validator identity. This requires coordinating with the Tempo team to deactivate your old identity and register a new one.
173-
We're planning to release a high-availability feature that allows storing consensus data in an external database, which will enable signing share recovery without the need for key rotation.
174-
175-
### Deleting Signing Shares
176-
177-
:::warning[Breaking Change in v1.1.0]
178-
`--delete-signing-share` now requires the `--force` flag to prevent accidental deletion of validator signing keys. **Update any automation scripts that manage validator key lifecycle.**
179-
:::
180-
181-
```bash
182-
tempo consensus --delete-signing-share --force
183-
```
118+
- **[ValidatorConfig V2](/guide/node/validator-config-v2)** (post-T2) — self-service operations
119+
- **[ValidatorConfig V1](/guide/node/validator-config-v1#key-management)** (pre-T2) — coordinated through the Tempo team
184120

185121
## Log Management
186122

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
title: ValidatorConfig V1 (Legacy)
3+
description: Legacy validator management via ValidatorConfig V1. Key rotation, IP updates, and signing share recovery pre-T2.
4+
---
5+
6+
# ValidatorConfig V1 (Legacy)
7+
8+
:::warning
9+
This page documents ValidatorConfig V1 behavior, which applies **before the T2 hardfork**. Once T2 is active and migration from V1 to V2 is complete, use [ValidatorConfig V2](/guide/node/validator-config-v2) instead. You can [check if V2 is initialized](/guide/node/validator-config-v2#check-if-v2-is-active) to confirm the migration is complete.
10+
:::
11+
12+
ValidatorConfig V1 is the original precompile for managing consensus participants. All management operations are permissioned and require coordinating with the Tempo team.
13+
14+
## Validator states
15+
16+
Under V1, your validator goes through the following states after being added on-chain. Each transition happens on epoch boundaries.
17+
18+
```mermaid
19+
flowchart TD
20+
A[Inactive] -->|epoch ends| B["Syncer<br/>The validator starts syncing"]
21+
B -->|+1 epoch| C["Syncer and Player"]
22+
C -->|"+1 epoch, receives share"| D["Syncer<br/>Player<br/>Dealer"]
23+
D -->|"once fully synced"| E["Voter ↔ Proposer"]
24+
25+
click A "#not-a-participant-e"
26+
click B "#syncer-epoch-e1"
27+
click C "#player-epoch-e2"
28+
click D "#dealer-epoch-e3"
29+
click E "#dealer-epoch-e3"
30+
```
31+
32+
Currently, on mainnet and testnet, the epoch length is around 3 hours, which means that your validator will transition through these states approximately every 3 hours.
33+
34+
#### Not a participant (E)
35+
36+
Epoch E marks the addition of your validator to the on-chain validator configuration smart contract. Your validator isn't considered a peer by validators yet. This is because the validator hasn't been refreshed in the current epoch yet. It is normal that no height metrics progress during this period, your node has to be considered a syncer to receive blocks.
37+
38+
#### Syncer (epoch E+1)
39+
40+
Your validator is now considered a peer by validators. It's syncing with the network and will be considered a player in the next epoch.
41+
42+
#### Player (epoch E+2)
43+
44+
Your validator is receiving consensus signing shares from dealers during the ceremony.
45+
46+
#### Dealer (epoch E+3)
47+
48+
Your validator is distributing consensus signing shares to other validators during the ceremony. Once your node is fully synced up, it will also be able to propose blocks and vote for other validators' proposed blocks.
49+
50+
## Key Management
51+
52+
### Signing Key Rotation
53+
54+
1. Generate a new keypair:
55+
56+
```bash
57+
tempo consensus generate-private-key --output <new-key-path>
58+
tempo consensus calculate-public-key --private-key <new-key-path>
59+
```
60+
61+
2. Contact the Tempo team to update your validator's public key on-chain
62+
63+
3. Once confirmed, update your node configuration to use the new key and restart. Once the node is running, your validator will go through the [validator states](#validator-states) again.
64+
65+
:::warning
66+
The old validator identity must be deactivated before the new one is activated.
67+
:::
68+
69+
### Signing Share Recovery
70+
71+
If you lose your signing share, coordinate with the Tempo team to deactivate your old identity and register a new one.
72+
73+
### Update IP Addresses
74+
75+
Contact the Tempo team to update your validator's ingress and egress addresses on-chain.

0 commit comments

Comments
 (0)