Extending Contracts
Most of the OpenZeppelin Contracts are expected to be used via inheritance: you will inherit from them when writing your own contracts.
This is the commonly found is syntax, like in contract MyToken is ERC20.
Overriding
Inheritance is often used to add the parent contract’s functionality to your own contract, but that’s not all it can do. You can also change how some parts of the parent behave using overrides.
For example, imagine you want to change AccessControl so that revokeRole can no longer be called. This can be achieved using overrides:
// contracts/AccessControlModified.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.sol";
contract AccessControlModified is AccessControl {
error AccessControlNonRevokable();
// Override the revokeRole function
function revokeRole(bytes32, address) public pure override {
revert AccessControlNonRevokable();
}
}The old revokeRole is then replaced by our override, and any calls to it will immediately revert. We cannot remove the function from the contract, but reverting on all calls is good enough.
Calling super
Sometimes you want to extend a parent’s behavior, instead of outright changing it to something else. This is where super comes in.
The super keyword will let you call functions defined in a parent contract, even if they are overridden. This mechanism can be used to add additional checks to a function, emit events, or otherwise add functionality as you see fit.
| For more information on how overrides work, head over to the official Solidity documentation. |
Here is a modified version of AccessControl where revokeRole cannot be used to revoke the DEFAULT_ADMIN_ROLE:
Unresolved include directive in modules/ROOT/pages/extending-contracts.adoc - include::api:example$access-control/AccessControlNonRevokableAdmin.sol[]The super.revokeRole statement at the end will invoke AccessControl's original version of revokeRole, the same code that would’ve run if there were no overrides in place.
The same rule is implemented and extended in AccessControlDefaultAdminRules, an extension that also adds enforced security measures for the DEFAULT_ADMIN_ROLE.
|
Security
The maintainers of OpenZeppelin Contracts are mainly concerned with the correctness and security of the code as published in the library, and the combinations of base contracts with the official extensions from the library.
Custom overrides, and those of hooks in particular, may break some important assumptions and introduce vulnerabilities in otherwise secure code. While we try to ensure the contracts remain secure in the face of a wide range of potential customizations, this is done in a best-effort manner. While we try to document all important assumptions, this should not be relied upon. Custom overrides should be carefully reviewed and checked against the source code of the contract they are customizing so as to fully understand their impact and guarantee their security.
The way functions interact internally should not be assumed to stay stable across releases of the library. For example, a function that is used in one context in a particular release may not be used in the same context in the next release. Contracts that override functions should revalidate their assumptions when updating the version of OpenZeppelin Contracts they are built on.