WIP: T3 docs update

src/pages/guide/node/network-upgrades.mdx

@@ -36,17 +36,19 @@ For detailed release notes and binaries, see the [Changelog](/changelog).
 
 | | |
 |---|---|
-| **Scope** | Enhanced access keys with periodic limits, call scoping, and an authorization ABI update; signature verification precompile; virtual addresses for TIP-20 deposit forwarding; and security hardening and gas correctness fixes |
-| **TIPs** | [TIP-1011: Enhanced Access Key Permissions](/protocol/tips/tip-1011), [TIP-1020: Signature Verification Precompile](/protocol/tips/tip-1020), [TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding](/protocol/tips/tip-1022), TIP-1038: T3 security hardening and gas correctness fixes |
+| **Scope** | Enhanced access keys with periodic limits, call scoping, and an authorization ABI update; signature verification precompile; and virtual addresses for TIP-20 deposit forwarding |
+| **TIPs** | [TIP-1011: Enhanced Access Key Permissions](/protocol/tips/tip-1011), [TIP-1020: Signature Verification Precompile](/protocol/tips/tip-1020), [TIP-1022: Virtual Addresses for TIP-20 Deposit Forwarding](/protocol/tips/tip-1022) |
 | **Details** | [T3 network upgrade](/protocol/upgrades/t3) |
 | **Release** | T3-compatible release coming soon |
 | **Testnet** | Moderato: Apr 22, 2026 16:00 CEST (unix: TBD) |
 | **Mainnet** | Presto: Apr 27, 2026 16:00 CEST (unix: TBD) |
 | **Priority** | <Badge variant="red">Required</Badge> |
 
-All node operators should upgrade before the Moderato activation date, even if they do not plan to use the new T3 feature set directly.
+### Who is affected?
 
-Partners that create or rotate access keys should also review the T3 upgrade page. Existing authorized access keys remain valid, but key authorization flows must move to the new TIP-1011 ABI after activation.
+Partners that directly call `AccountKeychain.authorizeKey(...)` or manually encode `key_authorization` to create or rotate access keys should also review the T3 upgrade page. Existing authorized access keys remain valid, but those low-level authorization flows must move to the new TIP-1011 format post-T3.
+
+Partners that index TIP-20 transfers should also review the T3 upgrade page. Virtual-address forwarding emits two-hop `Transfer` events, so raw transfer lists and counts will be misleading unless that pair is handled as one logical deposit.
 
 ---
 

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

