Utilities

This document is better viewed at https://docs.openzeppelin.com/contracts/api/utils

Miscellaneous contracts and libraries containing utility functions you can use to improve security, work with new data types, or safely use low-level primitives.

The Address, Arrays and Strings libraries provide more operations related to these native data types, while SafeCast adds ways to safely convert between the different signed and unsigned numeric types.

For new data types:

  • Counters: a simple way to get a counter that can only be incremented or decremented. Very useful for ID generation, counting contract activity, among others.

  • EnumerableMap: like Solidity’s mapping type, but with key-value enumeration: this will let you know how many entries a mapping has, and iterate over them (which is not possible with mapping).

  • EnumerableSet: like EnumerableMap, but for sets. Can be used to store privileged accounts, issued IDs, etc.

Because Solidity does not support generic types, EnumerableMap and EnumerableSet are specialized to a limited number of key-value types.

As of v3.0, EnumerableMap supports uint256 → address (UintToAddressMap), and EnumerableSet supports address and uint256 (AddressSet and UintSet).

Finally, Create2 contains all necessary utilities to safely use the CREATE2 EVM opcode, without having to deal with low-level assembly.

Math

Math

Standard math utilities missing in the Solidity language.

Functions

max(uint256 a, uint256 b) → uint256 internal

Returns the largest of two numbers.

min(uint256 a, uint256 b) → uint256 internal

Returns the smallest of two numbers.

average(uint256 a, uint256 b) → uint256 internal

Returns the average of two numbers. The result is rounded towards zero.

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 SafeMath and SignedSafeMath to extend it to smaller types, by performing all math on uint256 and int256 and then downcasting.

Functions

toUint128(uint256 value) → uint128 internal

Returns the downcasted uint128 from uint256, reverting on overflow (when the input is greater than largest uint128).

Counterpart to Solidity’s uint128 operator.

Requirements:

  • input must fit into 128 bits

toUint64(uint256 value) → uint64 internal

Returns the downcasted uint64 from uint256, reverting on overflow (when the input is greater than largest uint64).

Counterpart to Solidity’s uint64 operator.

Requirements:

  • input must fit into 64 bits

toUint32(uint256 value) → uint32 internal

Returns the downcasted uint32 from uint256, reverting on overflow (when the input is greater than largest uint32).

Counterpart to Solidity’s uint32 operator.

Requirements:

  • input must fit into 32 bits

toUint16(uint256 value) → uint16 internal

Returns the downcasted uint16 from uint256, reverting on overflow (when the input is greater than largest uint16).

Counterpart to Solidity’s uint16 operator.

Requirements:

  • input must fit into 16 bits

toUint8(uint256 value) → uint8 internal

Returns the downcasted uint8 from uint256, reverting on overflow (when the input is greater than largest uint8).

Counterpart to Solidity’s uint8 operator.

Requirements:

  • input must fit into 8 bits.

toUint256(int256 value) → uint256 internal

Converts a signed int256 into an unsigned uint256.

Requirements:

  • input must be greater than or equal to 0.

toInt128(int256 value) → int128 internal

Returns the downcasted int128 from int256, reverting on overflow (when the input is less than smallest int128 or greater than largest int128).

Counterpart to Solidity’s int128 operator.

Requirements:

  • input must fit into 128 bits

Available since v3.1.

toInt64(int256 value) → int64 internal

Returns the downcasted int64 from int256, reverting on overflow (when the input is less than smallest int64 or greater than largest int64).

Counterpart to Solidity’s int64 operator.

Requirements:

  • input must fit into 64 bits

Available since v3.1.

toInt32(int256 value) → int32 internal

Returns the downcasted int32 from int256, reverting on overflow (when the input is less than smallest int32 or greater than largest int32).

Counterpart to Solidity’s int32 operator.

Requirements:

  • input must fit into 32 bits

Available since v3.1.

toInt16(int256 value) → int16 internal

Returns the downcasted int16 from int256, reverting on overflow (when the input is less than smallest int16 or greater than largest int16).

Counterpart to Solidity’s int16 operator.

Requirements:

  • input must fit into 16 bits

Available since v3.1.

toInt8(int256 value) → int8 internal

