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

* docs: clarify network upgrade sidebar labels

- Remove (Active) labels from T2 and T3
- Add (Latest) next to T4
- Add (Next) next to T5

Amp-Thread-ID: https://ampcode.com/threads/T-019e41c7-3c78-7429-8c11-8e48e079ba59
Co-authored-by: Amp <amp@ampcode.com>

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

- T2: add status callout, switch overview/feature copy to past tense,
  normalize TIP links to tips.sh, drop pre-activation 'action required'
- T3: add status callout, drop pre/post-activation framing, simplify
  ABI migration text, remove stale SDK caveat, switch TIP links to
  tips.sh
- T4: drop 'current upgrade' framing, populate compatible SDK
  releases table from v1.7.0 release notes, fix bare URL for TIP-1046,
  normalize TIP links to tips.sh, past-tense TIP-1031 description
- T5: rename status callout to match T2-T4 pattern

Amp-Thread-ID: https://ampcode.com/threads/T-019e5e4e-9067-705c-9cd1-fb81d04f4cc4
Co-authored-by: Amp <amp@ampcode.com>

* docs: drop Moderato/Presto naming, use testnet/mainnet only

Replaces 'Moderato (testnet)' and 'Presto (mainnet)' in the timeline
tables and surrounding copy with plain 'Testnet' and 'Mainnet' across
T2-T5.

Amp-Thread-ID: https://ampcode.com/threads/T-019e5e4e-9067-705c-9cd1-fb81d04f4cc4
Co-authored-by: Amp <amp@ampcode.com>

---------

Co-authored-by: Amp <amp@ampcode.com>

Author: max-digi

src/pages/protocol/upgrades/t2.mdx

@@ -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)

src/pages/protocol/upgrades/t3.mdx

@@ -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
 
@@ -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
 
@@ -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)

src/pages/protocol/upgrades/t4.mdx

@@ -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.

src/pages/protocol/upgrades/t5.mdx

@@ -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 reserve 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
 
@@ -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