Skip to main content
This page is the guide to fee abstraction for app and agent developers. To send a transaction, see Using fee abstraction. For token and adapter addresses, see Fee currency contracts. For the protocol rules (exchange rates, tx-pool checks, intrinsic gas, node flags), see the fee abstraction specification. Fee abstraction is one of Celo’s core protocol features. It allows users to pay gas fees in ERC20 tokens — like USDC, USDT, or Mento stablecoins — instead of needing to hold the native CELO token.

​
Why Fee Abstraction Matters

On most EVM chains, users must hold the native token to pay for gas. This creates friction: a user who receives USDC on Celo can’t send it anywhere without first acquiring CELO. Fee abstraction removes this barrier entirely. With fee abstraction, a user holding only USDC can send transactions, interact with contracts, and pay gas — all in USDC. No bridging, no swaps, no extra steps. This is especially valuable for:
  • Onboarding new users who receive stablecoins but don’t know about gas tokens
  • Payment applications where users transact in a single currency end-to-end
  • AI agents that operate autonomously with a single token balance

​
How It Works

Fee abstraction is built into the Celo protocol at the node level — it is not a paymaster or relayer. When a transaction includes a feeCurrency field, the Celo blockchain:
  1. Calls debitGasFees on the fee currency contract to reserve the maximum gas cost
  2. Executes the transaction normally
  3. Calls creditGasFees to refund unused gas and distribute fees to block producers
This means fee abstraction works with any externally owned account (EOA) at the protocol level. No smart contract wallets, no relayers, no extra infrastructure needed. To use an alternate fee currency, set its token or adapter address as the feeCurrency property on the transaction object. For implementation details, see Using Fee Abstraction. To add a new fee currency to the protocol, see Adding Fee Currencies.

​
Wallet support for CIP-64

The protocol accepts a feeCurrency transaction from any account, but something has to build that transaction. feeCurrency is a field on the CIP-64 transaction type, so the wallet signing it must implement CIP-64. Setting feeCurrency in your app is necessary but not sufficient: whether it takes effect is decided by the wallet your user brings.
A wallet without CIP-64 support does not honour feeCurrency, and nothing tells you so. Some wallets, MetaMask among them, drop the field and sign a standard transaction: gas then comes out of the user’s CELO balance, or, if the user holds no CELO, the transaction fails with a generic insufficient-funds error. A wallet that validates request parameters may instead reject the request outright. None of these outcomes points at the wallet as the cause.
A wallet not listed here has not been confirmed either way. Check with the wallet before assuming. If a flow depends on fee abstraction, such as onboarding a user who holds no CELO, either target a wallet on this list or keep a path that works when gas is charged in CELO. Library support is a separate question from wallet support, and a library in a wallet’s stack says nothing about whether that wallet forwards an app’s feeCurrency. For viem, Ethers.js and web3.js, see Using Fee Abstraction.

​
Fee currencies and adapters

The allowlist, with token and adapter addresses for each network, is on Fee currency contracts. Tokens with 6 decimals (USDC, USDT, USAâ‚®) go through an adapter, and the adapter address, not the token address, is the feeCurrency value; see adapters for non-18-decimal tokens.