@@ -4,12 +4,22 @@ 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 [T3 changes](#t3-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.
 
+## T3 Changes
+
+T3 updates the TIP-20 rewards spec 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.
 

src/pages/protocol/tip20/spec.mdx

@@ -4,6 +4,10 @@ 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 [T3 changes](#t3-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.
 
@@ -12,6 +16,15 @@ 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.
 
+## T3 Changes
+
+T3 updates TIP-20 behavior in the following ways:
+
+- [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).
 

src/pages/protocol/tip403/spec.mdx

@@ -4,6 +4,10 @@ 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 [T3 changes](#t3-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.
@@ -14,6 +18,13 @@ 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.
 
+## T3 Changes
+
+T3 updates TIP-403 interactions with token recipients 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

src/pages/protocol/transactions/AccountKeychain.mdx

@@ -6,14 +6,30 @@ description: Technical specification for the Account Keychain precompile managin
 
 **Address:** `0xAAAAAAAA00000000000000000000000000000000`
 
+:::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 [T3 changes](#t3-changes) for the upcoming deltas.
+:::
+
 ## Overview
 
-The Account Keychain precompile manages authorized Access Keys for accounts, enabling Root Keys (e.g., passkeys) to provision scoped "secondary" Access Keys with expiry timestamps and per-TIP20 token spending limits. 
+The Account Keychain precompile manages authorized Access Keys for accounts, enabling Root Keys (e.g., passkeys) to provision scoped "secondary" Access Keys with expiry timestamps and per-TIP20 token spending limits.
 
 ## Motivation
 
 The Tempo Transaction type unlocks a number of new signature schemes, including WebAuthn (Passkeys). However, for an Account using a Passkey as its Root Key, the sender will subsequently be prompted with passkey prompts for every signature request. This can be a poor user experience for highly interactive or multi-step flows. Additionally, users would also see "Sign In" copy in prompts for signing transactions which is confusing. This proposal introduces the concept of the Root Key being able to provision a (scoped) Access Key that can be used for subsequent transactions, without the need for repetitive end-user prompting.
 
+## T3 Changes
+
+T3 updates the Account Keychain specification in the following ways:
+
+- [TIP-1011](/protocol/tips/tip-1011) extends `TokenLimit` with an optional recurring `period`, so spending limits can be either one-time or periodic.
+- `authorizeKey(...)` moves to the new ABI with `allowAnyCalls` and `allowedCalls`, enabling explicit call scoping during key authorization.
+- New `SelectorRule` and `CallScope` structs define per-target and per-selector allowlists, including recipient-bound rules for supported TIP-20 selectors.
+- New root-key-only functions `setAllowedCalls(...)` and `removeAllowedCalls(...)`, plus a new `getAllowedCalls(...)` view, are added for managing and inspecting call scopes.
+- `getRemainingLimit(...)` changes to return both `remaining` and `periodEnd` so callers can observe periodic reset state.
+- `updateSpendingLimit(...)` resets the remaining amount to `newLimit` but does not change the configured `period` or current `periodEnd`.
+- Access-key-signed transactions can no longer create contracts anywhere in the batch. Deployments and other `CREATE` / `CREATE2` flows must use the root key post-T3.
+
 ## Concepts
 
 ### Access Keys
@@ -35,7 +51,7 @@ The protocol enforces a strict hierarchy at validation time:
 1. **Root Key**: The account's main key (derived from the account address)
    - Can call all precompile functions
    - Has no spending limits
-   
+
 2. **Access Keys**: Secondary authorized keys
    - Cannot call mutable precompile functions (only view functions are allowed)
    - Subject to per-TIP20 token spending limits

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

@@ -4,6 +4,10 @@ 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 [T3 changes](#t3-changes) for the upcoming deltas.
+:::
+
 ## Abstract
 
 This spec introduces native protocol support for the following features, using a new Tempo transaction type:
@@ -20,6 +24,18 @@ 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. 
 
 
+## T3 Changes
+
+T3 updates the Tempo Transaction spec 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.
+- Low-level integrators that manually encode `key_authorization` must branch pre-T3 vs post-T3. The post-T3 digest and signed payload include `allowed_calls?` in addition to `expiry?` and `limits?`.
+- Access-key validation gains two new execution checks: call scopes must pass before execution begins, and access-key-signed transactions may no longer perform contract creation anywhere in the batch.
+- The Account Keychain precompile ABI changes in lockstep with T3 to support periodic limits, call-scoped authorizations, and new scope-management functions.
+- Intrinsic gas for `key_authorization` changes to account for periodic-limit state and call-scope storage. See [TIP-1011](/protocol/tips/tip-1011#intrinsic-gas-for-key-authorization) for the post-T3 slot-counting rules.
+
+
 ## Specification
 ### Transaction Type
 
@@ -688,16 +704,17 @@ The protocol tracks and enforces spending limits for TIP20 token transfers:
    ```typescript
    // Define key parameters
    const keyAuth = {
+     chain_id: 1,
      key_type: SignatureType.P256,      // 1
      key_id: keyId,                     // address derived from public key
      expiry: timestamp + 86400,         // 24 hours from now (or 0 for never)
      limits: [
-       { token: USDG_ADDRESS, amount: 1000000000 }, // 1000 USDG (6 decimals)
-       { token: DAI_ADDRESS, amount: 500000000000000000000 }  // 500 DAI (18 decimals)
+       { token: USDG_ADDRESS, limit: 1000000000 }, // 1000 USDG (6 decimals)
+       { token: DAI_ADDRESS, limit: 500000000000000000000 }  // 500 DAI (18 decimals)
      ]
    };
 
-   // Compute digest: keccak256(rlp([key_type, key_id, expiry, limits]))
+   // Compute digest: keccak256(rlp([chain_id, key_type, key_id, expiry, limits]))
    const authDigest = computeAuthorizationDigest(keyAuth);
    ```
 
@@ -718,10 +735,7 @@ The protocol tracks and enforces spending limits for TIP20 token transfers:
      max_fee_per_gas: 1000000000,
      max_priority_fee_per_gas: 1000000000,
      key_authorization: {
-       key_type: keyAuth.key_type,
-       expiry: keyAuth.expiry,
-       limits: keyAuth.limits,
-       key_id: keyAuth.key_id,
+       authorization: keyAuth,
        signature: rootSignature  // Root Key's signature on authDigest
      },
      // ... other fields