Merge branch 'master' into annotate-multicallUpgradeable

.github/workflows/checks.yml

@@ -87,4 +87,4 @@ jobs:
         uses: codespell-project/actions-codespell@v1.0
         with:
           check_filenames: true
-          skip: package-lock.json
+          skip: package-lock.json,*.pdf

CHANGELOG.md

@@ -11,6 +11,7 @@
  * `Strings`: add `toString` method for signed integers. ([#3773](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3773))
  * `MerkleProof`: optimize by using unchecked arithmetic. ([#3869](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3869))
  * `EnumerableMap`: add a `keys()` function that returns an array containing all the keys. ([#3920](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3920))
+ * `Ownable2Step`: make `acceptOwnership` public virtual to enable usecases that require overriding it. ([#3960](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3960))
  * `Multicall`: annotate `multicall` function as upgrade safe to not raise a flag for its delegatecall. ([#3961](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3961))
 
 ### Deprecations

CODE_OF_CONDUCT.md

@@ -55,7 +55,7 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at maintainers@openzeppelin.org. All
+reported by contacting the project team at contact@openzeppelin.com. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
 obligated to maintain confidentiality with regard to the reporter of an incident.

CONTRIBUTING.md

@@ -1,64 +1,34 @@
-Contributing to OpenZeppelin Contracts
-=======
+# Contributing Guidelines
 
-We really appreciate and value contributions to OpenZeppelin Contracts. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.
+There are many ways to contribute to OpenZeppelin Contracts.
 
-## Contribution guidelines
+## Troubleshooting
 
-Smart contracts manage value and are highly vulnerable to errors and attacks. We have very strict [guidelines], please make sure to review them!
+You can help other users in the community to solve their smart contract issues in the [OpenZeppelin Forum].
 
-## Creating Pull Requests (PRs)
+[OpenZeppelin Forum]: https://forum.openzeppelin.com/
 
-As a contributor, you are expected to fork this repository, work on your own fork and then submit pull requests. The pull requests will be reviewed and eventually merged into the main repo. See ["Fork-a-Repo"](https://help.github.com/articles/fork-a-repo/) for how this works.
+## Opening an issue
 
-## A typical workflow
+You can [open an issue] to suggest a feature or report a minor bug. For serious bugs please do not open an issue, instead refer to our [security policy] for appropriate steps.
 
-1) Make sure your fork is up to date with the main repository:
+If you believe your issue may be due to user error and not a problem in the library, consider instead posting a question on the [OpenZeppelin Forum].
 
-```
-cd openzeppelin-contracts
-git remote add upstream https://github.com/OpenZeppelin/openzeppelin-contracts.git
-git fetch upstream
-git pull --rebase upstream master
-```
-NOTE: The directory `openzeppelin-contracts` represents your fork's local copy.
+Before opening an issue, be sure to search through the existing open and closed issues, and consider posting a comment in one of those instead.
 
-2) Branch out from `master` into `fix/some-bug-#123`:
-(Postfixing #123 will associate your PR with the issue #123 and make everyone's life easier =D)
-```
-git checkout -b fix/some-bug-#123
-```
+When requesting a new feature, include as many details as you can, especially around the use cases that motivate it. Features are prioritized according to the impact they may have on the ecosystem, so we appreciate information showing that the impact could be high.
 
-3) Make your changes, add your files, commit, and push to your fork.
+[security policy]: https://github.com/OpenZeppelin/openzeppelin-contracts/security
+[open an issue]: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/new/choose
 
-```
-git add SomeFile.js
-git commit "Fix some bug #123"
-git push origin fix/some-bug-#123
-```
+## Submitting a pull request
 
-4) Run tests, linter, etc. This can be done by running local continuous integration and make sure it passes.
+If you would like to contribute code or documentation you may do so by forking the repository and submitting a pull request.
 
-```bash
-npm test
-npm run lint
-```
+Any non-trivial code contribution must be first discussed with the maintainers in an issue (see [Opening an issue](#opening-an-issue)). Only very minor changes are accepted without prior discussion.
 
-5) Go to [github.com/OpenZeppelin/openzeppelin-contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) in your web browser and issue a new pull request.
+Make sure to read and follow the [engineering guidelines](./GUIDELINES.md). Run linter and tests to make sure your pull request is good before submitting it.
 
-*IMPORTANT* Read the PR template very carefully and make sure to follow all the instructions. These instructions
-refer to some very important conditions that your PR must meet in order to be accepted, such as making sure that all tests pass, JS linting tests pass, Solidity linting tests pass, etc.
+When opening the pull request you will be presented with a template and a series of instructions. Read through it carefully and follow all the steps. Expect a review and feedback from the maintainers afterwards.
 
-6) Maintainers will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of OpenZeppelin Contracts.
-
-*IMPORTANT* Please pay attention to the maintainer's feedback, since it's a necessary step to keep up with the standards OpenZeppelin Contracts attains to.
-
-## All set!
-
-If you have any questions, feel free to post them to github.com/OpenZeppelin/openzeppelin-contracts/issues.
-
-Finally, if you're looking to collaborate and want to find easy tasks to start, look at the issues we marked as ["Good first issue"](https://github.com/OpenZeppelin/openzeppelin-contracts/labels/good%20first%20issue).
-
-Thanks for your time and code!
-
-[guidelines]: GUIDELINES.md
+If you're looking for a good place to start, look for issues labelled ["good first issue"](https://github.com/OpenZeppelin/openzeppelin-contracts/labels/good%20first%20issue)!

GUIDELINES.md

@@ -1,105 +1,103 @@
-Design Guidelines
-=======
+# Engineering Guidelines
 
-These are some global design goals in OpenZeppelin Contracts.
+## Testing
 
-#### D0 - Security in Depth
-We strive to provide secure, tested, audited code. To achieve this, we need to match intention with function. Thus, documentation, code clarity, community review and security discussions are fundamental.
+Code must be thoroughly tested with quality unit tests.
 
-#### D1 - Simple and Modular
-Simpler code means easier audits, and better understanding of what each component does. We look for small files, small contracts, and small functions. If you can separate a contract into two independent functionalities you should probably do it.
+We defer to the [Moloch Testing Guide](https://github.com/MolochVentures/moloch/tree/master/test#readme) for specific recommendations, though not all of it is relevant here. Note the introduction:
 
-#### D2 - Naming Matters
+> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests are just as important (if not more so) than the code itself, and should be written with the highest standards of clarity and elegance.
 
-We take our time with picking names. Code is going to be written once, and read hundreds of times. Renaming for clarity is encouraged.
+Every addition or change to the code must come with relevant and comprehensive tests.
 
-#### D3 - Tests
+Refactors should avoid simultaneous changes to tests.
 
-Write tests for all your code. We encourage Test Driven Development so we know when our code is right. Even though not all code in the repository is tested at the moment, we aim to test every line of code in the future.
+Flaky tests are not acceptable.
 
-#### D4 - Check preconditions and post-conditions
+The test suite should run automatically for every change in the repository, and in pull requests tests must pass before merging.
 
-A very important way to prevent vulnerabilities is to catch a contract’s inconsistent state as early as possible. This is why we want functions to check pre- and post-conditions for executing its logic. When writing code, ask yourself what you are expecting to be true before and after the function runs, and express it in code.
+The test suite coverage must be kept as close to 100% as possible, enforced in pull requests.
 
-#### D5 - Code Consistency
+In some cases unit tests may be insufficient and complementary techniques should be used:
 
-Consistency on the way classes are used is paramount to an easier understanding of the library. The codebase should be as unified as possible. Read existing code and get inspired before you write your own. Follow the style guidelines. Don’t hesitate to ask for help on how to best write a specific piece of code.
+1. Property-based tests (aka. fuzzing) for math-heavy code.
+2. Formal verification for state machines.
 
-#### D6 - Regular Audits
-Following good programming practices is a way to reduce the risk of vulnerabilities, but professional code audits are still needed. We will perform regular code audits on major releases, and hire security professionals to provide independent review.
+## Code style
 
-# Style Guidelines
+Solidity code should be written in a consistent format enforced by a linter, following the official [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html). See below for further [Solidity Conventions](#solidity-conventions).
 
-The design guidelines have quite a high abstraction level. These style guidelines are more concrete and easier to apply, and also more opinionated. We value clean code and consistency, and those are prerequisites for us to include new code in the repository. Before proposing a change, please read these guidelines and take some time to familiarize yourself with the style of the existing codebase.
+The code should be simple and straightforward, prioritizing readability and understandability. Consistency and predictability should be maintained across the codebase. In particular, this applies to naming, which should be systematic, clear, and concise.
 
-## Solidity code
+Sometimes these guidelines may be broken if doing so brings significant efficiency gains, but explanatory comments should be added.
 
-In order to be consistent with all the other Solidity projects, we follow the
-[official recommendations documented in the Solidity style guide](http://solidity.readthedocs.io/en/latest/style-guide.html).
+Modularity should be pursued, but not at the cost of the above priorities.
 
-Any exception or additions specific to our project are documented below.
+## Documentation
 
-* Try to avoid acronyms and abbreviations.
+For contributors, project guidelines and processes must be documented publicly.
 
-* All state variables should be private.
+For users, features must be abundantly documented. Documentation should include answers to common questions, solutions to common problems, and recommendations for critical decisions that the user may face.
 
-* Private state variables should have an underscore prefix.
+All changes to the core codebase (excluding tests, auxiliary scripts, etc.) must be documented in a changelog, except for purely cosmetic or documentation changes.
 
-    ```
-    contract TestContract {
-      uint256 private _privateVar;
-      uint256 internal _internalVar;
-    }
-    ```
+## Peer review
+
+All changes must be submitted through pull requests and go through peer code review.
+
+The review must be approached by the reviewer in a similar way as if it was an audit of the code in question (but importantly it is not a substitute for and should not be considered an audit).
+
+Reviewers should enforce code and project guidelines.
 
-* Parameters must not be prefixed with an underscore.
+External contributions must be reviewed separately by multiple maintainers.
 
-    ```
-    function test(uint256 testParameter1, uint256 testParameter2) {
-    ...
-    }
-    ```
+## Automation
 
-* Internal and private functions should have an underscore prefix.
+Automation should be used as much as possible to reduce the possibility of human error and forgetfulness.
 
-    ```
-    function _testInternal() internal {
-      ...
-    }
-    ```
+Automations that make use of sensitive credentials must use secure secret management, and must be strengthened against attacks such as [those on GitHub Actions worklows](https://github.com/nikitastupin/pwnhub).
 
-    ```
-    function _testPrivate() private {
-      ...
-    }
-    ```
+Some other examples of automation are:
+
+- Looking for common security vulnerabilities or errors in our code (eg. reentrancy analysis).
+- Keeping dependencies up to date and monitoring for vulnerable dependencies.
+
+# Solidity Conventions
+
+In addition to the official Solidity Style Guide we have a number of other conventions that must be followed.
+
+* All state variables should be private.
+
+  Changes to state should be accompanied by events, and in some cases it is not correct to arbitrarily set state. Encapsulating variables as private and only allowing modification via setters enables us to ensure that events and other rules are followed reliably and prevents this kind of user error.
+
+* Internal or private state variables or functions should have an underscore prefix.
+
+  ```
+  contract TestContract {
+      uint256 private _privateVar;
+      uint256 internal _internalVar;
+      function _testInternal() internal { ... }
+      function _testPrivate() private { ... }
+  }
+  ```
 
 * Events should be emitted immediately after the state change that they
-  represent, and consequently they should be named in past tense.
+  represent, and should be named in the past tense.
 
-    ```
-    function _burn(address who, uint256 value) internal {
+  ```
+  function _burn(address who, uint256 value) internal {
       super._burn(who, value);
       emit TokensBurned(who, value);
-    }
-    ```
+  }
+  ```
 
   Some standards (e.g. ERC20) use present tense, and in those cases the
-  standard specification prevails.
+  standard specification is used.
 
 * Interface names should have a capital I prefix.
 
-    ```
-    interface IERC777 {
-    ```
-
-
-## Tests
-
-* Tests Must be Written Elegantly
-
-    Tests are a good way to show how to use the library, and maintaining them is extremely necessary. Don't write long tests, write helper functions to make them be as short and concise as possible (they should take just a few lines each), and use good variable names.
-
-* Tests Must not be Random
+  ```
+  interface IERC777 {
+  ```
 
-    Inputs for tests should not be generated randomly. Accounts used to create test contracts are an exception, those can be random. Also, the type and structure of outputs should be checked.
+* Unchecked arithmetic blocks should contain comments explaining why overflow is guaranteed not to happen. If the reason is immediately apparent from the line above the unchecked block, the comment may be omitted.

LICENSE

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) 2016-2022 zOS Global Limited and contributors
+Copyright (c) 2016-2023 zOS Global Limited and contributors
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the