memoscan

0xffa6…f23c

All memos sent from and to 0xffa6…f23c.
0xffa68ea3…f23csent to0x7e880d8b…50e6·#20,108,712·0x3511cc6d…12a344
# [IP] eUSD 3.4.0 Upgrade Step 1 [https://forum.reserve.org/t/ip-eusd-3-4-0-upgrade/753](https://forum.reserve.org/t/ip-eusd-3-4-0-upgrade/753) Upgrade all eUSD core contracts and assets from version 3.0.1 to version 3.4.0 and upgrade to new Governance and TimelockController instances via a spell contract.
0xffa68ea3…f23csent to0x7e880d8b…50e6·#19,434,845·0x1ead1268…1dc36d
# 2024 Q1 Plug-in Upgrade - Upgrade trading plugins - Upgrade collateral plugins - Swap out aave-v2 and compound-v2 USDC for aave-v3 and compound-v3 USDC - Increase redemption throttle to $2.5m and 12.5%
0xffa68ea3…f23csent to0x7e880d8b…50e6·#16,929,327·0xed093daa…fff9cb
# Max Trade Slippage Reduction to .5% Summary Change Max Trade Slippage from 1% to default value of .5%. Abstract Max Trade Slippage is the percentage value the describes the maximum deviation from oracle prices that any trade that the protocol performs can clear at. Slippage permits additional price movement beyond the worst-case oracle price. 1% slippage means if oracles quote the price for USDT at $1.00 per USDT, the protocol will allow an auction to clear at $.99 per USDT, in the current state. I am proposing to half this possible discrepancy, to $.995 per USDT. Problem statement Clearing a trade of an asset at 1% deviation from the oracle price allows for those that participate in the auction to, in the limit, extract 1% of the total collateral value being auctioned from the RToken stakers. $3.75 million of USDT (if eUSD is at 7.5 million circulating supply), means that the auction participants can extract $37,500 from the RSR stakers (this is assuming there is no competition). Rationale I would like to change the Max Trade Slippage to the default value of .5%. 1% is too great of a value for upcoming eUSD collateral auction. Risks It is the default value, proposed by the Reserve team. There should be no risk to this.
0xffa68ea3…f23csent to0x7e880d8b…50e6·#16,929,327·0xc689373a…3312f1
# [Correct] Trading Delay Reduction to 2 Hours Summary Change the Trading Delay from 6 hours to 2 hours. Abstract Change Trading Delay of eUSD to 7200 seconds (2 hours) from 21600 seconds (6 hours). Currently the Trading Delay is an additional buffer of time between an event and when auctions start. When USDC depegged, the protocol initiated a 24 hour “wait-and-see” countdown. This default alarm itself puts the community on high alert to the default, and keeps them on high alert for 24 hours, watching the peg of the asset closely. At the end of the 24 hour period, USDC did not re-peg, and the protocol subsequently allowed for the auctioning of the USDC-denominated collateral. Before the protocol officially allows for the auctioning of the collateral, there is an additional timer, called the Trading Delay, which postponed the auctioning of USDC-denominated collateral for an additional 6 hours. The proposed changed would lessen this additional time, the Trading Delay, to 2 hours. Problem Statement The Trading Delay being set to 6 hours is not correct. I believe it should be set to 2 hours, as all events preceding the Trading Delay have sufficient time for the community to become alert. Governance proposals to change the basket of eUSD are one week. Default detections are 24 hours. The Trading Delay of 6 hours is too great of a delay. Rationale Both the default “wait-and-see” 24 hour and week long basket change proposal period allow the community sufficient time to be aware of potential impending changes. I do not believe the Trading Delay should be 0 or 1 hour, as I see the Trading Delay to be a planning buffer for teams and individuals. This planning time (Trading Delay) should be sufficient enough to allow some travel and communication for teams and individuals to be present for the auctions. Risks It is possible that the Trading Delay being set to 2 hours would cause some issues I am not anticipating. **Earlier proposal submitted was using incorrect math for 2 hours. My apologies.**
0xffa68ea3…f23csent to0x7e880d8b…50e6·#16,929,237·0xd29064d9…580e6c
# Trading Delay Reduction to 2 Hours Summary Change the Trading Delay from 6 hours to 2 hours. Abstract Change Trading Delay of eUSD to 3600 seconds (2 hours) from 21600 seconds (6 hours). Currently the Trading Delay is an additional buffer of time between an event and when auctions start. When USDC depegged, the protocol initiated a 24 hour “wait-and-see” countdown. This default alarm itself puts the community on high alert to the default, and keeps them on high alert for 24 hours, watching the peg of the asset closely. At the end of the 24 hour period, USDC did not re-peg, and the protocol subsequently allowed for the auctioning of the USDC-denominated collateral. Before the protocol officially allows for the auctioning of the collateral, there is an additional timer, called the Trading Delay, which postponed the auctioning of USDC-denominated collateral for an additional 6 hours. The proposed changed would lessen this additional time, the Trading Delay, to 2 hours. Problem Statement The Trading Delay being set to 6 hours is not correct. I believe it should be set to 2 hours, as all events preceding the Trading Delay have sufficient time for the community to become alert. Governance proposals to change the basket of eUSD are one week. Default detections are 24 hours. The Trading Delay of 6 hours is too great of a delay. Rationale Both the default “wait-and-see” 24 hour and week long basket change proposal period allow the community sufficient time to be aware of potential impending changes. I do not believe the Trading Delay should be 0 or 1 hour, as I see the Trading Delay to be a planning buffer for teams and individuals. This planning time (Trading Delay) should be sufficient enough to allow some travel and communication for teams and individuals to be present for the auctions. Risks It is possible that the Trading Delay being set to 2 hours would cause some issues I am not anticipating.