Returns the downcasted int8 from int256, reverting on overflow (when the input is less than smallest int8 or greater than largest int8).

Counterpart to Solidity’s int8 operator.

Requirements:

  • input must fit into 8 bits.

Available since v3.1.

toInt256(uint256 value) → int256 internal

Converts an unsigned uint256 into a signed int256.

Requirements:

  • input must be less than or equal to maxInt256.

SafeMath

Wrappers over Solidity’s arithmetic operations.

SafeMath is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking.
Functions

tryAdd(uint256 a, uint256 b) → bool, uint256 internal

Returns the addition of two unsigned integers, with an overflow flag.

Available since v3.4.

trySub(uint256 a, uint256 b) → bool, uint256 internal

Returns the substraction of two unsigned integers, with an overflow flag.

Available since v3.4.

tryMul(uint256 a, uint256 b) → bool, uint256 internal

Returns the multiplication of two unsigned integers, with an overflow flag.

Available since v3.4.

tryDiv(uint256 a, uint256 b) → bool, uint256 internal

Returns the division of two unsigned integers, with a division by zero flag.

Available since v3.4.

tryMod(uint256 a, uint256 b) → bool, uint256 internal

Returns the remainder of dividing two unsigned integers, with a division by zero flag.

Available since v3.4.

add(uint256 a, uint256 b) → uint256 internal

Returns the addition of two unsigned integers, reverting on overflow.

Counterpart to Solidity’s + operator.

Requirements:

  • Addition cannot overflow.

sub(uint256 a, uint256 b) → uint256 internal

Returns the subtraction of two unsigned integers, reverting on overflow (when the result is negative).

Counterpart to Solidity’s - operator.

Requirements:

  • Subtraction cannot overflow.

mul(uint256 a, uint256 b) → uint256 internal

Returns the multiplication of two unsigned integers, reverting on overflow.

Counterpart to Solidity’s * operator.

Requirements:

  • Multiplication cannot overflow.

div(uint256 a, uint256 b) → uint256 internal

Returns the integer division of two unsigned integers, reverting on division by zero. The result is rounded towards zero.

Counterpart to Solidity’s / operator.

Requirements:

  • The divisor cannot be zero.

mod(uint256 a, uint256 b) → uint256 internal

Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting when dividing by zero.

Counterpart to Solidity’s % operator. This function uses a revert opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero.

sub(uint256 a, uint256 b, string errorMessage) → uint256 internal

Returns the subtraction of two unsigned integers, reverting with custom message on overflow (when the result is negative).

This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use trySub.

Counterpart to Solidity’s - operator.

Requirements:

  • Subtraction cannot overflow.

div(uint256 a, uint256 b, string errorMessage) → uint256 internal

Returns the integer division of two unsigned integers, reverting with custom message on division by zero. The result is rounded towards zero.

Counterpart to Solidity’s % operator. This function uses a revert opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Counterpart to Solidity’s / operator. Note: this function uses a revert opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero.

mod(uint256 a, uint256 b, string errorMessage) → uint256 internal

Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), reverting with custom message when dividing by zero.

This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use tryMod.

Counterpart to Solidity’s % operator. This function uses a revert opcode (which leaves remaining gas untouched) while Solidity uses an invalid opcode to revert (consuming all remaining gas).

Requirements:

  • The divisor cannot be zero.

SignedSafeMath

Wrappers over Solidity’s arithmetic operations.

SignedSafeMath is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking.
Functions

mul(int256 a, int256 b) → int256 internal

Returns the multiplication of two signed integers, reverting on overflow.

Counterpart to Solidity’s * operator.

Requirements:

  • Multiplication cannot overflow.

div(int256 a, int256 b) → int256 internal

Returns the integer division of two signed integers. Reverts on division by zero. The result is rounded towards zero.

Counterpart to Solidity’s / operator.

Requirements:

  • The divisor cannot be zero.

sub(int256 a, int256 b) → int256 internal

Returns the subtraction of two signed integers, reverting on overflow.

Counterpart to Solidity’s - operator.

Requirements:

  • Subtraction cannot overflow.

add(int256 a, int256 b) → int256 internal

