-
Notifications
You must be signed in to change notification settings - Fork 79
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
WOETH: Withdraw OETH in surplus. #2119
Open
clement-ux
wants to merge
11
commits into
sparrowDom/woeth_hack_proof
Choose a base branch
from
clement/woeth-surplus-transfer
base: sparrowDom/woeth_hack_proof
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 6 commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
7f6795a
feat: withdraw surplus of oETH in wrapper.
clement-ux 4b10871
test: add tests for surplus withdrawal.
clement-ux c3e83c4
fix: add visibility to internal function.
clement-ux 429cb14
test: add test for rebase with loss.
clement-ux 21ea003
style: run prettier.
clement-ux df78c6d
style: remove comment.
clement-ux 9325358
perf: reduce `require` string lenght.
clement-ux 09d4a44
fix: apply change on reverting string message to test.
clement-ux e192d51
test: cannot transfer more than surplus after rebase.
clement-ux afdccc1
style: run prettier.
clement-ux 4a12161
test: remove test for negativ rebase.
clement-ux File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -80,9 +80,11 @@ contract WOETH is ERC4626, Governable, Initializable { | |
external | ||
onlyGovernor | ||
{ | ||
//@dev TODO: we could implement a feature where if anyone sends OETH direclty to | ||
// the contract, that we can let the governor transfer the excess of the token. | ||
require(asset_ != address(asset()), "Cannot collect OETH"); | ||
if (asset_ == address(asset())) { | ||
uint256 surplus = OETH(asset()).balanceOf(address(this)) - totalAssets(); | ||
require(amount_ <= surplus, "Cannot collect OETH more than surplus"); | ||
clement-ux marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
IERC20(asset_).safeTransfer(governor(), amount_); | ||
} | ||
|
||
|
@@ -95,7 +97,8 @@ contract WOETH is ERC4626, Governable, Initializable { | |
* @return amount of OETH credits the OETH amount corresponds to | ||
*/ | ||
function _creditsPerAsset(uint256 oethAmount) | ||
internal | ||
internal | ||
view | ||
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. nice catch 👍 |
||
returns (uint256) | ||
{ | ||
(, uint256 creditsPerTokenHighres, ) = OETH(asset()) | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
On a quick look, I'm a bit lost here. OETH is a rebasing token. wOETH's appreciation comes from the OETH yields (which are distributed during rebases with increasing balances). Won't this forgo all unrealized yields as well?
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.
Looks like it has an internal log of oethCredits (updating during wrap and unwrap) but let me check
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.
With WOETH ignore donations PR WOETH keeps the balance of the internal credits (of the OETH token) that change on mint, deposit, redeem, withdraw.
I think this approach is mathematically correct since the
surplus
figures out the difference between WOETH internal credits amount and OETH internal credits (for WOETH contract) multiplied by the credits per token - in other words operating with OETH token amounts.Surplus could also be calculated using another approach by finding the difference of internal credits tracked by WOETH and OETH and then multiplying it by the current credits per token ( to arrive to the OETH token surplus amount).
I think in either of the approaches the un-realized rebase yields aren't left on the table, since as long as we do the correct math on the underlying credits per token. The rebase will take care of correct yield distribution.
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.
Still a spot on comment @shahthepro 🙏 These are the sort of checks we need to make to be sure the math works correctly.
We could add a test for this @clement-ux, where:
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.
Thanks for the detailed explanation. Will check both PRs today to get more clarity on this.
Yeah, totally agree that we should be having unit and fork tests with different scenarios involving donations and rebases.
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.
I've added the test that @sparrowDom suggested in this commit and it passes.
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.
Do you mean dividing instead of multiplying maybe?
An implementation could look something like this:
This could consume less gas but can lead to rounding issues IMO. But as you already mentioned, I don't think it is important enough to increase complexity.