Request form
Frax
  • Stablecoin
  • Lending
  • DEX
  • Algo-Stables
  • Protocol
  • Audited
Docs
Source
ChefGPT

Inventors of the fractional stablecoin. $FRAX is the 1st stablecoin with parts backed & parts algorithmic

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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three 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 {_setupDecimals} is called. 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: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
ERC20Custom :
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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
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.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
Chainlink :
Uses imported CBOR library for encoding to buffer
BufferChainlink :
A library for working with mutable byte buffers in Solidity. Byte buffers are mutable and expandable, and provide a variety of primitives for writing 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.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
IAccessControl :
External interface of AccessControl declared to support ERC165 detection.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {AccessControl-_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
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. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three 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 {_setupDecimals} is called. 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: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
ERC20Burnable :
Extension of {ERC20} that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognized off-chain (via event analysis).
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}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for ``accounts``'s tokens of at least `amount`.
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 default value returned by this function, unless it's 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`.
ERC20Permit :
Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all. _Available since v3.4._
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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 :
Initializes the {EIP712} domain separator using the `name` parameter, and setting `version` to `"1"`. It's a good idea to use the same `name` that is defined as the ERC20 token name.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
IERC721Enumerable :
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}
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.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
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.
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.
Counters :
Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids. Include with `using Counters for Counters.Counter;`
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.
EIP712 :
https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data. The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`. This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}). The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain. NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask]. NOTE: In the upgradeable version of this contract, the cached values will correspond to the address, and the domain separator of the implementation contract. This will cause the `_domainSeparatorV4` function to always rebuild the separator from the immutable values, which is cheaper than accessing a cached version in cold storage. _Available since v3.4._
constructor :
Initializes the domain separator and parameter caches. The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]: - `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol. - `version`: the current major version of the signing domain. NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade].
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
SafeCast :
Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting.
SignedMath :
Standard signed math utilities missing in the Solidity language.
ShortStrings :
This library provides functions to convert short memory strings into a `ShortString` type that can be used as an immutable variable. Strings of arbitrary length can be optimized using this library if they are short enough (up to 31 bytes) by packing them with their length (1 byte) in a single EVM word (32 bytes). Additionally, a fallback mechanism can be used for every other case. Usage example: ```solidity contract Named { using ShortStrings for *; ShortString private immutable _name; string private _nameFallback; constructor(string memory contractName) { _name = contractName.toShortStringWithFallback(_nameFallback); } function name() external view returns (string memory) { return _name.toStringWithFallback(_nameFallback); } } ```
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
Strings :
String operations.
IUniswapV3Pool :
The pool interface is broken up into many smaller pieces
burn(int24,int24,uint128) :
Can be used to trigger a recalculation of fees owed to a position by calling with an amount of 0Fees must be collected separately via a call to #collect
collect(address,int24,int24,uint128,uint128) :
Does not recompute fees earned, which must be done either via mint or burn of any amount of liquidity. Collect must be called by the position owner. To withdraw only token0 or only token1, amount0Requested or amount1Requested may be set to zero. To withdraw all tokens owed, caller may pass any value greater than the actual tokens owed, e.g. type(uint128).max. Tokens owed may be from accumulated swap fees or burned liquidity.
feeGrowthGlobal0X128() :
This value can overflow the uint256
feeGrowthGlobal1X128() :
This value can overflow the uint256
flash(address,uint256,uint256,bytes) :
The caller of this method receives a callback in the form of IUniswapV3FlashCallback#uniswapV3FlashCallbackCan be used to donate underlying tokens pro-rata to currently in-range liquidity providers by calling with 0 amount{0,1} and sending the donation amount(s) from the callback
increaseObservationCardinalityNext(uint16) :
This method is no-op if the pool already has an observationCardinalityNext greater than or equal to the input observationCardinalityNext.
initialize(uint160) :
Price is represented as a sqrt(amountToken1/amountToken0) Q64.96 value
liquidity() :
This value has no relationship to the total liquidity across all ticks
maxLiquidityPerTick() :
This parameter is enforced per tick to prevent liquidity from overflowing a uint128 at any point, and also prevents out-of-range liquidity from being used to prevent adding in-range liquidity to a pool
mint(address,int24,int24,uint128,bytes) :
The caller of this method receives a callback in the form of IUniswapV3MintCallback#uniswapV3MintCallback in which they must pay any token0 or token1 owed for the liquidity. The amount of token0/token1 due depends on tickLower, tickUpper, the amount of liquidity, and the current price.
observations(uint256) :
You most likely want to use #observe() instead of this method to get an observation as of some amount of time ago, rather than at a specific index in the array.
observe(uint32[]) :
To get a time weighted average tick or liquidity-in-range, you must call this with two values, one representing the beginning of the period and another for the end of the period. E.g., to get the last hour time-weighted average tick, you must call it with secondsAgos = [3600, 0].The time weighted average tick represents the geometric time weighted average price of the pool, in log base sqrt(1.0001) of token1 / token0. The TickMath library can be used to go from a tick value to a ratio.
protocolFees() :
Protocol fees will never exceed uint128 max in either token
snapshotCumulativesInside(int24,int24) :
Snapshots must only be compared to other snapshots, taken over a period for which a position existed. I.e., snapshots cannot be compared if a position is not held for the entire period between when the first snapshot is taken and the second snapshot is taken.
swap(address,bool,int256,uint160,bytes) :
The caller of this method receives a callback in the form of IUniswapV3SwapCallback#uniswapV3SwapCallback
tickSpacing() :
Ticks can only be used at multiples of this value, minimum of 1 and always positive e.g.: a tickSpacing of 3 means ticks can be initialized every 3rd tick, i.e., ..., -6, -3, 0, 3, 6, ... This value is an int24 to avoid casting even though it is always positive.
SafeCast :
Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting.
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. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
FraxFamilialPitchGauge :
To use this: - Add to GaugeController as a gauge - Add to FXS Rewards Distributor as a gauge * BUT do not set as a middleman gauge on the FXS Rewards Distributor - Set as the `gaugeController` & `rewardsDistributor` on all children FraxFarms - Disable rewards for pre-existing gauges on the FXS Rewards Distributor
gauge_relative_weight_write(address,uint256) :
Note: unfortunately many of the steps in this process need to be done after completing previous step for all children
veFPISProxy :
Is given special permissions in veFPIS.vy to transfer FPIS to itself and whitelisted apps, and also to slash / lock additional FPIS for a userUsers cannot withdraw their veFPIS while they have a balance in the proxy
appAdd(address,uint256) :
App must first approve the veFPIS contract to spend the surplus amount of FPIS to payback
transferFromAppToVeFPIS(address,uint256) :
App must first approve the veFPIS contract to spend the amount of FPIS to payback
userSlash(address,uint256) :
useful in the case of a bug in the app which would otherwise prevent user from withdrawing from veFPIS
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.
Counters :
Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids. Include with `using Counters for Counters.Counter;`
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.
EIP712 :
https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data. The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`. This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}). The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain. NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask]. NOTE: In the upgradeable version of this contract, the cached values will correspond to the address, and the domain separator of the implementation contract. This will cause the `_domainSeparatorV4` function to always rebuild the separator from the immutable values, which is cheaper than accessing a cached version in cold storage. _Available since v3.4._
constructor :
Initializes the domain separator and parameter caches. The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]: - `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol. - `version`: the current major version of the signing domain. NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade].
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
ERC20Permit :
Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all. _Available since v3.4._
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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 :
Initializes the {EIP712} domain separator using the `name` parameter, and setting `version` to `"1"`. It's a good idea to use the same `name` that is defined as the ERC20 token name.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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`.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
ERC20PermitPermissionedMint :
ERC20PermitPermissionedMint adheres to EIP-712/EIP-2612 and can use permits
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for ``accounts``'s tokens of at least `amount`.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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`.
ERC20Virtual :
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.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. 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: - `recipient` 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}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
IERC20_Detailed :
Interface of the ERC20 standard as defined in the EIP. Does not include the optional functions; to access them see {ERC20Detailed}.
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 `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `sender` to `recipient` 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.
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.
ERC721 :
see https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
baseURI() :
Returns the base URI set via {_setBaseURI}. This will be automatically added as a prefix in {tokenURI} to each token's URI, or to the token ID if no specific URI is set for that token ID.
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}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
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.
IERC721Enumerable :
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}
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.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
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.
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.
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 `IERC721.onERC721Received.selector`.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
EnumerableMap :
Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type. Maps have the following properties: - Entries are added, removed, and checked for existence in constant time (O(1)). - Entries are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap; // Declare a set state variable EnumerableMap.UintToAddressMap private myMap; } ``` As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
Strings :
String operations.
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
FraxswapRouterMultihop :
Router for swapping across the majority of the FRAX liquidity
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
TokenVesting :
A token holder contract that can release its token balance gradually like a typical vesting scheme, with a cliff and vesting period. Optionally revocable by the owner. Modified from OpenZeppelin's TokenVesting.sol draft
constructor :
Creates a vesting contract that vests its balance of any ERC20 token to the beneficiary, gradually in a linear fashion until start + duration. By then all of the balance will have vested.
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
SignedSafeMath :
Wrappers over Solidity's arithmetic operations. NOTE: `SignedSafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking.
KyberFullMath :
Handles "phantom overflow" i.e., allows multiplication and division where an intermediate value overflows 256 bitsCode has been modified to be compatible with sol 0.8
ILendingPoolAddressesProvider :
Main registry of addresses part of or connected to the protocol, including permissioned roles - Acting also as factory of proxies and admin of those, so with right to change its implementations - Owned by the Aave Governance
ERC1967Proxy :
This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the implementation behind the proxy.
constructor :
Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializating the storage of the proxy like a Solidity constructor.
ERC1967Storage :
This abstract contract provides setters and getters for the different https://eips.ethereum.org/EIPS/eip-1967[EIP1967] storage slots. _Available since v4.1._
ERC1967Upgrade :
This abstract contract provides event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. _Available since v4.1._
AdminChanged(address,address) :
Emitted when the admin account has changed.
BeaconUpgraded(address) :
Emitted when the beacon is upgraded.
Upgraded(address) :
Emitted when the implementation is upgraded.
IBeacon :
This is the interface that {BeaconProxy} expects of its beacon.
implementation() :
Must return an address that can be used as a delegate call target. {BeaconProxy} will check that this address is a contract.
Initializable :
This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect. TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}. CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity.
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
IUniswapV3Pool :
The pool interface is broken up into many smaller pieces
burn(int24,int24,uint128) :
Can be used to trigger a recalculation of fees owed to a position by calling with an amount of 0Fees must be collected separately via a call to #collect
collect(address,int24,int24,uint128,uint128) :
Does not recompute fees earned, which must be done either via mint or burn of any amount of liquidity. Collect must be called by the position owner. To withdraw only token0 or only token1, amount0Requested or amount1Requested may be set to zero. To withdraw all tokens owed, caller may pass any value greater than the actual tokens owed, e.g. type(uint128).max. Tokens owed may be from accumulated swap fees or burned liquidity.
feeGrowthGlobal0X128() :
This value can overflow the uint256
feeGrowthGlobal1X128() :
This value can overflow the uint256
flash(address,uint256,uint256,bytes) :
The caller of this method receives a callback in the form of IUniswapV3FlashCallback#uniswapV3FlashCallbackCan be used to donate underlying tokens pro-rata to currently in-range liquidity providers by calling with 0 amount{0,1} and sending the donation amount(s) from the callback
increaseObservationCardinalityNext(uint16) :
This method is no-op if the pool already has an observationCardinalityNext greater than or equal to the input observationCardinalityNext.
initialize(uint160) :
Price is represented as a sqrt(amountToken1/amountToken0) Q64.96 value
liquidity() :
This value has no relationship to the total liquidity across all ticks
maxLiquidityPerTick() :
This parameter is enforced per tick to prevent liquidity from overflowing a uint128 at any point, and also prevents out-of-range liquidity from being used to prevent adding in-range liquidity to a pool
mint(address,int24,int24,uint128,bytes) :
The caller of this method receives a callback in the form of IUniswapV3MintCallback#uniswapV3MintCallback in which they must pay any token0 or token1 owed for the liquidity. The amount of token0/token1 due depends on tickLower, tickUpper, the amount of liquidity, and the current price.
observations(uint256) :
You most likely want to use #observe() instead of this method to get an observation as of some amount of time ago, rather than at a specific index in the array.
observe(uint32[]) :
To get a time weighted average tick or liquidity-in-range, you must call this with two values, one representing the beginning of the period and another for the end of the period. E.g., to get the last hour time-weighted average tick, you must call it with secondsAgos = [3600, 0].The time weighted average tick represents the geometric time weighted average price of the pool, in log base sqrt(1.0001) of token1 / token0. The TickMath library can be used to go from a tick value to a ratio.
protocolFees() :
Protocol fees will never exceed uint128 max in either token
snapshotCumulativesInside(int24,int24) :
Snapshots must only be compared to other snapshots, taken over a period for which a position existed. I.e., snapshots cannot be compared if a position is not held for the entire period between when the first snapshot is taken and the second snapshot is taken.
swap(address,bool,int256,uint160,bytes) :
The caller of this method receives a callback in the form of IUniswapV3SwapCallback#uniswapV3SwapCallback
tickSpacing() :
Ticks can only be used at multiples of this value, minimum of 1 and always positive e.g.: a tickSpacing of 3 means ticks can be initialized every 3rd tick, i.e., ..., -6, -3, 0, 3, 6, ... This value is an int24 to avoid casting even though it is always positive.
IUniswapV3PoolDeployer :
This is used to avoid having constructor arguments in the pool contract, which results in the init code hash of the pool being constant allowing the CREATE2 address of the pool to be cheaply computed on-chain
parameters() :
Called by the pool constructor to fetch the parameters of the pool Returns factory The factory address Returns token0 The first token of the pool by address sort order Returns token1 The second token of the pool by address sort order Returns fee The fee collected upon every swap in the pool, denominated in hundredths of a bip Returns tickSpacing The minimum number of ticks between initialized ticks
FixedPoint96 :
Used in SqrtPriceMath.sol
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
Address_8 :
Collection of functions related to the address type
Multicall_Oz :
Provides a function to batch together multiple calls in a single external call. _Available since v4.1._
multicall(address,bytes[]) :
Receives and executes a batch of function calls on the target contract.
multicallMany(address[],bytes[]) :
Receives and executes a batch of function calls on the target contract(s).
multicallThis(bytes[]) :
Receives and executes a batch of function calls on this contract.
ReentrancyGuardV2 :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
FRAX3CRV_Curve_FXS_Distributor.sol
Context.sol
ERC20.sol
ERC20Custom.sol
IERC20.sol
Frax.sol
FraxPool.sol
FraxPoolLibrary.sol
FXS.sol
AccessControl.sol
Governance.sol
Babylonian.sol
FixedPoint.sol
SafeMath.sol
AggregatorV3Interface.sol
ChainlinkETHUSDPriceConsumer.sol
UniswapPairOracle.sol
Owned.sol
IUniswapV2Factory.sol
IUniswapV2Pair.sol
TransferHelper.sol
UniswapV2Library.sol
UniswapV2OracleLibrary.sol
Address.sol
EnumerableSet.sol
SigRelayer2.sol
AddressAliasHelper.sol
Chainlink.sol
ChainlinkClient.sol
AggregatorV3Interface.sol
ChainlinkRequestInterface.sol
ENSInterface.sol
LinkTokenInterface.sol
OperatorInterface.sol
OracleInterface.sol
PointerInterface.sol
BufferChainlink.sol
CBORChainlink.sol
ENSResolver.sol
AccessControl.sol
IAccessControl.sol
Ownable.sol
IERC5267.sol
Pausable.sol
ReentrancyGuard.sol
ERC20.sol
draft-ERC20Permit.sol
draft-IERC20Permit.sol
ERC20Burnable.sol
ERC20Permit.sol
IERC20Metadata.sol
IERC20Permit.sol
IERC20.sol
SafeERC20.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721.sol
Address.sol
Context.sol
Counters.sol
ECDSA.sol
EIP712.sol
ERC165.sol
IERC165.sol
Math.sol
SafeCast.sol
SignedMath.sol
ShortStrings.sol
StorageSlot.sol
Strings.sol
IUniswapV2Callee.sol
IUniswapV2Pair.sol
IWETH.sol
IUniswapV3SwapCallback.sol
IUniswapV3Pool.sol
IUniswapV3PoolActions.sol
IUniswapV3PoolDerivedState.sol
IUniswapV3PoolEvents.sol
IUniswapV3PoolImmutables.sol
IUniswapV3PoolOwnerActions.sol
IUniswapV3PoolState.sol
SafeCast.sol
TransferHelper.sol
Babylonian.sol
BAMM.sol
BAMMHelper.sol
FixedPoint.sol
FraxswapDummyRouter.sol
FraxswapOracle.sol
CrossChainBridgeBacker_ARBI_AnySwap.sol
FraxLiquidityBridger_ARBI_AnySwap.sol
IL1CustomGateway.sol
IL2GatewayRouter.sol
CrossChainBridgeBacker.sol
FraxLiquidityBridger.sol
ContextV2.sol
Ownable.sol
CurveInterfaces.sol
CurveVoterProxy.sol
FraxCrossChainRewarder.sol
FraxFamilialPitchGauge.sol
FraxGaugeFXSRewardsDistributor.sol
FraxMiddlemanGauge.sol
FraxMiddlemanGaugeFerryHelper.sol
FraxMiddlemanGaugeV2.sol
ICurvefrxETHETHPool.sol
IDelegationProxy.sol
IFraxGaugeController.sol
IFraxGaugeControllerV2.sol
IFraxGaugeFXSRewardsDistributor.sol
ILiquidityGaugeV2.sol
IMetaImplementationUSD.sol
IMinter.sol
IStableSwap3Pool.sol
IveFPIS.sol
IveFXS.sol
IVotingEscrowDelegation.sol
FraxMiddlemanGauge_ARBI_Curve_VSTFRAX.sol
FraxMiddlemanGauge_FRAX_mUSD.sol
NoopRewardsDistributor.sol
SmartWalletWhitelist.sol
veFPISProxy.sol
ERC165.sol
IERC165.sol
anyFRAX.sol
anyFXS.sol
AnyswapV4ERC20.sol
AnyswapV5ERC20.sol
anyUSDC.sol
arbiUSDC.sol
celrFRAX.sol
celrFXS.sol
CrossChainCanonical.sol
CrossChainCanonicalFRAX.sol
CrossChainCanonicalFXS.sol
CrossChainCanonicalV2.sol
IanyFRAX.sol
IanyFXS.sol
IAnyswapV4ERC20.sol
IAnyswapV5ERC20.sol
IArbFiatToken.sol
IChildChainManager.sol
ICrossChainCanonical.sol
IUChildAdministrableERC20.sol
IUChildERC20.sol
oneFRAX.sol
oneFXS.sol
oneUSDC.sol
polyFRAX.sol
polyFXS.sol
polyUSDC.sol
DeflatingERC20.sol
ERC20Mock.sol
ERC20MockTWAMM.sol
ERC20PermissionedMint.sol
Counters.sol
ECDSA.sol
EIP712.sol
ERC20Permit.sol
IERC20Permit.sol
ERC20PermitPermissionedMint.sol
ERC20Virtual.sol
IERC20_Detailed.sol
IERC20Metadata.sol
IERC20V2.sol
IWETH.sol
SafeERC20.sol
Comp.sol
FarmToken.sol
FRAX3CRV_V2_Mock.sol
IQToken.sol
ERC721.sol
IERC721.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721Receiver.sol
Context.sol
AccessControl.sol
SafeMath.sol
Address.sol
EnumerableMap.sol
EnumerableSet.sol
Strings.sol
ABDKMath64x64.sol
FPI.sol
FPIControllerPool.sol
FPIS.sol
FPIStaking.sol
FPIStaking2.sol
IERC20.sol
IFPI.sol
Math.sol
PermissionedSend.sol
SafeMath.sol
StakedFPI.sol
FraxAMOMinter.sol
FraxAMOMinterLayer2.sol
FraxBridge.sol
IFrax.sol
IFraxAMOMinter.sol
IFraxAMOMinterOld.sol
FraxPoolV3.sol
FraxPoolvAMM.sol
IFraxPool.sol
Pool_USDC.sol
PoolvAMM_USDC.sol
TestDriftingReserves.sol
Fraxauction.sol
FraxFPIBond.sol
FraxFPIBondYield.sol
FXB.sol
IFPIControllerPool.sol
SlippageAuction.sol
FrxETHMiniRouter.sol
IfrxETH.sol
IfrxETHMinter.sol
IsfrxETH.sol
DummyToken.sol
Fraxferry.sol
IFraxferry.sol
FerryOnL1.sol
FerryOnL2.sol
IFraxlendAMO.sol
IFraxlendAMOV3.sol
IFraxlendPair.sol
IFraxlendPairHelper.sol
DummyPriceOracle.sol
DummyStateRootOracle.sol
Fraxoracle.sol
FraxoraclePriceSource.sol
IBlockhashProvider.sol
IInbox.sol
IMessageProvider.sol
IPriceOracle.sol
IStateRootOracle.sol
ITelepathyRouter.sol
MerklePatriciaProofVerifier.sol
MerkleTreeProver.sol
RLPReader.sol
StateProofVerifier.sol
MerkleProofPriceSource.sol
ArbitrumBlockhashProvider.sol
ArbitrumBlockhashRelay.sol
OperatorBlockhashProvider.sol
TelepathyBlockhashProvider.sol
TelepathyBlockhashRelay.sol
StateProver.sol
StateRootOracle.sol
FraxswapERC20.sol
FraxswapFactory.sol
FraxswapPair.sol
GlobalPauseHelper.sol
IERC20V5.sol
IFraxswapFactory.sol
IFraxswapPair.sol
IUniswapV2CalleeV5.sol
IUniswapV2ERC20V5.sol
IUniswapV2FactoryV5.sol
IUniswapV2PairPartialV5.sol
IUniswapV2PairV5.sol
Math.sol
SafeMath.sol
UQ112x112.sol
ComputeUniswapV2PairInitHash.sol
ERC20CoreTest.sol
ILiquidityModifier.sol
AddressStringUtil.sol
Babylonian.sol
BitMath.sol
FixedPoint.sol
FullMath.sol
SafeERC20Namer.sol
TransferHelper.sol
ExampleComputeLiquidityValue.sol
ExampleFlashSwap.sol
ExampleOracleSimple.sol
ExampleSlidingWindowOracle.sol
ExampleSwapToPrice.sol
FraxswapRouter.sol
FraxswapRouterMultihop.sol
IERC20.sol
IFraxswapRouterMultihop.sol
IUniswapV2MigratorV5.sol
IUniswapV2Router01V5.sol
IUniswapV2Router02V5.sol
IWETH.sol
IUniswapV1Exchange.sol
IUniswapV1Factory.sol
FraxswapRouterLibrary.sol
SafeMath.sol
UniswapV2LiquidityMathLibrary.sol
UniswapV2LiquidityMathLibraryMini.sol
UniswapV2OracleLibrary.sol
DeflatingERC20.sol
ERC20PeriTest.sol
RouterEventEmitter.sol
WETH9.sol
LongTermOrders.sol
FXB.sol
FXBFactory.sol
FXBMintRedeemerAMO.sol
IFxs.sol
TokenVesting.sol
Timelock.sol
IERC20.sol
TestERC20.sol
AddressStringUtil.sol
BitMath.sol
BokkyPooBahsDateTimeContract.sol
BokkyPooBahsDateTimeLibrary.sol
FullMath.sol
HomoraMath.sol
MagnitudesAndPowers.sol
Math.sol
MathV2.sol
SafeDecimalMath.sol
SafeERC20Namer.sol
SafeMathV2.sol
SignedSafeMath.sol
UQ112x112.sol
CurveAMO_ARBI.sol
SushiSwapLiquidityAMO_ARBI.sol
IBBROARMasterchef.sol
IROARMasterchef.sol
IApePair.sol
IApeRouter.sol
IMasterApe.sol
IAxialToken.sol
IMasterChefAxialV3.sol
ISwapFlashLoan.sol
IBalancerChildLiquidityGauge.sol
IBalancerVault.sol
IL2BalancerPseudoMinter.sol
IStablePool.sol
IBalancerOracle.sol
IBunniGauge.sol
IBunniLens.sol
IBunniMinter.sol
IBunniTokenLP.sol
IOptionsToken.sol
IComptroller.sol
IcUSDC_Partial.sol
Convex_AMO_V2.sol
IConvexBaseRewardPool.sol
IConvexBooster.sol
IConvexClaimZap.sol
IConvexStakingWrapperFrax.sol
IConvexStakingWrapperFraxWithEarned.sol
ICvxLocker.sol
ICvxLockerV2.sol
IcvxRewardPool.sol
IDepositToken.sol
IStakingProxyConvex.sol
IVirtualBalanceRewardPool.sol
I2pool.sol
I2PoolcvxCRVCRV.sol
I2poolGaugeDeposit.sol
I2poolNoLending.sol
I2poolToken.sol
I3pool.sol
I3poolGaugeDeposit.sol
I3poolToken.sol
IFRAX2pool.sol
IFRAX3pool.sol
IZapDepositor2pool.sol
IZapDepositor3pool.sol
IMasterPlatypusV3.sol
FXS1559_AMO_V3.sol
IGUniPool.sol
ICErc20DelegatorOld.sol
IAMO.sol
IConvexAMO_Old.sol
ICrossChainAMO.sol
IKSElasticLMV2.sol
IKSReinvestmentTokenPool.sol
IKyberSwapFarmingToken.sol
IKyberFactory.sol
KyberTickMath.sol
IKyberPool.sol
IPoolActions.sol
IPoolEvents.sol
IPoolStorage.sol
IAntiSnipAttackPositionManager.sol
ITickFeesReader.sol
KyberFullMath.sol
KyberLiquidityMath.sol
KyberMathConstants.sol
KyberSafeCast.sol
IRouter.sol
ISwapCallback.sol
IAAVE_aFRAX.sol
IAAVE_aUSDC_Partial.sol
IAaveIncentivesControllerPartial.sol
IAAVELendingPool_Partial.sol
IAToken.sol
ILendingPool.sol
ILendingPoolAddressesProvider.sol
IProtocolDataProvider.sol
IScaledBalanceToken.sol
IStakedAave.sol
AaveAMO_V2.sol
AaveAMO.sol
IFraxLendPair_Partial.sol
IFraxLendPairDeployer_Partial.sol
FraxLendAMO.sol
IBentoBoxV1.sol
IKashiPairMediumRiskV1.sol
IOracle.sol
KashiAMO.sol
ICErc20Delegator.sol
IRariComptroller.sol
RariFuseLendingAMO_V2.sol
RariFuseLendingAMO_V3.sol
IManagedPortfolio.sol
IManagedPortfolioFactory.sol
IPoolFactory.sol
IStkTruToken.sol
ITrueFiPool2.sol
ITrueMultiFarm.sol
TruefiAMO 2.sol
TruefiAMO.sol
ManualTokenTrackerAMO.sol
MSIGHelper.sol
IFeederPool.sol
IL1StandardBridge.sol
IL2StandardBridge.sol
IAsset.sol
IMasterPlatypusV4.sol
IVoter.sol
IRootChainManager.sol
IChildLiquidityGauge.sol
IChildLiquidityGaugeFactory.sol
IGaugeMinter.sol
IPoolRegistry.sol
IRootGauge.sol
ISaddleD4_LP.sol
ISaddleLPToken.sol
ISaddleMiniChefV2.sol
ISaddlePermissionlessSwap.sol
ILinearRateModel.sol
ILToken.sol
ILPToken.sol
ISwapFlashLoan.sol
ICurveVault.sol
IOpynPerpVault.sol
IStakeDAOController.sol
IStakeDAOGauge.sol
IStakeDaoVault.sol
ILPStaking.sol
IStellaDistributorV2.sol
IStellaSwapFlashLoan.sol
ITempleFraxAMMOps.sol
OwnerTesting.sol
IThenaGaugeV2.sol
ItAsset.sol
TokenTrackerV2.sol
TWAMM_AMO.sol
UniV3LiquidityAMO_V2.sol
IPoolRewards.sol
IVPool.sol
MockConvexRegistry.sol
MockConvexVault.sol
ChainlinkETHUSDPriceConsumerTest.sol
ChainlinkFXSUSDPriceConsumer.sol
ComboOracle_KyberSwapElastic.sol
ComboOracle_UniV2_UniV3.sol
ComboOracle.sol
CPITrackerOracle.sol
CrossChainOracle.sol
CrossChainOracleSingleAsset.sol
CrossChainOracleSingleAssetV2.sol
FRAXOracleWrapper.sol
FXSOracleWrapper.sol
ICrossChainOracle.sol
IPricePerShareOptions.sol
PIDController.sol
ReserveTracker.sol
UniswapPairOracleExtra.sol
UniV3TWAPOracle.sol
UniswapPairOracle_6DEC_WETH.sol
UniswapPairOracle_FRAX_6DEC.sol
UniswapPairOracle_FRAX_FXS.sol
UniswapPairOracle_FRAX_USDC.sol
UniswapPairOracle_FRAX_USDT.sol
UniswapPairOracle_FRAX_WETH.sol
UniswapPairOracle_FXS_6DEC.sol
UniswapPairOracle_FXS_USDC.sol
UniswapPairOracle_FXS_USDT.sol
UniswapPairOracle_FXS_WETH.sol
UniswapPairOracle_USDC_WETH.sol
UniswapPairOracle_USDT_WETH.sol
UniswapPairOracleExtra_SDT_WETH.sol
ERC1967Proxy.sol
ERC1967Storage.sol
ERC1967Upgrade.sol
IBeacon.sol
Initializable.sol
Proxy.sol
CommunalFarm.sol
FraxCrossChainFarm.sol
FraxCrossChainFarmV2.sol
FraxCrossChainFarmV3_ERC20.sol
FraxCrossChainFarmV3_Pos_Rebase.sol
FraxFarmRageQuitter_Gelato_FRAX_DAI.sol
FraxFarmRageQuitter_mStable.sol
FraxFarmRageQuitter_StakeDAO_FraxPut.sol
FraxFarmRageQuitter_Temple.sol
FraxUnifiedFarm_ERC20.sol
FraxUnifiedFarm_KyberSwapElastic.sol
FraxUnifiedFarm_PosRebase.sol
FraxUnifiedFarm_UniV3.sol
FraxUnifiedFarmTemplate.sol
FraxUnifiedFarmTemplateClone.sol
FraxUniV3Farm_Stable.sol
FXSRewards.sol
IFraxFarm.sol
ILockReceiver.sol
IStakingRewards.sol
IStakingRewardsDual.sol
IStakingRewardsDualForMigrator.sol
IStakingRewardsDualV3.sol
IveFPISYieldDistributor.sol
IveFXSYieldDistributor.sol
MicroVeFXSStaker.sol
Owned_Proxy.sol
OwnedV2.sol
Pausable.sol
RewardsDistributionRecipient.sol
StakingRewardsDualV5.sol
StakingRewardsMultiGauge.sol
CommunalFarm_SaddleD4.sol
FraxCCFarmV2_ArbiCurveVSTFRAX.sol
FraxCCFarmV2_SaddleArbUSDv2.sol
FraxCCFarmV3_ArbiSaddleL2D4.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Stable_Factory.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Stable.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Volatile.sol
FraxUnifiedFarm_ERC20_Convex_frxETH.sol
FraxUnifiedFarm_ERC20_Convex_Generic.sol
FraxUnifiedFarm_ERC20_Fraxlend.sol
FraxUnifiedFarm_ERC20_FraxswapV2.sol
FraxUnifiedFarm_KyberSwapElasticGeneric.sol
FraxUnifiedFarm_PosRebase_aFRAX.sol
FraxUnifiedFarm_UniV3_FRAX_RAI.sol
veFPISYieldDistributorV4.sol
veFPISYieldDistributorV5.sol
veFXSYieldDistributorV4.sol
ISwapRouter.sol
IUniswapV3Factory.sol
IUniswapV3Pool.sol
IUniswapV3PoolDeployer.sol
IUniswapV3PositionsNFT.sol
FixedPoint96.sol
FullMath.sol
LiquidityAmounts.sol
Testing.sol
TickMath.sol
IERC721Permit.sol
INonfungiblePositionManager.sol
IPeripheryImmutableState.sol
IPeripheryPayments.sol
IPoolInitializer.sol
OracleLibrary.sol
PoolAddress.sol
IUniswapV3PoolActions.sol
IUniswapV3PoolDerivedState.sol
IUniswapV3PoolEvents.sol
IUniswapV3PoolImmutables.sol
IUniswapV3PoolOwnerActions.sol
IUniswapV3PoolState.sol
IUniswapV2Callee.sol
IUniswapV2ERC20.sol
IUniswapV2Router01.sol
IUniswapV2Router02.sol
SwapToPrice.sol
TransferHelperV2.sol
Address_8.sol
BlockMiner.sol
BundleUtils.sol
GasHelper.sol
MigrationBundleUtils.sol
MigrationHelper.sol
Migrations.sol
Multicall_Oz.sol
ReentrancyGuard.sol
ReentrancyGuardV2.sol
StorageSlot.sol
console.sol
LeveragePool.sol

