Skip to main content

Full Reference

Everything exported by the package

📄️ AccessControl

Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see . Roles are referred to by their bytes32 identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using public constant hash digests function foo() public { require(hasRole(MYROLE, msg.sender)); ... } Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is DEFAULTADMINROLE, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {\setRoleAdmin}. WARNING it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.

📄️ AccessControlUpgradeable

Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see . Roles are referred to by their bytes32 identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using public constant hash digests function foo() public { require(hasRole(MYROLE, msg.sender)); ... } Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is DEFAULTADMINROLE, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {\setRoleAdmin}. WARNING it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.

📄️ Clones

https://eips.ethereum.org/EIPS/eip-1167 is a standard for deploying minimal proxy contracts, also known as "clones". > To simply and cheaply clone contract functionality in an immutable way, this standard specifies > a minimal bytecode implementation that delegates all calls to a known, fixed address. The library includes functions to deploy a proxy using either create (traditional deployment) or create2 (salted deterministic deployment). It also includes functions to predict the addresses of clones deployed using the deterministic method. Available since v3.4.\\

📄️ DoubleEndedQueueUpgradeable

A sequence of items with the ability to efficiently push and pop items (i.e. insert and remove) on both ends of the sequence (called front and back). Among other access patterns, it can be used to implement efficient LIFO and FIFO queues. Storage use is optimized, and all operations are O(1) constant time. This includes , given that the existing queue contents are left in storage. The struct is called Bytes32Deque. Other types can be cast to and from bytes32. This data structure can only be used in storage, and not in memory. DoubleEndedQueue.Bytes32Deque queue; *Available since v4.6.*

📄️ ERC1155Base

The ERC1155Base smart contract implements the ERC1155 NFT standard. It includes the following additions to standard ERC1155 logic: - Ability to mint NFTs via the provided mintTo and batchMintTo functions. - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces.

📄️ ERC1155DelayedReveal

BASE DelayedReveal The ERC1155DelayedReveal contract uses the DelayedReveal extension. 'Lazy minting' means defining the metadata of NFTs without minting it to an address. Regular 'minting' of NFTs means actually assigning an owner to an NFT. As a contract admin, this lets you prepare the metadata for NFTs that will be minted by an external party, without paying the gas cost for actually minting the NFTs. 'Delayed reveal' is a mechanism by which you can distribute NFTs to your audience and reveal the metadata of the distributed NFTs, after the fact. You can read more about how the DelayedReveal extension works, here//blog.thirdweb.com/delayed-reveal-nfts

📄️ ERC1155Drop

BASE DropSinglePhase1155 The ERC1155Base smart contract implements the ERC1155 NFT standard. It includes the following additions to standard ERC1155 logic: - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces. The drop mechanism in the DropSinglePhase1155 extension is a distribution mechanism for lazy minted tokens. It lets you set restrictions such as a price to charge, an allowlist etc. when an address attempts to mint lazy minted tokens. The ERC721Drop contract lets you lazy mint tokens, and distribute those lazy minted tokens via the drop mechanism.

📄️ ERC1155LazyMint

BASE LazyMint The ERC1155LazyMint smart contract implements the ERC1155 NFT standard. It includes the following additions to standard ERC1155 logic: - Lazy minting - Ability to mint NFTs via the provided mintTo and batchMintTo functions. - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces. The ERC1155LazyMint contract uses the LazyMint extension. 'Lazy minting' means defining the metadata of NFTs without minting it to an address. Regular 'minting' of NFTs means actually assigning an owner to an NFT. As a contract admin, this lets you prepare the metadata for NFTs that will be minted by an external party, without paying the gas cost for actually minting the NFTs.

📄️ ERC1155PresetUpgradeable

token, including: - ability for holders to burn (destroy) their tokens - a minter role that allows for token minting (creation) - a pauser role that allows to stop all token transfers This contract uses {AccessControl} to lock permissioned functions using the different roles - head to its documentation for details. The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to other accounts.

📄️ ERC1155SignatureMint

BASE SignatureMintERC1155 The ERC1155SignatureMint contract uses the ERC1155Base contract, along with the SignatureMintERC1155 extension. The 'signature minting' mechanism in the SignatureMintERC1155 extension uses EIP 712, and is a way for a contract admin to authorize an external party's request to mint tokens on the admin's contract. At a high level, this means you can authorize some external party to mint tokens on your contract, and specify what exactly will be minted by that external party.

📄️ ERC165

Implementation of the interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.

📄️ ERC165Upgradeable

Implementation of the interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.

📄️ ERC20

