Safe Wallet’s Fallback Handler: Exploiting Delegatecall Patterns and Securing Custom Implementations

Safe Wallet’s architecture enables powerful extensibility through its fallback handler mechanism, allowing developers to add custom logic without modifying the core multisignature wallet contract. However, the fallback handler operates through delegatecall, a pattern that introduces serious security risks if not implemented carefully. A developer deploying custom implementations must understand exactly which functions will be routed through delegatecall, how the execution context changes, and what invariants their custom code must preserve to avoid compromising the wallet’s multisig protections or enabling fund theft.

The fallback handler is not a design flaw—it is a deliberate trade-off between flexibility and risk. Properly implemented custom handlers can integrate DAOs with external protocols, enable conditional fund releases, or implement role-based spending limits without requiring a new wallet deployment. Improperly implemented handlers can silently bypass signature verification, corrupt wallet state, or execute transfers that appear authorized when they are not. The difference between a secure custom handler and a critical vulnerability often rests on details that are invisible in the user interface but determining in the bytecode.

How the fallback handler intercepts transaction execution

When a transaction reaches a Safe Wallet, the wallet’s executeTransaction function first validates signatures and nonces against the multisig threshold. If that validation passes, the transaction is executed directly within the wallet’s context. However, if a fallback handler is registered, any function call that does not match the wallet’s own interface is forwarded to the handler via delegatecall. This means the handler code executes as if it were part of the wallet itself, with access to the wallet’s storage, balance, and execution privileges.

The delegatecall mechanism is the foundation of the proxy pattern and enables contract upgradability, but it also means the handler inherits the wallet’s entire execution context. A handler function that calls selfdestruct, for example, would destroy the wallet, not the handler. A handler that modifies a wallet storage variable would corrupt state. A handler that executes a call to transfer assets would spend the wallet’s funds, not the handler’s. This context transfer is not a bug; it is how delegatecall works. The risk arises when a developer assumes normal function call isolation applies, or when the handler’s code contains logic that should not execute with wallet-level privileges.

Safe Wallet implements the fallback handler pattern through a low-level assembly mechanism. When a function call arrives that the wallet does not recognize, Solidity’s default fallback function is invoked. If a handler is set, the wallet executes a delegatecall to that handler’s address with the exact calldata that arrived. The handler must decode the call, execute the appropriate logic, and return data that the wallet will forward to the caller. If the handler reverts, the entire transaction reverts; if it succeeds, the caller receives the return data and the transaction state changes persist.

The separation between “wallet function” and “handler function” is therefore a semantic distinction enforced entirely by function selectors. If the wallet implements a function and the handler also implements a function with the same selector, the wallet’s version takes precedence because it matches first. If the wallet does not implement a selector, the fallback is invoked, and the handler is called. This design prevents the handler from accidentally overriding critical wallet functions such as execTransaction or addOwnerWithThreshold, but only if those functions are actually present in the wallet’s interface. A developer adding a custom handler must verify which selectors are already reserved.

The delegatecall context problem and state collision

Delegatecall executes code in the calling contract’s storage space, using the caller’s this reference and msg.sender identity. When a Safe Wallet delegatecalls its fallback handler, the handler sees msg.sender as the wallet itself, this as the wallet’s address, and storage slot 0, 1, 2, and so on as the wallet’s own storage variables. This is powerful because the handler can read and modify wallet state directly. It is also dangerous because the handler is responsible for preserving all wallet invariants while doing so.

The most common state collision occurs when a handler declares its own state variables without understanding what storage slots the wallet already occupies. A Safe Wallet stores owner lists, thresholds, nonces, and other critical data in specific storage positions. A handler that declares a mapping or array in its own contract definition will occupy the next available slot from the handler’s perspective, but when delegatecall executes, that slot corresponds to part of the wallet’s reserved space. Writing to what the handler thinks is its local variable may actually overwrite a wallet owner address or the signature threshold. The wallet will continue to function until the corrupted storage is accessed, at which point authentication may fail or unexpected behavior may occur.

Preventing this collision requires either of two approaches. First, a handler can avoid declaring storage variables entirely and instead use only local variables, function arguments, and return values. This eliminates the risk of accidental slot collision because no new storage is introduced. Second, a handler can be designed as a standalone contract that does not use delegatecall itself, and the wallet can call it normally. That function call style means the handler’s code runs in its own context, and state is not shared. The fallback handler pattern itself becomes unnecessary for the handler to work; it is instead used only to avoid matching one of the wallet’s own functions.

