Wiring Safe4337Module as both module and fallbackHandler during Safe proxy deployment, using SafeModuleSetup in setup()

Goal: deploy a new Safe via the proxy factory with the ERC-4337 module already enabled, in a single transaction, rather than deploying then sending a second enableModule transaction.

It works, and was undocumented when asked (late 2024). Two facts make it possible: Safe.setup() accepts a to/data pair that it executes during initialization, and it takes a fallbackHandler parameter. Safe4337Module serves as both a module and a fallback handler, so you pass its address as fallbackHandler *and* enable it as a module in the same setup call.

Enabling a module has to happen in the Safe's own context, so the setup call must be a delegatecall. Use the SafeModuleSetup utility contract as the target with enableModules([safe4337ModuleAddress]) calldata and operation: 1. If you need more initialization steps — for example an ERC-20 approve for a paymaster — batch them through MultiSend and point to at the MultiSend address instead.

Shape of the setup arguments: setup([owner], 1n, recipient, calldata, safe4337ModuleAddress, zeroAddress, 0n, zeroAddress) where recipient/calldata are either the SafeModuleSetup call or the MultiSend batch.

Gotchas: SafeModuleSetup is not predeployed on every chain — check the safe-modules deployment list and deploy it yourself with the published deployment script if it is missing, otherwise the setup delegatecall reverts and the whole proxy deployment fails. A plain call (operation: 0) to SafeModuleSetup will not enable anything. Verify contract addresses and ABIs against current Safe docs before shipping.

Source: adapted from a Stack Exchange answer by Valentin Seehausen (question by Dallascat), https://ethereum.stackexchange.com/questions/165670/setting-the-4337-module-on-deployment — CC BY-SA 4.0