diff --git a/src/pages/protocol/upgrades/t2.mdx b/src/pages/protocol/upgrades/t2.mdx index 5d0f95d8..50830604 100644 --- a/src/pages/protocol/upgrades/t2.mdx +++ b/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) diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx index 9d68b922..4a6e74ca 100644 --- a/src/pages/protocol/upgrades/t3.mdx +++ b/src/pages/protocol/upgrades/t3.mdx @@ -5,24 +5,28 @@ 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 @@ -30,16 +34,13 @@ These breaking changes only affect access-key integrations. You need to update y ### 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 @@ -47,9 +48,9 @@ Post-T3, access-key-signed transactions can no longer create contracts in any co - 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) diff --git a/src/pages/protocol/upgrades/t4.mdx b/src/pages/protocol/upgrades/t4.mdx index bc7a56bf..4335da75 100644 --- a/src/pages/protocol/upgrades/t4.mdx +++ b/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. diff --git a/src/pages/protocol/upgrades/t5.mdx b/src/pages/protocol/upgrades/t5.mdx index 42f56cd2..9ad80813 100644 --- a/src/pages/protocol/upgrades/t5.mdx +++ b/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 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 @@ -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 diff --git a/vocs.config.ts b/vocs.config.ts index fa3db871..318d478c 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -725,19 +725,19 @@ export default defineConfig({ collapsed: true, items: [ { - text: 'T5', + text: 'T5 (Next)', link: '/protocol/upgrades/t5', }, { - text: 'T4 (Active)', + text: 'T4 (Latest)', link: '/protocol/upgrades/t4', }, { - text: 'T3 (Active)', + text: 'T3', link: '/protocol/upgrades/t3', }, { - text: 'T2 (Active)', + text: 'T2', link: '/protocol/upgrades/t2', }, ],