From 0500c9e53e0144d04e2a8d8737c873278da17385 Mon Sep 17 00:00:00 2001 From: William Entriken Date: Tue, 20 Jul 2021 09:35:58 -0400 Subject: [PATCH] Use "OpenZeppelin Contracts" where appropriate (#2778) --- .github/ISSUE_TEMPLATE/feature_request.md | 2 +- CONTRIBUTING.md | 4 ++-- GUIDELINES.md | 2 +- README.md | 8 ++++---- RELEASING.md | 4 ++-- audit/2017-03.md | 2 ++ contracts/token/ERC20/ERC20.sol | 7 ++++--- docs/modules/ROOT/pages/access-control.adoc | 2 +- docs/modules/ROOT/pages/erc20-supply.adoc | 2 +- docs/modules/ROOT/pages/releases-stability.adoc | 2 +- test/TESTING.md | 2 +- 11 files changed, 20 insertions(+), 17 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index ac8771eab..ff596b0c3 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -10,5 +10,5 @@ about: Suggest an idea for OpenZeppelin Contracts **📝 Details** - + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 247396df4..1c55795d1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -49,9 +49,9 @@ npm run lint *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. -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. +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 its a necessary step to keep up with the standards OpenZeppelin attains to. +*IMPORTANT* Please pay attention to the maintainer's feedback, since its a necessary step to keep up with the standards OpenZeppelin Contracts attains to. ## All set! diff --git a/GUIDELINES.md b/GUIDELINES.md index 5ea5566e8..97067500f 100644 --- a/GUIDELINES.md +++ b/GUIDELINES.md @@ -1,7 +1,7 @@ Design Guidelines ======= -These are some global design goals in OpenZeppelin. +These are some global design goals in OpenZeppelin Contracts. #### 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. diff --git a/README.md b/README.md index 63186026b..2a4a7730c 100644 --- a/README.md +++ b/README.md @@ -60,9 +60,9 @@ Finally, you may want to take a look at the [guides on our blog](https://blog.op ## Security -This project is maintained by [OpenZeppelin](https://openzeppelin.com), and developed following our high standards for code quality and security. OpenZeppelin is meant to provide tested and community-audited code, but please use common sense when doing anything that deals with real money! We take no responsibility for your implementation decisions and any security problems you might experience. +This project is maintained by [OpenZeppelin](https://openzeppelin.com), and developed following our high standards for code quality and security. OpenZeppelin Contracts is meant to provide tested and community-audited code, but please use common sense when doing anything that deals with real money! We take no responsibility for your implementation decisions and any security problems you might experience. -The core development principles and strategies that OpenZeppelin is based on include: security in depth, simple and modular code, clarity-driven naming conventions, comprehensive unit testing, pre-and-post-condition sanity checks, code consistency, and regular audits. +The core development principles and strategies that OpenZeppelin Contracts is based on include: security in depth, simple and modular code, clarity-driven naming conventions, comprehensive unit testing, pre-and-post-condition sanity checks, code consistency, and regular audits. The latest audit was done on October 2018 on version 2.0.0. @@ -70,8 +70,8 @@ Please report any security issues you find to security@openzeppelin.org. ## Contribute -OpenZeppelin exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the [contribution guide](CONTRIBUTING.md)! +OpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the [contribution guide](CONTRIBUTING.md)! ## License -OpenZeppelin is released under the [MIT License](LICENSE). +OpenZeppelin Contracts is released under the [MIT License](LICENSE). diff --git a/RELEASING.md b/RELEASING.md index 5840c9c9f..f356ab2e4 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -10,10 +10,10 @@ Publish a release candidate with `npm run release rc`. Publish the final release with `npm run release final`. -Follow the general [OpenZeppelin release checklist]. +Follow the general [OpenZeppelin Contracts release checklist]. [details about release schedule]: https://docs.openzeppelin.com/contracts/releases-stability -[OpenZeppelin release checklist]: https://github.com/OpenZeppelin/code-style/blob/master/RELEASE_CHECKLIST.md +[OpenZeppelin Contracts release checklist]: https://github.com/OpenZeppelin/code-style/blob/master/RELEASE_CHECKLIST.md ## Merging the release branch diff --git a/audit/2017-03.md b/audit/2017-03.md index 51c0b7ab5..53eb702ab 100644 --- a/audit/2017-03.md +++ b/audit/2017-03.md @@ -1,5 +1,7 @@ # OpenZeppelin Audit +NOTE ON 2021-07-19: This report makes reference to Zeppelin, OpenZeppelin, OpenZeppelin [C]ontracts, the OpenZeppelin team, and OpenZeppelin library. Many of these things have since been renamed and know that this audit applies to what is currently called the OpenZeppelin Contracts which are maintained by the OpenZeppelin Conracts Community. + March, 2017 Authored by Dennis Peterson and Peter Vessenes diff --git a/contracts/token/ERC20/ERC20.sol b/contracts/token/ERC20/ERC20.sol index 310eee517..46122eb0a 100644 --- a/contracts/token/ERC20/ERC20.sol +++ b/contracts/token/ERC20/ERC20.sol @@ -17,9 +17,10 @@ import "../../utils/Context.sol"; * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How * to implement supply mechanisms]. * - * We have followed general OpenZeppelin guidelines: functions revert instead - * of returning `false` on failure. This behavior is nonetheless conventional - * and does not conflict with the expectations of ERC20 applications. + * We have followed general OpenZeppelin Contracts guidelines: functions revert + * instead returning `false` on failure. This behavior is nonetheless + * conventional and does not conflict with the expectations of ERC20 + * applications. * * Additionally, an {Approval} event is emitted on calls to {transferFrom}. * This allows applications to reconstruct the allowance for all accounts just diff --git a/docs/modules/ROOT/pages/access-control.adoc b/docs/modules/ROOT/pages/access-control.adoc index c958bf9e9..822bb84b1 100644 --- a/docs/modules/ROOT/pages/access-control.adoc +++ b/docs/modules/ROOT/pages/access-control.adoc @@ -7,7 +7,7 @@ Access control—that is, "who is allowed to do this thing"—is incredibly impo The most common and basic form of access control is the concept of _ownership_: there's an account that is the `owner` of a contract and can do administrative tasks on it. This approach is perfectly reasonable for contracts that have a single administrative user. -OpenZeppelin provides xref:api:access.adoc#Ownable[`Ownable`] for implementing ownership in your contracts. +OpenZeppelin Contracts provides xref:api:access.adoc#Ownable[`Ownable`] for implementing ownership in your contracts. [source,solidity] ---- diff --git a/docs/modules/ROOT/pages/erc20-supply.adoc b/docs/modules/ROOT/pages/erc20-supply.adoc index 84830615d..653e8f655 100644 --- a/docs/modules/ROOT/pages/erc20-supply.adoc +++ b/docs/modules/ROOT/pages/erc20-supply.adoc @@ -108,4 +108,4 @@ contract ERC20WithAutoMinerReward is ERC20 { [[wrapping-up]] == Wrapping Up -We've seen two ways to implement ERC20 supply mechanisms: internally through `_mint`, and externally through `ERC20PresetMinterPauser`. Hopefully this has helped you understand how to use OpenZeppelin and some of the design principles behind it, and you can apply them to your own smart contracts. +We've seen two ways to implement ERC20 supply mechanisms: internally through `_mint`, and externally through `ERC20PresetMinterPauser`. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts. diff --git a/docs/modules/ROOT/pages/releases-stability.adoc b/docs/modules/ROOT/pages/releases-stability.adoc index 4f926c962..a2ced6bb6 100644 --- a/docs/modules/ROOT/pages/releases-stability.adoc +++ b/docs/modules/ROOT/pages/releases-stability.adoc @@ -24,7 +24,7 @@ After several months or a year a new major release may come out. These are not s [[api-stability]] == API Stability -On the https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0[OpenZeppelin 2.0 release], we committed ourselves to keeping a stable API. We aim to more precisely define what we understand by _stable_ and _API_ here, so users of the library can understand these guarantees and be confident their project won't break unexpectedly. +On the https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0[OpenZeppelin Contracts 2.0 release], we committed ourselves to keeping a stable API. We aim to more precisely define what we understand by _stable_ and _API_ here, so users of the library can understand these guarantees and be confident their project won't break unexpectedly. In a nutshell, the API being stable means _if your project is working today, it will continue to do so after a minor upgrade_. New contracts and features will be added in minor releases, but only in a backwards compatible way. diff --git a/test/TESTING.md b/test/TESTING.md index 91464f59f..a5ee9323f 100644 --- a/test/TESTING.md +++ b/test/TESTING.md @@ -1,3 +1,3 @@ ## Testing -Unit test are critical to the OpenZeppelin framework. They help ensure code quality and mitigate against security vulnerabilities. The directory structure within the `/test` directory corresponds to the `/contracts` directory. +Unit test are critical to OpenZeppelin Contracts. They help ensure code quality and mitigate against security vulnerabilities. The directory structure within the `/test` directory corresponds to the `/contracts` directory.