> Source: [/docs/protocol/upgrades/t2](https://tempo.xyz/developers/docs/protocol/upgrades/t2.md) > Section: [Tempo EVM](https://tempo.xyz/developers/docs/development.md). Build on Tempo EVM: wallets and keys, transactions and fees, TIP-20 Tokens, contracts, exchange, network details, nodes, protocol specifications, and changelog. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. # 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 | |---------|------|-----------| | Testnet | Thursday, 26th March 4pm CET | `1774537200` | | Mainnet | Tuesday, 31st March 4pm CEST | `1774965600` | Node operators needed to upgrade to the T2-compatible release before the testnet activation timestamp. ## Overview T2 built on T1 and introduced the following features: * [Compound transfer policies](https://tips.sh/1015) * [Permit](https://tips.sh/1004) support for TIP-20 tokens * A new [Validator Config V2](https://tips.sh/1017) precompile * [T2 network upgrade](https://tips.sh/1036) security improvements ## Feature TIPs ### Compound transfer policies Read the [technical specification](https://tips.sh/1015). **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 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. ### Validator Config V2 Read the [technical specification](https://tips.sh/1017). **Operator guide:** [Controlling validator lifecycle](https://tempo.xyz/developers/docs/guide/node/validator-lifecycle) **TLDR:** New precompile for managing consensus validators. Adds Ed25519 signature verification at registration, append-only history, and stable validator indices. **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 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. ### Permit for TIP-20 Read the [technical specification](https://tips.sh/1004). **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 use `permit()` to combine approve + action in a single transaction. ### Meta TIP: Security Improvements Read the [technical specification](https://tips.sh/1036).