# 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).