--- id: TIP-1059 title: Discounted Pure Payment Transfers description: Lets simple TIP-20 payment and redemption operations settle at a lower gas price. authors: Mallesh Pai status: Approved related: TIP-1010, TIP-1016 protocolVersion: T6 --- # TIP-1059: Discounted Pure Payment Transfers ## Abstract This TIP lets simple TIP-20 payment and redemption operations settle at 12 billion attodollars per gas instead of the normal 20 billion attodollars per gas. The discount is intentionally narrow. It applies only to payment-lane transactions that call a small set of TIP-20 transfer or burn functions and use no more than 250,000 gas. Approvals, mints, arbitrary contract execution, mixed batches, and higher-gas transactions continue to pay the normal base fee. ## Motivation Tempo keeps the fixed base fee high enough to price worst-case spam and state growth. That is the right default for arbitrary execution and state-creating transactions, but it overprices simple, low-gas payment flows. This TIP carves out a lower settlement price for those low-cost payment and redemption paths: TIP-20 transfers, delegated transfers, and burns. Wallets still authorize the normal base fee for reliable inclusion. After execution, if the transaction satisfies the payment-lane rules, uses only an eligible TIP-20 function, and stays under the gas-used threshold, the protocol charges the lower gas price and refunds the difference. The discount is a payment UX improvement, not a replacement for the normal base fee as the chain's main spam-resistance mechanism. --- # Specification ## Parameters At the T6 hardfork, introduce the following parameters: | Parameter | Value | Meaning | | --- | ---: | --- | | Normal base fee | 20,000,000,000 | Existing gas price for ordinary transactions | | Discounted payment gas price | 12,000,000,000 | Gas price charged to eligible payment operations | | Maximum discounted payment gas used | TIP-1000 new-state-write gas cost, 250,000 gas at T6 | Per-transaction execution cap for the discount | All gas prices are denominated in attodollars per gas. ## Eligible operations A transaction is eligible for the discounted payment gas price only if all of the following are true: 1. It satisfies the current payment-lane classification rules. 2. Every user call in the transaction is one of: - `transfer(address to, uint256 amount)` - `transferWithMemo(address to, uint256 amount, bytes32 memo)` - `transferFrom(address from, address to, uint256 amount)` - `transferFromWithMemo(address from, address to, uint256 amount, bytes32 memo)` - `burn(uint256 amount)` - `burnWithMemo(uint256 amount, bytes32 memo)` 3. The transaction uses no more than the TIP-1000 new-state-write gas cost. At T6, this is 250,000 gas. This enforces the discount to apply only to transactions that do not create new state. For account-abstraction (type `0x76`) transactions, every call in `calls` must individually be classified as a TIP-20 payment. A transaction with any call that does not satisfy this constraint is not eligible for the discount. This eligible function set is intentionally narrower than the payment lane. Payment-lane eligibility is a prerequisite for the discount, not a guarantee of the discount. `transferFrom` is included because it is also a payment movement. The discount does not make allowance creation cheaper: approvals are not eligible. `burn` is included for redemption and off-ramp flows. It does not create recipient state. ## Applying the discount A transaction that satisfies the eligibility rules receives a fixed discount equal to the difference between the normal T6 base fee and the discounted payment gas price. At T6, the normal base fee is 20 billion attodollars per gas and the discounted payment gas price is 12 billion attodollars per gas, so the discount is 8 billion attodollars per gas. The discount is subtracted from the transaction-derived effective gas price. Any effective priority fee remains payable. A transaction that does not satisfy the eligibility rules receives no discount. Execution semantics are otherwise unchanged. In particular, execution uses the normal base fee as the transaction gas price. The discount affects post-execution fee settlement only. ## Fee caps and refunds All transactions must authorize the normal base fee. A transaction with `max_fee_per_gas` below the normal base fee is not eligible for inclusion under this TIP. A transaction that receives the discount is charged the transaction-derived effective gas price minus the fixed discount. A transaction that does not receive the discount is charged its normal transaction-derived effective gas price. If a transaction receives the discount, the unused authorized amount is refunded through the existing gas refund path. Wallets SHOULD continue to use the normal base fee by default. This gives users reliable inclusion while still letting them benefit from the discount when the transaction is eligible. ## Block building The payload fee total used for builder comparison MUST use the same fee amount that will be charged during settlement. ## RPC and estimation Fee estimation for ordinary transactions is unchanged. Fee estimation for eligible pure TIP-20 payment operations SHOULD show the discounted settlement gas price when the transaction is expected to qualify. RPCs and wallets SHOULD make clear that transactions still authorize the normal base fee for reliable inclusion. ## Compatibility This TIP is layered on top of the payment lane introduced at genesis and recently expanded in TIP-1045. If a transaction is not eligible for the payment lane, it is not eligible for this discount. Existing wallets can continue to submit payment transactions with `max_fee_per_gas` set to the normal base fee. These transactions remain valid whether or not the discount applies. Existing payment-lane transactions that are not in this TIP's narrower eligible function set continue to work as before and continue to pay the normal base fee. --- # Alternatives Considered ## Lower the base fee for all transactions This is the simplest change, but it makes storage creation and arbitrary contract execution cheaper too. That weakens the protections the chain has against cheap worst-case spam and permanent state growth. ## Lower the payment-lane base fee for all payment-lane transactions This is broader than the proposal in this TIP. Doing this risks making permanent state creation, approvals, and other non-transfer payment-lane activity too cheap. ## Discount based only on gas limit This would be simpler to validate before execution, but it would punish wallets that set conservative gas limits because they do not always know how much gas a transfer will use. This TIP uses actual gas used instead. ## Cap discounted gas per block A per-block cap would bound the amount of discounted execution in each block, but it adds ordering complexity and makes the discount less predictable for users. At a discounted price of 12 billion attodollars per gas, this TIP keeps spam resistance closer to the normal base fee without adding a separate discounted-cap market. ## Allow discount-only transactions This would let users submit transactions with `max_fee_per_gas` below the normal base fee. It also makes inclusion less reliable because those transactions are valid only if the discount applies. This TIP keeps the first version simpler: users authorize the normal base fee, and the protocol refunds the difference when the discount applies. ## Use a capped EIP-1559 style fee controller A dynamic fee could make payments cheap most of the time while rising under load. It is also more complex: the protocol would need a fee market, wallet behavior would need to change, and a lot of permanent state could be added cheaply to the chain during periods of low prices. ## Separate storage pricing from execution pricing This is the clean long-term model. State creation could stay expensive while execution gets cheaper. It is also a larger protocol change than needed for the immediate goal of making ordinary payments cheaper.