> Source: [/docs/protocol/upgrades/t13](https://tempo.xyz/developers/docs/protocol/upgrades/t13.md) > Section: [Tempo EVM](https://tempo.xyz/developers/docs/development.md). Build on Tempo EVM: wallets and keys, payments, transactions and fees, TIP-20 Tokens, contracts, exchange, network details, nodes, protocol specifications, and changelog. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. # T13 Network Upgrade T13 ships the prover for [Tempo Zones](https://tempo.xyz/developers/docs/zones), adds multi-block Tempo imports for Zones, makes block system calls explicit, and lets transactions pay fees in OUSD when the fee payer has no pathUSD. :::info[T13 status] T13 is scheduled for **October 29, 2026 at 15:00 UTC on Moderato testnet** and **November 3, 2026 at 15:00 UTC on mainnet**. The required node release is `tempo/v1.17.0`, coming soon. See [Node Operator Updates](https://tempo.xyz/developers/docs/guide/node/network-upgrades#t13) before upgrading. ::: **Integration note:** If your integration sets `feeToken` to pathUSD or requires a pathUSD balance for gas, users who hold only OUSD still fail after T13. [See integration guidance](https://tempo.xyz/developers/docs/protocol/upgrades/t13#integration-impact). ## Timeline | Network | Activation date (UTC) | Unix timestamp | |---------|-----------------------|----------------| | Testnet | October 29, 2026 at 15:00 | `1793286000` | | Mainnet | November 3, 2026 at 15:00 | `1793718000` | ## T13 overview * **Zone prover:** Tempo verifies a Nitro attestation of each Zone batch's execution before accepting settlement, with a temporary fallback to sequencer signatures during rollout. * **Multi-block Tempo imports for Zones:** bounds the work in each Zone batch so the prover can replay it, and lets Zones catch up after downtime. * **Explicit block system calls:** Tempo blocks run only the system calls Tempo uses, instead of inheriting Ethereum's, so future Ethereum changes cannot alter block validity. * **OUSD fee-token fallback:** a transaction with no fee token selected pays in OUSD when the fee payer has too little pathUSD, instead of failing. ## T13 features ### Zone prover A Zone sequencer executes transactions privately and settles batches on Tempo. Before T13, Tempo accepted a batch when enough sequencers signed it, trusting them to have executed it correctly. With T13, a prover replays each batch, checking balances and authorized transfers, and Tempo verifies its attestation before settlement. Inside the private Zone, the sequencer sends a batch and state witness to the Nitro prover, which replays it in AWS Nitro and returns a signed attestation. The sequencer submits the batch, quorum signatures and attestation to the Zone portal on Tempo. The portal checks the signatures, the native verifier checks the attestation, and the batch settles: state is recorded and withdrawals are queued. In T13, a NoProof batch skips the verifier and settles on quorum signatures alone. Private transactions and the state witness stay in the Zone. Tempo sees only the batch commitments, the attestation, and signatures. 1. **Prepare.** The sequencer groups Zone blocks into a batch and gathers a state witness: the starting state and the Tempo state the batch read. 2. **Prove.** The prover replays the batch inside an AWS Nitro Enclave running approved code, then signs an attestation bound to the Zone, the batch, and its resulting commitments. 3. **Settle.** The sequencer submits the batch, attestation, and quorum signatures to the Zone's portal. The portal checks the signatures and continuity, and the native verifier at `0x5a56000000000000000000000000000000000000` checks the AWS certificate chain, approved enclave measurements, and batch digest. Only then does the portal record the new state and queue withdrawals. The prover runs in a trusted execution environment: security rests on the approved enclave code and AWS Nitro's attestation. **Temporary NoProof fallback.** During rollout, a sequencer can also settle a batch in `NoProof` mode, which keeps the signature and continuity checks but skips attestation verification. Batches settled this way rely on sequencer signatures, as before T13. A later upgrade removes this mode. Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1098.md) and [Zone proving and settlement](https://tempo.xyz/developers/docs/protocol/zones/proving). ### Multi-block Tempo imports for Zones T13 lets one Zone block import a range of consecutive Tempo headers. A header-only block advances the Zone's Tempo checkpoint, and a full block then processes pending deposits and token enablements against the latest imported state. Zones can recover from a long outage without historical state proofs, and each batch stays small enough for the prover to replay. To keep that work bounded, each Zone portal limits pending items: | Limit | Value | Effect | |-------|-------|--------| | Unprocessed deposits | 230 | Withdrawal bounce-backs are rejected at this limit. | | Reserve for withdrawal bounce-backs | 20 | Ordinary deposits are rejected once 210 deposits are unprocessed. | | Unprocessed token enablements | 8 | `enableToken` reverts while eight enablements are pending. | A withdrawal batch is rejected if its size exceeds the remaining deposit capacity, because every withdrawal could bounce back. Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1096.md). ### Explicit block system calls T13 Tempo blocks run only two automatic system calls: the EIP-2935 parent-hash history update before transactions, and the committee update after the last block of each epoch. Blocks no longer schedule the EIP-4788 beacon-root call or the EIP-7002, EIP-7251, and builder request calls, and the execution-request list is always empty. Previously Tempo inherited Ethereum's system-call selection, so an upstream change, such as Amsterdam requiring builder contracts, could change which blocks are valid. Zone blocks follow the same rules. Transactions and receipts are unchanged. Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1119.md). ### Ordered fallback fee tokens Before T13, a transaction with no `feeToken`, no stored preference, and no inferred token pays its fee in pathUSD, and fails if the fee payer holds too little pathUSD. As OUSD becomes the recommended stablecoin on Tempo, many accounts hold OUSD but no pathUSD. T13 replaces that last step with an ordered list: pathUSD, then [OUSD](https://tempo.xyz/developers/docs/guide/ousd) (`0x20c0000000000000000000006a37da5c996874be`). If the transaction already has a fee token from feeToken, a stored preference, or inference, it pays in that token as before. Otherwise it pays in pathUSD if pathUSD covers the max fee, else in OUSD if OUSD covers it, else it is rejected for insufficient funds. One token must cover the whole maximum fee, `ceil(gasLimit * maxFeePerGas / 10^12)` in base units; balances are not combined. Only an insufficient balance moves on to OUSD: pause, policy, access-key, and Fee AMM liquidity failures on the selected token do not. Explicit `feeToken` values, `setUserToken` preferences, and inference from TIP-20 transfers and DEX swaps keep their precedence. The validator default fee token remains pathUSD. Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1115.md). ### Zone deposit and refund fixes * Zone deposits, withdrawal bounce-backs, and refund claims check TIP-403 `Recipient` authorization instead of `MintRecipient`. Receive policies and refund behavior are unchanged. * `ZoneInbox.claimRefund(token)` reverts with `NoRefund` when the caller has no pending refund for that token. ## Integration impact * **Transactions without a fee token:** standard Ethereum transactions, and Tempo transactions that leave `feeToken` empty with no stored preference, now pay in OUSD when the fee payer has too little pathUSD. No change is needed. To pin a token, set `feeToken` or call `setUserToken`. * **Integrations that pin pathUSD:** if you set `feeToken` to pathUSD, accept only pathUSD as a fee token, or require a pathUSD balance for gas, users who hold only OUSD still fail after T13. Accept OUSD, or omit `feeToken`. * **Wallets and fee displays:** read the fee token from the receipt's `feeToken` field. To estimate before signing, check pathUSD, then OUSD, against the maximum fee.