A Token Curated Registry (TCR) allows token holders to collectively curate what is accepted or rejected from a list. TCR’s deployed on Ethereum today, such as AdChain and FOAM, use PLCR voting to coordinate token holder decisions. Other decision making mechanisms could be used for TCR’s, such as anonymous voting, quadratic voting, or futarchy. Our team at Level K implemented the registry-builder library, which provides smart contracts that can be composed and extended to create new types of registries and TCR’s with any type of decision making mechanism. While this library offers utility in creating general purpose registries as well, we will focus this article specifically around the more popular notion of a TCR.
Our goal in creating this library is twofold. First, to create accessible, open source TCR smart contracts designed around modularity and composability. Second, to coordinate the community efforts to develop new TCR functionality. What if there was one place that provided a suite of modular features, which you could mix and match to create your custom registry? Ideally, as teams utilize this library and program new features or challenge mechanisms, they can also contribute features back to the library for the rest of the community to integrate.
Thus far, we’ve achieved modularity in two ways:
First, inspired by OpenZeppelin, individual features are grouped into smaller smart contracts which can then be extended. For instance, the StakedRegistry contract acts as a simple registry that allows staking on items. Our TokenCuratedRegistry contract then extends StakedRegistry to include this staking functionality.
Second, the challenge mechanism is decoupled from the registry. We have defined two interfaces for challenges: IChallenge and IChallengeFactory. All logic for challenge resolution will live in separate contracts that implement these interfaces. The TokenCuratedRegistry uses this pattern to allow integration with any type of challenge.
Also, this library is built as a ZeppelinOS EVM package. This way, you can deploy a proxy contract that points to the deployed package on mainnet, kovan, ropsten, or rinkeby, reducing your gas deployment costs. You can also use ZeppelinOS to upgrade to new versions of the package as they’re released.
In the near future, we look forward to improving on this library in a number of ways. We’d like to incorporate a way to make certain TCR parameters upgradeable (i.e. minimum stake, challenge duration). We’re also thinking about new challenge implementations such as futarchy and reputation based voting.
We’d love to see contributions. If you’re interested in contributing feel free to create a Pull Request or an Issue on the registry-builder repository!
