Automating USDC Gas Fee Payments on Base via ICP Canister

Developers
1

I’ve successfully implemented USDC transactions on Base derived from Internet Identity on ICP, and I can currently approve gas fees manually.

The next step I’d like to achieve is:

  • The canister itself covers the gas fee in ETH on Base automatically,

  • So that transactions execute seamlessly,

  • And the user only enters the USDC amount (without needing to worry about gas).

:backhand_index_pointing_right: My main questions:

  1. Has anyone implemented a similar architecture where an ICP canister pays the gas fees on behalf of the user on base?

  2. What’s the best approach to allow an ICP canister to hold ETH (on Base) and automatically use it to cover gas costs?

  3. Has anyone integrated an EIP-2771 meta-transaction style relayer with ICP outcalls to an EVM chain?

  4. Are there recommended patterns for handling EIP-3009 / meta-transaction standards, signatures, ETH balance management, and security in this setup?

Any guidance, references, or examples from those who have explored this would be greatly appreciated.

5 Likes
2

many people are interested in this and this is not specific to Base, but rather a topic to be addressed for all EVM chains. it is discussed every once in a while :sweat_smile:

I haven’t seen any implementation of this yet, but I am also curious if somebody has taken a deeper look into this topic and can share experiences and findings.

I have talked to @hpeebles about this topic quite some time ago, not sure if he went further down the road.

cc @Manu @StefanBerger-DFINIT1

3 Likes
3

I’ve made significant progress with the implementation, but the two areas I’m still struggling with are:

  1. Gas estimation – even when slightly overpaying to push tx through.

  2. Consensus – reaching reliable agreement feels like a bottleneck.

Curious if anyone has found good patterns to address these.

1 Like
4

what exactly is the issue here? :thinking:

you are aware that the evm-rpc-canister provides a method to get the fee history, right? see Using the EVM RPC canister | Internet Computer

what is the issue here? can you elaborate on that?

1 Like
5

On the gas side: I know the evm-rpc-canister exposes fee history. My issue is slightly different: when I manually craft and sign a USDC transaction externally and broadcast it, I can overpay a little and it reliably goes through.

But when I try to do the same flow from the wallet canister itself, the canister has ETH balance but I don’t see how it can actually broadcast the signed transaction with the right gas parameters. Basically:

  • Externally → I can pay the fee from a hot wallet and submit → tx is mined.

  • From canister → it “has ETH”, but how do I actually push that signed tx out onto the network via the rpc canister?

So the gap for me is: how to go from “wallet canister holds ETH + has the tx data” → to “transaction gets propagated with the right gas and fee handling” without relying on an external broadcaster.

That’s the piece I’m trying to solve.

2 Likes
6

are you aware of these docs? Signing transactions | Internet Computer

there shouldn’t be much of a difference. you need to build a tx from the canister, sign it and broadcast it.

7

How does the onesec bridge do it? When I transfer stablecoins from one chain to another, I don’t need to have Ethereum

8

With onesec.to, the gas fees on Base is handled automatically, when you bridge USDC/ICP out of the IC. As opposed to ckUSDC, which requires you to hold ckETH at the time and can only bridge to Ethereum and not Base.

9

I went through the OneSec docs and saw how the flow works with threshold ECDSA signing on ICP + HTTP outcalls (and relayers) to broadcast raw transactions on the EVM side. I also noticed the emphasis on consensus across multiple RPCs for reliability.

What I’d love to understand more clearly is the gas abstraction piece you mentioned: when bridging to Base, how exactly is the transaction fee handled under the hood? From the docs I can see how signing and broadcasting are managed, but I didn’t see a detailed breakdown of whether this is done via pre-funded relayers, a fee-pool model, or some other standard.

10

There’s two ways onesec.to does fees sponsoring:

  • when bridging out, no need for ckETH, the gas fees is included in the fees when bridging and taken from the token you’re bridging out with
  • when bridging in, you can use onesec forwarding address, npm package, it derives an EVM address associated to your ICP principal, anything you send to this address gets forwarded to the IC, the gas fees is also sponsored and taken as a fee between your EVM forwarding address and the IC
4 Likes
11

I’ve successfully implemented automatic USDC transfers on Base via ICP, where the admin pays gas fees in ETH, making transfers seamless for users. Now, users only need to enter the USDC amount—they don’t worry about gas.

Key highlights:

:white_check_mark: Gasless user experience: Users can transfer USDC to others without paying gas.

:white_check_mark: EIP-3009 powered: Transfers use gasless authorization signatures for security and efficiency.

:white_check_mark: EIP-1559 prepared transactions: Admin covers ETH fees while transactions are prepared with EIP-1559 for smooth execution.

:white_check_mark: Admin sends gas to a payment master (a treasury canister): This ensures transaction costs are automatically covered.

:warning: Potential errors: If the payment master/treasury dries up and can’t cover gas, transactions will fail with an “insufficient funds” error.

:link: Example transaction: Base Transaction Hash: 0xfdbfe0ece4... | BaseScan

This setup combines ICP canisters, meta-transaction patterns, and gasless UX to deliver a seamless DeFi experience. The next step is expanding this pattern for more tokens and chains!

2 Likes
12

Thanks to Rachid and everyone else, this is now running on COOWN.box

1 Like