docs: remove stale T3 future-tense callouts

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

@@ -4,8 +4,8 @@ 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.
+:::info[T3 changes in this spec]
+This specification includes the [T3 network upgrade](/protocol/upgrades/t3). The sections below describe the current behavior, and [T3 changes](#t3-changes) summarizes the upgrade-specific deltas.
 :::
 
 ## Abstract
@@ -14,11 +14,11 @@ An opt-in, scalable, pro-rata reward distribution mechanism built into TIP-20 to
 ## 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 changes
 
-T3 updates the TIP-20 rewards spec through [TIP-1022](/protocol/tips/tip-1022) in one place:
+T3 updated 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.
+- `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.
 
 ## 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.

src/pages/protocol/tip20/spec.mdx

@@ -4,8 +4,8 @@ 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.
+:::info[T3 changes in this spec]
+This specification includes the [T3 network upgrade](/protocol/upgrades/t3). The sections below describe the current behavior, and [T3 changes](#t3-changes) summarizes the upgrade-specific deltas.
 :::
 
 ## Abstract
@@ -16,9 +16,9 @@ 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 changes
 
-T3 updates TIP-20 behavior through [TIP-1022](/protocol/tips/tip-1022). All changes below come from TIP-1022:
+T3 updated TIP-20 behavior through [TIP-1022](/protocol/tips/tip-1022). The active changes are:
 
 - [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.

src/pages/protocol/tip403/spec.mdx

@@ -4,8 +4,8 @@ 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.
+:::info[T3 changes in this spec]
+This specification includes the [T3 network upgrade](/protocol/upgrades/t3). The sections below describe the current behavior, and [T3 changes](#t3-changes) summarizes the upgrade-specific deltas.
 :::
 
 ## Abstract
@@ -18,9 +18,9 @@ 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 changes
 
-T3 updates TIP-403 interactions with token recipients through [TIP-1022](/protocol/tips/tip-1022) as follows:
+T3 updated 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.

src/pages/protocol/transactions/AccountKeychain.mdx

@@ -6,8 +6,8 @@ description: Technical specification for the Account Keychain precompile managin
 
 **Address:** `0xAAAAAAAA00000000000000000000000000000000`
 
-:::info[T3 will change this precompile]
-The [T3 network upgrade](/protocol/upgrades/t3) will update this specification. The sections below describe the current T2 behavior and include `T2 -> T3 changes` notes for each section. If you are migrating now, start with [Account keychain post-T3](#account-keychain-post-t3).
+:::info[T3 changes in this precompile]
+This specification covers the current post-T3 behavior and keeps `T2 -> T3 changes` notes where the historical diff is still useful. If you are migrating from a pre-T3 integration, start with [Account keychain post-T3](#account-keychain-post-t3).
 :::
 
 ## Overview

src/pages/protocol/transactions/spec-tempo-transaction.mdx

@@ -4,8 +4,8 @@ description: Technical specification for the Tempo transaction type (EIP-2718) w
 
 # Tempo Transaction
 
-:::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.
+:::info[T3 changes in this spec]
+This specification includes the [T3 network upgrade](/protocol/upgrades/t3). The sections below describe the current behavior, and [T3 changes](#t3-changes) summarizes the upgrade-specific deltas.
 :::
 
 ## Abstract
@@ -24,9 +24,9 @@ Current accounts are limited to secp256k1 signatures and sequential nonces, crea
 Users cannot leverage modern authentication methods like passkeys, applications face throughput limitations due to sequential nonces. 
 
 
-## Upcoming changes
+## T3 changes
 
-T3 updates the Tempo Transaction spec through [TIP-1011](/protocol/tips/tip-1011) in the following ways:
+T3 updated the Tempo Transaction spec through [TIP-1011](/protocol/tips/tip-1011) in the following ways:
 
 - `KeyAuthorization` expands with the [TIP-1011](/protocol/tips/tip-1011) fields `allowed_calls` and periodic `TokenLimit.period`, adding call scoping and recurring spending limits to access keys.
 - The signed post-T3 key-authorization payload remains `SignedKeyAuthorization { authorization, signature }`, but `authorization` now uses the expanded `KeyAuthorization` shape and new RLP encoding.