Convention for Proxy specific methods

Support Contracts
1

I'm working on a custom proxy, that inherits from ERC-1967 Proxy contract.

In this custom proxy, I need to define some external methods. If the name of those methods is the same as the methods of the implementation contract, those methods will be unreachable in the implementation.

Is there any convention for naming external methods in a Proxy contract?

I was thinking using something like <ProxyContractName>__method, but before doing it I wanted to check if there's some existing convention I can use.

I haven't found anything about it in https://eips.ethereum.org/EIPS/eip-1967

2

Hi @gnarvaja,

I'm curious about this custom proxy and why you need to define external methods. As you mention, the name of those methods may collide with the implementation contract.

To solve that issue, there are a couple of different approaches. For example, a TransparentUpgradeableProxy defines an interface that only a specialized address (the admin) can interact with, this way the proxy remains 100% transparent.

Similarly, a UUPSUpgradeable contract allows to include the complete upgrading logic in the implementation so that compilation fails if there's a collision.

The reason ERC 1967 doesn't define a convention for naming external methods in a Proxy contract is because it could be considered an implementation detail. I guess that your use case may be doable with a different setup. For example, by overriding TransparentUpgradeable's _fallback function to include another function only available to the certain callers or by just adding it to your implementation and using the UUPS approach.

Both have tradeoffs. Hope this helps!

3

Here you have an example of a Proxy I'm working on that has custom methods:

The idea is to use Proxies not to support upgradeability, but instead as a way to plug a middleware in the contracts.