You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Metaregistry deployed at 0xF98B45FA17DE75FB1aD0e7aFD971b0ca00e379fC is an on-chain API that integrators can use to get more information about the latest pools from Curve. It is currently used by analysts and notable integrators in the dex aggregator as well as yield aggregator space.
Requirements
Users have needs that evolve with the times. The immutable nature of the Metaregistry does not accommodate this evolution. Since the metaregistry does not hold user funds, it is a good candidate to adopt an upgradeable proxy architecture.
Limitations
Vyper does not currently support upgradeable proxies in a way that is useful to the metaregistry. To date, the best implementation of this is by Banteg, which has several limitations:
Limitation 1: cannot cleanly comply with EIP1967 for storage slots
_gap_0 and _gap_1 are hacky ways to ensure that implementation and admin methods have deterministic storage slots. This can be achieved by specifying storage slots during compile time but this falls short since integrators will not go the length to add yet another .json file in the pipeline to verify these contracts.
Vyper needs the ability to specify storage slots at compile time but within the smart contract itself. This would be the bare minimum devex necessary for the second gen of the metaregistry.
Limitation 2: cannot specify universal return type in fallback method
In the example, banted mentions:
@external
def __default__() -> uint256:
"""
FIXME vyper needs a way to pass verbatim buffer for this to work universally
"""
result: uint256 = convert(raw_call(self.implementation, msg.data, max_outsize=32, is_delegate_call=True), uint256)
return result
The __default__ method cannot return values other than uint256 here. For this, Vyper devs have theorised a raw_return, which could potentially looks similar to:
Second-generation metaregistry is blocked from being developed without overcoming these two limitations. It also makes limited sense to build it without it being upgradeable since that would not be a future-proof way.
Task List
Coordinate with vyper devs and get enabling features on vyper release 0.4.1
create2deploy upgradeable proxy with deterministic addresses across all chains
test and deploy metaregistry contracts on these chains
Challenges
Because the metaregistry is going to be on several chains, this is quite the cumbersome task since there can be quite a few edge-cases.
The text was updated successfully, but these errors were encountered:
Background
The Metaregistry deployed at 0xF98B45FA17DE75FB1aD0e7aFD971b0ca00e379fC is an on-chain API that integrators can use to get more information about the latest pools from Curve. It is currently used by analysts and notable integrators in the dex aggregator as well as yield aggregator space.
Requirements
Users have needs that evolve with the times. The immutable nature of the Metaregistry does not accommodate this evolution. Since the metaregistry does not hold user funds, it is a good candidate to adopt an upgradeable proxy architecture.
Limitations
Vyper does not currently support upgradeable proxies in a way that is useful to the metaregistry. To date, the best implementation of this is by Banteg, which has several limitations:
Limitation 1: cannot cleanly comply with EIP1967 for storage slots
_gap_0
and_gap_1
are hacky ways to ensure thatimplementation
andadmin
methods have deterministic storage slots. This can be achieved by specifying storage slots during compile time but this falls short since integrators will not go the length to add yet another .json file in the pipeline to verify these contracts.Vyper needs the ability to specify storage slots at compile time but within the smart contract itself. This would be the bare minimum devex necessary for the second gen of the metaregistry.
Limitation 2: cannot specify universal return type in fallback method
In the example, banted mentions:
The
__default__
method cannot return values other than uint256 here. For this, Vyper devs have theorised araw_return
, which could potentially looks similar to:Second-generation metaregistry is blocked from being developed without overcoming these two limitations. It also makes limited sense to build it without it being upgradeable since that would not be a future-proof way.
Task List
Challenges
Because the metaregistry is going to be on several chains, this is quite the cumbersome task since there can be quite a few edge-cases.
The text was updated successfully, but these errors were encountered: