diff --git a/src/components/StorageSavingsExplorer.tsx b/src/components/StorageSavingsExplorer.tsx
new file mode 100644
index 00000000..3fdd9d9c
--- /dev/null
+++ b/src/components/StorageSavingsExplorer.tsx
@@ -0,0 +1,222 @@
+'use client'
+
+import * as React from 'react'
+import { Container } from './Container'
+
+type Scenario = {
+  id: string
+  label: string
+  description: string
+  earnLabel: string
+  earnBefore: number
+  earnAfter: number
+  reuseLabel: string
+  reuseBefore: number
+  reuseAfter: number
+}
+
+const SCENARIOS: Scenario[] = [
+  {
+    id: 'cancel',
+    label: 'Order is canceled',
+    description:
+      'The maker cancels an eligible order, then returns later to place another eligible order.',
+    earnLabel: 'Cancel bid, earn reusable savings',
+    earnBefore: 304_741,
+    earnAfter: 361_184,
+    reuseLabel: 'Same maker reuses savings after cancel',
+    reuseBefore: 2_075_413,
+    reuseAfter: 868_756,
+  },
+  {
+    id: 'full-fill',
+    label: 'Order is fully filled',
+    description:
+      'An eligible order is fully filled, then the same maker returns later with another eligible order.',
+    earnLabel: 'Full fill, earn reusable savings',
+    earnBefore: 384_497,
+    earnAfter: 436_040,
+    reuseLabel: 'Same maker reuses savings after full fill',
+    reuseBefore: 1_828_213,
+    reuseAfter: 621_456,
+  },
+]
+
+const numberFormat = new Intl.NumberFormat('en-US')
+const percentFormat = new Intl.NumberFormat('en-US', {
+  maximumFractionDigits: 1,
+})
+
+function formatGas(value: number) {
+  return `${numberFormat.format(value)} gas`
+}
+
+function formatSignedGas(value: number) {
+  const sign = value > 0 ? '+' : value < 0 ? '-' : ''
+  return `${sign}${formatGas(Math.abs(value))}`
+}
+
+function formatSavings(value: number) {
+  if (value > 0) return `${formatGas(value)} saved`
+  if (value < 0) return `${formatGas(Math.abs(value))} more`
+  return 'No gas change'
+}
+
+function formatPercent(value: number) {
+  const sign = value > 0 ? '+' : value < 0 ? '-' : ''
+  return `${sign}${percentFormat.format(Math.abs(value))}%`
+}
+
+function changePercent(before: number, after: number) {
+  return ((after - before) / before) * 100
+}
+
+export function StorageSavingsExplorer() {
+  const [scenarioId, setScenarioId] = React.useState(SCENARIOS[0].id)
+  const [repeatOrders, setRepeatOrders] = React.useState(1)
+  const scenario = SCENARIOS.find((item) => item.id === scenarioId) ?? SCENARIOS[0]
+
+  const earningCost = scenario.earnAfter - scenario.earnBefore
+  const reuseSavings = scenario.reuseBefore - scenario.reuseAfter
+  const beforeTotal = scenario.earnBefore + scenario.reuseBefore * repeatOrders
+  const afterTotal = scenario.earnAfter + scenario.reuseAfter * repeatOrders
+  const netSavings = beforeTotal - afterTotal
+  const netPercent = changePercent(beforeTotal, afterTotal)
+  const breaksEven = reuseSavings > earningCost
+  const updateRepeatOrders = (value: number) => {
+    setRepeatOrders(Math.min(10, Math.max(1, value)))
+  }
+
+  return (
+    <Container
+      headerLeft={
+        <h4 className="font-normal text-[14px] text-gray12 leading-none">
+          Storage savings explorer
+        </h4>
+      }
+      footer={
+        <span>
+          Uses the merged DEX benchmark in{' '}
+          <a href="https://github.com/tempoxyz/tempo/pull/5903">tempoxyz/tempo#5903</a>. These
+          numbers are for the StablecoinDEX benchmark only.
+        </span>
+      }
+    >
+      <div className="space-y-5">
+        <div className="space-y-2">
+          <p className="m-0 text-gray11 text-sm">
+            Pick the lifecycle that earns a storage saving, then choose how many later eligible
+            orders the same maker places.
+          </p>
+
+          <fieldset className="grid gap-2 md:grid-cols-2">
+            <legend className="sr-only">Storage lifecycle</legend>
+            {SCENARIOS.map((item) => {
+              const active = item.id === scenario.id
+              return (
+                <button
+                  key={item.id}
+                  type="button"
+                  aria-pressed={active}
+                  onClick={() => setScenarioId(item.id)}
+                  className={`rounded-md border px-3 py-2 text-left text-sm transition-colors ${
+                    active
+                      ? 'border-accent bg-accent/10 text-gray12'
+                      : 'border-gray5 bg-gray1 text-gray11 hover:border-gray8 hover:text-gray12'
+                  }`}
+                >
+                  <span className="block font-medium">{item.label}</span>
+                  <span className="mt-1 block text-[13px] leading-5">{item.description}</span>
+                </button>
+              )
+            })}
+          </fieldset>
+        </div>
+
+        <div className="space-y-2 text-sm">
+          <div className="flex items-center justify-between gap-3 text-gray11">
+            <span id="repeat-orders-label">Later eligible orders by the same maker</span>
+            <span className="flex items-center gap-2">
+              <button
+                type="button"
+                aria-label="Decrease later eligible orders"
+                disabled={repeatOrders === 1}
+                onClick={() => updateRepeatOrders(repeatOrders - 1)}
+                className="grid h-7 w-7 place-items-center rounded-md border border-gray5 text-gray12 disabled:cursor-not-allowed disabled:opacity-40"
+              >
+                -
+              </button>
+              <strong className="min-w-5 text-center text-gray12">{repeatOrders}</strong>
+              <button
+                type="button"
+                aria-label="Increase later eligible orders"
+                disabled={repeatOrders === 10}
+                onClick={() => updateRepeatOrders(repeatOrders + 1)}
+                className="grid h-7 w-7 place-items-center rounded-md border border-gray5 text-gray12 disabled:cursor-not-allowed disabled:opacity-40"
+              >
+                +
+              </button>
+            </span>
+          </div>
+          <input
+            type="range"
+            min="1"
+            max="10"
+            value={repeatOrders}
+            aria-labelledby="repeat-orders-label"
+            onChange={(event) => updateRepeatOrders(Number(event.currentTarget.value))}
+            onInput={(event) => updateRepeatOrders(Number(event.currentTarget.value))}
+            className="w-full accent-gray12"
+          />
+        </div>
+
+        <div className="grid gap-4 md:grid-cols-[1fr_1.1fr]">
+          <div className="space-y-3">
+            <h5 className="m-0 font-medium text-[14px] text-gray12">Benchmark impact</h5>
+
+            <div className="grid grid-cols-[1fr_auto] gap-x-4 gap-y-2 text-sm">
+              <span className="text-gray11">{scenario.earnLabel}</span>
+              <span className="text-right text-gray12">
+                {formatSignedGas(earningCost)} (
+                {formatPercent(changePercent(scenario.earnBefore, scenario.earnAfter))})
+              </span>
+              <span className="text-gray11">{scenario.reuseLabel}</span>
+              <span className="text-right text-gray12">
+                {formatSavings(reuseSavings)} (
+                {formatPercent(changePercent(scenario.reuseBefore, scenario.reuseAfter))})
+              </span>
+              <span className="text-gray11">Net over this lifecycle</span>
+              <span className="text-right font-medium text-gray12">
+                {formatSavings(netSavings)} ({formatPercent(netPercent)})
+              </span>
+            </div>
+          </div>
+
+          <div className="space-y-3">
+            <h5 className="m-0 font-medium text-[14px] text-gray12">Who should get the saving?</h5>
+
+            <ol className="m-0 grid list-decimal gap-2 pl-5 text-gray11 text-sm">
+              <li>Alice clears eligible order storage and earns reusable savings.</li>
+              <li>Bob places an order later, but does not spend Alice's savings.</li>
+              <li>Alice returns and can use the savings she earned.</li>
+            </ol>
+          </div>
+        </div>
+
+        <div className="border-gray4 border-t pt-4 text-gray11 text-sm">
+          {breaksEven ? (
+            <p className="m-0">
+              In this benchmark, one later eligible order is enough to outweigh the extra gas paid
+              when the DEX records who earned the reusable savings.
+            </p>
+          ) : (
+            <p className="m-0">
+              This lifecycle needs more repeat usage before the reusable savings outweigh the
+              upfront accounting cost.
+            </p>
+          )}
+        </div>
+      </div>
+    </Container>
+  )
+}
diff --git a/src/pages/guide/issuance/distribute-rewards.mdx b/src/pages/guide/issuance/distribute-rewards.mdx
index 56e4f2c6..e91bf6c4 100644
--- a/src/pages/guide/issuance/distribute-rewards.mdx
+++ b/src/pages/guide/issuance/distribute-rewards.mdx
@@ -16,6 +16,10 @@ import { Cards, Card } from 'vocs'
 
 # Distribute Rewards
 
