October 18, 2022: How Meta 🎁🚢
MetaRegistry: The One Registry to Rule Them All
Contrary to the long-standing critiques of Curve’s frontend user experience, Curve’s developer user experience is top-notch. The excessively developer friendly nature of their smart contracts has a tendency to attract myself and other developers into the ecosystem. As I started poking into the protocol, nearly every question I had about building smart contracts on top of Curve had an excessively simple answer, at that time often provided swiftly by the core team.
Usually questions I had about the on-chain architecture took the form of some other contracts preemptively deployed on-chain. These contracts often sported such an early version of Vyper as to suggest (1) the early team would anticipate dev issues years before they’d manifest as problems (2) they were happy to use relatively primitive tooling (by today’s standards) to attack these problems and (3) they were eager to spend their hard-earned ETH making the developer experience pristine.
Some examples of common questions that still pop up in the #dev channel.
Why is there no dx function? Try the Calculator contract.
How can I find the best routing? Try the Exchange contract.
How can I find [nearly anything] for a given pool? Try the Registry contract.
How can I find the registry on a given chain? The Address Provider contract points to all relevant contracts and is the same address on every chain.
For most questions, the “Registry” contract usually has the answer. The registry contains a whole litany of helpful functions: functions to find a pool for a pair of coins, find a pool for an LP token, find a pool by name. See for yourself…
The Registry served as a magic decoder ring for the entire Curve ecosystem. All you needed do to summon the Registry is bookmark the Address Provider, always deployed to the same address on all chains, which would helpfully be updated with the newest version of the Registry contract.
However, once the Curve pool factory launched, the Registry no longer served as the single source of truth. The new Factory contract itself served as a registry for every new factory pool. In this new paradigm, if you wanted to find a Curve pool, you’d have two stops. You needed to check both the classic Registry containing all the pools launched by the team, as well as the Factory contract containing all the pools launched by the public.
Makes sense, innit? At the high level, an easy way of sorting permissionless factory pools from those that went through the scrutiny of the early team applying a heavy quality filter.
Then came the advent of v2 pools. The Curve team needed a new registry format to handle their new evolution. For example, v2 pools have a “D” parameter that v1 pools lack. Enter the Crypto Registry, Curve’s third registry contract built just for crypto pools.
The Crypto Registry worked well enough. After launching a total of nine pools through this registry, they felt it was time to open Crypto pools to the adoring public. The Crypto Pool Factory would quickly explode in popularity, with a total of 146 pools launched permissionlessly through its interface. Like the v1 Factory contract, this v2 Factory would also function as the fourth registry.
At this point, developers building atop Curve ran into a bit of a problem. Now you needed to search through four different contracts to hunt for whatever information you needed.
Thankfully, the registries are fairly consistently formatted (again, Curve team paying exquisite attention to developer experience), so it’s mostly possible to loop through the registries until you find what you need. It stood out as a rare point of friction for developers.
This past weekend, @fiddyresearch.eth from Curve solved the problem. He deployed the MetaRegistry, aka the “one registry to rule them all.” The new contract is a sleek wrapper that crawls data among all of Curve’s myriad registries, so devs don’t have to.
The MetaRegistry is future-proofed with the capability of scanning up to 10 registries, wrapping access to all the useful functions you may need no matter where Curve innovation may go.
Per the Github:
Note the contract is heavily optimized for developers querying data from off-chain. While theoretically users could encode this into on-chain contracts, this would not be the recommended use case.
Some features of the new MetaRegistry:
The exceedingly useful `find_pools_for_coins` shows off the utility of Vyper’s new dynamically sized arrays.
To our point about outstanding devex, most of the logic is consistent among the registries, with the edge cases covered by separate RegistryHandlers. This design choice provides some bonus upgradability for the contract.
This keeps the MetaRegistry contract nice and clean, loaded with lots of documentation about how each function works for users just getting into Curve.
New users will also enjoy reading through the easily accessible Github, which is also extensively documented and the first Curve repo utilizing the hot Ape Framework for its testing.
Since the repository’s author has no public Twitter presence, the job of harvesting likes fell to surrogates.
When users complain about Curve’s user experience, they perhaps neglect to realize that Curve’s team of hardcore devs pays acute attention to the user experience for developers. The MetaRegistry is a perfect example of this.
Given how popular the MetaRegistry is already proving, we may even see future versions that threaten to make it even more all-encompassing…