Implementation of the interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {\mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP//forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning false on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}._

📄️ ERC20DropVote

BASE DropSinglePhase The ERC20Drop contract uses the DropSinglePhase extensions, along with ERC20Votes. It implements the ERC20 standard, along with the following additions to standard ERC20 logic See method, which can be used to change an account's ERC20 allowance by presenting a message signed by the account. The drop mechanism in the DropSinglePhase extension is a distribution mechanism tokens. It lets you set restrictions such as a price to charge, an allowlist etc. when an address attempts to mint tokens.

📄️ ERC20SignatureMint

BASE SignatureMintERC20 The ERC20SignatureMint contract uses the ERC20Base contract, along with the SignatureMintERC20 extension. The 'signature minting' mechanism in the SignatureMintERC20 extension uses EIP 712, and is a way for a contract admin to authorize an external party's request to mint tokens on the admin's contract. At a high level, this means you can authorize some external party to mint tokens on your contract, and specify what exactly will be minted by that external party.

📄️ ERC20SignatureMintVote

BASE SignatureMintERC20 The ERC20SignatureMint contract uses the ERC20Vote contract, along with the SignatureMintERC20 extension. The 'signature minting' mechanism in the SignatureMintERC20 extension uses EIP 712, and is a way for a contract admin to authorize an external party's request to mint tokens on the admin's contract. At a high level, this means you can authorize some external party to mint tokens on your contract, and specify what exactly will be minted by that external party.

📄️ ERC20Upgradeable

Implementation of the interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {\mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP//forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning false on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}._

📄️ ERC20Votes

Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's, and supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1. NOTE: If exact COMP compatibility is required, use the variant of this module. This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getVotes} and {getPastVotes}. By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. *Available since v4.2.*

📄️ ERC20VotesUpgradeable

Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's, and supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1. NOTE: If exact COMP compatibility is required, use the variant of this module. This extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either by calling the {delegate} function directly, or by providing a signature to be used with {delegateBySig}. Voting power can be queried through the public accessors {getVotes} and {getPastVotes}. By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked. *Available since v4.2.*

📄️ ERC721Base

The ERC721Base smart contract implements the ERC721 NFT standard, along with the ERC721A optimization to the standard. It includes the following additions to standard ERC721 logic: - Ability to mint NFTs via the provided mint function. - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces.

📄️ ERC721DelayedReveal

BASE DelayedReveal The ERC721DelayedReveal contract uses the ERC721LazyMint contract, along with DelayedReveal extension. 'Lazy minting' means defining the metadata of NFTs without minting it to an address. Regular 'minting' of NFTs means actually assigning an owner to an NFT. As a contract admin, this lets you prepare the metadata for NFTs that will be minted by an external party, without paying the gas cost for actually minting the NFTs. 'Delayed reveal' is a mechanism by which you can distribute NFTs to your audience and reveal the metadata of the distributed NFTs, after the fact. You can read more about how the DelayedReveal extension works, here//blog.thirdweb.com/delayed-reveal-nfts

📄️ ERC721Drop

BASE DropSinglePhase The ERC721Drop contract implements the ERC721 NFT standard, along with the ERC721A optimization to the standard. It includes the following additions to standard ERC721 logic: - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces. The drop mechanism in the DropSinglePhase extension is a distribution mechanism for lazy minted tokens. It lets you set restrictions such as a price to charge, an allowlist etc. when an address attempts to mint lazy minted tokens. The ERC721Drop contract lets you lazy mint tokens, and distribute those lazy minted tokens via the drop mechanism.

📄️ ERC721LazyMint

BASE LazyMint The ERC721LazyMint smart contract implements the ERC721 NFT standard, along with the ERC721A optimization to the standard. It includes the following additions to standard ERC721 logic: - Lazy minting - Contract metadata for royalty support on platforms such as OpenSea that use off-chain information to distribute royalties. - Ownership of the contract, with the ability to restrict certain functions to only be called by the contract's owner. - Multicall capability to perform multiple actions atomically - EIP 2981 compliance for royalty support on NFT marketplaces. 'Lazy minting' means defining the metadata of NFTs without minting it to an address. Regular 'minting' of NFTs means actually assigning an owner to an NFT. As a contract admin, this lets you prepare the metadata for NFTs that will be minted by an external party, without paying the gas cost for actually minting the NFTs.

📄️ ERC721SignatureMint

BASE SignatureMintERC721 The ERC721SignatureMint contract uses the ERC721Base contract, along with the SignatureMintERC721 extension. The 'signature minting' mechanism in the SignatureMintERC721 extension uses EIP 712, and is a way for a contract admin to authorize an external party's request to mint tokens on the admin's contract. At a high level, this means you can authorize some external party to mint tokens on your contract, and specify what exactly will be minted by that external party.

📄️ EnumerableSet

Library for managing https - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } As of v3.3.0, sets of type bytes32 (Bytes32Set), address (AddressSet) and uint256 (UintSet) are supported. [WARNING] ==== Trying to delete such a structure from storage will likely result in data corruption, rendering the structure unusable. See https://github.com/ethereum/solidity/pull/11843[ethereum/solidity#11843] for more info. In order to clean an EnumerableSet, you can either remove all elements one by one or create a fresh instance using an array of EnumerableSet. ====

📄️ EnumerableSetUpgradeable

Library for managing https - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } As of v3.3.0, sets of type bytes32 (Bytes32Set), address (AddressSet) and uint256 (UintSet) are supported. [WARNING] ==== Trying to delete such a structure from storage will likely result in data corruption, rendering the structure unusable. See https://github.com/ethereum/solidity/pull/11843[ethereum/solidity#11843] for more info. In order to clean an EnumerableSet, you can either remove all elements one by one or create a fresh instance using an array of EnumerableSet. ====

