ERC-4337 Smart Account Swap

For smart wallets using the ERC-4337 standard (Pimlico, ZeroDev, etc.). The routing step is identical to the EOA flow — use POST /routing/scan/stream (see Find a Route). The difference is in the /tx/create request and response.

Four gas payment modes are available:

  • Mode A -- ERC-20 paymaster: gas is paid in an ERC-20 token (e.g. USDC) via the CrossCurve Pimlico proxy.

  • Mode B -- Sponsored / custom paymaster: your own verifying paymaster sponsors gas.

  • Mode C -- Native gas: no paymaster; the smart wallet pays gas in the native token directly.

  • Mode D -- Calldata only: raw calldata returned; integrator builds their own UserOperation and manages approvals.

The smart wallet address (from) must already be deployed on the source chain. If the contract is not deployed, the server returns a 400 NOT_SMART_ACCOUNT error.

Request Fields

The request body uses the same base fields as EOA (from, recipient, routing) plus these AA-specific fields:

Field
Type
Required
Description

walletType

string

Yes

"4337"

gasToken

string

No

ERC-20 token address for gas payment via paymaster

paymasterAddress

string

No

Custom paymaster contract address

entryPoint

string

No

Custom EntryPoint contract address

calldataOnly

boolean

No

Return raw calldata without calls[] wrapper

Do not include buildCalldata -- it is ignored for AA wallets.

Mode A -- ERC-20 Paymaster

Gas is paid in an ERC-20 token through CrossCurve's Pimlico paymaster. The response includes a pimlicoChainName used to route subsequent bundler and paymaster calls through the /pimlico/{chainName} proxy endpoint.

Request:

Response:

Response fields:

Field
Type
Description

walletType

"4337"

Wallet type echo

calls

array

Ordered calls for the UserOperation (see below)

chainId

number

Source chain ID

pimlicoChainName

string

Chain name for the /pimlico/{chainName} proxy

paymasterContext

object

Contains token -- the ERC-20 address used for gas payment

paymasterAddress

string

Paymaster contract address (present in ERC-20 and sponsored modes)

entryPoint

string

EntryPoint contract address (present in ERC-20 and sponsored modes)

Each item in calls has:

Field
Type
Description

to

string

Target contract address

value

string

Native token value (wei)

data

string

Encoded calldata

The three calls in order:

  1. Paymaster token approve -- approves the paymaster to spend the gas token.

  2. Router token approve -- approves the router to spend the input token.

  3. Router start -- calls router.start() to initiate the swap.

Full flow (10 steps):

  1. POST /routing/scan/stream -- find a route (see EOA Step 2).

  2. POST /tx/create with walletType: "4337" and gasToken -- receive calls, pimlicoChainName, paymasterContext, paymasterAddress, entryPoint.

  3. POST /pimlico/{pimlicoChainName} -- call pimlico_getUserOperationGasPrice to get gas prices.

  4. Build a UserOperation from calls. Set maxFeePerGas and maxPriorityFeePerGas from step 3.

  5. POST /pimlico/{pimlicoChainName} -- call pm_getPaymasterStubData to get stub data for gas estimation.

  6. POST /pimlico/{pimlicoChainName} -- call eth_estimateUserOperationGas to fill gas limits.

  7. POST /pimlico/{pimlicoChainName} -- call pm_getPaymasterData to get final paymaster data.

  8. Sign the UserOperation.

  9. POST /pimlico/{pimlicoChainName} -- call eth_sendUserOperation to submit.

  10. Poll with eth_getUserOperationReceipt via POST /pimlico/{pimlicoChainName} until the operation is confirmed.

Full Example (JavaScript)

Full Example (TypeScript + permissionless)

Mode B -- Sponsored / Custom Paymaster

Your own verifying paymaster sponsors gas. No gasToken is needed.

Request:

Response:

Key differences from Mode A:

  • 2 calls instead of 3 -- no paymaster token approve (your paymaster sponsors gas).

  • pimlicoChainName is absent -- the Pimlico proxy is not needed.

  • paymasterContext.token is the zero address.

  • The integrator manages their own paymaster and bundler infrastructure.

Example (JavaScript)

Mode C -- Native Gas

No paymaster is used. The smart wallet pays gas in the native token directly, the same way an EOA would.

Request:

Response:

Key differences:

  • 2 calls -- router approve and router start.

  • value on the router start call may be non-zero.

  • pimlicoChainName, paymasterAddress, and entryPoint are absent.

  • paymasterContext.token is the zero address.

  • No paymaster is involved -- the smart wallet pays gas in the native token.

Estimate gas and submit the UserOperation through your own bundler or node.

Mode D -- Calldata Only

