T3 Network Upgrade

T3 introduced enhanced access keys, a standard signature verification precompile, and virtual addresses for TIP-20 deposit routing.

Timeline

Node operators needed to upgrade to the T3-compatible release before the testnet activation timestamp.

Overview

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 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 hand-encode calldata, use the exact tuple-form signature from the Account Keychain precompile spec.

Access-key contract creation

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 testnet

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

Supporting new features

Virtual addresses for explorers and indexers

Each virtual-address deposit emits two Transfer events in one transaction: Transfer(sender, virtualAddress, amount) then Transfer(virtualAddress, masterWallet, amount). Collapse these into one logical deposit to the master wallet. The virtual address is for attribution only — balanceOf(virtualAddress) is always zero.

See Virtual addresses for TIP-20 deposits for the full routing model and event sequences.

Signature verification precompile

TIP-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 guide.

Compatible SDK releases

Tempo's broader tooling ecosystem is available in Developer tools.

Related docs

• Virtual addresses for TIP-20 deposits
• TIP-1022
• Coordinating meta TIP: tempoxyz/tempo#3273