Add ERC: Router Proxy

[eternauta1337]

The Router Proxy Standard 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.

[eip-review-bot]

File ERCS/erc-7771.md

Requires 1 more reviewers from @axic, @g11tech, @samwilsn, @xinbenlv

[github-actions[bot]]

The commit cd1e5dec9f18c00de117740ea351b00efdb80d29 (as a parent of 778ed6acd04bb3ad23d0039ef045db8a448e4d38) contains errors. Please inspect the Run Summary for details.

[mudgen]

Unlike the latter, this method hardcodes module addresses within the proxy’s implementation contract

I would like to clarify that EIP-2535 Diamond can be implemented with hardcoded module addresses and selectors, and this has been done by the Pendle project. In general I really like this idea and I would like to see a new standard that standardizes this kind of implementation but that also implements EIP-2535 Diamonds, which is not hard to do. An article that covers the minimum things required to comply with the EIP-2535 Diamonds standard is here: https://eip2535diamonds.substack.com/p/compliance-with-eip-2535-diamonds

[eternauta1337]

Unlike the latter, this method hardcodes module addresses within the proxy’s implementation contract

I would like to clarify that EIP-2535 Diamond can be implemented with hardcoded module addresses and selectors, and this has been done by the Pendle project. In general I really like this idea and I would like to see a new standard that standardizes this kind of implementation but that also implements EIP-2535 Diamonds, which is not hard to do. An article that covers the minimum things required to comply with the EIP-2535 Diamonds standard is here: https://eip2535diamonds.substack.com/p/compliance-with-eip-2535-diamonds

Hey @mudgen 👋 Apologies. I wasn't aware that Diamonds supported hardcoded addresses. Will fix ASAP.

Regarding your suggestion to make this standard compatible with EIP-2535, I'd rather not. Even though this was heavily inspired by diamonds, the whole point during its design was to produce something simpler, more minimalistic. IMO Diamonds brings in a lot of complexity that is not necessary to solve the underlying issue.

[mudgen]

@eternauta1337 In this case to make a static router compliant with EIP-2535 Diamonds all that is necessary is to emit an event (DiamondCut) that says what functions the router/diamond has. And implement 4 read only functions that return what functions and contracts the router/diamond has. This can be implemented in a simple straightforward way such as done by Pendle here: https://gist.github.com/mudgen/7d50e3d0aca93b9cc321dfa0dbded373 Note that the most complicated part of the implementation is the binary search for a facet/contract address for a given selector and this has to be implemented whether the EIP2535 event and functions are implemented or not.

If is fine if you don't want to support this functionality (event and 4 read-only functions) but I would appreciate it if you don't give reasons that are highly subjective opinion and critical. You can simply say you don't want to support any other functionality.

Obviously I do think the emission of an event that says what is in a router or diamond and the 4 read only introspective functions are worth it. They provide tools like contract viewers and builders and block explorers to easily provide information about what makes up a router or diamond. I am currently working with someone from etherscan to add support for EIP-2535.

[github-actions[bot]]

There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions[bot]]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.