T5 Network Upgrade

T5 is Tempo's latest network upgrade. It lowered costs for session-based payments, improved DEX flip-order tracking, simplified fee-token routing, added on-chain token logos, and added witness binding for key authorization flows.

Timeline

Mainnet node operators needed to upgrade to the T5-compatible release (v1.8.0) before the mainnet activation timestamp.

Overview

T5 focuses on four integration areas, plus a storage correctness fix:

• Cheaper payment sessions. The TIP20ChannelReserve precompile gives MPP and other session-based payment apps a protocol-native reserve path.
• Clearer DEX state. Flip orders can use the same tick on both sides and keep the same orderId after each flip.
• Simpler fee-token liquidity. FeeAMM routing can use two hops, so issuers usually do not need a direct pool against every validator payout token.
• Better token and key metadata. TIP-20 tokens can expose an on-chain logoURI, listed precompiles can pull TIP-20 tokens without a separate approval, and key authorizations can include an app-defined witness digest.
• Storage correctness fix. Shrinking writes to dynamic precompile storage clear their stale tail slots at the hardfork boundary (TIP-1057).

Most T5 changes are additive: existing TIP-20 tokens, MPP contracts, and non-flip DEX flows continue to work.

Features

Enshrined TIP-20 reserve channel

The reserve precompile lives at 0x4D50500000000000000000000000000000000000 (ASCII MPP). It replaces the application-level MPP reserve contract for new integrations, while the existing contract continues to work.

Measured gas savings versus the legacy reserve contract:

These numbers cover only the channel operation itself. Under the legacy path, first-time users also had to send a separate approve transaction before opening a channel. With the precompile on the Implicit Approvals List, that approval round trip and allowance storage write are removed.

Read the technical specification at TIP-1034.

Payment lane classification

T5 moved payment-lane eligibility from local builder policy into consensus. The allow-list covers TIP-20 calls and the new TIP20ChannelReserve precompile, so reserve-channel transactions are classified consistently across the network.

Read the technical specification at TIP-1045.

DEX flip-order improvements

The upgrade changed flip orders in two ways:

• flipTick == tick is valid.
• A filled flip order keeps the same orderId and emits OrderFlipped instead of creating a new order with OrderPlaced.

This makes a market-making strategy easier to track over time. Indexers should treat OrderFlipped as the latest active state for that orderId.

Read the technical specifications at TIP-1030 and TIP-1056.

Multihop FeeAMM routing

FeeAMM can now route through two pools when there is no usable direct pool between the user's fee token and the validator's payout token.

For token issuers, this usually means pairing against one liquid quote token, such as pathUSD, instead of provisioning direct pools against every validator payout token.

Read the technical specification at TIP-1033.

Optional on-chain logoURI

TIP-20 tokens can expose an optional logoURI field. Wallets and explorers can read the official token icon directly from the token contract instead of relying only on the tokenlist registry.

The field is capped at 256 bytes, and non-empty values must use an allowed URI scheme: https, http, ipfs, or data.

Read the technical specification at TIP-1026.

Implicit approvals

Listed protocol precompiles can pull TIP-20 tokens without a prior approve. This removes an extra wallet prompt and avoids the allowance storage write for native flows such as DEX orders, DEX swaps, FeeAMM fee collection, and reserve-channel operations.

The internal transfer path is not part of the public TIP-20 ABI and cannot be called by EOAs or external contracts. It still enforces balance checks, TIP-403 transfer policies, AccountKeychain spending limits, and emits the standard TIP-20 Transfer event.

Read the technical specification at TIP-1035.

Witness digest in key authorizations

key_authorization now supports an optional witness: bytes32 field. Apps can bind one key-authorization signature to an application challenge, which removes the need for a separate challenge signature in login or delegated-access flows.

Read the technical specification at TIP-1053.

Storage correctness fix

T5 gates one precompile storage fix at the hardfork boundary. Overwriting a Vec, String, or Bytes value with a shorter one used to leave the trailing slots populated, so reads past the new length returned stale data. T5 clears those slots on shrinking writes.

This changes storage state and gas at the activation boundary, but no public ABI changes and no integrator action is required.

Read the technical specification at TIP-1057.

Compatible SDK releases

The following releases support the full T5 feature set. New integrations should prefer the TIP20ChannelReserve precompile over the legacy MPP reserve contract.

What operators and integrators should know

T5 is mostly additive. Integrators, indexers, wallets, explorers, and partner infrastructure should review the notes below.

For MPP and payment-session integrators

• Keep supporting the legacy reserve contract during the transition.
• Prefer the TIP20ChannelReserve precompile for new SDK releases.
• Update monitoring to recognize both reserve surfaces.
• Show channel-open, top-up, and close flows from the precompile path.

For DEX indexers and frontends

• Index OrderFlipped.
• Treat OrderFlipped as the active state for the same orderId.
• Do not assume a filled flip order receives a new orderId.
• Remove checks that reject flipTick == tick.
• See the flip-order indexing notes.

For FeeAMM integrators

• Account for two-pool routes when quoting or explaining fee conversion.
• Show route availability from direct pools and multihop paths.
• Make clear that one conversion may reserve and consume liquidity from two pools.

For token issuers, wallets, and explorers

• Read logoURI() directly from TIP-20 contracts when available.
• Continue using the tokenlist for richer metadata and fallback icons.
• Watch LogoURIUpdated(address indexed updater, string newLogoURI).
• Use square, single-frame PNG or WebP images for token icons.

For key-management and auth flows

• Add the optional witness field to key-authorization encoding and decoding.
• Include the witness in signing and verification flows.
• Treat the witness as opaque application data.