Skip to content
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

3.0.0 #809

Merged
merged 414 commits into from
Sep 20, 2023
Merged

3.0.0 #809

merged 414 commits into from
Sep 20, 2023

Conversation

tbrent
Copy link
Collaborator

@tbrent tbrent commented May 5, 2023

No description provided.

tbrent and others added 30 commits May 3, 2023 18:41
* implement DutchTrade

* add hardhat-storage-layout plugin

* first compile

* tuning

* prevent bidding in same block as auction creation

* chain bid into new auction

* add 1-block cooldown between trades of the same type

* more tuning

* rate-limit same-kind auctions based on endTime(), not time of settlement

* switch order of TradeKind and TradeRequest

* RevenueTrader

* lint clean

* RevenueTrader: expose distributeTokenToBuy directly

* refresh()/melt() before RevenueTrader manageToken

* update scripts

* fix gap

* DutchTrade asserts

* Broker events/governance setters

* Trading minor ternary expression optimization

* RevenueTrader require bugfix

* RevenueTrader: minimize melting + asset refresh()

* keep RToken up to backingBuffer as well

* do not manageToken() after handoutRevenue(); leave for facade

* p0 + p1 tests

* docs/system-design.md

* scenario tests

* integration tests

* reorder FacadeAct tests

* plugin integration tests

* make backingBuffer handling more straightforward

* tests back to passing

* fix typo

* move tradeEnd into BackingManager + bugfixes

* initial revenue dutch tests

* sync BackingManagerP0/P1

* lint clean

* better error message + fix EasyAuction test

* BackingManager tests

* fix tests

* guard against reentrancy + eliminate 12s magic number throughout codebase

* reorder FacadeAct tests

* confirm DutchTrade has starting balance

* wrap up DutchTrade testing

* gas tests for Broker / BackingManager

* 80% -> 85%

* phase3-rtoken/rTokenConfig.ts

* set backing buffer to 0 in recollat test

* clarify seemingly obsolete test

* pull out as much as possible into beforeEach from Broker GnosisTrade/DutchTrade tests

* nits

* empty buffer block

* add full recollateralization tests

* RevenueTraderP1.manageToken() reentrancy nitpick

* comment RCEI

* label checks/effects/interactions

* lint clean

* fix tests & linting.

* add invalid claim logic replacement tests

* missing revenue test

* fix plugin tests

---------

Co-authored-by: pmckelvy1 <[email protected]>
julianmrodri and others added 18 commits July 6, 2023 09:01
Co-authored-by: brr <[email protected]>
Co-authored-by: Taylor Brent <[email protected]>
Co-authored-by: pmckelvy1 <[email protected]>
Co-authored-by: Akshat Mittal <[email protected]>
Co-authored-by: brr <[email protected]>
Co-authored-by: Taylor Brent <[email protected]>
Co-authored-by: Julian M. Rodriguez <[email protected]>
Co-authored-by: brr <[email protected]>
Co-authored-by: Taylor Brent <[email protected]>
Co-authored-by: pmckelvy1 <[email protected]>
Co-authored-by: Julian M. Rodriguez <[email protected]>
Co-authored-by: Patrick McKelvy <[email protected]>
Co-authored-by: Patrick McKelvy <[email protected]>
@tbrent
Copy link
Collaborator Author

tbrent commented Sep 14, 2023

@julianmrodri can you confirm the .openzeppelin/mainnet-3_0_0.json file is correct and what we want?

@julianmrodri
Copy link
Contributor

julianmrodri commented Sep 15, 2023

@julianmrodri can you confirm the .openzeppelin/mainnet-3_0_0.json file is correct and what we want?

The contents in that file match what it was deployed. However if you compile the code now, and pretend to reproduce the deployment the implementations of BackingManagerP1 and BasketHandlerP1, produce a different hash. I double checked this and see there are no differences in terms of variables, slots, types, but some internal "references" to contracts differ a bit (seems to be an internal id that OZ uses to connect compiled contracts)

This does not create issues to upgrade or release new versions. I ran a POC locally for both contracts and was able to upgrade the 3.0.0 implementation with no issues. There was probably something different in the compilation at the time it was deployed vs now. But this is not a big deal I think. I've opened a question with OZ to understand what could cause these differences.

I'll be opening a PR using Infura instead of Alchemy so we can group into a single network file.

@tbrent
Copy link
Collaborator Author

tbrent commented Sep 15, 2023

@julianmrodri can you confirm the .openzeppelin/mainnet-3_0_0.json file is correct and what we want?

The contents in that file match what it was deployed. However if you compile the code now, and pretend to reproduce the deployment the implementations of BackingManagerP1 and BasketHandlerP1, produce a different hash. I double checked this and see there are no differences in terms of variables, slots, types, but some internal "references" to contracts differ a bit (seems to be an internal id that OZ uses to connect compiled contracts)

This does not create issues to upgrade or release new versions. I ran a POC locally for both contracts and was able to upgrade the 3.0.0 implementation with no issues. There was probably something different in the compilation at the time it was deployed vs now. But this is not a big deal I think. I've opened a question with OZ to understand what could cause these differences.

I'll be opening a PR using Infura instead of Alchemy so we can group into a single network file.

Very nice, thanks.

@tbrent
Copy link
Collaborator Author

tbrent commented Sep 15, 2023

It's also expected for DeployerP1 to be different; I added an event to deployRTokenAsset() that isn't worth re-redeploying for.

@julianmrodri
Copy link
Contributor

The difference I was seeing was due to using different external library addresses which are linked to BM and BH. So this is perfectly fine if I use the same addresses you used for this deployment.

@tbrent tbrent merged commit 336e5b1 into master Sep 20, 2023
8 checks passed
@tbrent tbrent deleted the 3.0.0 branch September 20, 2023 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants