feat: add erc20 to 7677 middleware

[andysim3d]

Pull Request Checklist

• Did you add new tests and confirm existing tests pass? (yarn test)
• Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
• Do your commits follow the Conventional Commits standard?
• Does your PR title also follow the Conventional Commits standard?
• If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
• Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
• Did you follow the contribution guidelines?

---

PR-Codex overview

This PR introduces a new PolicyToken type and integrates it into the erc7677Middleware. It enhances the middleware to support ERC-20 paymaster interactions, allowing for token-based fee payments in user operations.

Detailed summary

• Added PolicyToken type with properties: tokenAddress, approvalMode, maxTokenAmount, erc20Name, and version.
• Updated ClientMiddlewareArgs to include policyToken.
• Enhanced erc7677Middleware to calculate token amounts based on gas fees and policyToken.
• Implemented logic for requesting token conversion rates and creating permit data for ERC-20 tokens.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
aa-sdk-site	❌ Failed (Inspect)			Apr 25, 2025 7:55pm
aa-sdk-ui-demo	❌ Failed (Inspect)			Apr 25, 2025 7:55pm

[jakehobbs]

this may be of use to you (if this is used to convert eth to wei): https://viem.sh/docs/utilities/parseEther.html

[dphilipson]

Also if you do need a constant, TypeScript convention is upper snake-case, e.g. ETH_2_WEI, although I would probably name this something like WEI_PER_ETH which is a big more specific.

[jakehobbs]

nit (style): we normally camel case variable names in ts

[dphilipson]

(Nit) If this variable is always going to be assigned to later, then don't initialize it with an assignment. Instead do

let paymasterAddress: Hex;

This has two advantages:

• It gives it the more narrow type Hex instead of string, meaning it would be a type error if we accidentally assign a non-hex value to it later.
• It makes it a type error if we forget to assign to it in one of the branches below.

[dphilipson]

Just to reiterate: uo is not a UserOperationStruct<"0.7.0">, it is a PromiseOrValue<UserOperationStruct<"0.7.0">>. You should read from userOp instead.

[dphilipson]

Do we not need to update total_gas in this branch?

[dphilipson]

Also if you do need a constant, TypeScript convention is upper snake-case, e.g. ETH_2_WEI, although I would probably name this something like WEI_PER_ETH which is a big more specific.

[dphilipson]

(Nit) Can write this as context.erc20Context.

[dphilipson]

Looks unused. (Ignore if you just haven't written the part that uses it yet).

[moldy530]

does erc7677 define how erc20 should be handled or is the logic in this file specific to alchemy?

[moldy530]

if this isn't to a specific spec (it doesn't look like it since it looks similar to the logic for alchemy_requestGasAndPaymasterAndData), then we shouldn't it in here. Instead we should put it just in gasManager.ts in account-kit/infra

[moldy530]

regarding my comment about the logic in aa-sdk/core. I think that logic should go within the alchemyGasManagerMiddleware.

you can leverage the base middleware:

erc7677Middleware<{ policyId: string | string[] }>({
    context: { policyId: policyId },
  })

to make calls to the RPC and do all of the 7677 stuff, but since you also need to sign permit data based on mode you'll likely have to wrap the middleware here.

likely something like:

export function alchemyGasManagerMiddleware(
  policyId: string | string[]
): Pick<ClientMiddlewareConfig, "dummyPaymasterAndData" | "paymasterAndData"> {
  const baseMiddleware = erc7677Middleware<{ policyId: string | string[] }>({
    context: { policyId: policyId },
  });
  // don't actually do this with ...middlewareParams it's just cuz I'm being too lazy to scroll to what should actually be here
  return {
    dummyPaymasterAndData: (...args) => {
      // if you need custom logic, do it here and at some point use:
      baseMiddleware.dummyPaymasterAndData(...args);
    },
    paymasterAndData: (...args) => {
      // do your custom logic, call baseMiddleware.paymasterAndData(...args), do other custom logic, return result
    }
  }
}

[moldy530]

How much of this logic is the same as what's in the alchemyRequestGasAndPaymasterData middleware? Since we have to move the code in aa-sdk/core into account-kit/infra anyways, then we should just share as much of the code as we can

[moldy530]

Also, how are we testing this?