For integrators with their own AA infrastructure who want raw calldata without the calls[] wrapper. The integrator builds their own approve calls, UserOperation, and paymaster interactions.

Request:

Response:

Response fields:

Field
Type
Description

calldataOnly

true

Indicates calldata-only mode

to

string

Router contract address

data

string

Encoded calldata for router.start()

value

string

Native token value (wei)

feeToken

string

Token address for fee payment (zero address for native token)

executionPrice

string

Delivery fee amount in feeToken units

chainId

number

Source chain ID

The integrator is responsible for:

  • Building approve calls (if feeToken is an ERC-20, approve the router for amountIn + executionPrice).

  • Constructing the full UserOperation.

  • Managing paymaster interactions (if any).

  • Submitting through their own bundler.


EIP-7702 Swap

For EOA wallets with EIP-7702 code delegation. The EOA temporarily gains smart account functionality for the duration of the operation, without needing a separate smart wallet contract.

Key differences from ERC-4337:

  • walletType is "7702" instead of "4337".

  • The sender address in the UserOperation is the EOA itself, not a separate smart account.

  • Requires an EIP-7702 authorization signature for code delegation.

  • Uses EntryPoint v0.8 (ERC-4337 uses v0.6).

The same gas payment modes are available as ERC-4337: ERC-20 paymaster, sponsored/custom paymaster, and native gas. The response shape is identical -- see the ERC-4337 response fields for field descriptions.

Request

The request body uses the same fields as ERC-4337 with walletType set to "7702".

ERC-20 paymaster mode:

Native gas mode (no paymaster):

Response

Same shape as ERC-4337 but with walletType: "7702":

Full Flow (ERC-20 Paymaster)

  1. POST /routing/scan/stream -- find a route (see EOA Step 2).

  2. POST /tx/create with walletType: "7702" and gasToken -- receive calls, pimlicoChainName, paymasterContext, paymasterAddress, entryPoint.

  3. POST /pimlico/{pimlicoChainName} -- call pimlico_getUserOperationGasPrice to get gas prices.

  4. Sign an EIP-7702 authorization for code delegation to the Smart7702 implementation.

  5. Build a UserOperation with the authorization. Set maxFeePerGas and maxPriorityFeePerGas from step 3.

  6. POST /pimlico/{pimlicoChainName} -- call pm_getPaymasterStubData to get stub data for gas estimation.

  7. POST /pimlico/{pimlicoChainName} -- call eth_estimateUserOperationGas to fill gas limits.

  8. POST /pimlico/{pimlicoChainName} -- call pm_getPaymasterData to get final paymaster data.

  9. Sign and send the UserOperation via POST /pimlico/{pimlicoChainName} using eth_sendUserOperation.

Full Flow (Native Gas)

  1. POST /routing/scan/stream -- find a route (see EOA Step 2).

  2. POST /tx/create with walletType: "7702" (no gasToken) -- receive calls.

  3. Sign an EIP-7702 authorization for code delegation.

  4. Build a UserOperation from calls.

  5. Estimate gas, sign, and send. No paymaster is needed -- the EOA pays gas in the native token.

Full Example (JavaScript, ERC-20 Paymaster)

This example shows the 7702-specific authorization step. See the ERC-4337 example for the pimlicoRpc helper and common patterns.


Pimlico Proxy

JSON-RPC 2.0 proxy for account abstraction bundler and paymaster operations. Routes requests to the Pimlico infrastructure through the CrossCurve API.

{chainName} is the chain identifier from the pimlicoChainName field in the /tx/create response (e.g. sepolia, sonic-testnet).

Request Format

Headers:

Header
Value

Content-Type

application/json

api-key

YOUR_API_KEY

Allowed Methods

Method
Description

eth_sendUserOperation

Submit a UserOperation

eth_estimateUserOperationGas

Estimate gas for a UserOperation

eth_getUserOperationReceipt

Get receipt by UserOperation hash

eth_getUserOperationByHash

Get UserOperation by hash

eth_supportedEntryPoints

List supported EntryPoint addresses

pm_getPaymasterData

Get paymaster data for gas sponsoring

pm_getPaymasterStubData

Get stub data for gas estimation

pm_supportedTokens

List tokens available for gas payment

pimlico_getUserOperationGasPrice

Get recommended gas prices

pimlico_getTokenQuotes

Get token quotes for paymaster

Any method not in this list returns a 400 error.

Limits

Constraint
Value

Rate limit

60 requests per minute per IP

Max payload

50 KB

Timeout

15 seconds

Batch JSON-RPC

Not supported

For eth_sendUserOperation and eth_estimateUserOperationGas, the EntryPoint address passed in params[1] must match one of the EntryPoint addresses configured for the chain.

Example -- Reusable Helper (JavaScript)


Last updated