Returns the addition of two signed integers, reverting on overflow.

Counterpart to Solidity’s + operator.

Requirements:

  • Addition cannot overflow.

Cryptography

ECDSA

Elliptic Curve Digital Signature Algorithm (ECDSA) operations.

These functions can be used to verify that a message was signed by the holder of the private keys of a given address.

Functions

recover(bytes32 hash, bytes signature) → address internal

Returns the address that signed a hashed message (hash) with signature. This address can then be used for verification purposes.

The ecrecover EVM opcode allows for malleable (non-unique) signatures: this function rejects them by requiring the s value to be in the lower half order, and the v value to be either 27 or 28.

hash must be the result of a hash operation for the verification to be secure: it is possible to craft signatures that recover to arbitrary addresses for non-hashed data. A safe way to ensure this is by receiving a hash of the original message (which may otherwise be too long), and then calling toEthSignedMessageHash on it.

recover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) → address internal

Overload of ECDSA.recover that receives the v, r and s signature fields separately.

toEthSignedMessageHash(bytes32 hash) → bytes32 internal

Returns an Ethereum Signed Message, created from a hash. This produces hash corresponding to the one signed with the eth_sign JSON-RPC method as part of EIP-191.

See recover. /

toTypedDataHash(bytes32 domainSeparator, bytes32 structHash) → bytes32 internal

Returns an Ethereum Signed Typed Data, created from a domainSeparator and a structHash. This produces hash corresponding to the one signed with the eth_signTypedData JSON-RPC method as part of EIP-712.

See recover. /

MerkleProof

These functions deal with verification of Merkle Trees proofs.

The proofs can be generated using the JavaScript library merkletreejs. Note: the hashing algorithm should be keccak256 and pair sorting should be enabled.

See test/utils/cryptography/MerkleProof.test.js for some examples.

Functions

verify(bytes32[] proof, bytes32 root, bytes32 leaf) → bool internal

Returns true if a leaf can be proved to be a part of a Merkle tree defined by root. For this, a proof must be provided, containing sibling hashes on the branch from the leaf to the root of the tree. Each pair of leaves and each pair of pre-images are assumed to be sorted.

EIP712

EIP 712 is a standard for hashing and signing of typed structured data.

The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of abi.encode and keccak256.

This contract implements the EIP 712 domain separator (_domainSeparatorV4) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA (_hashTypedDataV4).

The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain.

This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method eth_signTypedDataV4 in MetaMask.

Available since v3.4.

Functions

constructor(string name, string version) internal

Initializes the domain separator and parameter caches.

The meaning of name and version is specified in EIP 712:

  • name: the user readable name of the signing domain, i.e. the name of the DApp or the protocol.

  • version: the current major version of the signing domain.

These parameters cannot be changed except through a smart contract upgrade.

_domainSeparatorV4() → bytes32 internal

Returns the domain separator for the current chain.

_hashTypedDataV4(bytes32 structHash) → bytes32 internal

Given an already hashed struct, this function returns the hash of the fully encoded EIP712 message for this domain.

This hash can be used together with ECDSA.recover to obtain the signer of a message. For example:

bytes32 digest = _hashTypedDataV4(keccak256(abi.encode(
    keccak256("Mail(address to,string contents)"),
    mailTo,
    keccak256(bytes(mailContents))
)));
address signer = ECDSA.recover(digest, signature);

Escrow

ConditionalEscrow

Base abstract escrow to only allow withdrawal if a condition is met. Intended usage: See Escrow. Same usage guidelines apply here.

Functions
Escrow
Ownable
Events
Escrow
Ownable

withdrawalAllowed(address payee) → bool public

Returns whether an address is allowed to withdraw their funds. To be implemented by derived contracts.

withdraw(address payable payee) public

Escrow

Base escrow contract, holds funds designated for a payee until they withdraw them.

Intended usage: This contract (and derived escrow contracts) should be a standalone contract, that only interacts with the contract that instantiated it. That way, it is guaranteed that all Ether will be handled according to the Escrow rules, and there is no need to check for payable functions or transfers in the inheritance tree. The contract that uses the escrow as its payment method should be its owner, and provide public methods redirecting to the escrow’s deposit and withdraw.

