ERC-XXXX: Cento Proxy – Index-Based Multi-Facet Proxy

Motivation Over the past several years, the Ethereum ecosystem has shown sustained interest in modular proxy architectures. ERC-2535 (Diamonds) established the first widely adopted standard, and subsequent proposals such as ERC-8109 and ERC-8153 have continued to refine different aspects of the design, particularly around selector management, introspection, and the standardization boundary. While following these discussions, one architectural question kept recurring: Should modular routing fundamentally identify implementation modules through function selectors at all? Function selectors naturally identify externally callable functions. Facets, however, are implementation modules. In existing selector-centric architectures, these two responsibilities become coupled, making selector management a permanent concern throughout deployment, upgrades, and protocol maintenance. Routing Model This proposal explores an alternative routing model based on a different principle: Protocol routing should identify facets, while function selectors should remain dedicated to interface compatibility. Instead of routing through selector tables, Cento Proxy assigns each facet a compact routing index. Native protocol calls append this routing index to calldata; the router strips it before delegation, and the delegated facet receives the original calldata exactly as if it had been called directly. Existing standard interfaces remain selector-routed to preserve compatibility with current tooling and infrastructure. This naturally separates two distinct responsibilities: Protocol routing : index → facet Interface compatibility : selector → index → facet As a result, modularity becomes fundamentally facet-centric rather than selector-centric, allowing deployment, upgrades, and observability to operate directly on implementation modules instead of collections of function selectors. This separation has several practical consequences: native protocol development no longer depends on selector management or selector collision concerns, upgrade costs scale with the number of affected facets rather than functions, and protocol evolution becomes centered around implementation modules instead of selector tables. Resources Alongside the proposal, I’ve prepared: a complete Reference Implementation ; an ERC Proposal describing the routing model; comprehensive tests, benchmarks, documentation, and deployment tooling. Thoughts & Feedback Although the routing model itself is the primary contribution, I’d especially appreciate discussion around the standardization boundary. The Diamond ecosystem has shown that topics such as mandatory interfaces, introspection, upgrade events, and standardized errors remain open design questions rather than settled conventions. Since index-based routing approaches modularity from a different architectural perspective, I believe it provides an opportunity to reimagine the modular proxy standard from a fresh start rather than inheriting previous assumptions. I’d be particularly interested in feedback on: the routing model itself; which aspects should belong in the standard versus remain implementation-defined; whether events, errors, interfaces, and introspection capabilities should be standardized. Thank you for taking the time to read through the proposal. I look forward to hearing your thoughts and discussing it with the community. 1 post - 1 participant Read full topic