---
id: TIP-1115
title: Ordered Fallback Fee Tokens
description: Selects the first token in a protocol-defined fallback list with enough balance to cover the maximum transaction fee.
authors: Dan Robinson
status: Approved
related: N/A
protocolVersion: T13
---

# TIP-1115: Ordered Fallback Fee Tokens

## Abstract

Replace the pathUSD fee-token fallback with an ordered list of stablecoins.
Select the first token whose balance covers the transaction's maximum gas fee.

## Motivation

Users holding other stablecoins should be able to pay fees by default without
acquiring pathUSD or setting a fee-token preference.

## Assumptions

Listed tokens are deployed USD-denominated TIP-20s.

---

# Specification

## Fallback List

Define `FALLBACK_FEE_TOKENS` as an ordered list of distinct token addresses in
protocol configuration. The initial list is `[pathUSD, OUSD]`, in this order:

1. pathUSD: `0x20c0000000000000000000000000000000000000`.
2. OUSD: `0x20c0000000000000000000006a37da5c996874be`.

Changes to the list take effect through protocol upgrades. The activation
version is TBD.

## Selection

Replace only the final pathUSD fallback. Existing explicit fee-token choices,
preferences, and inference rules retain their precedence; failures under those
rules do not enter the fallback list.

When the fallback is reached, compute the maximum fee in TIP-20 base units:

```text
maxFee = ceil(gasLimit * maxFeePerGas / 10^12)
```

For legacy transactions, use `gasPrice` in place of `maxFeePerGas`.
Using the fee payer's balances before execution:

```text
for token in FALLBACK_FEE_TOKENS:
    if balance(token, feePayer) >= maxFee:
        return token

fail with insufficient funds
```

One token must cover the entire fee. A zero maximum fee selects pathUSD.

Only insufficient balance advances the search. Once a token is selected,
existing pause, policy, access-key, and FeeAMM liquidity checks apply; a failure
does not try another token. Fee collection and refunds use the selected token
under the existing rules. The validator's default fee token remains pathUSD.

## Validation

Pool validation and execution use the same selection rule. Changes to the fee
payer's balance in any examined token require revalidation, including tokens
skipped for insufficient balance. Replay must track these read dependencies.
Before activation, historical execution uses the existing pathUSD fallback.

## Gas Overhead

For a list of `N` tokens, transactions rejected because every candidate has
insufficient balance require `N - 1` additional storage reads. The worst-case
number of storage reads per transaction also increases by `N - 1`, since even a
valid transaction may need to check the entire list.

The gas charged for fee-token selection remains constant regardless of the
number of tokens checked.

# Tooling

This change applies only to transactions that omit `feeToken` and whose fee-payer
address has no stored fee-token preference. Existing fee-token inference rules
still take precedence.

# Observability

Existing receipt `feeToken` and `feePayer` fields identify the payment. No new
events are needed.

# Threat Model

A transfer into an earlier token can change which token pays for a pending
transaction. Users can specify a fee token explicitly to pin that choice.

# Invariants

1. Before activation, use the existing fee-token rules. After activation, replace only the final pathUSD fallback; explicit choices, preferences, and inference retain their precedence.

2. Fallback selects the first listed token whose fee payer balance covers the full maximum fee. Balances cannot be combined. A zero maximum fee selects pathUSD; if none covers a nonzero maximum, the transaction is invalid.

3. Once selected, a token is used for collection, refunds, and the receipt. A later payment failure does not trigger another candidate.

4. Pool validation, execution, and replay select from their current pre-execution state. If an examined balance changes, the pool must resolve the token again before using its cached choice