A practical example illustrates the risk. A developer implements a custom spending limit handler that tracks cumulative transfers per day. They declare uint256 spentToday as a state variable, intending to reset it daily. If the handler’s contract is compiled first and spentToday takes storage slot 0, but the wallet’s owners list is also at slot 0, writing to spentToday will corrupt the owners array. The wallet will appear to lose all owners, and future transactions will fail at the signature check. This kind of corruption is silent because the delegatecall succeeds; the failure only appears when the wallet tries to use the corrupted data.

Securing delegatecall with inline assembly and storage layout verification

The most robust pattern for a fallback handler is to avoid relying on contract-level state variables altogether. Instead, developers can use inline assembly to read and write storage slots by absolute position. This requires precise knowledge of which slots the wallet reserves, but it eliminates ambiguity. Solidity’s high-level storage declarations are convenient but dangerous in delegatecall contexts because they abstract away the actual slot numbers, making it easy to assume isolation that does not exist.

Safe Wallet’s storage layout is publicly documented. The wallet stores owners in a linked list structure, with specific slots reserved for the owner mapping, the owner count, and other data structures. A handler implementation can read this data directly using assembly load operations and avoid declaring any variables that would collide. For example, a handler that validates that a specific address is an owner of the wallet can compute the exact storage slot of the owner mapping and read from it using assembly, verifying ownership without modifying state.

To further secure custom implementations, developers should employ explicit storage layout comments and validate the layout during testing. Many teams use Hardhat’s storage layout plugin to generate a record of which slots are occupied by the main wallet and by the handler separately, then verify that the layouts do not overlap when the handler is used with the wallet. This is not a one-time check; it should be part of the test suite and run whenever contract code is modified.

An alternative pattern is to use a separate storage contract that holds handler-specific state. The wallet can interact with this contract normally via call, not delegatecall, and the storage is isolated. The handler then becomes a thin forwarding layer that reads from the wallet via delegatecall and writes to the storage contract via call. This design trades some efficiency for clarity: the separation of concerns is explicit in the code, and storage collisions become impossible because the storage contract uses its own independent slots.

Function selector collision and masking attacks

A second critical risk in fallback handler design is function selector collision. Solidity function selectors are computed as the first 4 bytes of the Keccak256 hash of the function signature. Two different functions can theoretically produce the same selector—this is called a collision—and while natural collisions are extremely rare, they can be artificially engineered. A developer might deliberately create a handler function with a selector matching a real wallet function, intending to intercept calls.

Safe Wallet defends against this by checking whether the wallet itself implements a given function before invoking the fallback handler. A function that the wallet implements directly will always execute the wallet’s version, not the handler’s. However, this protection only works if the wallet’s function actually exists in the compiled bytecode. If a developer deploys a modified wallet or if a wallet upgrade removes a function, the fallback handler becomes reachable for that selector. Additionally, if an attacker can somehow influence which handler is registered on the wallet, they can register a malicious handler that implements functions matching wallet selectors, though this would require control of the multisig itself.

A more subtle attack occurs when a handler implements a function with a selector that matches a legitimate DeFi protocol function that the wallet calls. Imagine a handler that implements the function approve(address, uint256) with the same selector as the ERC-20 approve function. If the wallet’s owner calls execTransaction to approve an ERC-20 token for spending, the transaction data will include the approve selector. If that transaction is routed through the handler instead of being executed directly, the handler’s approve function could be called instead of the ERC-20 token’s approve, allowing the handler to manipulate what the wallet approves. This is a redirected call attack, not a selector collision in the traditional sense, but it demonstrates the risk of function overlap.

Mitigating this risk requires explicit whitelisting or function routing logic. A handler should validate that the function selector it receives is one it is designed to handle, and it should reject unexpected selectors rather than processing them. Using a switch statement or selector mapping to route only known functions is more secure than a catch-all fallback within the handler. Furthermore, developers should avoid implementing function signatures that are commonly used in the DeFi ecosystem unless they are deliberately providing ERC-20 or other standard compliance.

Signature bypass and msg.sender context confusion

One of the most dangerous misconceptions in fallback handler design is that delegatecall automatically provides signature verification. It does not. Signature verification happens before the fallback handler is called. Once a transaction has passed the multisig check, any code the handler executes runs with that verification complete. This is by design: the handler is trusted because the wallet’s owners approved adding it, and the transaction was approved by the multisig threshold.

