Announcing OpenZeppelin Contracts 4.8

OpenZeppelin Contracts is a library for secure smart contract development consisting of reusable Solidity components to build custom contracts and complex decentralized systems. These contracts allow developers to build on a solid foundation of community-vetted code.

OpenZeppelin Contracts 4.8 is now final, wrapping up the open review period. We want to express our gratitude to the many developers who have participated in this review by inspecting the code, trying it out, and sharing their feedback. 

This release includes numerous small changes and optimizations. Here are a few highlights:

Efficient batch minting of NFTs

This feature adds support for EIP-2309: ERC-721 Consecutive Transfer Extension. ERC721Consecutive enables users to mint multiple NFT tokens in a single transaction – up to 5,000 per event emitted. This can lead to major cost reductions when batch-minting NFTs. The current cap of 5,000 was set to align with the maximum number supported by off-chain indexers for marketplaces.

Here is a gas price comparison making use of ERC721Consecutive during the deployment of an NFT contract, a given number of tokens are minted to the deployer’s address:

(Prices on 2022-11-04, gas: 25 gwei, ETH: $1620)

Note that these figures include the cost of deploying the contract AND the minting cost.

Optimizations in ERC20Votes and ERC721Votes

The cost of voting has been reduced by nearly 50%, which is a big win for Governor participants. This cost savings will be experienced when tallying the votes of community members, particularly for delegates who receive a significant amount of voting power delegated by other token holders.

Ownable2Step

This extension of Ownable’s transferOwnership function adds two-step functionality as an opt-in feature. Having this as an optional extension means that the previous one-step transfer of ownership function is still available. However, the owner can also benefit from the added safety of a securely designed two-step process. 

Math Additions

Numerous math functions such as logarithms in base 2, 10, and 256 are used in various parts of the OpenZeppelin Contracts codebase. This change in Contracts 4.8 rationalizes the code by making these functions available within the Math library, allowing for reuse by developers. 

Bug Fixes and Things to Look Out For

Admin for TimelockController

Timelocks are an important component in secure smart contract design in many cases, and the developer community has raised the issue around the way the admin role is allocated during deployment. When deploying the previous Contracts version of a TimelockController, the TimelockController granted the TIMELOCK_ADMIN_ROLE to the deployer and to the timelock itself. The deployer was then expected to renounce this role once the configuration of the timelock was over. Failing to renounce that role allowed the deployer to change the timelock’s permissions (but not to bypass the delay for any time-locked actions). In Contracts 4.8, the admin role is no longer given to the deployer by default. During timelock deployment, a new parameter admin can be set to a non-zero address to grant the admin role (to the deployer or any other address). As before, this admin role should be renounced after the timelock is configured. If this parameter is given address(0), the role is not allocated and therefore does not need to be revoked. In any case, the timelock itself continues to have this role.

Removed decimals from on-chain ERC-4626 calculations

Formerly, conversion from shares to assets (and vice-versa) in an empty vault considered the possibility of a mismatch between the decimals specified by the underlying asset and those of the vault. This initial conversion rate is now set to 1-to-1 irrespective of decimals, with the vault using the asset’s decimals by default. The numbers are intended to appear the same off-chain. This bug fix is for smart contract developers using the ERC-4626 tokenized vault standard.

These updates for version 4.8 of OpenZeppelin Contracts have been released as final. As usual, there remains a bug bounty of up to $25,000 to reward the finding of any issues in the code. For any questions or comments, please visit our Community Forum, and for updates follow us on Twitter.