Role-Based Access Control

Role-Based Access Control Explained in Detail

Role-based access control assigns permissions through roles. A contract might have separate roles for minting, pausing, upgrading, oracle updates, fee changes, or emergency recovery.

OpenZeppelin's AccessControl model also gives each role an admin role that can grant or revoke it.

Smart contract example

bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

function pause() external onlyRole(PAUSER_ROLE) {
    _pause();
}

The important question is not only whether pause() has a role check. Auditors also need to know who can grant PAUSER_ROLE and who controls that admin role.

Role-Based Access Control in Auditing

RBAC can reduce overbroad owner permissions, but it can also create hidden privilege paths. A role admin can be as sensitive as the role itself, and DEFAULT_ADMIN_ROLE is often the highest-risk account in the system.

Auditors review role hierarchy, least privilege, bootstrap setup, revocation, emergency rotation, multisig ownership, timelocks, and deployed role holders.

Red flags in code

• DEFAULT_ADMIN_ROLE is held by a hot EOA.

• A role is self-administered without a clear operational reason.

• Sensitive functions use inconsistent role checks.

• Setup scripts grant broad roles and never revoke temporary deployer permissions.

• Role changes are not covered by governance, multisig, or timelock controls where expected.

How to test or review it

• Build a table of each role, its admin role, and every function it can call.

• Test privileged functions from role holder, role admin, non-holder, and revoked holder accounts.

• Verify deploy scripts and initialization assign roles to intended accounts.

• Check role revocation and emergency rotation paths.

• Review any access control vulnerability risk created by indirect calls, proxies, or governance modules.