How FeverTokens Implements Role-Based Access Control in Smart Contracts

Web3 technology has redefined the concept of ownership on the internet, similar to how Web2 redefined content creation. With tokens and particularly non-fungible tokens (NFTs) on the blockchain, people can now own various types of digital assets such as money, art, and code. However, the widespread adoption of NFTs and the concept of ownership has led to misunderstandings about smart contracts. It is inaccurate to speak of owning a smart contract, as they are simply code stored on the blockchain that execute a set of predetermined rules when activated. A smart contract can be thought of as an independent entity with its own address that allows people to interact with it.

Interactions with a smart contract are typically governed by a set of rules that determine who is allowed to invoke its functions and execute its code. To standardize this process, OpenZeppelin, a well-known provider of Solidity libraries, has introduced the Ownership contract. This contract includes a function modifier called OnlyOwner, which restricts the ability to invoke certain functions to a specific address that has been designated as the owner.

As applications become more complex and involve multiple stakeholders, there is a need for more advanced approaches to managing restrictions. One such approach is the role-based access control scheme, which has been used in other development environments for some time. However, the concept of ownership has become ingrained in people's thinking to such an extent that many people talk about "owning" a smart contract.

At FeverTokens, we use Role-Based Access Control (RBAC) to provide more precise control over smart contracts. This is achieved by defining custom roles (e.g., minter role, upgrader role, etc.) that apply to specific functions and grant different levels of authorization.

In practice, our customers can deploy smart contracts where they are assigned administrative roles, which enable them to control the contract and invoke certain restricted public functions (e.g., mint functions). They also have security roles that allow them to pause, unpause, or upgrade the contract in the event of an incident.

FeverTokens also has some restricted control over builders' smart contracts, allowing us to pause or unpause the contracts on behalf of the builder in emergency situations. As we use an upgradeable architecture, we have implemented a freezing functionality that allows us to freeze the current implementation in the event of a major bug or incident. This will disable all customer proxies (smart contracts) that are using this implementation. Such action would only be taken in case a major vulnerability has been discovered in the implementation and would be initiated via a multisig transaction requiring the approval of designated members of the FeverTokens organization. In some cases, builders may be prompted to upgrade their proxies (smart contracts) to a new, patched, and secure implementation.

Upgrading a smart contract is a critical action, so an upgrader role is used to restrict the ability to upgrade the contract to the holder of this role. This role is automatically granted to the builder deploying the proxy. However, to ensure that our builders do not upgrade to an implementation with fraudulent logic, we have implemented a check in the upgrade function that restricts upgrades to valid implementations that have been audited and approved by our team and eventually legal authorities. This means that the builder is the only one allowed to upgrade their smart contract, but they are restricted to approved implementations.

It is important to note that builders can grant all the roles assigned to them during the creation of the smart contract to anyone they choose. This allows them to add multiple collaborators or assign specific roles to specific team members.

‍