From 2f3ac7d040889331a215c7e2ebd23befbdcc1d72 Mon Sep 17 00:00:00 2001 From: Max Date: Wed, 8 Jul 2026 10:48:05 +0100 Subject: [PATCH 01/22] Add T7 compatible Rust releases --- src/pages/docs/protocol/upgrades/t7.mdx | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/pages/docs/protocol/upgrades/t7.mdx b/src/pages/docs/protocol/upgrades/t7.mdx index 4fd67c5c..084cd205 100644 --- a/src/pages/docs/protocol/upgrades/t7.mdx +++ b/src/pages/docs/protocol/upgrades/t7.mdx @@ -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). @@ -151,4 +152,4 @@ Wallets, checkout flows, and infrastructure that display fees should expect the 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 From 3291fb5054350470b24b4ac01d70c91ffc53d7ae Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 15:20:22 +0100 Subject: [PATCH 02/22] Update docs for T7 mainnet activation --- src/pages/docs/build.mdx | 2 +- .../guide/issuance/distribute-rewards.mdx | 40 +++++++++---------- src/pages/docs/guide/issuance/index.mdx | 6 +-- .../docs/guide/node/network-upgrades.mdx | 6 +-- .../stablecoin-dex/providing-liquidity.mdx | 4 +- src/pages/docs/index.mdx | 2 +- src/pages/docs/protocol/fees/index.mdx | 4 +- src/pages/docs/protocol/fees/spec-fee.mdx | 11 ++--- .../docs/protocol/tip20-rewards/overview.mdx | 26 ++++++------ .../docs/protocol/tip20-rewards/spec.mdx | 12 +++--- src/pages/docs/protocol/tip20/overview.mdx | 8 ++-- src/pages/docs/protocol/tip20/spec.mdx | 12 +++--- src/pages/docs/protocol/upgrades/t7.mdx | 18 ++++----- 13 files changed, 76 insertions(+), 75 deletions(-) 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 084cd205..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 @@ -144,8 +144,8 @@ 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 From 8dbcb950ee992187b595ea09f76be01158b67ec7 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 15:28:00 +0100 Subject: [PATCH 03/22] Mark T7 as latest in docs nav --- src/pages/_root.css | 4 ---- vocs.config.ts | 3 +-- 2 files changed, 1 insertion(+), 6 deletions(-) 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/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', }, { From a13569eecbf5c6a2e2346e061619906873a3c5bf Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 15:49:09 +0100 Subject: [PATCH 04/22] Clarify pay-as-you-go guide intro --- src/pages/docs/guide/machine-payments/pay-as-you-go.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) 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 39de7284..d310d2d4 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 @@ -8,10 +8,12 @@ import { MermaidDiagram } from '../../../../components/MermaidDiagram' # Accept pay-as-you-go payments -Build a payment-gated photo gallery API that charges $0.01 per photo using `mppx` sessions. The server returns random photos from [Picsum](https://picsum.photos) behind a paywall. +Use pay-as-you-go sessions when a customer should pay a small amount each time they use an API or service, without sending an on-chain transaction for every request. + +This guide uses a simple photo API as the example: the client opens one `mppx` session, then pays $0.01 each time it asks for a photo. `mppx` is the library that manages the MPP session; [Picsum](https://picsum.photos) only supplies sample images for the demo. :::info -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. +Unlike [one-time payments](/docs/guide/machine-payments/one-time-payments), a session opens a payment channel once. Each later request is paid with a signed voucher that the server verifies off-chain. ::: :::info[T7 payment-channel savings] From 0a043fab18ae0e0feca0e39c758062da32ac94c2 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 15:55:19 +0100 Subject: [PATCH 05/22] Move T7 MPP savings under session flow --- .../guide/machine-payments/pay-as-you-go.mdx | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) 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 d310d2d4..b0550db0 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 @@ -16,18 +16,6 @@ This guide uses a simple photo API as the example: the client opens one `mppx` s Unlike [one-time payments](/docs/guide/machine-payments/one-time-payments), a session opens a payment channel once. Each later request is paid with a signed voucher that the server verifies off-chain. ::: -:::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 records a channel storage credit for that payer. If the same payer opens another channel later, that payer reuses the credit. Other payers cannot spend it. -::: - -The channel-reserve gas snapshot for the credited reopen path is: - -| Channel reserve snapshot | T7 gas | -|--------------------------|-------:| -| `open_new_channel_with_storage_credit` | 60,225 | - -This is a call-level gas number and excludes separate approval gas. It matters most for session services where the same payer opens, closes or withdraws, and later opens channels again. - ## How pay-as-you-go sessions work Date: Thu, 9 Jul 2026 22:27:11 +0100 Subject: [PATCH 06/22] Remove legacy rewards entry point --- src/pages/docs/guide/issuance/index.mdx | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/pages/docs/guide/issuance/index.mdx b/src/pages/docs/guide/issuance/index.mdx index 862ca5b0..81fdd681 100644 --- a/src/pages/docs/guide/issuance/index.mdx +++ b/src/pages/docs/guide/issuance/index.mdx @@ -37,13 +37,6 @@ Create and manage your own stablecoin on Tempo. Launch the token first, then con ## Operate a Stablecoin - - Date: Thu, 9 Jul 2026 22:31:22 +0100 Subject: [PATCH 07/22] Remove deprecated rewards guide page --- .../guide/issuance/distribute-rewards.mdx | 280 ------------------ 1 file changed, 280 deletions(-) delete mode 100644 src/pages/docs/guide/issuance/distribute-rewards.mdx diff --git a/src/pages/docs/guide/issuance/distribute-rewards.mdx b/src/pages/docs/guide/issuance/distribute-rewards.mdx deleted file mode 100644 index f0a77675..00000000 --- a/src/pages/docs/guide/issuance/distribute-rewards.mdx +++ /dev/null @@ -1,280 +0,0 @@ ---- -title: Legacy Token Rewards -description: Understand deprecated Tempo Token Rewards behavior and claim already-accrued rewards after T7. -interactive: true ---- - -import * as Demo from '../../../../components/guides/Demo.tsx' -import { AddFunds } from '../../../../components/guides/steps/payments/AddFunds.tsx' -import { ClaimReward } from '../../../../components/guides/steps/rewards/ClaimReward.tsx' -import { Connect } from '../../../../components/guides/steps/auth/Connect.tsx' -import { CreateOrLoadToken } from '../../../../components/guides/steps/issuance/CreateOrLoadToken.tsx' -import { GrantTokenRoles } from '../../../../components/guides/steps/issuance/GrantTokenRoles.tsx' -import { MintToken } from '../../../../components/guides/steps/issuance/MintToken.tsx' -import { OptInToRewards } from '../../../../components/guides/steps/rewards/OptInToRewards.tsx' -import { StartReward } from '../../../../components/guides/steps/rewards/StartReward.tsx' -import { Cards, Card } from 'vocs' - -# Legacy Token Rewards - -:::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. -::: - -Tempo Token Rewards is deprecated. This page is retained for legacy integrations and for claiming already-accrued rewards. - -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. - -## Legacy rewards demo - -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. - - - - - - - - - - - - -## Rewards distribution steps - -::::steps - -### [Optional] Create a reward 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. - -### Legacy: tell users to opt in to rewards - -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 - -```tsx twoslash [OptInToRewards.tsx] -import React from 'react' -import { Hooks } from 'wagmi/tempo' -import { useConnection } from 'wagmi' - -// @noErrors -export function OptInToRewards() { - const { address } = useConnection() - const tokenAddress = '0x...' // Your token address - - const setRecipient = Hooks.reward.useSetRecipientSync() - - const handleOptIn = () => { // [!code hl] - if (!address) return // [!code hl] - setRecipient.mutate({ // [!code hl] - recipient: address, // [!code hl] - token: tokenAddress, // [!code hl] - }) // [!code hl] - } // [!code hl] - - return ( - - ) -} -``` - -```tsx twoslash [config.ts] filename="config.ts" -// @noErrors -import { createConfig, http } from 'wagmi' -import { tempo } from 'viem/chains' -import { tempoWallet } from 'wagmi/connectors' - -export const config = createConfig({ - chains: [tempo], - connectors: [tempoWallet()], - transports: { - [tempo.id]: http(), - }, -}) -``` - -::: - -### Legacy: make a stablecoin reward distribution - -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 - -```tsx twoslash [StartReward.tsx] -import React from 'react' -import { Hooks } from 'wagmi/tempo' -import { parseUnits } from 'viem' - -// @noErrors -export function StartReward() { - const tokenAddress = '0x...' // Your token address - - const { data: metadata } = Hooks.token.useGetMetadata({ - token: tokenAddress, - }) - - const start = Hooks.reward.useStartSync() - - const handleStart = () => { // [!code hl] - if (!metadata) return // [!code hl] - start.mutate({ // [!code hl] - amount: parseUnits('50', metadata.decimals), // [!code hl] - token: tokenAddress, // [!code hl] - }) // [!code hl] - } // [!code hl] - - return ( - - ) -} -``` - -```tsx twoslash [config.ts] filename="config.ts" -// @noErrors -import { createConfig, http } from 'wagmi' -import { tempo } from 'viem/chains' -import { tempoWallet } from 'wagmi/connectors' - -export const config = createConfig({ - chains: [tempo], - connectors: [tempoWallet()], - transports: { - [tempo.id]: http(), - }, -}) -``` - -::: - -### Let users claim stablecoin rewards - -Once a reward is distributed, opted-in holders can claim their share. - -:::code-group - -```tsx twoslash [ClaimReward.tsx] -import React from 'react' -import { Hooks } from 'wagmi/tempo' - -// @noErrors -export function ClaimReward() { - const tokenAddress = '0x...' // Your token address - - const claim = Hooks.reward.useClaimSync() - - const handleClaim = () => { // [!code hl] - claim.mutate({ // [!code hl] - token: tokenAddress, // [!code hl] - }) // [!code hl] - } // [!code hl] - - return ( - - ) -} -``` - -```tsx twoslash [config.ts] filename="config.ts" -// @noErrors -import { createConfig, http } from 'wagmi' -import { tempo } from 'viem/chains' -import { tempoWallet } from 'wagmi/connectors' - -export const config = createConfig({ - chains: [tempo], - connectors: [tempoWallet()], - transports: { - [tempo.id]: http(), - }, -}) -``` - -::: - -:::: - -## Rewards distribution recipes - -### Legacy: watch for reward distribution events - -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' - -// @noErrors -function WatchRewards() { - const tokenAddress = '0x...' // Your token address - - Hooks.reward.useWatchRewardDistributed({ // [!code hl] - token: tokenAddress, // [!code hl] - onRewardDistributed(args) { // [!code hl] - console.log('New reward scheduled:', args) // [!code hl] - // Update UI, refetch balances, show notification, etc. // [!code hl] - }, // [!code hl] - }) // [!code hl] - - return
Watching for reward distributions...
-} -``` - -### Watch for reward opt-ins - -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' - -// @noErrors -function WatchOptIns() { - const tokenAddress = '0x...' // Your token address - - Hooks.reward.useWatchRewardRecipientSet({ // [!code hl] - token: tokenAddress, // [!code hl] - onRewardRecipientSet(args) { // [!code hl] - console.log('User opted in:', args) // [!code hl] - // Update UI, track analytics, etc. // [!code hl] - }, // [!code hl] - }) // [!code hl] - - return
Watching for reward opt-ins...
-} -``` - -## Rewards distribution learning resources - - - - - From 97800423ef1bb98f355b67af27a0b404db9841ff Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:32:03 +0100 Subject: [PATCH 08/22] Remove deprecated rewards protocol overview --- .../docs/protocol/tip20-rewards/overview.mdx | 40 ------------------- 1 file changed, 40 deletions(-) delete mode 100644 src/pages/docs/protocol/tip20-rewards/overview.mdx diff --git a/src/pages/docs/protocol/tip20-rewards/overview.mdx b/src/pages/docs/protocol/tip20-rewards/overview.mdx deleted file mode 100644 index 9971db82..00000000 --- a/src/pages/docs/protocol/tip20-rewards/overview.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Tempo Token Rewards -description: Legacy TIP-20 reward distribution behavior and the claim path for already-accrued rewards after T7. ---- - -import { Cards, Card } from 'vocs' - -# Tempo Token Rewards - -:::warning[Tempo Token Rewards deprecation] -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 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). - -Before T7, Tempo Token Rewards solved this without requiring tokens to be staked in separate contracts: - -- **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**: Reward transfers respected TIP-403 transfer policies - -## Links - - - - - From 52417343c12edb11593e2ca75c7bbfe99d8f3416 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:32:11 +0100 Subject: [PATCH 09/22] Remove deprecated rewards protocol spec --- .../docs/protocol/tip20-rewards/spec.mdx | 76 ------------------- 1 file changed, 76 deletions(-) delete mode 100644 src/pages/docs/protocol/tip20-rewards/spec.mdx diff --git a/src/pages/docs/protocol/tip20-rewards/spec.mdx b/src/pages/docs/protocol/tip20-rewards/spec.mdx deleted file mode 100644 index af807ce2..00000000 --- a/src/pages/docs/protocol/tip20-rewards/spec.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Tempo Token Rewards Specification -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 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 -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 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 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: - -```solidity -/// @notice Distribute rewards to opted-in token holders -/// @param amount Amount of tokens to distribute -function distributeReward(uint256 amount) external; - -/// @notice Set the reward recipient for the caller (opt in/out of rewards) -/// @param newRewardRecipient Recipient address (address(0) to opt out) -function setRewardRecipient(address newRewardRecipient) external; - -/// @notice Claim all pending rewards for the caller -/// @return maxAmount Amount claimed -function claimRewards() external returns (uint256 maxAmount); - -/// @notice Get user reward info -function userRewardInfo(address user) external view returns ( - address rewardRecipient, - uint256 rewardPerToken, - uint256 rewardBalance -); - -// State variables -function globalRewardPerToken() external view returns (uint256); -function optedInSupply() external view returns (uint128); -``` - -## Accrual Mechanism -The system uses an accumulator pattern: -- `globalRewardPerToken`: Cumulative rewards per token (scaled by 1e18) -- Each user stores a `rewardPerToken` snapshot; pending rewards = `(globalRewardPerToken - snapshot) * balance` - -Instant distributions (`seconds_ == 0`) add directly to `globalRewardPerToken` as: -`deltaRPT = amount * 1e18 / optedInSupply`. - -## Opt-In Model -Users must call `setRewardRecipient(recipient)` to opt in. When opted in: -- User's balance contributes to `optedInSupply` -- Rewards accrue to `rewardBalance` on balance-changing operations -- Users can delegate rewards to another address - -Setting recipient to `address(0)` opts out. - -`setRewardRecipient(...)` rejects [TIP-1022](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1022.md) virtual addresses: reward recipients must remain canonical accounts rather than forwarding aliases, because reward assignment is not a TIP-20 forwarding path. - -## TIP-403 Integration -All token movements must pass TIP-403 policy checks: -- `distributeReward`: Validates funder authorization -- `setRewardRecipient`: Validates holder and recipient -- `claimRewards`: Validates msg.sender - -## Invariants -- `globalRewardPerToken` must monotonically increase -- `optedInSupply` must equal the sum of balances for all opted-in users -- All token movements must comply with TIP-403 policies From 5aceffc3f46b483d6828a2df58c8b3b1e2e4161f Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:33:42 +0100 Subject: [PATCH 10/22] Fold DEX storage savings into liquidity guide --- src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx b/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx index 19ec0101..78751c23 100644 --- a/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx +++ b/src/pages/docs/guide/stablecoin-dex/providing-liquidity.mdx @@ -17,11 +17,7 @@ import { QueryOrder } from '../../../../components/guides/steps/exchange/QueryOr Add liquidity for a token pair by placing orders on the Stablecoin DEX. You can provide liquidity on the `buy` or `sell` side of the orderbook, with `limit` or `flip` orders. To learn more about order types see the [documentation on order types](/docs/protocol/exchange/providing-liquidity#order-types). -In this guide you will learn how to place buy and sell orders to provide liquidity on the Stablecoin DEX orderbook. - -:::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. -::: +In this guide you will learn how to place buy and sell orders to provide liquidity on the Stablecoin DEX orderbook. 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 From 20444e66194a416df1f0bbc153a2c337ede7c49e Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:34:38 +0100 Subject: [PATCH 11/22] Remove rewards references from TIP-20 overview --- src/pages/docs/protocol/tip20/overview.mdx | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/src/pages/docs/protocol/tip20/overview.mdx b/src/pages/docs/protocol/tip20/overview.mdx index abdc3c8a..84df5dd8 100644 --- a/src/pages/docs/protocol/tip20/overview.mdx +++ b/src/pages/docs/protocol/tip20/overview.mdx @@ -42,12 +42,6 @@ Below are some of the key benefits and features of TIP-20 tokens: icon="lucide:message-square" title="Transfer Memos" /> - ### Exchange @@ -131,10 +125,6 @@ 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. -### Legacy Reward Distribution - -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 A TIP-20 token can declare a currency identifier that identifies the reference asset whose price the token is designed to track. This enables proper routing and pricing in Tempo's [Stablecoin DEX](/docs/protocol/exchange). Currently, **only `USD`-denominated stablecoins** can be used to pay transaction fees on Tempo or traded on the StablecoinDEX. From cbd91f160d69683740896094131299ebfdd6d086 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:38:32 +0100 Subject: [PATCH 12/22] Remove unused rewards demo components --- .../guides/steps/rewards/ClaimReward.tsx | 110 ------------------ 1 file changed, 110 deletions(-) delete mode 100644 src/components/guides/steps/rewards/ClaimReward.tsx diff --git a/src/components/guides/steps/rewards/ClaimReward.tsx b/src/components/guides/steps/rewards/ClaimReward.tsx deleted file mode 100644 index 02fccba6..00000000 --- a/src/components/guides/steps/rewards/ClaimReward.tsx +++ /dev/null @@ -1,110 +0,0 @@ -'use client' -import { useQueryClient } from '@tanstack/react-query' -import * as React from 'react' -import { useConnection, useConnectionEffect, useWaitForTransactionReceipt } from 'wagmi' -import { Hooks } from 'wagmi/tempo' -import { useDemoContext } from '../../../DemoContext' -import { Button, ExplorerLink, Step } from '../../Demo' -import { alphaUsd } from '../../tokens' -import type { DemoStepProps } from '../types' -import { REWARD_AMOUNT } from './Constants' - -export function ClaimReward(props: DemoStepProps) { - const { stepNumber, last = false, flowDependencies = [] } = props - const { address } = useConnection() - const { getData, checkFlowDependencies } = useDemoContext() - const queryClient = useQueryClient() - const tokenAddress = getData('tokenAddress') - - const [expanded, setExpanded] = React.useState(true) - - const { data: balance } = Hooks.token.useGetBalance({ - account: address, - token: tokenAddress, - }) - - const { data: metadata } = Hooks.token.useGetMetadata({ - token: tokenAddress, - }) - - const claim = Hooks.reward.useClaim() - const receipt = useWaitForTransactionReceipt({ - hash: claim.data, - }) - - React.useEffect(() => { - if (!receipt.data) return - queryClient.refetchQueries({ queryKey: ['getBalance'] }) - }, [queryClient, receipt.data]) - - const isSuccess = Boolean(receipt.data) - const isConfirming = Boolean(claim.data && !receipt.data && !receipt.error) - const isPending = claim.isPending || isConfirming - const error = claim.error ?? receipt.error - - const txHash = receipt.data?.transactionHash ?? claim.data - - useConnectionEffect({ - onDisconnect() { - setExpanded(true) - claim.reset() - }, - }) - - const flowDependenciesMet = checkFlowDependencies(flowDependencies) - - const active = React.useMemo(() => { - const activeWithBalance = Boolean( - address && balance && balance.amount > 0n && tokenAddress && flowDependenciesMet, - ) - if (last) return activeWithBalance - return activeWithBalance && !isSuccess - }, [address, balance, tokenAddress, flowDependenciesMet, isSuccess, last]) - - return ( - setExpanded(!expanded)} - className="font-normal text-[14px] -tracking-[2%]" - type="button" - > - {expanded ? 'Hide' : 'Show'} - - ) : ( - - ) - } - > - {txHash && isSuccess && expanded && ( -
-
-
- Successfully claimed {REWARD_AMOUNT} {metadata?.name ?? 'token'}. -
- -
-
- )} - - ) -} From afe8382c66b93421ffa240aceb5c1771f5801c67 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:38:45 +0100 Subject: [PATCH 13/22] Remove unused rewards opt-in demo component --- .../guides/steps/rewards/OptInToRewards.tsx | 107 ------------------ 1 file changed, 107 deletions(-) delete mode 100644 src/components/guides/steps/rewards/OptInToRewards.tsx diff --git a/src/components/guides/steps/rewards/OptInToRewards.tsx b/src/components/guides/steps/rewards/OptInToRewards.tsx deleted file mode 100644 index 08503c77..00000000 --- a/src/components/guides/steps/rewards/OptInToRewards.tsx +++ /dev/null @@ -1,107 +0,0 @@ -'use client' -import { useQueryClient } from '@tanstack/react-query' -import * as React from 'react' -import { useConnection, useConnectionEffect, useWaitForTransactionReceipt } from 'wagmi' -import { Hooks } from 'wagmi/tempo' -import { useDemoContext } from '../../../DemoContext' -import { Button, ExplorerLink, Step } from '../../Demo' -import { alphaUsd } from '../../tokens' -import type { DemoStepProps } from '../types' - -export function OptInToRewards(props: DemoStepProps) { - const { stepNumber, last = false } = props - const { address } = useConnection() - const { getData, setData } = useDemoContext() - const queryClient = useQueryClient() - const tokenAddress = getData('tokenAddress') - - const [expanded, setExpanded] = React.useState(true) - - const { data: balance } = Hooks.token.useGetBalance({ - account: address, - token: tokenAddress, - }) - - const { data: metadata } = Hooks.token.useGetMetadata({ - token: tokenAddress, - }) - - const setRecipient = Hooks.reward.useSetRecipient() - const receipt = useWaitForTransactionReceipt({ - hash: setRecipient.data, - }) - - React.useEffect(() => { - if (!receipt.data) return - setData('rewardOptedIn', true) - queryClient.refetchQueries({ queryKey: ['getUserRewardInfo'] }) - }, [queryClient, receipt.data, setData]) - - const isSuccess = Boolean(receipt.data) - const isConfirming = Boolean(setRecipient.data && !receipt.data && !receipt.error) - const isPending = setRecipient.isPending || isConfirming - const error = setRecipient.error ?? receipt.error - - const txHash = receipt.data?.transactionHash ?? setRecipient.data - - useConnectionEffect({ - onDisconnect() { - setExpanded(true) - setRecipient.reset() - }, - }) - - const active = React.useMemo(() => { - const activeWithBalance = Boolean(address && balance && balance.amount > 0n && tokenAddress) - if (last) return activeWithBalance - return activeWithBalance && !isSuccess - }, [address, balance, tokenAddress, isSuccess, last]) - - return ( - setExpanded(!expanded)} - className="font-normal text-[14px] -tracking-[2%]" - type="button" - > - {expanded ? 'Hide' : 'Show'} - - ) : ( - - ) - } - > - {txHash && isSuccess && expanded && ( -
-
-
- Successfully opted in to rewards. -
- -
-
- )} - - ) -} From eb312e0e12c0cf568c4ce42e17551dc924625dbe Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:38:54 +0100 Subject: [PATCH 14/22] Remove unused rewards distribution demo component --- .../guides/steps/rewards/StartReward.tsx | 123 ------------------ 1 file changed, 123 deletions(-) delete mode 100644 src/components/guides/steps/rewards/StartReward.tsx diff --git a/src/components/guides/steps/rewards/StartReward.tsx b/src/components/guides/steps/rewards/StartReward.tsx deleted file mode 100644 index 3f05038e..00000000 --- a/src/components/guides/steps/rewards/StartReward.tsx +++ /dev/null @@ -1,123 +0,0 @@ -'use client' -import { useQueryClient } from '@tanstack/react-query' -import * as React from 'react' -import { parseUnits } from 'viem' -import { useConnection, useConnectionEffect, useWaitForTransactionReceipt } from 'wagmi' -import { Hooks } from 'wagmi/tempo' -import { useDemoContext } from '../../../DemoContext' -import { Button, ExplorerLink, Step } from '../../Demo' -import { alphaUsd } from '../../tokens' -import type { DemoStepProps } from '../types' -import { REWARD_AMOUNT, REWARD_RECIPIENT_UNSET } from './Constants' - -export function StartReward(props: DemoStepProps) { - const { stepNumber, last = false } = props - const { address } = useConnection() - const { getData, setData } = useDemoContext() - const queryClient = useQueryClient() - const tokenAddress = getData('tokenAddress') - const rewardOptedIn = getData('rewardOptedIn') - - const [expanded, setExpanded] = React.useState(true) - - const { data: balance } = Hooks.token.useGetBalance({ - account: address, - token: tokenAddress, - }) - - const { data: metadata } = Hooks.token.useGetMetadata({ - token: tokenAddress, - }) - - const { data: rewardInfo } = Hooks.reward.useUserRewardInfo({ - token: tokenAddress, - account: address, - }) - - const start = Hooks.reward.useDistribute() - const receipt = useWaitForTransactionReceipt({ - hash: start.data, - }) - - React.useEffect(() => { - if (!receipt.data) return - setData('rewardId', 1n) - queryClient.refetchQueries({ queryKey: ['getUserRewardInfo'] }) - queryClient.refetchQueries({ queryKey: ['getBalance'] }) - }, [queryClient, receipt.data, setData]) - - const isSuccess = Boolean(receipt.data) - const isConfirming = Boolean(start.data && !receipt.data && !receipt.error) - const isPending = start.isPending || isConfirming - const error = start.error ?? receipt.error - - const txHash = receipt.data?.transactionHash ?? start.data - - useConnectionEffect({ - onDisconnect() { - setExpanded(true) - start.reset() - }, - }) - - const active = React.useMemo(() => { - const activeWithBalance = Boolean( - address && - balance && - balance.amount > 0n && - tokenAddress && - metadata && - (rewardOptedIn || (!!rewardInfo && rewardInfo.rewardRecipient !== REWARD_RECIPIENT_UNSET)), - ) - if (last) return activeWithBalance - return activeWithBalance && !isSuccess - }, [address, balance, tokenAddress, metadata, rewardOptedIn, rewardInfo, last, isSuccess]) - - return ( - setExpanded(!expanded)} - className="font-normal text-[14px] -tracking-[2%]" - type="button" - > - {expanded ? 'Hide' : 'Show'} - - ) : ( - - ) - } - > - {txHash && isSuccess && expanded && ( -
-
-
- Successfully started reward distribution. -
- -
-
- )} - - ) -} From 67fbca2652e72b8f5925511e16079393e49c9cd6 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:39:30 +0100 Subject: [PATCH 15/22] Remove unused rewards demo constants --- src/components/guides/steps/rewards/Constants.tsx | 3 --- 1 file changed, 3 deletions(-) delete mode 100644 src/components/guides/steps/rewards/Constants.tsx diff --git a/src/components/guides/steps/rewards/Constants.tsx b/src/components/guides/steps/rewards/Constants.tsx deleted file mode 100644 index 60a0f814..00000000 --- a/src/components/guides/steps/rewards/Constants.tsx +++ /dev/null @@ -1,3 +0,0 @@ -'use client' -export const REWARD_AMOUNT = '50' -export const REWARD_RECIPIENT_UNSET = '0x0000000000000000000000000000000000000000' From 433c709b0a528ebfaee88507f35206fa6f00d980 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:47:42 +0100 Subject: [PATCH 16/22] Remove rewards distribution from TIP-20 spec --- src/pages/docs/protocol/tip20/spec.mdx | 29 ++++++-------------------- 1 file changed, 6 insertions(+), 23 deletions(-) diff --git a/src/pages/docs/protocol/tip20/spec.mdx b/src/pages/docs/protocol/tip20/spec.mdx index 0cee31a3..b8c6d45f 100644 --- a/src/pages/docs/protocol/tip20/spec.mdx +++ b/src/pages/docs/protocol/tip20/spec.mdx @@ -1,12 +1,12 @@ --- title: TIP-20 Tokens Specification -description: Technical specification for TIP-20 tokens, the optimized token standard extending ERC-20 with memos, legacy rewards behavior, and policy integration. +description: Technical specification for TIP-20 tokens, the optimized token standard extending ERC-20 with memos 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, legacy rewards behavior, and transfer policies. +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 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 and transfer policies. Additionally, since each ERC-20 token has its own implementation, integrators can't depend on consistent behavior across tokens. @@ -14,7 +14,7 @@ TIP-20 extends ERC-20, building these features into precompiled contracts that a 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 legacy [reward distribution](/docs/protocol/tip20-rewards/spec) claim path for already-accrued rewards. +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 and a role-based access control system for token administrative operations. ## TIP20 @@ -317,18 +317,6 @@ interface ITIP20 { /// @param newQuoteToken The new quote token that has been set event QuoteTokenUpdate(address indexed updater, ITIP20 indexed newQuoteToken); - /// @notice Emitted when a holder sets or updates their reward recipient address - /// @param holder The token holder configuring the recipient - /// @param recipient The address that will receive claimed rewards - event RewardRecipientSet(address indexed holder, address indexed recipient); - - /// @notice Emitted when a reward distribution is scheduled - /// @param funder The account funding the reward distribution - /// @param amount The total amount of tokens allocated to the reward - event RewardDistributed( - address indexed funder, - uint256 amount, - ); /// @notice Emitted when the token's supply cap is updated /// @param updater The account that updated the supply cap @@ -426,8 +414,6 @@ interface ITIP20 { /// @notice The new supply cap is invalid, for example lower than the current total supply error InvalidSupplyCap(); - /// @notice A rewards operation was attempted when no opted-in supply exists - error NoOptedInSupply(); /// @notice The configured transfer policy denies authorization for the sender or recipient error PolicyForbids(); @@ -464,7 +450,6 @@ Internally, this is implemented via a `transferAuthorized` modifier that: - Calls `TIP403_REGISTRY.isAuthorized(transferPolicyId, to)` for the recipient. Both checks must return `true`, otherwise the call reverts with `PolicyForbids`. -Reward operations (`distributeReward`, `setRewardRecipient`, `claimRewards`) also perform the same TIP-403 authorization checks before moving any funds. ## Invalid Recipient Protection TIP-20 tokens cannot be sent to other TIP-20 token contract addresses. The implementation uses a `validRecipient` guard that rejects recipients whose address is zero, or has the TIP-20 prefix (`0x20c000000000000000000000`). @@ -502,7 +487,7 @@ The admin (`DEFAULT_ADMIN_ROLE`) sets or clears it via `setLogoURI(string newLog Per [TIP-1026's recommended formats](https://tips.sh/1026#recommended-formats), use a square, single-frame rasterized image (PNG or WebP). SVG is allowed by the scheme allowlist but not recommended — integrators that accept SVG must follow TIP-1026's SVG-handling guidance. ## Pause Controls -Pause controls `pause` and `unpause` govern all transfer operations and reward related flows. When paused, transfers and memo transfers halt, but administrative and configuration functions remain allowed. The `paused()` getter reflects the current state and must be checked by all affected entrypoints. +Pause controls `pause` and `unpause` govern token movement. When paused, transfers and memo transfers halt, but administrative and configuration functions remain allowed. The `paused()` getter reflects the current state and must be checked by all affected entrypoints. ## TIP-20 Roles TIP-20 uses a role-based authorization system. The main roles are: @@ -521,7 +506,7 @@ System level functions `systemTransferFrom`, `transferFeePreTx`, and `transferFe ### Implicit approvals for listed precompiles (TIP-1035) An Implicit Approval List names the precompiles that may pull TIP-20 tokens without a prior `approve`. Listed precompiles call the internal `system_transfer_from(from, to, amount)` entrypoint, which: -- Is **not** part of the public TIP-20 ABI and is **not** callable by external contracts or EOAs. +- Is **not** part of the public TIP-20 ABI and **not** callable by external contracts or EOAs. - Skips allowance checks and the allowance storage write. - Still enforces balance checks, TIP-403 transfer policies, and AccountKeychain spending limits. - Emits the standard TIP-20 `Transfer` event. @@ -531,8 +516,6 @@ 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. -## 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`. @@ -661,7 +644,7 @@ interface ITIP20Factory { ## Invariants - `totalSupply()` must always equal to the sum of all `balanceOf(account)` over all accounts. - `totalSupply()` must always be `<= supplyCap` -- When `paused` is `true`, no functions that move tokens (`transfer`, `transferFrom`, memo variants, `systemTransferFrom`, `transferFeePreTx`, `distributeReward`, `setRewardRecipient`, `claimRewards`) can succeed. +- When `paused` is `true`, no functions that move tokens (`transfer`, `transferFrom`, memo variants, `systemTransferFrom`, `transferFeePreTx`) can succeed. - TIP20 tokens cannot be transferred to another TIP20 token contract address. - `systemTransferFrom`, `transferFeePreTx`, and `transferFeePostTx` never change `totalSupply()`. - `bytes(logoURI()).length` must always be `<= 256`. From 2c7bc84e101a6007dc987278e0a173275f503a7a Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 22:59:51 +0100 Subject: [PATCH 17/22] Remove rewards docs from navigation --- vocs.config.ts | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/vocs.config.ts b/vocs.config.ts index b1cd9718..bb11fb80 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -174,7 +174,6 @@ export default defineConfig({ 'stablecoin-dex': 'EXCHANGE', 'tempo-transaction': 'TRANSACTIONS', tip20: 'TIP-20', - 'tip20-rewards': 'REWARDS', tip403: 'TIP-403', tips: 'TIPS', transactions: 'TRANSACTIONS', @@ -373,10 +372,6 @@ export default defineConfig({ text: 'Use your stablecoin for fees', link: '/docs/guide/issuance/use-for-fees', }, - { - text: 'Distribute rewards', - link: '/docs/guide/issuance/distribute-rewards', - }, { text: 'Manage your stablecoin', link: '/docs/guide/issuance/manage-stablecoin', @@ -667,20 +662,6 @@ export default defineConfig({ }, ], }, - { - text: 'Tempo Token Rewards', - collapsed: false, - items: [ - { - text: 'Overview', - link: '/docs/protocol/tip20-rewards/overview', - }, - { - text: 'Specification', - link: '/docs/protocol/tip20-rewards/spec', - }, - ], - }, { text: 'Tempo Policies (TIP-403)', collapsed: false, @@ -1259,7 +1240,15 @@ export default defineConfig({ }, { source: '/docs/protocol/tip20-rewards', - destination: '/docs/protocol/tip20-rewards/overview', + destination: '/docs/protocol/upgrades/t7#deprecate-tip-20-rewards', + }, + { + source: '/docs/protocol/tip20-rewards/:path*', + destination: '/docs/protocol/upgrades/t7#deprecate-tip-20-rewards', + }, + { + source: '/docs/guide/issuance/distribute-rewards', + destination: '/docs/protocol/upgrades/t7#deprecate-tip-20-rewards', }, { source: '/docs/protocol/tip403', From 638a38ad20a8fec5c1b35a35494297a9deefff38 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 23:01:04 +0100 Subject: [PATCH 18/22] Sync OG sections after rewards removal --- src/lib/og-sections.ts | 1 - 1 file changed, 1 deletion(-) diff --git a/src/lib/og-sections.ts b/src/lib/og-sections.ts index eb2ed02f..dd55c6f3 100644 --- a/src/lib/og-sections.ts +++ b/src/lib/og-sections.ts @@ -51,7 +51,6 @@ export const ogSubsectionMap: Record = { 'stablecoin-dex': 'EXCHANGE', 'tempo-transaction': 'TRANSACTIONS', tip20: 'TIP-20', - 'tip20-rewards': 'REWARDS', tip403: 'TIP-403', tips: 'TIPS', transactions: 'TRANSACTIONS', From 1e260e11019289ec4c8e2f7e612cd20dc62214a9 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 23:03:05 +0100 Subject: [PATCH 19/22] Remove rewards e2e test --- e2e/distribute-rewards.test.ts | 113 --------------------------------- 1 file changed, 113 deletions(-) delete mode 100644 e2e/distribute-rewards.test.ts diff --git a/e2e/distribute-rewards.test.ts b/e2e/distribute-rewards.test.ts deleted file mode 100644 index 3bf9c963..00000000 --- a/e2e/distribute-rewards.test.ts +++ /dev/null @@ -1,113 +0,0 @@ -import { expect, test } from '@playwright/test' -import { getDemoStep } from './helpers' - -test('distribute rewards', async ({ page }) => { - test.setTimeout(240000) - - // Set up virtual authenticator via CDP - const client = await page.context().newCDPSession(page) - await client.send('WebAuthn.enable') - const { authenticatorId } = await client.send('WebAuthn.addVirtualAuthenticator', { - options: { - protocol: 'ctap2', - transport: 'internal', - hasResidentKey: true, - hasUserVerification: true, - isUserVerified: true, - }, - }) - - await page.goto('/docs/guide/issuance/distribute-rewards') - - // Step 1: Sign in - const signUpButton = page.getByRole('button', { name: 'Sign in' }).first() - await expect(signUpButton).toBeVisible({ timeout: 90000 }) - await signUpButton.click() - - await expect(page.getByRole('button', { name: 'Sign out' }).first()).toBeVisible({ - timeout: 30000, - }) - - // Step 2: Add funds - const addFundsButton = page.getByRole('button', { name: 'Add funds' }).first() - await expect(addFundsButton).toBeVisible() - await addFundsButton.click() - - await expect(page.getByRole('button', { name: 'Add more funds' }).first()).toBeVisible({ - timeout: 90000, - }) - - // Step 3: Create a token - // Use label-based selectors to ensure we're filling the right inputs in the demo form - const nameInput = page.getByLabel('Token name').first() - await expect(nameInput).toBeVisible() - await nameInput.fill('RewardTestUSD') - - const symbolInput = page.getByLabel('Token symbol').first() - await expect(symbolInput).toBeVisible() - await symbolInput.fill('REWARD') - - const deployButton = page.getByRole('button', { name: 'Deploy' }).first() - await expect(deployButton).toBeVisible() - await deployButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).first()).toBeVisible({ - timeout: 90000, - }) - - // Step 4: Grant issuer role - const grantStep = getDemoStep(page, 'Grant issuer role on RewardTestUSD.') - const grantEnterDetails = grantStep.getByRole('button', { name: 'Enter details' }) - await expect(grantEnterDetails).toBeVisible() - await grantEnterDetails.click() - - const grantButton = grantStep.getByRole('button', { name: 'Grant' }) - await grantButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).nth(1)).toBeVisible({ - timeout: 90000, - }) - - // Step 5: Mint tokens - const mintStep = getDemoStep(page, 'Mint 100 RewardTestUSD to yourself.') - const mintEnterDetails = mintStep.getByRole('button', { name: 'Enter details' }) - await expect(mintEnterDetails).toBeVisible() - await mintEnterDetails.click() - - const mintButton = mintStep.getByRole('button', { name: 'Mint' }) - await mintButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).nth(2)).toBeVisible({ - timeout: 90000, - }) - - // Step 6: Opt in to rewards - const optInButton = page.getByRole('button', { name: 'Opt In' }).first() - await expect(optInButton).toBeVisible() - await optInButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).nth(3)).toBeVisible({ - timeout: 90000, - }) - - // Step 7: Start reward - const startButton = page.getByRole('button', { name: 'Start Reward' }).first() - await expect(startButton).toBeVisible() - await startButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).nth(4)).toBeVisible({ - timeout: 90000, - }) - - // Step 8: Claim reward - const claimButton = page.getByRole('button', { name: 'Claim' }).first() - await expect(claimButton).toBeVisible() - await claimButton.click() - - await expect(page.getByRole('link', { name: 'View receipt' }).nth(5)).toBeVisible({ - timeout: 90000, - }) - - // Clean up - await client.send('WebAuthn.removeVirtualAuthenticator', { authenticatorId }) -}) From 3a981d2ef6954054ce6566ec17dd2c960c573592 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 23:03:28 +0100 Subject: [PATCH 20/22] Remove stale rewards spec link from blockspace docs --- src/pages/docs/protocol/blockspace/overview.mdx | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/pages/docs/protocol/blockspace/overview.mdx b/src/pages/docs/protocol/blockspace/overview.mdx index 193403c4..9f61e724 100644 --- a/src/pages/docs/protocol/blockspace/overview.mdx +++ b/src/pages/docs/protocol/blockspace/overview.mdx @@ -32,12 +32,11 @@ pub struct Header { ### Block body The block body in Tempo retains the canonical Ethereum block body structure, with the addition of system transactions. Transactions are ordered in the following sections: -1. Start-of-block system transaction(s) (must begin with the rewards registry call). +1. Start-of-block system transaction(s). 2. Proposer lane transactions, subject to `general_gas_limit` on non-payment transactions. 3. Remaining transactions that consume the shared gas budget. 4. Protocol-defined end-of-block system transactions, when required. ### System transactions -A valid tempo block must contain the following system transaction: - - **Rewards Registry (start-of-block)** — must be the first transaction in the block body; refreshes validator rewards metadata before user transactions begin. Detailed specification [here](/docs/protocol/tip20-rewards/spec). +A valid Tempo block must include any required protocol-defined system transactions in the expected order before and after user transactions. From 05ea4760a4e3a08c5533d8098cf21c21bb9c2c1b Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 23:04:28 +0100 Subject: [PATCH 21/22] Remove rewards from TIP-20 feature copy --- src/marketing/app/_components/features.tsx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/marketing/app/_components/features.tsx b/src/marketing/app/_components/features.tsx index f56afb21..4068b385 100644 --- a/src/marketing/app/_components/features.tsx +++ b/src/marketing/app/_components/features.tsx @@ -185,8 +185,7 @@ export const features: Feature[] = [ fees,{' '} memos,{' '} lanes,{' '} - policies,{' '} - rewards, and{' '} + policies, and{' '} issuer controls. ), From 239fe24a1123a643d3b50e7d8936eeffeed5c832 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 9 Jul 2026 23:05:24 +0100 Subject: [PATCH 22/22] Remove rewards routes from OG preview script --- scripts/download-og.sh | 2 -- 1 file changed, 2 deletions(-) diff --git a/scripts/download-og.sh b/scripts/download-og.sh index 62abcb05..45c34a62 100644 --- a/scripts/download-og.sh +++ b/scripts/download-og.sh @@ -86,7 +86,6 @@ download_og "Send Parallel Transactions" "BUILD" "PAYMENTS" "build--payments--pa download_og "Create a Stablecoin" "BUILD" "ISSUANCE" "build--issuance--create" download_og "Mint Stablecoins" "BUILD" "ISSUANCE" "build--issuance--mint" download_og "Use Your Stablecoin for Fees" "BUILD" "ISSUANCE" "build--issuance--use-for-fees" -download_og "Distribute Rewards" "BUILD" "ISSUANCE" "build--issuance--distribute-rewards" download_og "Manage Your Stablecoin" "BUILD" "ISSUANCE" "build--issuance--manage" download_og "Managing Fee Liquidity" "BUILD" "EXCHANGE" "build--exchange--fee-liquidity" @@ -103,7 +102,6 @@ download_og "Accept Streamed Payments" "BUILD" "MACHINE PAY" "build--machine-pay download_og "Specification" "PROTOCOL" "TIP-20" "protocol--tip20--spec" download_og "Overview" "PROTOCOL" "TIP-20" "protocol--tip20--overview" -download_og "Specification" "PROTOCOL" "TIP-20 REWARDS" "protocol--tip20-rewards--spec" download_og "Specification" "PROTOCOL" "TIP-403" "protocol--tip403--spec" download_og "Specification" "PROTOCOL" "FEES" "protocol--fees--spec" download_og "Fee AMM" "PROTOCOL" "FEES" "protocol--fees--fee-amm"