How to self-audit a smart contract

If you want to identify potential malicious functions that allow the owner to mint additional tokens or change the contract’s behavior, you should look for the following types of functions and patterns during a smart contract audit:

1. Minting Functions:

   • Functions that allow the owner to create or mint new tokens.
   • Look for functions that increase the total token supply. It’s important to understand the game theory of the token. If it’s a token that can be minted by anyone, then the supply is created by the community, and that’s probably part of the design. But if it’s only the owner or a privileged account that can do it, then you need to look deeper and see how it can impact the tokenomics.

2. Parameter Modification Functions:

   • Functions that enable the owner to modify critical contract parameters that affect token functionality or distribution.
   • These parameters can include rewards, allocation points, fees, or any variable that impacts token behavior.

3. Pausing or Freezing Functions:

   • Functions that give the owner the ability to pause or freeze the contract.
   • These functions can be used to prevent token transfers or other actions in the contract.

4. Ownership Transfer Functions:

   • Functions that allow the owner to transfer ownership or admin privileges to another address.

5. Role-Based Access Control (RBAC):

   • Complex role-based access control systems where the owner can assign different roles with varying levels of control and permissions.
   • Owner can manipulate these roles to exert control over the contract.

6. Whitelist or Blacklist Functions:

   • Functions that permit the owner to add or remove addresses from a whitelist or blacklist.
   • Owner can manipulate these lists to control user access or actions.

7. Parameter Initialization Functions:

   • Functions executed during the contract deployment that set critical parameters. These functions can include the initial allocation of tokens, setting rewards, or defining how the contract behaves.

8. Proxy Functions:

   • Functions used to upgrade the contract’s logic or to switch to a new implementation.
   • These can potentially be misused by the owner to change the contract’s behavior.

9. Privilege Revocation Functions:

   • Functions that the owner can use to revoke privileges or alter permissions for other users or roles.

10. Functionality Disabling Functions:

• Functions that can disable or restrict the functionality of certain features or other functions.

11. Admin-Only Functions:

• Functions that can only be called by the contract owner.

12. Emergency Functions:

• Functions that give the owner emergency control over contract actions.

It can be easily seen that the presence of owner or administrative privileges in a smart contract exposes the users to uncertainty about what could be done in the future if any of the functions is called. That’s why it’s important to interact with contracts that don’t have these privileges or where they’ve been renounced to a burn address, for example. When the contract can’t be changed, it’s immutable and doesn’t require any trust from the user. This, on the other hand, means that in case of an exploit, it will be impossible to intervene; however, that’s probably a lower risk than the owner calling arbitrarily different functions.

To check for owner/administrator privileges in a smart contract, you need to review the contract’s source code. These privileges are typically implemented through specific functions or state variables that allow the owner to perform administrative actions.

Here’s how you can recognize them in the code:

State Variables:

Look for state variables that designate the contract owner or administrator. Common names for such variables include owner, admin, creator, governance, or similar terms. These variables usually store the Ethereum address of the owner/administrator.

Example:

   address public owner;

Constructor Function:

In the constructor function, check for the assignment of an initial owner/administrator. This assignment is typically done within the contract’s deployment.

Example:

   constructor() { owner = msg.sender; // Assigns the deployer’s address as the owner }

Modifier Functions:

Look for functions that use modifiers like onlyOwner to restrict access to specific functionalities to the owner/administrator. These functions often contain sensitive operations, such as changing contract parameters or minting new tokens.

Example:

   modifier onlyOwner() { require(msg.sender == owner, “Only the owner can call this function”); _; }

Privileged Functions:

Review the functions within the contract to identify those that can only be called by the owner/administrator. Such functions usually contain logic that can alter the contract’s behavior or its state.

Example:

   function changeParameter(uint256 newValue) public onlyOwner { parameter = newValue; }

Role-Based Access Control (RBAC):

In some cases, smart contracts implement more complex role-based access control systems, where specific roles (e.g., admin, manager) have different levels of control. These systems can involve multiple state variables and functions to manage different roles.

Events:

Events are used to log important contract actions. Check for events that indicate owner/administrator actions, such as contract parameter changes or privilege updates.

Example:

   event ParameterChanged(uint256 oldValue, uint256 newValue);

Comments and Documentation:

Review comments and documentation within the contract code. Sometimes, the roles and privileges of the owner/administrator are explained in the code comments.

Here’s a simplified example of what it might look like in a smart contract: