🔓Vulnerability of Design Preventing EIP-165 Extensibility

When designing smart contract wallets, it’s crucial to ensure flexibility and adaptability, especially in the context of supporting new interfaces as standards evolve. EIP-165 provides a standard method for contracts to signal support for interfaces, which allows for easy detection of a contract’s capabilities by external protocols. However, if a wallet’s fallback mechanism is not properly designed, it can block the extensibility of EIP-165, making it impossible to extend or add support for new interfaces.

This tutorial will explain how the improper handling of fallback mechanisms can limit the extensibility of EIP-165, preventing future support for new standards, and how to properly implement a solution that ensures dynamic extensibility without redeploying the wallet.

---

Understanding EIP-165 and Fallback Handlers

EIP-165 introduces the supportsInterface function, which allows a contract to declare the interfaces it supports, such as ERC721 or ERC1155, making it easier for other contracts to detect what functionality a given contract has. This function follows a simple format:

function supportsInterface(bytes4 interfaceID) external view returns (bool);

Smart contracts often use fallback handlers to extend functionality. These fallback mechanisms allow contracts to delegate calls that are not explicitly defined in the main contract to an external fallback handler. This pattern allows for dynamic functionality, enabling wallets to be flexible and extensible.

However, there is a key limitation: when a function (such as supportsInterface) is defined in the main contract, calls to this function will not be forwarded to the fallback. This makes it impossible to override or extend certain functionalities—such as supporting new interfaces through EIP-165—without redeploying the contract.

Vulnerability: Wallet Design Prevents EIP-165 Extensibility

In a typical wallet design that uses fallback handlers, any function defined in the main wallet contract, such as supportsInterface, will always be handled by the main contract and not passed to the fallback. As a result, the fallback handler cannot dynamically extend or override the supportsInterface functionality.

This means that:

1. New Interfaces Cannot Be Added: Once the wallet is deployed, it will only support the interfaces defined at that point. Any future interfaces or standards that require EIP-165 detection will be unsupported unless the wallet is redeployed.

2. Inflexibility for Upgrades: The wallet is locked into the functionality defined at deployment. Any attempt to extend or upgrade support for new interfaces through the fallback will fail because the calls will be caught by the main contract.

Impact

• Limited Functionality: The wallet is constrained to the interfaces it supports at the time of deployment, making it inflexible for future upgrades.

• Incompatibility with Future Standards: If a new interface standard (like an upgrade to ERC721 or a completely new interface) becomes necessary, the wallet will not be able to signal support for it dynamically, limiting its compatibility with evolving systems.

• Missed Extensibility: Without being able to extend the functionality via a fallback, the wallet cannot benefit from the dynamic upgrades that a proper fallback mechanism provides.

example: https://github.com/code-423n4/2023-06-ambire-mitigation-findings/issues/21