Tempo Sets Its T6 Upgrade Deadline

Version 1.9.0 requires operators to upgrade before June 18 on testnet and June 23 on mainnet, with new receive policies and admin keys.

Tempo released version 1.9.0 of its client on June 15, with a mandatory instruction for operators: upgrade before the T6 network upgrade activates on testnet on June 18, 2026 at 16:00 CEST, then on mainnet on June 23 at 16:00 CEST. The release notes say validators and RPC nodes that remain on older software will fall out of sync. The core fact is therefore not just a software release. It is a coordination deadline for a payment-oriented blockchain.

Tempo is an EVM-compatible network, meaning it can run contracts close to Ethereum’s execution model, but it is designed around fast payments and stablecoins. T6 introduces two protocol changes that matter for financial application developers. The first, TIP-1028, adds address-level receive policies: an account can define which TIP-20 tokens and which senders it accepts. Blocked transfers do not simply revert. They are redirected to a contract called ReceivePolicyGuard, so the originator or a configured recovery authority can later recover the funds. That design turns a compliance refusal into an auditable holding path instead of a silent user-facing failure.

The second change, TIP-1049, adds admin access keys for account key management. In a payment application, the separation between a key that spends, a key that authorizes, and a key that administers is a practical security concern. Tempo says admin keys can manage other keys, but must not carry spending limits, call scopes, or expiry. That distinction sounds narrow, yet it addresses a real operating problem: companies need to manage accounts, permissions, and recovery flows without turning every maintenance operation into a transfer risk. It also gives wallet and custody teams a clearer boundary between operational control and financial authority.

The importance of T6 is this combination of compliance, security, and operations. Stablecoins promise programmable payments, but businesses also need to refuse some assets, block some senders, prove who can act on an account, and recover cleanly from mistakes. By moving more of that logic closer to the protocol layer, Tempo is trying to avoid each application rebuilding its own fragile control system. Caution is still warranted: a GitHub release note does not prove adoption or future volume. It does show that competition between payment blockchains is moving beyond raw throughput, toward less visible details such as key governance, transfer filtering, and whether operators can keep pace with dated network upgrades.