📄️ IDropERC1155

Thirdweb's 'Drop' contracts are distribution mechanisms for tokens. The DropERC721 contract is a distribution mechanism for ERC721 tokens. A minter wallet (i.e. holder of MINTERROLE) can (lazy)mint 'n' tokens at once by providing a single base URI for all tokens being lazy minted. The URI for each of the 'n' tokens lazy minted is the provided base URI + of the respective token. (e.g. "ipfs://Qmece.../1"). A minter can choose to lazy mint 'delayed-reveal' tokens. More on 'delayed-reveal' tokens in this article. A contract admin (i.e. holder of DEFAULTADMIN_ROLE) can create claim conditions with non-overlapping time windows, and accounts can claim the tokens according to restrictions defined in the claim condition that is active at the time of the transaction.

📄️ IDropERC1155_V2

Thirdweb's 'Drop' contracts are distribution mechanisms for tokens. The DropERC721 contract is a distribution mechanism for ERC721 tokens. A minter wallet (i.e. holder of MINTERROLE) can (lazy)mint 'n' tokens at once by providing a single base URI for all tokens being lazy minted. The URI for each of the 'n' tokens lazy minted is the provided base URI + of the respective token. (e.g. "ipfs://Qmece.../1"). A minter can choose to lazy mint 'delayed-reveal' tokens. More on 'delayed-reveal' tokens in this article. A contract admin (i.e. holder of DEFAULTADMIN_ROLE) can create claim conditions with non-overlapping time windows, and accounts can claim the tokens according to restrictions defined in the claim condition that is active at the time of the transaction.

📄️ IDropERC721

Thirdweb's 'Drop' contracts are distribution mechanisms for tokens. The DropERC721 contract is a distribution mechanism for ERC721 tokens. A minter wallet (i.e. holder of MINTERROLE) can (lazy)mint 'n' tokens at once by providing a single base URI for all tokens being lazy minted. The URI for each of the 'n' tokens lazy minted is the provided base URI + of the respective token. (e.g. "ipfs://Qmece.../1"). A minter can choose to lazy mint 'delayed-reveal' tokens. More on 'delayed-reveal' tokens in this article. A contract admin (i.e. holder of DEFAULTADMIN_ROLE) can create claim conditions with non-overlapping time windows, and accounts can claim the tokens according to restrictions defined in the claim condition that is active at the time of the transaction.

📄️ IDropERC721_V3

Thirdweb's 'Drop' contracts are distribution mechanisms for tokens. The DropERC721 contract is a distribution mechanism for ERC721 tokens. A minter wallet (i.e. holder of MINTERROLE) can (lazy)mint 'n' tokens at once by providing a single base URI for all tokens being lazy minted. The URI for each of the 'n' tokens lazy minted is the provided base URI + of the respective token. (e.g. "ipfs://Qmece.../1"). A minter can choose to lazy mint 'delayed-reveal' tokens. More on 'delayed-reveal' tokens in this article. A contract admin (i.e. holder of DEFAULTADMIN_ROLE) can create claim conditions with non-overlapping time windows, and accounts can claim the tokens according to restrictions defined in the claim condition that is active at the time of the transaction.

📄️ IEditionStake

