tempoxyz · jenpaff · Jun 11, 2026 · Jun 9, 2026 · Jun 9, 2026 · Jun 9, 2026
diff --git a/src/pages/guide/issuance/create-a-stablecoin.mdx b/src/pages/guide/issuance/create-a-stablecoin.mdx
@@ -15,8 +15,8 @@ Create your own stablecoin on Tempo using the [TIP-20 token standard](/protocol/
 TIP-20 tokens are designed specifically for payments with built-in compliance features, role-based permissions, 
 and integration with Tempo's payment infrastructure.
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), the TIP-20 factory exposes a new 7-arg `createToken` overload that accepts an on-chain `logoURI` at creation ([TIP-1026](https://tips.sh/1026)). Wallets and explorers can read the icon directly from the token contract via `logoURI()`, without going through the [tokenlist registry](/quickstart/tokenlist). The previous `createToken` overload is unchanged. Per [TIP-1026's recommended formats](https://tips.sh/1026#recommended-formats), use a square, single-frame rasterized image (PNG or WebP) for `logoURI`. SVG is allowed by the scheme allowlist but not recommended. See the [Optional logoURI in TIP-20 section of the T5 page](/protocol/upgrades/t5#optional-logouri-in-tip-20-tip-1026) for the full surface area.
+:::info[Set a token logo at creation]
+The TIP-20 factory exposes a 7-arg `createToken` overload that accepts an on-chain `logoURI` at creation ([TIP-1026](https://tips.sh/1026)). Wallets and explorers can then read the icon directly from the token contract via `logoURI()`, without going through the [tokenlist registry](/quickstart/tokenlist). Per [TIP-1026's recommended formats](https://tips.sh/1026#recommended-formats), use a square, single-frame rasterized image (PNG or WebP); SVG is allowed by the scheme allowlist but not recommended. See [Optional on-chain logoURI](/protocol/upgrades/t5#optional-on-chain-logouri).
 :::
 
 ## Demo

diff --git a/src/pages/guide/issuance/manage-stablecoin.mdx b/src/pages/guide/issuance/manage-stablecoin.mdx
@@ -21,8 +21,8 @@ import { Cards, Card } from 'vocs'
 
 Configure your stablecoin's permissions, supply limits, and compliance policies after deployment. This guide covers granting roles to manage token operations, setting supply caps, configuring transfer policies, and controlling token transfers through pause/unpause functionality.
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), an admin holding `DEFAULT_ADMIN_ROLE` can update the on-chain `logoURI` field on any TIP-20 via `setLogoURI(string newLogoURI)` ([TIP-1026](https://tips.sh/1026)). Wallets and explorers can read the icon directly from the token contract via `logoURI()`. Per [TIP-1026's recommended formats](https://tips.sh/1026#recommended-formats), use a square, single-frame rasterized image (PNG or WebP) for `logoURI`. SVG is allowed by the scheme allowlist but not recommended. See the [Optional logoURI in TIP-20 section of the T5 page](/protocol/upgrades/t5#optional-logouri-in-tip-20-tip-1026) for the full surface area.
+:::info[Update the token logo]
+An admin holding `DEFAULT_ADMIN_ROLE` can set or update the on-chain `logoURI` field on any TIP-20 via `setLogoURI(string newLogoURI)` ([TIP-1026](https://tips.sh/1026)). Wallets and explorers read the icon directly from the token contract via `logoURI()`. Per [TIP-1026's recommended formats](https://tips.sh/1026#recommended-formats), use a square, single-frame rasterized image (PNG or WebP); SVG is allowed by the scheme allowlist but not recommended. See [Optional on-chain logoURI](/protocol/upgrades/t5#optional-on-chain-logouri).
 :::
 
 TIP-20 tokens use a role-based access control system that allows you to delegate different administrative functions to different addresses. For detailed information about the role system, see the [TIP-20 specification](/protocol/tip20/spec#role-based-access-control).

diff --git a/src/pages/guide/issuance/use-for-fees.mdx b/src/pages/guide/issuance/use-for-fees.mdx
@@ -39,15 +39,11 @@ First, create and mint your stablecoin by following the [Create a Stablecoin](/g
 
 ### Add fee pool liquidity
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), the FeeAMM supports multihop routing ([TIP-1033](https://tips.sh/1033)). Issuers no longer need to provision a pool against every validator payout token — pairing your token against a single liquid quote (e.g., `pathUSD`) is enough, and multihop routing connects it to any validator payout token that has its own `pathUSD` pool. Until T5 activates, the per-validator-token setup described below still applies.
-:::
-
-Before users can pay fees with your token, you need to provide liquidity in the Fee AMM between your token and each of the tokens accepted by validators.
+Before users can pay fees with your token, you need to provide liquidity in the Fee AMM between your token and a liquid quote token, or directly against validator payout tokens where you want explicit direct-route coverage.
 
 To determine which validator tokens are needed, sample recent blocks and check the miner's preferred fee token using `getValidatorToken` on the FeeManager contract. For example, on Moderato testnet, validators accept fees in pathUSD and AlphaUSD. On mainnet, this token mix is different and subject to change.
 
-Add liquidity to your token's fee pool for each validator token:
+Add liquidity to your token's fee pool:
 
 :::code-group
 

diff --git a/src/pages/guide/machine-payments/pay-as-you-go.mdx b/src/pages/guide/machine-payments/pay-as-you-go.mdx
@@ -14,10 +14,6 @@ Build a payment-gated photo gallery API that charges $0.01 per photo using `mppx
 Unlike [one-time payments](/guide/machine-payments/one-time-payments), sessions open a payment channel once and use off-chain vouchers for each subsequent request — vouchers are processed in pure CPU-bound signature checks, not bottlenecked by blockchain throughput.
 :::
 
-:::info[Coming with T5]
-The [T5 network upgrade](/protocol/upgrades/t5) ships an enshrined `TIP20ChannelReserve` precompile at [`0x4D50500000000000000000000000000000000000`](https://explore.tempo.xyz/address/0x4D50500000000000000000000000000000000000) (ASCII `MPP`) that replaces the application-level escrow contract for new MPP integrations ([TIP-1034](https://tips.sh/1034)). The existing escrow contract continues to work; SDKs that target the precompile additionally save gas thanks to [implicit approvals](/protocol/upgrades/t5#tip-1035-implicit-approvals-list) — the channel can pull TIP-20 tokens without a prior `approve` transaction. New `mppx` releases that target the precompile will be linked under [Compatible SDK releases](/protocol/upgrades/t5#compatible-sdk-releases).
-:::
-
 ## How sessions work
 
 <MermaidDiagram chart={`sequenceDiagram

diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx
@@ -71,9 +71,9 @@ Integrators, indexers, wallets, explorers, and SDK maintainers should review the
 
 ### Who is affected?
 
-All node operators need to upgrade before the T5 activation timestamp. Non-upgraded nodes will fall out of consensus once T5 activates.
+All node operators needed to upgrade before the T5 activation timestamp.
 
-Integrators, indexers, wallets, explorers, and SDK maintainers should review the [T5 network upgrade](/protocol/upgrades/t5) page for the post-T5 surfaces and migration notes.
+Integrators, indexers, wallets, explorers, and SDK maintainers should review the [T5 network upgrade](/protocol/upgrades/t5) page for the T5 surfaces and migration notes.
 
 ---
 

diff --git a/src/pages/guide/stablecoin-dex/managing-fee-liquidity.mdx b/src/pages/guide/stablecoin-dex/managing-fee-liquidity.mdx
@@ -18,8 +18,8 @@ The Fee AMM converts transaction fees between stablecoins when users pay in a di
 
 Browse current pool reserves and route availability in the [FeeAMM explorer view](https://explore.tempo.xyz/fee-amm).
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), the Fee AMM supports multihop routing ([TIP-1033](https://tips.sh/1033)) — one fee conversion can route through two pools when a direct pair between the user's fee token and the validator's payout token doesn't exist or has insufficient liquidity for the user's transaction. Pool mechanics for adding and removing liquidity are unchanged, but a single fee conversion may now reserve and consume reserves from two pools you provide liquidity to instead of one.
+:::info[Multihop routing]
+The Fee AMM supports multihop routing ([TIP-1033](https://tips.sh/1033)) — one fee conversion can route through two pools when a direct pair between the user's fee token and the validator's payout token doesn't exist or has insufficient liquidity. Pool mechanics for adding and removing liquidity are unchanged, but a single fee conversion may reserve and consume liquidity from two pools you provide to instead of one.
 :::
 
 <Demo.Container name="Manage Fee Liquidity" footerVariant="source" src="tempoxyz/examples/tree/main/examples/issuance">

diff --git a/src/pages/guide/stablecoin-dex/providing-liquidity.mdx b/src/pages/guide/stablecoin-dex/providing-liquidity.mdx
@@ -308,16 +308,10 @@ console.log('Quote Token:', metadata?.quoteToken) // returns `pathUSD` address
 
 ### Flip order
 
-:::info[Coming with T5]
-The [T5 network upgrade](/protocol/upgrades/t5) changes flip-order behavior in two ways:
-- `flipTick == tick` becomes valid ([TIP-1030](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1030.md))
-- A filled flip order keeps the same `orderId` and emits a new `OrderFlipped` event instead of a fresh `OrderPlaced` ([TIP-1056](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1056.md))
-
-Until T5 activates, the behavior described below still applies. Developers updating indexers, SDKs, or contract code should see the [T4 → T5 migration appendix](/protocol/exchange/providing-liquidity#t4--t5-migration) on the Providing Liquidity spec page.
-:::
-
 Flip orders automatically switch between buy and sell sides when filled, providing continuous liquidity. Use viem's [`dex.placeFlip`](https://viem.sh/tempo/actions/dex.placeFlip) to create a flip order call.
 
+A flip order can re-list on the opposite side at the same tick (`flipTick == tick`), which is useful for pegged or near-1:1 pairs. When it fills, the order keeps the same `orderId` and emits an `OrderFlipped` event instead of a new `OrderPlaced`, so a single flip strategy stays trackable under one ID across its full lifecycle. Indexers, SDKs, and contract code that follow flip orders should treat `OrderFlipped` as the latest active state — see the [flip-order indexing notes](/protocol/exchange/providing-liquidity#flip-order-indexing).
+
 :::code-group
 
 ```tsx twoslash [PlaceFlipOrder.tsx]

diff --git a/src/pages/guide/stablecoin-dex/view-the-orderbook.mdx b/src/pages/guide/stablecoin-dex/view-the-orderbook.mdx
@@ -9,12 +9,6 @@ import { IndexSupplyQuery } from '../../../components/IndexSupplyQuery'
 
 Query and inspect the orderbook to see available liquidity, price levels, and individual orders on Tempo's Stablecoin DEX.
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), flip orders keep the same `orderId` when they flip. A fully filled flip order emits `OrderFilled`, then re-enters the book under the same `orderId` with an `OrderFlipped` event instead of a new `OrderPlaced` event.
-
-The SQL recipes below are pre-T5 examples. They currently treat any full `OrderFilled` as the end of an order and only read active liquidity from `OrderPlaced`, so they will miss flipped orders after T5. Post-T5 indexers should read `OrderFlipped` as the latest active state for that `orderId`, including its new side, tick, and flip tick. See the [T4 → T5 migration appendix](/protocol/exchange/providing-liquidity#t4--t5-migration) for the full action list.
-:::
-
 ## Recommended Approach
 
 We recommend using indexed data to query the orderbook for better performance and ease of use. While you can query logs and transactions directly from an RPC node, indexed data providers offer structured SQL interfaces that make complex queries simpler and more efficient.

diff --git a/src/pages/guide/use-accounts/authorize-access-keys.mdx b/src/pages/guide/use-accounts/authorize-access-keys.mdx
@@ -15,10 +15,6 @@ import { Tabs, Tab } from 'vocs'
 
 Send stablecoin payments using an access key: a secondary signing key that lets you transact without repeated passkey prompts. Access keys can be scoped with spending limits and expiry for security.
 
-:::info[Coming with T5]
-After the [T5 network upgrade](/protocol/upgrades/t5), `key_authorization` gains an optional `witness: bytes32` field ([TIP-1053](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1053.md)). "Sign-In with Tempo" style apps can derive a 32-byte witness from their challenge and include it in the access-key authorization, so a single user signature both authorizes the access key and binds to the app's challenge — replacing the current two-prompt flow. No breaking change; existing flows continue to work unchanged.
-:::
-
 ## Demo
 
 By the end of this guide you will be able to send payments on Tempo using an access key. Notice that no passkey prompt appears when sending a payment.

diff --git a/src/pages/protocol/blockspace/payment-lane-specification.mdx b/src/pages/protocol/blockspace/payment-lane-specification.mdx
@@ -4,10 +4,6 @@ description: Technical specification for Tempo payment lanes ensuring dedicated
 
 # Payment Lane Specification
 
-:::info[Coming with T5]
-The [T5 network upgrade](/protocol/upgrades/t5) replaces the pre-T5 TIP-20 prefix-only consensus classifier with TIP-1045's allow-listed call shapes ([TIP-1045](https://tips.sh/1045)). The allow-list covers TIP-20 calls and the new `TIP20ChannelReserve` precompile ([TIP-1034](https://tips.sh/1034)), so payment-channel reserve transactions become first-class payment-lane traffic. Indexers, explorers, and payment processors that classify "payments" should pick up the new selector list before activation. Until T5 activates, the prefix-based classification described below still applies.
-:::
-
 ## Abstract
 
 This specification introduces a second consensus gas constraint for **non-payment** transactions. Transactions are classified as either payments or non-payments based solely on their transaction data, without requiring any access to blockchain state. For a block to be valid, total `gas_used` by the block must be less than the `gas_limit`. Non-payment transactions executed in the proposer's lane (i.e. before the gas incentive section) must consume at most `general_gas_limit`, a new field added to the header. Once that budget is exhausted, additional inclusion is constrained by the remaining shared gas budget.
@@ -34,14 +30,14 @@ Non-payment transactions in the proposer's lane can only fill up to `general_gas
 
 A transaction is classified as a **payment transaction** when:
 
-  1.  the recipient address (`tx.to`) starts with the TIP-20 payment prefix `0x20c0000000000000000000000000`, or,
-  2. for TempoTransactions, every entry in `tx.calls` targets an address starting with the TIP-20 payment prefix `0x20c0000000000000000000000000`.
+1. Every call in the transaction matches an allow-listed payment call shape.
+2. The transaction `access_list` is empty.
+3. The transaction `authorization_list` and `tempo_authorization_list` are empty.
+4. If `key_authorization` is present, `len(rlp(key_authorization)) <= 1024` bytes.
 
 This classification is performed entirely on the transaction payload, no account state is consulted.
 
-:::info
-Later upgrades may enable other kinds of transactions to be classified as payment transactions as well.
-:::
+The payment call allow-list includes TIP-20 payment and mint/burn/approval calls, plus the `TIP20ChannelReserve` payment-channel precompile calls. Calls with unrecognized selectors, malformed ABI encoding, disallowed targets, non-empty auxiliary payloads, or dynamic calldata above the allow-list size bound are classified as non-payment transactions. See [TIP-1045](https://tips.sh/1045) for the complete selector table and ABI constraints.
 
 ### 2. Ordering of Transactions
 

diff --git a/src/pages/protocol/exchange/index.mdx b/src/pages/protocol/exchange/index.mdx
@@ -12,18 +12,12 @@ The exchange operates as a singleton precompiled contract at address `0xdec00000
 
 Trading pairs are determined by each token's quote token. All TIP-20 tokens specify a quote token for trading on the exchange. See [Quote Tokens](/protocol/exchange/quote-tokens) for more information on quote token selection and the optional [pathUSD](/protocol/exchange/quote-tokens#pathusd) stablecoin. See the [Stablecoin DEX Specification](/protocol/exchange/spec) for detailed information on the exchange structure.
 
-:::info[Coming with T5]
-The [T5 network upgrade](/protocol/upgrades/t5) changes flip-order behavior: `flipTick == tick` becomes valid ([TIP-1030](https://tips.sh/1030)), and a filled flip order keeps the same `orderId` and emits a new `OrderFlipped` event instead of a fresh `OrderPlaced` ([TIP-1056](https://tips.sh/1056)). See the [T4 → T5 migration appendix](/protocol/exchange/providing-liquidity#t4--t5-migration) on the Providing Liquidity page.
-
-T5 also adds the StablecoinDEX to the [Implicit Approvals List](/protocol/upgrades/t5#tip-1035-implicit-approvals-list) ([TIP-1035](https://tips.sh/1035)), so users no longer need to pre-approve the DEX before placing orders or swapping — saving a wallet prompt and the gas cost of an allowance write.
-:::
-
 The exchange supports three types of orders, each with different execution behavior:
 
 | Order Type | Description |
 |------------|-------------|
 | [**Limit Orders**](/protocol/exchange/providing-liquidity#limit-orders) | Place orders at specific price levels that wait in the book until matched or cancelled. Orders are added to the book immediately when placed. |
-| [**Flip Orders**](/protocol/exchange/providing-liquidity#flip-orders) | Special orders that automatically reverse to the opposite side when completely filled, acting like a perpetual liquidity pool. When a flip order is fully filled, a new order is immediately created on the opposite side. |
+| [**Flip Orders**](/protocol/exchange/providing-liquidity#flip-orders) | Special orders that automatically reverse to the opposite side when completely filled, acting like a perpetual liquidity pool. When a flip order is fully filled, the same `orderId` is rewritten on the opposite side and emits `OrderFlipped`. |
 | [**Market Orders**](/protocol/exchange/executing-swaps#swap-functions) | Execute immediately against the best available orders in the book (via swap functions). Swaps and cancellations execute immediately within the transaction. |
 
 For the complete execution mechanics, see the [Stablecoin DEX Specification](/protocol/exchange/spec).