* Removing the storage associated with decimals
* changelog entry
* changelog link to new issue number
* Update contracts/token/ERC20/ERC20.sol
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* Update contracts/token/ERC20/ERC20.sol
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* Update CHANGELOG.md
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* Clean code
- using type().interfaceId to improve readeability of ERC165 registration
- hardcoding some keccak256 that are otherwise computed at construction.
* hardcode keccak256 result
* Improve code readeability using try/catch
* Remove hardcoded hash
tests show that solc 0.8.0 does the optimization as expected
* Use try/catch to improve readability
* ERC165Checker: Do not revert when returndata is empty + new test
* Address PR comments
* improve testing of ERC721Receiver errors
* put back comment about invalid interface id
* coverage does not support 0.8.1. Reverting back to 0.8.0
* bubble all data with length > 0 if onERC721Receive fails.
* Fix test: revert without message trigger is bubble with the default message
* using enum object to improve readability
* Fix unnamed return variable warning
This commit fixes warnings thrown by the solc 0.7.4 compiler:
"Warning: Unnamed return variable can remain unassigned. Add an explicit
return with value to all non-reverting code paths or name the variable."
* Fix function state mutability warning
This commit fixes warnings thrown by the solc 0.7.4 compiler:
"Warning: Function state mutability can be restricted to pure"
* Fix shadows an existing declaration warning
This commit fixes warnings thrown by the solc 0.7.4 compiler:
"Warning: This declaration shadows an existing declaration."
1. Arguments by default are not underscored.
2. If the name isn't available due to shadowing, use prefix underscore.
3. If prefix underscore isn't available due to shadowing, use suffix underscore.
* docs: add notes explaining presets
* fix links for mint function
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* feature: setting sublevel test scenario for AddressSet
* feat: adding tests for EnumerableSet.UintSet
* feat: adding Behavior and AddressSet and UintSet tests
* Initial ERC1155 implementation with some tests (#1803)
* Initial ERC1155 implementation with some tests
* Remove mocked isERC1155TokenReceiver
* Revert reason edit nit
* Remove parameters associated with isERC1155TokenReceiver call
* Add tests for approvals and single transfers
* Add tests for transferring to contracts
* Add tests for batch transfers
* Make expectEvent.inTransaction tests async
* Renamed "owner" to "account" and "holder"
* Document unspecified balanceOfBatch reversion on zero behavior
* Ensure accounts can't set their own operator status
* Specify descriptive messages for underflow errors
* Bring SafeMath.add calls in line with OZ style
* Explicitly prevent _burn on the zero account
* Implement batch minting/burning
* Refactored operator approval check into isApprovedForAll calls
* Renamed ERC1155TokenReceiver to ERC1155Receiver
* Added ERC1155Holder
* Fix lint issues
* Migrate tests to @openzeppelin/test-environment
* port ERC1155 to Solidity 0.6
* make ERC1155 constructor more similar to ERC721 one
* also migrate mock contracts to Solidity 0.6
* mark all non-view functions as virtual
* add simple catch-all implementation for the metadata URI interface
* include an internal function to set the URI so users can implement functionality to switch URIs
* add tests for ERC1155 metadata URI
* fix nits, mostly pointed out by linter
* convert ERC1155 metadata URI work to Solidity 0.6
* mark all non-view functions as virtual
* Port ERC 1155 branch to Solidity 0.6 (and current master) (#2130)
* port ERC1155 to Solidity 0.6
* make ERC1155 constructor more similar to ERC721 one
* also migrate mock contracts to Solidity 0.6
* mark all non-view functions as virtual
* Update contracts/token/ERC1155/IERC1155MetadataURI.sol
Starting on Solidity v0.6.2, interfaces can now inherit. \o/
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
* Fix compile errors
* Remove URI event
* Merge MetadataCatchAll into ERC1155
* Improve documentation.
* Simplify tests
* Move tests into ERC1155 tests
* Update documentation
* Bump minimum compiler version for inteface inheritance
* Fix holder tests
* Improve setUri docs
* Fix docs generation
Co-authored-by: Alan Lu <alanlu1023@gmail.com>
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* update test-helpers to 0.5.6-rc.0
* remove comment that no longer applies
* fix uses of expectEvent.notEmitted
* remove mocha only
* update to final version
* Update test/token/ERC777/ERC777.test.js
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
tweak intro dev comment to reflect more typical use case, wrapping an `IERC20` reference for a deposit contract using others' ERC-20 tokens. I might be mistaken ~ but typically SafeERC20 won't be used in conjunction with ERC20 for OZ token deployments?
* Initial ERC1155 implementation with some tests (#1803)
* Initial ERC1155 implementation with some tests
* Remove mocked isERC1155TokenReceiver
* Revert reason edit nit
* Remove parameters associated with isERC1155TokenReceiver call
* Add tests for approvals and single transfers
* Add tests for transferring to contracts
* Add tests for batch transfers
* Make expectEvent.inTransaction tests async
* Renamed "owner" to "account" and "holder"
* Document unspecified balanceOfBatch reversion on zero behavior
* Ensure accounts can't set their own operator status
* Specify descriptive messages for underflow errors
* Bring SafeMath.add calls in line with OZ style
* Explicitly prevent _burn on the zero account
* Implement batch minting/burning
* Refactored operator approval check into isApprovedForAll calls
* Renamed ERC1155TokenReceiver to ERC1155Receiver
* Added ERC1155Holder
* Fix lint issues
* Migrate tests to @openzeppelin/test-environment
* Port ERC 1155 branch to Solidity 0.6 (and current master) (#2130)
* port ERC1155 to Solidity 0.6
* make ERC1155 constructor more similar to ERC721 one
* also migrate mock contracts to Solidity 0.6
* mark all non-view functions as virtual
Co-authored-by: Alan Lu <alanlu1023@gmail.com>
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
Co-authored-by: Robert Kaiser <kairo@kairo.at>
* Improve ERC20/721 Pausable docs
* Add ERC20Pausable mint and burn tests
* Add ERC721Pausable mint and burn tests
* Add _beforeTransfer hook in ERC777 to mint and burn
* provide 'automatic' token URI by appending the token ID to the base URI, if a base is set but no token-specific URI is available
* make the three cases more explicit, avoid else after return
* adjust comments to reflect reality
* Update access-control.adoc to make compile
Add call to `ERC20("MyToken", "TKN")` in `MyToken` constructor
* Update access-control.adoc to make compile
Add call to `ERC20("MyToken", "TKN")` in `MyToken` constructor
* Update access-control.adoc MyToken formatting
* Update erc20-supply.adoc to make compile
Add call to `ERC20("MyToken", "TKN")` in `ERC20FixedSupply` constructor
* Update erc20-supply.adoc to make compile
Add constructor to `ERC20WithMinerReward`
* Update erc20-supply.adoc to make compile
In `MinerRewardMinter` use `ERC20MinterPauser`
* Update erc20-supply.adoc to make compile
Add constructor and override to `ERC20WithAutoMinerReward`
* Update erc777.adoc to make compile
* Update gsn-strategies.adoc to make compile
* Update gsn-strategies.adoc to make compile
Fix imports, add overrides, and revert reason to `MyContract`
* Update docs for ERC20 and ERC721
* Add EnumerableMap to docs
* Update misc guides
* Apply suggestions from code review
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* Implement AddressSet in terms of a generic Set
* Add Uint256Set
* Add EnumerableMap
* Fix wording on EnumerableSet docs and tests
* Refactor ERC721 using EnumerableSet and EnumerableMap
* Fix tests
* Fix linter error
* Gas optimization for EnumerableMap
* Gas optimization for EnumerableSet
* Remove often not-taken if from Enumerable data structures
* Fix failing test
* Gas optimization for EnumerableMap
* Fix linter errors
* Add comment for clarification
* Improve test naming
* Rename EnumerableMap.add to set
* Add overload for EnumerableMap.get with custom error message
* Improve Enumerable docs
* Rename Uint256Set to UintSet
* Add changelog entry
* Remove _grantRole and _revokeRole, replace with _setupRole
* Make all external AccessControl functions public
* Remove Ownable._transferOwnership
* Rename ERC721's _safeTransferFrom and _transferFrom to _safeTransfer and _transfer
* Make all ERC721 external functions public
* Make all miscelaneous external functions public instead
* Add changelog entry
* Move calldata arguments to memory
* Update contracts/access/AccessControl.sol
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Restrict setupRole to the constructor
* Replace isConstructor for !isContract
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
* Add revert if the bytecode length is not greater than zero
* Add value parameter to create2 deploy function
Add tests for contract balance revert and depositing funds
* Change parameter name to amount for clarity
* Fix test for value sending
* Fix linter error
* Change revert reason
* Improve Create2.deploy documentation
* Slight test improvement
* Add changelog entry
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
* Add revert reason to EnumerableSet.get.
* Rename EnumerableSet values to keys
* Rename get to at
* Add changelog entry
* Rename keys to values
* Add leading underscore to struct members
* Add signed to unsigned conversion to SafeCast
* Update SafeCast exception message
* Add test for SafeCast int to uint conversion
- Update SafeCastMock
- Add tests for SafeCast int256 to uint256
* Update SafeCast int to uint definition
Apply suggestions from code review.
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* Update test for SafeCast int to uint conversion
* Update SafeCast test after code review
- Change "downcasts" to "casts"
- Move test closer to its function
* Fix error in SafeCast toUint256 description
* Fix breaking error in SafeCast
* Add uint256 to int256 conversion to SafeCast
- Add function
- Add mock
- Add test
* Update SafeCast unsigned to signed conversion
- Update error in conversion to be more clear
- Update constants in test to be powers of 2 instead of shifts
* Add changelog entry
* Update SafeCast tests
- Add minus in INT256_MIN for clarity
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
* Remove Roles
* Add AccessControl and tests
* Removed IAccessControl
* Add RoleGranted and RoleRevoked events
* Make roles grantable and revokable regardless of their previous status
* Fix typo
* Add documentation
* Cleanup tests
* Add enumeration tests
* Add _setRoleAdmin tests
* Fix lint error
* Fix AccessControl link in docs
* WIP on access control guide
* Rename getRoleMembersCount
* Add tests for new role admin
* Make AccessControl GSN compatible
* Update access control guide
* Rename admin to adminRole
* Rename roleIds to roles
* Add 'operator' to RoleGranted and RoleRevoked events.
* Only emit events if the roles were not previously granted/revoked
* Uncomment expectEvent.not tests
* Rename operator to sender
* Add changelog entry
In https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/pull/76, we are rearranging the erc721metadata contract storage layout, so the new variable is added at the end. This commit applies the same change to the vanilla contracts repository, so migration from 2.5 to 3.0 is easier for users using the transpiler.
* adding mock contacts, test code
* adding changes to ERC721.sol per @frangio's comments on original PR #1943
* fix solhint warnings
* Update contracts/token/ERC721/ERC721.sol
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* same revert wording per @frangio's review suggestion
* per @frangio's feedback, changing the inline assembly to accomplish: we want to ignore the first 4 bytes of content, so we should read the length and decrease it by 4, then take the memory location and add 4 to it, then store the new length at the new memory location, then that is the new byte array that we want.
* change revert msg assembly per PR comment by @frangio
* unify revert msg in test code
* fix some failed tests, wording change
* Update contracts/token/ERC721/ERC721.sol
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Update contracts/token/ERC721/ERC721.sol
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* fix test case, revert without reason
* fix 'ERC721ReceiverRevertsMock: Transaction rejected by receiver'
* style change per review by @frangio
* fix revert reason forwarding
* remove duplicate contracts/mocks/ERC721ReceiverRevertsMock.sol per review https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2018\#issuecomment-574381034
* Add changelog entry
* Fix tests
* Make tests more clear
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
* Reorder navbar
* Adapt content to new docsite structure, add links
* Fix list
* fix list
* Apply suggestions from code review
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Update index.adoc
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
Code sample for MyCrowdsaleDeployer causes TypeError:
```
browser/MyCrowdsaleDeployer.sol:21:13: TypeError: Invalid type for argument in function call.
Invalid implicit conversion from address to contract IERC20 requested.
address(token) // the token
^------------^
```
Change:
```solidity
address(token) // the token
```
To:
```solidity
token // the token
```
Reported by community member in the forum: https://forum.openzeppelin.com/t/invalid-implicit-conversion-from-address-to-contract-ierc20-requested/1937
* Changes ERC777 external functions to public for allowing overrides #1994
* Changes ERC777 external functions to public for allowing overrides (#1994)
* Update ReentrancyGuard for Istanbul Hard Fork
Changes:
Added L37, `_guardCounter = 1;`
Rationale:
The planned _Istanbul Hard Fork_ will implement [EIP 2200](e4d4ea348e/EIPS/eip-2200.md), which implements "net gas metering" for `sstore` operations. If the final value of `_guardCounter` is unchanged relative to the original value of it, a gas refund will be applied and charges for changing the value of `_guardCounter` will effectively not exist. This ends up being cheaper than the current implementation ONLY AFTER Istanbul. Before Istanbul, the added line actually ends up costing more gas.
Note that if `_guardCounter` is `0` initially, the initial cost and subsequent refund will both be larger than if `_guardCounter` is `1` initially. Although in both cases, the net gas cost (`gasCost - gasRefund`) are equal, it's better in terms of cost to have both the gas cost and refund smaller, as there is some limit to the percentage of a gas refund that can actually be realized.
* Update CHANGELOG.md
Added note for change to ReentrancyGuard.sol
* Update ReentrancyGuard.sol
* Update CHANGELOG.md
* Merge GSNBouncerBase into GSNRecipient
* Remove emtpy implementations for _pre and _post
* Rename bouncers to recipients
* Rename bouncers documentation to strategies
* Rewrite guides and docstrings to use the strategy naming scheme
* Address review comments
* Apply suggestions from code review
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* change wording of docs
(cherry picked from commit aae95db4e0)
* switch index to show arg names
* add index separators
* add classes to style variable type and name
* add class for inherited part of index
* use inheritedItems in contracts template
* refactor template to use explicit if and each
(cherry picked from commit 5d6a040fc3)
* GSNSignatureBoucer does not accept zero address
* Linting code.
* Update contracts/GSN/bouncers/GSNBouncerSignature.sol
Makes sense!
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* Update test/GSN/GSNBouncerSignature.test.js
ok!
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* Add zero address constant from OZ test Helpers
* revert prettier formatting
(cherry picked from commit f9a94788fb)
* Fix typo
* Replace pseudo code contracts with sample code
* Update GSN Bouncers text
* More text changes
* Update with latest code and remove reference to allowance
* Capitalize Custom Bouncer
* Update docs/modules/ROOT/pages/gsn-bouncers.adoc
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Update gsn-bouncers.adoc with Antora cross reference
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Revert to handling msg.sender msg.data differently
* Change by default to simplest implementation
* Change signing to include signature for GSNBouncerSignature
* Reword summary of what is in the guide
* Remove "The" from before `GSNBouncer...`
* Fix code snippet markdown
* Change to API references to xref:api
* Remove code from How it works sections
* Explain 1:1 exchange rate
* Change transaction request to relayed call
* Minor fixes
* Add info to Custom Bouncers
* Typo
* Minor fixes
* reorder sentence based on review gsn-bouncers.adoc
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Improve wording of signing of relayed call parameters by trusted signer
(cherry picked from commit 18473d0100)
* Improve IRelayRecipient docs
* Fix link
* Update IRelayHub docs to the docsite format
* Update IRelayRecipient docs to the dociste format
* Fix typo
* Improve GSN readme
* Fix link
* Update GSNRecipient docs
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
(cherry picked from commit d864228624)
* Merge GSNBouncerBase into GSNRecipient
* Remove emtpy implementations for _pre and _post
* Rename bouncers to recipients
* Rename bouncers documentation to strategies
* Rewrite guides and docstrings to use the strategy naming scheme
* Address review comments
* Apply suggestions from code review
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* change wording of docs
* switch index to show arg names
* add index separators
* add classes to style variable type and name
* add class for inherited part of index
* use inheritedItems in contracts template
* refactor template to use explicit if and each
* GSNSignatureBoucer does not accept zero address
* Linting code.
* Update contracts/GSN/bouncers/GSNBouncerSignature.sol
Makes sense!
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* Update test/GSN/GSNBouncerSignature.test.js
ok!
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* Add zero address constant from OZ test Helpers
* revert prettier formatting
* Fix typo
* Replace pseudo code contracts with sample code
* Update GSN Bouncers text
* More text changes
* Update with latest code and remove reference to allowance
* Capitalize Custom Bouncer
* Update docs/modules/ROOT/pages/gsn-bouncers.adoc
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Update gsn-bouncers.adoc with Antora cross reference
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Revert to handling msg.sender msg.data differently
* Change by default to simplest implementation
* Change signing to include signature for GSNBouncerSignature
* Reword summary of what is in the guide
* Remove "The" from before `GSNBouncer...`
* Fix code snippet markdown
* Change to API references to xref:api
* Remove code from How it works sections
* Explain 1:1 exchange rate
* Change transaction request to relayed call
* Minor fixes
* Add info to Custom Bouncers
* Typo
* Minor fixes
* reorder sentence based on review gsn-bouncers.adoc
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Improve wording of signing of relayed call parameters by trusted signer
* refactor(ERC165Checker) replaced assembly code with function
* returned false if result.length==0
* trigger ci
* updated ERC165Checker to return false if result.length < 32
* Improve IRelayRecipient docs
* Fix link
* Update IRelayHub docs to the docsite format
* Update IRelayRecipient docs to the dociste format
* Fix typo
* Improve GSN readme
* Fix link
* Update GSNRecipient docs
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
* Apply suggestions from code review
Co-Authored-By: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
* Adding in "<<: *defaults" under "coverage"
* Refactoring by capturing similar setup commands into single alias
* Reverting changes, I am not certain exactly how to refactor these setup steps, but at least the &default refactor can be made.
* move gsn link
* change underscore to dash
* add content to gsn api ref
* change link of GSN announcement
* Update contracts/GSN/bouncers/GSNBouncerERC20Fee.sol
Co-Authored-By: Nicolás Venturo <nicolas.venturo@gmail.com>
* fix crossreference to gsn guide
* Remove intro from gsn guide
We are moving the intro to the top-level in the docsite, and focusing this guide into writing gsn-enabled contracts.
* Update docs/modules/ROOT/pages/gsn.adoc
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Update gsn.adoc
* Update gsn_advanced.adoc
Line 15 - where it says, "prevent malicious users from spending the transactions subsidy", with transactions subsidy, is it supposed to be possessive "transaction's subsidy" or is the plural in the wrong place "transaction subsidies"?
Line 176 - where it says "or it is not allowed to spend that amount". Is IT referring to the sender/person or the tx? If IT refers to a person, then change to "or they are not allowed..." for gender neutral.
Line 213 - Where it says, "Please not how the gas cost estimation", a verb is missing, please what?
* Update gsn_advanced.adoc
Apply suggestions by Amy
* switch to using Context internally
* add context import
* Add smoke test to make sure enabling GSN support works
* Update test/GSN/ERC721GSNRecipientMock.test.js
Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>
* Upgrade truffle
* add missing awaits
* Revert "Upgrade truffle"
This reverts commit f9b0ba9019.
* Add base Context contract
* Add GSNContext and tests
* Add RelayHub deployment to tests
* Add RelayProvider integration, complete GSNContext tests
* Switch dependency to openzeppelin-gsn-provider
* Add default txfee to provider
* Add basic signing recipient
* Sign more values
* Add comment clarifying RelayHub's msg.data
* Make context constructors internal
* Rename SigningRecipient to GSNRecipientSignedData
* Add ERC20Charge recipients
* Harcode RelayHub address into GSNContext
* Fix Solidity linter errors
* Run server from binary, use gsn-helpers to fund it
* Migrate to published @openzeppelin/gsn-helpers
* Silence false-positive compiler warning
* Use GSN helper assertions
* Rename meta-tx to gsn, take out of drafts
* Merge ERC20 charge recipients into a single one
* Rename GSNRecipients to Bouncers
* Add GSNBouncerUtils to decouple the bouncers from GSNRecipient
* Add _upgradeRelayHub
* Store RelayHub address using unstructored storage
* Add IRelayHub
* Add _withdrawDeposits to GSNRecipient
* Add relayHub version to recipient
* Make _acceptRelayedCall and _declineRelayedCall easier to use
* Rename GSNBouncerUtils to GSNBouncerBase, make it IRelayRecipient
* Improve GSNBouncerBase, make pre and post sender-protected and optional
* Fix GSNBouncerERC20Fee, add tests
* Add missing GSNBouncerSignature test
* Override transferFrom in __unstable__ERC20PrimaryAdmin
* Fix gsn dependencies in package.json
* Rhub address slot reduced by 1
* Rename relay hub changed event
* Use released gsn-provider
* Run relayer with short sleep of 1s instead of 100ms
* update package-lock.json
* clear circle cache
* use optimized gsn-provider
* update to latest @openzeppelin/gsn-provider
* replace with gsn dev provider
* remove relay server
* rename arguments in approveFunction
* fix GSNBouncerSignature test
* change gsn txfee
* initialize development provider only once
* update RelayHub interface
* adapt to new IRelayHub.withdraw
* update @openzeppelin/gsn-helpers
* update relayhub singleton address
* fix helper name
* set up gsn provider for coverage too
* lint
* Revert "set up gsn provider for coverage too"
This reverts commit 8a7b5be5f9.
* remove unused code
* add gsn provider to coverage
* move truffle contract options back out
* increase gas limit for coverage
* remove unreachable code
* add more gas for GSNContext test
* fix test suite name
* rename GSNBouncerBase internal API
* remove onlyRelayHub modifier
* add explicit inheritance
* remove redundant event
* update name of bouncers error codes enums
* add basic docs page for gsn contracts
* make gsn directory all caps
* add changelog entry
* lint
* enable test run to fail in coverage
* Add circlci, remove .travis.yml. Fixes#1839.
* Fix circleci config
* Add slack notification
* Add circleci status
* Fix config.yml, we don't need separate truffle image and instances.
* Matches oz-sdk node version
* Seems node:10.13 doesn't work for CircleCI either
* Remove npm update in circleci
* CircleCI use package-lock.json as cache key and install only the lock version
* Add back travis.yml
* Rename job build to test
* CircleCI requires that job to be called build instead of test or build_and_test
* Fix the way to run jobs
* Fix CircleCI
* Change back to npm install
* Add workflow and split into tasks
* Add workspace
* Restore cache
* update readme circleci instructions
* make step name more accurate
* added _safeTransferFrom function
* added safeMint functions
* added package-lock.json for consistency, don't know why it changes
* added initial suggestions/modifications
* change _safeTransferFrom to internal, reverted package-lock.json to original, and changed ERC721Pausable to override _transferFrom instead of transferFrom
* included tests for safeMint functions
* modified safeMint tests to be on ERC721Mock contract
* added safeMint to ERC721Mintable & respective test to ERC721MintBurn.behavior.js
* Rename package and repository name from docs and scripts
* undo root package rename
* add @openzeppelin/contracts as subpackage with release automation
* synchronize @openzeppelin/contracts version
* remove private field from package.json
* make file patterns absolute
* change wording of a comment
* use a saner version script
* Using extcodehash instead of extcodesize for less gas
`extcodehash` uses less gas then `extcodesize`. You can tell which address is a contract by the hash (see EIP-1052).
* Fix
* Add explainer
* Update Address.sol
* add changelog entry
* Simplification and optimization of existing contracts #8888
* Simplification of SimpleToken
* This is the fixed Simplification
* My bad I'm playing around with this git stuff, should be correct now
* add missing parenthesis
* Updated code style to no more than120 characters per line.
* Unify code comments style with Doxygen-style tags.
* Fix the conflicts.
* Add a return value in the contract ERC20Burnable.
* A Add a wrapper function to change type of address to address payable.
* U Modify Address utils.
* A Add test case for Address.
* U Modify code style in ERC20Burnable.
* Add changelog entry.
* Improved dev docs.
* update truffle to 5.0.14
* fix setup to test with solc-nightly
* switch to npx in script/test.sh
* please the linter
* rename build to prepack
* move download of nightly build to a compile script
* make compile script executable
<!-- Briefly describe the issue you're experiencing. Tell us what you were trying to do and what happened instead. -->
<!-- Remember, this is not a place to ask for help debugging code. For that, we welcome you in the Zeppelin Forum: https://forum.zeppelin.solutions/. -->
<!-- Remember, this is not a place to ask for help debugging code. For that, we welcome you in the OpenZeppelin Community Forum: https://forum.openzeppelin.com/. -->
**💻 Environment**
<!-- Tell us what version of OpenZeppelin you're using, and how you're using it: Truffle, Remix, etc. -->
<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->
*`ERC1155Supply`: Handle `totalSupply` changes by hooking into `_beforeTokenTransfer` to ensure consistency of balances and supply during `IERC1155Receiver.onERC1155Received` calls.
## 4.3.2 (2021-09-14)
*`UUPSUpgradeable`: Add modifiers to prevent `upgradeTo` and `upgradeToAndCall` being executed on any contract that is not the active ERC1967 proxy. This prevents these functions being called on implementation contracts or minimal ERC1167 clones, in particular.
*`ERC2771Context`: use private variable from storage to store the forwarder address. Fixes issues where `_msgSender()` was not callable from constructors. ([#2754](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2754))
*`EnumerableSet`: add `values()` functions that returns an array containing all values in a single call. ([#2768](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2768))
*`Governor`: added a modular system of `Governor` contracts based on `GovernorAlpha` and `GovernorBravo`. ([#2672](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2672))
* Add an `interfaces` folder containing solidity interfaces to final ERCs. ([#2517](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2517))
*`ECDSA`: add `tryRecover` functions that will not throw if the signature is invalid, and will return an error flag instead. ([#2661](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2661))
*`SignatureChecker`: Reduce gas usage of the `isValidSignatureNow` function for the "signature by EOA" case. ([#2661](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2661))
## 4.2.0 (2021-06-30)
*`ERC20Votes`: add a new extension of the `ERC20` token with support for voting snapshots and delegation. ([#2632](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2632))
*`ERC20VotesComp`: Variant of `ERC20Votes` that is compatible with Compound's `Comp` token interface but restricts supply to `uint96`. ([#2706](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2706))
*`ERC20Wrapper`: add a new extension of the `ERC20` token which wraps an underlying token. Deposit and withdraw guarantee that the total supply is backed by a corresponding amount of underlying token. ([#2633](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2633))
* Enumerables: Improve gas cost of removal in `EnumerableSet` and `EnumerableMap`.
* Enumerables: Improve gas cost of lookup in `EnumerableSet` and `EnumerableMap`.
*`Counter`: add a reset method. ([#2678](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2678))
* Tokens: Wrap definitely safe subtractions in `unchecked` blocks.
*`Math`: Add a `ceilDiv` method for performing ceiling division.
*`ERC1155Supply`: add a new `ERC1155` extension that keeps track of the totalSupply of each tokenId. ([#2593](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2593))
*`BitMaps`: add a new `BitMaps` library that provides a storage efficient datastructure for `uint256` to `bool` mapping with contiguous keys. ([#2710](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2710))
### Breaking Changes
*`ERC20FlashMint` is no longer a Draft ERC. ([#2673](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2673)))
**How to update:** Change your import paths by removing the `draft-` prefix from `@openzeppelin/contracts/token/ERC20/extensions/draft-ERC20FlashMint.sol`.
> See [Releases and Stability: Drafts](https://docs.openzeppelin.com/contracts/4.x/releases-stability#drafts).
## 4.1.0 (2021-04-29)
*`IERC20Metadata`: add a new extended interface that includes the optional `name()`, `symbol()` and `decimals()` functions. ([#2561](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2561))
*`ERC777`: make reception acquirement optional in `_mint`. ([#2552](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2552))
*`ERC20Permit`: add a `_useNonce` to enable further usage of ERC712 signatures. ([#2565](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2565))
*`ERC20FlashMint`: add an implementation of the ERC3156 extension for flash-minting ERC20 tokens. ([#2543](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2543))
*`SignatureChecker`: add a signature verification library that supports both EOA and ERC1271 compliant contracts as signers. ([#2532](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2532))
*`Multicall`: add abstract contract with `multicall(bytes[] calldata data)` function to bundle multiple calls together ([#2608](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2608))
*`ECDSA`: add support for ERC2098 short-signatures. ([#2582](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2582))
*`AccessControl`: add a `onlyRole` modifier to restrict specific function to callers bearing a specific role. ([#2609](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2609))
*`StorageSlot`: add a library for reading and writing primitive types to specific storage slots. ([#2542](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2542))
* UUPS Proxies: add `UUPSUpgradeable` to implement the UUPS proxy pattern together with `EIP1967Proxy`. ([#2542](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2542))
### Breaking changes
This release includes two small breaking changes in `TimelockController`.
1. The `onlyRole` modifier in this contract was designed to let anyone through if the role was granted to `address(0)`,
allowing the possibility to to make a role "open", which can be used for `EXECUTOR_ROLE`. This modifier is now
replaced by `AccessControl.onlyRole`, which does not have this ability. The previous behavior was moved to the
modifier `TimelockController.onlyRoleOrOpenRole`.
2. It was possible to make `PROPOSER_ROLE` an open role (as described in the previous item) if it was granted to
`address(0)`. This would affect the `schedule`, `scheduleBatch`, and `cancel` operations in `TimelockController`.
This ability was removed as it does not make sense to open up the `PROPOSER_ROLE` in the same way that it does for
`EXECUTOR_ROLE`.
## 4.0.0 (2021-03-23)
* Now targeting the 0.8.x line of Solidity compilers. For 0.6.x (resp 0.7.x) support, use version 3.4.0 (resp 3.4.0-solc-0.7) of OpenZeppelin.
*`Context`: making `_msgData` return `bytes calldata` instead of `bytes memory` ([#2492](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2492))
*`ERC20`: removed the `_setDecimals` function and the storage slot associated to decimals. ([#2502](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2502))
*`Strings`: addition of a `toHexString` function. ([#2504](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2504))
*`EnumerableMap`: change implementation to optimize for `key → value` lookups instead of enumeration. ([#2518](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2518))
*`GSN`: deprecate GSNv1 support in favor of upcoming support for GSNv2. ([#2521](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2521))
*`ERC165`: remove uses of storage in the base ERC165 implementation. ERC165 based contracts now use storage-less virtual functions. Old behavior remains available in the `ERC165Storage` extension. ([#2505](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2505))
*`Initializable`: make initializer check stricter during construction. ([#2531](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2531))
*`ERC721`: remove enumerability of tokens from the base implementation. This feature is now provided separately through the `ERC721Enumerable` extension. ([#2511](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2511))
*`AccessControl`: removed enumerability by default for a more lightweight contract. It is now opt-in through `AccessControlEnumerable`. ([#2512](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2512))
* Meta Transactions: add `ERC2771Context` and a `MinimalForwarder` for meta-transactions. ([#2508](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2508))
* Overall reorganization of the contract folder to improve clarity and discoverability. ([#2503](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2503))
*`ERC20Capped`: optimize gas usage by enforcing the check directly in `_mint`. ([#2524](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2524))
* Rename `UpgradeableProxy` to `ERC1967Proxy`. ([#2547](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2547))
*`ERC777`: optimize the gas costs of the constructor. ([#2551](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2551))
*`ERC721URIStorage`: add a new extension that implements the `_setTokenURI` behavior as it was available in 3.4.0. ([#2555](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2555))
*`ERC1155`: make `uri` public so overloading function can call it using super. ([#2576](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2576))
### Bug fixes for beta releases
*`AccessControlEnumerable`: Fixed `renounceRole` not updating enumerable set of addresses for a role. ([#2572](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2572))
### How to upgrade from 3.x
Since this version has moved a few contracts to different directories, users upgrading from a previous version will need to adjust their import statements. To make this easier, the package includes a script that will migrate import statements automatically. After upgrading to the latest version of the package, run:
```
npx openzeppelin-contracts-migrate-imports
```
Make sure you're using git or another version control system to be able to recover from any potential error in our script.
### How to upgrade from 4.0-beta.x
Some further changes have been done between the different beta iterations. Transitions made during this period are configured in the `migrate-imports` script. Consequently, you can upgrade from any previous 4.0-beta.x version using the same script as described in the *How to upgrade from 3.x* section.
## 3.4.0 (2021-02-02)
*`BeaconProxy`: added new kind of proxy that allows simultaneous atomic upgrades. ([#2411](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2411))
*`EIP712`: added helpers to verify EIP712 typed data signatures on chain. ([#2418](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2418))
*`ERC20Permit`: added an implementation of the ERC20 permit extension for gasless token approvals. ([#2237](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2237))
* Presets: added token presets with preminted fixed supply `ERC20PresetFixedSupply` and `ERC777PresetFixedSupply`. ([#2399](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2399))
*`Address`: added `functionDelegateCall`, similar to the existing `functionCall`. ([#2333](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2333))
*`Clones`: added a library for deploying EIP 1167 minimal proxies. ([#2449](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2449))
*`Context`: moved from `contracts/GSN` to `contracts/utils`. ([#2453](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2453))
*`PaymentSplitter`: replace usage of `.transfer()` with `Address.sendValue` for improved compatibility with smart wallets. ([#2455](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2455))
*`UpgradeableProxy`: bubble revert reasons from initialization calls. ([#2454](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2454))
*`SafeMath`: fix a memory allocation issue by adding new `SafeMath.tryOp(uint,uint)→(bool,uint)` functions. `SafeMath.op(uint,uint,string)→uint` are now deprecated. ([#2462](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2462))
*`EnumerableMap`: fix a memory allocation issue by adding new `EnumerableMap.tryGet(uint)→(bool,address)` functions. `EnumerableMap.get(uint)→string` is now deprecated. ([#2462](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2462))
*`RefundEscrow`: `beneficiaryWithdraw` will forward all available gas to the beneficiary. ([#2480](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2480))
* Many view and pure functions have been made virtual to customize them via overrides. In many cases this will not imply that other functions in the contract will automatically adapt to the overridden definitions. People who wish to override should consult the source code to understand the impact and if they need to override any additional functions to achieve the desired behavior.
### Security Fixes
*`ERC777`: fix potential reentrancy issues for custom extensions to `ERC777`. ([#2483](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2483))
If you're using our implementation of ERC777 from version 3.3.0 or earlier, and you define a custom `_beforeTokenTransfer` function that writes to a storage variable, you may be vulnerable to a reentrancy attack. If you're affected and would like assistance please write to security@openzeppelin.com. [Read more in the pull request.](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2483)
## 3.3.0 (2020-11-26)
* Now supports both Solidity 0.6 and 0.7. Compiling with solc 0.7 will result in warnings. Install the `solc-0.7` tag to compile without warnings.
*`Address`: added `functionStaticCall`, similar to the existing `functionCall`. ([#2333](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2333))
*`TimelockController`: added a contract to augment access control schemes with a delay. ([#2354](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2354))
*`EnumerableSet`: added `Bytes32Set`, for sets of `bytes32`. ([#2395](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2395))
## 3.2.2-solc-0.7 (2020-10-28)
* Resolve warnings introduced by Solidity 0.7.4. ([#2396](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2396))
## 3.2.1-solc-0.7 (2020-09-15)
*`ERC777`: Remove a warning about function state visibility in Solidity 0.7. ([#2327](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2327))
## 3.2.0 (2020-09-10)
### New features
* Proxies: added the proxy contracts from OpenZeppelin SDK. ([#2335](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2335))
#### Proxy changes with respect to OpenZeppelin SDK
Aside from upgrading them from Solidity 0.5 to 0.6, we've changed a few minor things from the proxy contracts as they were found in OpenZeppelin SDK.
-`UpgradeabilityProxy` was renamed to `UpgradeableProxy`.
-`AdminUpgradeabilityProxy` was renamed to `TransparentUpgradeableProxy`.
-`Proxy._willFallback` was renamed to `Proxy._beforeFallback`.
-`UpgradeabilityProxy._setImplementation` and `AdminUpgradeabilityProxy._setAdmin` were made private.
### Improvements
*`Address.isContract`: switched from `extcodehash` to `extcodesize` for less gas usage. ([#2311](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2311))
### Breaking changes
*`ERC20Snapshot`: switched to using `_beforeTokenTransfer` hook instead of overriding ERC20 operations. ([#2312](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2312))
This small change in the way we implemented `ERC20Snapshot` may affect users who are combining this contract with
other ERC20 flavors, since it no longer overrides `_transfer`, `_mint`, and `_burn`. This can result in having to remove Solidity `override(...)` specifiers in derived contracts for these functions, and to instead have to add it for `_beforeTokenTransfer`. See [Using Hooks](https://docs.openzeppelin.com/contracts/3.x/extending-contracts#using-hooks) in the documentation.
## 3.1.0 (2020-06-23)
### New features
*`SafeCast`: added functions to downcast signed integers (e.g. `toInt32`), improving usability of `SignedSafeMath`. ([#2243](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2243))
*`functionCall`: new helpers that replicate Solidity's function call semantics, reducing the need to rely on `call`. ([#2264](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2264))
*`ERC1155`: added support for a base implementation, non-standard extensions and a preset contract. ([#2014](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2014), [#2230](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2230))
### Improvements
*`ReentrancyGuard`: reduced overhead of using the `nonReentrant` modifier. ([#2171](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2171))
*`AccessControl`: added a `RoleAdminChanged` event to `_setAdminRole`. ([#2214](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2214))
* Made all `public` functions in the token preset contracts `virtual`. ([#2257](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2257))
* Added SPX license identifier to all contracts. ([#2235](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2235))
## 3.0.1 (2020-04-27)
### Bugfixes
*`ERC777`: fixed the `_approve` internal function not validating some of their arguments for non-zero addresses. ([#2213](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2213))
## 3.0.0 (2020-04-20)
### New features
*`AccessControl`: new contract for managing permissions in a system, replacement for `Ownable` and `Roles`. ([#2112](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2112))
*`SafeCast`: new functions to convert to and from signed and unsigned values: `toUint256` and `toInt256`. ([#2123](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2123))
*`EnumerableMap`: a new data structure for key-value pairs (like `mapping`) that can be iterated over. ([#2160](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2160))
### Breaking changes
*`ERC721`: `burn(owner, tokenId)` was removed, use `burn(tokenId)` instead. ([#2125](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2125))
*`ERC721`: `_checkOnERC721Received` was removed. ([#2125](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2125))
*`ERC721`: `_transferFrom` and `_safeTransferFrom` were renamed to `_transfer` and `_safeTransfer`. ([#2162](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2162))
*`PullPayment`, `Escrow`: `withdrawWithGas` was removed. The old `withdraw` function now forwards all gas. ([#2125](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2125))
*`Roles` was removed, use `AccessControl` as a replacement. ([#2112](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2112))
*`ECDSA`: when receiving an invalid signature, `recover` now reverts instead of returning the zero address. ([#2114](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2114))
*`Create2`: added an `amount` argument to `deploy` for contracts with `payable` constructors. ([#2117](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2117))
*`Pausable`: moved to the `utils` directory. ([#2122](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2122))
*`Strings`: moved to the `utils` directory. ([#2122](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2122))
*`Counters`: moved to the `utils` directory. ([#2122](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2122))
*`SignedSafeMath`: moved to the `math` directory. ([#2122](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2122))
*`ERC20Snapshot`: moved to the `token/ERC20` directory. `snapshot` was changed into an `internal` function. ([#2122](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2122))
*`Ownable`: moved to the `access` directory. ([#2120](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2120))
*`Secondary`: removed from the library, use `Ownable` instead. ([#2120](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2120))
*`Escrow`, `ConditionalEscrow`, `RefundEscrow`: these now use `Ownable` instead of `Secondary`, their external API changed accordingly. ([#2120](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2120))
*`Address`: removed `toPayable`, use `payable(address)` instead. ([#2133](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2133))
*`ERC777`: `_send`, `_mint` and `_burn` now use the caller as the operator. ([#2134](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2134))
*`ERC777`: removed `_callsTokensToSend` and `_callTokensReceived`. ([#2134](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2134))
*`EnumerableSet`: renamed `get` to `at`. ([#2151](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2151))
*`ERC165Checker`: functions no longer have a leading underscore. ([#2150](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2150))
*`ERC721Metadata`, `ERC721Enumerable`: these contracts were removed, and their functionality merged into `ERC721`. ([#2160](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2160))
*`ERC721`: added a constructor for `name` and `symbol`. ([#2160](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2160))
*`ERC20Detailed`: this contract was removed and its functionality merged into `ERC20`. ([#2161](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2161))
*`ERC20`: added a constructor for `name` and `symbol`. `decimals` now defaults to 18. ([#2161](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2161))
*`Strings`: renamed `fromUint256` to `toString` ([#2188](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2188))
## 2.5.1 (2020-04-24)
### Bugfixes
*`ERC777`: fixed the `_send` and `_approve` internal functions not validating some of their arguments for non-zero addresses. ([#2212](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2212))
## 2.5.0 (2020-02-04)
### New features
*`SafeCast.toUintXX`: new library for integer downcasting, which allows for safe operation on smaller types (e.g. `uint32`) when combined with `SafeMath`. ([#1926](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1926))
*`ERC721Metadata`: added `baseURI`, which can be used for dramatic gas savings when all token URIs share a prefix (e.g. `http://api.myapp.com/tokens/<id>`). ([#1970](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1970))
*`EnumerableSet`: new library for storing enumerable sets of values. Only `AddressSet` is supported in this release. ([#2061](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/2061))
*`Create2`: simple library to make usage of the `CREATE2` opcode easier. ([#1744](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1744))
### Improvements
*`ERC777`: `_burn` is now internal, providing more flexibility and making it easier to create tokens that deflate. ([#1908](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1908))
*`ReentrancyGuard`: greatly improved gas efficiency by using the net gas metering mechanism introduced in the Istanbul hardfork. ([#1992](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1992), [#1996](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1996))
*`ERC777`: improve extensibility by making `_send` and related functions `internal`. ([#2027](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2027))
*`ERC721`: improved revert reason when transferring tokens to a non-recipient contract. ([#2018](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2018))
### Breaking changes
*`ERC165Checker` now requires a minimum Solidity compiler version of 0.5.10. ([#1829](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1829))
## 2.4.0 (2019-10-29)
### New features
*`Address.toPayable`: added a helper to convert between address types without having to resort to low-level casting. ([#1773](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1773))
* Facilities to make metatransaction-enabled contracts through the Gas Station Network. ([#1844](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1844))
*`Address.sendValue`: added a replacement to Solidity's `transfer`, removing the fixed gas stipend. ([#1962](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1962))
* Added replacement for functions that don't forward all gas (which have been deprecated): ([#1976](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1976))
*`SafeMath`: added support for custom error messages to `sub`, `div` and `mod` functions. ([#1828](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1828))
### Improvements
*`Address.isContract`: switched from `extcodesize` to `extcodehash` for less gas usage. ([#1802](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1802))
*`ERC20` and `ERC777` updated to throw custom errors on subtraction overflows. ([#1828](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1828))
### Deprecations
* Deprecated functions that don't forward all gas: ([#1976](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1976))
*`Address` now requires a minimum Solidity compiler version of 0.5.5. ([#1802](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1802))
*`SignatureBouncer` has been removed from drafts, both to avoid confusions with the GSN and `GSNRecipientSignature` (previously called `GSNBouncerSignature`) and because the API was not very clear. ([#1879](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1879))
### How to upgrade from 2.4.0-beta
The final 2.4.0 release includes a refactor of the GSN contracts that will be a breaking change for 2.4.0-beta users.
* The default empty implementations of `_preRelayedCall` and `_postRelayedCall` were removed and must now be explicitly implemented always in custom recipients. If your custom recipient didn't include an implementation, you can provide an empty one.
*`GSNRecipient`, `GSNBouncerBase`, and `GSNContext` were all merged into `GSNRecipient`.
*`GSNBouncerSignature` and `GSNBouncerERC20Fee` were renamed to `GSNRecipientSignature` and `GSNRecipientERC20Fee`.
* It is no longer necessary to inherit from `GSNRecipient` when using `GSNRecipientSignature` and `GSNRecipientERC20Fee`.
For example, a contract using `GSNBouncerSignature` would have to be changed in the following way.
```diff
-contract MyDapp is GSNRecipient, GSNBouncerSignature {
+contract MyDapp is GSNRecipientSignature {
```
Refer to the table below to adjust your inheritance list.
*`ERC1820`: added support for interacting with the [ERC1820](https://eips.ethereum.org/EIPS/eip-1820) registry contract (`IERC1820Registry`), as well as base contracts that can be registered as implementers there. ([#1677](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1677))
*`ERC777`: support for the [ERC777 token](https://eips.ethereum.org/EIPS/eip-777), which has multiple improvements over `ERC20` (but is backwards compatible with it) such as built-in burning, a more straightforward permission system, and optional sender and receiver hooks on transfer (mandatory for contracts!). ([#1684](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1684))
* All contracts now have revert reason strings, which give insight into error conditions, and help debug failing transactions. ([#1704](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1704))
### Improvements:
### Improvements
* Reverted the Solidity version bump done in v2.2.0, setting the minimum compiler version to v0.5.0, to prevent unexpected build breakage. Users are encouraged however to stay on top of new compiler releases, which usually include bugfixes. ([#1729](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1729))
### Bugfixes:
### Bugfixes
*`PostDeliveryCrowdsale`: some validations where skipped when paired with other crowdsale flavors, such as `AllowanceCrowdsale`, or `MintableCrowdsale` and `ERC20Capped`, which could cause buyers to not be able to claim their purchased tokens. ([#1721](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1721))
*`ERC20._transfer`: the `from` argument was allowed to be the zero address, so it was possible to internally trigger a transfer of 0 tokens from the zero address. This address is not a valid destinatary of transfers, nor can it give or receive allowance, so this behavior was inconsistent. It now reverts. ([#1752](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1752))
## 2.2.0 (2019-03-14)
### New features:
### New features
*`ERC20Snapshot`: create snapshots on demand of the token balances and total supply, to later retrieve and e.g. calculate dividends at a past time. ([#1617](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1617))
*`SafeERC20`: `ERC20` contracts with no return value (i.e. that revert on failure) are now supported. ([#1655](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1655))
*`ERC20`: added internal `_approve(address owner, address spender, uint256 value)`, allowing derived contracts to set the allowance of arbitrary accounts. ([#1609](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1609))
*`TimedCrowdsale`: added internal `_extendTime(uint256 newClosingTime)` as well as `TimedCrowdsaleExtended(uint256 prevClosingTime, uint256 newClosingTime)` event allowing to extend the crowdsale, as long as it hasn't already closed.
### Improvements:
### Improvements
* Upgraded the minimum compiler version to v0.5.2: this removes many Solidity warnings that were false positives. ([#1606](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1606))
*`ECDSA`: `recover` no longer accepts malleable signatures (those using upper-range values for `s`, or 0/1 for `v`). ([#1622](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1622))
*`ERC721`'s transfers are now more gas efficient due to removal of unnecessary `SafeMath` calls. ([#1610](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1610))
*``ERC721``'s transfers are now more gas efficient due to removal of unnecessary `SafeMath` calls. ([#1610](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1610))
* (minor) `SafeERC20`: `safeApprove` wasn't properly checking for a zero allowance when attempting to set a non-zero allowance. ([#1647](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1647))
### Breaking changes in drafts:
### Breaking changes in drafts
*`TokenMetadata` has been renamed to `ERC20Metadata`. ([#1618](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1618))
* The library `Counter` has been renamed to `Counters` and its API has been improved. See an example in `ERC721`, lines [17](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/3cb4a00fce1da76196ac0ac3a0ae9702b99642b5/contracts/token/ERC721/ERC721.sol#L17) and [204](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/3cb4a00fce1da76196ac0ac3a0ae9702b99642b5/contracts/token/ERC721/ERC721.sol#L204). ([#1610](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1610))
@ -47,7 +345,7 @@
## 2.1.0 (2019-01-04)
### New features:
### New features
* Now targeting the 0.5.x line of Solidity compilers. For 0.4.24 support, use version 2.0 of OpenZeppelin.
*`WhitelistCrowdsale`: a crowdsale where only whitelisted accounts (`WhitelistedRole`) can purchase tokens. Adding or removing accounts from the whitelist is done by whitelist admins (`WhitelistAdminRole`). Similar to the pre-2.0 `WhitelistedCrowdsale`. ([#1525](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1525), [#1589](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1589))
*`RefundablePostDeliveryCrowdsale`: replacement for `RefundableCrowdsale` (deprecated, see below) where tokens are only granted once the crowdsale ends (if it meets its goal). ([#1543](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1543))
@ -58,17 +356,17 @@
* Crowdsales: all constructors are now `public`, meaning it is not necessary to extend these contracts in order to deploy them. The exception is `FinalizableCrowdsale`, since it is meaningless unless extended. ([#1564](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1564))
*`SignedSafeMath`: added overflow-safe operations for signed integers (`int256`). ([#1559](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1559), [#1588](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1588))
### Improvements:
### Improvements
* The compiler version required by `Array` was behind the rest of the libray so it was updated to `v0.4.24`. ([#1553](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1553))
* Now conforming to a 4-space indentation code style. ([1508](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1508))
*`ERC20`: more gas efficient due to removed redundant `require`s. ([#1409](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1409))
*`ERC721`: fixed a bug that prevented internal data structures from being properly cleaned, missing potential gas refunds. ([#1539](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1539) and [#1549](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1549))
*`ERC721`: general gas savings on `transferFrom`, `_mint` and `_burn`, due to redudant `require`s and `SSTORE`s. ([#1549](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1549))
### Bugfixes:
### Bugfixes
### Breaking changes:
### Breaking changes
### Deprecations:
### Deprecations
*`ERC721._burn(address owner, uint256 tokenId)`: due to the `owner` parameter being unnecessary. ([#1550](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1550))
*`RefundableCrowdsale`: due to trading abuse potential on crowdsales that miss their goal. ([#1543](https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1543))
We really appreciate and value contributions to OpenZeppelin. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.
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.
## Contribution guidelines
Smart contracts manage value and are highly vulnerable to errors and attacks. We have very strict guidelines, please make sure to review them: ["Contribution guidelines wiki entry"](https://github.com/OpenZeppelin/openzeppelin-solidity/wiki/Contribution-guidelines).
Smart contracts manage value and are highly vulnerable to errors and attacks. We have very strict [guidelines], please make sure to review them!
## Creating Pull Requests (PRs)
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.
*IMPORTANT*
* Please see ["Git flow wiki entry"](https://github.com/OpenZeppelin/openzeppelin-solidity/wiki/Git-flow) for understanding how to use branches in this repository.
## A typical workflow
1) Make sure your fork is up to date with the main repository:
NOTE: The directory `openzeppelin-solidity` represents your fork's local copy.
NOTE: The directory `openzeppelin-contracts` represents your fork's local copy.
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)
@ -32,7 +29,7 @@ NOTE: The directory `openzeppelin-solidity` represents your fork's local copy.
git checkout -b fix/some-bug-#123
```
3) Make your changes, add your files, commit and push to your fork.
3) Make your changes, add your files, commit, and push to your fork.
```
git add SomeFile.js
@ -40,19 +37,28 @@ git commit "Fix some bug #123"
git push origin fix/some-bug-#123
```
4) Go to [github.com/OpenZeppelin/openzeppelin-solidity](https://github.com/OpenZeppelin/zeppelin-solidity) in your web browser and issue a new pull request.
4) Run tests, linter, etc. This can be done by running local continuous integration and make sure it passes.
*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.
```bash
npm test
npm run lint
```
5) 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.
5) Go to [github.com/OpenZeppelin/openzeppelin-contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) in your web browser and issue a new pull request.
*IMPORTANT*Please pay attention to the maintainer's feedback, since its a necessary step to keep up with the standards OpenZeppelin attains to.
*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 Contracts.
*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!
If you have any questions feel free to post them to github.com/OpenZeppelin/openzeppelin-solidity/issues.
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-solidity/labels/good%20first%20issue).
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).
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.
#### 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.
#### D2 - Naming Matters
We take our time with picking names. Code is going to be written once, and read hundreds of times. Renaming for clarity is encouraged.
#### D3 - 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.
#### D4 - Check preconditions and post-conditions
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.
#### D5 - Code Consistency
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.
#### 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.
# Style Guidelines
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.
## Solidity code
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).
Any exception or additions specific to our project are documented below.
* Try to avoid acronyms and abbreviations.
* All state variables should be private.
* Private state variables should have an underscore prefix.
```
contract TestContract {
uint256 private _privateVar;
uint256 internal _internalVar;
}
```
* Parameters must not be prefixed with an underscore.
```
function test(uint256 testParameter1, uint256 testParameter2) {
...
}
```
* Internal and private functions should have an underscore prefix.
```
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.
```
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.
* 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
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.
**OpenZeppelin is a library for secure smart contract development.**It provides implementations of standards like ERC20 and ERC721 which you can deploy as-is or extend to suit your needs, as well as Solidity components to build custom contracts and more complex decentralized systems.
**A library for secure smart contract development.**Build on a solid foundation of community-vetted code.
## Install
* Implementations of standards like [ERC20](https://docs.openzeppelin.com/contracts/erc20) and [ERC721](https://docs.openzeppelin.com/contracts/erc721).
* Reusable [Solidity components](https://docs.openzeppelin.com/contracts/utilities) to build custom contracts and complex decentralized systems.
```
npm install openzeppelin-solidity
:mage: **Not sure how to get started?** Check out [Contracts Wizard](https://wizard.openzeppelin.com/) — an interactive smart contract generator.
## Overview
### Installation
```console
$ npm install @openzeppelin/contracts
```
OpenZeppelin features a stable API, which means your contracts won't break unexpectedly when upgrading to a newer minor version. You can read ṫhe details in our [API Stability](https://forum.zeppelin.solutions/t/api-stability/138) document.
OpenZeppelin Contracts features a [stable API](https://docs.openzeppelin.com/contracts/releases-stability#api-stability), which means your contracts won't break unexpectedly when upgrading to a newer minor version.
## Usage
### Usage
To write your custom contracts, import ours and extend them through inheritance.
Once installed, you can use the contracts in the library by importing them:
> You need an ethereum development framework for the above import statements to work! Check out these guides for [Truffle], [Embark] or [Buidler].
_If you're new to smart contract development, head to [Developing Smart Contracts](https://docs.openzeppelin.com/learn/developing-smart-contracts) to learn about creating a new project and compiling your contracts._
On our site you will find a few [guides] to learn about the different parts of OpenZeppelin, as well as [documentation for the API][API docs]. Keep in mind that the API docs are work in progress, and don’t hesitate to ask questions in [our forum][forum].
To keep your system secure, you should **always** use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don't need to worry about it needlessly increasing gas costs.
## Learn More
The guides in the [docs site](https://docs.openzeppelin.com/contracts) will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:
* [Access Control](https://docs.openzeppelin.com/contracts/access-control): decide who can perform each of the actions on your system.
* [Tokens](https://docs.openzeppelin.com/contracts/tokens): create tradeable assets or collectives, and distribute them via [Crowdsales](https://docs.openzeppelin.com/contracts/crowdsales).
* [Gas Station Network](https://docs.openzeppelin.com/contracts/gsn): let your users interact with your contracts without having to pay for gas themselves.
* [Utilities](https://docs.openzeppelin.com/contracts/utilities): generic useful tools, including non-overflowing math, signature verification, and trustless paying systems.
The [full API](https://docs.openzeppelin.com/contracts/api/token/ERC20) is also thoroughly documented, and serves as a great reference when developing your smart contract application. You can also ask for help or follow Contracts's development in the [community forum](https://forum.openzeppelin.com).
Finally, you may want to take a look at the [guides on our blog](https://blog.openzeppelin.com/guides), which cover several common use cases and good practices.. The following articles provide great background reading, though please note, some of the referenced tools have changed as the tooling in the ecosystem continues to rapidly evolve.
* [The Hitchhiker’s Guide to Smart Contracts in Ethereum](https://blog.openzeppelin.com/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05) will help you get an overview of the various tools available for smart contract development, and help you set up your environment.
* [A Gentle Introduction to Ethereum Programming, Part 1](https://blog.openzeppelin.com/a-gentle-introduction-to-ethereum-programming-part-1-783cc7796094) provides very useful information on an introductory level, including many basic concepts from the Ethereum platform.
* For a more in-depth dive, you may read the guide [Designing the Architecture for Your Ethereum Application](https://blog.openzeppelin.com/designing-the-architecture-for-your-ethereum-application-9cec086f8317), which discusses how to better structure your application and its relationship to the real world.
## Security
OpenZeppelin the project is maintained by [Zeppelin] the company, 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.
Please report any security issues you find to security@openzeppelin.org.
Critical bug fixes will be backported to past major releases.
## 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]!
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).
This document describes our release process, and contains the steps to be followed by an OpenZeppelin maintainer at the several stages of a release.
> Visit the documentation for [details about release schedule].
We release a new version of OpenZeppelin monthly. Release cycles are tracked in the [issue milestones](https://github.com/OpenZeppelin/openzeppelin-solidity/milestones).
Start on an up-to-date `master` branch.
Each release has at least one release candidate published first, intended for community review and any critical fixes that may come out of it. At the moment we leave 1 week between the first release candidate and the final release.
Create the release branch with `npm run release start minor`.
Before starting make sure to verify the following items.
* Your local `master` branch is in sync with your `upstream` remote (it may have another name depending on your setup).
* Your repo is clean, particularly with no untracked files in the contracts and tests directories. Verify with `git clean -n`.
Publish a release candidate with `npm run release rc`.
Publish the final release with `npm run release final`.
## Creating the release branch
Follow the general [OpenZeppelin Contracts release checklist].
We'll refer to a release `vX.Y.Z`.
[details about release schedule]: https://docs.openzeppelin.com/contracts/releases-stability
Once in the release branch, change the version string in `package.json`, `package-lock.json` and `ethpm.json` to `X.Y.Z-rc.R`. (This will be `X.Y.Z-rc.1` for the first release candidate.) Commit these changes and tag the commit as `vX.Y.Z-rc.R`.
```
git add package.json package-lock.json ethpm.json
git commit -m "Release candidate vX.Y.Z-rc.R"
git tag -a vX.Y.Z-rc.R
git push upstream release-vX.Y.Z
git push upstream vX.Y.Z-rc.R
```
Draft the release notes in our [GitHub releases](https://github.com/OpenZeppelin/openzeppelin-solidity/releases). Make sure to mark it as a pre-release! Try to be consistent with our previous release notes in the title and format of the text. Release candidates don't need a detailed changelog, but make sure to include a link to GitHub's compare page.
Once the CI run for the new tag is green, publish on npm under the `next` tag. You should see the contracts compile automatically.
```
npm publish --tag next
```
Publish the release notes on GitHub and the forum, and ask our community manager to announce the release candidate on at least Twitter.
## Creating the final release
Make sure to have the latest changes from `upstream` in your local release branch.
```
git checkout release-vX.Y.Z
git pull upstream
```
Before starting the release process, make one final commit to CHANGELOG.md, including the date of the release.
Change the version string in `package.json`, `package-lock.json` and `ethpm.json` removing the "-rc.R" suffix. Commit these changes and tag the commit as `vX.Y.Z`.
```
git add package.json package-lock.json ethpm.json
git commit -m "Release vX.Y.Z"
git tag -a vX.Y.Z
git push upstream release-vX.Y.Z
git push upstream vX.Y.Z
```
Draft the release notes in GitHub releases. Try to be consistent with our previous release notes in the title and format of the text. Make sure to include a detailed changelog.
Once the CI run for the new tag is green, publish on npm. You should see the contracts compile automatically.
```
npm publish
```
Publish the release notes on GitHub and ask our community manager to announce the release!
Delete the `next` tag in the npm package as there is no longer a release candidate.
```
npm dist-tag rm --otp $2FA_CODE openzeppelin-solidity next
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.
The following provides visibility into how OpenZeppelin's contracts are organized:
- **access** - Smart contracts that enable functionality that can be used for selective restrictions and basic authorization control functions.
- **crowdsale** - A collection of smart contracts used to manage token crowdsales that allow investors to purchase tokens with ETH. Includes a base contract which implements fundamental crowdsale functionality in its simplest form. The base contract can be extended in order to satisfy your crowdsale’s specific requirements.
- **distribution** - Includes extensions of the base crowdsale contract which can be used to customize the completion of a crowdsale.
- **emission** - Includes extensions of the base crowdsale contract which can be used to mint and manage how tokens are issued to purchasers.
- **price** - Includes extensions of the crowdsale contract that can be used to manage changes in token prices.
- **validation** - Includes extensions of the crowdsale contract that can be used to enforce restraints and limit access to token purchases.
- **examples** - A collection of simple smart contracts that demonstrate how to add new features to base contracts through multiple inheritance.
- **introspection** - An interface that can be used to make a contract comply with the ERC-165 standard as well as a contract that implements ERC-165 using a lookup table.
- **lifecycle** - A collection of base contracts used to manage the existence and behavior of your contracts and their funds.
- **math** - Libraries with safety checks on operations that throw on errors.
- **mocks** - A collection of abstract contracts that are primarily used for unit testing. They also serve as good usage examples and demonstrate how to combine contracts with inheritance when developing your own custom applications.
- **ownership** - A collection of smart contracts that can be used to manage contract and token ownership
- **payment** - A collection of smart contracts that can be used to manage payments through escrow arrangements, withdrawals, and claims. Includes support for both single payees and multiple payees.
- **proposals** - A collection of smart contracts that reflect community Ethereum Improvement Proposals (EIPs). These contracts are under development and standardization. They are not recommended for production, but they are useful for experimentation with pending EIP standards. Go [here](https://github.com/OpenZeppelin/openzeppelin-solidity/wiki/ERC-Process) for more information.
- **token** - A collection of approved ERC standard tokens -- their interfaces and implementations.
- **ERC20** - A standard interface for fungible tokens:
- *Interfaces* - Includes the ERC-20 token standard basic interface. I.e., what the contract’s ABI can represent.
- *Implementations* - Includes ERC-20 token implementations that include all required and some optional ERC-20 functionality.
- **ERC721** - A standard interface for non-fungible tokens
- *Interfaces* - Includes the ERC-721 token standard basic interface. I.e., what the contract’s ABI can represent.
- *Implementations* - Includes ERC-721 token implementations that include all required and some optional ERC-721 functionality.
NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/access
This directory provides ways to restrict who can access the functions of a contract or when they can do it.
- {AccessControl} provides a general role based access control mechanism. Multiple hierarchical roles can be created and assigned each to multiple accounts.
- {Ownable} is a simpler mechanism with a single owner "role" that can be assigned to a single account. This simpler mechanism can be useful for quick tests but projects with production concerns are likely to outgrow it.
NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/finance
This directory includes primitives for financial systems. We currently only offer the {PaymentSplitter} contract, but we want to grow this directory so we welcome ideas.
NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/governance
This directory includes primitives for on-chain governance.
== Governor
This modular system of Governor contracts allows the deployment on-chain voting protocols similar to https://compound.finance/docs/governance[Compound's Governor Alpha & Bravo] and beyond, through the ability to easily customize multiple aspects of the protocol.
[TIP]
====
For a guided experience, set up your Governor contract using https://wizard.openzeppelin.com/#governor[Contracts Wizard].
For a written walkthrough, check out our guide on xref:ROOT:governance.adoc[How to set up on-chain governance].
====
* {Governor}: The core contract that contains all the logic and primitives. It is abstract and requires choosing one of each of the modules below, or custom ones.
Votes modules determine the source of voting power, and sometimes quorum number.
* {GovernorVotes}: Extracts voting weight from an {ERC20Votes} token.
* {GovernorVotesComp}: Extracts voting weight from a COMP-like or {ERC20VotesComp} token.
* {GovernorVotesQuorumFraction}: Combines with `GovernorVotes` to set the quorum as a fraction of the total token supply.
Counting modules determine valid voting options.
* {GovernorCountingSimple}: Simple voting mechanism with 3 voting options: Against, For and Abstain.
Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a `queue` step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.
* {GovernorTimelockControl}: Connects with an instance of {TimelockController}. Allows multiple proposers and executors, in addition to the Governor itself.
* {GovernorTimelockCompound}: Connects with an instance of Compound's https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol[`Timelock`] contract.
Other extensions can customize the behavior or interface in multiple ways.
* {GovernorCompatibilityBravo}: Extends the interface to be fully `GovernorBravo`-compatible. Note that events are compatible regardless of whether this extension is included or not.
* {GovernorProposalThreshold}: Restricts proposals to delegates with a minimum voting power.
In addition to modules and extensions, the core contract requires a few virtual functions to be implemented to your particular specifications:
* <<Governor-votingDelay-,`votingDelay()`>>: Delay (in number of blocks) since the proposal is submitted until voting power is fixed and voting starts. This can be used to enforce a delay after a proposal is published for users to buy tokens, or delegate their votes.
* <<Governor-votingPeriod-,`votingPeriod()`>>: Delay (in number of blocks) since the proposal starts until voting ends.
* <<Governor-quorum-uint256-,`quorum(uint256 blockNumber)`>>: Quorum required for a proposal to be successful. This function includes a `blockNumber` argument so the quorum can adapt through time, for example, to follow a token's `totalSupply`.
NOTE: Functions of the `Governor` contract do not include access control. If you want to restrict access, you should add these checks by overloading the particular functions. Among these, {Governor-_cancel} is internal by default, and you will have to expose it (which the right access control mechanism) yourself if this function is needed.
=== Core
{{IGovernor}}
{{Governor}}
=== Modules
{{GovernorCountingSimple}}
{{GovernorVotes}}
{{GovernorVotesQuorumFraction}}
{{GovernorVotesComp}}
=== Extensions
{{GovernorTimelockControl}}
{{GovernorTimelockCompound}}
{{GovernorProposalThreshold}}
{{GovernorCompatibilityBravo}}
== Timelock
In a governance system, the {TimelockController} contract is in carge of introducing a delay between a proposal and its execution. It can be used with or without a {Governor}.
{{TimelockController}}
[[timelock-terminology]]
==== Terminology
* *Operation:* A transaction (or a set of transactions) that is the subject of the timelock. It has to be scheduled by a proposer and executed by an executor. The timelock enforces a minimum delay between the proposition and the execution (see xref:access-control.adoc#operation_lifecycle[operation lifecycle]). If the operation contains multiple transactions (batch mode), they are executed atomically. Operations are identified by the hash of their content.
* *Operation status:*
** *Unset:* An operation that is not part of the timelock mechanism.
** *Pending:* An operation that has been scheduled, before the timer expires.
** *Ready:* An operation that has been scheduled, after the timer expires.
** *Done:* An operation that has been executed.
* *Predecessor*: An (optional) dependency between operations. An operation can depend on another operation (its predecessor), forcing the execution order of these two operations.
* *Role*:
** *Admin:* An address (smart contract or EOA) that is in charge of granting the roles of Proposer and Executor.
** *Proposer:* An address (smart contract or EOA) that is in charge of scheduling (and cancelling) operations.
** *Executor:* An address (smart contract or EOA) that is in charge of executing operations once the timelock has expired. This role can be given to the zero address to allow anyone to execute operations.
[[timelock-operation]]
==== Operation structure
Operation executed by the xref:api:governance.adoc#TimelockController[`TimelockController`] can contain one or multiple subsequent calls. Depending on whether you need to multiple calls to be executed atomically, you can either use simple or batched operations.
Both operations contain:
* *Target*, the address of the smart contract that the timelock should operate on.
* *Value*, in wei, that should be sent with the transaction. Most of the time this will be 0. Ether can be deposited before-end or passed along when executing the transaction.
* *Data*, containing the encoded function selector and parameters of the call. This can be produced using a number of tools. For example, a maintenance operation granting role `ROLE` to `ACCOUNT` can be encode using web3js as follows:
```javascript
const data = timelock.contract.methods.grantRole(ROLE, ACCOUNT).encodeABI()
```
* *Predecessor*, that specifies a dependency between operations. This dependency is optional. Use `bytes32(0)` if the operation does not have any dependency.
* *Salt*, used to disambiguate two otherwise identical operations. This can be any random value.
In the case of batched operations, `target`, `value` and `data` are specified as arrays, which must be of the same length.
[[timelock-operation-lifecycle]]
==== Operation lifecycle
Timelocked operations are identified by a unique id (their hash) and follow a specific lifecycle:
* By calling xref:api:governance.adoc#TimelockController-schedule-address-uint256-bytes-bytes32-bytes32-uint256-[`schedule`] (or xref:api:governance.adoc#TimelockController-scheduleBatch-address---uint256---bytes---bytes32-bytes32-uint256-[`scheduleBatch`]), a proposer moves the operation from the `Unset` to the `Pending` state. This starts a timer that must be longer than the minimum delay. The timer expires at a timestamp accessible through the xref:api:governance.adoc#TimelockController-getTimestamp-bytes32-[`getTimestamp`] method.
* Once the timer expires, the operation automatically gets the `Ready` state. At this point, it can be executed.
* By calling xref:api:governance.adoc#TimelockController-TimelockController-execute-address-uint256-bytes-bytes32-bytes32-[`execute`] (or xref:api:governance.adoc#TimelockController-executeBatch-address---uint256---bytes---bytes32-bytes32-[`executeBatch`]), an executor triggers the operation's underlying transactions and moves it to the `Done` state. If the operation has a predecessor, it has to be in the `Done` state for this transition to succeed.
* xref:api:governance.adoc#TimelockController-TimelockController-cancel-bytes32-[`cancel`] allows proposers to cancel any `Pending` operation. This resets the operation to the `Unset` state. It is thus possible for a proposer to re-schedule an operation that has been cancelled. In this case, the timer restarts when the operation is re-scheduled.
Operations status can be queried using the functions:
The admins are in charge of managing proposers and executors. For the timelock to be self-governed, this role should only be given to the timelock itself. Upon deployment, both the timelock and the deployer have this role. After further configuration and testing, the deployer can renounce this role such that all further maintenance operations have to go through the timelock process.
This role is identified by the *TIMELOCK_ADMIN_ROLE* value: `0x5f58e3a2316349923ce3780f8d587db2d72378aed66a8261c916544fa6846ca5`
[[timelock-proposer]]
===== Proposer
The proposers are in charge of scheduling (and cancelling) operations. This is a critical role, that should be given to governing entities. This could be an EOA, a multisig, or a DAO.
WARNING: *Proposer fight:* Having multiple proposers, while providing redundancy in case one becomes unavailable, can be dangerous. As proposer have their say on all operations, they could cancel operations they disagree with, including operations to remove them for the proposers.
This role is identified by the *PROPOSER_ROLE* value: `0xb09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1`
[[timelock-executor]]
===== Executor
The executors are in charge of executing the operations scheduled by the proposers once the timelock expires. Logic dictates that multisig or DAO that are proposers should also be executors in order to guarantee operations that have been scheduled will eventually be executed. However, having additional executors can reduce the cost (the executing transaction does not require validation by the multisig or DAO that proposed it), while ensuring whoever is in charge of execution cannot trigger actions that have not been scheduled by the proposers. Alternatively, it is possible to allow _any_ address to execute a proposal once the timelock has expired by granting the executor role to the zero address.
This role is identified by the *EXECUTOR_ROLE* value: `0xd8aa0f3194971a2a116679f7c2090f6939c8d4e01a2a8d7e41d55e5351469e63`
WARNING: A live contract without at least one proposer and one executor is locked. Make sure these roles are filled by reliable entities before the deployer renounces its administrative rights in favour of the timelock contract itself. See the {AccessControl} documentation to learn more about role management.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.