diff --git a/src/components/StorageSavingsSummary.tsx b/src/components/StorageSavingsSummary.tsx new file mode 100644 index 00000000..bc094aaa --- /dev/null +++ b/src/components/StorageSavingsSummary.tsx @@ -0,0 +1,101 @@ +'use client' + +import { Container } from './Container' + +const numberFormat = new Intl.NumberFormat('en-US') + +function formatGas(value: number) { + return `${numberFormat.format(value)} gas` +} + +function formatPercent(value: number) { + return `${value.toFixed(1)}%` +} + +function reduction(before: number, after: number) { + return ((before - after) / before) * 100 +} + +function barWidth(value: number, max: number) { + return `${Math.max((value / max) * 100, 3)}%` +} + +function BeforeAfterRow(props: { label: string; before: number; after: number }) { + const saved = props.before - props.after + + return ( +
+
+ {props.label} + + {formatGas(saved)} lower ({formatPercent(reduction(props.before, props.after))}) + +
+ +
+
+ Before + +
+ After + +
+
+ ) +} + +export function StorageSavingsSummary() { + return ( + + DEX savings at a glance + + } + footer={ + + This is the StablecoinDEX benchmark. Benchmark non-DEX contracts before making the same + claim. + + } + > +
+
+
+
Same-maker repeat orders
+

+ The saving shows up when the maker who earned it later places another eligible order. +

+
+ + +
+ +
+
+
Allocation rule
+

+ Savings should follow the user who cleared the storage. +

+
+
    +
  1. A maker cancels or fully fills an eligible order.
    2. +
  2. The DEX records reusable savings for that maker.
    3. +
  3. Only that same maker can use the saving on a later eligible order.
    4. +
+
+
+ + ) +} diff --git a/src/components/T7BenchmarkVisual.tsx b/src/components/T7BenchmarkVisual.tsx new file mode 100644 index 00000000..9398e37f --- /dev/null +++ b/src/components/T7BenchmarkVisual.tsx @@ -0,0 +1,127 @@ +'use client' + +import { Container } from './Container' + +const numberFormat = new Intl.NumberFormat('en-US') + +function formatGas(value: number) { + return `${numberFormat.format(value)} gas` +} + +function formatPercent(value: number) { + return `${value.toFixed(1)}%` +} + +function reduction(before: number, after: number) { + return ((before - after) / before) * 100 +} + +function barWidth(value: number, max: number) { + return `${Math.max((value / max) * 100, 3)}%` +} + +function BaseFeeRow(props: { + label: string + value: string + width: number + tone: 'before' | 'after' +}) { + return ( +
+
+ {props.label} + {props.value} +
+ + ) +} + +function BeforeAfterRow(props: { label: string; before: number; after: number; unit?: 'gas' }) { + const saved = props.before - props.after + + return ( +
+
+ {props.label} + + {formatGas(saved)} lower ({formatPercent(reduction(props.before, props.after))}) + +
+ +
+
+ Before + +
+ After + +
+
+ ) +} + +export function T7BenchmarkVisual() { + return ( + Fee impact at a glance + } + footer={ + + Bars are normalized within each comparison. Exact benchmark numbers are listed below. + + } + > +
+
+
+
Base fee
+

Example cost for a 50,000 gas transfer.

+
+ + + +
+ +
+
+
Payment channels
+

+ Repeated channel opens can reuse payer-scoped savings. +

+
+ + +
+ +
+
+
DEX repeat orders
+

+ Returning makers can reuse order-storage savings. +

+
+ + +
+
+ + ) +} diff --git a/src/pages/docs/guide/issuance/distribute-rewards.mdx b/src/pages/docs/guide/issuance/distribute-rewards.mdx index 50d0d22b..066858c3 100644 --- a/src/pages/docs/guide/issuance/distribute-rewards.mdx +++ b/src/pages/docs/guide/issuance/distribute-rewards.mdx @@ -17,6 +17,10 @@ import { Cards, Card } from 'vocs' # Distribute 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. +::: + 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/docs/guide/machine-payments/index.mdx b/src/pages/docs/guide/machine-payments/index.mdx index b4b53077..a68ee346 100644 --- a/src/pages/docs/guide/machine-payments/index.mdx +++ b/src/pages/docs/guide/machine-payments/index.mdx @@ -46,6 +46,7 @@ Tempo's transaction model is designed for agentic payments using MPP: - **~500ms finality** — Deterministic confirmation fast enough for synchronous request/response flows - **Sub-cent fees** — Low enough for micropayments and per-request billing +- **Lower repeated channel lifecycle costs** — T7 adds payer-scoped storage credits for MPP payment channels. In the [v1.10.1 release benchmark](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1), channel-reserve open calls are 72.1% lower for the open-existing path and 39.2% lower for the open-first path. - **Fee sponsorship** — Servers can cover gas on behalf of clients so they only need stablecoins - **2D and expiring nonces** — Parallel nonce lanes prevent payment transactions from blocking other account activity - **High throughput** — Supports the on-chain settlement volume that payment channels generate at scale diff --git a/src/pages/docs/guide/machine-payments/pay-as-you-go.mdx b/src/pages/docs/guide/machine-payments/pay-as-you-go.mdx index 9e34df19..cdb9a294 100644 --- a/src/pages/docs/guide/machine-payments/pay-as-you-go.mdx +++ b/src/pages/docs/guide/machine-payments/pay-as-you-go.mdx @@ -14,6 +14,19 @@ Build a payment-gated photo gallery API that charges $0.01 per photo using `mppx Unlike [one-time payments](/docs/guide/machine-payments/one-time-payments), sessions open a payment channel once and use off-chain vouchers for each subsequent request — vouchers are processed in pure CPU-bound signature checks, not bottlenecked by blockchain throughput. ::: +:::info[T7 payment-channel savings] +The [T7 network upgrade](/docs/protocol/upgrades/t7) adds payer-scoped storage credits for MPP payment channels. When a payer closes or withdraws a finished channel, the reserve can record a channel storage credit for that payer. If the same payer opens another channel later, that payer can reuse the credit. Other payers cannot spend it. +::: + +In the [v1.10.1 release benchmark](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1), channel-reserve open calls are lower after T7: + +| Channel reserve path | T6 | T7 | Gas change | +|----------------------|---:|---:|-----------:| +| Open existing | 1,055,229 | 294,425 | -760,804 (-72.1%) | +| Open first | 1,302,429 | 791,625 | -510,804 (-39.2%) | + +These are call-level gas numbers and exclude separate approval gas. They matter most for session services where the same payer opens, closes or withdraws, and later opens channels again. + ## How pay-as-you-go sessions work diff --git a/src/pages/docs/guide/t7-storage-credits.mdx b/src/pages/docs/guide/t7-storage-credits.mdx new file mode 100644 index 00000000..73c68e03 --- /dev/null +++ b/src/pages/docs/guide/t7-storage-credits.mdx @@ -0,0 +1,163 @@ +--- +title: Storage Credits for Repeated Workflows +description: Learn how storage credits lower repeat storage costs, how Refund mode works by default, and when to attribute savings to specific users. +--- + +import { StorageSavingsSummary } from '../../../components/StorageSavingsSummary' + +# Storage Credits for Repeated Workflows + +Storage credits make repeated storage workflows cheaper. Products can pass those savings to users through lower transaction costs, or explicitly attribute them to the users who earned them. They are useful for repeated business flows like DEX orders: placing an order creates storage, canceling or filling the order clears it, and the same maker may place another order later. + +T7 keeps fresh storage expensive enough to discourage state-growth spam, while letting contracts reuse value from storage they clear. By default, contracts benefit automatically. If your product needs the savings to follow a specific user, maker, payer, or account, you can add user-level accounting on top. + +:::info[Feature status] +Storage credits are part of the T7 network upgrade: testnet rollout is planned for July 2, 2026, and mainnet rollout is planned for July 9, 2026. See the [T7 network upgrade](/docs/protocol/upgrades/t7) for the full scope and release details. +::: + +## How storage credits work + +Each account has a protocol-maintained storage credit balance. A credit is not a token, cannot be transferred, and can only offset storage creation by the same account that earned it. + +The balance changes when that account's storage slots move between empty and non-empty: + +| Storage transition | What happens | +|---|---| +| Nonzero to zero | The account deletes storage and earns one storage credit | +| Zero to nonzero | The account creates storage; one available credit can offset the creditable portion of that creation, depending on the account's storage creation mode | + +A credit is tied to the storage-owning account, not to the transaction sender or the user whose action triggered the write. The same rule applies whether the account is a smart contract, precompile, or EOA, though contracts are the common case for application storage. + +One credit can offset most of the storage-creation cost for one new slot. For contract storage, the account is the contract address, so credits earned by a contract belong to the contract. + +## Default behavior: `Refund` mode + +Contracts do not need to call the storage credits precompile to benefit from storage credits. Every account starts each transaction in `Refund` mode. + +In `Refund` mode, storage creations pay upfront. At the end of the transaction, the protocol matches eligible creations with available credits for the same contract, consumes those credits, and applies the gas refund. + +| Action | `Refund` mode behavior | +|---|---| +| Contract deletes one of its own storage slots | The contract earns a protocol storage credit | +| Contract creates storage later | The creation pays upfront during execution | +| End-of-transaction settlement | Available credits can be consumed to refund matched creations | +| Contract has no user-level accounting | Credits are spent first-come, first-served by later storage creations | + +This default mode is usually enough when the contract simply wants lower net cost for repeated storage churn. It is not user-aware: whichever eligible storage creation happens next can consume an available credit, regardless of which user caused the earlier storage deletion. + +That first-come, first-served behavior is why explicit user-level attribution can be useful for products that want savings to follow a specific user. + +## Storage creation benchmark + +The [v1.10.1 release benchmark](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) shows why this primitive matters. In T6, the TIP-1000 storage creation component cost `250,000` gas. In T7, that component is split into a `5,000` gas residual cost plus a `245,000` gas creditable portion that one storage credit can offset. + +| Storage creation path | T6 | T7 | What it means | +|---|---:|---:|---| +| Credited `SSTORE 0 -> x` | 250,000 gas | 5,000 residual + up to 245,000 creditable gas | When a credit is applied, most of the storage-creation component can be offset. | + +Storage creation is not free, and a contract still has to earn credits first. But for workflows that repeatedly create, clear, and recreate temporary state, T7 lets the contract reuse much more of the value from cleared storage. + +## Why user-level accounting can be useful + +Protocol storage credits lower the contract's cost, but they do not answer the product question of which user should receive the benefit. + +For example: + +1. Alice places an order on a DEX. +2. Alice cancels the order, so the DEX deletes the order's physical storage. +3. The protocol credits the DEX contract because the DEX owned the storage. +4. Bob places a new order later. +5. With default first-come, first-served behavior, Bob's storage creation could use the credit that came from Alice's deleted order storage. + +That may be fine for some products. For the StablecoinDEX, the intended behavior is different: if Alice's order lifecycle created the reusable storage benefit, Alice should be able to use that benefit when she places a later order. + +Use user-level accounting when all of these are true: + +1. Deleted storage is clearly attributable to one user, maker, payer, or account. +2. That same user is expected to create similar storage again later. +3. You want the savings to follow that user instead of going to whichever eligible action happens next. +4. The contract can distinguish user-attributed storage from internal accounting storage. + +### StablecoinDEX pattern + +[TIP-1064](https://tips.sh/1064) adds user-level reusable storage accounting for StablecoinDEX order storage. + +The DEX keeps a dedicated state variable, `dex_storage_credits`, to track reusable order-storage credits per user. This is not the same as the TIP-1060 protocol credit balance. The protocol balance belongs to the DEX contract; `dex_storage_credits` is the DEX's user-facing record of which maker should receive the benefit. + +To enforce that attribution, DEX transactions preserve protocol credits by default and only spend them deliberately for attributed writes: + +- By default, DEX storage creations use `Preserve` mode. `Preserve` mode pays the normal storage-creation cost and leaves the DEX's protocol credit balance untouched, so a maker cannot accidentally consume credits attributed to someone else. +- When an eligible maker has DEX storage credits, the DEX switches to `Direct` mode for that maker's storage creation. `Direct` mode consumes an available DEX protocol credit during the write, so the maker's eligible order creation receives the benefit immediately. + +| Event | StablecoinDEX behavior | +|---|---| +| An operation deletes reusable order storage | TIP-1060 credits the DEX contract | +| The deleted storage belongs to maker `U` | The DEX increments `dex_storage_credits[U]` | +| Maker `U` later creates eligible order storage and has DEX storage credits | The DEX decrements `dex_storage_credits[U]` and switches to `Direct` mode so one DEX protocol credit can offset the creation | +| A different maker creates order storage, or maker `U` has no DEX storage credits | The DEX stays in `Preserve` mode so the write does not consume a credit attributed to someone else | + +The key idea is simple: TIP-1060 gives the DEX the raw storage credit, while TIP-1064 lets the DEX decide which maker can spend that benefit. + +### DEX savings example + +The DEX benchmark shows why user-level accounting can matter. Fresh order placement stays effectively unchanged, while repeat orders from a maker who already earned DEX storage credits become much cheaper. + + + +| Repeat order path | Before | After | Gas saved | +|---|---:|---:|---:| +| Same maker after cancel | 2,075,413 | 868,756 | 1,206,657 (-58.1%) | +| Same maker after filled order | 1,828,213 | 621,456 | 1,206,757 (-66.0%) | + +The cancellation or fill step does a little extra accounting to remember which maker earned the reusable order-storage benefit. The payoff appears when that same maker places a later eligible order. + +### Prevent cross-user leakage + +User-level accounting prevents one user's storage benefit from being spent by another user. + +| Case | Expected behavior | +|---|---| +| Same maker returns after earning DEX storage credits | Apply that maker's stored credits to eligible order storage | +| Different maker places the next order | Do not spend the first maker's credits | +| Internal accounting storage is cleared | Do not assign the credit to whichever user happened to trigger cleanup | + +The DEX benchmark includes cross-user isolation tests to prove this behavior, but the product rule is simpler: savings earned by Alice should stay available to Alice, and Bob should pay the normal cost unless Bob earned savings too. + +## Partner checklist + +When deciding whether default storage credits are enough or whether you should add user-level accounting, check: + +1. Does the contract create storage during the user flow? +2. Does the contract later clear that storage? +3. Is the deleted storage owned by the contract and eligible for protocol storage credits? +4. Is the storage lifecycle clearly attributable to a specific user, payer, maker, or account? +5. Is first-come, first-served credit usage acceptable? +6. If not, should the same user receive the later benefit? +7. Does the same user later create eligible storage again? +8. Can the contract track user-level credits without mixing them with unrelated users? +9. Are there internal accounting slots that should not be credited to any one user? +10. Do gas estimates differ between first-time usage and repeated usage? +11. Do benchmarks include cross-user cases to make sure credits do not leak? +12. Are the numbers from this DEX example or a workflow-specific test, rather than an early 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. +- Protocol storage credits automatically map to the right end user. +- Default first-come, first-served usage is always the right product behavior. +- Internal accounting storage should be credited to whichever user happened to trigger cleanup. +- DEX benchmark numbers apply to bridge, vault, routing, or other contracts without testing those workflows separately. + +## Related pages + +- [T7 network upgrade](/docs/protocol/upgrades/t7) +- [Providing Liquidity](/docs/protocol/exchange/providing-liquidity) +- [Stablecoin DEX Specification](/docs/protocol/exchange/spec) +- [Contract storage credits proposal (TIP-1060)](https://tips.sh/1060) +- [StablecoinDEX order storage credits proposal (TIP-1064)](https://tips.sh/1064) +- [v1.10.1 release notes](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) diff --git a/src/pages/docs/protocol/exchange/providing-liquidity.mdx b/src/pages/docs/protocol/exchange/providing-liquidity.mdx index e760d6c2..cb190bfe 100644 --- a/src/pages/docs/protocol/exchange/providing-liquidity.mdx +++ b/src/pages/docs/protocol/exchange/providing-liquidity.mdx @@ -17,6 +17,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] +Storage credits can reduce gas for active DEX makers who repeatedly place, cancel, or fully fill eligible orders. See [Storage Credits for Repeated Workflows](/docs/guide/t7-storage-credits) for the allocation pattern and benchmark examples. +::: + ## Order Types ### Limit Orders diff --git a/src/pages/docs/protocol/fees/index.mdx b/src/pages/docs/protocol/fees/index.mdx index b55e48d4..4d7a1138 100644 --- a/src/pages/docs/protocol/fees/index.mdx +++ b/src/pages/docs/protocol/fees/index.mdx @@ -11,7 +11,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 dynamic base fee 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). +::: ## Learn more about Tempo fees diff --git a/src/pages/docs/protocol/tip20-rewards/overview.mdx b/src/pages/docs/protocol/tip20-rewards/overview.mdx index 582408ca..de8c8297 100644 --- a/src/pages/docs/protocol/tip20-rewards/overview.mdx +++ b/src/pages/docs/protocol/tip20-rewards/overview.mdx @@ -7,6 +7,10 @@ import { Cards, Card } from 'vocs' # Tempo Token Rewards +:::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 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. +::: + 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). 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/docs/protocol/tip20-rewards/spec.mdx b/src/pages/docs/protocol/tip20-rewards/spec.mdx index 3a9f15ea..b58a7906 100644 --- a/src/pages/docs/protocol/tip20-rewards/spec.mdx +++ b/src/pages/docs/protocol/tip20-rewards/spec.mdx @@ -5,6 +5,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 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. +::: + ## 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/docs/protocol/upgrades/t7.mdx b/src/pages/docs/protocol/upgrades/t7.mdx index 638b56d6..1724f339 100644 --- a/src/pages/docs/protocol/upgrades/t7.mdx +++ b/src/pages/docs/protocol/upgrades/t7.mdx @@ -1,11 +1,15 @@ --- title: T7 Network Upgrade -description: Partner-focused overview and rollout dates for the T7 network upgrade, including storage credits, dynamic base fee behavior, and TIP-20 rewards deprecation. +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. --- +import { T7BenchmarkVisual } from '../../../../components/T7BenchmarkVisual' + # T7 Network Upgrade -T7 gives partners a clearer fee model for high-volume payment and exchange flows. It adds storage credits for reusable DEX order and TIP-20 channel state, makes the base fee move down when network usage is below the target threshold, and deprecates new TIP-20 rewards. +T7 makes repeated onchain workflows cheaper and gives partners a clearer fee story for payment and exchange flows. It adds storage savings for DEX order state and TIP-20 payment-channel state, lets the base fee move down when network usage is low, and deprecates new TIP-20 rewards activity. + +For partners, the headline is simple: 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] 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. @@ -22,41 +26,124 @@ Node operators should upgrade to [v1.10.1](https://github.com/tempoxyz/tempo/rel ## Overview -T7 focuses on three partner needs: +T7 focuses on five 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. +- **Payment-channel savings.** MPP payment channels can keep storage credits attached to the payer who earned them, so repeated session lifecycles can reuse channel-state savings. +- **Lower fees during quiet periods.** The base fee can fall when block gas usage is below the target threshold. +- **Rewards cleanup.** New Tempo Token Rewards opt-ins and distributions stop after activation, while already-accrued rewards remain claimable. + +These changes make costs easier to reason about for partners building high-throughput payment, liquidity, and exchange experiences. 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. -- **Lower fees for reusable protocol state.** Storage credits reduce fees when previously freed protocol storage can be reused, including DEX order storage and TIP-20 channel storage. -- **A more responsive base fee.** Dynamic base fee behavior lowers the base fee when gas usage is below the target threshold. -- **A simpler TIP-20 rewards model.** Deprecating new TIP-20 rewards simplifies reward-related accounting and user-facing balances. +## Why it matters -These changes are designed to make costs easier to reason about for partners building high-throughput payment, liquidity, and exchange experiences. Storage credits and dynamic base fee behavior affect fee calculations, while existing TIP-20 transfer behavior and claims for already-accrued rewards continue to work. +| Partner impact | What changes | +|----------------|--------------| +| Active DEX makers can pay much less on repeat order placement | In the T7 DEX benchmark, same-maker reuse is about 1.21M gas cheaper after an order is canceled or filled. | +| 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. | +| MPP sessions can get cheaper over repeated channel lifecycles | In the release benchmark, channel-reserve open calls are 72.1% lower for the open-existing path and 39.2% lower for the open-first path. | +| 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 -### Storage credits for reusable protocol state +### Reusable storage savings + +Storage credits lower fees 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 storage-credit idea but adds maker-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. -Storage credits lower fees for protocol surfaces where deleted storage can later be reused. This helps reduce the cost of flows where the network can account for reusable state separately from net-new long-lived state. +Read [Storage Credits for Repeated Workflows](/docs/guide/t7-storage-credits) for the allocation pattern, storage credit modes, and DEX benchmark. -| TIP | Scope | -|-----|-------| -| [TIP-1060: Storage Credits](https://tips.sh/1060) | Core storage credits primitive | -| [TIP-1064: StablecoinDEX Order Storage Credits](https://tips.sh/1064) | Storage credits for DEX order storage | -| [TIP-1066: TIP-20 Channel Storage Credits](https://tips.sh/1066) | Storage credits for TIP-20 channel state | +### Payer-scoped payment-channel savings + +T7 applies the storage-credit pattern to MPP payment channels through the `TIP20ChannelReserve` precompile. When a payer closes or withdraws a finished channel, the reserve can record a channel storage credit for that payer. When the same payer opens a later channel, the reserve can use that payer's credit. + +This keeps channel savings attached to the payer who earned them. A different payer cannot spend another payer's channel credit. + +For MPP partners, the benefit is focused on repeated session lifecycles. Per-request vouchers already stay off-chain; T7 can lower the net onchain lifecycle cost when a close or withdraw is followed by a later open from the same payer. + +The release benchmark reports the channel-reserve open paths below. These are call-level gas numbers and exclude separate approval gas. + +| Channel reserve path | T6 | T7 | Gas change | +|----------------------|---:|---:|-----------:| +| Open existing | 1,055,229 | 294,425 | -760,804 (-72.1%) | +| Open first | 1,302,429 | 791,625 | -510,804 (-39.2%) | + +Read [Accept pay-as-you-go payments](/docs/guide/machine-payments/pay-as-you-go) for the MPP session flow. ### Dynamic base fee -Dynamic base fee behavior lets the base fee move down when gas usage is below the target threshold. This gives wallets, apps, and infrastructure a fee model that can respond to lower network usage instead of assuming a fixed 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. + +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 | -| TIP | Scope | -|-----|-------| -| [TIP-1067: Dynamic Base Fee](https://tips.sh/1067-1) | Dynamic base fee behavior | +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. ### Deprecate TIP-20 rewards -T7 deprecates new TIP-20 reward opt-ins and reward distributions so partners do not need to model new reward accrual after the upgrade. Already-accrued rewards remain claimable, so historical rewards data should remain separate from post-T7 payment and balance reporting. +T7 deprecates new Tempo Token Rewards opt-ins and reward distributions so partners do not need to model new reward accrual after the upgrade. Already-accrued rewards remain claimable through the existing `claimRewards()` flow. -| TIP | Scope | -|-----|-------| -| [TIP-1075: Deprecate TIP-20 Rewards](https://github.com/tempoxyz/tempo/pull/5380) | Deprecate new TIP-20 rewards and preserve claims for already-accrued rewards | +Apps that show reward information should keep already-accrued rewards separate from post-T7 balances, and should stop presenting new rewards as accruing from post-T7 reward distributions. See [Tempo Token Rewards](/docs/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 | [TIP-1060: Storage Credits](https://tips.sh/1060) | +| User-attributed DEX savings | The DEX can keep reusable order-storage credits attached to the maker who earned them | [TIP-1064: StablecoinDEX Order Storage Credits](https://tips.sh/1064) | +| Payer-scoped payment-channel savings | MPP channel credits stay attached to the payer who earned them and can be reused by that payer on a later channel open | [TIP-1066: TIP-20 Channel Storage Credits](https://tips.sh/1066) | +| Dynamic base fee | The base fee can move within a bounded range instead of staying fixed | [TIP-1067: Dynamic Base Fee](https://tips.sh/1067-1) | +| Tempo Token Rewards cleanup | New reward opt-ins and distributions stop, while already-accrued rewards remain claimable | [TIP-1075: Deprecate TIP-20 Rewards](https://github.com/tempoxyz/tempo/pull/5380) | + +## Partner benefits + +| Partner type | What T7 can help with | +|--------------|-----------------------| +| DEX makers and liquidity providers | Lower gas when a maker cancels or fully fills orders, then places eligible orders later | +| MPP and pay-as-you-go providers | Lower onchain channel lifecycle costs when the same payer closes or withdraws a channel, then opens another channel 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 | + +## Benchmark highlights + +The [v1.10.1 release notes](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) include the headline gas benchmarks below. Treat these as protocol-level benchmarks: they show where T7 lowers base fees and storage-related costs, while partner-specific flows should still be tested end to end. + + + +| Area | T6 / before | T7 / after | What changes | +|------|-------------|------------|--------------| +| Base-fee ceiling for a 50,000 gas transfer | $0.001 | Cap $0.0006; quiet-period floor $0.00003 | The cap is 40% lower, and the floor is 20x below the cap. | +| Credited storage creation (`SSTORE 0 -> x`) | 250,000 gas | 5,000 residual + up to 245,000 creditable gas | When credits are available, most of the storage-creation cost can be offset. | +| Channel reserve open-existing path | 1,055,229 gas | 294,425 gas | 760,804 gas lower (-72.1%). | +| Channel reserve open-first path | 1,302,429 gas | 791,625 gas | 510,804 gas lower (-39.2%). | +| Observed transfer-like costs before T7 | Average $0.0037857 and median $0.0011855 across 1,000 transactions; median $0.0007657 across 598 steady-state transfers | T7 lowers the per-gas component through the new cap and floor | Useful baseline context, not a post-T7 production average. | + +### DEX order reuse + +For DEX order flows, fresh order placement is effectively unchanged while same-maker credit reuse is about 1.21M gas cheaper in the T7 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%)** | +| Order filled, earn reusable savings | 384,497 | 436,040 | +51,543 (+13.4%) | +| **Same maker reuses savings after filled order** | **1,828,213** | **621,456** | **1,206,757 gas saved (-66.0%)** | + +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. ## Compatible releases @@ -72,13 +159,22 @@ Release notes and binaries are available in the [v1.10.1 release](https://github T7 changes fee and reward behavior. Node operators, integrators, indexers, wallets, and partner infrastructure should review the notes below before testnet and mainnet rollout. -### For storage credits +### For storage savings -Partners using DEX or TIP-20 channel flows should review fee assumptions once the T7-compatible release is available. +Partners using DEX or TIP-20 channel flows should review fee assumptions on a T7-compatible testnet. - Storage credits are included for the core primitive, DEX order storage, and TIP-20 channel storage. - Wallets and apps that estimate fees should validate their fee displays against T7 behavior on testnet. - Indexers and analytics systems should keep pre-T7 fee assumptions separate from post-T7 fee data. +- Shared contracts should avoid global credit pools when savings should stay attached to a specific user, maker, payer, or account. + +### For dynamic fees + +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. +- Fee analytics should compare pre-T7 fixed-fee periods separately from post-T7 dynamic-fee periods. ### For TIP-20 rewards deprecation diff --git a/vocs.config.ts b/vocs.config.ts index 576f2672..c9aa5df4 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -387,6 +387,10 @@ export default defineConfig({ text: 'Withdraw from a zone', link: '/docs/guide/private-zones/withdraw-from-a-zone', }, + { + text: 'Storage savings to benefit your users', + link: '/docs/guide/t7-storage-credits', + }, ], }, {