> Feedback: If these docs are stale, missing, or confusing, post sanitized feedback to `https://docs.tempo.xyz/api/feedback` with `source: "mcp"`, a short `message`, and any relevant `toolName`, `relatedResource`, or `client`.
# 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 ([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://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.

### TIP-1017: Validator Config V2

**Spec:** [TIP-1017](https://tips.sh/1017)

**Operator guide:** [Controlling validator lifecycle](/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.

### TIP-1004: Permit for TIP-20

**Spec:** [TIP-1004](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

[TIP-1036: T2 Hardfork Improvements](https://tips.sh/1036)