T3 docs cleanup: make T3 canonical, consolidate T2 deltas into migration appendix

src/pages/guide/tempo-transaction/index.mdx

@@ -83,13 +83,4 @@ If you are an EVM smart contract developer, see the [Foundry guide for Tempo](/s
 
 ## Properties
 
-:::info[T3 examples]
-The examples below show the T3 Tempo Transaction shape. If you still support T2, the affected sections include a `T2 -> T3 changes` note with the migration details.
-
-- [Configurable Fee Tokens](#configurable-fee-tokens)
-- [Access Keys](#access-keys)
-
-The examples assume you are using a T3-compatible network and the most recent SDK releases.
-:::
-
 <TempoTxProperties />

src/pages/protocol/rpc/index.mdx

@@ -59,15 +59,15 @@ cast rpc tempo_forkSchedule --rpc-url https://rpc.tempo.xyz
 ```json
 {
   "schedule": [
-    { "name": "T0", "activationTime": 0, "active": true, "forkId": "0xa88e90f8" },
-    { "name": "T1", "activationTime": 1770908400, "active": true, "forkId": "0x5e3041a4" },
-    { "name": "T1A", "activationTime": 1770908400, "active": true, "forkId": "0x5e3041a4" },
-    { "name": "T1B", "activationTime": 1771858800, "active": true, "forkId": "0x92b1c4d7" },
-    { "name": "T1C", "activationTime": 1773327600, "active": true, "forkId": "0xf3a901bc" },
+    { "name": "T0", "activationTime": 0, "active": true, "forkId": "0xfde57c3e" },
+    { "name": "T1", "activationTime": 1770908400, "active": true, "forkId": "0x9e6fe384" },
+    { "name": "T1A", "activationTime": 1770908400, "active": true, "forkId": "0x9e6fe384" },
+    { "name": "T1B", "activationTime": 1771858800, "active": true, "forkId": "0x73a4f670" },
+    { "name": "T1C", "activationTime": 1773327600, "active": true, "forkId": "0x2a3ee80d" },
     { "name": "T2", "activationTime": 1774965600, "active": true, "forkId": "0x471a451c" },
-    { "name": "T3", "activationTime": 0, "active": false }
+    { "name": "T3", "activationTime": 1777298400, "active": true, "forkId": "0xd2087b77" }
   ],
-  "active": "T2"
+  "active": "T3"
 }
 ```
 

src/pages/protocol/tip20-rewards/spec.mdx

@@ -4,22 +4,12 @@ description: Technical specification for the TIP-20 reward distribution system u
 
 # TIP-20 Rewards Distribution
 
-:::info[T3 will change this spec]
-The [T3 network upgrade](/protocol/upgrades/t3) will update this specification. The sections below describe the currently active behavior. See [Upcoming changes](#upcoming-changes) for the upcoming deltas.
-:::
-
 ## Abstract
 An opt-in, scalable, pro-rata reward distribution mechanism built into TIP-20 tokens. The system uses a "reward-per-token" accumulator pattern to distribute rewards proportionally to opted-in holders without requiring staking or per-holder iteration. Rewards are distributed instantly; time-based streaming distributions are planned for a future upgrade.
 
 ## Motivation
 Many applications require pro-rata distribution of tokens to existing holders (incentive programs, deterministic inflation, staking rewards). Building this into TIP-20 allows efficient distribution without forcing users to stake tokens elsewhere or requiring distributors to loop over all holders.
 
-## Upcoming changes
-
-T3 updates the TIP-20 rewards spec through [TIP-1022](/protocol/tips/tip-1022) in one place:
-
-- `setRewardRecipient(...)` will reject [TIP-1022](/protocol/tips/tip-1022) virtual addresses. Reward recipients must remain canonical accounts rather than forwarding aliases, because reward assignment is not a TIP-20 forwarding path.
-
 ## Specification
 The rewards mechanism allows anyone to distribute token rewards to opted-in holders proportionally based on holdings. Users must opt in to receiving rewards and may delegate rewards to a recipient address.
 
@@ -67,6 +57,8 @@ Users must call `setRewardRecipient(recipient)` to opt in. When opted in:
 
 Setting recipient to `address(0)` opts out.
 
+`setRewardRecipient(...)` rejects [TIP-1022](/protocol/tips/tip-1022) virtual addresses: reward recipients must remain canonical accounts rather than forwarding aliases, because reward assignment is not a TIP-20 forwarding path.
+
 ## TIP-403 Integration
 All token movements must pass TIP-403 policy checks:
 - `distributeReward`: Validates funder authorization
@@ -77,3 +69,13 @@ All token movements must pass TIP-403 policy checks:
 - `globalRewardPerToken` must monotonically increase
 - `optedInSupply` must equal the sum of balances for all opted-in users
 - All token movements must comply with TIP-403 policies
+
+## T2 → T3 migration
+
+:::info[Migration appendix]
+This section captures changes introduced by the [T3 network upgrade](/protocol/upgrades/t3) for integrators migrating from T2. The spec above is the canonical post-T3 specification; this appendix exists for reference and will be removed in a future docs revision.
+:::
+
+T3 introduced [TIP-1022](/protocol/tips/tip-1022) virtual addresses, which affect TIP-20 rewards in one place:
+
+- `setRewardRecipient(...)` now rejects virtual addresses. Reward recipients must be canonical accounts, not forwarding aliases.

src/pages/protocol/tip20/spec.mdx

@@ -4,10 +4,6 @@ description: Technical specification for TIP-20, the optimized token standard ex
 
 # TIP20
 
-:::info[T3 will change this spec]
-The [T3 network upgrade](/protocol/upgrades/t3) will update this specification. The sections below describe the currently active behavior. See [Upcoming changes](#upcoming-changes) for the upcoming deltas.
-:::
-
 ## Abstract
 TIP20 is a suite of precompiles that provide a built-in optimized token implementation in the core protocol. It extends the ERC-20 token standard with built-in functionality like memo fields and reward distribution.
 
@@ -16,15 +12,6 @@ All major stablecoins today use the ERC-20 token standard. While ERC-20 provides
 TIP-20 extends ERC-20, building these features into precompiled contracts that anyone can permissionlessly deploy on Tempo. This makes token operations much more efficient, allows issuers to quickly set up on Tempo, and simplifies integrations since it ensures standardized behavior across tokens.
 It also enables deeper integration with token-specific Tempo features like paying gas in stablecoins and payment lanes.
 
-## Upcoming changes
-
-T3 updates TIP-20 behavior through [TIP-1022](/protocol/tips/tip-1022). All changes below come from TIP-1022:
-
-- [TIP-1022](/protocol/tips/tip-1022) adds virtual-address recipient resolution for recipient-bearing TIP-20 paths: `transfer`, `transferFrom`, `transferWithMemo`, `transferFromWithMemo`, `mint`, and `mintWithMemo`.
-- When a TIP-20 operation targets a registered virtual address, the effective recipient becomes the registered master wallet before recipient authorization and mint-recipient checks run.
-- Forwarded virtual-address deposits appear as two-hop standard `Transfer` events in the same transaction. Indexers and explorers should collapse that pair into one logical deposit to the resolved master wallet.
-- Virtual addresses are valid TIP-20 recipients on those paths, but they remain forwarding aliases rather than canonical TIP-20 holders. Non-TIP-20 tokens sent to a virtual address do not forward.
-
 ## Specification
 TIP-20 tokens support standard fungible token operations such as transfers, mints, and burns. They also support transfers, mints, and burns with an attached 32-byte memo; a role-based access control system for token administrative operations; and a system for opt-in [reward distribution](/protocol/tip20-rewards/spec).
 
@@ -460,6 +447,11 @@ Reward operations (`distributeReward`, `setRewardRecipient`, `claimRewards`) als
 TIP-20 tokens cannot be sent to other TIP-20 token contract addresses. The implementation uses a `validRecipient` guard that rejects recipients whose address is zero, or has the TIP-20 prefix (`0x20c000000000000000000000`).
 Any attempt to transfer to a TIP-20 token address must revert with `InvalidRecipient`. This prevents accidental token loss by sending funds to token contracts instead of user accounts.
 
+## Virtual Address Recipients
+Recipient-bearing TIP-20 paths — `transfer`, `transferFrom`, `transferWithMemo`, `transferFromWithMemo`, `mint`, and `mintWithMemo` — resolve [TIP-1022](/protocol/tips/tip-1022) virtual addresses before running recipient authorization and mint-recipient checks. When a recipient `to` is a registered virtual address, the effective recipient becomes the registered master wallet, and authorization, balance updates, and event emission target that master wallet.
+
+Virtual addresses are valid TIP-20 recipients on those paths but remain forwarding aliases rather than canonical TIP-20 holders. Non-TIP-20 tokens sent to a virtual address do not forward. Forwarded deposits appear as two-hop standard `Transfer` events in the same transaction; indexers and explorers should collapse that pair into one logical deposit to the resolved master wallet.
+
 ## Currencies and Quote Tokens
 Each TIP-20 token declares a currency identifier and a corresponding `quoteToken` used for pricing and routing in the Stablecoin DEX. Stablecoin currency identifiers should be [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) three-letter codes representing the underlying fiat currency (e.g., `"USD"`, `"EUR"`, `"GBP"`) — not the token's own symbol. The currency is set at token creation and **cannot be changed afterward**. **Only tokens with `currency == "USD"` are eligible for paying transaction fees.** Tokens with `currency == "USD"` must pair with a USD-denominated TIP-20 token.
 
@@ -611,3 +603,16 @@ interface ITIP20Factory {
 - When `paused` is `true`, no functions that move tokens (`transfer`, `transferFrom`, memo variants, `systemTransferFrom`, `transferFeePreTx`, `distributeReward`, `setRewardRecipient`, `claimRewards`) can succeed.
 - TIP20 tokens cannot be transferred to another TIP20 token contract address.
 - `systemTransferFrom`, `transferFeePreTx`, and `transferFeePostTx` never change `totalSupply()`.
+
+## T2 → T3 migration
+
+:::info[Migration appendix]
+This section captures changes introduced by the [T3 network upgrade](/protocol/upgrades/t3) for integrators migrating from T2. The spec above is the canonical post-T3 specification; this appendix exists for reference and will be removed in a future docs revision.
+:::
+
+T3 introduced [TIP-1022](/protocol/tips/tip-1022) virtual addresses, which affect TIP-20 in the following ways:
+
+- Virtual-address recipient resolution applies to recipient-bearing TIP-20 paths: `transfer`, `transferFrom`, `transferWithMemo`, `transferFromWithMemo`, `mint`, and `mintWithMemo`. See [Virtual Address Recipients](#virtual-address-recipients).
+- When an operation targets a registered virtual address, the effective recipient becomes the registered master wallet before recipient authorization and mint-recipient checks run.
+- Forwarded virtual-address deposits appear as two-hop standard `Transfer` events in the same transaction. Indexers and explorers should collapse that pair into one logical deposit to the resolved master wallet.
+- Virtual addresses are valid TIP-20 recipients on those paths but remain forwarding aliases rather than canonical TIP-20 holders. Non-TIP-20 tokens sent to a virtual address do not forward.

src/pages/protocol/tip403/spec.mdx

@@ -4,10 +4,6 @@ description: Technical specification for TIP-403, the policy registry system ena
 
 # Overview
 
-:::info[T3 will change this spec]
-The [T3 network upgrade](/protocol/upgrades/t3) will update this specification. The sections below describe the currently active behavior. See [Upcoming changes](#upcoming-changes) for the upcoming deltas.
-:::
-
 ## Abstract
 
 TIP-403 provides a policy registry system that allows TIP-20 tokens to inherit access control and compliance policies. The registry supports two types of policies (whitelist and blacklist) and includes special built-in policies for common use cases. Policies can be shared across multiple tokens, enabling consistent compliance enforcement.
@@ -18,13 +14,6 @@ Token issuers often need to implement compliance policies such as KYC/AML requir
 
 TIP-403 addresses this by providing a centralized registry that tokens can reference for authorization decisions. This enables consistent policy enforcement across multiple tokens and reduces implementation complexity for token issuers.
 
-## Upcoming changes
-
-T3 updates TIP-403 interactions with token recipients through [TIP-1022](/protocol/tips/tip-1022) as follows:
-
-- Policy-configuration functions that accept literal member addresses will reject [TIP-1022](/protocol/tips/tip-1022) virtual addresses.
-- TIP-20 policy checks for virtual-address transfers and mints will run against the resolved master wallet, not the forwarding alias, so policy membership must be configured on the master address.
-
 ---
 
 # Specification
@@ -242,6 +231,8 @@ TIP-20 tokens store the current TIP403 registry policy ID they adhere to in thei
 
 **Policy Changes:** When a token's transfer policy is changed via `changeTransferPolicyId()`, all future transfers are immediately subject to the new policy.
 
+**Virtual addresses:** Policy-configuration functions that accept literal member addresses (`createPolicyWithAccounts`, `modifyPolicyWhitelist`, `modifyPolicyBlacklist`) reject [TIP-1022](/protocol/tips/tip-1022) virtual addresses. TIP-20 policy checks for transfers and mints to a virtual address run against the resolved master wallet rather than the forwarding alias, so policy membership must be configured on the master address.
+
 ### Example Usage
 
 Creating and setting a policy:
@@ -277,3 +268,14 @@ return data.policyType == PolicyType.WHITELIST
 - When policyId = 0, all authorization checks must return false for every address.
 - When policyId = 1, all authorization checks must return true for every address.
 - Only the policy’s current admin may update the admin address for that policy.
+
+# T2 → T3 migration
+
+:::info[Migration appendix]
+This section captures changes introduced by the [T3 network upgrade](/protocol/upgrades/t3) for integrators migrating from T2. The spec above is the canonical post-T3 specification; this appendix exists for reference and will be removed in a future docs revision.
+:::
+
+T3 introduced [TIP-1022](/protocol/tips/tip-1022) virtual addresses, which affect TIP-403 in two places:
+
+- Policy-configuration functions that take literal member addresses (`createPolicyWithAccounts`, `modifyPolicyWhitelist`, `modifyPolicyBlacklist`) now reject virtual addresses.
+- TIP-20 policy checks for virtual-address transfers and mints now run against the resolved master wallet, not the forwarding alias. Policy membership must be configured on the master address.