From 6f3805f2bc80c555559e4a26426f066f5b140e5c Mon Sep 17 00:00:00 2001 From: jenpaff Date: Thu, 2 Apr 2026 18:01:31 +0100 Subject: [PATCH 1/5] Add context about upcoming t3 network upgrade --- src/pages/guide/node/network-upgrades.mdx | 18 ++++ src/pages/protocol/upgrades/t3.mdx | 126 ++++++++++++++++++++++ vocs.config.ts | 4 + 3 files changed, 148 insertions(+) create mode 100644 src/pages/protocol/upgrades/t3.mdx diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx index 5e983832..f9532dd9 100644 --- a/src/pages/guide/node/network-upgrades.mdx +++ b/src/pages/guide/node/network-upgrades.mdx @@ -25,6 +25,24 @@ For detailed release notes and binaries, see the [Changelog](/changelog). --- +## T3 + +| | | +|---|---| +| **Scope** | Enhanced access keys with periodic limits, call scoping, and an authorization ABI update; signature verification precompile; virtual addresses for TIP-20 deposit forwarding; and security hardening and gas correctness fixes | +| **TIPs** | [TIP-1011: Enhanced Access Key Permissions](/protocol/tips/tip-1011), [TIP-1020: Signature Verification Precompile](/protocol/tips/tip-1020), [TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding](/protocol/tips/tip-1022), TIP-1038: T3 security hardening and gas correctness fixes | +| **Details** | [T3 network upgrade](/protocol/upgrades/t3) | +| **Release** | T3-compatible release coming soon | +| **Testnet** | Moderato: Apr 22, 2026 16:00 CEST (unix: TBD) | +| **Mainnet** | Presto: Apr 27, 2026 16:00 CEST (unix: TBD) | +| **Priority** | Required | + +All node operators should upgrade before the Moderato activation date, even if they do not plan to use the new T3 feature set directly. + +Partners that create or rotate access keys should also review the T3 upgrade page. Existing authorized access keys remain valid, but key authorization flows must move to the new TIP-1011 ABI after activation. + +--- + ## T2 | | | diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx new file mode 100644 index 00000000..b12c951b --- /dev/null +++ b/src/pages/protocol/upgrades/t3.mdx @@ -0,0 +1,126 @@ +--- +title: T3 Network Upgrade +description: Details and timeline for the T3 network upgrade, including enhanced access keys, signature verification, virtual addresses, and security hardening and gas correctness fixes. +--- + +# T3 Network Upgrade + +This page summarizes the features, partner impact, and breaking changes included in the T3 network upgrade. + +:::warning[T3 is not live yet] +The features described on this page are scheduled for T3 and are not active on Moderato or Presto yet. They only become live once the T3 activation timestamps are reached. +::: + +## Timeline + +| Network | Date | Timestamp | +|---------|------|-----------| +| Moderato (testnet) | April 22, 2026 4pm CEST | `TBD` | +| Presto (mainnet) | April 27, 2026 4pm CEST | `TBD` | + +Partners should upgrade nodes to the T3-compatible release before the Moderato activation timestamp. + +## Overview + +T3 is Tempo's next network upgrade. It introduces the following changes: +- Enhanced access key permissions with periodic spending limits, call scoping, and a protocol-level ban on access-key contract creation ([TIP-1011](/protocol/tips/tip-1011)) +- A signature verification precompile for secp256k1, P256, and WebAuthn signatures ([TIP-1020](/protocol/tips/tip-1020)) +- Virtual addresses for TIP-20 deposit forwarding ([TIP-1022](/protocol/tips/tip-1022)) +- Security hardening and gas correctness fixes (TIP-1038) + +**Action required:** All node operators must upgrade to the T3-compatible release before the activation timestamp. + +## Partner impact + +| Area | Who should review | Summary | +|------|-------------------|---------| +| Access keys | Wallets, account SDKs, and apps using connected apps or subscriptions | Existing authorized access keys remain valid for delegated transaction flows. T3 adds optional periodic limits and call scoping, bans contract creation from access-key transactions, and changes the authorization ABI used to create or rotate keys. | +| Signature verification precompile | Smart contract teams, account integrators, and wallet SDKs | Contracts can verify secp256k1, P256, and WebAuthn signatures through one precompile instead of custom verifier contracts. | +| Virtual addresses | Exchanges, ramps, custodians, and payment processors | Partners can generate per-user TIP-20 deposit addresses that forward to a registered master wallet. Explorers and indexers should display forwarded deposits correctly. | +| Node upgrades | Node operators, RPC providers, and infra teams | T3 also includes security hardening and gas correctness fixes. All operators should roll out the T3-compatible release before activation, even if they do not plan to use the new features directly. | + +## Breaking changes + +Partners that create or update access keys should upgrade to a T3-compatible SDK release before activation. + +T3 introduces one breaking change for access-key integrations. + +### Breaking change for access-key integrations + +**What stays the same:** Existing authorized access keys continue to work after T3 activates. + +**What changes:** T3 replaces the legacy `AccountKeychain.authorizeKey(...)` ABI with the new TIP-1011 authorization format. This only affects flows that create, rotate, or re-authorize access keys. + +**Before activation:** Integrations must continue using the legacy `AccountKeychain.authorizeKey(...)` ABI. The TIP-1011 authorization format is not yet valid onchain. + +**After activation:** Integrations must use the TIP-1011 authorization format. Legacy calls fail with `LegacyAuthorizeKeySelectorChanged`, sometimes surfaced as `LegacyAuthorizeKeySelectorChanged(newSelector: 0x980a6025)`. + +Affected flows include: + +- creating a new access key +- authorizing an access key during onboarding or setup +- rotating or re-authorizing a key if that path still uses the old ABI +- any SDK or script wrapper that still encodes the legacy `authorizeKey` call + +## Compatible SDK releases + +Tempo's broader tooling ecosystem is available in [Developer tools](/quickstart/developer-tools). + +| SDK | T3-compatible release | +|-----|-----------------------| +| TypeScript | `TBD` | +| Rust | `TBD` | +| Go | `TBD` | +| Python | `TBD` | +| Foundry | `TBD` | + +Versions will be added here once a T3-compatible release has been published for each SDK. + +## Related docs + +- [Account Keychain precompile](/protocol/transactions/AccountKeychain) +- [Predeployed contracts](/quickstart/predeployed-contracts) +- Virtual addresses guide: coming soon +- Subscription and recurring-permissions guide: coming soon + +## Feature TIPs + +### TIP-1011: Enhanced Access Key Permissions + +**Spec:** [TIP-1011](/protocol/tips/tip-1011) + +**TLDR:** Adds periodic spending limits and call scoping to access keys. This lets users authorize patterns such as "up to 10 USDC per month" or "only call this contract for this recipient." + +**Customer use case:** Recurring billing, subscriptions, payroll, and app-specific permissions all become easier to implement without repeated approvals. + +**Integrator note:** Existing authorized access keys remain valid, but any flow that authorizes or re-authorizes a key must move to the new TIP-1011 ABI after activation. + +### TIP-1020: Signature Verification Precompile + +**Spec:** [TIP-1020](/protocol/tips/tip-1020) + +**TLDR:** Adds a single precompile for verifying secp256k1, P256, and WebAuthn signatures onchain. + +**Customer use case:** Contracts can support passkeys, multisigs, governance approvals, and subscription flows without deploying custom verifier contracts for each signature type. + +**Integrator note:** Keychain signatures still need `AccountKeychain` for key resolution. This precompile covers the underlying signature schemes, not the full keychain authorization flow. + +### TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding + +**Spec:** [TIP-1022](/protocol/tips/tip-1022) + +**TLDR:** Lets partners issue per-user deposit addresses that forward TIP-20 deposits to a registered master wallet at the protocol level. + +**Customer use case:** Exchanges, ramps, custodians, and payment processors can support large-scale deposit infrastructure without sweep transactions or per-user onchain wallets. + +**Integrator note:** Forwarding applies to TIP-20 transfer paths. Explorers, indexers, and backend systems should treat forwarded deposits as deposits to the registered master wallet. + +### T3 hardening and gas correctness fixes + +**Reference:** TIP-1038 + +**TLDR:** T3 includes a set of security hardening and gas correctness fixes that ship alongside the new feature work. + +**Customer use case:** Most users will experience this as improved reliability and safer execution rather than a new integration surface. + +**Partner impact:** All node operators should treat the T3-compatible release as required infrastructure work, even if their application does not use access keys, signature verification, or virtual addresses directly. diff --git a/vocs.config.ts b/vocs.config.ts index 77c68a8a..e6af94f5 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -520,6 +520,10 @@ export default defineConfig({ text: 'Network Upgrades', collapsed: true, items: [ + { + text: 'T3', + link: '/protocol/upgrades/t3', + }, { text: 'T2', link: '/protocol/upgrades/t2', From 5dc25498a216d39aea4ca6582224ea27511f4e52 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Thu, 2 Apr 2026 20:30:39 +0100 Subject: [PATCH 2/5] Update feature tip section --- src/pages/protocol/upgrades/t3.mdx | 37 +++--------------------------- 1 file changed, 3 insertions(+), 34 deletions(-) diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx index b12c951b..417dc12b 100644 --- a/src/pages/protocol/upgrades/t3.mdx +++ b/src/pages/protocol/upgrades/t3.mdx @@ -77,9 +77,6 @@ Tempo's broader tooling ecosystem is available in [Developer tools](/quickstart/ Versions will be added here once a T3-compatible release has been published for each SDK. ## Related docs - -- [Account Keychain precompile](/protocol/transactions/AccountKeychain) -- [Predeployed contracts](/quickstart/predeployed-contracts) - Virtual addresses guide: coming soon - Subscription and recurring-permissions guide: coming soon @@ -87,40 +84,12 @@ Versions will be added here once a T3-compatible release has been published for ### TIP-1011: Enhanced Access Key Permissions -**Spec:** [TIP-1011](/protocol/tips/tip-1011) - -**TLDR:** Adds periodic spending limits and call scoping to access keys. This lets users authorize patterns such as "up to 10 USDC per month" or "only call this contract for this recipient." - -**Customer use case:** Recurring billing, subscriptions, payroll, and app-specific permissions all become easier to implement without repeated approvals. - -**Integrator note:** Existing authorized access keys remain valid, but any flow that authorizes or re-authorizes a key must move to the new TIP-1011 ABI after activation. +[TIP-1011](/protocol/tips/tip-1011) adds periodic spending limits and call scoping to access keys, including restrictions on which contracts a key can call and, for common token flows, which recipient it can target. This gives wallets, account SDKs, and apps a safer way to offer delegated permissions for recurring billing, subscription renewals, payroll, connected-app approvals, or agent budgets without asking the user to approve every transaction manually. For existing partners, previously authorized access keys continue to work after activation, but any flow that creates, rotates, or re-authorizes a key must move to the new TIP-1011 ABI, and access-key transactions can no longer be used for contract creation. ### TIP-1020: Signature Verification Precompile -**Spec:** [TIP-1020](/protocol/tips/tip-1020) - -**TLDR:** Adds a single precompile for verifying secp256k1, P256, and WebAuthn signatures onchain. - -**Customer use case:** Contracts can support passkeys, multisigs, governance approvals, and subscription flows without deploying custom verifier contracts for each signature type. - -**Integrator note:** Keychain signatures still need `AccountKeychain` for key resolution. This precompile covers the underlying signature schemes, not the full keychain authorization flow. +[TIP-1020](/protocol/tips/tip-1020) adds a single precompile for verifying secp256k1, P256, and WebAuthn signatures onchain. This gives smart contract teams, wallet builders, and account integrators a standard verification surface for passkey wallets, multisigs, governance approvals, subscription authorization, and other signature-driven flows without deploying and maintaining custom verifier contracts for each signature type. This change is additive for existing partners: nothing breaks if you keep your current verifier setup, but teams that want simpler integrations or forward-compatible support for Tempo signature types can adopt the precompile. Keychain signatures still need `AccountKeychain` for key resolution, so this precompile covers the underlying signature schemes rather than the full keychain authorization flow. ### TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding -**Spec:** [TIP-1022](/protocol/tips/tip-1022) - -**TLDR:** Lets partners issue per-user deposit addresses that forward TIP-20 deposits to a registered master wallet at the protocol level. - -**Customer use case:** Exchanges, ramps, custodians, and payment processors can support large-scale deposit infrastructure without sweep transactions or per-user onchain wallets. - -**Integrator note:** Forwarding applies to TIP-20 transfer paths. Explorers, indexers, and backend systems should treat forwarded deposits as deposits to the registered master wallet. - -### T3 hardening and gas correctness fixes - -**Reference:** TIP-1038 - -**TLDR:** T3 includes a set of security hardening and gas correctness fixes that ship alongside the new feature work. - -**Customer use case:** Most users will experience this as improved reliability and safer execution rather than a new integration surface. - -**Partner impact:** All node operators should treat the T3-compatible release as required infrastructure work, even if their application does not use access keys, signature verification, or virtual addresses directly. +[TIP-1022](/protocol/tips/tip-1022) lets partners issue per-user deposit addresses that forward TIP-20 deposits to a registered master wallet at the protocol level. This is useful for exchanges, ramps, custodians, and payment processors that want one deposit address per customer for reconciliation, attribution, or account crediting, but do not want to maintain sweep jobs or fund separate onchain wallets for every user. For existing partners, nothing changes unless you adopt virtual addresses, but teams that do should update explorers, indexers, and backend systems to treat forwarded deposits as deposits to the registered master wallet. Forwarding applies only to TIP-20 transfer paths. From 5abd24ef0fd3de6db8d42f51b7d9a12d80485484 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Thu, 2 Apr 2026 20:35:02 +0100 Subject: [PATCH 3/5] small fixes in the docs --- src/pages/protocol/upgrades/t3.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx index 417dc12b..5c2cc81e 100644 --- a/src/pages/protocol/upgrades/t3.mdx +++ b/src/pages/protocol/upgrades/t3.mdx @@ -7,7 +7,7 @@ description: Details and timeline for the T3 network upgrade, including enhanced This page summarizes the features, partner impact, and breaking changes included in the T3 network upgrade. -:::warning[T3 is not live yet] +:::info[T3 is not live yet] The features described on this page are scheduled for T3 and are not active on Moderato or Presto yet. They only become live once the T3 activation timestamps are reached. ::: @@ -28,7 +28,7 @@ T3 is Tempo's next network upgrade. It introduces the following changes: - Virtual addresses for TIP-20 deposit forwarding ([TIP-1022](/protocol/tips/tip-1022)) - Security hardening and gas correctness fixes (TIP-1038) -**Action required:** All node operators must upgrade to the T3-compatible release before the activation timestamp. +**Action required for integrators:** Partners that create or update access keys should upgrade to a T3-compatible SDK release before activation. ## Partner impact @@ -36,7 +36,7 @@ T3 is Tempo's next network upgrade. It introduces the following changes: |------|-------------------|---------| | Access keys | Wallets, account SDKs, and apps using connected apps or subscriptions | Existing authorized access keys remain valid for delegated transaction flows. T3 adds optional periodic limits and call scoping, bans contract creation from access-key transactions, and changes the authorization ABI used to create or rotate keys. | | Signature verification precompile | Smart contract teams, account integrators, and wallet SDKs | Contracts can verify secp256k1, P256, and WebAuthn signatures through one precompile instead of custom verifier contracts. | -| Virtual addresses | Exchanges, ramps, custodians, and payment processors | Partners can generate per-user TIP-20 deposit addresses that forward to a registered master wallet. Explorers and indexers should display forwarded deposits correctly. | +| Virtual addresses | Exchanges, ramps, custodians, payment processors, explorers, and indexers | Partners can generate per-user TIP-20 deposit addresses that forward to a registered master wallet. Explorers and indexers should display and attribute forwarded deposits correctly. | | Node upgrades | Node operators, RPC providers, and infra teams | T3 also includes security hardening and gas correctness fixes. All operators should roll out the T3-compatible release before activation, even if they do not plan to use the new features directly. | ## Breaking changes @@ -92,4 +92,4 @@ Versions will be added here once a T3-compatible release has been published for ### TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding -[TIP-1022](/protocol/tips/tip-1022) lets partners issue per-user deposit addresses that forward TIP-20 deposits to a registered master wallet at the protocol level. This is useful for exchanges, ramps, custodians, and payment processors that want one deposit address per customer for reconciliation, attribution, or account crediting, but do not want to maintain sweep jobs or fund separate onchain wallets for every user. For existing partners, nothing changes unless you adopt virtual addresses, but teams that do should update explorers, indexers, and backend systems to treat forwarded deposits as deposits to the registered master wallet. Forwarding applies only to TIP-20 transfer paths. +[TIP-1022](/protocol/tips/tip-1022) lets partners issue per-user deposit addresses that forward TIP-20 deposits to a registered master wallet at the protocol level. This is useful for exchanges, ramps, custodians, and payment processors that want one deposit address per customer for reconciliation, attribution, or account crediting, but do not want to maintain sweep jobs or fund separate onchain wallets for every user. For existing partners, nothing changes unless you adopt virtual addresses, but any explorer, indexer, or backend system that surfaces TIP-20 deposit activity should handle forwarded deposits correctly. Teams that adopt virtual addresses should treat those forwarded deposits as deposits to the registered master wallet. Forwarding applies only to TIP-20 transfer paths. From 214e5f3ece225786b04f4dae92c0f374d98b82f8 Mon Sep 17 00:00:00 2001 From: Jennifer Date: Thu, 2 Apr 2026 20:40:37 +0100 Subject: [PATCH 4/5] Apply suggestion from @legion2002 Co-authored-by: Tanishk Goyal --- src/pages/protocol/upgrades/t3.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx index 5c2cc81e..f9f4397a 100644 --- a/src/pages/protocol/upgrades/t3.mdx +++ b/src/pages/protocol/upgrades/t3.mdx @@ -49,7 +49,7 @@ T3 introduces one breaking change for access-key integrations. **What stays the same:** Existing authorized access keys continue to work after T3 activates. -**What changes:** T3 replaces the legacy `AccountKeychain.authorizeKey(...)` ABI with the new TIP-1011 authorization format. This only affects flows that create, rotate, or re-authorize access keys. +**What changes:** T3 replaces the legacy `AccountKeychain.authorizeKey(...)` ABI with the new TIP-1011 authorization format. This only affects flows that create access keys onchain. Access keys created through `KeyAuthorizations` in Tempo Txs don't break. **Before activation:** Integrations must continue using the legacy `AccountKeychain.authorizeKey(...)` ABI. The TIP-1011 authorization format is not yet valid onchain. From cb379c331ec0d545746c0125323a97e33b42ec51 Mon Sep 17 00:00:00 2001 From: jenpaff Date: Thu, 2 Apr 2026 21:34:34 +0100 Subject: [PATCH 5/5] Clarify breaking change section --- src/pages/protocol/upgrades/t3.mdx | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/pages/protocol/upgrades/t3.mdx b/src/pages/protocol/upgrades/t3.mdx index f9f4397a..99de19b6 100644 --- a/src/pages/protocol/upgrades/t3.mdx +++ b/src/pages/protocol/upgrades/t3.mdx @@ -47,7 +47,7 @@ T3 introduces one breaking change for access-key integrations. ### Breaking change for access-key integrations -**What stays the same:** Existing authorized access keys continue to work after T3 activates. +**What stays the same:** Existing authorized access keys continue to work after T3 activates. Tempo Transactions that provision a new access key through `key_authorization` also continue to work. **What changes:** T3 replaces the legacy `AccountKeychain.authorizeKey(...)` ABI with the new TIP-1011 authorization format. This only affects flows that create access keys onchain. Access keys created through `KeyAuthorizations` in Tempo Txs don't break. @@ -57,10 +57,9 @@ T3 introduces one breaking change for access-key integrations. Affected flows include: -- creating a new access key -- authorizing an access key during onboarding or setup -- rotating or re-authorizing a key if that path still uses the old ABI -- any SDK or script wrapper that still encodes the legacy `authorizeKey` call +- direct onchain calls to `AccountKeychain.authorizeKey(...)` +- key rotation or re-authorization flows that still submit the legacy `authorizeKey(...)` calldata +- SDKs, backend services, or admin scripts that still encode the legacy `authorizeKey(...)` call ## Compatible SDK releases