Functions
Ownable
Events
Ownable

depositsOf(address payee) → uint256 public

deposit(address payee) public

Stores the sent amount as credit to be withdrawn.

withdraw(address payable payee) public

Withdraw accumulated balance for a payee, forwarding all gas to the recipient.

Forwarding all gas opens the door to reentrancy vulnerabilities. Make sure you trust the recipient, or are either following the checks-effects-interactions pattern or using ReentrancyGuard.

Deposited(address payee, uint256 weiAmount) event

Withdrawn(address payee, uint256 weiAmount) event

RefundEscrow

Escrow that holds funds for a beneficiary, deposited from multiple parties. Intended usage: See Escrow. Same usage guidelines apply here. The owner account (that is, the contract that instantiates this contract) may deposit, close the deposit period, and allow for either withdrawal by the beneficiary, or refunds to the depositors. All interactions with RefundEscrow will be made through the owner contract.

Functions
ConditionalEscrow
Escrow
Ownable
Events
Escrow
Ownable

constructor(address payable beneficiary_) public

Constructor.

state() → enum RefundEscrow.State public

beneficiary() → address payable public

deposit(address refundee) public

Stores funds that may later be refunded.

close() public

Allows for the beneficiary to withdraw their funds, rejecting further deposits.

enableRefunds() public

Allows for refunds to take place, rejecting further deposits.

beneficiaryWithdraw() public

Withdraws the beneficiary’s funds.

withdrawalAllowed(address) → bool public

Returns whether refundees can withdraw their deposits (be refunded). The overridden function receives a 'payee' argument, but we ignore it here since the condition is global, not per-payee.

RefundsClosed() event

RefundsEnabled() event

Introspection

This set of interfaces and contracts deal with type introspection of contracts, that is, examining which functions can be called on them. This is usually referred to as a contract’s interface.

Ethereum contracts have no native concept of an interface, so applications must usually simply trust they are not making an incorrect call. For trusted setups this is a non-issue, but often unknown and untrusted third-party addresses need to be interacted with. There may even not be any direct calls to them! (e.g. ERC20 tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever). In these cases, a contract declaring its interface can be very helpful in preventing errors.

There are two main ways to approach this.

  • Locally, where a contract implements IERC165 and declares an interface, and a second one queries it directly via ERC165Checker.

  • Globally, where a global and unique registry (IERC1820Registry) is used to register implementers of a certain interface (IERC1820Implementer). It is then the registry that is queried, which allows for more complex setups, like contracts implementing interfaces for externally-owned accounts.

Note that, in all cases, accounts simply declare their interfaces, but they are not required to actually implement them. This mechanism can therefore be used to both prevent errors and allow for complex interactions (see ERC777), but it must not be relied on for security.

IERC165

Interface of the ERC165 standard, as defined in the EIP.

Implementers can declare support of contract interfaces, which can then be queried by others (ERC165Checker).

For an implementation, see ERC165.

Functions

supportsInterface(bytes4 interfaceId) → bool external

Returns true if this contract implements the interface defined by interfaceId. See the corresponding EIP section to learn more about how these ids are created.

This function call must use less than 30 000 gas.

ERC165

Implementation of the IERC165 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:

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.

Functions

supportsInterface(bytes4 interfaceId) → bool public

See IERC165.supportsInterface.

ERC165Storage

Storage based implementation of the IERC165 interface.

Contracts may inherit from this and call _registerInterface to declare their support of an interface.

Functions

supportsInterface(bytes4 interfaceId) → bool public

See IERC165.supportsInterface.

_registerInterface(bytes4 interfaceId) internal

Registers the contract as an implementer of the interface defined by interfaceId. Support of the actual ERC165 interface is automatic and registering its interface id is not required.

See IERC165.supportsInterface.

Requirements:

  • interfaceId cannot be the ERC165 invalid interface (0xffffffff).

ERC165Checker

Library used to query support of an interface declared via IERC165.

Note that these functions return the actual result of the query: they do not revert if an interface is not supported. It is up to the caller to decide what to do in these cases.

Functions

supportsERC165(address account) → bool internal

