# T12 Network Upgrade

T12 adds configurable nonces for parallel expiring transactions, enables MPP sessions with closed-loop stablecoins, restores compatibility with calldata suffixes, aligns quote and swap calculations, and adds authorized burns for TIP-20 tokens.

**Integration note:** If you use fixed gas limits, some calls to Tempo's native contracts may need a small increase after T12. Fees remain based on gas actually used. [See integration guidance](#breaking-changes).

## Timeline

| Network | Planned activation |
|---------|--------------------|
| Testnet | October 8, 2026 — time TBD |
| Mainnet | October 13, 2026 — time TBD |

<span id="t12-upgrade-overview" />

<span id="overview" />

## T12 overview

* **Configurable nonces for expiring transactions:** lets developers submit otherwise identical transactions in parallel by assigning distinct `nonce` values, without coordinating sequential nonces.
* **MPP sessions for closed-loop stablecoins:** lets prepaid credits fund payment channels while preserving restrictions on which merchants can receive payments.
* **Relaxed ABI validation:** accepts correctly formatted calls to Tempo's built-in contracts with extra data at the end.
* **More reliable swap quotes:** fixes rounding differences between the amount quoted and the amount calculated during a swap.
* **Authorized burns for TIP-20 tokens:** lets stablecoin issuers support burn-and-mint bridging without a separate token approval from the user.

<span id="features" />

## T12 features

<span id="easier-repeated-payments" />

### Configurable nonces for expiring transactions

T12 lets developers set the existing `nonce` field on expiring transactions to any `uint64` value. Distinct values let otherwise identical transactions be submitted in parallel within the same validity window, without coordinating sequential nonces.

This replaces access-list entries used only to make transactions unique. Transactions without an access list can use the [payment lane](https://tempo.xyz/developers/docs/protocol/blockspace/payment-lane-specification) if they meet its other requirements.

Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1106.md).

<span id="payment-channels-for-restricted-tokens" />

### MPP sessions for closed-loop stablecoins

T12 enables recipient-restricted TIP-20 tokens, such as prepaid credits, to work with MPP payment channels. Users can fund a session and pay approved merchants without the issuer also having to allowlist the channel reserve.

Funding and settlement check TIP-403 permissions against the channel's payer and payee. Refunds can return unused funds to the original payer without adding them to the recipient allowlist. Token pauses and account receive policies still apply.

Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1095.md).

<span id="compatibility-with-appended-data" />

<span id="support-for-extra-information" />

### Relaxed ABI validation

T12 relaxes ABI decoding to accept trailing bytes in otherwise valid calls to Tempo's built-in contracts. This restores compatibility with [calls rejected at T11](https://tempo.xyz/developers/docs/protocol/upgrades/t11); other strict decoding checks remain.

Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1116.md).

<span id="more-reliable-swap-quotes" />

### Accurate swap quotes and cheaper execution

T12 makes Stablecoin DEX quotes use the same per-order matching and rounding as swaps. For unchanged orderbook state, quoted amounts match swap fill calculations, eliminating rounding differences that could cause unexpected reverts.

This also removes redundant liquidity-tracking writes during swaps, order placement, and cancellation.

Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1088.md).

### Authorized burns for TIP-20 tokens

Stablecoin issuers use burn-and-mint bridges to move tokens between chains: tokens are burned on the source chain and the corresponding amount is minted on the destination chain, keeping total supply unchanged.

T12 adds `burnAt(from, amount)`, which lets an issuer's bridge burn tokens directly from a user's balance when they bridge out, without requiring a separate token approval. The issuer grants the bridge `BURN_AT_ROLE`.

Token pauses, protected-address checks, and applicable access-key spending limits still apply.

Read the [specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1006.md).

## Integration impact

* **Parallel transactions:** if your integration needs to submit otherwise identical expiring transactions in parallel, assign each a distinct `uint64` nonce after T12 activates. For example, use `nonce = 101` and `nonce = 102` for two otherwise identical transactions. Ensure builders and signers preserve the supplied nonce, and remove access-list entries used only to make transactions unique. To retry a transaction, resend its original signed transaction while valid.
* **MPP integrations:** after T12 activates, you can use closed-loop credits with [MPP sessions](https://tempo.xyz/developers/docs/guide/machine-payments/pay-as-you-go). Existing channels need no migration.
* **ABI compatibility:** if your integration was affected by [T11's strict ABI validation](https://tempo.xyz/developers/docs/protocol/upgrades/t11), you can restore calldata suffixes after T12 activates on your network.
* **DEX integrations:** quote and swap APIs are unchanged. If you read tick liquidity totals directly from storage, switch to `getTickLevel()` or sum the remaining amounts of active orders. Stored tick totals stop updating at T12.
* **Token issuers:** to use `burnAt` after T12 activates, grant `BURN_AT_ROLE` only to tightly scoped contracts, such as a bridge that burns only amounts users request to bridge out. Existing `ISSUER_ROLE` and `BURN_BLOCKED_ROLE` permissions do not grant access to `burnAt`.

### Breaking changes

**Gas limits for native contract calls**

T12 applies the [EIP-2200 safety check](https://eips.ethereum.org/EIPS/eip-2200) to Tempo's native contracts. Before writing to storage, a call must have more than 2,300 gas remaining; otherwise, it fails with an out-of-gas error.

If your integration hardcodes transaction gas limits, re-estimate them on T12 testnet. If a contract explicitly caps the gas forwarded to a native contract, test and adjust that cap as needed.

A higher gas limit provides the required execution headroom, while fees remain based on the gas actually used.