Skip to content

Payment Lane Specification

Abstract

This specification introduces a second consensus gas constraint for non-payment transactions. Transactions are classified as either payments or non-payments based solely on their transaction data, without requiring any access to blockchain state. For a block to be valid, total gas_used by the block must be less than the gas_limit. Non-payment transactions executed in the proposer's lane (i.e. before the gas incentive section) must consume at most general_gas_limit, a new field added to the header. Once that budget is exhausted, any additional inclusion must come via the gas incentive lane defined in the sub-blocks specification.

Motivation

Tempo ensures that payment transactions always have available blockspace, even during periods of high network congestion from DeFi activity or complex smart contracts. No action is required by the user to take advantage of this feature.

This is achieved through separate gas limits for payment and non-payment transactions. When blocks are constructed, validators enforce two separate gas constraints:

  1. gas_limit — The total gas available for all transactions (standard Ethereum behavior)
  2. general_gas_limit — The maximum gas that non-payment transactions can consume

Non-payment transactions in the proposer's lane can only fill up to general_gas_limit, payment transactions can still use the remaining capacity up.

Terminology

  • Payment transaction: Determined by a function, is_payment(tx) -> bool. This function returns true if the transaction is a payment transaction, false otherwise.
  • Non-payment transaction: !is_payment(tx).

Specification

1. Transaction classification

A transaction is classified as a payment transaction when:

  1. the recipient address (tx.to) starts with the TIP-20 payment prefix 0x20c0000000000000000000000000, or,
  2. for TempoTransactions, every entry in tx.calls targets an address starting with the TIP-20 payment prefix 0x20c0000000000000000000000000.

This classification is performed entirely on the transaction payload, no account state is consulted.

2. Ordering of Transactions

The specification does not require any specific ordering of transactions: payment and non-payment transactions can be intermixed.

3. Gas accounting & validity (consensus)

Validity of a block requires that,

general_gas_limit >= Σ gas_consumed(tx[i])   
for all i such that !is_payment(tx[i]) and tx[i] is in the proposer's lane

Where gas_consumed includes intrinsic gas and gas burned by reverts, as in the existing protocol.