Issue | Instances | |
---|---|---|
L‑1 | Critical functions should be controlled by time locks | 19 |
L‑2 | Owner can renounce Ownership | 2 |
L‑3 | Missing storage gap for upgradable contracts | 1 |
L‑4 | Use Ownable2Step instead of Ownable | 1 |
23 |
It is a good practice to give time for users to react and adjust to critical changes. A timelock provides more guarantees and reduces the level of trust required, thus decreasing risk for users. It also indicates that the project is legitimate (less risk of a malicious owner making a sandwich attack on a user).
Total instances: 19
GitHub: 114, 135, 142, 149, 160, 214, 233
GitHub: 81, 103, 107, 111, 115, 119, 123, 127, 131, 135
GitHub: 182
GitHub: 84
Typically, the contract’s owner is the account that deploys the contract. As a result, the owner is able to perform certain privileged activities.
The Openzeppelin’s Ownable used in this project contract implements renounceOwnership. This can represent a certain risk if the ownership is renounced for any other reason than by design. Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
Total instances: 2
GitHub: 16
GitHub: 11
See description of this storage variable. While some contracts may not currently be sub-classed, adding the variable now protects against forgetting to add it in the future.
Total instances: 1
GitHub: 16
Ownable2Step
and Ownable2StepUpgradeable prevent the contract ownership from mistakenly being transferred to an address that cannot handle it (e.g. due to a typo in the address), by requiring that the recipient of the owner permissions actively accept via a contract call of its own.
Total instances: 1
GitHub: 11
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.