+:::warning[Rewards deprecation planned]
+This change is planned for testnet on June 30, 2026 and mainnet on July 6, 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 [network upgrade overview](/protocol/upgrades/t7) for the full timeline and scope.
+:::
+
 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.
 
 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.
diff --git a/src/pages/guide/node/network-upgrades.mdx b/src/pages/guide/node/network-upgrades.mdx
index c95780b6..348d2c05 100644
--- a/src/pages/guide/node/network-upgrades.mdx
+++ b/src/pages/guide/node/network-upgrades.mdx
@@ -36,15 +36,15 @@ For detailed release notes and binaries, see the [Changelog](/changelog).
 
 | | |
 |---|---|
-| **Scope** | Lower fees for work that is expected to expire; lower the base fee when gas is below the target threshold; remove TIP-20 rewards |
-| **TIPs** | [TIP-1060: Gas Credits Primitive](https://tips.sh/1060), [TIP-1064: Gas Credits for DEX](https://tips.sh/1064), [TIP-1066: Gas Credits for MPP](https://tips.sh/1066), [TIP-1067: Dynamic Base Fee](https://tips.sh/1067-1), [TIP-1075: Remove TIP-20 Rewards](https://github.com/tempoxyz/tempo/pull/5380) |
-| **Details** | [T7 network upgrade](/protocol/upgrades/t7) |
+| **Scope** | Reusable storage savings; user-attributed DEX storage savings; dynamic base fee; Tempo Token Rewards cleanup |
+| **References** | [Contract storage credits proposal (TIP-1060)](https://github.com/tempoxyz/tempo/pull/4016), [StablecoinDEX order storage credits proposal (TIP-1064)](https://github.com/tempoxyz/tempo/pull/4082), [Dynamic base fee proposal](https://github.com/tempoxyz/tempo/pull/5153), [Rewards deprecation proposal](https://github.com/tempoxyz/tempo/pull/5380) |
+| **Details** | [Network upgrade overview](/protocol/upgrades/t7) |
 | **Release** | TBD |
 | **Testnet** | Planned: June 30, 2026 |
 | **Mainnet** | Planned: July 6, 2026 |
 | **Priority** | TBD |
 
-T7 is planned but does not have a release yet. Node operator upgrade guidance will be added when the T7-compatible release is available.
+T7 is planned for testnet on June 30, 2026 and mainnet on July 6, 2026. Node operator upgrade guidance will be added when the T7-compatible release is available.
 
 ---
 
diff --git a/src/pages/guide/stablecoin-dex/providing-liquidity.mdx b/src/pages/guide/stablecoin-dex/providing-liquidity.mdx
index e7f4d16d..34a83edb 100644
--- a/src/pages/guide/stablecoin-dex/providing-liquidity.mdx
+++ b/src/pages/guide/stablecoin-dex/providing-liquidity.mdx
@@ -18,6 +18,10 @@ 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 or fully fill eligible orders and later place new eligible orders. See [Storage Savings to Benefit Your Users](/guide/t7-storage-credits) for the DEX benchmark and allocation pattern.
+:::
+
 ## Demo
 
 <Demo.Container name="Place an Order" footerVariant="source" src="tempoxyz/examples/tree/main/examples/exchange">
diff --git a/src/pages/guide/t7-storage-credits.mdx b/src/pages/guide/t7-storage-credits.mdx
new file mode 100644
index 00000000..ae42e4ce
--- /dev/null
+++ b/src/pages/guide/t7-storage-credits.mdx
@@ -0,0 +1,146 @@
+---
+title: Storage Savings to Benefit Your Users
+description: Learn how shared contracts can use storage savings to benefit the users who earned them.
+interactive: true
+---
+
+import { StorageSavingsExplorer } from '../../components/StorageSavingsExplorer'
+
+# Storage Savings to Benefit Your Users
+
+Storage credits are a planned network feature for contracts that create storage, clear it, and later create storage again in the same contract. The benefit is strongest for repeat workflows with temporary state, such as DEX orders.
+
+For partners, the important question is not just "can my contract earn a storage credit?" It is "how should I allocate the storage credits to benefit my users fairly?"
+
+:::info[Feature status]
+Storage credits are planned for the T7 network upgrade: testnet on June 30, 2026 and mainnet on July 6, 2026. Scope and dates may change before activation.
+:::
+
+## DEX benchmark example
+
+The DEX benchmark shows why user-level allocation matters. Fresh order placement stays effectively unchanged, while same-maker reuse becomes much cheaper in the measured lifecycle.
+
+| Flow | Before | After | Gas change |
+|---|---:|---:|---:|
+| Fresh place bid | 2,595,385 | 2,604,066 | +8,681 (+0.3%) |
+| Fresh place ask | 2,348,185 | 2,356,766 | +8,581 (+0.4%) |
+| Cancel bid, earn reusable savings | 304,741 | 361,184 | +56,443 (+18.5%) |
+| **Same maker reuses savings after cancel** | **2,075,413** | **868,756** | **1,206,657 gas saved (-58.1%)** |
+| Full fill, earn reusable savings | 384,497 | 436,040 | +51,543 (+13.4%) |
+| **Same maker reuses savings after full fill** | **1,828,213** | **621,456** | **1,206,757 gas saved (-66.0%)** |
+
+Fresh wallet flows are effectively unchanged. The credit-earning steps cost more because the DEX records who earned the reusable savings. The benefit appears when the same maker later places another eligible order: the repeat order is about 1.21M gas cheaper.
+
+## Explore the savings pattern
+
+<StorageSavingsExplorer />
+
+The explorer uses the merged StablecoinDEX benchmark numbers because that is the clearest verified example today. Use it to understand the pattern, then benchmark the specific partner flow before making claims for a bridge, vault, routing contract, or other shared system.
+
+## How storage credits work
+
+The storage credit primitive gives an account a storage credit when it clears one of its own storage slots. Later, that same account can use the credit to reduce the gas cost of creating storage again.
+
+In simple terms:
+
+1. A contract creates storage.
+2. The contract later clears that storage.
+3. The network records a storage credit for that contract.
+4. The contract can use that credit to reduce gas for a future storage creation.
+
+This is useful when storage is temporary rather than permanent. A one-time storage write is different from a repeated create, clear, and recreate pattern.
+
+## Why shared contracts need allocation
+
+Storage credits belong to the account that owns the storage. For shared contracts, that usually means the contract earns the credit, not the end user automatically.
+
+That creates an allocation problem.
+
+For example:
+
+1. Alice places and later cancels an order.
+2. The DEX clears Alice's order storage and earns a storage credit.
+3. Bob places a new order later.
+4. Without user-level accounting, Bob could receive the benefit from storage Alice cleared.
+
+Contracts that serve many users should add their own accounting layer when credits need to stay attached to a specific user, payer, maker, or account.
+
+## Pattern: credit the user who cleared state
+
+The planned DEX implementation applies this idea to the StablecoinDEX.
+
+Instead of treating all DEX storage credits as one shared pool, the DEX tracks which maker earned reusable order-storage savings. When that same maker later creates eligible order storage, the DEX can apply that maker's savings.
+
+Technically, [TIP-1064](https://github.com/tempoxyz/tempo/pull/4082) applies this allocation pattern to the StablecoinDEX on top of [TIP-1060](https://github.com/tempoxyz/tempo/pull/4016), the planned contract storage credits primitive.
+
+| Event | Result |
+|---|---|
+| Maker cancels an eligible order | The DEX clears order storage and records reusable savings for that maker |
+| Maker's order is fully filled | The DEX clears order storage and records reusable savings for that maker |
+| Same maker places a later eligible order | The DEX can apply that maker's savings |
+| Different maker places an order | They do not consume savings they did not earn |
+
+Use this pattern for shared contracts:
+
+1. Identify which storage is clearly attributable to one user.
+2. Credit that user when the contract clears that storage.
+3. Spend that user's credits only when the same user creates eligible storage later.
+4. Keep shared accounting storage separate from user-attributed storage.
+
+## Prevent cross-user leakage
+
+User-level allocation prevents one user's savings from being spent by another user.
+
+| Case | Expected behavior |
+|---|---|
+| Same maker returns after earning savings | Apply that maker's stored savings to an eligible order |
+| Different maker places the next order | Do not spend the first maker's savings |
+| Shared internal accounting is cleared | Do not assign the saving to whichever user happened to trigger cleanup |
+
+The DEX benchmark includes cross-user isolation tests to prove this behavior, but the partner-facing rule is simpler: savings earned by Alice should stay available to Alice, and Bob should pay the normal cost unless Bob earned savings too.
+
+## When to use this pattern
+
+Use this pattern when the same user, payer, maker, or account has a repeated lifecycle:
+
+1. The contract creates temporary storage for that user.
+2. The contract later clears that storage.
+3. The same user is likely to create storage again through the same contract.
+4. The contract can track that user's credits without mixing them with unrelated users.
+
+For bridge, vault, routing, and other shared-contract flows, benchmark the specific workflow before making partner-facing claims. Do not reuse DEX numbers for a different contract shape.
+
+## Partner checklist
+
+When deciding whether a contract can benefit from storage credits, check:
+
+1. Does the contract create storage during the user flow?
+2. Does the contract later clear that storage?
+3. Is the cleared storage attributable to one user, payer, order owner, or account?
+4. Does the same user later create eligible storage again?
+5. Can the contract track credits per user instead of sharing all credits globally?
+6. Are there shared internal accounting slots that should not be credited to any one user?
+7. Do gas estimates differ between first-time usage and repeated usage?
+8. Do benchmarks include cross-user cases to make sure credits do not leak?
+9. Are the numbers from a merged benchmark or a partner-specific test, rather than a draft confidence check?
+
+## What not to assume
+
+Storage credits are not a blanket gas discount.
+
+Do not assume:
+
+- Every transaction gets cheaper.
+- First-time users receive the same savings as repeat users.
+- Contract-level credits automatically map to the right end user.
+- Shared accounting storage should be credited to whichever user happened to trigger the cleanup.
+- DEX benchmark numbers apply to bridge, vault, or routing contracts without testing those workflows separately.
+
+## Related pages
+
+- [Network upgrade overview](/protocol/upgrades/t7)
+- [Providing Liquidity](/protocol/exchange/providing-liquidity)
+- [Stablecoin DEX Specification](/protocol/exchange/spec)
+- [Contract storage credits proposal (TIP-1060)](https://github.com/tempoxyz/tempo/pull/4016)
+- [StablecoinDEX order storage credits proposal (TIP-1064)](https://github.com/tempoxyz/tempo/pull/4082)
+- [Merged DEX benchmark](https://github.com/tempoxyz/tempo/pull/5903)
diff --git a/src/pages/protocol/exchange/providing-liquidity.mdx b/src/pages/protocol/exchange/providing-liquidity.mdx
index cbea348a..41ba8ee1 100644
--- a/src/pages/protocol/exchange/providing-liquidity.mdx
+++ b/src/pages/protocol/exchange/providing-liquidity.mdx
@@ -16,6 +16,10 @@ The DEX uses an onchain orderbook where you can place orders at specific price t
 
 Unlike traditional AMMs, you specify exact prices where you want to buy or sell, giving you more precise control over your liquidity provision strategy.
 
+:::info[Storage credits for DEX makers]
+The planned storage credits feature can reduce gas for active DEX makers who repeatedly place, cancel, or fully fill eligible orders. See [Storage Savings to Benefit Your Users](/guide/t7-storage-credits) for the allocation pattern and benchmark examples.
+:::
+
 ## Order Types
 
 ### Limit Orders
diff --git a/src/pages/protocol/fees/index.mdx b/src/pages/protocol/fees/index.mdx
index f7d48e28..5760938d 100644
--- a/src/pages/protocol/fees/index.mdx
+++ b/src/pages/protocol/fees/index.mdx
@@ -10,7 +10,11 @@ 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 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 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.
+
+:::info[Dynamic base fee]
+A planned dynamic base fee can fall when block gas usage is below target and rise back to the cap when the network is busy. See the [network upgrade overview](/protocol/upgrades/t7) and [dynamic base fee proposal](https://tips.sh/1067).
+:::
 
 ## Learn More
 
diff --git a/src/pages/protocol/tip20-rewards/overview.mdx b/src/pages/protocol/tip20-rewards/overview.mdx
index 6e8dd980..06207c14 100644
--- a/src/pages/protocol/tip20-rewards/overview.mdx
+++ b/src/pages/protocol/tip20-rewards/overview.mdx
@@ -6,6 +6,10 @@ import { Cards, Card } from 'vocs'
 
 # Tempo Token Rewards
 
+:::warning[Tempo Token Rewards cleanup planned]
+This change is planned for testnet on June 30, 2026 and mainnet on July 6, 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 [network upgrade overview](/protocol/upgrades/t7) for the full timeline and scope.
+:::
+
 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](/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:
diff --git a/src/pages/protocol/tip20-rewards/spec.mdx b/src/pages/protocol/tip20-rewards/spec.mdx
index ef7e8209..3b3c04c6 100644
--- a/src/pages/protocol/tip20-rewards/spec.mdx
+++ b/src/pages/protocol/tip20-rewards/spec.mdx
@@ -4,6 +4,10 @@ description: Technical specification for Tempo Token Rewards using reward-per-to
 
 # Tempo Token Rewards Specification
 
+:::warning[Tempo Token Rewards cleanup planned]
+This change is planned for testnet on June 30, 2026 and mainnet on July 6, 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 [network upgrade overview](/protocol/upgrades/t7) for the full timeline and scope.
+:::
+
 ## 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.
 
diff --git a/src/pages/protocol/upgrades/t7.mdx b/src/pages/protocol/upgrades/t7.mdx
index 6b26d74f..2f6fc9d6 100644
--- a/src/pages/protocol/upgrades/t7.mdx
+++ b/src/pages/protocol/upgrades/t7.mdx
@@ -1,17 +1,19 @@
 ---
 title: T7 Network Upgrade
-description: Planned overview for the T7 network upgrade, including gas credits, dynamic base fee behavior, and removal of TIP-20 rewards.
+description: Planned overview for the T7 network upgrade, including storage savings, lower quiet-period fees, and Tempo Token Rewards cleanup.
 ---
 
 # T7 Network Upgrade
 
-T7 is a planned network upgrade focused on lowering fees for work that is expected to expire, lowering the base fee when gas usage is below the target threshold, and removing TIP-20 rewards.
+T7 is a planned network upgrade focused on making real repeat usage cheaper. It introduces storage credits for contracts that create and clear temporary state, lets the network lower fees when usage is quiet, and cleans up Tempo Token Rewards activity that partners should stop building new flows around.
 
-:::info[T7 status]
-T7 is planned but does not have a release yet. The scope and rollout dates may change before activation.
+For partners, the headline is simple: apps with repeat contract workflows can pass meaningful gas savings to returning users, while all users can benefit from lower base fees during low-usage periods.
+
+:::info[Planned upgrade]
+T7 is planned for testnet on June 30, 2026 and mainnet on July 6, 2026. Scope and dates may change before activation.
 :::
 
-## Timeline
+## Release timeline
 
 | Network | Date |
 |---------|------|
@@ -20,26 +22,106 @@ T7 is planned but does not have a release yet. The scope and rollout dates may c
 
 Node operator upgrade guidance will be added when the T7-compatible release is available.
 
-## Planned scope
+## Overview
+
+T7 focuses on four partner-facing changes:
+
+- **Reusable storage savings.** Contracts that create storage, clear it, and later create storage again in the same contract can lower the cost of the next eligible storage write.
+- **Savings tied to the right user.** Shared systems such as the StablecoinDEX can keep those savings attached to the maker who earned them, instead of letting the next user spend them by accident.
+- **Lower fees during quiet periods.** T7 replaces the fixed base fee with a bounded dynamic fee that can fall when block gas usage is below target.
+- **Rewards cleanup.** New Tempo Token Rewards opt-ins and distributions stop after activation, while already-accrued rewards remain claimable.
+
+For partners, the main opportunity is to identify workflows with temporary state and decide whether the contract should allocate storage-credit savings per user, payer, maker, or account.
+
+## Why it matters
+
+| Partner impact | What changes |
+|----------------|--------------|
+| Active DEX makers can pay much less on repeat order placement | In the merged DEX benchmark, same-maker reuse is about 1.21M gas cheaper after a cancel or full fill. |
+| Returning users can benefit without first-time flows getting worse | Fresh DEX order placement changes by less than 0.5% in the measured bid and ask flows. |
+| Apps can avoid random gas discounts | Shared contracts can track which user earned credits and spend them only for that same user. |
+| 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. |
+
+## Features
+
+### Reusable storage savings
+
+Storage credits lower gas for workflows that repeatedly create and clear temporary storage. A contract earns a credit when it clears eligible storage, then can use that credit to reduce the cost of creating eligible storage later.
+
+This is not a blanket gas discount. It matters most when a workflow has a natural lifecycle: create state, clear it, then create more state in the same contract.
+
+### User-attributed DEX savings
+
+The StablecoinDEX uses the same idea but adds user-level accounting. If a maker cancels or fully fills an eligible order, the DEX can keep the reusable order-storage savings attached to that maker. When the same maker places a later eligible order, the DEX can apply those savings.
+
+Read [Storage Savings to Benefit Your Users](/guide/t7-storage-credits) for the contract design pattern and benchmark examples.
+
+### 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, and 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 |
+|---------------------|------------------:|-------:|----------------------:|
+| 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.
+
+### Tempo Token Rewards cleanup
+
+After T7 activation, new Tempo Token Rewards opt-ins and new reward distributions become no-ops. Already-accrued rewards remain claimable through the existing `claimRewards()` flow.
+
+This change is planned for testnet on June 30, 2026 and mainnet on July 6, 2026. See [Tempo Token Rewards](/protocol/tip20-rewards/overview) if your integration still uses rewards.
+
+## Technical references
+
+| Feature | What changes | Reference |
+|---------|--------------|-----------|
+| Reusable storage savings | Contracts can earn credits when they clear eligible storage and use those credits to lower later storage-creation gas | [Contract storage credits proposal (TIP-1060)](https://github.com/tempoxyz/tempo/pull/4016) |
+| User-attributed DEX savings | The DEX can keep reusable order-storage credits attached to the maker who earned them | [StablecoinDEX order storage credits proposal (TIP-1064)](https://github.com/tempoxyz/tempo/pull/4082) |
+| Dynamic base fee | The base fee can move within a bounded range instead of staying fixed | [Dynamic base fee proposal](https://github.com/tempoxyz/tempo/pull/5153) |
+| Tempo Token Rewards cleanup | New reward opt-ins and distributions stop, while already-accrued rewards remain claimable | [Rewards deprecation proposal](https://github.com/tempoxyz/tempo/pull/5380) |
+
+## Partner benefits
+
+| Partner type | What the planned features can help with |
+|--------------|-----------------------|
+| DEX makers and liquidity providers | Lower gas when a maker cancels or fully fills orders, then places eligible orders later |
+| Shared contract developers | A clear pattern for passing storage savings to the user who earned them |
+| Wallets, checkout teams, and consumer apps | Lower base fees during periods of low network usage |
+| Rewards integrators | Clear migration timing for stopping new Tempo Token Rewards activity |
+| Bridge, vault, and routing teams | Potential savings if their contracts repeatedly clear and recreate user-attributed state; benchmark each workflow before sharing partner-specific claims |
+
+## Benchmark highlights
+
+For DEX order flows, fresh order placement is effectively unchanged while same-maker credit reuse is about 1.21M gas cheaper in the merged benchmark.
+
+| DEX flow | Before | After | Gas change |
+|----------|-------:|------:|-------:|
+| Fresh place bid | 2,595,385 | 2,604,066 | +8,681 (+0.3%) |
+| Fresh place ask | 2,348,185 | 2,356,766 | +8,581 (+0.4%) |
+| Cancel bid, earn reusable savings | 304,741 | 361,184 | +56,443 (+18.5%) |
+| **Same maker reuses savings after cancel** | **2,075,413** | **868,756** | **1,206,657 gas saved (-58.1%)** |
+| Full fill, earn reusable savings | 384,497 | 436,040 | +51,543 (+13.4%) |
+| **Same maker reuses savings after full fill** | **1,828,213** | **621,456** | **1,206,757 gas saved (-66.0%)** |
 
-### Lower fees for things we know will expire
+The credit-earning steps cost more because the DEX records which maker earned the reusable savings. The payoff is the next eligible order from that same maker.
 
-T7 plans to introduce gas credits for protocol surfaces where temporary work is expected to expire.
+## Compatible SDK releases
 
-| TIP | Scope |
-|-----|-------|
-| [TIP-1060: Gas Credits Primitive](https://tips.sh/1060) | Core gas credits primitive |
-| [TIP-1064: Gas Credits for DEX](https://tips.sh/1064) | Gas credits for DEX flows |
-| [TIP-1066: Gas Credits for MPP](https://tips.sh/1066) | Gas credits for MPP flows; stretch goal |
+T7-compatible SDK releases will be listed here as they ship.
 
-### Lowering the base fee when gas is below certain threshold
+## What operators and integrators should know
 
-| TIP | Scope |
-|-----|-------|
-| [TIP-1067: Dynamic Base Fee](https://tips.sh/1067-1) | Dynamic base fee behavior |
+Node operators should upgrade to the T7-compatible release before the activation timestamp. Release details will be added when the compatible node release is available.
 
-### Remove TIP-20 Rewards
+Before T7 activation, integrators should:
 
-| TIP | Scope |
-|-----|-------|
-| [TIP-1075: Remove TIP-20 Rewards](https://github.com/tempoxyz/tempo/pull/5380) | Remove TIP-20 rewards |
+1. Identify flows that create and later clear storage.
+2. Decide whether cleared storage can be attributed to a specific user, maker, payer, or account.
+3. Add user-level accounting where shared contract savings should not be consumed by unrelated users.
+4. Benchmark first-time usage, repeat usage, and cross-user cases before publishing workflow-specific claims.
+5. Update frontend gas estimates, fee quotes, and support docs after T7-compatible releases are available.
+6. Stop building new flows on Tempo Token Rewards; already-accrued rewards remain claimable.
diff --git a/vocs.config.ts b/vocs.config.ts
index 15a128aa..f5a106d2 100644
--- a/vocs.config.ts
+++ b/vocs.config.ts
@@ -315,6 +315,10 @@ export default defineConfig({
                 text: 'Providing liquidity',
                 link: '/guide/stablecoin-dex/providing-liquidity',
               },
+              {
+                text: 'Storage savings to benefit your users',
+                link: '/guide/t7-storage-credits',
+              },
             ],
           },
           {