Skip to content

docs: shift T2-T4 upgrade pages to past tense, polish T5 #440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
max-digi merged 3 commits into from
May 25, 2026
+70 −66
Merged

docs: shift T2-T4 upgrade pages to past tense, polish T5 #440

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
94d76bf
docs: clarify network upgrade sidebar labels
max-digi May 19, 2026
a3600b0
docs: shift T2-T4 upgrade pages to past tense, polish T5
max-digi May 25, 2026
d7f4ceb
docs: drop Moderato/Presto naming, use testnet/mainnet only
max-digi May 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 26 additions & 24 deletions src/pages/protocol/upgrades/t2.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,66 +5,68 @@ description: Details and timeline for the T2 network upgrade including compound

# T2 Network Upgrade

This page summarises new features included in the T2 network upgrade.
This page summarises the features that shipped in the T2 network upgrade.

:::info[T2 status]
T2 is active on both testnet and mainnet.
:::

## Timeline

| Network | Date | Timestamp |
|---------|------|-----------|
| Moderato (testnet) | Thursday, 26th March 4pm CET | `1774537200` |
| Presto (mainnet) | Tuesday, 31st March 4pm CEST | `1774965600` |
| Testnet | Thursday, 26th March 4pm CET | `1774537200` |
| Mainnet | Tuesday, 31st March 4pm CEST | `1774965600` |

Partners should upgrade nodes to the T2-compatible release before the moderato activation timestamp.
Node operators needed to upgrade to the T2-compatible release before the testnet 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://github.com/tempoxyz/tempo/blob/main/tips/tip-1015.md))
- Permit support for TIP-20 tokens ([TIP-1004](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1004.md))
- a new Validator Config V2 precompile ([TIP-1017](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1017.md))
- and security improvements ([TIP-1036](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1036.md)).