However, this opens a subtle vulnerability. If a handler receives function calls not through the wallet’s executeTransaction mechanism but directly from external callers, the handler executes without signature verification. For example, if a handler implements a function that is also valid for direct external calls—such as a public function that accepts parameters—an attacker could call the handler directly and bypass multisig approval. The handler would execute in the wallet’s context via delegatecall only when called through the wallet’s fallback mechanism. Direct calls to the handler go to the handler’s own code in the handler’s context, not delegatecall.

This distinction is critical and often misunderstood. When called through the wallet’s fallback, the handler executes via delegatecall and modifies wallet state. When called directly, the handler code runs in the handler’s context with the handler’s own storage. A developer can exploit this by ensuring that only the delegatecall path performs sensitive operations. A public function on the handler that is also accessible via direct call should revert if called outside the delegatecall context. This can be checked using assembly to compare the caller’s address with the expected wallet address, or by using an internal library that the handler calls through delegatecall.

Users logging in through Safe Wallet login interfaces should be aware that custom handlers introduce new trust assumptions. The wallet’s security model still depends on multisig approval, but it also now depends on the handler code being correctly implemented and not containing backdoors. A malicious handler could extract funds by encoding approval functions as fallback targets. This is why institutional users and DAOs should audit custom handlers the same way they audit other smart contracts before enabling them.

Testing, auditing, and post-deployment monitoring

Deploying a custom fallback handler requires testing at multiple levels. Unit tests should verify that the handler computes the correct results for all expected inputs. Integration tests should deploy both the wallet and the handler, register the handler, and then call it through the wallet’s fallback mechanism to confirm the delegatecall execution path works as intended. State tests should verify that the handler does not corrupt wallet storage after multiple transactions.

A critical test case is the storage layout check. Before deployment, run the Hardhat storage layout report for both the wallet and the handler, and manually verify that no slots overlap. If the handler uses inline assembly for storage access, verify the exact slot numbers against the wallet’s documented layout. After any code change, rerun this test to ensure the change did not introduce collisions.

Another essential test is the direct call test. Call the handler’s functions directly (not through the wallet’s fallback) and verify that sensitive operations revert. If a handler implements withdrawFunds, calling withdrawFunds directly on the handler should fail, either because the function does not exist on the handler as a separate callable interface, or because it checks msg.sender and reverts when called outside the wallet context.

Post-deployment monitoring should track which functions are called through the handler and what state changes occur. Wallets should emit events when the fallback handler is invoked, and developers should log all state modifications. This creates an audit trail that can be reviewed if unexpected behavior occurs. If a handler is suspected of being compromised, a multisig transaction can replace it with a new handler or disable it entirely, but catching the compromise early prevents fund loss.

Multi-handler coordination and cascading fallback risks

Some advanced wallet implementations use multiple fallback handlers or chain handlers together. One handler might implement DeFi routing, another might implement spending limits, and a third might implement governance integrations. Chaining multiple handlers introduces additional risk because each handler must correctly delegate to the next one without corrupting state, and the order of execution becomes significant.

If handler A calls into handler B via delegatecall, both handlers are executing in the wallet’s context, and both are modifying the same storage. If handler A expects to write to certain slots that handler B also expects to use, the result is corruption. Additionally, if handler A reverts, the entire transaction reverts, so partial execution is not possible. Developers coordinating multiple handlers must explicitly document which storage slots each handler uses and ensure no overlap.

A safer pattern is to avoid cascading delegatecalls. Instead, the primary handler can use normal function calls (not delegatecall) to secondary handlers, keeping those in separate contexts. The primary handler then aggregates results and executes delegatecall-sensitive operations itself. This requires more code in the primary handler but provides isolation and clearer state management.

Future protocol considerations and handler upgradability

As EVM chains evolve, new opcodes and execution models will affect fallback handler design. Account abstraction proposals and changes to msg.sender semantics could alter how delegatecall context works. Developers implementing handlers should design with future compatibility in mind. Avoid relying on specific gas costs or execution model details that might change. Use well-documented patterns that other developers can verify and audit.

Handler upgradability is another consideration. A fallback handler can be replaced by the wallet’s owners through a multisig transaction, but users and DAOs should have a clear process for auditing a new handler before enabling it. The new handler should be deployed to a testnet, tested thoroughly, and reviewed by independent security experts before being activated on mainnet. A governance process that includes a timelock allows stakeholders to review and exit before a handler change takes effect.