The Hummus protocol is a single-side Automated Market Maker designed for exchanging stable cryptocurrencies on the Metis blockchain. Hummus is an authorized fork of Platypus Finance
OwnableUpgradeable :
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.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
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.
PausableUpgradeable :
Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account. This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract. Note that they will not be pausable by simply including this module, only once the modifiers are put in place.
Paused(address) :
Emitted when the pause is triggered by `account`.
Unpaused(address) :
Emitted when the pause is lifted by `account`.
paused() :
Returns true if the contract is paused, and false otherwise.
ReentrancyGuardUpgradeable :
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].
ERC20Upgradeable :
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 Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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`.
IERC20Upgradeable :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `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.
IERC20MetadataUpgradeable :
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 `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.
SafeERC20Upgradeable :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
AddressUpgradeable :
Collection of functions related to the address type
ContextUpgradeable :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see {AccessControlEnumerable}. 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.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_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.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
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 anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
TimelockController :
Contract module which acts as a timelocked controller. When set as the owner of an `Ownable` smart contract, it enforces a timelock on all `onlyOwner` maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied. By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations. A common use case is to position this {TimelockController} as the owner of a smart contract, with a multisig or a DAO as the sole proposer. _Available since v3.3._
Execute an (ready) operation containing a batch of transactions. Emits one {CallExecuted} event per transaction in the batch. Requirements: - the caller must have the 'executor' role.
getMinDelay() :
Returns the minimum delay for an operation to become valid. This value can be changed by executing an operation that calls `updateDelay`.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getTimestamp(bytes32) :
Returns the timestamp at with an operation becomes ready (0 for unset operations, 1 for done operations).
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`.
Returns the identifier of an operation containing a batch of transactions.
isOperation(bytes32) :
Returns whether an id correspond to a registered operation. This includes both Pending, Ready and Done operations.
isOperationDone(bytes32) :
Returns whether an operation is done or not.
isOperationPending(bytes32) :
Returns whether an operation is pending or not.
isOperationReady(bytes32) :
Returns whether an operation is ready or not.
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.
Schedule an operation containing a batch of transactions. Emits one {CallScheduled} event per transaction in the batch. Requirements: - the caller must have the 'proposer' role.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
updateDelay(uint256) :
Changes the minimum timelock duration for future operations. Emits a {MinDelayChange} event. Requirements: - the caller must be the timelock itself. This can only be achieved by scheduling and later executing an operation where the timelock is the target and the data is the ABI-encoded call to this function.
ReentrancyGuard :
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].
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. 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 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `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 `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.
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
Strings :
String operations.
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.
AggregateAccount :
Aggregate Account has to be set for Asset
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Asset :
Expect to be owned by Timelock for management, and _pool links to Pool for coordination
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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.
initialize(address,string,string,address) :
_ suffix to avoid shadowing underlyingToken() name and symbolmax decimal points for underlying token is 18.
name() :
Returns the name of the token.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
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`.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
transferUnderlyingToken(address,uint256) :
Not to be confused with transferring platypus Assets.
Core :
Uses DSMath to compute using WAD and RAY.
Pool :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. + Added recover user funds (for funds mistakingly sent to this contract) + Added view function for eqCovRatio
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getEquilibriumCoverageRatio() :
[ sum of Ai * fi / sum Li * fi ]
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolAAvaxC :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added aAvaxc state variable and setaAvaxc() function adjusted pricicing feed to get rate from aAVAXc StakedAvax contract Mainnet : Can only handle WAVAX and aAVAXc
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSAvax :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added sAVAX state variable and setSAvax() function adjusted pricicing feed to get rate from BenQI StakedAvax contract Mainnet : 0x2b2C81e08f1Af8835a78Bb2A90AE924ACE0eA4bE Can only handle WAVAX and sAVAX
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSecondary :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSecondaryPure :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits pure means no external oracle is consulted and it always assumes 1:1 peg is maintained.
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolYYAvax :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added yyAvax state variable and setyyAvax() function adjusted pricicing feed to get rate from YY StakedAvax contract Mainnet : 0xf7d9281e8e363584973f946201b82ba72c965d27 Can only handle WAVAX and yyAvax
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
WETHForwarder :
Unwraps and forwards actual AVAX to userAllows transfer of WAVAX (called `weth` here).
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PlatypusRouter01 :
Owner is allowed and required to approve token spending by pools via approveSpendingByPool function
approveSpendingByPool(address[],address) :
needs to be done after asset deployment for router to be able to support the tokens
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PlatypusRouter02 :
Owner is allowed and required to approve token spending by pools via approveSpendingByPool function Edits: fixed haircut calculation
approveSpendingByPool(address[],address) :
needs to be done after asset deployment for router to be able to support the tokens
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Platypus has devised a whole new kind of StableSwap for enhanced capital efficiency, scalability and user experience in the Avalanche ecosystem.
Contracts
We detail a few of the core contracts for the Platypus Finance Protocol.
Core.sol
Handles most of the math: fees, slippage and haircut as defined in the yellow paper.
Pool.sol
Handles deposits, withdrawals and swaps with an open and extendable pool design.
Testing and Development
Local Development
Requires node@>=14
Install dependencies
yarn
Compile Contracts
yarn compile
Run tests
yarn test
Slither
Run
We use a mirror of slither to guarantee consistency and compatibility.
It is located in this repository.
docker run --rm -it -v "$PWD":/src platypusfinance/eth-security-toolbox
# Inside container
cd /src
slither .
Slither may generate false positives that may break CI. To suppress these false positives :
docker run --rm -it -v "$PWD":/src platypusfinance/eth-security-toolbox
# Inside container
cd /src
slither . --triage
# An interactive prompt will be invoked for suppressing the warnings
A new slither.db.json will be created and should be commited.
Echidna fuzzer
To launch echidna fuzzer, first cd into the core directory.
The primary license for Platypus Finance Core v1 is the Business Source License 1.1 (BUSL-1.1), see LICENSE.
The Hummus protocol is a single-side Automated Market Maker designed for exchanging stable cryptocurrencies on the Metis blockchain. Hummus is an authorized fork of Platypus Finance
OwnableUpgradeable :
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.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
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.
PausableUpgradeable :
Contract module which allows children to implement an emergency stop mechanism that can be triggered by an authorized account. This module is used through inheritance. It will make available the modifiers `whenNotPaused` and `whenPaused`, which can be applied to the functions of your contract. Note that they will not be pausable by simply including this module, only once the modifiers are put in place.
Paused(address) :
Emitted when the pause is triggered by `account`.
Unpaused(address) :
Emitted when the pause is lifted by `account`.
paused() :
Returns true if the contract is paused, and false otherwise.
ReentrancyGuardUpgradeable :
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].
ERC20Upgradeable :
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 Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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`.
IERC20Upgradeable :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `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.
IERC20MetadataUpgradeable :
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 `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.
SafeERC20Upgradeable :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
AddressUpgradeable :
Collection of functions related to the address type
ContextUpgradeable :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
AccessControl :
Contract module that allows children to implement role-based access control mechanisms. This is a lightweight version that doesn't allow enumerating role members except through off-chain means by accessing the contract event logs. Some applications may benefit from on-chain enumerability, for those cases see {AccessControlEnumerable}. 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.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_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.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
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 anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
TimelockController :
Contract module which acts as a timelocked controller. When set as the owner of an `Ownable` smart contract, it enforces a timelock on all `onlyOwner` maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied. By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations. A common use case is to position this {TimelockController} as the owner of a smart contract, with a multisig or a DAO as the sole proposer. _Available since v3.3._
Execute an (ready) operation containing a batch of transactions. Emits one {CallExecuted} event per transaction in the batch. Requirements: - the caller must have the 'executor' role.
getMinDelay() :
Returns the minimum delay for an operation to become valid. This value can be changed by executing an operation that calls `updateDelay`.
getRoleAdmin(bytes32) :
Returns the admin role that controls `role`. See {grantRole} and {revokeRole}. To change a role's admin, use {_setRoleAdmin}.
getTimestamp(bytes32) :
Returns the timestamp at with an operation becomes ready (0 for unset operations, 1 for done operations).
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`.
Returns the identifier of an operation containing a batch of transactions.
isOperation(bytes32) :
Returns whether an id correspond to a registered operation. This includes both Pending, Ready and Done operations.
isOperationDone(bytes32) :
Returns whether an operation is done or not.
isOperationPending(bytes32) :
Returns whether an operation is pending or not.
isOperationReady(bytes32) :
Returns whether an operation is ready or not.
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.
Schedule an operation containing a batch of transactions. Emits one {CallScheduled} event per transaction in the batch. Requirements: - the caller must have the 'proposer' role.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
updateDelay(uint256) :
Changes the minimum timelock duration for future operations. Emits a {MinDelayChange} event. Requirements: - the caller must be the timelock itself. This can only be achieved by scheduling and later executing an operation where the timelock is the target and the data is the ABI-encoded call to this function.
ReentrancyGuard :
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].
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. 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 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `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 `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.
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
Address :
Collection of functions related to the address type
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
Strings :
String operations.
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.
AggregateAccount :
Aggregate Account has to be set for Asset
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Asset :
Expect to be owned by Timelock for management, and _pool links to Pool for coordination
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
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.
initialize(address,string,string,address) :
_ suffix to avoid shadowing underlyingToken() name and symbolmax decimal points for underlying token is 18.
name() :
Returns the name of the token.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
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`.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
transferUnderlyingToken(address,uint256) :
Not to be confused with transferring platypus Assets.
Core :
Uses DSMath to compute using WAD and RAY.
Pool :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. + Added recover user funds (for funds mistakingly sent to this contract) + Added view function for eqCovRatio
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getEquilibriumCoverageRatio() :
[ sum of Ai * fi / sum Li * fi ]
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolAAvaxC :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added aAvaxc state variable and setaAvaxc() function adjusted pricicing feed to get rate from aAVAXc StakedAvax contract Mainnet : Can only handle WAVAX and aAVAXc
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSAvax :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added sAVAX state variable and setSAvax() function adjusted pricicing feed to get rate from BenQI StakedAvax contract Mainnet : 0x2b2C81e08f1Af8835a78Bb2A90AE924ACE0eA4bE Can only handle WAVAX and sAVAX
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSecondary :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolSecondaryPure :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits pure means no external oracle is consulted and it always assumes 1:1 peg is maintained.
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
initialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
PoolYYAvax :
The main entry-point of Platypus protocol Note The Pool is ownable and the owner wields power. Note The ownership will be transferred to a governance contract once Platypus community can show to govern itself. The unique features of the Platypus make it an important subject in the study of evolutionary biology. Changes: removed impairment loss/gain on withdrawals/deposits removed _checkPriceDeviation (chainlink peg check) added weth and wethforwarder added swapFromETH, swapToETH, depositETH, withdrawETH added yyAvax state variable and setyyAvax() function adjusted pricicing feed to get rate from YY StakedAvax contract Mainnet : 0xf7d9281e8e363584973f946201b82ba72c965d27 Can only handle WAVAX and yyAvax
assetOf(address) :
to be used externally
deposit(address,uint256,address,uint256) :
Asset needs to be created and added to pool before any operation
getTokenAddresses() :
To be used externally
owner() :
Returns the address of the current owner.
pause() :
pause pool, restricting certain operations
paused() :
Returns true if the contract is paused, and false otherwise.
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
supports weth assetsinitialToken and wantedToken assets' must be in the same aggregateAlso, cov of wantedAsset must be higher than 1 after withdrawal for this to be accepted
WETHForwarder :
Unwraps and forwards actual AVAX to userAllows transfer of WAVAX (called `weth` here).
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PlatypusRouter01 :
Owner is allowed and required to approve token spending by pools via approveSpendingByPool function
approveSpendingByPool(address[],address) :
needs to be done after asset deployment for router to be able to support the tokens
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PlatypusRouter02 :
Owner is allowed and required to approve token spending by pools via approveSpendingByPool function Edits: fixed haircut calculation
approveSpendingByPool(address[],address) :
needs to be done after asset deployment for router to be able to support the tokens
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions anymore. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby removing any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Hummus Exchange
