diff --git a/src/pages/_root.css b/src/pages/_root.css
index 007a62be..b92f76a2 100644
--- a/src/pages/_root.css
+++ b/src/pages/_root.css
@@ -1422,10 +1422,6 @@ body {
box-shadow: none;
}
-[data-v-sidebar] a[data-v-sidebar-item][href$="/protocol/upgrades/t7"] [data-v-sidebar-item-badge] {
- background: var(--color-gray4);
-}
-
/* ---------------------------------------------------------------------------
* Terminal theme — scoped color variables for the embedded terminal demo.
* --------------------------------------------------------------------------- */
diff --git a/src/pages/docs/build.mdx b/src/pages/docs/build.mdx
index fe3f5d65..8e7e1e08 100644
--- a/src/pages/docs/build.mdx
+++ b/src/pages/docs/build.mdx
@@ -24,7 +24,7 @@ Use [Agentic Payments](/docs/guide/machine-payments) when agents, APIs, or servi
/>
diff --git a/src/pages/docs/guide/issuance/distribute-rewards.mdx b/src/pages/docs/guide/issuance/distribute-rewards.mdx
index 066858c3..f0a77675 100644
--- a/src/pages/docs/guide/issuance/distribute-rewards.mdx
+++ b/src/pages/docs/guide/issuance/distribute-rewards.mdx
@@ -1,6 +1,6 @@
---
-title: Distribute Rewards
-description: Distribute rewards to token holders using TIP-20's built-in reward mechanism. Allocate tokens proportionally based on holder balances.
+title: Legacy Token Rewards
+description: Understand deprecated Tempo Token Rewards behavior and claim already-accrued rewards after T7.
interactive: true
---
@@ -15,21 +15,21 @@ import { OptInToRewards } from '../../../../components/guides/steps/rewards/OptI
import { StartReward } from '../../../../components/guides/steps/rewards/StartReward.tsx'
import { Cards, Card } from 'vocs'
-# Distribute Rewards
+# Legacy Token Rewards
-:::warning[Rewards deprecation planned]
-This change is planned for testnet on July 2, 2026 and mainnet on July 9, 2026. After activation, new Tempo Token Rewards opt-ins and distributions become no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow. See the [T7 network upgrade](/docs/protocol/upgrades/t7) for the full timeline and scope.
+:::warning[Rewards deprecated]
+T7 is active on testnet and mainnet. New Tempo Token Rewards opt-ins and distributions are no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow.
:::
-Distribute rewards to token holders using TIP-20's built-in reward distribution mechanism. Rewards allow parties to incentivize holders of a token by distributing tokens proportionally based on their balance.
+Tempo Token Rewards is deprecated. This page is retained for legacy integrations and for claiming already-accrued rewards.
-Rewards can be distributed by anyone on any TIP-20 token, and claimed by any holder who has opted in. This guide covers both the reward distributor and token holder use cases. While the demo below uses a token you create, the same principles apply to any token.
+Before T7, rewards could be distributed by anyone on any TIP-20 token and claimed by holders who had opted in. After T7, new opt-ins and distributions are no-ops; claiming already-accrued rewards remains supported.
-## Rewards distribution demo
+## Legacy rewards demo
-Try out the complete rewards flow: create a token, opt in to receive rewards on it, create a reward for yourself, and claim it.
+The historical flow below shows the legacy rewards surface. New opt-in and distribution calls are no-ops after T7, but the claim step remains relevant for already-accrued rewards.
-
+
@@ -46,11 +46,11 @@ Try out the complete rewards flow: create a token, opt in to receive rewards on
### [Optional] Create a reward token
-If you would like to distribute rewards on a token you have created, follow the [Create a Stablecoin](/docs/guide/issuance/create-a-stablecoin) guide to deploy your token.
+The legacy examples assume a token you have created. Follow the [Create a Stablecoin](/docs/guide/issuance/create-a-stablecoin) guide for the current token creation flow.
-### Tell users to opt in to rewards
+### Legacy: tell users to opt in to rewards
-Token holders must opt in to receive rewards by setting their reward recipient address. This is typically set to their own address.
+Before T7, token holders opted in to receive rewards by setting their reward recipient address. After T7, this call is a no-op for new opt-ins.
:::code-group
@@ -103,9 +103,9 @@ export const config = createConfig({
:::
-### Make a stablecoin reward distribution
+### Legacy: make a stablecoin reward distribution
-Anyone can make a reward distribution that allocates tokens to all opted-in holders proportionally based on their balance.
+Before T7, anyone could make a reward distribution that allocated tokens to all opted-in holders proportionally based on their balance. After T7, new distribution calls are no-ops.
:::code-group
@@ -216,9 +216,9 @@ export const config = createConfig({
## Rewards distribution recipes
-### Watch for new reward distributions
+### Legacy: watch for reward distribution events
-Use `useWatchRewardDistributed` to listen for new reward distributions on a token. This is useful for updating your UI when a reward is distributed.
+Use `useWatchRewardDistributed` to listen for historical reward distribution events on a token. New reward distributions are no-ops after T7.
```tsx twoslash
import { Hooks } from 'wagmi/tempo'
@@ -241,7 +241,7 @@ function WatchRewards() {
### Watch for reward opt-ins
-Use `useWatchRewardRecipientSet` to listen for when users opt in to rewards by setting their recipient address. This is useful for tracking opt-in activity.
+Use `useWatchRewardRecipientSet` to listen for historical reward opt-in activity. New reward opt-ins are no-ops after T7.
```tsx twoslash
import { Hooks } from 'wagmi/tempo'
@@ -266,13 +266,13 @@ function WatchOptIns() {
Required |
-T7 is live on testnet and supported by [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1), published on June 29, 2026. Mainnet node operators should upgrade before the mainnet activation timestamp.
+T7 is active on testnet and mainnet and supported by [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1), published on June 29, 2026. Node operators were required to run the T7-compatible release before their network's activation timestamp to stay synced.
---
diff --git a/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx b/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx
index 7039e535..19ec0101 100644
--- a/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx
+++ b/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx
@@ -19,8 +19,8 @@ Add liquidity for a token pair by placing orders on the Stablecoin DEX. You can
In this guide you will learn how to place buy and sell orders to provide liquidity on the Stablecoin DEX orderbook.
-:::info[Planned storage savings for active makers]
-After the T7 network upgrade, active makers may pay less gas when they cancel eligible orders or have eligible orders filled, then later place new eligible orders. See the [T7 network upgrade](/docs/protocol/upgrades/t7#user-attributed-dex-savings) for the feature details.
+:::info[Storage savings for active makers]
+With T7 active, active makers may pay less gas when they cancel eligible orders or have eligible orders filled, then later place new eligible orders. See the [T7 network upgrade](/docs/protocol/upgrades/t7#user-attributed-dex-savings) for the feature details.
:::
## Liquidity provider demo
diff --git a/src/pages/docs/index.mdx b/src/pages/docs/index.mdx
index 7064304a..3bd7ccca 100644
--- a/src/pages/docs/index.mdx
+++ b/src/pages/docs/index.mdx
@@ -48,7 +48,7 @@ If you are new to Tempo, start with **Connect to Tempo**, then use **Stablecoin
/>
diff --git a/src/pages/docs/protocol/fees/index.mdx b/src/pages/docs/protocol/fees/index.mdx
index a11bdba3..748e1e4c 100644
--- a/src/pages/docs/protocol/fees/index.mdx
+++ b/src/pages/docs/protocol/fees/index.mdx
@@ -11,10 +11,10 @@ Tempo has no native token. Instead, transaction fees—including both gas fees a
For a stablecoin to be accepted, it must be USD-denominated, issued as a native TIP-20 contract, and have sufficient liquidity on the native Fee AMM.
-Tempo currently uses a fixed base fee (rather than a variable base fee as in EIP-1559), set so that a TIP-20 transfer costs less than $0.001. All fees accrue to the validator who proposes the block.
+Tempo uses a bounded dynamic base fee. It can fall when block gas usage is below target and rise back toward the cap when the network is busy. For a 50,000 gas transfer, the base-fee cap is about $0.0006, with a quiet-period floor around $0.00003. All fees accrue to the validator who proposes the block.
:::info[Dynamic base fee]
-The T7 network upgrade introduces a dynamic base fee. It can fall when block gas usage is below target and rise back to the cap when the network is busy. For a 50,000 gas transfer, the base-fee ceiling moves from about $0.001 to a T7 cap of about $0.0006, with a quiet-period floor around $0.00003. See the [T7 network upgrade](/docs/protocol/upgrades/t7) and [dynamic base fee proposal](https://tips.sh/1067-1).
+T7 activated the dynamic base fee on testnet and mainnet. See the [T7 network upgrade](/docs/protocol/upgrades/t7) and [dynamic base fee specification](https://tips.sh/1067).
:::
For pool mechanics, swaps, liquidity accounting, and fee-token conversion rules, see the [Fee AMM specification](/docs/protocol/fees/spec-fee-amm).
diff --git a/src/pages/docs/protocol/fees/spec-fee.mdx b/src/pages/docs/protocol/fees/spec-fee.mdx
index 53861720..4d66d13f 100644
--- a/src/pages/docs/protocol/fees/spec-fee.mdx
+++ b/src/pages/docs/protocol/fees/spec-fee.mdx
@@ -25,9 +25,9 @@ Attodollars provide sufficient precision for low-fee transactions. Since TIP-20
### Base Fee Model
-Tempo uses a fixed base fee rather than the dynamic base fee mechanism specified in EIP-1559. The base fee is set such that a TIP-20 transfer costs less than $0.001.
+Tempo uses a bounded dynamic base fee. The base fee can fall when block gas usage is below target and rise back toward the cap when usage increases. The cap is set such that a TIP-20 transfer costs about $0.0006, with a quiet-period floor around $0.00003.
-The fixed base fee combined with USD-denominated payment provides predictable unit economics. Applications can budget for transaction costs without exposure to fee volatility or native token price fluctuations.
+The bounded base fee combined with USD-denominated payment provides predictable unit economics. Applications can budget for transaction costs without exposure to native token price fluctuations.
Congestion is managed through:
@@ -173,15 +173,16 @@ If validators have not specified a fee token preference, the protocol falls back
## Gas Parameters
-As of [TIP-1010](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1010.md), Tempo uses the following mainnet gas parameters:
+As of T7, Tempo uses the following mainnet gas parameters:
| Parameter | Value |
|-----------|-------|
-| Base fee | 20 billion attodollars per gas (`2 × 10^10`) |
+| Base fee cap | 12 billion attodollars per gas (`1.2 × 10^10`) |
+| Base fee floor | 600 million attodollars per gas (`6 × 10^8`) |
| Total block gas limit | 500M gas |
| General gas limit | 30M gas/block |
-A standard TIP-20 transfer (~50,000 gas) costs approximately 1,000 microdollars (0.1 cent / $0.001) at the base fee.
+A standard TIP-20 transfer (~50,000 gas) costs approximately 600 microdollars ($0.0006) at the cap and approximately 30 microdollars ($0.00003) at the floor.
### Removing validator preference
diff --git a/src/pages/docs/protocol/tip20-rewards/overview.mdx b/src/pages/docs/protocol/tip20-rewards/overview.mdx
index bd4624c7..9971db82 100644
--- a/src/pages/docs/protocol/tip20-rewards/overview.mdx
+++ b/src/pages/docs/protocol/tip20-rewards/overview.mdx
@@ -1,6 +1,6 @@
---
title: Tempo Token Rewards
-description: Built-in reward distribution mechanism for TIP-20 tokens enabling efficient, opt-in proportional rewards to token holders at scale.
+description: Legacy TIP-20 reward distribution behavior and the claim path for already-accrued rewards after T7.
---
import { Cards, Card } from 'vocs'
@@ -8,33 +8,33 @@ import { Cards, Card } from 'vocs'
# Tempo Token Rewards
:::warning[Tempo Token Rewards deprecation]
-T7 is live on testnet and planned for mainnet on July 9, 2026. After T7 activation on each network, new Tempo Token Rewards opt-ins and distributions are no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow.
+T7 is active on testnet and mainnet. New Tempo Token Rewards opt-ins and distributions are no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow.
:::
-Tempo Token Rewards is a built-in mechanism that allows for efficient distribution of rewards to opted-in token holders proportional to their holdings, while maintaining low gas costs at scale and complying with [TIP-403 transfer policies](/docs/protocol/tip403/spec).
+Tempo Token Rewards is a legacy built-in mechanism for distributing rewards to opted-in token holders proportional to their holdings, while maintaining low gas costs at scale and complying with [TIP-403 transfer policies](/docs/protocol/tip403/spec).
-Traditional reward mechanisms require tokens to be staked in separate contracts, which fragments user holdings and adds complexity to wallet implementations. Tempo Token Rewards solves this by:
+Before T7, Tempo Token Rewards solved this without requiring tokens to be staked in separate contracts:
-- **Built-in Distribution**: Rewards are integrated directly into the token contract, no separate staking required
-- **Opt-in Participation**: Users choose whether to participate by setting a reward recipient
-- **Proportional Distribution**: Rewards accrue based on token holdings automatically
-- **Instant Rewards**: Distribute rewards immediately to opted-in holders
+- **Built-in Distribution**: Rewards were integrated directly into the token contract, no separate staking required
+- **Opt-in Participation**: Users chose whether to participate by setting a reward recipient
+- **Proportional Distribution**: Rewards accrued based on token holdings automatically
+- **Instant Rewards**: Distributions applied immediately to opted-in holders
- **Efficient at Scale**: Constant-time updates regardless of the number of token holders
-- **Policy Compliant**: All reward transfers respect TIP-403 transfer policies
+- **Policy Compliant**: Reward transfers respected TIP-403 transfer policies
## Links
-
\ No newline at end of file
+
diff --git a/src/pages/docs/protocol/tip20-rewards/spec.mdx b/src/pages/docs/protocol/tip20-rewards/spec.mdx
index b58a7906..af807ce2 100644
--- a/src/pages/docs/protocol/tip20-rewards/spec.mdx
+++ b/src/pages/docs/protocol/tip20-rewards/spec.mdx
@@ -1,22 +1,22 @@
---
title: Tempo Token Rewards Specification
-description: Technical specification for Tempo Token Rewards using reward-per-token accumulator pattern for scalable pro-rata rewards.
+description: Legacy technical specification for Tempo Token Rewards and the claim path for already-accrued rewards after T7.
---
# Tempo Token Rewards Specification
-:::warning[Tempo Token Rewards cleanup planned]
-This change is planned for testnet on July 2, 2026 and mainnet on July 9, 2026. After activation, new reward opt-ins and new reward distributions become no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow. See the [T7 network upgrade](/docs/protocol/upgrades/t7) for the full timeline and scope.
+:::warning[Tempo Token Rewards deprecation]
+T7 is active on testnet and mainnet. New reward opt-ins and new reward distributions are no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow.
:::
## Abstract
-An opt-in, scalable, pro-rata reward distribution mechanism built into TIP-20 tokens. The system uses a "reward-per-token" accumulator pattern to distribute rewards proportionally to opted-in holders without requiring staking or per-holder iteration. Rewards are distributed instantly; time-based streaming distributions are planned for a future upgrade.
+This specification documents the legacy opt-in, scalable, pro-rata reward distribution mechanism built into TIP-20 tokens. The system uses a "reward-per-token" accumulator pattern to distribute rewards proportionally to opted-in holders without requiring staking or per-holder iteration. After T7, new opt-ins and new distributions are no-ops, while already-accrued rewards remain claimable.
## Motivation
-Many applications require pro-rata distribution of tokens to existing holders (incentive programs, deterministic inflation, staking rewards). Building this into TIP-20 allows efficient distribution without forcing users to stake tokens elsewhere or requiring distributors to loop over all holders.
+Many applications required pro-rata distribution of tokens to existing holders (incentive programs, deterministic inflation, staking rewards). Building this into TIP-20 allowed efficient distribution without forcing users to stake tokens elsewhere or requiring distributors to loop over all holders.
## Specification
-The rewards mechanism allows anyone to distribute token rewards to opted-in holders proportionally based on holdings. Users must opt in to receiving rewards and may delegate rewards to a recipient address.
+The legacy rewards mechanism allowed anyone to distribute token rewards to opted-in holders proportionally based on holdings. Users opted in to receiving rewards and could delegate rewards to a recipient address. After T7, new opt-ins and distributions are no-ops; `claimRewards()` remains available for already-accrued rewards.
## Tempo Token Rewards Functions
These functions are part of the [ITIP20](/docs/protocol/tip20/spec) interface:
diff --git a/src/pages/docs/protocol/tip20/overview.mdx b/src/pages/docs/protocol/tip20/overview.mdx
index c49d7cfa..abdc3c8a 100644
--- a/src/pages/docs/protocol/tip20/overview.mdx
+++ b/src/pages/docs/protocol/tip20/overview.mdx
@@ -43,10 +43,10 @@ Below are some of the key benefits and features of TIP-20 tokens:
title="Transfer Memos"
/>
@@ -131,9 +131,9 @@ TIP-20 tokens also have **pause/unpause** commands, which provide emergency cont
**Transfer memos** enable you to attach 32-byte memos to transfers for payment references, invoice IDs, or transaction notes.
-### Reward Distribution
+### Legacy Reward Distribution
-TIP-20 supports an opt-in [reward distribution system](/docs/protocol/tip20-rewards/overview) that allows issuers to distribute rewards to token holders. Rewards can be claimed by holders or automatically forwarded to designated recipient addresses.
+TIP-20 rewards are deprecated after T7. New opt-ins and distributions are no-ops, while already-accrued rewards remain claimable. See [Tempo Token Rewards](/docs/protocol/tip20-rewards/overview) for the legacy behavior and claim path.
### Currency Declaration
diff --git a/src/pages/docs/protocol/tip20/spec.mdx b/src/pages/docs/protocol/tip20/spec.mdx
index fe9d89ba..0cee31a3 100644
--- a/src/pages/docs/protocol/tip20/spec.mdx
+++ b/src/pages/docs/protocol/tip20/spec.mdx
@@ -1,20 +1,20 @@
---
title: TIP-20 Tokens Specification
-description: Technical specification for TIP-20 tokens, the optimized token standard extending ERC-20 with memos, rewards distribution, and policy integration.
+description: Technical specification for TIP-20 tokens, the optimized token standard extending ERC-20 with memos, legacy rewards behavior, and policy integration.
---
# TIP-20 Tokens Specification
## Abstract
-TIP-20 tokens are a suite of precompiles that provide a built-in optimized token implementation in the core protocol. They extend the ERC-20 token standard with built-in functionality like memo fields and reward distribution.
+TIP-20 tokens are a suite of precompiles that provide a built-in optimized token implementation in the core protocol. They extend the ERC-20 token standard with built-in functionality like memo fields, legacy rewards behavior, and transfer policies.
## Motivation
-All major stablecoins today use the ERC-20 token standard. While ERC-20 provides a solid foundation for fungible tokens, it lacks features critical for stablecoin issuers today such as memos, transfer policies, and rewards distribution. Additionally, since each ERC-20 token has its own implementation, integrators can't depend on consistent behavior across tokens.
+All major stablecoins today use the ERC-20 token standard. While ERC-20 provides a solid foundation for fungible tokens, it lacks features critical for stablecoin issuers today such as memos and transfer policies. Additionally, since each ERC-20 token has its own implementation, integrators can't depend on consistent behavior across tokens.
TIP-20 extends ERC-20, building these features into precompiled contracts that anyone can permissionlessly deploy on Tempo. This makes token operations much more efficient, allows issuers to quickly set up on Tempo, and simplifies integrations since it ensures standardized behavior across tokens.
It also enables deeper integration with token-specific Tempo features like paying gas in stablecoins and payment lanes.
## Specification
-TIP-20 tokens support standard fungible token operations such as transfers, mints, and burns. They also support transfers, mints, and burns with an attached 32-byte memo; a role-based access control system for token administrative operations; and a system for opt-in [reward distribution](/docs/protocol/tip20-rewards/spec).
+TIP-20 tokens support standard fungible token operations such as transfers, mints, and burns. They also support transfers, mints, and burns with an attached 32-byte memo; a role-based access control system for token administrative operations; and a legacy [reward distribution](/docs/protocol/tip20-rewards/spec) claim path for already-accrued rewards.
## TIP20
@@ -531,8 +531,8 @@ This generalizes the system-only path described above (`systemTransferFrom`, `tr
### Payment-channel reserve (TIP-1034)
The enshrined `TIP20ChannelReserve` precompile at [`0x4D50500000000000000000000000000000000000`](https://explore.tempo.xyz/address/0x4D50500000000000000000000000000000000000) (ASCII `MPP`) is a TIP-20 consumer rather than a change to the TIP-20 contract itself — it pulls funds via the implicit-approval path above and emits standard `Transfer` events from the host TIP-20. See the [enshrined TIP-20 reserve channel section of the T5 page](/docs/protocol/upgrades/t5#enshrined-tip-20-reserve-channel) for the channel lifecycle, channel ID derivation, and event surface.
-## Token Rewards Distribution
-See [rewards distribution](/docs/protocol/tip20-rewards/spec) for more information.
+## Legacy Token Rewards Distribution
+TIP-20 rewards are deprecated after T7. New reward opt-ins and distributions are no-ops, while already-accrued rewards remain claimable. See [rewards distribution](/docs/protocol/tip20-rewards/spec) for the legacy behavior and claim path.
## TIP20Factory
The `TIP20Factory` contract is the canonical entrypoint for creating new TIP-20 tokens on Tempo. The factory derives deterministic deployment addresses using a caller-provided salt, combined with the caller's address, under a fixed 12-byte TIP-20 prefix. This ensures that every TIP-20 token exists at a predictable, collision-free address. The `TIP20Factory` precompile is deployed at `0x20Fc000000000000000000000000000000000000`.
diff --git a/src/pages/docs/protocol/upgrades/t7.mdx b/src/pages/docs/protocol/upgrades/t7.mdx
index 4fd67c5c..d39108eb 100644
--- a/src/pages/docs/protocol/upgrades/t7.mdx
+++ b/src/pages/docs/protocol/upgrades/t7.mdx
@@ -1,6 +1,6 @@
---
title: T7 Network Upgrade
-description: Partner-focused overview and rollout dates for the T7 network upgrade, including storage savings, payment-channel savings, dynamic base fee behavior, and TIP-20 rewards deprecation.
+description: Partner-focused overview and activation status for the T7 network upgrade, including storage savings, payment-channel savings, dynamic base fee behavior, and TIP-20 rewards deprecation.
---
import { T7BenchmarkVisual } from '../../../../components/T7BenchmarkVisual'
@@ -12,7 +12,7 @@ T7 makes repeated onchain workflows cheaper. It adds storage savings for DEX ord
Apps with repeat contract workflows can pass meaningful gas savings to returning users, MPP sessions can reuse channel-state savings for the same payer, and all users can benefit from lower base fees during quieter network periods.
:::info[T7 status]
-T7 is live on testnet. Mainnet rollout is planned for July 9, 2026. Release [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) is required for T7; see the [Network Upgrades and Releases table](/docs/guide/node/network-upgrades#node-operator-updates) for the current node-operator release status.
+T7 is active on testnet and mainnet. Release [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) is required for T7; see the [Network Upgrades and Releases table](/docs/guide/node/network-upgrades#node-operator-updates) for the current node-operator release status.
:::
## Timeline
@@ -20,7 +20,7 @@ T7 is live on testnet. Mainnet rollout is planned for July 9, 2026. Release [v1.
| Milestone | Date |
|-----------|------|
| Testnet rollout | Live: July 2, 2026 |
-| Mainnet rollout | Planned: July 9, 2026 |
+| Mainnet rollout | Live: July 9, 2026 |
## Overview
@@ -41,7 +41,7 @@ These changes make costs easier to reason about for partners building high-throu
| Active DEX makers can benefit on repeat order placement | Maker-attributed storage credits let reusable order-storage savings stay attached to the maker who earned them. |
| Apps can avoid random gas discounts | Shared contracts can track which user earned credits and spend them only for that same user. |
| MPP sessions can get cheaper over repeated channel lifecycles | The credited reopen path, `open_new_channel_with_storage_credit`, is 60,225 gas in the channel-reserve gas snapshot. |
-| All integrators get a simpler low-fee story | The new base fee cap is 40% lower than today's fixed base fee, and quiet periods can be up to 20x cheaper than the cap. |
+| All integrators get a simpler low-fee story | The T7 base fee cap is 40% lower than the pre-T7 fixed base fee, and quiet periods can be up to 20x cheaper than the cap. |
## Features
@@ -73,16 +73,16 @@ Read [Accept pay-as-you-go payments](/docs/guide/machine-payments/pay-as-you-go)
### Dynamic base fee
-T7 replaces the fixed base fee with a bounded dynamic base fee. The new cap is 40% lower than the current fixed fee. When block gas usage is below target, the base fee can fall toward a floor that is one twentieth of the cap.
+T7 replaces the fixed base fee with a bounded dynamic base fee. The cap is 40% lower than the pre-T7 fixed fee. When block gas usage is below target, the base fee can fall toward a floor that is one twentieth of the cap.
For a simple fee example, a 50,000 gas transfer costs about $0.0006 at the new cap and about $0.00003 at the floor.
-| Example transaction | Today's fixed fee | T7 cap | T7 quiet-period floor |
+| Example transaction | Pre-T7 fixed fee | T7 cap | T7 quiet-period floor |
|---------------------|------------------:|-------:|----------------------:|
| 50,000 gas transfer | $0.0010 | $0.0006 | $0.00003 |
| 1,000,000 gas transaction | $0.0200 | $0.0120 | $0.0006 |
-At the quiet-period floor, the same transaction is 20x cheaper than the T7 cap and about 33x cheaper than today's fixed fee. The base fee starts at the cap at activation and moves with block usage.
+At the quiet-period floor, the same transaction is 20x cheaper than the T7 cap and about 33x cheaper than the pre-T7 fixed fee. After activation, the base fee moves with block usage within the T7 cap and floor.
### Deprecate TIP-20 rewards
@@ -124,11 +124,12 @@ The [v1.10.1 release notes](https://github.com/tempoxyz/tempo/releases/tag/v1.10
## Compatible releases
-The following release supports the T7 feature set:
+The following releases support the T7 feature set:
| Ecosystem | T7-compatible releases |
|-----------|------------------------|
-| Node operators | [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) |
+| Node operators | [`v1.10.1`](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) |
+| Rust | `tempo-alloy@1.8.1`, `tempo-primitives@1.8.1`, `tempo-contracts@1.8.1`, `tempo-chainspec@1.8.2` |
Release notes and binaries are available in the [v1.10.1 release](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1).
@@ -143,12 +144,12 @@ Release notes and binaries are available in the [v1.10.1 release](https://github
Wallets, checkout flows, and infrastructure that display fees should expect the base fee to move instead of staying fixed.
-- The base fee starts at the cap at activation.
-- Fees can fall when block gas usage is below target.
+- Fees can fall when block gas usage is below target and rise back toward the cap when usage increases.
+- Fee estimators should handle movement between the floor and cap.
- Fee analytics should compare pre-T7 fixed-fee periods separately from post-T7 dynamic-fee periods.
### For TIP-20 rewards deprecation
Apps that show TIP-20 reward information should stop presenting new rewards as accruing from post-T7 reward distributions.
-- Wallets and dashboards should separate already-accrued rewards from post-T7 balances.
+- Wallets and dashboards should separate already-accrued rewards from post-T7 balances.
\ No newline at end of file
diff --git a/vocs.config.ts b/vocs.config.ts
index 3090a61e..b1cd9718 100644
--- a/vocs.config.ts
+++ b/vocs.config.ts
@@ -857,12 +857,11 @@ export default defineConfig({
items: [
{
text: 'T7',
- badge: { text: 'Next', variant: 'note' as const },
+ badge: { text: 'Latest', variant: 'info' as const },
link: '/docs/protocol/upgrades/t7',
},
{
text: 'T6',
- badge: { text: 'Latest', variant: 'info' as const },
link: '/docs/protocol/upgrades/t6',
},
{