Interfaces
| This document is better viewed at https://docs.openzeppelin.com/contracts/api/interfaces |
List of standardized interfaces
These interfaces are available as .sol files, and also as compiler .json ABI files (through the npm package). These
are useful to interact with third party contracts that implement them.
Detailed ABI
IERC20Errors
import "@openzeppelin/contracts/interfaces/draft-IERC6093.sol";
Standard ERC-20 Errors Interface of the ERC-6093 custom errors for ERC-20 tokens.
ERC20InsufficientBalance(address sender, uint256 balance, uint256 needed) error
Indicates an error related to the current balance of a sender. Used in transfers.
ERC20InvalidSender(address sender) error
Indicates a failure with the token sender. Used in transfers.
ERC20InvalidReceiver(address receiver) error
Indicates a failure with the token receiver. Used in transfers.
ERC20InsufficientAllowance(address spender, uint256 allowance, uint256 needed) error
Indicates a failure with the spender’s allowance. Used in transfers.
IERC721Errors
import "@openzeppelin/contracts/interfaces/draft-IERC6093.sol";
Standard ERC-721 Errors Interface of the ERC-6093 custom errors for ERC-721 tokens.
ERC721InvalidOwner(address owner) error
Indicates that an address can’t be an owner. For example, address(0) is a forbidden owner in ERC-721.
Used in balance queries.
ERC721IncorrectOwner(address sender, uint256 tokenId, address owner) error
Indicates an error related to the ownership over a particular token. Used in transfers.
ERC721InvalidSender(address sender) error
Indicates a failure with the token sender. Used in transfers.
ERC721InvalidReceiver(address receiver) error
Indicates a failure with the token receiver. Used in transfers.
ERC721InsufficientApproval(address operator, uint256 tokenId) error
Indicates a failure with the operator’s approval. Used in transfers.
IERC1155Errors
import "@openzeppelin/contracts/interfaces/draft-IERC6093.sol";
Standard ERC-1155 Errors Interface of the ERC-6093 custom errors for ERC-1155 tokens.
ERC1155InsufficientBalance(address sender, uint256 balance, uint256 needed, uint256 tokenId) error
Indicates an error related to the current balance of a sender. Used in transfers.
ERC1155InvalidSender(address sender) error
Indicates a failure with the token sender. Used in transfers.
ERC1155InvalidReceiver(address receiver) error
Indicates a failure with the token receiver. Used in transfers.
ERC1155MissingApprovalForAll(address operator, address owner) error
Indicates a failure with the operator’s approval. Used in transfers.
ERC1155InvalidApprover(address approver) error
Indicates a failure with the approver of a token to be approved. Used in approvals.
IERC1271
import "@openzeppelin/contracts/interfaces/IERC1271.sol";
Interface of the ERC-1271 standard signature validation method for contracts as defined in ERC-1271.
IERC1363
import "@openzeppelin/contracts/interfaces/IERC1363.sol";
Interface of the ERC-1363 standard as defined in the ERC-1363.
Defines an extension interface for ERC-20 tokens that supports executing code on a recipient contract
after transfer or transferFrom, or code on a spender contract after approve, in a single transaction.
transferAndCall(address to, uint256 value) → bool external
Moves a value amount of tokens from the caller’s account to to
and then calls IERC1363Receiver.onTransferReceived on to.
transferAndCall(address to, uint256 value, bytes data) → bool external
Moves a value amount of tokens from the caller’s account to to
and then calls IERC1363Receiver.onTransferReceived on to.
transferFromAndCall(address from, address to, uint256 value) → bool external
Moves a value amount of tokens from from to to using the allowance mechanism
and then calls IERC1363Receiver.onTransferReceived on to.
transferFromAndCall(address from, address to, uint256 value, bytes data) → bool external
Moves a value amount of tokens from from to to using the allowance mechanism
and then calls IERC1363Receiver.onTransferReceived on to.
approveAndCall(address spender, uint256 value) → bool external
Sets a value amount of tokens as the allowance of spender over the
caller’s tokens and then calls IERC1363Spender.onApprovalReceived on spender.
approveAndCall(address spender, uint256 value, bytes data) → bool external
Sets a value amount of tokens as the allowance of spender over the
caller’s tokens and then calls IERC1363Spender.onApprovalReceived on spender.
IERC1363Receiver
import "@openzeppelin/contracts/interfaces/IERC1363Receiver.sol";
Interface for any contract that wants to support transferAndCall or transferFromAndCall
from ERC-1363 token contracts.
onTransferReceived(address operator, address from, uint256 value, bytes data) → bytes4 external
Whenever ERC-1363 tokens are transferred to this contract via transferAndCall or transferFromAndCall
by operator from from, this function is called.
To accept the transfer, this must return
bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))
(i.e. 0x88a7ca5c, or its own function selector).
|
IERC1363Spender
import "@openzeppelin/contracts/interfaces/IERC1363Spender.sol";
Interface for any contract that wants to support approveAndCall
from ERC-1363 token contracts.
onApprovalReceived(address owner, uint256 value, bytes data) → bytes4 external
Whenever an ERC-1363 token owner approves this contract via approveAndCall
to spend their tokens, this function is called.
To accept the approval, this must return
bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))
(i.e. 0x7b04a2d0, or its own function selector).
|
IERC1820Implementer
import "@openzeppelin/contracts/interfaces/IERC1820Implementer.sol";
Interface for an ERC-1820 implementer, as defined in the
ERC.
Used by contracts that will be registered as implementers in the
IERC1820Registry.
IERC1820Registry
import "@openzeppelin/contracts/interfaces/IERC1820Registry.sol";
Interface of the global ERC-1820 Registry, as defined in the ERC. 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 ERC text.
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.
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:
-
the caller must be the current manager for
account. -
interfaceHashmust not be anIERC165interface id (i.e. it must not end in 28 zeroes). -
implementermust implementIERC1820Implementerand return true when queried for support, unlessimplementeris the caller. SeeIERC1820Implementer.canImplementInterfaceForAddress.
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 ERC.
IERC1822Proxiable
import "@openzeppelin/contracts/interfaces/draft-IERC1822.sol";
ERC-1822: Universal Upgradeable Proxy Standard (UUPS) documents a method for upgradeability through a simplified proxy whose upgrades are fully controlled by the current implementation.
proxiableUUID() → bytes32 external
Returns the storage slot that the proxiable contract assumes is being used to store the implementation address.
| A proxy pointing at a proxiable contract should not be considered proxiable itself, because this risks bricking a proxy that upgrades to it, by delegating to itself until out of gas. Thus it is critical that this function revert if invoked through a proxy. |
IERC2981
import "@openzeppelin/contracts/interfaces/IERC2981.sol";
Interface for the NFT Royalty Standard.
A standardized way to retrieve royalty payment information for non-fungible tokens (NFTs) to enable universal support for royalty payments across all NFT marketplaces and ecosystem participants.
royaltyInfo(uint256 tokenId, uint256 salePrice) → address receiver, uint256 royaltyAmount external
Returns how much royalty is owed and to whom, based on a sale price that may be denominated in any unit of exchange. The royalty amount is denominated and should be paid in that same unit of exchange.
| ERC-2981 allows setting the royalty to 100% of the price. In that case all the price would be sent to the royalty receiver and 0 tokens to the seller. Contracts dealing with royalty should consider empty transfers. |
IERC3156FlashLender
import "@openzeppelin/contracts/interfaces/IERC3156FlashLender.sol";
Interface of the ERC-3156 FlashLender, as defined in ERC-3156.
IERC3156FlashBorrower
import "@openzeppelin/contracts/interfaces/IERC3156FlashBorrower.sol";
Interface of the ERC-3156 FlashBorrower, as defined in ERC-3156.
IERC4626
import "@openzeppelin/contracts/interfaces/IERC4626.sol";
Interface of the ERC-4626 "Tokenized Vault Standard", as defined in ERC-4626.
asset() → address assetTokenAddress external
Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.
-
MUST be an ERC-20 token contract.
-
MUST NOT revert.
totalAssets() → uint256 totalManagedAssets external
Returns the total amount of the underlying asset that is “managed” by Vault.
-
SHOULD include any compounding that occurs from yield.
-
MUST be inclusive of any fees that are charged against assets in the Vault.
-
MUST NOT revert.
convertToShares(uint256 assets) → uint256 shares external
Returns the amount of shares that the Vault would exchange for the amount of assets provided, in an ideal scenario where all the conditions are met.
-
MUST NOT be inclusive of any fees that are charged against assets in the Vault.
-
MUST NOT show any variations depending on the caller.
-
MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
-
MUST NOT revert.
| This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and from. |
convertToAssets(uint256 shares) → uint256 assets external
Returns the amount of assets that the Vault would exchange for the amount of shares provided, in an ideal scenario where all the conditions are met.
-
MUST NOT be inclusive of any fees that are charged against assets in the Vault.
-
MUST NOT show any variations depending on the caller.
-
MUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.
-
MUST NOT revert.
| This calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the “average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and from. |
maxDeposit(address receiver) → uint256 maxAssets external
Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver, through a deposit call.
-
MUST return a limited value if receiver is subject to some deposit limit.
-
MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited.
-
MUST NOT revert.
previewDeposit(uint256 assets) → uint256 shares external
Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given current on-chain conditions.
-
MUST return as close to and no more than the exact amount of Vault shares that would be minted in a deposit call in the same transaction. I.e. deposit should return the same or more shares as previewDeposit if called in the same transaction.
-
MUST NOT account for deposit limits like those returned from maxDeposit and should always act as though the deposit would be accepted, regardless if the user has enough tokens approved, etc.
-
MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
-
MUST NOT revert.
| any unfavorable discrepancy between convertToShares and previewDeposit SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing. |
deposit(uint256 assets, address receiver) → uint256 shares external
Deposit assets underlying tokens and send the corresponding number of vault shares (shares) to receiver.
-
MUST emit the Deposit event.
-
MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the deposit execution, and are accounted for during deposit.
-
MUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).
| most implementations will require pre-approval of the Vault with the Vault’s underlying asset token. |
maxMint(address receiver) → uint256 maxShares external
Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call. - MUST return a limited value if receiver is subject to some mint limit. - MUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted. - MUST NOT revert.
previewMint(uint256 shares) → uint256 assets external
Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given current on-chain conditions.
-
MUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call in the same transaction. I.e. mint should return the same or fewer assets as previewMint if called in the same transaction.
-
MUST NOT account for mint limits like those returned from maxMint and should always act as though the mint would be accepted, regardless if the user has enough tokens approved, etc.
-
MUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.
-
MUST NOT revert.
| any unfavorable discrepancy between convertToAssets and previewMint SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by minting. |
mint(uint256 shares, address receiver) → uint256 assets external
Mints exactly shares vault shares to receiver in exchange for assets underlying tokens.
-
MUST emit the Deposit event.
-
MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint execution, and are accounted for during mint.
-
MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).
| most implementations will require pre-approval of the Vault with the Vault’s underlying asset token. |
maxWithdraw(address owner) → uint256 maxAssets external
Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the Vault, through a withdraw call.
-
MUST return a limited value if owner is subject to some withdrawal limit or timelock.
-
MUST NOT revert.
previewWithdraw(uint256 assets) → uint256 shares external
Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block, given current on-chain conditions.
-
MUST return as close to and no fewer than the exact amount of Vault shares that would be burned in a withdraw call in the same transaction. I.e. withdraw should return the same or fewer shares as previewWithdraw if called in the same transaction.
-
MUST NOT account for withdrawal limits like those returned from maxWithdraw and should always act as though the withdrawal would be accepted, regardless if the user has enough shares, etc.
-
MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
-
MUST NOT revert.
| any unfavorable discrepancy between convertToShares and previewWithdraw SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by depositing. |
withdraw(uint256 assets, address receiver, address owner) → uint256 shares external
Burns shares from owner and sends exactly assets of underlying tokens to receiver.
-
MUST emit the Withdraw event.
-
MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the withdraw execution, and are accounted for during withdraw.
-
MUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).
Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately.
maxRedeem(address owner) → uint256 maxShares external
Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault, through a redeem call.
-
MUST return a limited value if owner is subject to some withdrawal limit or timelock.
-
MUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock.
-
MUST NOT revert.
previewRedeem(uint256 shares) → uint256 assets external
Allows an on-chain or off-chain user to simulate the effects of their redemption at the current block, given current on-chain conditions.
-
MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call in the same transaction. I.e. redeem should return the same or more assets as previewRedeem if called in the same transaction.
-
MUST NOT account for redemption limits like those returned from maxRedeem and should always act as though the redemption would be accepted, regardless if the user has enough shares, etc.
-
MUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.
-
MUST NOT revert.
| any unfavorable discrepancy between convertToAssets and previewRedeem SHOULD be considered slippage in share price or some other type of condition, meaning the depositor will lose assets by redeeming. |
redeem(uint256 shares, address receiver, address owner) → uint256 assets external
Burns exactly shares from owner and sends assets of underlying tokens to receiver.
-
MUST emit the Withdraw event.
-
MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the redeem execution, and are accounted for during redeem.
-
MUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).
| some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately. |
IERC4906
import "@openzeppelin/contracts/interfaces/IERC4906.sol";
IERC5267
import "@openzeppelin/contracts/interfaces/IERC5267.sol";
IERC5313
import "@openzeppelin/contracts/interfaces/IERC5313.sol";
Interface for the Light Contract Ownership Standard.
A standardized minimal interface required to identify an account that controls a contract
IERC6372
import "@openzeppelin/contracts/interfaces/IERC6372.sol";
IERC6909
import "@openzeppelin/contracts/interfaces/IERC6909.sol";
Required interface of an ERC-6909 compliant contract, as defined in the ERC.
balanceOf(address owner, uint256 id) → uint256 external
Returns the amount of tokens of type id owned by owner.
allowance(address owner, address spender, uint256 id) → uint256 external
Returns the amount of tokens of type id that spender is allowed to spend on behalf of owner.
| Does not include operator allowances. |
isOperator(address owner, address spender) → bool external
Returns true if spender is set as an operator for owner.
approve(address spender, uint256 id, uint256 amount) → bool external
Sets an approval to spender for amount of tokens of type id from the caller’s tokens. An amount of
type(uint256).max signifies an unlimited approval.
Must return true.
setOperator(address spender, bool approved) → bool external
Grants or revokes unlimited transfer permission of any token id to spender for the caller’s tokens.
Must return true.
transfer(address receiver, uint256 id, uint256 amount) → bool external
Transfers amount of token type id from the caller’s account to receiver.
Must return true.
transferFrom(address sender, address receiver, uint256 id, uint256 amount) → bool external
Transfers amount of token type id from sender to receiver.
Must return true.
Approval(address indexed owner, address indexed spender, uint256 indexed id, uint256 amount) event
Emitted when the allowance of a spender for an owner is set for a token of type id.
The new allowance is amount.
IERC6909ContentURI
import "@openzeppelin/contracts/interfaces/IERC6909.sol";
Optional extension of IERC6909 that adds content URI functions.
IERC6909Metadata
import "@openzeppelin/contracts/interfaces/IERC6909.sol";
Optional extension of IERC6909 that adds metadata functions.
IERC6909TokenSupply
import "@openzeppelin/contracts/interfaces/IERC6909.sol";
Optional extension of IERC6909 that adds a token supply function.
IERC7674
import "@openzeppelin/contracts/interfaces/draft-IERC7674.sol";
Temporary Approval Extension for ERC-20 (ERC-7674)
IERC7751
import "@openzeppelin/contracts/interfaces/IERC7751.sol";
Wrapping of bubbled up reverts Interface of the ERC-7751 wrapping of bubbled up reverts.
IERC7786GatewaySource
import "@openzeppelin/contracts/interfaces/draft-IERC7786.sol";
Interface for ERC-7786 source gateways.
See ERC-7786 for more details
supportsAttribute(bytes4 selector) → bool external
Getter to check whether an attribute is supported or not.
sendMessage(bytes recipient, bytes payload, bytes[] attributes) → bytes32 sendId external
Endpoint for creating a new message. If the message requires further (gateway specific) processing before
it can be sent to the destination chain, then a non-zero sendId must be returned. Otherwise, the
message MUST be sent and this function must return 0.
-
MUST emit a
MessageSentevent.
If any of the attributes is not supported, this function SHOULD revert with an UnsupportedAttribute error.
Other errors SHOULD revert with errors not specified in ERC-7786.
MessageSent(bytes32 indexed sendId, bytes sender, bytes recipient, bytes payload, uint256 value, bytes[] attributes) event
Event emitted when a message is created. If sendId is zero, no further processing is necessary. If
sendId is not zero, then further (gateway specific, and non-standardized) action is required.
IERC7786Recipient
import "@openzeppelin/contracts/interfaces/draft-IERC7786.sol";
Interface for the ERC-7786 client contract (receiver).
See ERC-7786 for more details