From 8384ea496cb599976d0f403a4d3eb144c3003c65 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Fri, 20 Mar 2026 18:21:39 +0000 Subject: [PATCH 01/11] T2 docs --- src/pages/guide/node/network-upgrades.mdx | 15 +++++ src/pages/protocol/upgrades/t2.mdx | 78 +++++++++++++++++++++++ vocs.config.ts | 10 +++ 3 files changed, 103 insertions(+) create mode 100644 src/pages/protocol/upgrades/t2.mdx diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx index d8072371..2e39919e 100644 --- a/src/pages/guide/node/network-upgrades.mdx +++ b/src/pages/guide/node/network-upgrades.mdx @@ -15,6 +15,8 @@ For detailed release notes and binaries, see the [Changelog](/changelog). | Release | Date | Network | Description | Priority | |---------|------|---------|-------------|----------| +| v1.5.0 | Mar 26, 2026 | Moderato + Mainnet | Required for T2; implements compound transfer policies (TIP-1015), ValidatorConfig V2 (TIP-1017), and 14 audit-driven bug fixes (TIP-1036) | Required | +| [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 | Recommended | | [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 | Recommended | | [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 | Recommended | | [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 | Required | @@ -23,6 +25,19 @@ For detailed release notes and binaries, see the [Changelog](/changelog). --- +## T2 + +| | | +|---|---| +| **Scope** | Compound transfer policies, ValidatorConfig V2, and audit-driven bug fixes | +| **TIPs** | [TIP-1015: Compound Transfer Policies](https://docs.tempo.xyz/protocol/tips/tip-1015), [TIP-1017: Validator Config V2](https://docs.tempo.xyz/protocol/tips/tip-1017), [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) | +| **Release** | v1.5.0 | +| **Testnet** | Moderato: Mar 26, 2026 16:00 CET (unix: 1774537200) | +| **Mainnet** | Mar 31, 2026 16:00 CEST (unix: 1774965600) | +| **Priority** | Required | + +--- + ## T1C | | | diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx new file mode 100644 index 00000000..35fae099 --- /dev/null +++ b/src/pages/protocol/upgrades/t2.mdx @@ -0,0 +1,78 @@ +--- +title: T2 Network Upgrade +description: Details and timeline for the T2 network upgrade including compound transfer policies, Validator Config V2, EIP-2612 permit, and audit-driven bug fixes. +--- + +# T2 Network Upgrade + +This doc is for internal use only to inform about what is going live with T2 and when. Request for input on: Which partners should we reach out to specifically? + +## Timeline + +Cut release Monday, 23rd March and send out to partners. + +| Network | Date | Timestamp | +|---------|------|-----------| +| Moderato (testnet) | Thursday, 24th March 4pm CET | `1774537200` | +| Presto (mainnet) | Tuesday, March 31st 4pm CET | `1774965600` | + +Partners should upgrade nodes to the T2-compatible release before the moderato activation timestamp. + +## Overview + +T2 is Tempo's next network upgrade, building on T1. It introduces compound transfer policies ([TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015)), EIP-2612 permit support for TIP-20 tokens ([TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004)), a new Validator Config V2 precompile ([TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017)), and 13 audit-driven bug fixes ([TIP-1036](https://docs.tempo.xyz/protocol/tips/tip-1036)). + +**Action required:** All node operators must upgrade to the T2-compatible release before the activation timestamp. + +## Feature TIPs + +### TIP-1015: Compound Transfer Policies + +**Spec:** [TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015) + +**TLDR:** Extends TIP-403 policies so token issuers can set different authorization rules for senders, recipients, and mint recipients. Previously a single policy applied to both sides of a transfer. + +**Customer use case:** Issuers of regulated or closed-loop tokens need to enforce different rules for senders vs recipients. For example: KYC required to on-ramp into a stablecoin, but anyone in the approved set can spend. Without compound policies, issuers must apply the same restrictions to both sides, which breaks real-world Commerce patterns and Tokenized Asset distribution flows. + +**Partner impact:** +- If you integrate with TIP-403 policies: new `isAuthorizedSender()`, `isAuthorizedRecipient()`, and `isAuthorizedMintRecipient()` functions are available. The existing `isAuthorized()` still works (returns `senderCheck && recipientCheck`). +- If you issue TIP-20 tokens: You can now create compound policies for use cases like vendor credits, directional KYC, or asymmetric compliance. + +### TIP-1017: Validator Config V2 + +**Spec:** [TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017) + +**Operator guide:** [Validator Config V2](https://docs.tempo.xyz/guide/node/validator-config-v2) + +**Internal docs for migration:** Migration from Validator Config V1 to V2 + +**TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history, stable validator indices, and fee recipient separation. + +**Customer use case:** Node operators currently depend on Tempo to make any validator configuration changes. With V2, operators can self-service IP rotations, key rotations, and ownership transfers without waiting on Tempo — reducing operational dependency and enabling faster incident response. + +**Partner impact:** +- **Node operators:** Once T2 activates, the contract owner (Tempo) will migrate validators from V1 to V2 via `migrateValidator()` + `initializeIfMigrated()`. After the migration, operators can then self-service IP updates, key rotation, and ownership transfers. Node operators won't need to do anything for this migration. +- **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. Stripe requested this feature since they didn't want their node operators to have the capability to change this key. +- **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. Combined with Reth storage v2 (which allows pruning historical data in-place), this enables validators to run in minimal mode reducing disk from hundreds of GB to a fraction. Reth v2 will be released next week. This makes Tempo's node requirements significantly lighter than comparable networks. + +### TIP-1004: Permit for TIP-20 + +**Spec:** [TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004) + +**TLDR:** Adds EIP-2612 `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures. + +**Customer use case:** Any Ramp or Commerce platform that sponsors gas for end users needs `permit()` to avoid forcing two separate transactions. Avenia was the first partner blocked on this — they can't ship their LATAM on/off-ramp flow without it. + +**Partner impact:** +- Users can now use `permit()` to combine approve + action in a single transaction. + +### Meta TIP: Audit & Bug Fixes + +**(WIP)** [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) + +**PR:** [#3205](https://github.com/tempoxyz/tempo/pull/3205) + +Some items that may affect partners: +- If you call AccountKeychain admin functions from a contract, refactor to direct EOA calls. +- If you submit AA transactions with `fee_payer == sender`, use a separate fee payer account. +- If you estimate gas for 2D nonce key transactions, update gas estimates (ref [#2533](https://github.com/tempoxyz/tempo/pull/2533)). diff --git a/vocs.config.ts b/vocs.config.ts index 94840ad5..8baedec2 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -512,6 +512,16 @@ export default defineConfig({ }, ], }, + { + text: 'Network Upgrades', + collapsed: true, + items: [ + { + text: 'T2', + link: '/protocol/upgrades/t2', + }, + ], + }, { text: 'TIPs', link: '/protocol/tips', From 1e9f0ac5084f9e098bfc3c24ad5c91d6a2c7e205 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Fri, 20 Mar 2026 18:41:06 +0000 Subject: [PATCH 02/11] Update TIP-1017 --- src/pages/protocol/upgrades/t2.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 35fae099..6c0dc32c 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -44,14 +44,12 @@ T2 is Tempo's next network upgrade, building on T1. It introduces compound trans **Operator guide:** [Validator Config V2](https://docs.tempo.xyz/guide/node/validator-config-v2) -**Internal docs for migration:** Migration from Validator Config V1 to V2 - **TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history, stable validator indices, and fee recipient separation. **Customer use case:** Node operators currently depend on Tempo to make any validator configuration changes. With V2, operators can self-service IP rotations, key rotations, and ownership transfers without waiting on Tempo — reducing operational dependency and enabling faster incident response. **Partner impact:** -- **Node operators:** Once T2 activates, the contract owner (Tempo) will migrate validators from V1 to V2 via `migrateValidator()` + `initializeIfMigrated()`. After the migration, operators can then self-service IP updates, key rotation, and ownership transfers. Node operators won't need to do anything for this migration. +- **Node operators:** Node operators won't need to do anything for this migration. After the migration, operators can self-service IP updates, key rotation, and ownership transfers. - **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. Stripe requested this feature since they didn't want their node operators to have the capability to change this key. - **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. Combined with Reth storage v2 (which allows pruning historical data in-place), this enables validators to run in minimal mode reducing disk from hundreds of GB to a fraction. Reth v2 will be released next week. This makes Tempo's node requirements significantly lighter than comparable networks. From 7ee29aa26559ac054ddf0b15d88ca0ca37c77ae0 Mon Sep 17 00:00:00 2001 From: Derek Cofausper <256792747+decofe@users.noreply.github.com> Date: Tue, 24 Mar 2026 14:07:49 +0100 Subject: [PATCH 03/11] docs(node): add ValidatorConfig V2 operator guide (#190) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * docs(node): add ValidatorConfig V2 operator guide Adds operator documentation for TIP-1017 ValidatorConfig V2: - Reading validator state (by address, pubkey, index) - Self-service operations: IP updates, fee recipient, key rotation, ownership transfer - V1 vs V2 comparison table - Migration walkthrough - Cross-references from existing operate-validator page Co-authored-by: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> Amp-Thread-ID: https://ampcode.com/threads/T-019d0529-863c-737b-8027-db9e2a491918 * docs(node): remove fee recipient section, not yet active Co-authored-by: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> Amp-Thread-ID: https://ampcode.com/threads/T-019d0529-863c-737b-8027-db9e2a491918 * docs(node): differentiate pre-T2 and post-T2 validator operations ValidatorConfig V2 activates with the T2 hardfork. Updated operator and validator docs to clearly distinguish pre-T2 (contact Tempo team) vs post-T2 (self-service via V2 precompile) behavior for key rotation, data reset, and signing share recovery. Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): restructure operate-validator around V1/V2 split Leads with ValidatorConfig V2 as the primary key management interface (post-T2), with V1 procedures moved to a Legacy section below. Adds V2 sections for IP updates and ownership transfer alongside rotation and share recovery. Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): add validator lifecycle flowchart to V2 page Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): simplify V2 flowchart to match operate-validator style Replaces the lifecycle diagram with a linear state progression chart matching the V1 chart style. Key difference: no syncer warmup step — validators become players immediately in the next epoch. Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): remove migration section from V2 operator docs Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): fix description, remove migration mention Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): extract V1 content into validator-config-v1.mdx Moves V1-specific content (validator states flowchart, key rotation, IP updates, signing share recovery) from operate-validator.mdx into a new validator-config-v1.mdx page. operate-validator.mdx now only contains version-agnostic operations: metrics, node lifecycle, logs, and Grafana dashboards. Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): remove deleting signing shares section Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): add isInitialized/getInitializedAtHeight to check V2 status V2 doc gets a 'Check if V2 is active' section with cast calls. V1 doc warning updated to mention migration completion and link to the check. Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): link 'check if V2 is active' from intro Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): remove V2 mention from validator.mdx intro Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): fix lifecycle link to point to V2 validator states Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): replace signature spec with CLI commands, remove consensus integration Rotation section now shows tempo consensus rotate-validator, create-rotate-validator-signature, and create-add-validator-signature instead of raw signature construction. Removes consensus integration section (not operator-relevant). Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): add rotation best practice — keep old validator until out of committee Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): mention asymmetric ingress/egress and partial IP updates Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): fix stale link to V1 validator states Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): rephrase V2 availability intro Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): nest validator config pages under 'Operating your validator' dropdown Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * docs(node): replace getActiveValidators cast call with tempo consensus validators-info Co-Authored-By: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> * remove the raw contract call for validator rotation; add an info box on validator state --------- Co-authored-by: Richard Janis Goldschmidt <701177+SuperFluffy@users.noreply.github.com> Co-authored-by: Richard Janis Goldschmidt --- src/pages/guide/node/operate-validator.mdx | 84 +------- src/pages/guide/node/validator-config-v1.mdx | 75 +++++++ src/pages/guide/node/validator-config-v2.mdx | 203 +++++++++++++++++++ src/pages/guide/node/validator.mdx | 4 +- vocs.config.ts | 16 +- 5 files changed, 305 insertions(+), 77 deletions(-) create mode 100644 src/pages/guide/node/validator-config-v1.mdx create mode 100644 src/pages/guide/node/validator-config-v2.mdx diff --git a/src/pages/guide/node/operate-validator.mdx b/src/pages/guide/node/operate-validator.mdx index d6b93af6..2b266c03 100644 --- a/src/pages/guide/node/operate-validator.mdx +++ b/src/pages/guide/node/operate-validator.mdx @@ -1,51 +1,20 @@ --- title: Operate your validator node -description: Day-to-day operations for Tempo validators. Node lifecycle, upgrades, key rotation, monitoring, and troubleshooting. +description: Day-to-day operations for Tempo validators. Node lifecycle, monitoring, metrics, log management, and Grafana dashboards. --- # Operate your validator This guide covers day-to-day operations for running a Tempo validator in production. -## Validator states +Validator management differs depending on which ValidatorConfig version is active: -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. +- **[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 -```mermaid -flowchart TD - A[Inactive] -->|epoch ends| B["Syncer
The validator starts syncing"] - B -->|+1 epoch| C["Syncer and Player"] - C -->|"+1 epoch, receives share"| D["Syncer
Player
Dealer"] - D -->|"once fully synced"| E["Voter ↔ Proposer"] +For validator states and lifecycle transitions, see the respective V1 and V2 pages. - click A "#not-a-participant-e" - click B "#syncer-epoch-e1" - click C "#player-epoch-e2" - click D "#dealer-epoch-e3" - click E "#dealer-epoch-e3" -``` - -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. - -#### Not a participant (E) - -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. - -#### Syncer (epoch E+1) - -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. - -#### Player (epoch E+2) - -Your validator is receiving consensus signing shares from dealers during the ceremony. - -#### Dealer (epoch E+3) - -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. - -#### Checking your validator's state +## Checking your validator's state Monitor these metrics to track your validator's state: @@ -140,47 +109,14 @@ 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. This requires coordinating with the Tempo team to deactivate your old identity and register a new one. +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). ## Key Management -### Signing Key Rotation - -To rotate your validator's signing key: - -1. Generate a new keypair: - -```bash -tempo consensus generate-private-key --output -tempo consensus calculate-public-key --private-key -``` - -2. Contact the Tempo team to update your validator's public key on-chain - -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). - -:::warning -The old validator identity must be deactivated before the new one is activated -::: - -### Signing Share Recovery +For signing key rotation, IP address updates, signing share recovery, and ownership transfers, see: -:::danger -**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 lose your signing share (stored on the database in `/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. -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. - -### Deleting Signing Shares - -:::warning[Breaking Change in v1.1.0] -`--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.** -::: - -```bash -tempo consensus --delete-signing-share --force -``` +- **[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 ## Log Management diff --git a/src/pages/guide/node/validator-config-v1.mdx b/src/pages/guide/node/validator-config-v1.mdx new file mode 100644 index 00000000..15098a6b --- /dev/null +++ b/src/pages/guide/node/validator-config-v1.mdx @@ -0,0 +1,75 @@ +--- +title: ValidatorConfig V1 (Legacy) +description: Legacy validator management via ValidatorConfig V1. Key rotation, IP updates, and signing share recovery pre-T2. +--- + +# ValidatorConfig V1 (Legacy) + +:::warning +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. +::: + +ValidatorConfig V1 is the original precompile for managing consensus participants. All management operations are permissioned and require coordinating with the Tempo team. + +## Validator states + +Under V1, your validator goes through the following states after being added on-chain. Each transition happens on epoch boundaries. + +```mermaid +flowchart TD + A[Inactive] -->|epoch ends| B["Syncer
The validator starts syncing"] + B -->|+1 epoch| C["Syncer and Player"] + C -->|"+1 epoch, receives share"| D["Syncer
Player
Dealer"] + D -->|"once fully synced"| E["Voter ↔ Proposer"] + + click A "#not-a-participant-e" + click B "#syncer-epoch-e1" + click C "#player-epoch-e2" + click D "#dealer-epoch-e3" + click E "#dealer-epoch-e3" +``` + +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. + +#### Not a participant (E) + +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. + +#### Syncer (epoch E+1) + +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. + +#### Player (epoch E+2) + +Your validator is receiving consensus signing shares from dealers during the ceremony. + +#### Dealer (epoch E+3) + +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. + +## Key Management + +### Signing Key Rotation + +1. Generate a new keypair: + +```bash +tempo consensus generate-private-key --output +tempo consensus calculate-public-key --private-key +``` + +2. Contact the Tempo team to update your validator's public key on-chain + +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. + +:::warning +The old validator identity must be deactivated before the new one is activated. +::: + +### Signing Share Recovery + +If you lose your signing share, coordinate with the Tempo team to deactivate your old identity and register a new one. + +### Update IP Addresses + +Contact the Tempo team to update your validator's ingress and egress addresses on-chain. diff --git a/src/pages/guide/node/validator-config-v2.mdx b/src/pages/guide/node/validator-config-v2.mdx new file mode 100644 index 00000000..1e0deb6f --- /dev/null +++ b/src/pages/guide/node/validator-config-v2.mdx @@ -0,0 +1,203 @@ +--- +title: ValidatorConfig V2 +description: Manage your validator with ValidatorConfig V2. Self-service key rotation, IP updates, and ownership transfer. +--- + +# 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 becomes available after the T2 hardfork is activated and after an admin has finished the migration of entries from V1 to V2. Migration completion will be communicated to operators — you can also [check if V2 is active](#check-if-v2-is-active) yourself. + +## Validator states + +With V2, the syncer warmup phase from V1 is removed. Once added, a validator immediately becomes a player in the next epoch. + +```mermaid +flowchart TD + A[Inactive] -->|epoch ends| B["Player
Receives signing shares"] + B -->|"+1 epoch, receives share"| C["Player
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: + +- **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) +- **Transfer ownership** — rebind your validator entry to a new address +- **Fee recipient separation** — will be enabled in a future hardfork. For now, continue using `--consensus.fee-recipient` when starting your node. + +All write operations require either the contract owner or the validator's own address. + +## Precompile address + +```solidity +address constant VALIDATOR_CONFIG_V2 = 0xCCCCCCCC00000000000000000000000000000001; +``` + +## Check if V2 is active + +After the T2 hardfork, the contract owner migrates validators from V1 to V2. Use these calls to check if migration is complete and V2 is active: + +```bash +# Returns true once migration is complete and V2 is the active config +cast call 0xCCCCCCCC00000000000000000000000000000001 \ + "isInitialized()(bool)" \ + --rpc-url https://rpc.tempo.xyz + +# Returns the block height at which V2 was initialized (0 if not yet initialized) +cast call 0xCCCCCCCC00000000000000000000000000000001 \ + "getInitializedAtHeight()(uint64)" \ + --rpc-url https://rpc.tempo.xyz +``` + +If `isInitialized()` returns `true`, V2 is active and all operations on this page are available. If it returns `false`, the network is still on [ValidatorConfig V1](/guide/node/validator-config-v1). + +## Reading validator state + +### Query active validators + +Use `validators-info` to see the current state of all validators: + +```bash +tempo consensus validators-info --rpc-url https://rpc.tempo.xyz +``` + +This returns the committee of the current epoch (validators with `in_committee = true`) as well as validators that have been added but will only become active in a future epoch. Use this to verify your validator's status after registration or rotation. + +:::info +The on-chain contract represents which validators should eventually be members of the committee, not which ones currently are. Every epoch, the Tempo network performs a distribute key generation ceremony, distributing keys to validators that should be +committee members in the next epoch. So adding, deactiving, or rotating validators entries in epoch `E` can only be taken into account for the next DKG ceremony that runs during epoch `E+1`, and take effect in epoch `E+2`. +::: + +### Look up your validator + +You can query your validator by address, public key, or index: + +```bash +# By address +cast call 0xCCCCCCCC00000000000000000000000000000001 \ + "validatorByAddress(address)(bytes32,address,string,string,uint64,uint64,uint64,address)" \ + \ + --rpc-url https://rpc.tempo.xyz + +# By public key +cast call 0xCCCCCCCC00000000000000000000000000000001 \ + "validatorByPublicKey(bytes32)(bytes32,address,string,string,uint64,uint64,uint64,address)" \ + \ + --rpc-url https://rpc.tempo.xyz + +# By index +cast call 0xCCCCCCCC00000000000000000000000000000001 \ + "validatorByIndex(uint64)(bytes32,address,string,string,uint64,uint64,uint64,address)" \ + \ + --rpc-url https://rpc.tempo.xyz +``` + +The returned `Validator` struct fields are: + +| Field | Type | Description | +|-------|------|-------------| +| `publicKey` | `bytes32` | Ed25519 communication public key | +| `validatorAddress` | `address` | Validator control address | +| `ingress` | `string` | Inbound address (`IP:port`) | +| `egress` | `string` | Outbound address (`IP`) | +| `index` | `uint64` | Index of the validator (constant under rotation)| +| `addedAtHeight` | `uint64` | Block height when added | +| `deactivatedAtHeight` | `uint64` | Block height when deactivated (`0` = active) | +| `feeRecipient` | `address` | Address that receives block proposal fees | + +## Operator guide + +### Update IP addresses + +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. If you only want to update one, pass the current value for the other. + +```bash +cast send 0xCCCCCCCC00000000000000000000000000000001 \ + "setIpAddresses(uint64,string,string)" \ + \ + ":" \ + "" \ + --rpc-url https://rpc.tempo.xyz \ + --private-key +``` + +`:` and `` may remain unchanged if you only need to update one of the two. + +:::warning +Ingress addresses must be unique across all active validators. The transaction will revert if another active validator already uses the same `IP:port`. +::: + +### 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. + +The simplest way to rotate is using the `tempo` CLI, which handles signature creation and the on-chain transaction in one step: + +```bash +tempo consensus rotate-validator \ + --signing-key \ + --rpc-url https://rpc.tempo.xyz +``` + +:::info +Rotation preserves your validator index and active validator count. The old entry is appended to history as deactivated, and the entry at your index is updated in place. You must use a different ingress address (changing the port is sufficient). +::: + +After rotation, your validator goes through the [standard lifecycle](#validator-states) with the new identity. + +:::danger[Do not shut down the old validator immediately] +After rotation, the rotated-out validator is still a member of the current committee until the next successful DKG ceremony completes. Shutting it down early will degrade network liveness. + +Keep the old validator running and use `validators-info` to monitor its status: + +```bash +tempo consensus validators-info --rpc-url https://rpc.tempo.xyz +``` + +Once the old validator shows `in_committee = false`, it is safe to shut down. +::: + +#### Initial registration + +When registering a new validator, generate the add-validator signature and provide it to the Tempo team: + +```bash +tempo consensus create-add-validator-signature \ + --signing-key \ + --rpc-url https://rpc.tempo.xyz +``` + +### Transfer validator ownership + +Rebind your validator entry to a new control address: + +```bash +cast send 0xCCCCCCCC00000000000000000000000000000001 \ + "transferValidatorOwnership(uint64,address)" \ + \ + \ + --rpc-url https://rpc.tempo.xyz \ + --private-key +``` + +The new address must not already be used by another active validator. + +## 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 | + + diff --git a/src/pages/guide/node/validator.mdx b/src/pages/guide/node/validator.mdx index c09d66dc..87619d29 100644 --- a/src/pages/guide/node/validator.mdx +++ b/src/pages/guide/node/validator.mdx @@ -16,7 +16,7 @@ All validators have two kinds of keys: * signing key - this is an ED25519 keypair used to identify your validator amongst others * signing share - this is a share of a BLS12-381 keypair used to sign block notarizations and finalizations -The signing key is static and can only be rotated by removing and re-creating a validator on-chain. The signing share is dynamic and is updated periodically on each DKG ceremony. Once updated, it will be saved to disk. Currently, the DKG ceremony is scheduled to run on-chain every ~3 hours. +The signing key is static. Pre-T2, it can only be rotated by removing and re-creating a validator on-chain with the Tempo team. Post-T2, [ValidatorConfig V2](/guide/node/validator-config-v2) enables self-service rotation via the `rotateValidator` precompile. The signing share is dynamic and is updated periodically on each DKG ceremony. Once updated, it will be saved to disk. Currently, the DKG ceremony is scheduled to run on-chain every ~3 hours. ## Generating a signing key @@ -105,7 +105,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](https://docs.tempo.xyz/guide/node/operate-validator#validator-states) +- 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 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: diff --git a/vocs.config.ts b/vocs.config.ts index 8baedec2..7d26cfb4 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -664,7 +664,21 @@ export default defineConfig({ }, { text: 'Operating your validator', - link: '/guide/node/operate-validator', + collapsed: true, + items: [ + { + text: 'Overview', + link: '/guide/node/operate-validator', + }, + { + text: 'ValidatorConfig V2', + link: '/guide/node/validator-config-v2', + }, + { + text: 'ValidatorConfig V1 (Legacy)', + link: '/guide/node/validator-config-v1', + }, + ], }, { text: 'Network Upgrades and Releases', From 823bb30dcc78120aca7d0040e394d159d7451b5a Mon Sep 17 00:00:00 2001 From: Jennifer Date: Tue, 24 Mar 2026 13:25:11 +0000 Subject: [PATCH 04/11] Apply suggestions from code review Co-authored-by: Jennifer --- src/pages/protocol/upgrades/t2.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 6c0dc32c..b4e9dc8f 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -5,7 +5,7 @@ description: Details and timeline for the T2 network upgrade including compound # T2 Network Upgrade -This doc is for internal use only to inform about what is going live with T2 and when. Request for input on: Which partners should we reach out to specifically? +This page summarises new features included in the T2 network upgrade. ## Timeline From 8dffa70e0c5f0b1389f5fa2ecde34d7065f0fc40 Mon Sep 17 00:00:00 2001 From: Jennifer Date: Tue, 24 Mar 2026 13:31:12 +0000 Subject: [PATCH 05/11] Apply suggestions from code review Co-authored-by: Jennifer --- src/pages/protocol/upgrades/t2.mdx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index b4e9dc8f..7e1f4d9b 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -20,7 +20,11 @@ Partners should upgrade nodes to the T2-compatible release before the moderato a ## Overview -T2 is Tempo's next network upgrade, building on T1. It introduces compound transfer policies ([TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015)), EIP-2612 permit support for TIP-20 tokens ([TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004)), a new Validator Config V2 precompile ([TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017)), and 13 audit-driven bug fixes ([TIP-1036](https://docs.tempo.xyz/protocol/tips/tip-1036)). +T2 is Tempo's next network upgrade, building on T1. It introduces the following new features: +- Compound transfer policies ([TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015)) +- EIP-2612 permit support for TIP-20 tokens ([TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004)) +- a new Validator Config V2 precompile ([TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017)) +- and security improvements ([TIP-1036](https://docs.tempo.xyz/protocol/tips/tip-1036)). **Action required:** All node operators must upgrade to the T2-compatible release before the activation timestamp. @@ -50,7 +54,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces compound trans **Partner impact:** - **Node operators:** Node operators won't need to do anything for this migration. After the migration, operators can self-service IP updates, key rotation, and ownership transfers. -- **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. Stripe requested this feature since they didn't want their node operators to have the capability to change this key. +- **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. - **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. Combined with Reth storage v2 (which allows pruning historical data in-place), this enables validators to run in minimal mode reducing disk from hundreds of GB to a fraction. Reth v2 will be released next week. This makes Tempo's node requirements significantly lighter than comparable networks. ### TIP-1004: Permit for TIP-20 From 0c080b6d657dbbe291d5989ed0e6159bf2dc6753 Mon Sep 17 00:00:00 2001 From: Jennifer Date: Tue, 24 Mar 2026 13:34:43 +0000 Subject: [PATCH 06/11] Apply suggestions from code review Co-authored-by: Jennifer --- src/pages/protocol/upgrades/t2.mdx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 7e1f4d9b..1146adee 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -55,7 +55,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **Partner impact:** - **Node operators:** Node operators won't need to do anything for this migration. After the migration, operators can self-service IP updates, key rotation, and ownership transfers. - **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. -- **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. Combined with Reth storage v2 (which allows pruning historical data in-place), this enables validators to run in minimal mode reducing disk from hundreds of GB to a fraction. Reth v2 will be released next week. This makes Tempo's node requirements significantly lighter than comparable networks. +- **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. ### TIP-1004: Permit for TIP-20 @@ -63,7 +63,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **TLDR:** Adds EIP-2612 `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures. -**Customer use case:** Any Ramp or Commerce platform that sponsors gas for end users needs `permit()` to avoid forcing two separate transactions. Avenia was the first partner blocked on this — they can't ship their LATAM on/off-ramp flow without it. +**Customer use case:** Any Ramp or Commerce platform that sponsors gas for end users needs `permit()` to avoid forcing two separate transactions. **Partner impact:** - Users can now use `permit()` to combine approve + action in a single transaction. @@ -74,6 +74,10 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **PR:** [#3205](https://github.com/tempoxyz/tempo/pull/3205) +**(WIP)** [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) + +**PR:** [#3205](https://github.com/tempoxyz/tempo/pull/3205) + Some items that may affect partners: - If you call AccountKeychain admin functions from a contract, refactor to direct EOA calls. - If you submit AA transactions with `fee_payer == sender`, use a separate fee payer account. From 49cf7d727c46e6f69ad4c1ccfa4a29571b024439 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Tue, 24 Mar 2026 13:37:38 +0000 Subject: [PATCH 07/11] Update docs --- src/pages/protocol/upgrades/t2.mdx | 23 ++++++----------------- 1 file changed, 6 insertions(+), 17 deletions(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 1146adee..be0bc89e 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -38,7 +38,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **Customer use case:** Issuers of regulated or closed-loop tokens need to enforce different rules for senders vs recipients. For example: KYC required to on-ramp into a stablecoin, but anyone in the approved set can spend. Without compound policies, issuers must apply the same restrictions to both sides, which breaks real-world Commerce patterns and Tokenized Asset distribution flows. -**Partner impact:** +**What this enables:** - If you integrate with TIP-403 policies: new `isAuthorizedSender()`, `isAuthorizedRecipient()`, and `isAuthorizedMintRecipient()` functions are available. The existing `isAuthorized()` still works (returns `senderCheck && recipientCheck`). - If you issue TIP-20 tokens: You can now create compound policies for use cases like vendor credits, directional KYC, or asymmetric compliance. @@ -52,7 +52,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **Customer use case:** Node operators currently depend on Tempo to make any validator configuration changes. With V2, operators can self-service IP rotations, key rotations, and ownership transfers without waiting on Tempo — reducing operational dependency and enabling faster incident response. -**Partner impact:** +**What this enables:** - **Node operators:** Node operators won't need to do anything for this migration. After the migration, operators can self-service IP updates, key rotation, and ownership transfers. - **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. - **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. @@ -61,24 +61,13 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **Spec:** [TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004) -**TLDR:** Adds EIP-2612 `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures. +**TLDR:** Adds EIP-2612 compatible `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures. **Customer use case:** Any Ramp or Commerce platform that sponsors gas for end users needs `permit()` to avoid forcing two separate transactions. -**Partner impact:** +**What this enables:** - Users can now use `permit()` to combine approve + action in a single transaction. -### Meta TIP: Audit & Bug Fixes +### Meta TIP: Security Improvements -**(WIP)** [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) - -**PR:** [#3205](https://github.com/tempoxyz/tempo/pull/3205) - -**(WIP)** [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) - -**PR:** [#3205](https://github.com/tempoxyz/tempo/pull/3205) - -Some items that may affect partners: -- If you call AccountKeychain admin functions from a contract, refactor to direct EOA calls. -- If you submit AA transactions with `fee_payer == sender`, use a separate fee payer account. -- If you estimate gas for 2D nonce key transactions, update gas estimates (ref [#2533](https://github.com/tempoxyz/tempo/pull/2533)). +[TIP-1036: T2 Hardfork Improvements](https://docs.tempo.xyz/protocol/tips/tip-1036) From 9559521ce4fe0e744a2a03fc647e76f5d5411375 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Tue, 24 Mar 2026 14:06:23 +0000 Subject: [PATCH 08/11] Update docs --- src/pages/guide/node/network-upgrades.mdx | 4 +-- src/pages/guide/node/validator-config-v2.mdx | 6 ++--- src/pages/protocol/upgrades/t2.mdx | 27 +++++++++----------- 3 files changed, 17 insertions(+), 20 deletions(-) diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx index 2e39919e..95875dcb 100644 --- a/src/pages/guide/node/network-upgrades.mdx +++ b/src/pages/guide/node/network-upgrades.mdx @@ -15,7 +15,7 @@ For detailed release notes and binaries, see the [Changelog](/changelog). | Release | Date | Network | Description | Priority | |---------|------|---------|-------------|----------| -| v1.5.0 | Mar 26, 2026 | Moderato + Mainnet | Required for T2; implements compound transfer policies (TIP-1015), ValidatorConfig V2 (TIP-1017), and 14 audit-driven bug fixes (TIP-1036) | Required | +| [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), EIP-2612 permit for TIP-20 (TIP-1004), ValidatorConfig V2 (TIP-1017), and 14 audit-driven bug fixes (TIP-1036) | Required | | [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 | Recommended | | [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 | Recommended | | [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 | Recommended | @@ -30,7 +30,7 @@ For detailed release notes and binaries, see the [Changelog](/changelog). | | | |---|---| | **Scope** | Compound transfer policies, ValidatorConfig V2, and audit-driven bug fixes | -| **TIPs** | [TIP-1015: Compound Transfer Policies](https://docs.tempo.xyz/protocol/tips/tip-1015), [TIP-1017: Validator Config V2](https://docs.tempo.xyz/protocol/tips/tip-1017), [TIP-1036: T2 Hardfork Bug Fixes](https://docs.tempo.xyz/protocol/tips/tip-1036) | +| **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) | | **Release** | v1.5.0 | | **Testnet** | Moderato: Mar 26, 2026 16:00 CET (unix: 1774537200) | | **Mainnet** | Mar 31, 2026 16:00 CEST (unix: 1774965600) | diff --git a/src/pages/guide/node/validator-config-v2.mdx b/src/pages/guide/node/validator-config-v2.mdx index 1e0deb6f..cc4171b7 100644 --- a/src/pages/guide/node/validator-config-v2.mdx +++ b/src/pages/guide/node/validator-config-v2.mdx @@ -29,7 +29,7 @@ With V2, validators can perform several operations themselves without coordinati - **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) - **Transfer ownership** — rebind your validator entry to a new address -- **Fee recipient separation** — will be enabled in a future hardfork. For now, continue using `--consensus.fee-recipient` when starting your node. +- **Fee recipient separation** — will be enabled in a future release. For now, continue using `--consensus.fee-recipient` when starting your node. All write operations require either the contract owner or the validator's own address. @@ -70,8 +70,8 @@ tempo consensus validators-info --rpc-url https://rpc.tempo.xyz This returns the committee of the current epoch (validators with `in_committee = true`) as well as validators that have been added but will only become active in a future epoch. Use this to verify your validator's status after registration or rotation. :::info -The on-chain contract represents which validators should eventually be members of the committee, not which ones currently are. Every epoch, the Tempo network performs a distribute key generation ceremony, distributing keys to validators that should be -committee members in the next epoch. So adding, deactiving, or rotating validators entries in epoch `E` can only be taken into account for the next DKG ceremony that runs during epoch `E+1`, and take effect in epoch `E+2`. +The on-chain contract represents which validators should eventually be members of the committee, not which ones currently are. Every epoch, the Tempo network performs a distributed key generation ceremony, distributing keys to validators that should be +committee members in the next epoch. So adding, deactivating, or rotating validators entries in epoch `E` can only be taken into account for the next DKG ceremony that runs during epoch `E+1`, and take effect in epoch `E+2`. ::: ### Look up your validator diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index be0bc89e..595de9d5 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -9,22 +9,20 @@ This page summarises new features included in the T2 network upgrade. ## Timeline -Cut release Monday, 23rd March and send out to partners. - | Network | Date | Timestamp | |---------|------|-----------| -| Moderato (testnet) | Thursday, 24th March 4pm CET | `1774537200` | -| Presto (mainnet) | Tuesday, March 31st 4pm CET | `1774965600` | +| Moderato (testnet) | Thursday, 26th March 4pm CET | `1774537200` | +| Presto (mainnet) | Tuesday, 31st March 4pm CEST | `1774965600` | Partners should upgrade nodes to the T2-compatible release before the moderato activation timestamp. ## Overview -T2 is Tempo's next network upgrade, building on T1. It introduces the following new features: -- Compound transfer policies ([TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015)) -- EIP-2612 permit support for TIP-20 tokens ([TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004)) -- a new Validator Config V2 precompile ([TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017)) -- and security improvements ([TIP-1036](https://docs.tempo.xyz/protocol/tips/tip-1036)). +T2 is Tempo's next network upgrade, building on T1. It introduces the following new features: +- Compound transfer policies ([TIP-1015](/protocol/tips/tip-1015)) +- EIP-2612 permit support for TIP-20 tokens ([TIP-1004](/protocol/tips/tip-1004)) +- a new Validator Config V2 precompile ([TIP-1017](/protocol/tips/tip-1017)) +- and security improvements ([TIP-1036](/protocol/tips/tip-1036)). **Action required:** All node operators must upgrade to the T2-compatible release before the activation timestamp. @@ -32,7 +30,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following ### TIP-1015: Compound Transfer Policies -**Spec:** [TIP-1015](https://docs.tempo.xyz/protocol/tips/tip-1015) +**Spec:** [TIP-1015](/protocol/tips/tip-1015) **TLDR:** Extends TIP-403 policies so token issuers can set different authorization rules for senders, recipients, and mint recipients. Previously a single policy applied to both sides of a transfer. @@ -44,9 +42,9 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following ### TIP-1017: Validator Config V2 -**Spec:** [TIP-1017](https://docs.tempo.xyz/protocol/tips/tip-1017) +**Spec:** [TIP-1017](/protocol/tips/tip-1017) -**Operator guide:** [Validator Config V2](https://docs.tempo.xyz/guide/node/validator-config-v2) +**Operator guide:** [Validator Config V2](/guide/node/validator-config-v2) **TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history, stable validator indices, and fee recipient separation. @@ -54,12 +52,11 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **What this enables:** - **Node operators:** Node operators won't need to do anything for this migration. After the migration, operators can self-service IP updates, key rotation, and ownership transfers. -- **Fee recipient configuration:** Validators should now configure fee recipients on the validator v2 contract to route block fees to a dedicated treasury address. - **Minimal nodes for validators:** Validator v2 unlocks a major innovation: minimal nodes for validators. Today, validators must keep ~64,000 blocks of history to reconstruct validator sets requiring hundreds of GB of storage. V2 eliminates this requirement, letting validators query the set from the latest state only. ### TIP-1004: Permit for TIP-20 -**Spec:** [TIP-1004](https://docs.tempo.xyz/protocol/tips/tip-1004) +**Spec:** [TIP-1004](/protocol/tips/tip-1004) **TLDR:** Adds EIP-2612 compatible `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures. @@ -70,4 +67,4 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following ### Meta TIP: Security Improvements -[TIP-1036: T2 Hardfork Improvements](https://docs.tempo.xyz/protocol/tips/tip-1036) +[TIP-1036: T2 Hardfork Improvements](/protocol/tips/tip-1036) From a3ec59d85b0f48db2163c7bf13d8d24d5ec3b703 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Tue, 24 Mar 2026 14:09:59 +0000 Subject: [PATCH 09/11] Fix typos --- src/pages/guide/node/network-upgrades.mdx | 2 +- src/pages/protocol/upgrades/t2.mdx | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx index 95875dcb..5e983832 100644 --- a/src/pages/guide/node/network-upgrades.mdx +++ b/src/pages/guide/node/network-upgrades.mdx @@ -15,7 +15,7 @@ For detailed release notes and binaries, see the [Changelog](/changelog). | Release | Date | Network | Description | Priority | |---------|------|---------|-------------|----------| -| [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), EIP-2612 permit for TIP-20 (TIP-1004), ValidatorConfig V2 (TIP-1017), and 14 audit-driven bug fixes (TIP-1036) | Required | +| [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) | Required | | [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 | Recommended | | [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 | Recommended | | [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 | Recommended | diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 595de9d5..13010e2d 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -1,6 +1,6 @@ --- title: T2 Network Upgrade -description: Details and timeline for the T2 network upgrade including compound transfer policies, Validator Config V2, EIP-2612 permit, and audit-driven bug fixes. +description: Details and timeline for the T2 network upgrade including compound transfer policies, Validator Config V2, permit support for TIP-20, and audit-driven bug fixes. --- # T2 Network Upgrade @@ -20,7 +20,7 @@ Partners should upgrade nodes to the T2-compatible release before the moderato a T2 is Tempo's next network upgrade, building on T1. It introduces the following new features: - Compound transfer policies ([TIP-1015](/protocol/tips/tip-1015)) -- EIP-2612 permit support for TIP-20 tokens ([TIP-1004](/protocol/tips/tip-1004)) +- Permit support for TIP-20 tokens ([TIP-1004](/protocol/tips/tip-1004)) - a new Validator Config V2 precompile ([TIP-1017](/protocol/tips/tip-1017)) - and security improvements ([TIP-1036](/protocol/tips/tip-1036)). From 753f72a703d07b09decffa87f4b8db2ed0d738db Mon Sep 17 00:00:00 2001 From: jenpaff Date: Tue, 24 Mar 2026 14:11:06 +0000 Subject: [PATCH 10/11] Remove fee recipient separation mentioned --- src/pages/guide/node/validator-config-v2.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/src/pages/guide/node/validator-config-v2.mdx b/src/pages/guide/node/validator-config-v2.mdx index cc4171b7..94fbbecb 100644 --- a/src/pages/guide/node/validator-config-v2.mdx +++ b/src/pages/guide/node/validator-config-v2.mdx @@ -29,7 +29,6 @@ With V2, validators can perform several operations themselves without coordinati - **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) - **Transfer ownership** — rebind your validator entry to a new address -- **Fee recipient separation** — will be enabled in a future release. For now, continue using `--consensus.fee-recipient` when starting your node. All write operations require either the contract owner or the validator's own address. From 3504fdc290cc36571a2821977ed6382e988963a6 Mon Sep 17 00:00:00 2001 From: Jennifer Date: Tue, 24 Mar 2026 14:12:08 +0000 Subject: [PATCH 11/11] Apply suggestion from @jenpaff --- src/pages/protocol/upgrades/t2.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 13010e2d..4b6ec8c8 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/src/pages/protocol/upgrades/t2.mdx @@ -46,7 +46,7 @@ T2 is Tempo's next network upgrade, building on T1. It introduces the following **Operator guide:** [Validator Config V2](/guide/node/validator-config-v2) -**TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history, stable validator indices, and fee recipient separation. +**TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history and stable validator indices. **Customer use case:** Node operators currently depend on Tempo to make any validator configuration changes. With V2, operators can self-service IP rotations, key rotations, and ownership transfers without waiting on Tempo — reducing operational dependency and enabling faster incident response.