Most smart contracts have functions that not everyone should be able to call: minting new tokens, pausing the contract, changing fees, upgrading the code or withdrawing funds. Access control decides who may call what. When it is missing or wrong, anyone can call those functions, and a whole category of hacks starts exactly there.
Ownable or Role-Based?
The simplest model is a single owner who may do everything. That is fine for a small contract during development, but in production it means one key controls the entire system. Role-based access control splits power into separate roles, such as a minter, a pauser, a fee manager and an upgrader, each assigned to the account that needs it and nothing more.
We usually build on the well-reviewed OpenZeppelin implementations and design the role structure around how your organisation actually works.
Principles We Apply
- Least privilege: every role can do only what it needs. An operational bot that pauses in an emergency should not also be able to mint.
- Powerful roles in a multisig: admin and upgrade roles sit in a multisig, not in one person's wallet.
- Slow changes for big decisions: role changes and critical parameters go through a timelock, so users can see them coming.
- Emergency pause: a pause function that a fast-reacting role can trigger, while unpausing requires more signatures.
- Safe handover: two-step ownership transfers, so admin rights cannot be sent to a wrong address by a typo.
- Tested permissions: tests that check not only that the right accounts can act, but that every other account is rejected.
Common Mistakes
A function that should have been restricted but was not. An initialiser on an upgradeable contract that anyone can call. A deployer wallet that still holds every role months after launch. These are easy to prevent at design time and painful to discover afterwards.
Frequently Asked Questions about Smart Contract Access Control
What is the difference between Ownable and AccessControl?
Ownable gives all privileges to one owner address. AccessControl defines multiple roles, each with its own permissions and its own admin. For production systems with more than one type of privileged action, role-based access control is almost always the better choice.
Can roles be changed after deployment?
Yes, if the contract is designed for it. Roles can be granted and revoked by the role's admin. We recommend putting that admin behind a multisig and, for sensitive roles, a timelock.
Should we renounce ownership?
Only when the contract truly never needs an admin action again. Renouncing makes a contract immutable, which builds trust but also removes the ability to respond to problems. Often a multisig with a timelock is the better balance.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our smart contract development services. Planning an audit? See smart contract audit support.
Get the Permissions Right
Tell us which actions your contracts need and who should be able to take them. We will design a role structure that is secure and workable.