Gas estimation producing 20x oversized limits (4.18% efficiency)

[moonshot-cyber]

I analyzed agent wallets using the DeleGator framework on Base and found extremely low gas efficiency of just 4.18%.

Example wallet: 0x464fc339add314932920d3e060745bd7ea3e92ad

Findings:

• 258 failed transactions (all reverted, 0 out-of-gas)
• Average gas limit set: ~20x higher than actual gas used
• Estimated monthly waste: $71.35 per agent
• Gas efficiency: 4.18% (meaning 95.82% of allocated gas goes unused)

Expected behavior:
Gas limits should be closer to actual usage (targeting 70-90% efficiency range)

Actual behavior:
Gas limits appear to be massively over-estimated, causing users to lock up unnecessary capital and potentially pay higher priority fees.

Impact:
Agents using this framework are wasting significant funds on oversized gas allocations.

Is this a known issue with the gas estimation logic in EIP-7702 proxy implementations?

[MoMannn]

Can you give a bit more information? If a transaction fails its quite logical that only some gas is used instead of all allocated. Also gas limits are something that is set by the transaction maker and does not have anything to do with the framework itself. Are you sure your bot is not the one incorrectly setting gas? From what I can see from that wallet gas for any transaction is set to 5million. You can use estimate gas call to get the correct estimation and also to figure out if the transaction will fail before being submitted. This looks like more of a problem of bot doing inefficient work.

[Samdevrel]

Adding some context since I've been tracking AI agent wallets using ERC-7702/7710:

@MoMannn is right that this looks like a bot configuration issue rather than a framework problem. A few things I've seen in the wild:

Why agents over-estimate gas:

1. Many agents use a "safe" multiplier (2-3x estimated gas) to avoid failed txs
2. Some agents hardcode gas limits (the 5M you noted) instead of using estimateGas
3. Batch transactions through DeleGator can have variable gas depending on the delegation chain

What actually works:

• Use estimateGas per-transaction, then add a 20-30% buffer (not 20x)
• For DeleGator specifically, simulate the full execution path before submitting
• Track gas used vs gas limit and adjust dynamically

The 258 failed txs is the real issue — the agent is submitting transactions that revert, which suggests it's not validating delegation permissions or target state before submission. This is independent of gas estimation.

Happy to dig into specific delegation patterns if you can share what operations the agent is attempting. The DeleGator framework itself handles gas correctly; it's the agent's submission logic that needs work. 🔮

[noraimanbinjamain950-cpu]

.

[MoMannn]

Closing this issue, since no additional data and it does not seem an actual issue with the framework.