**Action required:** All node operators must upgrade to the T2-compatible release before the activation timestamp.
T2 built on T1 and introduced the following features:
- Compound transfer policies ([TIP-1015](https://tips.sh/1015))
- Permit support for TIP-20 tokens ([TIP-1004](https://tips.sh/1004))
- A new Validator Config V2 precompile ([TIP-1017](https://tips.sh/1017))
- Security improvements ([TIP-1036](https://tips.sh/1036))

## Feature TIPs

### TIP-1015: Compound Transfer Policies

**Spec:** [TIP-1015](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1015.md)
**Spec:** [TIP-1015](https://tips.sh/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.
**TLDR:** Extended 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.
**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 had to apply the same restrictions to both sides, which broke real-world Commerce patterns and Tokenized Asset distribution flows.

**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.
- 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://github.com/tempoxyz/tempo/blob/main/tips/tip-1017.md)
**Spec:** [TIP-1017](https://tips.sh/1017)

**Operator guide:** [Controlling validator lifecycle](/guide/node/validator-lifecycle)

**TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history and stable validator indices.
**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.
**Customer use case:** Before V2, node operators depended 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.

**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.
- **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.
- **Node operators:** Node operators didn't need to take action for the migration itself. Operators can now self-service IP updates, key rotation, and ownership transfers.
- **Minimal nodes for validators:** Validator V2 unlocks minimal nodes for validators. Previously, validators had to keep ~64,000 blocks of history to reconstruct validator sets, requiring hundreds of GB of storage. V2 removes that requirement, letting validators query the set from the latest state only.

### TIP-1004: Permit for TIP-20

**Spec:** [TIP-1004](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1004.md)
**Spec:** [TIP-1004](https://tips.sh/1004)

**TLDR:** Adds EIP-2612 compatible `permit()` to all TIP-20 tokens, enabling gasless approvals via off-chain signatures.
**TLDR:** Added 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.

**What this enables:**
- Users can now use `permit()` to combine approve + action in a single transaction.
- Users can use `permit()` to combine approve + action in a single transaction.

### Meta TIP: Security Improvements

[TIP-1036: T2 Hardfork Improvements](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1036.md)
[TIP-1036: T2 Hardfork Improvements](https://tips.sh/1036)
39 changes: 18 additions & 21 deletions src/pages/protocol/upgrades/t3.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,51 +5,52 @@ description: Details and timeline for the T3 network upgrade, including enhanced

# T3 Network Upgrade

T3 is the next Tempo protocol upgrade. It introduces enhanced access keys, a standard signature verification precompile, and virtual addresses for TIP-20 deposit routing.
T3 introduced enhanced access keys, a standard signature verification precompile, and virtual addresses for TIP-20 deposit routing.

:::info[T3 status]
T3 is active on both testnet and mainnet.
:::

## Timeline

| Network | Date | Timestamp |
|---------|------|-----------|
| Moderato (testnet) | April 21, 2026 4pm CEST | `1776780000` |
| Presto (mainnet) | April 27, 2026 4pm CEST | `1777298400` |
| Testnet | April 21, 2026 4pm CEST | `1776780000` |
| Mainnet | April 27, 2026 4pm CEST | `1777298400` |

Partners should upgrade nodes to the T3-compatible release before the Moderato activation timestamp.
Node operators needed to upgrade to the T3-compatible release before the testnet activation timestamp.

## Overview

| TIP | What it does | Who should review |
|-----|-------------|-------------------|
| [TIP-1011](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1011.md) | Periodic spending limits, call scoping, and a ban on access-key contract creation | Wallets, account SDKs, apps using connected apps or subscriptions |
| [TIP-1020](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1020.md) | Signature verification precompile for secp256k1, P256, and WebAuthn | Smart contract teams, account integrators, wallet SDKs |
| [TIP-1022](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1022.md) | [Virtual addresses](/protocol/tip20/virtual-addresses) for TIP-20 deposit forwarding | Exchanges, ramps, custodians, payment processors, explorers, indexers |
| [TIP-1011](https://tips.sh/1011) | Periodic spending limits, call scoping, and a ban on access-key contract creation | Wallets, account SDKs, apps using connected apps or subscriptions |
| [TIP-1020](https://tips.sh/1020) | Signature verification precompile for secp256k1, P256, and WebAuthn | Smart contract teams, account integrators, wallet SDKs |
| [TIP-1022](https://tips.sh/1022) | [Virtual addresses](/protocol/tip20/virtual-addresses) for TIP-20 deposit forwarding | Exchanges, ramps, custodians, payment processors, explorers, indexers |

## Breaking changes

These breaking changes only affect access-key integrations. You need to update your integration if you create new access keys, manually encode `key_authorization` or `authorizeKey(...)`, or rely on access-key-signed deployment flows. Existing authorized keys continue to work.

### Access-key authorization ABI

Integrations that directly call `AccountKeychain.authorizeKey(...)` or manually encode `key_authorization` must migrate to the TIP-1011 format after activation. Legacy calls fail with `LegacyAuthorizeKeySelectorChanged(newSelector: 0x980a6025)`.

- **Before activation:** use the legacy ABI. The TIP-1011 format is not yet valid onchain.
- **After activation:** use the TIP-1011 tuple-form ABI. The legacy selector `0x54063a55` stops working.
Integrations that directly call `AccountKeychain.authorizeKey(...)` or manually encode `key_authorization` must use the TIP-1011 tuple-form ABI. The legacy selector `0x54063a55` no longer works — legacy calls fail with `LegacyAuthorizeKeySelectorChanged(newSelector: 0x980a6025)`.

If you use an updated SDK, this is mostly a tooling upgrade. If you support both pre-T3 and post-T3 networks, branch on network version or activation timestamp. If you hand-encode calldata, use the exact tuple-form signature from the [Account Keychain precompile spec](/protocol/transactions/AccountKeychain).
If you use an updated SDK, this is mostly a tooling upgrade. If you hand-encode calldata, use the exact tuple-form signature from the [Account Keychain precompile spec](/protocol/transactions/AccountKeychain).

### Access-key contract creation

Post-T3, access-key-signed transactions can no longer create contracts in any configuration — including direct CREATE, factory CREATE, and internal CREATE2. Move those flows to a root key path.
Access-key-signed transactions can no longer create contracts in any configuration — including direct CREATE, factory CREATE, and internal CREATE2. Move those flows to a root key path.

### Migration checklist

- Upgrade to a T3-compatible SDK release listed below
- Regenerate contract bindings or replace handcrafted encoders for `authorizeKey(...)`
- Move any access-key contract-creation flows to a root key path
- If you adopt virtual addresses, collapse the two-hop `Transfer` pair into one logical deposit to the registered master wallet rather than treating the virtual address hop as a separate transfer
- Test key creation, key rotation, and recovery flows on Moderato after T3 activates
- Test key creation, key rotation, and recovery flows on testnet

Most integrators only need to upgrade tooling. Existing authorized access keys keep working.
Most integrators only needed to upgrade tooling. Existing authorized access keys keep working.

## Supporting new features

Expand All @@ -61,7 +62,7 @@ See [Virtual addresses for TIP-20 deposits](/protocol/tip20/virtual-addresses) f

### Signature verification precompile

[TIP-1020](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1020.md) is additive — existing verifier setups keep working. Teams that want a standard onchain verification surface can adopt the precompile instead of maintaining custom verifier contracts. See the [Signature Verification with Foundry](/sdk/foundry/signature-verifier) guide.
[TIP-1020](https://tips.sh/1020) is additive — existing verifier setups keep working. Teams that want a standard onchain verification surface can adopt the precompile instead of maintaining custom verifier contracts. See the [Signature Verification with Foundry](/sdk/foundry/signature-verifier) guide.

## Compatible SDK releases

Expand All @@ -75,11 +76,7 @@ Tempo's broader tooling ecosystem is available in [Developer tools](/quickstart/
| [Python](https://github.com/tempoxyz/pytempo) | [`0.5.0`](https://github.com/tempoxyz/pytempo/releases/tag/pytempo%400.5.0) |
| [Foundry](https://github.com/foundry-rs/foundry) | [`v1.7.0`](https://github.com/foundry-rs/foundry/releases/tag/v1.7.0) |

:::note[Current SDK caveat]
The Accounts SDK and `wallet_authorizeAccessKey` docs still describe the legacy pre-T3 access-key shape. Until their T3 support lands, use the protocol specs and the T3-compatible SDK releases above for the post-T3 `authorizeKey(...)` ABI.
:::

## Related docs
- [Virtual addresses for TIP-20 deposits](/protocol/tip20/virtual-addresses)
- [TIP-1022](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1022.md)
- [TIP-1022](https://tips.sh/1022)
- Coordinating meta TIP: [tempoxyz/tempo#3273](https://github.com/tempoxyz/tempo/pull/3273)
27 changes: 16 additions & 11 deletions src/pages/protocol/upgrades/t4.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,35 +8,40 @@ description: Details and timeline for the T4 network upgrade, including consensu
This page summarizes T4 scope.

:::info[T4 status]
T4 is active on both Moderato (testnet) and Presto (mainnet).
T4 is active on both testnet and mainnet.
:::

## Timeline

| Network | Date | Timestamp |
|---------|------|-----------|
| Moderato (testnet) | May 14, 2026 4pm CEST | `1778767200` |
| Presto (mainnet) | May 18, 2026 4pm CEST | `1779112800` |
| Testnet | May 14, 2026 4pm CEST | `1778767200` |
| Mainnet | May 18, 2026 4pm CEST | `1779112800` |

Node operators needed to upgrade to the T4-compatible release (v1.7.0, released May 11, 2026 4pm CEST) before the Moderato activation timestamp.
Node operators needed to upgrade to the T4-compatible release (v1.7.0, released May 11, 2026 4pm CEST) before the testnet activation timestamp.

## Overview

T4 is Tempo's current network upgrade. It introduced the following changes:
- Embedding consensus context into the block header to unlock deferred verification and reduce finalization latency ([TIP-1031](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1031.md))
- A bundle of T4 bug fixes and security hardening (https://tips.sh/1046)
T4 introduced the following changes:
- Embedding consensus context into the block header to unlock deferred verification and reduce finalization latency ([TIP-1031](https://tips.sh/1031))
- A bundle of bug fixes and security hardening ([TIP-1046](https://tips.sh/1046))

## Compatible SDK releases

T4-compatible SDK releases will be listed here as they ship.
| SDK | T4-compatible release |
|-----|-----------------------|
| [Rust](https://github.com/tempoxyz/tempo) | [`tempo-alloy@1.7.0`](https://github.com/tempoxyz/tempo/releases/tag/tempo-alloy%401.7.0), [`tempo-primitives@1.7.0`](https://github.com/tempoxyz/tempo/releases/tag/tempo-primitives%401.7.0), [`tempo-contracts@1.7.0`](https://github.com/tempoxyz/tempo/releases/tag/tempo-contracts%401.7.0) |
| [Foundry](https://github.com/foundry-rs/foundry) | nightly (T4 hardfork-aware decoding) |

See [Developer tools](/quickstart/developer-tools) for the broader SDK ecosystem.

## Related docs
- [Network upgrades and releases](/guide/node/network-upgrades)
- [TIP-1031: Embed Consensus Context in the Block Header](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1031.md)
- [TIP-1046: T4 Hardfork Meta TIP](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1046.md)
- [TIP-1031: Embed Consensus Context in the Block Header](https://tips.sh/1031)
- [TIP-1046: T4 Hardfork Meta TIP](https://tips.sh/1046)

## Feature TIPs

### TIP-1031: Embed Consensus Context in the Block Header

[TIP-1031](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1031.md) adds an optional `Context` field (epoch, view, parent view, leader) as the last field of `TempoHeader`. This commits consensus metadata to the block hash so Tempo blocks implement Commonware's `CertifiableBlock` trait, enabling deferred verification (optimistic notarization with async background verification) and reduced finalization latency. Pre-activation headers are unchanged; post-activation headers require the field and validators reject mismatched context.
[TIP-1031](https://tips.sh/1031) added an optional `Context` field (epoch, view, parent view, leader) as the last field of `TempoHeader`. This commits consensus metadata to the block hash so Tempo blocks implement Commonware's `CertifiableBlock` trait, enabling deferred verification (optimistic notarization with async background verification) and reduced finalization latency. Pre-T4 headers are unchanged; post-T4 headers require the field, and validators reject mismatched context.
12 changes: 6 additions & 6 deletions src/pages/protocol/upgrades/t5.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,18 +7,18 @@ description: Details and timeline for the T5 network upgrade, including the ensh

T5 is Tempo's next network upgrade. It introduces an enshrined TIP-20 escrow channel precompile for MPP and similar session-based payment flows, payment lane classification in consensus, DEX improvements (same-tick flip orders and persistent order IDs across flips), multihop FeeAMM routing, an on-chain `logoURI` field for TIP-20 tokens, an Implicit Approvals List for gas-efficient internal transfers, and a witness digest binding for one-signature key authorization flows.

:::info[T5 is not live yet]
The features described on this page are scheduled for T5 and are not active on Moderato or Presto yet. They only become live once the T5 activation timestamps are reached.
:::info[T5 status]
T5 is not yet active on testnet or mainnet. The features described on this page become live at the activation timestamps below.
:::

## Timeline

| Network | Date | Timestamp |
|---------|------|-----------|
| Moderato (testnet) | June 3, 2026 | TBD |
| Presto (mainnet) | June 9, 2026 | TBD |
| Testnet | June 3, 2026 | TBD |
| Mainnet | June 9, 2026 | TBD |

Node operators must upgrade to the T5-compatible release (v1.8.0, targeted for May 27, 2026) before the Moderato activation timestamp.
Node operators must upgrade to the T5-compatible release (v1.8.0, targeted for May 27, 2026) before the testnet activation timestamp.

## Overview

Expand All @@ -32,7 +32,7 @@ T5 introduces the following changes:
- An Implicit Approvals List enabling listed precompiles to pull TIP-20 tokens without a prior approval ([TIP-1035](https://tips.sh/1035))
- A witness digest field in key authorizations to bind one signature to an application challenge ([TIP-1053](https://tips.sh/1053))

**Action required for node operators:** Upgrade to v1.8.0 before the Moderato activation timestamp. Non-upgraded nodes will fall out of consensus.
**Action required for node operators:** Upgrade to v1.8.0 before the testnet activation timestamp. Non-upgraded nodes will fall out of consensus.

## Integration changes

Expand Down
Loading
Loading