From 5c4f0a53a8d880f36b9f906a21f84a92ac4ff239 Mon Sep 17 00:00:00 2001 From: buldazer23 Date: Tue, 28 Nov 2023 20:40:59 +0300 Subject: [PATCH] commit --- README.md | 6 +++--- protocols/USDe/README.md | 6 +++--- protocols/USDe/contracts/README.md | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index ee553a6..d9a47f8 100644 --- a/README.md +++ b/README.md @@ -68,9 +68,9 @@ By setting a delegated signer, the smart contract allows both the `order.benefac `EthenaMinting.sol` have crucial roles called the `MINTER` and `REDEEMER`. Starting with `MINTER`, in our original design, they have the ability to mint any amount of USDe for any amount of collateral. Given `MINTER` is a hot wallet and is an EOA address, we considered the scenario where this key becomes compromised. An attacker could then mint a billion USDe for no collateral, and dump them on pools, causing a black swan event our insurance fund cannot cover. -Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in seperate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materialy affect our operations. +Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in separate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materially affect our operations. -Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this prvileage means their `GATEKEEPER` role will be removed. +Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this privilege means their `GATEKEEPER` role will be removed. The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable minting/redeeming. `DEFAULT_ADMIN_ROLE` also has the power to add/remove `GATEKEEPERS`,`MINTER` and `REDEEMER`. @@ -82,7 +82,7 @@ The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable min This contract is a modification of the ERC4626 standard, with a change to vest in rewards linearly over 8 hours to prevent users frontrunning the payment of yield, then unwinding their position right after (or even in the same block). This is also the reason for `REWARDER` role. Otherwise users can be denied rewards if random addresses send in 1 wei and modifies the rate of reward vesting. -There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a seperate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. +There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a separate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. Due to legal requirements, there's a `SOFT_RESTRICTED_STAKER_ROLE` and `FULL_RESTRICTED_STAKER_ROLE`. The former is for addresses based in countries we are not allowed to provide yield to, for example USA. Addresses under this category will be soft restricted. They cannot deposit USDe to get stUSDe or withdraw stUSDe for USDe. However they can participate in earning yield by buying and selling stUSDe on the open market. diff --git a/protocols/USDe/README.md b/protocols/USDe/README.md index 4af7da4..0f0a974 100644 --- a/protocols/USDe/README.md +++ b/protocols/USDe/README.md @@ -66,9 +66,9 @@ By setting a delegated signer, the smart contract allows both the `order.benefac `EthenaMinting.sol` have crucial roles called the `MINTER` and `REDEEMER`. Starting with `MINTER`, in our original design, they have the ability to mint any amount of USDe for any amount of collateral. Given `MINTER` is a hot wallet and is an EOA address, we considered the scenario where this key becomes compromised. An attacker could then mint a billion USDe for no collateral, and dump them on pools, causing a black swan event our insurance fund cannot cover. -Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in seperate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materialy affect our operations. +Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in separate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materially affect our operations. -Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this prvileage means their `GATEKEEPER` role will be removed. +Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this privilege means their `GATEKEEPER` role will be removed. The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable minting/redeeming. `DEFAULT_ADMIN_ROLE` also has the power to add/remove `GATEKEEPERS`,`MINTER` and `REDEEMER`. @@ -80,7 +80,7 @@ The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable min This contract is a modification of the ERC4626 standard, with a change to vest in rewards linearly over 8 hours to prevent users frontrunning the payment of yield, then unwinding their position right after (or even in the same block). This is also the reason for `REWARDER` role. Otherwise users can be denied rewards if random addresses send in 1 wei and modifies the rate of reward vesting. -There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a seperate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. +There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a separate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. Due to legal requirements, there's a `SOFT_RESTRICTED_STAKER_ROLE` and `FULL_RESTRICTED_STAKER_ROLE`. The former is for addresses based in countries we are not allowed to provide yield to, for example USA. Addresses under this category will be soft restricted. They cannot deposit USDe to get stUSDe or withdraw stUSDe for USDe. However they can participate in earning yield by buying and selling stUSDe on the open market. diff --git a/protocols/USDe/contracts/README.md b/protocols/USDe/contracts/README.md index 4af7da4..0f0a974 100644 --- a/protocols/USDe/contracts/README.md +++ b/protocols/USDe/contracts/README.md @@ -66,9 +66,9 @@ By setting a delegated signer, the smart contract allows both the `order.benefac `EthenaMinting.sol` have crucial roles called the `MINTER` and `REDEEMER`. Starting with `MINTER`, in our original design, they have the ability to mint any amount of USDe for any amount of collateral. Given `MINTER` is a hot wallet and is an EOA address, we considered the scenario where this key becomes compromised. An attacker could then mint a billion USDe for no collateral, and dump them on pools, causing a black swan event our insurance fund cannot cover. -Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in seperate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materialy affect our operations. +Our solution is to enforce an on chain mint and redeem limitation of 100k USDe per block. In addition, we have `GATEKEEPER` roles with the ability to disable mint/redeems and remove `MINTERS`,`REDEEMERS`. `GATEKEEPERS` acts as a safety layer in case of compromised `MINTER`/`REDEEMER`. They will be run in separate AWS accounts not tied to our organisation, constantly checking each transaction on chain and disable mint/redeems on detecting transactions at prices not in line with the market. In case compromised `MINTERS` or `REDEEMERS` after this security implementation, a hacker can at most mint 100k USDe for no collateral, and redeem all the collateral within the contract (we will hold ~$200k max), for a max loss of $300k in a single block, before `GATEKEEPER` disable mint and redeem. The $300k loss will not materially affect our operations. -Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this prvileage means their `GATEKEEPER` role will be removed. +Further down the line, there has been considerations to give external organisations a `GATEKEEPER` role. We expect the external organisations to only invoke the gatekeeper functions when price errors occur on chain. Abuse of this privilege means their `GATEKEEPER` role will be removed. The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable minting/redeeming. `DEFAULT_ADMIN_ROLE` also has the power to add/remove `GATEKEEPERS`,`MINTER` and `REDEEMER`. @@ -80,7 +80,7 @@ The `DEFAULT_ADMIN_ROLE`, also our ethena multisig, is required to re-enable min This contract is a modification of the ERC4626 standard, with a change to vest in rewards linearly over 8 hours to prevent users frontrunning the payment of yield, then unwinding their position right after (or even in the same block). This is also the reason for `REWARDER` role. Otherwise users can be denied rewards if random addresses send in 1 wei and modifies the rate of reward vesting. -There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a seperate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. +There's also an additional change to add a 14 day cooldown period on unstaking stUSDe. When the unstake process is initiated, from the user's perspective, stUSDe is burnt immediately, and they will be able to invoke the withdraw function after cooldown is up to get their USDe in return. Behind the scenes, on burning of stUSDe, USDe is sent to a separate silo contract to hold the funds for the cooldown period. And on withdrawal, the staking contract moves user funds from silo contract out to the user's address. The cooldown is configurable up to 90 days. Due to legal requirements, there's a `SOFT_RESTRICTED_STAKER_ROLE` and `FULL_RESTRICTED_STAKER_ROLE`. The former is for addresses based in countries we are not allowed to provide yield to, for example USA. Addresses under this category will be soft restricted. They cannot deposit USDe to get stUSDe or withdraw stUSDe for USDe. However they can participate in earning yield by buying and selling stUSDe on the open market.