Returns true if account supports the IERC165 interface,

supportsInterface(address account, bytes4 interfaceId) → bool internal

Returns true if account supports the interface defined by interfaceId. Support for IERC165 itself is queried automatically.

See IERC165.supportsInterface.

getSupportedInterfaces(address account, bytes4[] interfaceIds) → bool[] internal

Returns a boolean array where each value corresponds to the interfaces passed in and whether they’re supported or not. This allows you to batch check interfaces for a contract where your expectation is that some interfaces may not be supported.

See IERC165.supportsInterface.

Available since v3.4.

supportsAllInterfaces(address account, bytes4[] interfaceIds) → bool internal

Returns true if account supports all the interfaces defined in interfaceIds. Support for IERC165 itself is queried automatically.

Batch-querying can lead to gas savings by skipping repeated checks for IERC165 support.

See IERC165.supportsInterface.

IERC1820Registry

Interface of the global ERC1820 Registry, as defined in the EIP. Accounts may register implementers for interfaces in this registry, as well as query support.

Implementers may be shared by multiple accounts, and can also implement more than a single interface for each account. Contracts can implement interfaces for themselves, but externally-owned accounts (EOA) must delegate this to a contract.

IERC165 interfaces can also be queried via the registry.

For an in-depth explanation and source code analysis, see the EIP text.

Functions
Events

setManager(address account, address newManager) external

Sets newManager as the manager for account. A manager of an account is able to set interface implementers for it.

By default, each account is its own manager. Passing a value of 0x0 in newManager will reset the manager to this initial state.

Emits a ManagerChanged event.

Requirements:

  • the caller must be the current manager for account.

getManager(address account) → address external

Returns the manager for account.

See setManager.

setInterfaceImplementer(address account, bytes32 _interfaceHash, address implementer) external

Sets the implementer contract as account's implementer for interfaceHash.

account being the zero address is an alias for the caller’s address. The zero address can also be used in implementer to remove an old one.

See interfaceHash to learn how these are created.

Emits an InterfaceImplementerSet event.

Requirements:

getInterfaceImplementer(address account, bytes32 _interfaceHash) → address external

Returns the implementer of interfaceHash for account. If no such implementer is registered, returns the zero address.

If interfaceHash is an IERC165 interface id (i.e. it ends with 28 zeroes), account will be queried for support of it.

account being the zero address is an alias for the caller’s address.

interfaceHash(string interfaceName) → bytes32 external

Returns the interface hash for an interfaceName, as defined in the corresponding section of the EIP.

updateERC165Cache(address account, bytes4 interfaceId) external

implementsERC165Interface(address account, bytes4 interfaceId) → bool external

implementsERC165InterfaceNoCache(address account, bytes4 interfaceId) → bool external

InterfaceImplementerSet(address account, bytes32 interfaceHash, address implementer) event

ManagerChanged(address account, address newManager) event

IERC1820Implementer

Interface for an ERC1820 implementer, as defined in the EIP. Used by contracts that will be registered as implementers in the IERC1820Registry.

Functions

canImplementInterfaceForAddress(bytes32 interfaceHash, address account) → bytes32 external

Returns a special value (ERC1820_ACCEPT_MAGIC) if this contract implements interfaceHash for account.

See IERC1820Registry.setInterfaceImplementer.

ERC1820Implementer

Implementation of the IERC1820Implementer interface.

Contracts may inherit from this and call _registerInterfaceForAddress to declare their willingness to be implementers. IERC1820Registry.setInterfaceImplementer should then be called for the registration to be complete.

Functions

canImplementInterfaceForAddress(bytes32 interfaceHash, address account) → bytes32 public

_registerInterfaceForAddress(bytes32 interfaceHash, address account) internal

Declares the contract as willing to be an implementer of interfaceHash for account.

See IERC1820Registry.setInterfaceImplementer and IERC1820Registry.interfaceHash.

Data Structures

EnumerableMap

Library for managing an enumerable variant of Solidity’s mapping type.

Maps have the following properties:

  • Entries are added, removed, and checked for existence in constant time (O(1)).

  • Entries are enumerated in O(n). No guarantees are made on the ordering.

