NoBey/openzeppelin-contracts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Group typographical errors (#5443)

Browse Source 
Co-authored-by: futreall <86553580+futreall@users.noreply.github.com>
Co-authored-by: Marco <wudmytrotest200@gmail.com>
Co-authored-by: Dmitry <98899785+mdqst@users.noreply.github.com>
Co-authored-by: Dmytrol <46675332+Dimitrolito@users.noreply.github.com>
Co-authored-by: Noisy <125606576+donatik27@users.noreply.github.com>
Co-authored-by: Danil <37103154+Danyylka@users.noreply.github.com>
Co-authored-by: CrazyFrog <anna.shuraeva13@gmail.com>
Co-authored-by: Bryer <0xbryer@gmail.com>
Co-authored-by: Viktor Pavlik <160131789+Vikt0rPavlik@users.noreply.github.com>
Co-authored-by: Skylar Ray <137945430+sky-coderay@users.noreply.github.com>
Co-authored-by: Brawn <nftdropped@gmail.com>
Co-authored-by: fuder.eth <139509124+vtjl10@users.noreply.github.com>
Co-authored-by: FT <140458077+zeevick10@users.noreply.github.com>
Co-authored-by: Ann Wagner <chant_77_swirly@icloud.com>
Co-authored-by: Hopium <135053852+Hopium21@users.noreply.github.com>
Co-authored-by: Arr00 <13561405+arr00@users.noreply.github.com>
Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
This commit is contained in:
Ernesto García
2025-01-24 11:18:59 -06:00
committed by GitHub
parent 6e752dc169
commit fd812ee954
18 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/modules/ROOT/pages/erc20-supply.adoc
View File

@ -68,4 +68,4 @@ include::api:example$ERC20WithAutoMinerReward.sol[]
[[wrapping-up]]
== Wrapping Up
We've seen how to implement a ERC-20 supply mechanism: internally through `_mint`. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts.
We've seen how to implement an ERC-20 supply mechanism: internally through `_mint`. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts.

2
docs/modules/ROOT/pages/governance.adoc
View File

@ -20,7 +20,7 @@ The ERC-20 extension to keep track of votes and vote delegation is one such case
=== Governor & GovernorStorage
An OpenZeppelin Governor contract is not interface-compatible with Compound's GovernorAlpha or Bravo. Even though events are fully compatible, proposal lifecycle functions (creation, execution, etc.) have different signatures that are meant to optimize storage use. Other functions from GovernorAlpha and Bravo are likewise not available. It’s possible to opt in some Bravo-like behavior by inheriting from the GovernorStorage module. This module provides proposal enumerability and alternate versions of the `queue`, `execute` and `cancel` function that only take the proposal id. This module reduces the calldata needed by some operations in exchange for an increased the storage footprint. This might be a good trade-off for some L2 chains. It also provides primitives for indexer-free frontends.
An OpenZeppelin Governor contract is not interface-compatible with Compound's GovernorAlpha or Bravo. Even though events are fully compatible, proposal lifecycle functions (creation, execution, etc.) have different signatures that are meant to optimize storage use. Other functions from GovernorAlpha and Bravo are likewise not available. It’s possible to opt in some Bravo-like behavior by inheriting from the GovernorStorage module. This module provides proposal enumerability and alternate versions of the `queue`, `execute` and `cancel` function that only take the proposal id. This module reduces the calldata needed by some operations in exchange for an increased storage footprint. This might be a good trade-off for some L2 chains. It also provides primitives for indexer-free frontends.
Note that even with the use of this module, one important difference with Compound's GovernorBravo is the way that `proposalId`s are calculated. Governor uses the hash of the proposal parameters with the purpose of keeping its data off-chain by event indexing, while the original Bravo implementation uses sequential `proposalId`s.