Lock Admin Key Architecture

Overview of our non-custodial admin setup

Lock Protocol
Lock Protocol
3 min readApr 8, 2020

--

Admin Key Overview

Smart contracts have administrators. The actions an administrator can take depends on the design of the smart contracts. This feature of programmable finance is a two-edged sword. On one hand, smart contracts enable people to design systems with innovative functions and ways to store or manage tokens. On the other hand, when secure administration fails, it can lead to problems for both the users and the protocol.

You can learn more in this article from The Cryptonomist. Also, this analysis from Ameen Soleimani discussing the Compound admin key may be informative.

Lock’s Admin Key

These are the main considerations for our administration key:

  • Lock should never control user funds
  • Lock should provide support to users and ensure the safety of funds to the highest degree possible
  • Complex situations will emerge that require emergency action

With these points in mind, Lock admin can take these actions:

  • Emergency Unlock — Unforeseeable events may lead to necessary action from holders of a particular token. These can include a chain swap or critical vote. The Lock admin can unlock all active locks for a particular token in these cases. Lock will never have access to the user’s tokens, but can enable users to withdraw immediately. Lock will not unlock tokens for foreseeable events such as planned network votes. Emergency unlock is also a last resort effort in case the protocol does not function as intended.
  • Pause Locks — If there is an issue with the Lock protocol or an upcoming upgrade to our contracts, the Lock admin can pause the ability to create new locks. All existing locks will remain active with no changes.
  • Add New Tokens — The Lock admin can add new tokens to the system. We considered enabling users to lock any ERC-20 token. Upon further analysis, we realized that overseeing all tokens was not possible. At this stage it is best to limit available tokens to lock so we can manage them with appropriate oversight.
  • Edit Fees — Lock admin can change fees for new locks. Lock displays fees to users before they make a lock. There are no fees to claim an asset once a lock is over.
  • Support Airdrops — The Lock admin manages airdrops for locked tokens. When an airdrop lands in our contract we distribute the tokens to each user. Users claim both the airdropped and primary tokens once their lock is over.

These features provide support to users without being too invasive. If you can think of a way to improve this design, please reach out to us.

Continued Iteration

Protocol design is a continuous process. Every day we learn about new possibilities and challenges associated with time-locking funds. We will continue to provide users a safe environment to lock tokens. Part of this is our audits and another is deciding how and how often to upgrade the protocol. We decided, for now, to not use upgradable contracts to protect our users. It is imperative that once a user locks tokens that what they have committed to will not change.

Protocol upgrades will occur with substantial notice and careful planning. All locks in previous versions of the protocol remain claimable in perpetuity. If you have issues claiming tokens from a previous version, please reach out. We will also provide LOCK tokens to relock assets in the updated version at no extra fee.

To Conclude

We hope this provides you with a complete understanding of our admin key architecture and the potential risks of using Lock. If you have any questions or suggestions on how we can improve, please reach out.

You can follow us on these channels:

Website | Medium | Twitter | Github | Telegram

You can use Lock here.

Thanks for reading!

--

--