Time Locks

An examination of the time lock mechanism, a rarely mentioned but important component of smart contracts

DeFi protocols are made of fascinating components which are full of game theory and engineering ingenuity. Widely discussed components include oracles, auctions, and liquidation mechanisms.

Today I wanted to give a closer look at an important sub-component that is very rarely talked about: the time lock.

Background

Smart contracts are immutable, meaning once deployed the code cannot be changed. Immutability is what makes smart contracts trust-less.

For many types of DeFi projects, it makes sense to allow some parameters to be configurable. Since the code itself cannot be modified, state changing functionality need to be included upfront. For example, lending protocols will often have specific methods to update interest rate parameters.

Now, who gets to change these parameters? Usually, the development team will start out owning this responsibility via a multiSig wallet. The idea is that some day, the process will be replaced by a decentralized governance framework.

Critical Configurations

The caveat is that certain configurations are so critical that unintended alteration can lead to complete disaster. Let’s take the hypothetical situation of a decentralized lending pool with upgradable price oracles. If somehow, an attacker got permission to change the oracle, they can:

1. Upload a malicious price oracle that claims the price of 1 token X is worth $1.5b, where token X is a token supported by the lending pool
2. deposit 1 token XYZ as collateral
3. Assuming a collateral ratio of 150%, borrow up to $1b(or more likely, the entire available fund in the lending pool)

Another example is an upgradable decentralized exchange protocol(such as Hydro or 0x). If an attacker somehow were able to upload a malicious exchange module, then they would be able to effectively steal assets by making lopsided trades.

Guarding Secrets

Of course, the multiSig wallets will be closely guarded by development teams. But even assuming the team is trustworthy, competent, and has rigorous processes in place, they are still just guarding secrets. By the way, guarding secrets is basically what centralized exchanges do. This burden of custody is what many decentralized projects are working so hard to avoid in the first place. In other words:

A (naive) upgradable decentralized protocol is no better than a centralized custodial model

It would be ironic if this were true in general, since a major goal of DeFi projects are to get rid of the reliance on trust.

Time Locks To The Rescue

A time lock is a simple mechanism that allows a procedure to take effect sometime in the future.

Under a time lock, “upgrade module” becomes “upgrade module in 2 weeks”.

Now the best an attacker can do is submit a malicious upgrade that will take effect in 2 weeks. This waiting period makes all the difference, as it gives enough time for users and relayers to withdraw or disapprove. With the help of time locks, critical failure can be avoided even if secrets are compromised.

Emergency Shutdown Bypass

In general, it’s a good idea to put most critical administrative operations under a time lock. There is one important exception. Many DeFi protocols contain an emergency shutdown switch, meant only to be used if a critical bug is discovered. Shutdown bypasses must occur immediately.

To see why, consider the case where a critical exploit is found. If there is no shutdown mechanism, and the team publishes an update under a time lock, then potential attackers get 2 weeks to utilize the exploit.

If the shutdown mechanism itself is under a time-lock, then the team cannot pull the emergency switch at all. Because doing so meaning they have to wait helplessly for two weeks while giving off hints to the existence of a critical exploit.

So if a contract contains an emergency shutdown switch, it must be able to bypass the time lock. In general, the only combination that works is fast shutdown, slow upgrade.

From Multisig wallet to DAO

Proper time lock utilization might only be relevant to smart contract engineers and the ultra-rare advanced users who enjoy validating smart contract integrity from first principle.

For everyone else, why does this matter? Because the time lock based multisig wallet might give clues to how things might work under a decentralized governance framework. The latency introduced by time locks can act as a preview for how things might work under the slow process of disseminating information, voting, and reaching consensus.