Thirdweb's EditionStake smart contract allows users to stake their ERC-1155 NFTs and earn rewards in form of an ERC-20 token. note: - Reward token and staking token can't be changed after deployment. - ERC1155 tokens from only the specified contract can be staked. - All token/NFT transfers require approval on their respective contracts. - Admin must deposit reward tokens using the depositRewardTokens function only. Any direct transfers may cause unintended consequences, such as locking of tokens. - Users must stake NFTs using the stake function only. Any direct transfers may cause unintended consequences, such as locking of NFTs.

📄️ INFTStake

Thirdweb's NFTStake smart contract allows users to stake their ERC-721 NFTs and earn rewards in form of an ERC-20 token. note: - Reward token and staking token can't be changed after deployment. - ERC721 tokens from only the specified contract can be staked. - All token/NFT transfers require approval on their respective contracts. - Admin must deposit reward tokens using the depositRewardTokens function only. Any direct transfers may cause unintended consequences, such as locking of tokens. - Users must stake NFTs using the stake function only. Any direct transfers may cause unintended consequences, such as locking of NFTs.

📄️ ITokenStake

Thirdweb's TokenStake smart contract allows users to stake their ERC-20 Tokens and earn rewards in form of a different ERC-20 token. note: - Reward token and staking token can't be changed after deployment. Reward token contract can't be same as the staking token contract. - ERC20 tokens from only the specified contract can be staked. - All token transfers require approval on their respective token-contracts. - Admin must deposit reward tokens using the depositRewardTokens function only. Any direct transfers may cause unintended consequences, such as locking of tokens. - Users must stake tokens using the stake function only. Any direct transfers may cause unintended consequences, such as locking of tokens.

📄️ Initializable

This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since proxied contracts do not make use of a constructor, it's common to move constructor logic to an external initializer function, usually called initialize. It then becomes necessary to protect this initializer function so it can only be called once. The modifier provided by this contract will have this effect. The initialization functions use a version number. Once a version number is used, it is consumed and cannot be reused. This mechanism prevents re-execution of each "step" but allows the creation of new initialization steps in case an upgrade adds a module that needs to be initialized. For example To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the data argument to {ERC1967Proxy-constructor}. CAUTION [.hljs-theme-light.nopadding] `

📄️ Proxy

This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction delegatecall. We refer to the second contract as the *implementation* behind the proxy, and it has to be specified by overriding the virtual {\implementation} function. Additionally, delegation to the implementation can be triggered manually through the {\fallback} function, or to a different contract through the {\delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy._

📄️ ReentrancyGuardLogic

Contract module that helps prevent reentrant calls to a function. Inheriting from ReentrancyGuard will make the modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single nonReentrant guard, functions marked as nonReentrant may not call one another. This can be worked around by making those functions private, and then adding external nonReentrant entry points to them. TIP//blog.openzeppelin.com/reentrancy-after-istanbul/.

📄️ SafeCast

Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. SafeCast restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with and {SignedSafeMath} to extend it to smaller types, by performing all math on uint256 and int256 and then downcasting.

📄️ SafeCastUpgradeable

Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. SafeCast restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with and {SignedSafeMath} to extend it to smaller types, by performing all math on uint256 and int256 and then downcasting.

📄️ SoulboundERC721A

The SoulboundERC721A extension smart contract is meant to be used with ERC721A contracts as its base. It provides the appropriate before transfer hook for ERC721A, where it checks whether a given transfer is valid to go through or not. This contract uses the Permissions extension, and creates a role 'TRANSFER_ROLE'. - If address(0) holds the transfer role, then all transfers go through. - Else, a transfer goes through only if either the sender or recipient holds the transfer role.

📄️ StorageSlot

Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a value member that can be used to read or write. Example usage to set ERC1967 implementation slot new implementation is not a contract"); StorageSlot.getAddressSlot(IMPLEMENTATIONSLOT).value = newImplementation; } } *Available since v4.1 for address, bool, bytes32, and uint256.*

📄️ TWStorageSlot

Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a value member that can be used to read or write. Example usage to set ERC1967 implementation slot new implementation is not a contract"); StorageSlot.getAddressSlot(IMPLEMENTATIONSLOT).value = newImplementation; } } *Available since v4.1 for address, bool, bytes32, and uint256.*

📄️ Upgradeable

An upgradeability mechanism designed for UUPS proxies. The functions included here can perform an upgrade of an , when this contract is set as the implementation behind such a proxy. A security mechanism ensures that an upgrade does not turn off upgradeability accidentally, although this risk is reinstated if the upgrade retains upgradeability but removes the security mechanism, e.g. by replacing UUPSUpgradeable with a custom implementation of upgrades. The {*authorizeUpgrade} function must be overridden to include access restriction to the upgrade mechanism. \Available since v4.1.*_