contract Example {
    // Add the library methods
    using EnumerableMap for EnumerableMap.UintToAddressMap;

    // Declare a set state variable
    EnumerableMap.UintToAddressMap private myMap;
}

As of v3.0.0, only maps of type uint256 → address (UintToAddressMap) are supported.

Functions

set(struct EnumerableMap.UintToAddressMap map, uint256 key, address value) → bool internal

Adds a key-value pair to a map, or updates the value for an existing key. O(1).

Returns true if the key was added to the map, that is if it was not already present.

remove(struct EnumerableMap.UintToAddressMap map, uint256 key) → bool internal

Removes a value from a set. O(1).

Returns true if the key was removed from the map, that is if it was present.

contains(struct EnumerableMap.UintToAddressMap map, uint256 key) → bool internal

Returns true if the key is in the map. O(1).

length(struct EnumerableMap.UintToAddressMap map) → uint256 internal

Returns the number of elements in the map. O(1).

at(struct EnumerableMap.UintToAddressMap map, uint256 index) → uint256, address internal

Returns the element stored at position index in the set. O(1). Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • index must be strictly less than length.

tryGet(struct EnumerableMap.UintToAddressMap map, uint256 key) → bool, address internal

Tries to returns the value associated with key. O(1). Does not revert if key is not in the map.

Available since v3.4.

get(struct EnumerableMap.UintToAddressMap map, uint256 key) → address internal

Returns the value associated with key. O(1).

Requirements:

  • key must be in the map.

get(struct EnumerableMap.UintToAddressMap map, uint256 key, string errorMessage) → address internal

Same as get, with a custom error message when key is not in the map.

This function is deprecated because it requires allocating memory for the error message unnecessarily. For custom revert reasons use tryGet.

EnumerableSet

Library for managing sets of primitive types.

Sets have the following properties:

  • 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.

Functions

add(struct EnumerableSet.Bytes32Set set, bytes32 value) → bool internal

Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present.

remove(struct EnumerableSet.Bytes32Set set, bytes32 value) → bool internal

Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present.

contains(struct EnumerableSet.Bytes32Set set, bytes32 value) → bool internal

Returns true if the value is in the set. O(1).

length(struct EnumerableSet.Bytes32Set set) → uint256 internal

Returns the number of values in the set. O(1).

at(struct EnumerableSet.Bytes32Set set, uint256 index) → bytes32 internal

Returns the value stored at position index in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • index must be strictly less than length.

add(struct EnumerableSet.AddressSet set, address value) → bool internal

Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present.

remove(struct EnumerableSet.AddressSet set, address value) → bool internal

Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present.

contains(struct EnumerableSet.AddressSet set, address value) → bool internal

Returns true if the value is in the set. O(1).

length(struct EnumerableSet.AddressSet set) → uint256 internal

Returns the number of values in the set. O(1).

at(struct EnumerableSet.AddressSet set, uint256 index) → address internal

Returns the value stored at position index in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • index must be strictly less than length.

add(struct EnumerableSet.UintSet set, uint256 value) → bool internal

Add a value to a set. O(1).

Returns true if the value was added to the set, that is if it was not already present.

remove(struct EnumerableSet.UintSet set, uint256 value) → bool internal

Removes a value from a set. O(1).

Returns true if the value was removed from the set, that is if it was present.

contains(struct EnumerableSet.UintSet set, uint256 value) → bool internal

Returns true if the value is in the set. O(1).

length(struct EnumerableSet.UintSet set) → uint256 internal

Returns the number of values on the set. O(1).

at(struct EnumerableSet.UintSet set, uint256 index) → uint256 internal

Returns the value stored at position index in the set. O(1).

Note that there are no guarantees on the ordering of values inside the array, and it may change when more values are added or removed.

Requirements:

  • index must be strictly less than length.

Libraries

Create2

Helper to make usage of the CREATE2 EVM opcode easier and safer. CREATE2 can be used to compute in advance the address where a smart contract will be deployed, which allows for interesting new mechanisms known as 'counterfactual interactions'.

See the EIP for more information.

Functions

deploy(uint256 amount, bytes32 salt, bytes bytecode) → address internal

