Handling Critical Address Changes in Smart Contracts

Handling Critical Address Changes in Smart Contracts

What is meant by critical address change?

Critical addresses in smart contracts should be changed with two simple transactions:

1. The first transaction (originating from the old/current address) registering the new address (granting ownership) and
2. The second transaction (originating from the new address) replacing the old address with the new one (i.e., claims ownership).

This provides a chance to fix any inaccurate addresses that were accidentally used in the first stage. Otherwise, contract functionality may lose ownership or introduce malicious or incorrect addresses.

Understanding Access Control and Ownership Claim in Smart Contracts:

Access Control Management:
The concept of access control, or “who is permitted to perform this thing,” is crucial in the context of smart contracts. Your contract’s access control may determine who can issue tokens, cast votes on initiatives, halt transfers, and many other things. To prevent someone else from stealing your entire system, it is crucial to implement proper access control modifiers.

Claim Ownership and Ownable:
The concept of ownership is the most prevalent and fundamental type of access control: there is an account that is the owner of a contract and has administrative access to it. For contracts with a single administrative user, this strategy is fair.
The account that deployed the Ownable contract by default is its owner, which is typically what you want.

Ownable enables you to:

• transferOwnership: to a new account from the owner account, and
• renounceOwnership: After an early stage of centralized administration is complete, ownership typically requires the owner to give up this administrative privilege.

Role-Based Access Control:
Although simple systems or rapid prototyping can benefit from the simplicity of ownership, several degrees of authorization are frequently required. You might want an account to be able to remove users from a system, but not be able to add new tokens. This is where role-based access control (RBAC) is flexible.
In essence, we’ll be establishing several roles, each of which will have a specific set of actions allowed. Instead of just using onlyOwner, you should check to see if an account has any additional roles, such as “moderator,” “minter,” or “admin.” You can establish guidelines for how accounts can be given a role, have it revoked, and more separately.

How to use Access Control?

OpenZeppelin’s AccessControl contract allows implementing role-based access control. For each role you define, you produce a new role identifier, which is then used to grant, revoke, and verify whether an account has that role.
Even though it is obvious and explicit, Ownable would have allowed us to accomplish the same thing. Indeed, situations requiring granular permissions, which may be achieved by creating numerous roles, are where AccessControl truly excels.

Best Practices for Critical Address Change in Smart Contracts:

Using Ownable2Step:

It is recommended to use OpenZeppelin’s Ownable2Step contract which makes use of two step address change or implement similar two-step functions in your contract:

1. The function transferOwnership() sets the value of _pendingOwner :

function transferOwnership(address newOwner) public virtual override onlyOwner {
    _pendingOwner = newOwner;
    emit OwnershipTransferStarted(owner(), newOwner);
}

2. The function acceptOwnership() is used by the new owner to accept their address:

function acceptOwnership() external {
 address sender = _msgSender();
 require(pendingOwner() == sender, “Ownable2Step: caller is not the new owner”);
 _transferOwnership(sender);
}

Making use of TimelockControler:
TimelockController is a contract that enforces a time lock on all the onlyOwner functions operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied such as updating a critical address or changing ownership.

Using MultiSig
The administrators and owners should be multisig accounts to prevent a single point of failure. This basically means that changing a critical address will require multiple users to sign the transaction.

Implementing Access Controls
Lastly, it is important to make sure that all the critical functions that are adding or modifying address parameters should have proper access control modifiers which will prevent external users from calling the functions.

Conclusion:
In this article, we talked about how critical address and ownership changes can lead to exploitation draining all the funds if proper mitigations are not taken. You can rely on SolidityScan to ensure that the proper steps are taken to achieve the highest level of smart contract security. Signup for a free trial at https://solidityscan.com/signup