B004: Smart Contract Centralization

In the blockchain space, the term “decentralization” has been hashed over again and again leading to it deviating from its true meaning as well as purpose. We will showcase certain paradigms we have seen commonly applied in projects that surrender an unwarranted amount of control to the project’s original deployer and how to avoid them.

Contract Ownership

A contract’s ownership can be expressed in multiple ways, be it via using a standard implementation such as Ownable by OpenZeppelin, a more elaborate scheme such as AccessControl again by OZ or even coding one’s own implementation from scratch.

Example of “Bad” Contract Ownership
Compound: Example Implementation of Healthy Ownership Management

Blind Trust

Smart contracts are immutable pieces of code that execute in a deterministic manner regardless of their hardware & environment. As such, it is entirely possible to strictly dictate the expected logic paths the code is meant to execute and prohibit otherwise “unwanted” execution paths from occurring.

Example of Blind Trust
Example of Good Faith

Fund Centralization

This is a relatively self-explanatory issue that can be observed in both recent as well as historical projects. Minting the total supply of a token directly to the contract’s deployer used to be an accepted pattern but over time it has progressed into a tool for rug-pulls to quickly dump and destroy their token’s value for a quick profit.

Example Snippet of a Fully Centralized Token

Conclusion

Decentralization is a fluid term that can vary in degree depending on the actual needs of a project, however, it is easy to discern which projects do not boast this trait even to the slightest degree. Every potential investor and user of a project should perform their own due diligence in the decentralization of it as it is a safe indicator of both its health and maturity.

A Solidity security auditor keen to share his knowledge.