From 989bee88bbda64037ccb043695dd0f67da226f48 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:36:42 +0200 Subject: [PATCH 01/12] first draft of the Slippage protection for Tokenized Vault ERC --- EIPS/eip-XXXX.md | 205 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 EIPS/eip-XXXX.md diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md new file mode 100644 index 00000000000000..c409874ccb30bc --- /dev/null +++ b/EIPS/eip-XXXX.md @@ -0,0 +1,205 @@ +--- +eip: XXX +title: Slippage protection for Tokenized Vault +description: An extension of the ERC-4626 standard for improve EOA interactions. +author: Hadrien Croubois (@amxx) +discussions-to: https://ethereum-magicians.org/t/eip-4626-yield-bearing-vault-standard/7900 +status: Draft +type: Standards Track +category: ERC +created: 2022-06-09 +requires: 4626 +--- + +## Abstract + +The following standard extends the ERC-4626 Tokenized Vault standard with functions dedicated to the safe interaction between EOAs and the vault when price is subject to slippage. + +## Motivation + +[ERC-4626](./eip-4626.md) security considerations section state that: +> "If implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits, since they have no other means to revert the transaction if the exact output amount is not achieved." + +Yes, ERC-4626 does not standardize the corresponding functions signature and behavior. For improved interroperability, and better support by wallets, it is essential that this optional functions are also standardized. + +## Specification + +ERC-XXX is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. + +### Methods + +#### deposit + +Overloaded version of ERC-4626's `deposit` + +Mints `shares` Vault shares to `receiver` by depositing exactly `amount` of underlying tokens. + +MUST emit the `Deposit` event. + +MUST support ERC-20 `approve` / `transferFrom` on `asset` as a deposit flow. +MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the `deposit` execution, and are accounted for during `deposit`. + +MUST revert if all of `assets` cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). +MUST revert if depositing `assets` underlying asset mints less then `minShares` shares + +Note that most implementations will require pre-approval of the Vault with the Vault's underlying `asset` token. + +```yaml +- name: deposit + type: function + stateMutability: nonpayable + + inputs: + - name: assets + type: uint256 + - name: receiver + type: address + - name: minShares + type: uint256 + + outputs: + - name: shares + type: uint256 +``` + +#### mint + +Overloaded version of ERC-4626's `mint` + +Mints exactly `shares` Vault shares to `receiver` by depositing `amount` of underlying tokens. + +MUST emit the `Deposit` event. + +MUST support ERC-20 `approve` / `transferFrom` on `asset` as a mint flow. +MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the `mint` execution, and are accounted for during `mint`. + +MUST revert if all of `shares` cannot be minted (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). +MUST revert if minting `amount` shares cost more then `maxAssets` shares + +Note that most implementations will require pre-approval of the Vault with the Vault's underlying `asset` token. + +```yaml +- name: mint + type: function + stateMutability: nonpayable + + inputs: + - name: shares + type: uint256 + - name: receiver + type: address + - name: maxAssets + type: uint256 + + outputs: + - name: assets + type: uint256 +``` + +#### withdraw + +Overloaded version of ERC-4626's `withdraw` + +Burns `shares` from `owner` and sends exactly `assets` of underlying tokens to `receiver`. + +MUST emit the `Withdraw` event. + +MUST support a withdraw flow where the shares are burned from `owner` directly where `owner` is `msg.sender` or `msg.sender` has ERC-20 approval over the shares of `owner`. +MAY support an additional flow in which the shares are transferred to the Vault contract before the `withdraw` execution, and are accounted for during `withdraw`. + +MUST revert if all of `assets` cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). +MUST revert if withdrawing `assets` underlying tokens requires burning more then `maxShares` shares + +Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately. + +```yaml +- name: withdraw + type: function + stateMutability: nonpayable + + inputs: + - name: assets + type: uint256 + - name: receiver + type: address + - name: owner + type: address + - name: maxShares + type: uint256 + + outputs: + - name: shares + type: uint256 +``` + +#### redeem + +Overloaded version of ERC-4626's `redeem` + +Burns exactly `shares` from `owner` and sends `assets` of underlying tokens to `receiver`. + +MUST emit the `Withdraw` event. + +MUST support a redeem flow where the shares are burned from `owner` directly where `owner` is `msg.sender` or `msg.sender` has ERC-20 approval over the shares of `owner`. +MAY support an additional flow in which the shares are transferred to the Vault contract before the `redeem` execution, and are accounted for during `redeem`. + +MUST revert if all of `shares` cannot be redeemed (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). +MUST revert if redeeming `shares` shares sends less than `minAssets` shares + +Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately. + +```yaml +- name: redeem + type: function + stateMutability: nonpayable + + inputs: + - name: shares + type: uint256 + - name: receiver + type: address + - name: owner + type: address + - name: minAssets + type: uint256 + + outputs: + - name: assets + type: uint256 +``` + +## Rationale + +ERC-XXXX's function do not replace ERC-4626's equivalent mechanism. They are additional mechanism designed to protect EOA interracting with the Vault. + +When smart contract interract with an ERC-4626 vault, they can preview any operation using the dedicated functions and then execute the operation, all +atomically, with no risk of price change. This is not true of EOA, which will preview their operation on a UI, sign a transaction, and see it mined later. +Between the preview and the transaction being executed, the blockchain state might change, resulting in unexpected outcomes. In particular, frontrunning +make EOA's interracton with an ERC-4626 vault possibly risky. + +Other projects in the DeFi spaces, such as decentralized exchanges, already include similar mechanisms so a user can request its transaction reverts if the +resulting exchange rate is not considered good enough. + +Implementing ERC-XXXX on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert +check on the returned value. + +## Backwards Compatibility + +ERC-XXXX is fully backward compatible with the ERC-4626 and ERC-20 standards and has no known compatibility issues with other standards. + +## Reference Implementations + +TODO + + + + + + +## Security Considerations + +This ERC addresses one of the security consideration raised by ERC-4626. Other consideration still apply. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 1ab43e731abd4b63814bab2386747f053dbd1aa8 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:38:15 +0200 Subject: [PATCH 02/12] =?UTF-8?q?renaming=20XXX=20=E2=86=92=205143?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- EIPS/eip-XXXX.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index c409874ccb30bc..500c45b08420a5 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -1,5 +1,5 @@ --- -eip: XXX +eip: 5143 title: Slippage protection for Tokenized Vault description: An extension of the ERC-4626 standard for improve EOA interactions. author: Hadrien Croubois (@amxx) @@ -24,7 +24,7 @@ Yes, ERC-4626 does not standardize the corresponding functions signature and beh ## Specification -ERC-XXX is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. +ERC-5143 is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. ### Methods @@ -170,7 +170,7 @@ Note that some implementations will require pre-requesting to the Vault before a ## Rationale -ERC-XXXX's function do not replace ERC-4626's equivalent mechanism. They are additional mechanism designed to protect EOA interracting with the Vault. +ERC-5143's functions do not replace ERC-4626's equivalent mechanism. They are additional mechanism designed to protect EOA interracting with the Vault. When smart contract interract with an ERC-4626 vault, they can preview any operation using the dedicated functions and then execute the operation, all atomically, with no risk of price change. This is not true of EOA, which will preview their operation on a UI, sign a transaction, and see it mined later. @@ -180,12 +180,12 @@ make EOA's interracton with an ERC-4626 vault possibly risky. Other projects in the DeFi spaces, such as decentralized exchanges, already include similar mechanisms so a user can request its transaction reverts if the resulting exchange rate is not considered good enough. -Implementing ERC-XXXX on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert +Implementing ERC-5143 on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert check on the returned value. ## Backwards Compatibility -ERC-XXXX is fully backward compatible with the ERC-4626 and ERC-20 standards and has no known compatibility issues with other standards. +ERC-5143 is fully backward compatible with the ERC-4626 and ERC-20 standards and has no known compatibility issues with other standards. ## Reference Implementations @@ -198,7 +198,7 @@ TODO ## Security Considerations -This ERC addresses one of the security consideration raised by ERC-4626. Other consideration still apply. +This ERC addresses one of the security consideration raised by ERC-4626. Other considerations still apply. ## Copyright From 5e84838a3eb36a1b1c0d3dd4380d4ff05a3bdb12 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:38:50 +0200 Subject: [PATCH 03/12] rename document --- EIPS/{eip-XXXX.md => eip-5143.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-XXXX.md => eip-5143.md} (100%) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-5143.md similarity index 100% rename from EIPS/eip-XXXX.md rename to EIPS/eip-5143.md From edf6f2247101bca5639df06c18e729d715329c7d Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:42:33 +0200 Subject: [PATCH 04/12] update link to discussion --- EIPS/eip-5143.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 500c45b08420a5..c9ac49cb01bfa8 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -3,7 +3,7 @@ eip: 5143 title: Slippage protection for Tokenized Vault description: An extension of the ERC-4626 standard for improve EOA interactions. author: Hadrien Croubois (@amxx) -discussions-to: https://ethereum-magicians.org/t/eip-4626-yield-bearing-vault-standard/7900 +discussions-to: https://ethereum-magicians.org/t/eip-5143-slippage-protection-for-tokenized-vaults/9554 status: Draft type: Standards Track category: ERC From 7cb023d45c8dc6333fc23ccb5283d12a645ea6da Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:46:43 +0200 Subject: [PATCH 05/12] spelling --- EIPS/eip-5143.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index c9ac49cb01bfa8..f7d5a96a5d99d5 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -17,10 +17,10 @@ The following standard extends the ERC-4626 Tokenized Vault standard with functi ## Motivation -[ERC-4626](./eip-4626.md) security considerations section state that: +[ERC-4626](./eip-4626.md) security considerations section states that: > "If implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits, since they have no other means to revert the transaction if the exact output amount is not achieved." -Yes, ERC-4626 does not standardize the corresponding functions signature and behavior. For improved interroperability, and better support by wallets, it is essential that this optional functions are also standardized. +Yet, ERC-4626 does not standardize the corresponding function signatures and behaviors. For improved interroperability, and better support by wallets, it is essential that this optional functions are also standardized. ## Specification @@ -170,12 +170,12 @@ Note that some implementations will require pre-requesting to the Vault before a ## Rationale -ERC-5143's functions do not replace ERC-4626's equivalent mechanism. They are additional mechanism designed to protect EOA interracting with the Vault. +ERC-5143 functions do not replace ERC-4626 equivalent mechanisms. They are additional (overloaded) methods designed to protect EOAs interracting with the vault. -When smart contract interract with an ERC-4626 vault, they can preview any operation using the dedicated functions and then execute the operation, all -atomically, with no risk of price change. This is not true of EOA, which will preview their operation on a UI, sign a transaction, and see it mined later. +When smart contracts interract with an ERC-4626 vault, they can preview any operation using the dedicated functions before executing the operation. This can be done +atomically, with no risk of price change. This is not true of EOA, which will preview their operations on a UI, sign a transaction, and have it mined later. Between the preview and the transaction being executed, the blockchain state might change, resulting in unexpected outcomes. In particular, frontrunning -make EOA's interracton with an ERC-4626 vault possibly risky. +make EOA's interractons with an ERC-4626 vault possibly risky. Other projects in the DeFi spaces, such as decentralized exchanges, already include similar mechanisms so a user can request its transaction reverts if the resulting exchange rate is not considered good enough. From d6b510d5212ff3c0dedbb5e24c3854f22af7d990 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:51:23 +0200 Subject: [PATCH 06/12] rewording --- EIPS/eip-5143.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index f7d5a96a5d99d5..433f6a0bade19d 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -30,9 +30,9 @@ ERC-5143 is an extenson of ERC-4626. Any contract implementing it MUST also impl #### deposit -Overloaded version of ERC-4626's `deposit` +Overloaded version of ERC-4626's `deposit`. -Mints `shares` Vault shares to `receiver` by depositing exactly `amount` of underlying tokens. +Mints `shares` Vault shares to `receiver` by depositing exactly `assets` of underlying tokens. MUST emit the `Deposit` event. @@ -40,7 +40,7 @@ MUST support ERC-20 `approve` / `transferFrom` on `asset` as a deposit flow. MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the `deposit` execution, and are accounted for during `deposit`. MUST revert if all of `assets` cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). -MUST revert if depositing `assets` underlying asset mints less then `minShares` shares +MUST revert if depositing `assets` underlying asset mints less then `minShares` shares. Note that most implementations will require pre-approval of the Vault with the Vault's underlying `asset` token. @@ -64,9 +64,9 @@ Note that most implementations will require pre-approval of the Vault with the V #### mint -Overloaded version of ERC-4626's `mint` +Overloaded version of ERC-4626's `mint`. -Mints exactly `shares` Vault shares to `receiver` by depositing `amount` of underlying tokens. +Mints exactly `shares` Vault shares to `receiver` by depositing `assets` of underlying tokens. MUST emit the `Deposit` event. @@ -74,7 +74,7 @@ MUST support ERC-20 `approve` / `transferFrom` on `asset` as a mint flow. MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the `mint` execution, and are accounted for during `mint`. MUST revert if all of `shares` cannot be minted (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). -MUST revert if minting `amount` shares cost more then `maxAssets` shares +MUST revert if minting `shares` shares cost more then `maxAssets` underlying tokens. Note that most implementations will require pre-approval of the Vault with the Vault's underlying `asset` token. @@ -98,7 +98,7 @@ Note that most implementations will require pre-approval of the Vault with the V #### withdraw -Overloaded version of ERC-4626's `withdraw` +Overloaded version of ERC-4626's `withdraw`. Burns `shares` from `owner` and sends exactly `assets` of underlying tokens to `receiver`. @@ -108,7 +108,7 @@ MUST support a withdraw flow where the shares are burned from `owner` directly w MAY support an additional flow in which the shares are transferred to the Vault contract before the `withdraw` execution, and are accounted for during `withdraw`. MUST revert if all of `assets` cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). -MUST revert if withdrawing `assets` underlying tokens requires burning more then `maxShares` shares +MUST revert if withdrawing `assets` underlying tokens requires burning more then `maxShares` shares. Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately. @@ -134,7 +134,7 @@ Note that some implementations will require pre-requesting to the Vault before a #### redeem -Overloaded version of ERC-4626's `redeem` +Overloaded version of ERC-4626's `redeem`. Burns exactly `shares` from `owner` and sends `assets` of underlying tokens to `receiver`. @@ -144,7 +144,7 @@ MUST support a redeem flow where the shares are burned from `owner` directly whe MAY support an additional flow in which the shares are transferred to the Vault contract before the `redeem` execution, and are accounted for during `redeem`. MUST revert if all of `shares` cannot be redeemed (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc). -MUST revert if redeeming `shares` shares sends less than `minAssets` shares +MUST revert if redeeming `shares` shares sends less than `minAssets` underlying tokens to `receiver`. Note that some implementations will require pre-requesting to the Vault before a withdrawal may be performed. Those methods should be performed separately. From fcc3d663708a6db74037c2da4fc1b62df1ac9a47 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 9 Jun 2022 14:55:52 +0200 Subject: [PATCH 07/12] Add a reference implementation --- EIPS/eip-5143.md | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 433f6a0bade19d..11760dffcfcb30 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -189,13 +189,32 @@ ERC-5143 is fully backward compatible with the ERC-4626 and ERC-20 standards and ## Reference Implementations -TODO - - - - - - +Given an exisitng ERC-4626 implementation + +``` solidity +contract ERC5143 is ERC4626 { + function deposit(uint256 assets, address receiver, uint256 minShares) public virtual returns (uint256) { + uint256 shares = deposit(assets, receiver); + require(shares >= minShares, "ERC5143: deposit slippage protection"); + return shares; + } + function mint(uint256 shares, address receiver, uint256 maxAssets) public virtual returns (uint256) { + uint256 assets = mint(shares, receiver); + require(assets <= maxAssets, "ERC5143: mint slippage protection"); + return assets; + } + function withdraw(uint256 assets, address receiver, address owner, uint256 maxShares) public virtual returns (uint256) { + uint256 shares = withdraw(assets, receiver, owner); + require(shares <= maxShares, "ERC5143: withdraw slippage protection"); + return shares; + } + function redeem(uint256 shares, address receiver, address owner, uint256 minAssets) public virtual returns (uint256) { + uint256 assets = redeem(shares, receiver, owner); + require(assets >= minAssets, "ERC5143: redeem slippage protection"); + return assets; + } +} +``` ## Security Considerations This ERC addresses one of the security consideration raised by ERC-4626. Other considerations still apply. From 24c3021966839b72e3b749c484575f9c399ecb38 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 16 Jun 2022 10:10:53 +0200 Subject: [PATCH 08/12] Apply suggestions from code review Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-5143.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 11760dffcfcb30..86b4664c358e0b 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -1,7 +1,7 @@ --- eip: 5143 -title: Slippage protection for Tokenized Vault -description: An extension of the ERC-4626 standard for improve EOA interactions. +title: Slippage Protection for Tokenized Vault +description: An extension of the ERC-4626 standard for improved EOA interactions. author: Hadrien Croubois (@amxx) discussions-to: https://ethereum-magicians.org/t/eip-5143-slippage-protection-for-tokenized-vaults/9554 status: Draft @@ -13,7 +13,7 @@ requires: 4626 ## Abstract -The following standard extends the ERC-4626 Tokenized Vault standard with functions dedicated to the safe interaction between EOAs and the vault when price is subject to slippage. +The following standard extends the [ERC-4626](./eip-4626.md) Tokenized Vault standard with functions dedicated to the safe interaction between EOAs and the vault when price is subject to slippage. ## Motivation @@ -170,9 +170,9 @@ Note that some implementations will require pre-requesting to the Vault before a ## Rationale -ERC-5143 functions do not replace ERC-4626 equivalent mechanisms. They are additional (overloaded) methods designed to protect EOAs interracting with the vault. +ERC-5143 functions do not replace ERC-4626 equivalent mechanisms. They are additional (overloaded) methods designed to protect EOAs interacting with the vault. -When smart contracts interract with an ERC-4626 vault, they can preview any operation using the dedicated functions before executing the operation. This can be done +When smart contracts interact with an ERC-4626 vault, they can preview any operation using the dedicated functions before executing the operation. This can be done atomically, with no risk of price change. This is not true of EOA, which will preview their operations on a UI, sign a transaction, and have it mined later. Between the preview and the transaction being executed, the blockchain state might change, resulting in unexpected outcomes. In particular, frontrunning make EOA's interractons with an ERC-4626 vault possibly risky. From ab153915be98c03fcc8a046a1e67b5cbfaf5de5b Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Thu, 16 Jun 2022 10:20:05 +0200 Subject: [PATCH 09/12] add an Alternative approaches section --- EIPS/eip-5143.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 86b4664c358e0b..b3e13926ca555e 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -24,7 +24,7 @@ Yet, ERC-4626 does not standardize the corresponding function signatures and beh ## Specification -ERC-5143 is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. +This ERC is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. ### Methods @@ -170,7 +170,7 @@ Note that some implementations will require pre-requesting to the Vault before a ## Rationale -ERC-5143 functions do not replace ERC-4626 equivalent mechanisms. They are additional (overloaded) methods designed to protect EOAs interacting with the vault. +This ERC's functions do not replace ERC-4626 equivalent mechanisms. They are additional (overloaded) methods designed to protect EOAs interacting with the vault. When smart contracts interact with an ERC-4626 vault, they can preview any operation using the dedicated functions before executing the operation. This can be done atomically, with no risk of price change. This is not true of EOA, which will preview their operations on a UI, sign a transaction, and have it mined later. @@ -180,12 +180,12 @@ make EOA's interractons with an ERC-4626 vault possibly risky. Other projects in the DeFi spaces, such as decentralized exchanges, already include similar mechanisms so a user can request its transaction reverts if the resulting exchange rate is not considered good enough. -Implementing ERC-5143 on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert +Implementing This ERC on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert check on the returned value. -## Backwards Compatibility +## Alternative approaches -ERC-5143 is fully backward compatible with the ERC-4626 and ERC-20 standards and has no known compatibility issues with other standards. +This ERC aims at solving the security concerns (describes in the motivation section) at the vault level. For completeness, we have to mention that these issues can also be addressed using a generic ERC-4626 router, similar to how Uniswap V2 & V3 use a router to provide good user workflows on top of the Uniswap pairs. The router approach is possibly more versatile and leaves more room for evolutions (the router can be replaced at any point) but it also leads to more expensive operations because the router needs to take temporary custody of the tokens going into the vault. ## Reference Implementations From e176774ce857b913ed31e8990b9171e0678a70be Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Sun, 19 Jun 2022 18:27:21 +0200 Subject: [PATCH 10/12] Apply suggestions from code review Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5143.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index b3e13926ca555e..2c53b2151e8cc4 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -1,7 +1,7 @@ --- eip: 5143 title: Slippage Protection for Tokenized Vault -description: An extension of the ERC-4626 standard for improved EOA interactions. +description: An extension of ERC-4626 supporting improved EOA interactions. author: Hadrien Croubois (@amxx) discussions-to: https://ethereum-magicians.org/t/eip-5143-slippage-protection-for-tokenized-vaults/9554 status: Draft @@ -13,18 +13,18 @@ requires: 4626 ## Abstract -The following standard extends the [ERC-4626](./eip-4626.md) Tokenized Vault standard with functions dedicated to the safe interaction between EOAs and the vault when price is subject to slippage. +The following standard extends the [EIP-4626](./eip-4626.md) Tokenized Vault standard with functions dedicated to the safe interaction between EOAs and the vault when price is subject to slippage. ## Motivation -[ERC-4626](./eip-4626.md) security considerations section states that: +[EIP-4626](./eip-4626.md) security considerations section states that: > "If implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits, since they have no other means to revert the transaction if the exact output amount is not achieved." -Yet, ERC-4626 does not standardize the corresponding function signatures and behaviors. For improved interroperability, and better support by wallets, it is essential that this optional functions are also standardized. +Yet, EIP-4626 does not standardize the corresponding function signatures and behaviors. For improved interroperability, and better support by wallets, it is essential that this optional functions are also standardized. ## Specification -This ERC is an extenson of ERC-4626. Any contract implementing it MUST also implement ERC-4626. +This ERC is an extension of EIP-4626. Any contract implementing it MUST also implement EIP-4626. ### Methods @@ -36,7 +36,7 @@ Mints `shares` Vault shares to `receiver` by depositing exactly `assets` of unde MUST emit the `Deposit` event. -MUST support ERC-20 `approve` / `transferFrom` on `asset` as a deposit flow. +MUST support [EIP-20](./eip-20.md) `approve` / `transferFrom` on `asset` as a deposit flow. MAY support an additional flow in which the underlying tokens are owned by the Vault contract before the `deposit` execution, and are accounted for during `deposit`. MUST revert if all of `assets` cannot be deposited (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc). @@ -187,7 +187,7 @@ check on the returned value. This ERC aims at solving the security concerns (describes in the motivation section) at the vault level. For completeness, we have to mention that these issues can also be addressed using a generic ERC-4626 router, similar to how Uniswap V2 & V3 use a router to provide good user workflows on top of the Uniswap pairs. The router approach is possibly more versatile and leaves more room for evolutions (the router can be replaced at any point) but it also leads to more expensive operations because the router needs to take temporary custody of the tokens going into the vault. -## Reference Implementations +## Reference Implementation Given an exisitng ERC-4626 implementation From d5b905d32a097ca7e66e288e929cfb152dbee4d7 Mon Sep 17 00:00:00 2001 From: Hadrien Croubois Date: Sun, 19 Jun 2022 18:28:58 +0200 Subject: [PATCH 11/12] typos --- EIPS/eip-5143.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 2c53b2151e8cc4..73481c94059114 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -1,14 +1,14 @@ --- eip: 5143 title: Slippage Protection for Tokenized Vault -description: An extension of ERC-4626 supporting improved EOA interactions. +description: An extension of EIP-4626 supporting improved EOA interactions. author: Hadrien Croubois (@amxx) discussions-to: https://ethereum-magicians.org/t/eip-5143-slippage-protection-for-tokenized-vaults/9554 status: Draft type: Standards Track category: ERC created: 2022-06-09 -requires: 4626 +requires: 20, 4626 --- ## Abstract @@ -183,7 +183,7 @@ resulting exchange rate is not considered good enough. Implementing This ERC on top of an ERC-4626 contract can be done very easily. It just requires calling the corresponding ERC-4626 function and adding a revert check on the returned value. -## Alternative approaches +### Alternative approaches This ERC aims at solving the security concerns (describes in the motivation section) at the vault level. For completeness, we have to mention that these issues can also be addressed using a generic ERC-4626 router, similar to how Uniswap V2 & V3 use a router to provide good user workflows on top of the Uniswap pairs. The router approach is possibly more versatile and leaves more room for evolutions (the router can be replaced at any point) but it also leads to more expensive operations because the router needs to take temporary custody of the tokens going into the vault. From 5a01953dfdae185767e3d418973c8a50153aaaf3 Mon Sep 17 00:00:00 2001 From: lightclient <14004106+lightclient@users.noreply.github.com> Date: Tue, 28 Jun 2022 18:00:47 +0200 Subject: [PATCH 12/12] Update EIPS/eip-5143.md --- EIPS/eip-5143.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5143.md b/EIPS/eip-5143.md index 73481c94059114..525ef1e8872a48 100644 --- a/EIPS/eip-5143.md +++ b/EIPS/eip-5143.md @@ -189,7 +189,7 @@ This ERC aims at solving the security concerns (describes in the motivation sect ## Reference Implementation -Given an exisitng ERC-4626 implementation +Given an existing ERC-4626 implementation ``` solidity contract ERC5143 is ERC4626 {