-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: Sharable interface for Borrowing #6882
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,112 @@ | ||||||||
--- | ||||||||
eip: 6882 | ||||||||
title: Sharable interface for Borrowing | ||||||||
description: Defines interface for borrowing from a defi pool | ||||||||
author: 0xbakuchi (@massun-onibakuchi), Takeru Natsui(@cotoneum), Brian Ko (@briankostar) | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||
discussions-to: https://ethereum-magicians.org/t/eip-5313-light-contract-ownership/10052 | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This |
||||||||
status: Draft | ||||||||
type: Standards Track | ||||||||
category: ERC | ||||||||
created: 2023-08-15 | ||||||||
--- | ||||||||
|
||||||||
## Abstract | ||||||||
|
||||||||
This EIP proposes a standard API for borrowing tokens from lending protocols and introduces a borrowing aggregator that provides users with optimal borrowing paths across multiple lending protocols. | ||||||||
|
||||||||
## Motivation | ||||||||
|
||||||||
Many lending protocols in the DeFi ecosystem share common features, and creating a standard API will simplify the process of building applications that interact with these protocols. Borrowing aggregators can provide users with lower borrow APRs and higher supply APRs, improving the overall user experience. | ||||||||
|
||||||||
## Specification | ||||||||
|
||||||||
The key word “MUST” in this document is to be interpreted as described in RFC 2119. | ||||||||
|
||||||||
Every contract compliant with this EIP MUST implement the `EIP6882` interface. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||
|
||||||||
```solidity | ||||||||
interface ILendingMarket { | ||||||||
/** | ||||||||
* @notice Supplies an `amount` of underlying asset into the reserve, receiving in return overlying interest-bearing tokens. | ||||||||
* - E.g. User supplies 100 USDC and gets in return 100 / price interest-bearing USDC | ||||||||
* @param asset The address of the underlying asset to supply | ||||||||
* @param amount The amount to be supplied | ||||||||
* @param receiver The address that will receive the interest-bearing tokens, same as msg.sender if the user | ||||||||
* wants to receive them on his own wallet, or a different address if the beneficiary of interest-bearing tokens | ||||||||
* is a different wallet | ||||||||
*/ | ||||||||
function supply(address asset, uint256 amount, address receiver) external returns (uint256); | ||||||||
|
||||||||
/** | ||||||||
* @notice Withdraws an `amount` of underlying asset from the reserve, burning the equivalent interest-bearing tokens owned | ||||||||
* E.g. User has 100 interest-bearing USDC, calls withdraw() and receives 100 * price USDC, burning the 100 interest-bearing USDC | ||||||||
* @param asset The address of the underlying asset to withdraw | ||||||||
* @param amount The underlying amount to be withdrawn | ||||||||
* @param receiver The address that will receive the underlying, same as msg.sender if the user | ||||||||
* wants to receive it on his own wallet, or a different address if the beneficiary is a | ||||||||
* different wallet | ||||||||
* @return The final amount withdrawn | ||||||||
*/ | ||||||||
function withdraw(address asset, uint256 amount, address receiver) external returns (uint256); | ||||||||
|
||||||||
/** | ||||||||
* @notice Allows users to borrow a specific `amount` of the reserve underlying asset, provided that the borrower | ||||||||
* already supplied enough collateral, or he was given enough allowance by a credit delegator on the | ||||||||
* corresponding debt token | ||||||||
* - E.g. User borrows 100 USDC passing as `receiver` his own address, receiving the 100 USDC in his wallet | ||||||||
* and 100 debt tokens | ||||||||
* @param asset The address of the underlying asset to borrow | ||||||||
* @param amount The amount to be borrowed | ||||||||
* @param receiver The address of the user who will receive the debt. Should be the address of the borrower itself | ||||||||
* calling the function if he wants to borrow against his own collateral, or the address of the credit delegator | ||||||||
* if he has been given credit delegation allowance | ||||||||
*/ | ||||||||
function borrow(address asset, uint256 amount, address receiver, address owner) external returns (uint256); | ||||||||
|
||||||||
/** | ||||||||
* @notice Repays a borrowed `amount` on a specific reserve, burning the equivalent debt tokens owned | ||||||||
* @param asset The address of the borrowed underlying asset previously borrowed | ||||||||
* @param amount The amount to repay | ||||||||
* @param onBehalfOf The address of the user who will get his debt reduced/removed. Should be the address of the | ||||||||
* user calling the function if he wants to reduce/remove his own debt, or the address of any other | ||||||||
* other borrower whose debt should be removed | ||||||||
* @return The final amount repaid | ||||||||
*/ | ||||||||
function repay(address asset, uint256 amount, address onBehalfOf) external returns (uint256); | ||||||||
|
||||||||
/* | ||||||||
* Allow third party accounts to borrow tokens on behalf of the owner. | ||||||||
* @param delegatee The address of the third party account to allow | ||||||||
* @param allowed True if the delegatee is allowed to borrow tokens on behalf of the owner, false otherwise | ||||||||
*/ | ||||||||
function allow(address delegatee, bool allowed) external; | ||||||||
|
||||||||
/* | ||||||||
* Returns true if the delegatee is allowed to borrow tokens on behalf of the owner. | ||||||||
* @param owner The address of the owner | ||||||||
* @param account The address of the delegatee | ||||||||
*/ | ||||||||
function isAllowed(address owner, address account) external view returns (bool); | ||||||||
} | ||||||||
|
||||||||
``` | ||||||||
|
||||||||
## Rationale | ||||||||
|
||||||||
The rationale behind creating a standard API for borrowing tokens is to improve the user and developer experience when interacting with lending protocols. By providing a borrowing aggregator, users can access aggregated data from multiple lending protocols in a single place and easily move funds between them to achieve the best borrowing rates. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph belongs in the Motivation section. The Rationale section should justify individual technical choices made within the proposal itself (eg. why |
||||||||
|
||||||||
## Backwards Compatibility | ||||||||
|
||||||||
This proposal is designed to be compatible with major lending protocols, such as Aave V2/V3 and Compound V3. However, it may not support some protocols like Compound V2 and Morpho, due to significant differences in their interfaces and the lack of support for 'credit delegation' parameters. | ||||||||
|
||||||||
## Test Cases | ||||||||
|
||||||||
Test cases for the proposed EIP will be provided in a well-written test template for contracts that comply with the standard. | ||||||||
Comment on lines
+102
to
+104
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
You can omit this section for now, and put it back when you add your tests cases to the |
||||||||
|
||||||||
## Security Considerations | ||||||||
|
||||||||
By providing a well-written test template for contracts that comply with the standard, the security of the contracts can be improved, leading to better user experience and higher overall security. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
The paragraph currently here doesn't really provide any new information or considerations that isn't already well-known in the smart contract community. If you have specific considerations, do list them here. |
||||||||
|
||||||||
## Copyright | ||||||||
|
||||||||
Copyright and related rights waived via [CC0](../LICENSE.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.