TVL

$5.65M

21 downloads

Chains

Authors

Frax
  • Stablecoin
  • Lending
  • DEX
  • Algo-Stables
  • Protocol
  • Audited
Info
Docs
Source
ChefGPT
Expand
Share

Get Cookin'

21 downloads

Chains

Authors

Frax Finance ā€“ Solidity Implementation

šŸ–„ Website ā€“ https://frax.finance

šŸ“– Documentation ā€“ https://docs.frax.finance

šŸ“² Telegram ā€“ https://t.me/fraxfinance

What is Frax?

Frax is the first fractional-algorithmic stablecoin protocol. Frax is open-source, permissionless, and entirely on-chain ā€“ currently implemented on Ethereum (with possible cross chain implementations in the future). The end goal of the Frax protocol is to provide a highly scalable, decentralized, algorithmic money in place of fixed-supply digital assets like BTC.

Frax is a new paradigm in stablecoin design. It brings together familiar concepts into a never before seen protocol:

  • Fractional-Algorithmic ā€“ Frax is the first and only stablecoin with parts of its supply backed by collateral and parts of the supply algorithmic. The ratio of collateralized and algorithmic depends on the market's pricing of the FRAX stablecoin. If FRAX is trading at above $1, the protocol decreases the collateral ratio. If FRAX is trading at under $1, the protocol increases the collateral ratio.

  • Decentralized & Governance-minimized ā€“ Community governed and emphasizing a highly autonomous, algorithmic approach with no active management.

  • Fully on-chain oracles ā€“ Frax v1 uses Uniswap (ETH, USDT, USDC time-weighted average prices) and Chainlink (USD price) oracles.

  • Two Tokens ā€“ FRAX is the stablecoin targeting a tight band around $1/coin. Frax Shares (FXS) is the governance token which accrues fees, seigniorage revenue, and excess collateral value.

  • Swap-based Monetary Policy ā€“ Frax uses principles from automated market makers like Uniswap to create swap-based price discovery and real-time stabilization incentives through arbitrage.

