Smart account bridge signing: how the source-chain approval works

An ERC-4337 smart account authorizes a bridge on the source chain by signing a UserOperation that contains the route call and any required token approval. The operation is sent to a bundler, which simulates it before an EntryPoint validates and executes it on that chain.

The bridge quote describes a route; it does not itself move funds or authorize the account. For a practical overview of quotes, approvals and transaction building, see this fuller guide to the bungee bridge. In an integration, use the selected route’s transaction data as the call the smart account is being asked to make.

What does the smart account sign?

With ERC-4337, the account signs a UserOperation hash that covers the operation fields, EntryPoint address and chain ID, as specified by the standard. The account’s validation code checks the signature and nonce; the signature format and policy depend on the account implementation.

For a bridge, the operation’s call data typically instructs the account to call a source-chain router. If the input is an ERC-20 token, that call may need an allowance first. An account that supports batching can place approval and route execution in one UserOperation; otherwise, the approval must be confirmed before the bridge operation can proceed.

Keep the bridge authorization distinct from account setup. On chains using EIP-7702, a wallet may also provide an authorization that delegates code to an EOA, but that authorizes code delegation; it does not approve a bridge transfer. A UserOperation signature and an EIP-7702 authorization protect different actions.

How should an integration build the operation?

Build the operation from the chosen route and the smart account’s source-chain address. Bungee’s manual integration flow separates requesting a quote, selecting a route, building transaction data, checking any required allowance and executing the transaction; an ERC-4337 integration must adapt execution to the account and bundler it supports.

• Request route data for the source chain, destination chain, input token, amount and intended recipient.
• Check the returned approval requirement and spender; request only the allowance needed for the chosen route where the token and wallet support it.
• Encode the approval and router call as one operation if the account supports batching, or submit them as separate operations in order.
• Estimate gas and fees, then collect the account signature and any required paymaster data before sending the UserOperation to a compatible bundler.

A paymaster can cover the operation’s gas under its own rules, but sponsorship does not change what the account call authorizes. The EntryPoint validates the account and, if present, the paymaster before it executes the call data. Bundlers simulate operations before inclusion, so a bad nonce, signature, gas estimate or allowance can stop execution before the bridge call runs.

What should the wallet verify before signing?

The wallet should show the source network, token and amount, destination network, recipient, quoted output and any fee before asking for a signature. It should decode the router target and approval spender where possible, because the UserOperation signature authorizes the encoded calls rather than a plain-language bridge request.

The destination transfer is a separate stage: the source-chain operation starts the route, while delivery follows the bridge route’s own execution process. Do not treat source transaction inclusion as proof that the destination asset has arrived; track the source transaction and the route’s status until delivery is reported.

For most integrations, keep account validation, bridge execution and destination tracking as separate steps in the product flow. The next actions are to test the selected account implementation’s batching and paymaster behavior on the source chain, then confirm that the bridge route reports the expected recipient and completion state.