I am smart contract auditor and I do not believe in a trustless world. When my colleagues tell me that an “overpowered owner” is an issue, I start arguing with them. When I get for an audit a project with the overpowered owner, I point that out as a major issue in the report. So, am I a hypocrite? I hope, this article will show you, what is happening on the other side.

What is overpowered owner

The following definition is debatable, but I will stick to it in this article.

Overpowered owner (i.e. the owner that has too much power) is the project design where contract owner (or owners) can manually invoke critical functions of the system.

It may sound obvious, but let me clarify the definition:

When token owner can mint tokens to anyone at any time, this is an overpowered owner.

When several owners can mint tokens to anyone at any time by voting, this is still an overpowered owner.

When all users vote to issue tokens to someone, this is not an overpowered owner.

When owner should manually invoke function at a certain time (for example, to change ETH/USD rate), this is an overpowered owner.

When ETH/USD rate is changed by the backend, this is still an overpowered owner.

When ETH/USD rate is received from oracle, this is not an overpowered owner.

Why people implement overpowered owner

According to our internal statistics, overpowered owner is present in 37% of ethereum projects. Why do developers continue implementing non-trustless systems? Because such pattern can solve multiple problems.

It helps to protect customers’ interests

Smart contracts cannot be changed once deployed. This means an unnoticed bug can jeopardize the entire system. That is why creators may decide to implement functions that will help to reduce potential losses from the actions of malicious user. For example, freezing the entire system, blacklisting and whitelisting.

It allows taking care of the system environment

Sometimes contract creators want to preserve the ability to change contract parameters. For example, when the logic for setting these values is way too complex.

Imagine a situation when overpowered owner has the ability to mint and burn tokens. These functions can be used to manipulate token economics to control it, in the way this is done in the real world with the real currencies.

Design

Let’s be honest: we are all used to the presence of an overpowered owner. In the modern world, there is almost always some person who can make critical decisions. Moreover, in the world of centralized systems, for developer, it is pretty hard to design a decentralized one. Some prefer to not waste time and implement something that works ASAP.

UX

Overpowered owner is a pretty simple system pattern, which can be easily explained to user. In the current world, user experience is very important. And if overpowered owner paradigm affects UX in a positive way, then why not to use it.

Why overpowered owner is bad

Despite all the advantages mentioned above, “overpowered owner” design entails risks that should not be underestimated. As one great man said, with great power comes great responsibility. And that great power can be used in malicious way.

You have to trust the owner

No one guarantees that the owner would not use his/her powers in an unexpected way, potentially stealing funds, blackmailing, etc.

Key privacy

The person who uses project with overpowered owner must be sure that the owner is concerned about key privacy. A loss of the owner’s keys inflicts serious damage or, in the worst case scenario, puts an end to a project.

A great example of such failure is KickICO project. Hackers have compromised owner’s private key and have stolen tokens, worth 7,700,000$.

Bus factor

Bus factor is the minimum number of team members, that should accidentally disappear before the project begins to stall. What is this for?

Overpowered owner paradigm implies a small number of people with exceptional abilities. Thus, the bus factor of such projects is relatively low. It is okay when owner, responsible for hacker attacks mitigation, disappears. The other situation when the presence of the owner is vital for project existence.

When one implements overpowered owner, he/she should remember, that no one is immune to a hard drive failure or death.

What to do with overpowered owner

In my opinion, ideally, overpowered owner should not be present in the project. Of course, it is not an easy task to do so since it may require a more complex architecture. Though, this task is still feasible. To make it a little bit easier, I would recommend taking a look at similar projects.

If it is impossible to get rid of overpowered owner completely for some reason (complex design, lack of time, etc.), then I would recommend segregating duties. Segregation of duties is a concept of having more than one person to complete the task. That means, more than one person is required to make a crucial or malicious change to the smart contract. This can be achieved in multiple ways, for example, by using multisig.

In a pinch, there is nothing about not doing anything. The fact that blockchain initially was conceived as a trustless system does not imply every project on Ethereum to be trustless. There are more Ethereum benefits besides being trustless.

TLDR

To summarize, overpowered owner is a certain system design with its advantages and risks. However, I would advise if not to get rid of Overpowered Owner then at least to stick to the paradigm of “segregation of duties”. After all, even in the modern world, there are such things as shares, board of directors, and so on.

And remember, if you ask me to audit your code with Overpowered Owner, I will report this as an issue.