Abstract
The Router Proxy introduces a streamlined approach to managing multiple implementations behind a single proxy, similar to the Diamond Proxy Standard (ERC-2535 ). Unlike the latter, this method hardcodes module addresses within the proxy’s implementation contract, offering a simpler, more explicit, and gas-efficient mechanism. This design reduces complexity, making it easier to reason about and improving overall efficiency while retaining the flexibility to manage multiple modules.
ERC Pull Request
---
eip: 7771
title: Router Proxy
description: A Simple Proxies Architecture with Multiple Hardcoded Implementations
author: Alejandro Santander (@theethernaut), Noah Litvin (@noahlitvin)
discussions-to: https://ethereum-magicians.org/t/erc-7771-router-proxy/21137
status: Draft
type: Standards Track
category: ERC
created: 2024-09-19
---
## Abstract
The Router Proxy introduces a streamlined approach to managing multiple implementations behind a single proxy, similar to the Diamond Proxy Standard ([ERC-2535](./erc-2535.md)). Unlike the latter, this method hardcodes module addresses within the proxy’s implementation contract, offering a simpler, more explicit, and gas-efficient mechanism. This design reduces complexity, making it easier to reason about and improving overall efficiency while retaining the flexibility to manage multiple modules.
## Motivation
As Ethereum's application layer continues to mature, the complexity of smart contracts required for these applications has increased. Given the 24KB size limitation for a single smart contract, developers often need to compose applications using multiple interconnected contracts. This necessitates the use of an onchain registry to manage the relationships and interactions between these contracts. Typically, one contract within the application must know how to interact with another, querying the registry for specific addresses. Similarly, when a component of the system receives an interaction, it must verify with the registry whether the caller is an authorized part of the application. Consequently, non-trivial Ethereum applications require these "connecting wires," which are cumbersome to deploy, complex to code, inefficient at runtime, and, most importantly, prone to human error and common attack vectors due to the lack of standardized solutions.
This file has been truncated. show original