<!-- tempo-docs-context -->
> Source: [/docs/accounts/fees/fee-tokens](https://tempo.xyz/developers/docs/accounts/fees/fee-tokens.md)
> Section: [Accounts](https://tempo.xyz/developers/docs/accounts.md). Create accounts, set up signing methods, policies, access keys, key rotation, and fees, and follow guides for users, automations, agents, and teams.
> [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md)

> Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation.
> If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly.

# Fee Tokens

Sets the USD stablecoin an account pays its network fees in.

## Overview

A fee token is the USD stablecoin a transaction pays its network fee in. A Tempo account needs no separate gas token for fees.

Set the account's default fee token once. Override it on any transaction that should pay in another stablecoin. On mainnet, use [OUSD](https://tempo.xyz/developers/docs/guide/ousd) for most accounts.

<span id="fee-token-limits" />

## Supported Fee Tokens

Before a transaction runs, Tempo checks its fee token:

* It's a [TIP-20 token](https://tempo.xyz/developers/docs/protocol/tip20/overview), Tempo's token standard, whose currency is USD.
* The account paying the fee holds enough of it to cover the maximum fee. The maximum fee is the gas limit times the gas price.
* If the block's validator wants a different stablecoin, the [Fee AMM](https://tempo.xyz/developers/docs/protocol/fees/spec-fee-amm) has enough liquidity to convert it. The Fee AMM is Tempo's built-in exchange pools.

If any check fails, the transaction is invalid and isn't included. Tempo doesn't try another token.

<span id="set-an-accounts-default-fee-token" />

## Set a Default Fee Token

The default covers every transaction the account pays the fee for. That includes ones it sponsors for other accounts as a [fee payer](https://tempo.xyz/developers/docs/accounts/fees/fee-sponsorship). Without one, Tempo follows the [fee token order](https://tempo.xyz/developers/docs/accounts/fees#fee-token-precedence). That order can fall back to pathUSD, a stablecoin the account might not hold.

In the code, `account` is a funded configurable account from [Create an account](https://tempo.xyz/developers/docs/accounts/create#create-an-account-from-a-signing-key). Configurable accounts run only on the Tempo Accounts devnet until T14. `client.ts` connects to the devnet ([set up the devnet key](https://tempo.xyz/developers/docs/accounts/create#connect-to-the-devnet)). The examples pay fees in its faucet's test stablecoins. A single-key account on mainnet or testnet sets and overrides its fee token the same way, with that network's stablecoins.

:::code-group
```ts [set-fee-token.ts]
import { client } from './client'

// A test stablecoin on the devnet
const otherStablecoin = '0x20c0000000000000000000000000000000000002'

const { receipt } = await client.fee.setUserTokenSync({ // [!code hl]
  account, // [!code hl]
  token: otherStablecoin, // [!code hl]
  // pays this transaction's own fee in the same stablecoin // [!code hl]
  feeToken: otherStablecoin, // [!code hl]
}) // [!code hl]
```

```ts [client.ts]
import { http } from 'viem'
import { tempoDevnet } from 'viem/chains'
import { createClient } from 'viem/tempo'

// The Tempo Accounts devnet. Its RPC needs a key, which Tempo gives you.
const rpcKey = process.env.TEMPO_DEVNET_RPC_KEY

export const client = createClient({
  chain: tempoDevnet,
  transport: http('https://rpc-t14-checkpoint.devnet.tempoxyz.dev', {
    fetchOptions: { headers: { Authorization: `Basic ${btoa(`previews:${rpcKey}`)}` } },
  }),
})
```
:::

[`fee.setUserToken`](https://viem.sh/tempo/actions/fee.setUserToken) calls `setUserToken` on the FeeManager, Tempo's built-in fee contract. Pass `feeToken` as well. Before the default exists, this transaction's own fee can fall back to pathUSD.

Read the current default with `client.fee.getUserToken({ account: account.address })`. It returns `null` until one is set.

The default outranks the token being transferred. With OUSD as the default, a transfer of another stablecoin still pays its fee in OUSD. The transaction is invalid if the account's OUSD can't cover it.

<span id="override-the-fee-token-per-transaction" />

<span id="per-transaction-fee-token" />

## Override the Fee Token

Pass `feeToken` to pay one transaction's fee in a different stablecoin. It outranks the default and every other rule, for that transaction only. Here the account sends one stablecoin to `recipient`, the payee's address. It pays the fee in another stablecoin:

```ts [transfer.ts]
import { parseUnits } from 'viem'
import { client } from './client'

// Two test stablecoins on the devnet
const stablecoin = '0x20c0000000000000000000000000000000000001'
const otherStablecoin = '0x20c0000000000000000000000000000000000002'

await client.token.transferSync({
  account,
  amount: parseUnits('25', 6),
  // this transaction's fee token
  feeToken: stablecoin, // [!code hl]
  to: recipient,
  token: otherStablecoin,
})
```

On a transaction sent through a [fee payer server](https://tempo.xyz/developers/docs/accounts/fees/fee-sponsorship#fee-sponsorship-limits), leave `feeToken` off, because the server picks it. When your backend sponsors the transaction itself, set `feeToken` to the token being transferred.

## Related

[Fee Management](https://tempo.xyz/developers/docs/accounts/fees): Covers who pays each fee and the order Tempo uses to pick the fee token.

[Fee Sponsorship](https://tempo.xyz/developers/docs/accounts/fees/fee-sponsorship): Use for paying your customers' fees with a fee payer.

[Choose a Fee Token](https://tempo.xyz/developers/docs/guide/payments/pay-fees-in-any-stablecoin): Use for trying a per-transaction fee token in Wagmi, Rust, Python, Go, or Cast.

[Fee Specification](https://tempo.xyz/developers/docs/protocol/fees/spec-fee#fee-token-preferences): Covers fee token preferences in the protocol.