> Feedback: If these docs are stale, missing, or confusing, post sanitized feedback to `https://docs.tempo.xyz/api/feedback` with `source: "mcp"`, a short `message`, and any relevant `toolName`, `relatedResource`, or `client`.
# 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, additional inclusion is constrained by the remaining shared gas budget.

## 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. Every call in the transaction matches an allow-listed payment call shape.
2. The transaction `access_list` is empty.
3. The transaction `authorization_list` and `tempo_authorization_list` are empty.
4. If `key_authorization` is present, `len(rlp(key_authorization)) <= 1024` bytes.

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

The payment call allow-list includes TIP-20 payment and mint/burn/approval calls, plus the `TIP20ChannelReserve` payment-channel precompile calls. Calls with unrecognized selectors, malformed ABI encoding, disallowed targets, non-empty auxiliary payloads, or dynamic calldata above the allow-list size bound are classified as non-payment transactions. See [TIP-1045](https://tips.sh/1045) for the complete selector table and ABI constraints.

### 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.