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.

📄️ 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 roaylties. - 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 LazyMint, DelayedReveal The ERC1155DelayedReveal contract uses the ERC1155Base contract, along with the LazyMint and 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 SignatureMintERC1155, DropSinglePhase1155 The ERC1155Drop contract uses the ERC1155Base contract, along with the SignatureMintERC1155 and DropSinglePhase1155 extension. The 'signature minting' mechanism in the SignatureMintERC1155 extension 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. 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 atttempts to mint lazy minted tokens. The ERC721Drop contract lets you lazy mint tokens, and distribute those lazy minted tokens via signature minting, or via the drop mechanism.

📄️ 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}._

📄️ ERC20Drop

BASE SignatureMintERC20, DropSinglePhase The ERC20Drop contract uses the ERC20Base contract, along with the SignatureMintERC20 and DropSinglePhase extensions. The 'signature minting' mechanism in the SignatureMintERC20 extension 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. The drop mechanism in the DropSinglePhase extension is a distribution mechanism for tokens. It lets you set restrictions such as a price to charge, an allowlist etc. when an address atttempts to mint tokens.

📄️ ERC20DropVote

BASE SignatureMintERC20, DropSinglePhase The ERC20Drop contract uses the ERC20Vote contract, along with the SignatureMintERC20 and DropSinglePhase extensions. The 'signature minting' mechanism in the SignatureMintERC20 extension 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. 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 atttempts 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 roaylties. - 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 LazyMint, DelayedReveal The ERC721DelayedReveal contract uses the ERC721Base contract, along with the LazyMint and 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 SignatureMintERC721, DropSinglePhase The ERC721Drop contract uses the ERC721Base contract, along with the SignatureMintERC721 and DropSinglePhase extension. The 'signature minting' mechanism in the SignatureMintERC721 extension 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. 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 atttempts to mint lazy minted tokens. The ERC721Drop contract lets you lazy mint tokens, and distribute those lazy minted tokens via signature minting, or via the drop mechanism.

📄️ 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.

📄️ 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. "ipsf://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. "ipsf://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.

📄️ 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. TIP When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity. [CAUTION] ==== Avoid leaving a contract uninitialized. An uninitialized contract can be taken over by an attacker. This applies to both a proxy and its implementation contract, which may impact the proxy. To initialize the implementation contract, you can either invoke the initializer manually, or you can include a constructor to automatically mark it as initialized when it is deployed: [.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._

📄️ ReentrancyGuardUpgradeable

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 transfe 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.*