Decentralised naming for wallets, websites, & more.
Buffer :
A library for working with mutable byte buffers in Solidity. Byte buffers are mutable and expandable, and provide a variety of primitives for appending to them. At any time you can fetch a bytes object containing the current contents of the buffer. The bytes object should not be stored between operations, as it may change due to resizing of the buffer.
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
IERC1271 :
Interface of the ERC1271 standard signature validation method for contracts as defined in https://eips.ethereum.org/EIPS/eip-1271[ERC-1271]. _Available since v4.1._
isValidSignature(bytes32,bytes) :
Should return whether the signature provided is valid for the provided data
IERC1155MetadataURI :
Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
uri(uint256) :
Returns the URI for token type `id`. If the `\{id\}` substring is present in the URI, it must be replaced by clients with the actual token type ID.
IERC1155 :
Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP]. _Available since v3.1._
ApprovalForAll(address,address,bool) :
Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to `approved`.
Emitted when `value` tokens of token type `id` are transferred from `from` to `to` by `operator`.
URI(string,uint256) :
Emitted when the URI for token type `id` changes to `value`, if it is a non-programmatic URI. If an {URI} event was emitted for `id`, the standard https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[guarantees] that `value` will equal the value returned by {IERC1155MetadataURI-uri}.
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. NOTE: To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector).
Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. NOTE: To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector).
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
ERC20 :
Implementation of the {IERC20} 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: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. 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}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. The default value of {decimals} is 18. To select a different value for {decimals} you should overload it. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless this function is overridden; NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
ERC721 :
Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
constructor :
Initializes the contract by setting a `name` and a `symbol` to the token collection.
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721Receiver.onERC721Received.selector`.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
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 https://eips.ethereum.org/EIPS/eip-1014#motivation[EIP] for more information.
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.
SignatureChecker :
Signature verification helper that can be used instead of `ECDSA.recover` to seamlessly support both ECDSA signatures from externally owned accounts (EOAs) as well as ERC1271 signatures from smart contract wallets like Argent and Gnosis Safe. _Available since v4.1._
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: ```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.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Math :
Standard math utilities missing in the Solidity language.
Strings :
String operations.
DNSRegistrar :
An ENS registrar that allows the owner of a DNS name to claim the corresponding name in ENS.
proveAndClaim(bytes,(bytes,bytes)[]) :
Submits proofs to the DNSSEC oracle, then claims a name using those proofs.
TLDPublicSuffixList :
A public suffix list that treats all TLDs as public suffixes.
Algorithm :
An interface for contracts implementing a DNSSEC (signing) algorithm.
verify(bytes,bytes,bytes) :
Verifies a signature.
DummyAlgorithm :
Implements a dummy DNSSEC (signing) algorithm that approves all signatures, for testing.
EllipticCurve :
NOTE: To disambiguate public keys when verifying signatures, activate condition 'rs[1] > lowSmax' in validateSignature().
RSASHA1Algorithm :
Implements the DNSSEC RSASHA1 algorithm.
RSASHA256Algorithm :
Implements the DNSSEC RSASHA256 algorithm.
Digest :
An interface for contracts implementing a DNSSEC digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
DummyDigest :
Implements a dummy DNSSEC digest that approves all hashes, for testing.
SHA1Digest :
Implements the DNSSEC SHA1 digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
SHA256Digest :
Implements the DNSSEC SHA256 digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
Owned :
Contract mixin for 'owned' contracts.
RRUtils :
RRUtils is a library that provides utilities for parsing DNS resource records.
ETHRegistrarAdmin :
Contract to act as the owner of the ETHRegistrar, permitting its owner to make certain changes with additional checks. This was implemented in response to a vulnerability disclosure that would permit the DAO to appoint a malicious controller that shortens the registration period of affected ENS names. This contract exists to prevent that from happening.
addController(address) :
Authorizes a controller proxy to register and renew names on the registrar.
deployControllerProxy(address) :
Deploys a controller proxy for the given controller, if one does not already exist. Anyone can call this function, but the proxy will only function if added by an authorized caller using `addController`.
getProxyAddress(address) :
Gets the address of the proxy contract for a given controller.
owner() :
Returns the address of the current owner.
removeController(address) :
Deauthorizes a controller proxy.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
setResolver(address) :
Sets the resolver for the TLD this registrar manages.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ETHRegistrarController :
A registrar controller for registering and renewing names at fixed cost.
owner() :
Returns the address of the current owner.
recoverFunds(address,address,uint256) :
The contract is Ownable and only the owner can call the recover function.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
SafeMath :
Unsigned math operations with safety checks that revert on error
TestResolver :
A test resolver implementation
DummyNameWrapper :
Implements a dummy NameWrapper which returns the caller's address
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
NameWrapperAdmin :
Contract to act as the owner of the NameWrapper, permitting its owner to make certain changes with additional checks. This was implemented in response to a vulnerability disclosure that would permit the DAO to appoint a malicious controller that shortens the registration period of affected ENS names. This contract exists to prevent that from happening.
addController(address) :
Authorizes a controller proxy to register and renew names on the wrapper.
deployControllerProxy(address) :
Deploys a controller proxy for the given controller, if one does not already exist. Anyone can call this function, but the proxy will only function if added by an authorized caller using `addController`.
getProxyAddress(address) :
Gets the address of the proxy contract for a given controller.
owner() :
Returns the address of the current owner.
removeController(address) :
Deauthorizes a controller proxy.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
setUpgradeContract(address) :
The default value of upgradeContract is the 0 address. Use the 0 address at any time to make the contract not upgradable.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
If your environment does not have compiler, you can access to the raw hardhat artifacts files at node_modules/@ensdomains/ens-contracts/artifacts/contracts/${modName}/${contractName}.sol/${contractName}.json
Contracts
Registry
The ENS registry is the core contract that lies at the heart of ENS resolution. All ENS lookups start by querying the registry. The registry maintains a list of domains, recording the owner, resolver, and TTL for each, and allows the owner of a domain to make changes to that data. It also includes some generic registrars.
ENS.sol
Interface of the ENS Registry.
ENSRegistry
Implementation of the ENS Registry, the central contract used to look up resolvers and owners for domains.
Implementation of a simple first-in-first-served registrar, which issues (sub-)domains to the first account to request them.
ReverseRegistrar
Implementation of the reverse registrar responsible for managing reverse resolution via the .addr.reverse special-purpose TLD.
TestRegistrar
Implementation of the .test registrar facilitates easy testing of ENS on the Ethereum test networks. Currently deployed on Ropsten network, it provides functionality to instantly claim a domain for test purposes, which expires 28 days after it was claimed.
EthRegistrar
Implements an ENS registrar intended for the .eth TLD.
These contracts were audited by ConsenSys Diligence; the audit report is available here.
BaseRegistrar
BaseRegistrar is the contract that owns the TLD in the ENS registry. This contract implements a minimal set of functionality:
The owner of the registrar may add and remove controllers.
Controllers may register new domains and extend the expiry of (renew) existing domains. They can not change the ownership or reduce the expiration time of existing domains.
Name owners may transfer ownership to another address.
Name owners may reclaim ownership in the ENS registry if they have lost it.
Owners of names in the interim registrar may transfer them to the new registrar, during the 1 year transition period. When they do so, their deposit is returned to them in its entirety.
This separation of concerns provides name owners strong guarantees over continued ownership of their existing names, while still permitting innovation and change in the way names are registered and renewed via the controller mechanism.
EthRegistrarController
EthRegistrarController is the first implementation of a registration controller for the new registrar. This contract implements the following functionality:
The owner of the registrar may set a price oracle contract, which determines the cost of registrations and renewals based on the name and the desired registration or renewal duration.
The owner of the registrar may withdraw any collected funds to their account.
Users can register new names using a commit/reveal process and by paying the appropriate registration fee.
Users can renew a name by paying the appropriate fee. Any user may renew a domain, not just the name's owner.
The commit/reveal process is used to avoid frontrunning, and operates as follows:
A user commits to a hash, the preimage of which contains the name to be registered and a secret value.
After a minimum delay period and before the commitment expires, the user calls the register function with the name to register and the secret value from the commitment. If a valid commitment is found and the other preconditions are met, the name is registered.
The minimum delay and expiry for commitments exist to prevent miners or other users from effectively frontrunning registrations.
SimplePriceOracle
SimplePriceOracle is a trivial implementation of the pricing oracle for the EthRegistrarController that always returns a fixed price per domain per year, determined by the contract owner.
StablePriceOracle
StablePriceOracle is a price oracle implementation that allows the contract owner to specify pricing based on the length of a name, and uses a fiat currency oracle to set a fixed price in fiat per name.
Resolvers
Resolver implements a general-purpose ENS resolver that is suitable for most standard ENS use cases. The public resolver permits updates to ENS records by the owner of the corresponding name.
PublicResolver includes the following profiles that implements different EIPs.
PubkeyResolver = EIP 619 - SECP256k1 public keys (pubkey()).
TextResolver = EIP 634 - Text records (text()).
DNSResolver = Experimental support is available for hosting DNS domains on the Ethereum blockchain via ENS. The more detail is on the old ENS doc.
Developer guide
Prettier pre-commit hook
This repo runs a husky precommit to prettify all contract files to keep them consistent. Add new folder/files to prettier format script in package.json. If you need to add other tasks to the pre-commit script, add them to .husky/pre-commit
How to setup
git clone https://github.com/ensdomains/ens-contracts
cd ens-contracts
yarn
How to run tests
yarn test
How to publish
yarn pub
Release flow
Create a feature branch from staging branch
Make code updates
Ensure you are synced up with staging
Code should now be in a state where you think it can be deployed to production
Create a "Release Candidate" release on GitHub. This will be of the form v1.2.3-RC0. This tagged commit is now subject to our bug bounty.
Have the tagged commit audited if necessary
If changes are required, make the changes and then once ready for review create another GitHub release with an incremented RC value v1.2.3-RC0 -> v.1.2.3-RC1. Repeat as necessary.
Deploy to testnet. Open a pull request to merge the deploy artifacts into
the feature branch. Get someone to review and approve the deployment and then merge. You now MUST merge this branch into staging branch.
Create GitHub release of the form v1.2.3-testnet from the commit that has the new deployment artifacts.
If any further changes are needed, you can either make them on the existing feature branch that is in sync or create a new branch, and follow steps 1 -> 9. Repeat as necessary.
Make Deployment to mainnet from staging. Commit build artifacts. You now MUST merge this branch into main.
Create GitHub release of the form v1.2.3-mainnet from the commit that has the new deployment artifacts.
Emergency release process
Branch from main, make fixes, deploy to testnet (can skip), deploy to mainnet
Merge changes back into main and staging immediately after deploy
Create GitHub releases, if you didn't deploy to testnet in step 1, do it now
Notes
staging branch and main branch should start off in sync
staging is intended to be a practice main. Only code that is intended to be released to main can be merged to staging. Consequently:
Feature branches will be long-lived
Feature branches must be kept in sync with staging
Audits are conducted on feature branches
All code that is on staging and main should be deployed to testnet and mainnet respectively i.e. these branches should not have any undeployed code
It is preferable to not edit the same file on different feature branches.
Code on staging and main will always be a subset of what is deployed, as smart contracts cannot be undeployed.
Release candidates, staging and main branch are subject to our bug bounty
Releases follow semantic versioning and should contain a description of changes with developers being the intended audience
Decentralised naming for wallets, websites, & more.
Buffer :
A library for working with mutable byte buffers in Solidity. Byte buffers are mutable and expandable, and provide a variety of primitives for appending to them. At any time you can fetch a bytes object containing the current contents of the buffer. The bytes object should not be stored between operations, as it may change due to resizing of the buffer.
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
IERC1271 :
Interface of the ERC1271 standard signature validation method for contracts as defined in https://eips.ethereum.org/EIPS/eip-1271[ERC-1271]. _Available since v4.1._
isValidSignature(bytes32,bytes) :
Should return whether the signature provided is valid for the provided data
IERC1155MetadataURI :
Interface of the optional ERC1155MetadataExtension interface, as defined in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP]. _Available since v3.1._
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
uri(uint256) :
Returns the URI for token type `id`. If the `\{id\}` substring is present in the URI, it must be replaced by clients with the actual token type ID.
IERC1155 :
Required interface of an ERC1155 compliant contract, as defined in the https://eips.ethereum.org/EIPS/eip-1155[EIP]. _Available since v3.1._
ApprovalForAll(address,address,bool) :
Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to `approved`.
Emitted when `value` tokens of token type `id` are transferred from `from` to `to` by `operator`.
URI(string,uint256) :
Emitted when the URI for token type `id` changes to `value`, if it is a non-programmatic URI. If an {URI} event was emitted for `id`, the standard https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[guarantees] that `value` will equal the value returned by {IERC1155MetadataURI-uri}.
balanceOf(address,uint256) :
Returns the amount of tokens of token type `id` owned by `account`. Requirements: - `account` cannot be the zero address.
balanceOfBatch(address[],uint256[]) :
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {balanceOf}. Requirements: - `accounts` and `ids` must have the same length.
isApprovedForAll(address,address) :
Returns true if `operator` is approved to transfer ``account``'s tokens. See {setApprovalForAll}.
xref:ROOT:erc1155.adoc#batch-operations[Batched] version of {safeTransferFrom}. Emits a {TransferBatch} event. Requirements: - `ids` and `amounts` must have the same length. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155BatchReceived} and return the acceptance magic value.
Transfers `amount` tokens of token type `id` from `from` to `to`. Emits a {TransferSingle} event. Requirements: - `to` cannot be the zero address. - If the caller is not `from`, it must have been approved to spend ``from``'s tokens via {setApprovalForAll}. - `from` must have a balance of tokens of type `id` of at least `amount`. - If `to` refers to a smart contract, it must implement {IERC1155Receiver-onERC1155Received} and return the acceptance magic value.
setApprovalForAll(address,bool) :
Grants or revokes permission to `operator` to transfer the caller's tokens, according to `approved`, Emits an {ApprovalForAll} event. Requirements: - `operator` cannot be the caller.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Handles the receipt of a multiple ERC1155 token types. This function is called at the end of a `safeBatchTransferFrom` after the balances have been updated. NOTE: To accept the transfer(s), this must return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81, or its own function selector).
Handles the receipt of a single ERC1155 token type. This function is called at the end of a `safeTransferFrom` after the balance has been updated. NOTE: To accept the transfer, this must return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61, or its own function selector).
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
ERC20 :
Implementation of the {IERC20} 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: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. 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}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. The default value of {decimals} is 18. To select a different value for {decimals} you should overload it. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the value {ERC20} uses, unless this function is overridden; NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
ERC721 :
Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
constructor :
Initializes the contract by setting a `name` and a `symbol` to the token collection.
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721Receiver.onERC721Received.selector`.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
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 https://eips.ethereum.org/EIPS/eip-1014#motivation[EIP] for more information.
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.
SignatureChecker :
Signature verification helper that can be used instead of `ECDSA.recover` to seamlessly support both ECDSA signatures from externally owned accounts (EOAs) as well as ERC1271 signatures from smart contract wallets like Argent and Gnosis Safe. _Available since v4.1._
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: ```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.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Math :
Standard math utilities missing in the Solidity language.
Strings :
String operations.
DNSRegistrar :
An ENS registrar that allows the owner of a DNS name to claim the corresponding name in ENS.
proveAndClaim(bytes,(bytes,bytes)[]) :
Submits proofs to the DNSSEC oracle, then claims a name using those proofs.
TLDPublicSuffixList :
A public suffix list that treats all TLDs as public suffixes.
Algorithm :
An interface for contracts implementing a DNSSEC (signing) algorithm.
verify(bytes,bytes,bytes) :
Verifies a signature.
DummyAlgorithm :
Implements a dummy DNSSEC (signing) algorithm that approves all signatures, for testing.
EllipticCurve :
NOTE: To disambiguate public keys when verifying signatures, activate condition 'rs[1] > lowSmax' in validateSignature().
RSASHA1Algorithm :
Implements the DNSSEC RSASHA1 algorithm.
RSASHA256Algorithm :
Implements the DNSSEC RSASHA256 algorithm.
Digest :
An interface for contracts implementing a DNSSEC digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
DummyDigest :
Implements a dummy DNSSEC digest that approves all hashes, for testing.
SHA1Digest :
Implements the DNSSEC SHA1 digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
SHA256Digest :
Implements the DNSSEC SHA256 digest.
verify(bytes,bytes) :
Verifies a cryptographic hash.
Owned :
Contract mixin for 'owned' contracts.
RRUtils :
RRUtils is a library that provides utilities for parsing DNS resource records.
ETHRegistrarAdmin :
Contract to act as the owner of the ETHRegistrar, permitting its owner to make certain changes with additional checks. This was implemented in response to a vulnerability disclosure that would permit the DAO to appoint a malicious controller that shortens the registration period of affected ENS names. This contract exists to prevent that from happening.
addController(address) :
Authorizes a controller proxy to register and renew names on the registrar.
deployControllerProxy(address) :
Deploys a controller proxy for the given controller, if one does not already exist. Anyone can call this function, but the proxy will only function if added by an authorized caller using `addController`.
getProxyAddress(address) :
Gets the address of the proxy contract for a given controller.
owner() :
Returns the address of the current owner.
removeController(address) :
Deauthorizes a controller proxy.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
setResolver(address) :
Sets the resolver for the TLD this registrar manages.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ETHRegistrarController :
A registrar controller for registering and renewing names at fixed cost.
owner() :
Returns the address of the current owner.
recoverFunds(address,address,uint256) :
The contract is Ownable and only the owner can call the recover function.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
SafeMath :
Unsigned math operations with safety checks that revert on error
TestResolver :
A test resolver implementation
DummyNameWrapper :
Implements a dummy NameWrapper which returns the caller's address
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
NameWrapperAdmin :
Contract to act as the owner of the NameWrapper, permitting its owner to make certain changes with additional checks. This was implemented in response to a vulnerability disclosure that would permit the DAO to appoint a malicious controller that shortens the registration period of affected ENS names. This contract exists to prevent that from happening.
addController(address) :
Authorizes a controller proxy to register and renew names on the wrapper.
deployControllerProxy(address) :
Deploys a controller proxy for the given controller, if one does not already exist. Anyone can call this function, but the proxy will only function if added by an authorized caller using `addController`.
getProxyAddress(address) :
Gets the address of the proxy contract for a given controller.
owner() :
Returns the address of the current owner.
removeController(address) :
Deauthorizes a controller proxy.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
setUpgradeContract(address) :
The default value of upgradeContract is the 0 address. Use the 0 address at any time to make the contract not upgradable.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Ethereum Name Service
