Arc-native gas

Documentation Index

Fetch the complete documentation index at: https://docs.usecompassai.com/llms.txt

Use this file to discover all available pages before exploring further.

On Arc, USDC pays for gas directly. Compass UserOps on Arc need no paymaster, no second-token balance, and no swap workaround. On other supported chains, a paymaster bridges the gap — and one specific step in the cross-chain pipeline goes around it entirely.

This page covers the gas model Compass uses across chains. For the cross-chain pipeline that’s affected by it, see Four-step pipeline.

​

The two-token problem on other EVMs

The usual EVM gas model creates an awkward situation for any account that holds one token and needs another for gas:

1. The user (or agent) holds USDC for yield.
2. Every transaction requires the chain’s native gas token (typically ETH on most L2s).
3. So the account needs a parallel ETH balance to keep functioning.
4. Or it needs an on-chain swap path to convert USDC to ETH when low.
5. Or it relies on a paymaster contract to sponsor gas and reimburse itself from the account’s USDC.

For an autonomous agent that rebalances often, options 1–4 are all operationally painful. Option 5 — the ERC-4337 paymaster — is the standard fix on chains where USDC isn’t native gas.

​

Arc removes the problem

Arc treats USDC as a native gas token. Transactions on Arc denominate gas in USDC directly. For Compass UserOps on Arc:

• paymasterAndData on the UserOp is empty.
• The ERC-4337 EntryPoint deducts gas from the sender Diamond’s USDC balance.
• No paymaster contract sits in the path.
• No second-token balance to manage.

This is a real reduction in moving parts, not a cosmetic one. The deterministic loop doesn’t have to model an ETH balance, the executor doesn’t have to detect “low on gas, swap first,” and there’s no path where USDC sits idle because the gas float is empty.

​

What this looks like per chain

On non-Arc chains, the paymaster is what restores the “one token to hold” property — from the user’s perspective, the Diamond still only needs USDC. The paymaster handles the gas-token leg internally.

​

The one step paymasters can’t cover

There is one specific situation where even a paymaster won’t work: step 3 of the cross-chain pipeline — the gatewayMint call on the destination chain. At the moment of that call, the destination Diamond has zero USDC. It is about to receive USDC from the mint. A paymaster contract would sponsor the gas, but there is nothing to reimburse it from post-execution. Compass handles this by making gatewayMint an EOA transaction from the session key directly, not a UserOp. The session key holds a small native-gas float on each non-Arc destination chain specifically for these mint calls. A few properties of this setup:

• The float is small — a single gatewayMint is cheap, and the session key only does this when a route lands on that chain.
• The float is the session key’s, not the user’s. Users never have to manage gas tokens on any chain.
• After the mint settles, step 4 (the actual venue call) goes through the Diamond + paymaster as normal.
• Arc destinations skip this entirely — gatewayMint on Arc pays its gas in USDC just like any other call, so the same step uses a UserOp.

​

Why this matters for the architecture

The “agent only needs one token” property isn’t unique to Compass — plenty of paymaster-based account systems offer it. What Arc adds is the ability to deliver that property with no paymaster trust assumption at all for the chain Compass calls home. For everything that happens on Arc — account deployment, policy updates, session-key registration, position management when the position lives on Arc — there is no intermediary contract sponsoring gas. The Diamond pays its own gas in the same token it holds. This is the simplest possible shape for an ERC-4337 account, and Arc is what makes it possible. The cross-chain steps still need paymasters for the non-Arc legs. That’s a chain property, not a Compass property — until other chains adopt native stablecoin gas, the paymaster workaround stays.

​

Next steps