Earn interest, borrow assets, and build applications
GPv2SafeERC20 :
Gas-efficient version of Openzeppelin's SafeERC20 contract.
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}.
Address :
Collection of functions related to the address type
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}.
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 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}, 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`.
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.
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.
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.
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.
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.
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.
Strings :
String operations.
AdminUpgradeabilityProxy :
Extends from BaseAdminUpgradeabilityProxy with a constructor for initializing the implementation, admin, and init data.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
BaseAdminUpgradeabilityProxy :
This contract combines an upgradeability proxy with an authorization mechanism for administrative tasks. All external functions in this contract must be guarded by the `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity feature proposal that would enable this to be done automatically.
AdminChanged(address,address) :
Emitted when the administration has been transferred.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
BaseUpgradeabilityProxy :
This contract implements a proxy that allows to change the implementation address to which it will delegate. Such a change is called an implementation upgrade.
Upgraded(address) :
Emitted when the implementation is upgraded.
Initializable :
Helper contract to support initializer functions. To use it, replace the constructor with a function that has the `initializer` modifier. WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors.
InitializableAdminUpgradeabilityProxy :
Extends from BaseAdminUpgradeabilityProxy with an initializer for initializing the implementation, admin, and init data.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
initialize(address,bytes) :
Contract initializer.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
InitializableUpgradeabilityProxy :
Extends BaseUpgradeabilityProxy with an initializer for initializing implementation and init data.
initialize(address,bytes) :
Contract initializer.
Proxy :
Implements delegation of calls to other contracts, with proper forwarding of return values and bubbling of failures. It defines a fallback function that delegates all calls to the address returned by the abstract _implementation() internal function.
UpgradeabilityProxy :
Extends BaseUpgradeabilityProxy with a constructor for initializing implementation and init data.
constructor :
Contract constructor.
ReservesSetupHelper :
The ReservesSetupHelper is an Ownable contract, so only the deployer or future owners can call this contract.
The Pool or Risk admin must transfer the ownership to ReservesSetupHelper before calling this function
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.
IFlashLoanReceiver :
Implement this interface to develop a flashloan-compatible flashLoanReceiver contract
Ensure that the contract can return the debt + premium, e.g., has enough funds to repay and has approved the Pool to pull the total amount
IAaveIncentivesController :
It only contains one single function, needed as a hook on aToken and debtToken transfers.
handleAction(address,uint256,uint256) :
Called by the corresponding asset on transfer hook in order to update the rewards distribution.The units of `totalSupply` and `userBalance` should be the same.
IStableDebtToken :
It does not inherit from IERC20 to save in code size
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debtIn some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest the user earned
mint(address,address,uint256,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debt
ZeroReserveInterestRateStrategy :
It returns zero liquidity and borrow rate.
constructor :
Constructor.
getStableRateExcessOffset() :
It's an additional premium applied to the stable when stable debt > OPTIMAL_STABLE_TO_TOTAL_DEBT_RATIO
getStableRateSlope1() :
It's the stable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getStableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
getVariableRateSlope1() :
It's the variable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getVariableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
MintableDelegationERC20 :
ERC20 minting logic with delegation
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 {_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.
mint(uint256) :
Function to mint tokens
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`.
MintableERC20 :
ERC20 minting logic
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 {_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.
implements the permit function as for https://github.com/ethereum/EIPs/blob/8a34d644aacf0f9f8f00815307fd7dd5da07655f/EIPS/eip-2612.md
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`.
PoolAddressesProvider :
Acts as factory of proxies and admin of those, so with right to change its implementationsOwned by the Aave Governance
constructor :
Constructor.
getAddress(bytes32) :
The returned address might be an EOA or a contract, potentially proxiedIt returns ZERO if there is no registered address with the given id
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.
setAddress(bytes32,address) :
IMPORTANT Use this function carefully, as it will do a hard replacement
setAddressAsProxy(bytes32,address) :
IMPORTANT Use this function carefully, only for ids that don't have an explicit setter function, in order to avoid unexpected consequences
setMarketId(string) :
This can be used to create an onchain registry of PoolAddressesProviders to identify and validate multiple Aave markets.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PoolAddressesProviderRegistry :
Used for indexing purposes of Aave protocol's markets. The id assigned to a PoolAddressesProvider refers to the market it is connected with, for example with `1` for the Aave main market and `2` for the next created.
constructor :
Constructor.
owner() :
Returns the address of the current owner.
registerAddressesProvider(address,uint256) :
The PoolAddressesProvider must not already be registered in the registryThe id must not be used by an already registered PoolAddressesProvider
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.
PriceOracleSentinel :
Once the PriceOracle gets up after an outage/downtime, users can make their positions healthy during a grace period. So the PriceOracle is considered completely up once its up and the grace period passed.
constructor :
Constructor
isBorrowAllowed() :
Operation not allowed when PriceOracle is down or grace period not passed.
isLiquidationAllowed() :
Operation not allowed when PriceOracle is down or grace period not passed.
BaseImmutableAdminUpgradeabilityProxy :
The admin role is stored in an immutable, which helps saving transactions costs All external functions in this contract must be guarded by the `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity feature proposal that would enable this to be done automatically.
constructor :
Constructor.
upgradeTo(address) :
Only the admin can call this function.
upgradeToAndCall(address,bytes) :
This is useful to initialize the proxied contract.
InitializableImmutableAdminUpgradeabilityProxy :
Extends BaseAdminUpgradeabilityProxy with an initializer function
constructor :
Constructor.
initialize(address,bytes) :
Contract initializer.
upgradeTo(address) :
Only the admin can call this function.
upgradeToAndCall(address,bytes) :
This is useful to initialize the proxied contract.
VersionedInitializable :
WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors.
PercentageMath :
Percentages are defined by default with 2 decimals of precision (100.00). The precision is indicated by PERCENTAGE_FACTOROperations are rounded. If a value is >=.5, will be rounded up, otherwise rounded down.
WadRayMath :
Provides mul and div function for wads (decimal numbers with 18 digits of precision) and rays (decimal numbers with 27 digits of precision)Operations are rounded. If a value is >=.5, will be rounded up, otherwise rounded down.
DefaultReserveInterestRateStrategy :
The model of interest rate is based on 2 slopes, one before the `OPTIMAL_USAGE_RATIO` point of usage and another from that one to 100%. - An instance of this same contract, can't be used across different Aave markets, due to the caching of the PoolAddressesProvider
constructor :
Constructor.
getStableRateExcessOffset() :
It's an additional premium applied to the stable when stable debt > OPTIMAL_STABLE_TO_TOTAL_DEBT_RATIO
getStableRateSlope1() :
It's the stable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getStableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
getVariableRateSlope1() :
It's the variable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getVariableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
Pool :
To be covered by a proxy contract, owned by the PoolAddressesProvider of the specific marketAll admin functions are callable by the PoolConfigurator contract defined also in the PoolAddressesProvider
In eMode, the protocol allows very high borrowing power to borrow assets of the same category. The category 0 is reserved as it's the default for volatile assets
IMPORTANT There are security concerns for developers of flashloan receiver contracts that must be kept into consideration. For further details please visit https://docs.aave.com/developers/
IMPORTANT There are security concerns for developers of flashloan receiver contracts that must be kept into consideration. For further details please visit https://docs.aave.com/developers/
getReserveNormalizedVariableDebt(address) :
WARNING: This function is intended to be used primarily by the protocol itself to get a "dynamic" variable index based on time, current stored index and virtual rate at the current moment (approx. a borrower would get if opening a position). This means that is always used in combination with variable debt supply/balances. If using this function externally, consider that is possible to have an increasing normalized variable debt that is not equivalent to how the variable debt index would be updated in storage (e.g. only updates with non-zero variable debt supply)
Function is invoked by the proxy contract when the Pool contract is added to the PoolAddressesProvider of the market.Caching the address of the PoolAddressesProvider in order to reduce gas consumption on subsequent operations
repayWithATokens(address,uint256,uint256) :
Passing uint256.max as amount will clean up any residual aToken dust balance, if the user aToken balance is not enough to cover the whole debt
The total premium is calculated on the total borrowed amountThe premium to protocol is calculated on the total premium, being a percentage of `flashLoanPremiumTotal`Only callable by the PoolConfigurator contract
PoolConfigurator :
Implements the configuration methods for the Aave protocol
All the values are expressed in bps. A value of 10000, results in 100.00%The `liquidationBonus` is always above 100%. A value of 105% means the liquidator will receive a 5% bonus
setBorrowableInIsolation(address,bool) :
When this flag is set to true, the asset will be borrowable against isolated collaterals and the borrowed amount will be accumulated in the isolated collateral's total debt exposureOnly assets of the same family (e.g. USD stablecoins) should be borrowable in isolation mode to keep consistency in the debt ceiling calculations
If zero is provided as oracle address, the default asset oracles will be used to compute the overall debt and overcollateralization of the users using this category.The new ltv and liquidation threshold must be greater than the base ltvs and liquidation thresholds of all assets within the eMode category
setReserveBorrowing(address,bool) :
Can only be disabled (set to false) if stable borrowing is disabled
setReserveStableRateBorrowing(address,bool) :
Can only be enabled (set to true) if borrowing is enabled
Updates the aToken implementation for the reserve.
updateFlashloanPremiumToProtocol(uint128) :
Expressed in bpsThe premium to protocol is calculated on the total flashloan premium
updateFlashloanPremiumTotal(uint128) :
Expressed in bpsThe premium is calculated on the total amount borrowed
PoolStorage :
It defines the storage layout of the Pool contract.
DelegationAwareAToken :
The underlying asset needs to be compatible with the COMP delegation interface
DelegateUnderlyingTo(address) :
Emitted when underlying voting power is delegated
DOMAIN_SEPARATOR() :
Overrides the base function to fully implement IATokensee `EIP712Base.DOMAIN_SEPARATOR()` for more detailed documentation
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`.
burn(address,address,uint256,uint256) :
In some instances, the mint event could be emitted from a burn transaction if the amount to burn is less than the interest that the user accrued
constructor :
Constructor.
handleRepayment(address,address,uint256) :
The default implementation is empty as with standard ERC20 tokens, nothing needs to be done after the transfer is concluded. However in the future there may be aTokens that allow for example to stake the underlying to receive LM rewards. In that case, `handleRepayment()` would perform the staking of the underlying asset.
nonces(address) :
Overrides the base function to fully implement IATokensee `EIP712Base.nonces()` for more detailed documentation
implements the permit function as for https://github.com/ethereum/EIPs/blob/8a34d644aacf0f9f8f00815307fd7dd5da07655f/EIPS/eip-2612.md
scaledBalanceOf(address) :
The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update
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.
transferUnderlyingTo(address,uint256) :
Used by the Pool to transfer assets in borrow(), withdraw() and flashLoan()
StableDebtToken :
Transfer and approve functionalities are disabled since its a non-transferable token
DOMAIN_SEPARATOR() :
Return cached value if chainId matches cache, otherwise recomputes separator
balanceOf(address) :
Returns the amount of tokens owned by `account`.
burn(address,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debtIn some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest the user earned
constructor :
Constructor.
mint(address,address,uint256,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debt
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Being non transferrable, the debt token does not implement any of the standard ERC20 functions for transfer and allowance.
VariableDebtToken :
Transfer and approve functionalities are disabled since its a non-transferable token
DOMAIN_SEPARATOR() :
Return cached value if chainId matches cache, otherwise recomputes separator
balanceOf(address) :
Returns the amount of tokens owned by `account`.
burn(address,uint256,uint256) :
In some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest that the user accrued
constructor :
Constructor.
scaledBalanceOf(address) :
The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Being non transferrable, the debt token does not implement any of the standard ERC20 functions for transfer and allowance.
This repository contains the smart contracts source code and markets configuration for Aave Protocol V3. The repository uses Docker Compose and Hardhat as development environment for compilation, testing and deployment tasks.
What is Aave?
Aave is a decentralized non-custodial liquidity markets protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) or undercollateralized (one-block liquidity) fashion.
Documentation
See the link to the technical paper or visit the Aave Developer docs
You can join the Discord channel or the Governance Forum to ask questions about the protocol or talk about Aave with other peers.
Getting Started
You can install @aave/core-v3 as an NPM package in your Hardhat or Truffle project to import the contracts and interfaces:
npm install @aave/core-v3
Import at Solidity files:
import {IPool} from "@aave/core-v3/contracts/interfaces/IPool.sol";
contract Misc {
function supply(address pool, address token, address user, uint256 amount) public {
IPool(pool).supply(token, amount, user, 0);
{...}
}
}
The JSON artifacts with the ABI and Bytecode are also included in the bundled NPM package at artifacts/ directory.
Import JSON file via Node JS require:
const PoolV3Artifact = require('@aave/core-v3/artifacts/contracts/protocol/pool/Pool.sol/Pool.json');
// Log the ABI into console
console.log(PoolV3Artifact.abi)
Setup
The repository uses Docker Compose to manage sensitive keys and load the configuration. Prior to any action like test or deploy, you must run docker-compose up to start the contracts-env container, and then connect to the container console via docker-compose exec contracts-env bash.
Follow the next steps to setup the repository:
Install docker and docker-compose
Create an environment file named .env and fill the next environment variables
# Add Alchemy or Infura provider keys, alchemy takes preference at the config level
ALCHEMY_KEY=""
INFURA_KEY=""
# Optional, if you plan to use Tenderly scripts
TENDERLY_PROJECT=""
TENDERLY_USERNAME=""
Test
You can run the full test suite with the following commands:
# In one terminal
docker-compose up
# Open another tab or terminal
docker-compose exec contracts-env bash
# A new Bash terminal is prompted, connected to the container
npm run test
Earn interest, borrow assets, and build applications
GPv2SafeERC20 :
Gas-efficient version of Openzeppelin's SafeERC20 contract.
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}.
Address :
Collection of functions related to the address type
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}.
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 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}, 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`.
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.
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.
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.
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.
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.
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.
Strings :
String operations.
AdminUpgradeabilityProxy :
Extends from BaseAdminUpgradeabilityProxy with a constructor for initializing the implementation, admin, and init data.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
BaseAdminUpgradeabilityProxy :
This contract combines an upgradeability proxy with an authorization mechanism for administrative tasks. All external functions in this contract must be guarded by the `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity feature proposal that would enable this to be done automatically.
AdminChanged(address,address) :
Emitted when the administration has been transferred.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
BaseUpgradeabilityProxy :
This contract implements a proxy that allows to change the implementation address to which it will delegate. Such a change is called an implementation upgrade.
Upgraded(address) :
Emitted when the implementation is upgraded.
Initializable :
Helper contract to support initializer functions. To use it, replace the constructor with a function that has the `initializer` modifier. WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors.
InitializableAdminUpgradeabilityProxy :
Extends from BaseAdminUpgradeabilityProxy with an initializer for initializing the implementation, admin, and init data.
changeAdmin(address) :
Changes the admin of the proxy. Only the current admin can call this function.
initialize(address,bytes) :
Contract initializer.
upgradeTo(address) :
Upgrade the backing implementation of the proxy. Only the admin can call this function.
upgradeToAndCall(address,bytes) :
Upgrade the backing implementation of the proxy and call a function on the new implementation. This is useful to initialize the proxied contract.
InitializableUpgradeabilityProxy :
Extends BaseUpgradeabilityProxy with an initializer for initializing implementation and init data.
initialize(address,bytes) :
Contract initializer.
Proxy :
Implements delegation of calls to other contracts, with proper forwarding of return values and bubbling of failures. It defines a fallback function that delegates all calls to the address returned by the abstract _implementation() internal function.
UpgradeabilityProxy :
Extends BaseUpgradeabilityProxy with a constructor for initializing implementation and init data.
constructor :
Contract constructor.
ReservesSetupHelper :
The ReservesSetupHelper is an Ownable contract, so only the deployer or future owners can call this contract.
The Pool or Risk admin must transfer the ownership to ReservesSetupHelper before calling this function
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.
IFlashLoanReceiver :
Implement this interface to develop a flashloan-compatible flashLoanReceiver contract
Ensure that the contract can return the debt + premium, e.g., has enough funds to repay and has approved the Pool to pull the total amount
IAaveIncentivesController :
It only contains one single function, needed as a hook on aToken and debtToken transfers.
handleAction(address,uint256,uint256) :
Called by the corresponding asset on transfer hook in order to update the rewards distribution.The units of `totalSupply` and `userBalance` should be the same.
IStableDebtToken :
It does not inherit from IERC20 to save in code size
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debtIn some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest the user earned
mint(address,address,uint256,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debt
ZeroReserveInterestRateStrategy :
It returns zero liquidity and borrow rate.
constructor :
Constructor.
getStableRateExcessOffset() :
It's an additional premium applied to the stable when stable debt > OPTIMAL_STABLE_TO_TOTAL_DEBT_RATIO
getStableRateSlope1() :
It's the stable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getStableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
getVariableRateSlope1() :
It's the variable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getVariableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
MintableDelegationERC20 :
ERC20 minting logic with delegation
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 {_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.
mint(uint256) :
Function to mint tokens
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`.
MintableERC20 :
ERC20 minting logic
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 {_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.
implements the permit function as for https://github.com/ethereum/EIPs/blob/8a34d644aacf0f9f8f00815307fd7dd5da07655f/EIPS/eip-2612.md
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`.
PoolAddressesProvider :
Acts as factory of proxies and admin of those, so with right to change its implementationsOwned by the Aave Governance
constructor :
Constructor.
getAddress(bytes32) :
The returned address might be an EOA or a contract, potentially proxiedIt returns ZERO if there is no registered address with the given id
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.
setAddress(bytes32,address) :
IMPORTANT Use this function carefully, as it will do a hard replacement
setAddressAsProxy(bytes32,address) :
IMPORTANT Use this function carefully, only for ids that don't have an explicit setter function, in order to avoid unexpected consequences
setMarketId(string) :
This can be used to create an onchain registry of PoolAddressesProviders to identify and validate multiple Aave markets.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
PoolAddressesProviderRegistry :
Used for indexing purposes of Aave protocol's markets. The id assigned to a PoolAddressesProvider refers to the market it is connected with, for example with `1` for the Aave main market and `2` for the next created.
constructor :
Constructor.
owner() :
Returns the address of the current owner.
registerAddressesProvider(address,uint256) :
The PoolAddressesProvider must not already be registered in the registryThe id must not be used by an already registered PoolAddressesProvider
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.
PriceOracleSentinel :
Once the PriceOracle gets up after an outage/downtime, users can make their positions healthy during a grace period. So the PriceOracle is considered completely up once its up and the grace period passed.
constructor :
Constructor
isBorrowAllowed() :
Operation not allowed when PriceOracle is down or grace period not passed.
isLiquidationAllowed() :
Operation not allowed when PriceOracle is down or grace period not passed.
BaseImmutableAdminUpgradeabilityProxy :
The admin role is stored in an immutable, which helps saving transactions costs All external functions in this contract must be guarded by the `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity feature proposal that would enable this to be done automatically.
constructor :
Constructor.
upgradeTo(address) :
Only the admin can call this function.
upgradeToAndCall(address,bytes) :
This is useful to initialize the proxied contract.
InitializableImmutableAdminUpgradeabilityProxy :
Extends BaseAdminUpgradeabilityProxy with an initializer function
constructor :
Constructor.
initialize(address,bytes) :
Contract initializer.
upgradeTo(address) :
Only the admin can call this function.
upgradeToAndCall(address,bytes) :
This is useful to initialize the proxied contract.
VersionedInitializable :
WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors.
PercentageMath :
Percentages are defined by default with 2 decimals of precision (100.00). The precision is indicated by PERCENTAGE_FACTOROperations are rounded. If a value is >=.5, will be rounded up, otherwise rounded down.
WadRayMath :
Provides mul and div function for wads (decimal numbers with 18 digits of precision) and rays (decimal numbers with 27 digits of precision)Operations are rounded. If a value is >=.5, will be rounded up, otherwise rounded down.
DefaultReserveInterestRateStrategy :
The model of interest rate is based on 2 slopes, one before the `OPTIMAL_USAGE_RATIO` point of usage and another from that one to 100%. - An instance of this same contract, can't be used across different Aave markets, due to the caching of the PoolAddressesProvider
constructor :
Constructor.
getStableRateExcessOffset() :
It's an additional premium applied to the stable when stable debt > OPTIMAL_STABLE_TO_TOTAL_DEBT_RATIO
getStableRateSlope1() :
It's the stable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getStableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
getVariableRateSlope1() :
It's the variable rate when usage ratio > 0 and <= OPTIMAL_USAGE_RATIO
getVariableRateSlope2() :
It's the variable rate when usage ratio > OPTIMAL_USAGE_RATIO
Pool :
To be covered by a proxy contract, owned by the PoolAddressesProvider of the specific marketAll admin functions are callable by the PoolConfigurator contract defined also in the PoolAddressesProvider
In eMode, the protocol allows very high borrowing power to borrow assets of the same category. The category 0 is reserved as it's the default for volatile assets
IMPORTANT There are security concerns for developers of flashloan receiver contracts that must be kept into consideration. For further details please visit https://docs.aave.com/developers/
IMPORTANT There are security concerns for developers of flashloan receiver contracts that must be kept into consideration. For further details please visit https://docs.aave.com/developers/
getReserveNormalizedVariableDebt(address) :
WARNING: This function is intended to be used primarily by the protocol itself to get a "dynamic" variable index based on time, current stored index and virtual rate at the current moment (approx. a borrower would get if opening a position). This means that is always used in combination with variable debt supply/balances. If using this function externally, consider that is possible to have an increasing normalized variable debt that is not equivalent to how the variable debt index would be updated in storage (e.g. only updates with non-zero variable debt supply)
Function is invoked by the proxy contract when the Pool contract is added to the PoolAddressesProvider of the market.Caching the address of the PoolAddressesProvider in order to reduce gas consumption on subsequent operations
repayWithATokens(address,uint256,uint256) :
Passing uint256.max as amount will clean up any residual aToken dust balance, if the user aToken balance is not enough to cover the whole debt
The total premium is calculated on the total borrowed amountThe premium to protocol is calculated on the total premium, being a percentage of `flashLoanPremiumTotal`Only callable by the PoolConfigurator contract
PoolConfigurator :
Implements the configuration methods for the Aave protocol
All the values are expressed in bps. A value of 10000, results in 100.00%The `liquidationBonus` is always above 100%. A value of 105% means the liquidator will receive a 5% bonus
setBorrowableInIsolation(address,bool) :
When this flag is set to true, the asset will be borrowable against isolated collaterals and the borrowed amount will be accumulated in the isolated collateral's total debt exposureOnly assets of the same family (e.g. USD stablecoins) should be borrowable in isolation mode to keep consistency in the debt ceiling calculations
If zero is provided as oracle address, the default asset oracles will be used to compute the overall debt and overcollateralization of the users using this category.The new ltv and liquidation threshold must be greater than the base ltvs and liquidation thresholds of all assets within the eMode category
setReserveBorrowing(address,bool) :
Can only be disabled (set to false) if stable borrowing is disabled
setReserveStableRateBorrowing(address,bool) :
Can only be enabled (set to true) if borrowing is enabled
Updates the aToken implementation for the reserve.
updateFlashloanPremiumToProtocol(uint128) :
Expressed in bpsThe premium to protocol is calculated on the total flashloan premium
updateFlashloanPremiumTotal(uint128) :
Expressed in bpsThe premium is calculated on the total amount borrowed
PoolStorage :
It defines the storage layout of the Pool contract.
DelegationAwareAToken :
The underlying asset needs to be compatible with the COMP delegation interface
DelegateUnderlyingTo(address) :
Emitted when underlying voting power is delegated
DOMAIN_SEPARATOR() :
Overrides the base function to fully implement IATokensee `EIP712Base.DOMAIN_SEPARATOR()` for more detailed documentation
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`.
burn(address,address,uint256,uint256) :
In some instances, the mint event could be emitted from a burn transaction if the amount to burn is less than the interest that the user accrued
constructor :
Constructor.
handleRepayment(address,address,uint256) :
The default implementation is empty as with standard ERC20 tokens, nothing needs to be done after the transfer is concluded. However in the future there may be aTokens that allow for example to stake the underlying to receive LM rewards. In that case, `handleRepayment()` would perform the staking of the underlying asset.
nonces(address) :
Overrides the base function to fully implement IATokensee `EIP712Base.nonces()` for more detailed documentation
implements the permit function as for https://github.com/ethereum/EIPs/blob/8a34d644aacf0f9f8f00815307fd7dd5da07655f/EIPS/eip-2612.md
scaledBalanceOf(address) :
The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update
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.
transferUnderlyingTo(address,uint256) :
Used by the Pool to transfer assets in borrow(), withdraw() and flashLoan()
StableDebtToken :
Transfer and approve functionalities are disabled since its a non-transferable token
DOMAIN_SEPARATOR() :
Return cached value if chainId matches cache, otherwise recomputes separator
balanceOf(address) :
Returns the amount of tokens owned by `account`.
burn(address,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debtIn some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest the user earned
constructor :
Constructor.
mint(address,address,uint256,uint256) :
The resulting rate is the weighted average between the rate of the new debt and the rate of the previous debt
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Being non transferrable, the debt token does not implement any of the standard ERC20 functions for transfer and allowance.
VariableDebtToken :
Transfer and approve functionalities are disabled since its a non-transferable token
DOMAIN_SEPARATOR() :
Return cached value if chainId matches cache, otherwise recomputes separator
balanceOf(address) :
Returns the amount of tokens owned by `account`.
burn(address,uint256,uint256) :
In some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest that the user accrued
constructor :
Constructor.
scaledBalanceOf(address) :
The scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Being non transferrable, the debt token does not implement any of the standard ERC20 functions for transfer and allowance.
Aave V3