Deploys a contract using CREATE2. The address where the contract will be deployed can be known in advance via computeAddress.

The bytecode for a contract can be obtained from Solidity with type(contractName).creationCode.

Requirements:

  • bytecode must not be empty.

  • salt must have not been used for bytecode already.

  • the factory must have a balance of at least amount.

  • if amount is non-zero, bytecode must have a payable constructor.

computeAddress(bytes32 salt, bytes32 bytecodeHash) → address internal

Returns the address where a contract will be stored if deployed via deploy. Any change in the bytecodeHash or salt will result in a new destination address.

computeAddress(bytes32 salt, bytes32 bytecodeHash, address deployer) → address internal

Returns the address where a contract will be stored if deployed via deploy from a contract located at deployer. If deployer is this contract’s address, returns the same value as computeAddress.

Address

Collection of functions related to the address type

Functions

isContract(address account) → bool internal

Returns true if account is a contract.

It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract.

Among others, isContract will return false for the following types of addresses:

  • an externally-owned account

  • a contract in construction

  • an address where a contract will be created

  • an address where a contract lived, but was destroyed

sendValue(address payable recipient, uint256 amount) internal

Replacement for Solidity’s transfer: sends amount wei to recipient, forwarding all available gas and reverting on errors.

EIP1884 increases the gas cost of certain opcodes, possibly making contracts go over the 2300 gas limit imposed by transfer, making them unable to receive funds via transfer. sendValue removes this limitation.

Learn more.

because control is transferred to recipient, care must be taken to not create reentrancy vulnerabilities. Consider using ReentrancyGuard or the checks-effects-interactions pattern.

functionCall(address target, bytes data) → bytes internal

Performs a Solidity function call using a low level call. A plain`call` is an unsafe replacement for a function call: use this function instead.

If target reverts with a revert reason, it is bubbled up by this function (like regular Solidity function calls).

Returns the raw returned data. To convert to the expected return value, use abi.decode.

Requirements:

  • target must be a contract.

  • calling target with data must not revert.

Available since v3.1.

functionCall(address target, bytes data, string errorMessage) → bytes internal

Same as functionCall, but with errorMessage as a fallback revert reason when target reverts.

Available since v3.1.

functionCallWithValue(address target, bytes data, uint256 value) → bytes internal

Same as functionCall, but also transferring value wei to target.

Requirements:

  • the calling contract must have an ETH balance of at least value.

  • the called Solidity function must be payable.

Available since v3.1.

functionCallWithValue(address target, bytes data, uint256 value, string errorMessage) → bytes internal

Same as functionCallWithValue, but with errorMessage as a fallback revert reason when target reverts.

Available since v3.1.

functionStaticCall(address target, bytes data) → bytes internal

Same as functionCall, but performing a static call.

Available since v3.3.

functionStaticCall(address target, bytes data, string errorMessage) → bytes internal

Same as functionCall, but performing a static call.

Available since v3.3.

functionDelegateCall(address target, bytes data) → bytes internal

Same as functionCall, but performing a delegate call.

Available since v3.4.

functionDelegateCall(address target, bytes data, string errorMessage) → bytes internal

Same as functionCall, but performing a delegate call.

Available since v3.4.

Arrays

Collection of functions related to array types.

Functions

findUpperBound(uint256[] array, uint256 element) → uint256 internal

Searches a sorted array and returns the first index that contains a value greater or equal to element. If no such index exists (i.e. all values in the array are strictly less than element), the array length is returned. Time complexity O(log n).

array is expected to be sorted in ascending order, and to contain no repeated elements.

Counters

Provides counters that can only be incremented or decremented by one. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids.

Include with using Counters for Counters.Counter;

Functions

current(struct Counters.Counter counter) → uint256 internal

increment(struct Counters.Counter counter) internal

decrement(struct Counters.Counter counter) internal

Strings

String operations.

Functions

toString(uint256 value) → string internal

Converts a uint256 to its ASCII string decimal representation.

toHexString(uint256 value) → string internal

Converts a uint256 to its ASCII string hexadecimal representation.

toHexString(uint256 value, uint256 length) → string internal

Converts a uint256 to its ASCII string hexadecimal representation with fixed length.

← Security