Most blockchain projects have some sort of centralized control (admin key) that allows a developer or founding team to make decisions on the smart contracts underpinning their work. Many projects take steps to secure these admin keys, but still, the admin key yields a large amount of power to the hands of very few. Decisions over user balances or replacing code can be made unilaterally.
We’re excited to announce a new approach to re-DAO-ify Tellor. We’re taking these steps to fulfill the long-term vision of Tellor as fully trustless and unstoppable.
What are the risks with an admin key?
In the early stages of a project an admin key is great for building and making sure the system functions as intended, however admin keys take away much of the trustlessness and decentralization of blockchain technology. It relies on faith that the admins won’t abuse their powers. Worst-case, rug pulls happen and a team member is hacked or takes users’ funds and disappears.
To eliminate this centralized point of risk, a small minority of projects remove the admin key by sending it to a burn address. This creates a new set of challenges. What if there’s an error in how the project is built and how is it fixed? What if the community votes for a bogus change to the project? And if the project comes under attack, what are the control measures to make sure the attacker doesn’t succeed when time is of the essence?
The risk of facing government regulation is also a wide open question for ‘centralized’ projects with an admin key. The regulators may take out projects that have a ‘kill switch’ in the form of an admin key. DeFi projects that have centralized ‘custodial’ control over users and their funds face heat, especially in the form of legislation. If regulators can find a centralized party or group of people, they will grab hold.
Tellor’s Parachute Smart Contract
At Tellor, we’re familiar with the tradeoffs. Having initially built Tellor with an admin key in place, then sending it to a zero address last October, and subsequently encountering a fatal error forcing us to fork to a new contract giving us admin keys back — we’ve learned a lot along the way.
Tellor’s core philosophy is to be the most decentralized, censorship-resistant oracle. This long-term view of the project allows the team to make decisions that may be new or different. But these structural changes are designed for the success of the larger blockchain community. We want to build a flourishing ecosystem and set an example for those that want to build towards this goal.
As of Wednesday, August 11, 2021, Tellor has sent its admin key to a smart contract called Parachute.
- Check the code here: https://github.com/tellor-io/parachute
- Parachute contract address: https://etherscan.io/address/0x83eB2094072f6eD9F57d3F19f54820ee0BaE6084
This helps Tellor become more decentralized while also creating a fallback in case a catastrophic event happens in the future.
So what does it mean for Tellor and the community? Throughout the normal operation of the Tellor oracle, the Parachute smart contract will sit idle or unused — so not much changes. In the case of an underflow attack, broken mining and reporting, or Tellor updates to something non-functional, the Parachute will pass admin rights to the Tellor team to take the necessary actions.
This new feature of the Tellor protocol creates a more decentralized project, while adding a narrow set of fail-safes; events that would allow the Tellor team to gain back control to fix bugs or rectify attacks with clear and transparent logic, driven by code.
To be clear this doesn’t give the Tellor team backdoor access to critical pieces of the project. The admin key is completely out of the founder’s control now and in the hands of the community through token governance mechanisms.
The Bigger Picture
Many projects, at some point, will face the tradeoff between control and decentralization. We’d encourage any project that is interested in going the DAO route to consider a Parachute that fits their own criteria.
In the early days of a project, it may make sense for the founders to keep control in order to have a stable deployment and quickly adapt post launch. However we hope our use of a parachute style contract will influence these projects to “take the leap” as early as possible.
