Smart Contract Ownership

Published: April 20, 2018, updated: January 4, 2025

Update from 2025: the cryptocurrency boom of 2017 and 2017 and ICOs were an interesting time, huh? It’s not my cup of tea anymore. At the same time, I’d like for this post to stand here as a historical artifact, and encourage you to spend your time on more worthwhile things instead.

Thank you for reading my disclaimer. Please enjoy the following post:

When building your smart contract platform—whether on Ethereum or any other blockchain—at some you’ll be faced with the question of ownership. In this article, I explain three different types of smart contract ownership and discuss their advantages and disadvantages.

What is smart contract ownership? Smart contracts and decentralized applications (DApps) frequently require external input to guarantee continuous operation. Many of these external inputs and operations require some form of consensus from the contract stakeholders to:

In more practical terms, we can imagine each of these operations as calling smart contract functions. To illustrate this, let’s imagine a token crowdsale contract—one of the most popular forms of smart contracts out there, widely used for ICOs.

(This article explains the mechanisms of token crowdsales. OpenZeppelin’s crowdsale contract, which can be deployed on the Ethereum blockchain, is described here.)

A token crowdsale has lots of different knobs and settings that you might have to change while it’s running:

1. Owner-less

The simplest option is to make these settings fixed and unchangeable. In that case, your contract has to be set up correctly from the beginning. It’s not possible to go back and revise options. This also means that once the crowdsale is set up, token buyers never have the feeling of investing in a bait and switch.

graph crowdsale[Crowdsale Contract] token[Token Contract] crowdsale -->|owns| token

The contract code looks roughly like this:

contract Crowdsale {
    ERC20 public token;

    function Crowdsale(ERC20 _token, ...parameters) public {
        token = _token;
        // Copy remaining into crowdsale instance
    }

    function() public {
        // Sell token
        // ...
    }
}

The advantage is that this crowdsale contract can not be changed after deployment. If an investor decides to buy its tokens, they are guaranteed to receive the tokens during payout exactly under the same conditions that they have purchased them under.

You need to consider two risk factors:

2. Single owner

The next option is to add a single owner to the contract.

graph owner[Crowdsale Owner] contract[Crowdsale Contract] token[Token Contract] owner -->|owns| contract contract -->|owns| token

The single owner can then change crowdsale parameters, such as bonus payouts or soft and hard caps. We can then limit the ability to change crowdsale parameters to the contract owner. By default, this is the address that created the contract.

If you’re basing your contract on OpenZeppelin’s Ownable, implementation becomes an easy task. Simply define your smart contract like so:

contract Crowdsale is Ownable {
    ERC20 public token;

    function Crowdsale(ERC20 _token, ...parameters) public {
        token = _token;
        // Copy remaining into crowdsale instance
    }

    function() public {
        // Sell token
        // ...
    }

    // The owner can now change crowdsale parameters
    function changeAttributeXYZ(XYZ newValue) public onlyOwner {
        value = newValue;
    }
}

Having a single owner allows changes to the crowdsale to be done swiftly. This is useful if urgent action is required. Especially if the crowdsale is happening in a trusted and closed environment—where all parties know and trust each other—having a single owner is the best option.

Some risks need to considered as well:

3. Governance

A third option is a governance smart contract. This can typically involve many shareholders who each own a stake in the governance contract and can change it based on consensus. The governance contract in turn manages the crowdsale contract. The stakeholders can be advisors, investors, or founders.

graph stakeholderA[Stakeholder A] stakeholderB[Stakeholder B] stakeholderC[Stakeholder C] ballot[Ballot] governance[Governance Contract] crowdsale[Crowdsale Contract] token[Token Contract] stakeholderA -->|votes| ballot stakeholderB -->|votes| ballot stakeholderC -- votes --> ballot ballot -- interaction ---governance governance -->|owns| crowdsale crowdsale -->|owns| token

Changes to the crowdsale contract parameters are handled in a democratic way. The following steps are required.

  1. A stakeholder proposes a change to the crowdsale and creates a ballot. The ballot contains code that the governance contract can execute, in this case, code that changes crowdsale parameters.
  2. Each stakeholder is assigned votes proportionate to their shares or other predetermined factors.
  3. All stakeholders have an opportunity to vote.
  4. Once all eligible voters have voted or the ballot has closed, whichever comes first, the ballot is executed.

This process provides the best possible outcome for openness and trustworthiness. Making decisions out in the open and letting those with a stake in the project take part in it shows that you are seriously interested in implementing a democratic and decentralized crowdsale that treats stakeholders in a fair way.

In a governance setting, every change in crowdsale parameters comes after a standardized voting process during which people have the opportunity to understand and discuss how a change in the smart contract affects their investment.

Even in the most democratic setting, malicious actors can manipulate the process. Someone owning a lot of votes—by acquiring crowdsale shares—can influence a ballot’s outcome. The owner can even try to conceal this by owning the shares through many different wallet addresses. But still, since voting happens out in the open, stakeholders are more likely to notice any attempt at deception.

4. Conclusion

To sum it up, there are three different ways to control contract ownership:

  1. owner-less contracts,
  2. single-owner contracts, and
  3. governance-owned contracts

When implementing your decentralized app on the blockchain, you should carefully weigh the advantages and disadvantages of each approach and come to a decision that works best for both for you and your users.

5. Changes

Changed graphs to use mermaid instead.

Tags

I would be thrilled to hear from you! Please share your thoughts and ideas with me via email.

Back to Index