From ba9fc70beba15083672b3661657c719fb7849a07 Mon Sep 17 00:00:00 2001 From: Anil Date: Tue, 11 Aug 2026 04:04:39 +0300 Subject: [PATCH] docs: replace startReward with distributeReward after T7 deprecation Evergreen protocol docs still referenced the removed startReward() selector. Align fee-token inference and spending-limit tracking with the current TIP-20 ABI and note that new reward distributions are deprecated since the T7 upgrade. Fixes tempoxyz/docs#741 --- src/pages/docs/protocol/fees/spec-fee.mdx | 8 ++++++-- .../docs/protocol/transactions/spec-tempo-transaction.mdx | 4 ++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/src/pages/docs/protocol/fees/spec-fee.mdx b/src/pages/docs/protocol/fees/spec-fee.mdx index b17b929cc..82e9d8927 100644 --- a/src/pages/docs/protocol/fees/spec-fee.mdx +++ b/src/pages/docs/protocol/fees/spec-fee.mdx @@ -100,7 +100,7 @@ The protocol checks for token preferences in five ways, with this order of prece 1. Transaction (set by the `fee_token` field of the transaction) 2. Account (set on the FeeManager contract by the `fee_payer` of the transaction) -3. TIP-20 contract (if the transaction is calling `transfer`, `transferWithMemo`, or `startReward` on a TIP-20 token contract, the transaction uses that token as its fee token) +3. TIP-20 contract (if the transaction is calling `transfer`, `transferWithMemo`, or `distributeReward` on a TIP-20 token contract, the transaction uses that token as its fee token) 4. Stablecoin DEX (for certain swap calls, the transaction uses the `tokenIn` argument as its fee token) 5. PathUSD (as a fallback) @@ -136,7 +136,11 @@ If the top-level call of a transaction is to one of the following functions on a * `transfer(address to, uint256 amount)` * `transferWithMemo(address to, uint256 amount, bytes32 memo)` -* `startReward(uint256 amount, uint32 seconds_)` +* `distributeReward(uint256 amount, uint32 seconds_)` + +:::info[Rewards deprecation] +Since the [T7 upgrade](/docs/protocol/upgrades/t7), new TIP-20 reward distributions are deprecated. The `distributeReward` references below describe pre-T7 fee-token inference behavior. +::: then that TIP-20 token is used as the user's fee token for that transaction (unless there is a preference specified at the [transaction](#transaction-level) or [account](#account-level) level). diff --git a/src/pages/docs/protocol/transactions/spec-tempo-transaction.mdx b/src/pages/docs/protocol/transactions/spec-tempo-transaction.mdx index f0cf1f839..505aa0146 100644 --- a/src/pages/docs/protocol/transactions/spec-tempo-transaction.mdx +++ b/src/pages/docs/protocol/transactions/spec-tempo-transaction.mdx @@ -695,7 +695,7 @@ When a limited Access Key attempts to call any mutable keychain function: The protocol tracks and enforces spending limits for TIP20 token transfers: -**Scope:** Only TIP20 `transfer()`, `transferWithMemo()`, `approve()`, and `startReward()` calls are tracked +**Scope:** Only TIP20 `transfer()`, `transferWithMemo()`, `approve()`, and `distributeReward()` calls are tracked (new reward distributions are deprecated since [T7](/docs/protocol/upgrades/t7); tracking below reflects pre-T7 behavior) - Spending limits only apply when `msg.sender == tx.origin` (direct EOA calls) - When a contract makes transfers on behalf of the user, spending limits do NOT apply (e.g., `transferFrom()`) - Native value transfers are NOT limited @@ -703,7 +703,7 @@ The protocol tracks and enforces spending limits for TIP20 token transfers: - Other asset types are NOT limited **Tracking:** During transaction execution, when an Access Key's transaction directly calls TIP20 methods: -1. Protocol intercepts `transfer(to, amount)`, `transferWithMemo()`, `approve(spender, amount)`, and `startReward()` calls +1. Protocol intercepts `transfer(to, amount)`, `transferWithMemo()`, `approve(spender, amount)`, and `distributeReward()` calls 2. For `transfer`/`transferWithMemo`, the full `amount` is checked against the remaining limit 3. For `approve`, only **increases** in approval (new approval minus previous allowance) are checked and counted against the limit 4. Queries: `getRemainingLimitWithPeriod(account, keyId, token)`, which returns `(remaining, periodEnd)` and reflects any periodic rollover