Running tests

cd ./src/hardhat npx hardhat test ./test/FraxSwap/fraxswap-twamm-test.js

Inventors of the fractional stablecoin. $FRAX is the 1st stablecoin with parts backed & parts algorithmic
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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three 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 {_setupDecimals} is called. 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: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
ERC20Custom :
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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
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.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
Chainlink :
Uses imported CBOR library for encoding to buffer
BufferChainlink :
A library for working with mutable byte buffers in Solidity. Byte buffers are mutable and expandable, and provide a variety of primitives for writing 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.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
IAccessControl :
External interface of AccessControl declared to support ERC165 detection.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {AccessControl-_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {AccessControl-_setRoleAdmin}.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
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. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
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 {ERC20Mintable}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. Requirements: - `spender` cannot be the zero address.approve(address spender, uint256 amount)
balanceOf(address) :
See {IERC20-balanceOf}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for `accounts`'s tokens of at least `amount`.
constructor :
Sets the values for {name} and {symbol}, initializes {decimals} with a default value of 18. To select a different value for {decimals}, use {_setupDecimals}. All three 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 {_setupDecimals} is called. 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: - `recipient` 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}; Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for `sender`'s tokens of at least `amount`.
ERC20Burnable :
Extension of {ERC20} that allows token holders to destroy both their own tokens and those that they have an allowance for, in a way that can be recognized off-chain (via event analysis).
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}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for ``accounts``'s tokens of at least `amount`.
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 default value returned by this function, unless it's 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`.
ERC20Permit :
Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all. _Available since v3.4._
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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 :
Initializes the {EIP712} domain separator using the `name` parameter, and setting `version` to `"1"`. It's a good idea to use the same `name` that is defined as the ERC20 token name.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
IERC721Enumerable :
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}
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.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
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.
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.
Counters :
Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids. Include with `using Counters for Counters.Counter;`
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.
EIP712 :
https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data. The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`. This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}). The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain. NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask]. NOTE: In the upgradeable version of this contract, the cached values will correspond to the address, and the domain separator of the implementation contract. This will cause the `_domainSeparatorV4` function to always rebuild the separator from the immutable values, which is cheaper than accessing a cached version in cold storage. _Available since v3.4._
constructor :
Initializes the domain separator and parameter caches. The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]: - `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol. - `version`: the current major version of the signing domain. NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade].
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
SafeCast :
Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting.
SignedMath :
Standard signed math utilities missing in the Solidity language.
ShortStrings :
This library provides functions to convert short memory strings into a `ShortString` type that can be used as an immutable variable. Strings of arbitrary length can be optimized using this library if they are short enough (up to 31 bytes) by packing them with their length (1 byte) in a single EVM word (32 bytes). Additionally, a fallback mechanism can be used for every other case. Usage example: ```solidity contract Named { using ShortStrings for *; ShortString private immutable _name; string private _nameFallback; constructor(string memory contractName) { _name = contractName.toShortStringWithFallback(_nameFallback); } function name() external view returns (string memory) { return _name.toStringWithFallback(_nameFallback); } } ```
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
Strings :
String operations.
IUniswapV3Pool :
The pool interface is broken up into many smaller pieces
burn(int24,int24,uint128) :
Can be used to trigger a recalculation of fees owed to a position by calling with an amount of 0Fees must be collected separately via a call to #collect
collect(address,int24,int24,uint128,uint128) :
Does not recompute fees earned, which must be done either via mint or burn of any amount of liquidity. Collect must be called by the position owner. To withdraw only token0 or only token1, amount0Requested or amount1Requested may be set to zero. To withdraw all tokens owed, caller may pass any value greater than the actual tokens owed, e.g. type(uint128).max. Tokens owed may be from accumulated swap fees or burned liquidity.
feeGrowthGlobal0X128() :
This value can overflow the uint256
feeGrowthGlobal1X128() :
This value can overflow the uint256
flash(address,uint256,uint256,bytes) :
The caller of this method receives a callback in the form of IUniswapV3FlashCallback#uniswapV3FlashCallbackCan be used to donate underlying tokens pro-rata to currently in-range liquidity providers by calling with 0 amount{0,1} and sending the donation amount(s) from the callback
increaseObservationCardinalityNext(uint16) :
This method is no-op if the pool already has an observationCardinalityNext greater than or equal to the input observationCardinalityNext.
initialize(uint160) :
Price is represented as a sqrt(amountToken1/amountToken0) Q64.96 value
liquidity() :
This value has no relationship to the total liquidity across all ticks
maxLiquidityPerTick() :
This parameter is enforced per tick to prevent liquidity from overflowing a uint128 at any point, and also prevents out-of-range liquidity from being used to prevent adding in-range liquidity to a pool
mint(address,int24,int24,uint128,bytes) :
The caller of this method receives a callback in the form of IUniswapV3MintCallback#uniswapV3MintCallback in which they must pay any token0 or token1 owed for the liquidity. The amount of token0/token1 due depends on tickLower, tickUpper, the amount of liquidity, and the current price.
observations(uint256) :
You most likely want to use #observe() instead of this method to get an observation as of some amount of time ago, rather than at a specific index in the array.
observe(uint32[]) :
To get a time weighted average tick or liquidity-in-range, you must call this with two values, one representing the beginning of the period and another for the end of the period. E.g., to get the last hour time-weighted average tick, you must call it with secondsAgos = [3600, 0].The time weighted average tick represents the geometric time weighted average price of the pool, in log base sqrt(1.0001) of token1 / token0. The TickMath library can be used to go from a tick value to a ratio.
protocolFees() :
Protocol fees will never exceed uint128 max in either token
snapshotCumulativesInside(int24,int24) :
Snapshots must only be compared to other snapshots, taken over a period for which a position existed. I.e., snapshots cannot be compared if a position is not held for the entire period between when the first snapshot is taken and the second snapshot is taken.
swap(address,bool,int256,uint160,bytes) :
The caller of this method receives a callback in the form of IUniswapV3SwapCallback#uniswapV3SwapCallback
tickSpacing() :
Ticks can only be used at multiples of this value, minimum of 1 and always positive e.g.: a tickSpacing of 3 means ticks can be initialized every 3rd tick, i.e., ..., -6, -3, 0, 3, 6, ... This value is an int24 to avoid casting even though it is always positive.
SafeCast :
Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows. Using this library instead of the unchecked operations eliminates an entire class of bugs, so it's recommended to use it always. Can be combined with {SafeMath} and {SignedSafeMath} to extend it to smaller types, by performing all math on `uint256` and `int256` and then downcasting.
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. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
FraxFamilialPitchGauge :
To use this: - Add to GaugeController as a gauge - Add to FXS Rewards Distributor as a gauge * BUT do not set as a middleman gauge on the FXS Rewards Distributor - Set as the `gaugeController` & `rewardsDistributor` on all children FraxFarms - Disable rewards for pre-existing gauges on the FXS Rewards Distributor
gauge_relative_weight_write(address,uint256) :
Note: unfortunately many of the steps in this process need to be done after completing previous step for all children
veFPISProxy :
Is given special permissions in veFPIS.vy to transfer FPIS to itself and whitelisted apps, and also to slash / lock additional FPIS for a userUsers cannot withdraw their veFPIS while they have a balance in the proxy
appAdd(address,uint256) :
App must first approve the veFPIS contract to spend the surplus amount of FPIS to payback
transferFromAppToVeFPIS(address,uint256) :
App must first approve the veFPIS contract to spend the amount of FPIS to payback
userSlash(address,uint256) :
useful in the case of a bug in the app which would otherwise prevent user from withdrawing from veFPIS
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.
Counters :
Provides counters that can only be incremented, decremented or reset. This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids. Include with `using Counters for Counters.Counter;`
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.
EIP712 :
https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data. The encoding specified in the EIP is very generic, and such a generic implementation in Solidity is not feasible, thus this contract does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in their contracts using a combination of `abi.encode` and `keccak256`. This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA ({_hashTypedDataV4}). The implementation of the domain separator was designed to be as efficient as possible while still properly updating the chain id to protect against replay attacks on an eventual fork of the chain. NOTE: This contract implements the version of the encoding known as "v4", as implemented by the JSON RPC method https://docs.metamask.io/guide/signing-data.html[`eth_signTypedDataV4` in MetaMask]. NOTE: In the upgradeable version of this contract, the cached values will correspond to the address, and the domain separator of the implementation contract. This will cause the `_domainSeparatorV4` function to always rebuild the separator from the immutable values, which is cheaper than accessing a cached version in cold storage. _Available since v3.4._
constructor :
Initializes the domain separator and parameter caches. The meaning of `name` and `version` is specified in https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]: - `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol. - `version`: the current major version of the signing domain. NOTE: These parameters cannot be changed except through a xref:learn::upgrading-smart-contracts.adoc[smart contract upgrade].
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
ERC20Permit :
Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all. _Available since v3.4._
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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 :
Initializes the {EIP712} domain separator using the `name` parameter, and setting `version` to `"1"`. It's a good idea to use the same `name` that is defined as the ERC20 token name.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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`.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
ERC20PermitPermissionedMint :
ERC20PermitPermissionedMint adheres to EIP-712/EIP-2612 and can use permits
DOMAIN_SEPARATOR() :
See {IERC20Permit-DOMAIN_SEPARATOR}.
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}.
burn(uint256) :
Destroys `amount` tokens from the caller. See {ERC20-_burn}.
burnFrom(address,uint256) :
Destroys `amount` tokens from `account`, deducting from the caller's allowance. See {ERC20-_burn} and {ERC20-allowance}. Requirements: - the caller must have allowance for ``accounts``'s tokens of at least `amount`.
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 default value returned by this function, unless it's 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`.
eip712Domain() :
See {EIP-5267}. _Available since v4.9._
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.
nonces(address) :
See {IERC20Permit-nonces}.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
See {IERC20Permit-permit}.
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`.
ERC20Virtual :
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.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin guidelines: functions revert instead of 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}. 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: - `recipient` 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}. Requirements: - `sender` and `recipient` cannot be the zero address. - `sender` must have a balance of at least `amount`. - the caller must have allowance for ``sender``'s tokens of at least `amount`.
IERC20_Detailed :
Interface of the ERC20 standard as defined in the EIP. Does not include the optional functions; to access them see {ERC20Detailed}.
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 `recipient`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `sender` to `recipient` 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.
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.
ERC721 :
see https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
baseURI() :
Returns the base URI set via {_setBaseURI}. This will be automatically added as a prefix in {tokenURI} to each token's URI, or to the token ID if no specific URI is set for that token ID.
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}. Time complexity O(1), guaranteed to always use less than 30 000 gas.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
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.
IERC721Enumerable :
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}
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.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
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.
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.
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 `IERC721.onERC721Received.selector`.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. Roles are referred to by their `bytes32` identifier. These should be exposed in the external API and be unique. The best way to achieve this is by using `public constant` hash digests: ``` bytes32 public constant MY_ROLE = keccak256("MY_ROLE"); ``` Roles can be used to represent a set of permissions. To restrict access to a function call, use {hasRole}: ``` function foo() public { require(hasRole(MY_ROLE, msg.sender)); ... } ``` Roles can be granted and revoked dynamically via the {grantRole} and {revokeRole} functions. Each role has an associated admin role, and only accounts that have a role's admin role can call {grantRole} and {revokeRole}. By default, the admin role for all roles is `DEFAULT_ADMIN_ROLE`, which means that only accounts with this role will be able to grant or revoke other roles. More complex role relationships can be created by using {_setRoleAdmin}. WARNING: The `DEFAULT_ADMIN_ROLE` is also its own admin: it has permission to grant and revoke this role. Extra precautions should be taken to secure accounts that have been granted it.
RoleAdminChanged(bytes32,bytes32,bytes32) :
Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole` `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite {RoleAdminChanged} not being emitted signaling this. _Available since v3.1._
RoleGranted(bytes32,address,address) :
Emitted when `account` is granted `role`. `sender` is the account that originated the contract call, an admin role bearer except when using {_setupRole}.
RoleRevoked(bytes32,address,address) :
Emitted when `account` is revoked `role`. `sender` is the account that originated the contract call: - if using `revokeRole`, it is the admin role bearer - if using `renounceRole`, it is the role bearer (i.e. `account`)
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getRoleMember(bytes32,uint256) :
Returns one of the accounts that have `role`. `index` must be a value between 0 and {getRoleMemberCount}, non-inclusive. Role bearers are not sorted in any particular way, and their ordering may change at any point. WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure you perform all queries on the same block. See the following https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post] for more information.
getRoleMemberCount(bytes32) :
Returns the number of accounts that have `role`. Can be used together with {getRoleMember} to enumerate all bearers of a role.
grantRole(bytes32,address) :
Grants `role` to `account`. If `account` had not been already granted `role`, emits a {RoleGranted} event. Requirements: - the caller must have ``role``'s admin role.
hasRole(bytes32,address) :
Returns `true` if `account` has been granted `role`.
renounceRole(bytes32,address) :
Revokes `role` from the calling account. Roles are often managed via {grantRole} and {revokeRole}: this function's purpose is to provide a mechanism for accounts to lose their privileges if they are compromised (such as when a trusted device is misplaced). If the calling account had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must be `account`.
revokeRole(bytes32,address) :
Revokes `role` from `account`. If `account` had been granted `role`, emits a {RoleRevoked} event. Requirements: - the caller must have ``role``'s admin role.
EnumerableMap :
Library for managing an enumerable variant of Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`] type. Maps have the following properties: - Entries are added, removed, and checked for existence in constant time (O(1)). - Entries are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableMap for EnumerableMap.UintToAddressMap; // Declare a set state variable EnumerableMap.UintToAddressMap private myMap; } ``` As of v3.0.0, only maps of type `uint256 -> address` (`UintToAddressMap`) are supported.
EnumerableSet :
Library for managing https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets] of primitive types. Sets have the following properties: - Elements are added, removed, and checked for existence in constant time (O(1)). - Elements are enumerated in O(n). No guarantees are made on the ordering. ``` contract Example { // Add the library methods using EnumerableSet for EnumerableSet.AddressSet; // Declare a set state variable EnumerableSet.AddressSet private mySet; } ``` As of v3.0.0, only sets of type `address` (`AddressSet`) and `uint256` (`UintSet`) are supported.
Strings :
String operations.
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
FraxswapRouterMultihop :
Router for swapping across the majority of the FRAX liquidity
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling 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.
TokenVesting :
A token holder contract that can release its token balance gradually like a typical vesting scheme, with a cliff and vesting period. Optionally revocable by the owner. Modified from OpenZeppelin's TokenVesting.sol draft
constructor :
Creates a vesting contract that vests its balance of any ERC20 token to the beneficiary, gradually in a linear fashion until start + duration. By then all of the balance will have vested.
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
SignedSafeMath :
Wrappers over Solidity's arithmetic operations. NOTE: `SignedSafeMath` is no longer needed starting with Solidity 0.8. The compiler now has built in overflow checking.
KyberFullMath :
Handles "phantom overflow" i.e., allows multiplication and division where an intermediate value overflows 256 bitsCode has been modified to be compatible with sol 0.8
ILendingPoolAddressesProvider :
Main registry of addresses part of or connected to the protocol, including permissioned roles - Acting also as factory of proxies and admin of those, so with right to change its implementations - Owned by the Aave Governance
ERC1967Proxy :
This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the implementation behind the proxy.
constructor :
Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializating the storage of the proxy like a Solidity constructor.
ERC1967Storage :
This abstract contract provides setters and getters for the different https://eips.ethereum.org/EIPS/eip-1967[EIP1967] storage slots. _Available since v4.1._
ERC1967Upgrade :
This abstract contract provides event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. _Available since v4.1._
AdminChanged(address,address) :
Emitted when the admin account has changed.
BeaconUpgraded(address) :
Emitted when the beacon is upgraded.
Upgraded(address) :
Emitted when the implementation is upgraded.
IBeacon :
This is the interface that {BeaconProxy} expects of its beacon.
implementation() :
Must return an address that can be used as a delegate call target. {BeaconProxy} will check that this address is a contract.
Initializable :
This is a base contract to aid in writing upgradeable contracts, or any kind of contract that will be deployed behind a proxy. Since a proxied contract can't have a constructor, it's common to move constructor logic to an external initializer function, usually called `initialize`. It then becomes necessary to protect this initializer function so it can only be called once. The {initializer} modifier provided by this contract will have this effect. TIP: To avoid leaving the proxy in an uninitialized state, the initializer function should be called as early as possible by providing the encoded function call as the `_data` argument to {ERC1967Proxy-constructor}. CAUTION: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or to ensure that all initializers are idempotent. This is not verified automatically as constructors are by Solidity.
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
IUniswapV3Pool :
The pool interface is broken up into many smaller pieces
burn(int24,int24,uint128) :
Can be used to trigger a recalculation of fees owed to a position by calling with an amount of 0Fees must be collected separately via a call to #collect
collect(address,int24,int24,uint128,uint128) :
Does not recompute fees earned, which must be done either via mint or burn of any amount of liquidity. Collect must be called by the position owner. To withdraw only token0 or only token1, amount0Requested or amount1Requested may be set to zero. To withdraw all tokens owed, caller may pass any value greater than the actual tokens owed, e.g. type(uint128).max. Tokens owed may be from accumulated swap fees or burned liquidity.
feeGrowthGlobal0X128() :
This value can overflow the uint256
feeGrowthGlobal1X128() :
This value can overflow the uint256
flash(address,uint256,uint256,bytes) :
The caller of this method receives a callback in the form of IUniswapV3FlashCallback#uniswapV3FlashCallbackCan be used to donate underlying tokens pro-rata to currently in-range liquidity providers by calling with 0 amount{0,1} and sending the donation amount(s) from the callback
increaseObservationCardinalityNext(uint16) :
This method is no-op if the pool already has an observationCardinalityNext greater than or equal to the input observationCardinalityNext.
initialize(uint160) :
Price is represented as a sqrt(amountToken1/amountToken0) Q64.96 value
liquidity() :
This value has no relationship to the total liquidity across all ticks
maxLiquidityPerTick() :
This parameter is enforced per tick to prevent liquidity from overflowing a uint128 at any point, and also prevents out-of-range liquidity from being used to prevent adding in-range liquidity to a pool
mint(address,int24,int24,uint128,bytes) :
The caller of this method receives a callback in the form of IUniswapV3MintCallback#uniswapV3MintCallback in which they must pay any token0 or token1 owed for the liquidity. The amount of token0/token1 due depends on tickLower, tickUpper, the amount of liquidity, and the current price.
observations(uint256) :
You most likely want to use #observe() instead of this method to get an observation as of some amount of time ago, rather than at a specific index in the array.
observe(uint32[]) :
To get a time weighted average tick or liquidity-in-range, you must call this with two values, one representing the beginning of the period and another for the end of the period. E.g., to get the last hour time-weighted average tick, you must call it with secondsAgos = [3600, 0].The time weighted average tick represents the geometric time weighted average price of the pool, in log base sqrt(1.0001) of token1 / token0. The TickMath library can be used to go from a tick value to a ratio.
protocolFees() :
Protocol fees will never exceed uint128 max in either token
snapshotCumulativesInside(int24,int24) :
Snapshots must only be compared to other snapshots, taken over a period for which a position existed. I.e., snapshots cannot be compared if a position is not held for the entire period between when the first snapshot is taken and the second snapshot is taken.
swap(address,bool,int256,uint160,bytes) :
The caller of this method receives a callback in the form of IUniswapV3SwapCallback#uniswapV3SwapCallback
tickSpacing() :
Ticks can only be used at multiples of this value, minimum of 1 and always positive e.g.: a tickSpacing of 3 means ticks can be initialized every 3rd tick, i.e., ..., -6, -3, 0, 3, 6, ... This value is an int24 to avoid casting even though it is always positive.
IUniswapV3PoolDeployer :
This is used to avoid having constructor arguments in the pool contract, which results in the init code hash of the pool being constant allowing the CREATE2 address of the pool to be cheaply computed on-chain
parameters() :
Called by the pool constructor to fetch the parameters of the pool Returns factory The factory address Returns token0 The first token of the pool by address sort order Returns token1 The second token of the pool by address sort order Returns fee The fee collected upon every swap in the pool, denominated in hundredths of a bip Returns tickSpacing The minimum number of ticks between initialized ticks
FixedPoint96 :
Used in SqrtPriceMath.sol
FullMath :
Handles "phantom overflow", i.e., allows multiplication and division where an intermediate value overflows 256 bits.
Address_8 :
Collection of functions related to the address type
Multicall_Oz :
Provides a function to batch together multiple calls in a single external call. _Available since v4.1._
multicall(address,bytes[]) :
Receives and executes a batch of function calls on the target contract.
multicallMany(address[],bytes[]) :
Receives and executes a batch of function calls on the target contract(s).
multicallThis(bytes[]) :
Receives and executes a batch of function calls on this contract.
ReentrancyGuardV2 :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
FRAX3CRV_Curve_FXS_Distributor.sol
Context.sol
ERC20.sol
ERC20Custom.sol
IERC20.sol
Frax.sol
FraxPool.sol
FraxPoolLibrary.sol
FXS.sol
AccessControl.sol
Governance.sol
Babylonian.sol
FixedPoint.sol
SafeMath.sol
AggregatorV3Interface.sol
ChainlinkETHUSDPriceConsumer.sol
UniswapPairOracle.sol
Owned.sol
IUniswapV2Factory.sol
IUniswapV2Pair.sol
TransferHelper.sol
UniswapV2Library.sol
UniswapV2OracleLibrary.sol
Address.sol
EnumerableSet.sol
SigRelayer2.sol
AddressAliasHelper.sol
Chainlink.sol
ChainlinkClient.sol
AggregatorV3Interface.sol
ChainlinkRequestInterface.sol
ENSInterface.sol
LinkTokenInterface.sol
OperatorInterface.sol
OracleInterface.sol
PointerInterface.sol
BufferChainlink.sol
CBORChainlink.sol
ENSResolver.sol
AccessControl.sol
IAccessControl.sol
Ownable.sol
IERC5267.sol
Pausable.sol
ReentrancyGuard.sol
ERC20.sol
draft-ERC20Permit.sol
draft-IERC20Permit.sol
ERC20Burnable.sol
ERC20Permit.sol
IERC20Metadata.sol
IERC20Permit.sol
IERC20.sol
SafeERC20.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721.sol
Address.sol
Context.sol
Counters.sol
ECDSA.sol
EIP712.sol
ERC165.sol
IERC165.sol
Math.sol
SafeCast.sol
SignedMath.sol
ShortStrings.sol
StorageSlot.sol
Strings.sol
IUniswapV2Callee.sol
IUniswapV2Pair.sol
IWETH.sol
IUniswapV3SwapCallback.sol
IUniswapV3Pool.sol
IUniswapV3PoolActions.sol
IUniswapV3PoolDerivedState.sol
IUniswapV3PoolEvents.sol
IUniswapV3PoolImmutables.sol
IUniswapV3PoolOwnerActions.sol
IUniswapV3PoolState.sol
SafeCast.sol
TransferHelper.sol
Babylonian.sol
BAMM.sol
BAMMHelper.sol
FixedPoint.sol
FraxswapDummyRouter.sol
FraxswapOracle.sol
CrossChainBridgeBacker_ARBI_AnySwap.sol
FraxLiquidityBridger_ARBI_AnySwap.sol
IL1CustomGateway.sol
IL2GatewayRouter.sol
CrossChainBridgeBacker.sol
FraxLiquidityBridger.sol
ContextV2.sol
Ownable.sol
CurveInterfaces.sol
CurveVoterProxy.sol
FraxCrossChainRewarder.sol
FraxFamilialPitchGauge.sol
FraxGaugeFXSRewardsDistributor.sol
FraxMiddlemanGauge.sol
FraxMiddlemanGaugeFerryHelper.sol
FraxMiddlemanGaugeV2.sol
ICurvefrxETHETHPool.sol
IDelegationProxy.sol
IFraxGaugeController.sol
IFraxGaugeControllerV2.sol
IFraxGaugeFXSRewardsDistributor.sol
ILiquidityGaugeV2.sol
IMetaImplementationUSD.sol
IMinter.sol
IStableSwap3Pool.sol
IveFPIS.sol
IveFXS.sol
IVotingEscrowDelegation.sol
FraxMiddlemanGauge_ARBI_Curve_VSTFRAX.sol
FraxMiddlemanGauge_FRAX_mUSD.sol
NoopRewardsDistributor.sol
SmartWalletWhitelist.sol
veFPISProxy.sol
ERC165.sol
IERC165.sol
anyFRAX.sol
anyFXS.sol
AnyswapV4ERC20.sol
AnyswapV5ERC20.sol
anyUSDC.sol
arbiUSDC.sol
celrFRAX.sol
celrFXS.sol
CrossChainCanonical.sol
CrossChainCanonicalFRAX.sol
CrossChainCanonicalFXS.sol
CrossChainCanonicalV2.sol
IanyFRAX.sol
IanyFXS.sol
IAnyswapV4ERC20.sol
IAnyswapV5ERC20.sol
IArbFiatToken.sol
IChildChainManager.sol
ICrossChainCanonical.sol
IUChildAdministrableERC20.sol
IUChildERC20.sol
oneFRAX.sol
oneFXS.sol
oneUSDC.sol
polyFRAX.sol
polyFXS.sol
polyUSDC.sol
DeflatingERC20.sol
ERC20Mock.sol
ERC20MockTWAMM.sol
ERC20PermissionedMint.sol
Counters.sol
ECDSA.sol
EIP712.sol
ERC20Permit.sol
IERC20Permit.sol
ERC20PermitPermissionedMint.sol
ERC20Virtual.sol
IERC20_Detailed.sol
IERC20Metadata.sol
IERC20V2.sol
IWETH.sol
SafeERC20.sol
Comp.sol
FarmToken.sol
FRAX3CRV_V2_Mock.sol
IQToken.sol
ERC721.sol
IERC721.sol
IERC721Enumerable.sol
IERC721Metadata.sol
IERC721Receiver.sol
Context.sol
AccessControl.sol
SafeMath.sol
Address.sol
EnumerableMap.sol
EnumerableSet.sol
Strings.sol
ABDKMath64x64.sol
FPI.sol
FPIControllerPool.sol
FPIS.sol
FPIStaking.sol
FPIStaking2.sol
IERC20.sol
IFPI.sol
Math.sol
PermissionedSend.sol
SafeMath.sol
StakedFPI.sol
FraxAMOMinter.sol
FraxAMOMinterLayer2.sol
FraxBridge.sol
IFrax.sol
IFraxAMOMinter.sol
IFraxAMOMinterOld.sol
FraxPoolV3.sol
FraxPoolvAMM.sol
IFraxPool.sol
Pool_USDC.sol
PoolvAMM_USDC.sol
TestDriftingReserves.sol
Fraxauction.sol
FraxFPIBond.sol
FraxFPIBondYield.sol
FXB.sol
IFPIControllerPool.sol
SlippageAuction.sol
FrxETHMiniRouter.sol
IfrxETH.sol
IfrxETHMinter.sol
IsfrxETH.sol
DummyToken.sol
Fraxferry.sol
IFraxferry.sol
FerryOnL1.sol
FerryOnL2.sol
IFraxlendAMO.sol
IFraxlendAMOV3.sol
IFraxlendPair.sol
IFraxlendPairHelper.sol
DummyPriceOracle.sol
DummyStateRootOracle.sol
Fraxoracle.sol
FraxoraclePriceSource.sol
IBlockhashProvider.sol
IInbox.sol
IMessageProvider.sol
IPriceOracle.sol
IStateRootOracle.sol
ITelepathyRouter.sol
MerklePatriciaProofVerifier.sol
MerkleTreeProver.sol
RLPReader.sol
StateProofVerifier.sol
MerkleProofPriceSource.sol
ArbitrumBlockhashProvider.sol
ArbitrumBlockhashRelay.sol
OperatorBlockhashProvider.sol
TelepathyBlockhashProvider.sol
TelepathyBlockhashRelay.sol
StateProver.sol
StateRootOracle.sol
FraxswapERC20.sol
FraxswapFactory.sol
FraxswapPair.sol
GlobalPauseHelper.sol
IERC20V5.sol
IFraxswapFactory.sol
IFraxswapPair.sol
IUniswapV2CalleeV5.sol
IUniswapV2ERC20V5.sol
IUniswapV2FactoryV5.sol
IUniswapV2PairPartialV5.sol
IUniswapV2PairV5.sol
Math.sol
SafeMath.sol
UQ112x112.sol
ComputeUniswapV2PairInitHash.sol
ERC20CoreTest.sol
ILiquidityModifier.sol
AddressStringUtil.sol
Babylonian.sol
BitMath.sol
FixedPoint.sol
FullMath.sol
SafeERC20Namer.sol
TransferHelper.sol
ExampleComputeLiquidityValue.sol
ExampleFlashSwap.sol
ExampleOracleSimple.sol
ExampleSlidingWindowOracle.sol
ExampleSwapToPrice.sol
FraxswapRouter.sol
FraxswapRouterMultihop.sol
IERC20.sol
IFraxswapRouterMultihop.sol
IUniswapV2MigratorV5.sol
IUniswapV2Router01V5.sol
IUniswapV2Router02V5.sol
IWETH.sol
IUniswapV1Exchange.sol
IUniswapV1Factory.sol
FraxswapRouterLibrary.sol
SafeMath.sol
UniswapV2LiquidityMathLibrary.sol
UniswapV2LiquidityMathLibraryMini.sol
UniswapV2OracleLibrary.sol
DeflatingERC20.sol
ERC20PeriTest.sol
RouterEventEmitter.sol
WETH9.sol
LongTermOrders.sol
FXB.sol
FXBFactory.sol
FXBMintRedeemerAMO.sol
IFxs.sol
TokenVesting.sol
Timelock.sol
IERC20.sol
TestERC20.sol
AddressStringUtil.sol
BitMath.sol
BokkyPooBahsDateTimeContract.sol
BokkyPooBahsDateTimeLibrary.sol
FullMath.sol
HomoraMath.sol
MagnitudesAndPowers.sol
Math.sol
MathV2.sol
SafeDecimalMath.sol
SafeERC20Namer.sol
SafeMathV2.sol
SignedSafeMath.sol
UQ112x112.sol
CurveAMO_ARBI.sol
SushiSwapLiquidityAMO_ARBI.sol
IBBROARMasterchef.sol
IROARMasterchef.sol
IApePair.sol
IApeRouter.sol
IMasterApe.sol
IAxialToken.sol
IMasterChefAxialV3.sol
ISwapFlashLoan.sol
IBalancerChildLiquidityGauge.sol
IBalancerVault.sol
IL2BalancerPseudoMinter.sol
IStablePool.sol
IBalancerOracle.sol
IBunniGauge.sol
IBunniLens.sol
IBunniMinter.sol
IBunniTokenLP.sol
IOptionsToken.sol
IComptroller.sol
IcUSDC_Partial.sol
Convex_AMO_V2.sol
IConvexBaseRewardPool.sol
IConvexBooster.sol
IConvexClaimZap.sol
IConvexStakingWrapperFrax.sol
IConvexStakingWrapperFraxWithEarned.sol
ICvxLocker.sol
ICvxLockerV2.sol
IcvxRewardPool.sol
IDepositToken.sol
IStakingProxyConvex.sol
IVirtualBalanceRewardPool.sol
I2pool.sol
I2PoolcvxCRVCRV.sol
I2poolGaugeDeposit.sol
I2poolNoLending.sol
I2poolToken.sol
I3pool.sol
I3poolGaugeDeposit.sol
I3poolToken.sol
IFRAX2pool.sol
IFRAX3pool.sol
IZapDepositor2pool.sol
IZapDepositor3pool.sol
IMasterPlatypusV3.sol
FXS1559_AMO_V3.sol
IGUniPool.sol
ICErc20DelegatorOld.sol
IAMO.sol
IConvexAMO_Old.sol
ICrossChainAMO.sol
IKSElasticLMV2.sol
IKSReinvestmentTokenPool.sol
IKyberSwapFarmingToken.sol
IKyberFactory.sol
KyberTickMath.sol
IKyberPool.sol
IPoolActions.sol
IPoolEvents.sol
IPoolStorage.sol
IAntiSnipAttackPositionManager.sol
ITickFeesReader.sol
KyberFullMath.sol
KyberLiquidityMath.sol
KyberMathConstants.sol
KyberSafeCast.sol
IRouter.sol
ISwapCallback.sol
IAAVE_aFRAX.sol
IAAVE_aUSDC_Partial.sol
IAaveIncentivesControllerPartial.sol
IAAVELendingPool_Partial.sol
IAToken.sol
ILendingPool.sol
ILendingPoolAddressesProvider.sol
IProtocolDataProvider.sol
IScaledBalanceToken.sol
IStakedAave.sol
AaveAMO_V2.sol
AaveAMO.sol
IFraxLendPair_Partial.sol
IFraxLendPairDeployer_Partial.sol
FraxLendAMO.sol
IBentoBoxV1.sol
IKashiPairMediumRiskV1.sol
IOracle.sol
KashiAMO.sol
ICErc20Delegator.sol
IRariComptroller.sol
RariFuseLendingAMO_V2.sol
RariFuseLendingAMO_V3.sol
IManagedPortfolio.sol
IManagedPortfolioFactory.sol
IPoolFactory.sol
IStkTruToken.sol
ITrueFiPool2.sol
ITrueMultiFarm.sol
TruefiAMO 2.sol
TruefiAMO.sol
ManualTokenTrackerAMO.sol
MSIGHelper.sol
IFeederPool.sol
IL1StandardBridge.sol
IL2StandardBridge.sol
IAsset.sol
IMasterPlatypusV4.sol
IVoter.sol
IRootChainManager.sol
IChildLiquidityGauge.sol
IChildLiquidityGaugeFactory.sol
IGaugeMinter.sol
IPoolRegistry.sol
IRootGauge.sol
ISaddleD4_LP.sol
ISaddleLPToken.sol
ISaddleMiniChefV2.sol
ISaddlePermissionlessSwap.sol
ILinearRateModel.sol
ILToken.sol
ILPToken.sol
ISwapFlashLoan.sol
ICurveVault.sol
IOpynPerpVault.sol
IStakeDAOController.sol
IStakeDAOGauge.sol
IStakeDaoVault.sol
ILPStaking.sol
IStellaDistributorV2.sol
IStellaSwapFlashLoan.sol
ITempleFraxAMMOps.sol
OwnerTesting.sol
IThenaGaugeV2.sol
ItAsset.sol
TokenTrackerV2.sol
TWAMM_AMO.sol
UniV3LiquidityAMO_V2.sol
IPoolRewards.sol
IVPool.sol
MockConvexRegistry.sol
MockConvexVault.sol
ChainlinkETHUSDPriceConsumerTest.sol
ChainlinkFXSUSDPriceConsumer.sol
ComboOracle_KyberSwapElastic.sol
ComboOracle_UniV2_UniV3.sol
ComboOracle.sol
CPITrackerOracle.sol
CrossChainOracle.sol
CrossChainOracleSingleAsset.sol
CrossChainOracleSingleAssetV2.sol
FRAXOracleWrapper.sol
FXSOracleWrapper.sol
ICrossChainOracle.sol
IPricePerShareOptions.sol
PIDController.sol
ReserveTracker.sol
UniswapPairOracleExtra.sol
UniV3TWAPOracle.sol
UniswapPairOracle_6DEC_WETH.sol
UniswapPairOracle_FRAX_6DEC.sol
UniswapPairOracle_FRAX_FXS.sol
UniswapPairOracle_FRAX_USDC.sol
UniswapPairOracle_FRAX_USDT.sol
UniswapPairOracle_FRAX_WETH.sol
UniswapPairOracle_FXS_6DEC.sol
UniswapPairOracle_FXS_USDC.sol
UniswapPairOracle_FXS_USDT.sol
UniswapPairOracle_FXS_WETH.sol
UniswapPairOracle_USDC_WETH.sol
UniswapPairOracle_USDT_WETH.sol
UniswapPairOracleExtra_SDT_WETH.sol
ERC1967Proxy.sol
ERC1967Storage.sol
ERC1967Upgrade.sol
IBeacon.sol
Initializable.sol
Proxy.sol
CommunalFarm.sol
FraxCrossChainFarm.sol
FraxCrossChainFarmV2.sol
FraxCrossChainFarmV3_ERC20.sol
FraxCrossChainFarmV3_Pos_Rebase.sol
FraxFarmRageQuitter_Gelato_FRAX_DAI.sol
FraxFarmRageQuitter_mStable.sol
FraxFarmRageQuitter_StakeDAO_FraxPut.sol
FraxFarmRageQuitter_Temple.sol
FraxUnifiedFarm_ERC20.sol
FraxUnifiedFarm_KyberSwapElastic.sol
FraxUnifiedFarm_PosRebase.sol
FraxUnifiedFarm_UniV3.sol
FraxUnifiedFarmTemplate.sol
FraxUnifiedFarmTemplateClone.sol
FraxUniV3Farm_Stable.sol
FXSRewards.sol
IFraxFarm.sol
ILockReceiver.sol
IStakingRewards.sol
IStakingRewardsDual.sol
IStakingRewardsDualForMigrator.sol
IStakingRewardsDualV3.sol
IveFPISYieldDistributor.sol
IveFXSYieldDistributor.sol
MicroVeFXSStaker.sol
Owned_Proxy.sol
OwnedV2.sol
Pausable.sol
RewardsDistributionRecipient.sol
StakingRewardsDualV5.sol
StakingRewardsMultiGauge.sol
CommunalFarm_SaddleD4.sol
FraxCCFarmV2_ArbiCurveVSTFRAX.sol
FraxCCFarmV2_SaddleArbUSDv2.sol
FraxCCFarmV3_ArbiSaddleL2D4.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Stable_Factory.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Stable.sol
FraxUnifiedFarm_ERC20_Convex_FRAXBP_Volatile.sol
FraxUnifiedFarm_ERC20_Convex_frxETH.sol
FraxUnifiedFarm_ERC20_Convex_Generic.sol
FraxUnifiedFarm_ERC20_Fraxlend.sol
FraxUnifiedFarm_ERC20_FraxswapV2.sol
FraxUnifiedFarm_KyberSwapElasticGeneric.sol
FraxUnifiedFarm_PosRebase_aFRAX.sol
FraxUnifiedFarm_UniV3_FRAX_RAI.sol
veFPISYieldDistributorV4.sol
veFPISYieldDistributorV5.sol
veFXSYieldDistributorV4.sol
ISwapRouter.sol
IUniswapV3Factory.sol
IUniswapV3Pool.sol
IUniswapV3PoolDeployer.sol
IUniswapV3PositionsNFT.sol
FixedPoint96.sol
FullMath.sol
LiquidityAmounts.sol
Testing.sol
TickMath.sol
IERC721Permit.sol
INonfungiblePositionManager.sol
IPeripheryImmutableState.sol
IPeripheryPayments.sol
IPoolInitializer.sol
OracleLibrary.sol
PoolAddress.sol
IUniswapV3PoolActions.sol
IUniswapV3PoolDerivedState.sol
IUniswapV3PoolEvents.sol
IUniswapV3PoolImmutables.sol
IUniswapV3PoolOwnerActions.sol
IUniswapV3PoolState.sol
IUniswapV2Callee.sol
IUniswapV2ERC20.sol
IUniswapV2Router01.sol
IUniswapV2Router02.sol
SwapToPrice.sol
TransferHelperV2.sol
Address_8.sol
BlockMiner.sol
BundleUtils.sol
GasHelper.sol
MigrationBundleUtils.sol
MigrationHelper.sol
Migrations.sol
Multicall_Oz.sol
ReentrancyGuard.sol
ReentrancyGuardV2.sol
StorageSlot.sol
console.sol
LeveragePool.sol