DEV Community

Cover image for When you jam a bug that no AI can solve for you...
Pesova Tech
Pesova Tech

Posted on

When you jam a bug that no AI can solve for you...

When you jam a bug that no AI can solve for you...

Spent hours debugging a gasless transaction flow using Dynamic.xyz + ZeroDev (ERC-4337 Account Abstraction). The goal was simple, let users withdraw ERC-20 tokens without ever touching ETH for gas. The Paymaster handles it. Clean UX. No seed phrases, no gas headaches.

Except it wasn't working.

Every UserOperation was getting rejected at the bundler (Pimlico) with:
AA21 didn't pay prefund

For anyone who's worked with ERC-4337, AA21 means the Paymaster either isn't set up, isn't funded, or isn't authorizing the transaction. Classic rabbit hole.

I checked everything:
ZeroDev Project ID - correct
Paymaster policy - active
Smart wallet factory - deploying correctly
kernelClient routing - UserOps going through the bundler

Still failing. Same ZeroDev project ID. Same chain (Base Sepolia). Same code.

Every AI model I threw this at suggested code changes. I made code changes for weeks. Nothing moved.

Then I noticed something, the exact same ZeroDev project ID worked perfectly on a different Dynamic environment. Same ID. Different Dynamic account. One works, one doesn't.

That narrowed it down fast. The issue wasn't ZeroDev at all. It was a misconfiguration inside the Dynamic environment itself, something in how that specific environment was initialized that caused the smart wallets it spawned to be unrecognizable to the Paymaster.

Fix: Created a fresh Dynamic environment, mirrored the settings from the working one, rewired the ZeroDev Project ID, everything worked first try.

Gasless transactions are a game changer for Web3 UX. But the infra stack (Dynamic -> ZeroDev-> Pimlico-> EntryPoint) has a lot of moving parts, and a misconfigured environment ID can silently break the entire sponsorship chain.

Top comments (0)