-
Notifications
You must be signed in to change notification settings - Fork 7
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
[DO NOT MERGE] KIP-3 to Dev #429
Closed
Closed
Conversation
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
… StabilityPool As a first step to redirecting revenue flow from staked KUMO tokens to Stability Pool depositors, we need to move variables and functions responsible for counting gains. `mapping(address => uint256) F_ASSETS` was transformed into the `uint256 F_ASSET` because we have a Stability Pool instance for each supported asset. And KUMOStaking supported all assets in one contract.
That's for future optimization when we add more variables in a `_getAssetGainFromSnapshots` function and hit a `Stack Too Deep` error.
After debugging tests, I discovered that storing deposited KUSD and KUSD gains in one tracker is not the best idea. That's why we introduce a new tracker - `totalKUSDGains`. Also added several helper functions and `_increaseKUSDGains` for `increaseF_KUSD`.
`increaseF_Asset` is called by KUMO core contracts when they send a fee to a Stability Pool (this will be implemented later). Those fees should be accounted for on the SP asset tracker.
…setGainFromSnapshots` In a Stability Pool, assets could be gained only from liquidations. But as we redirect revenue flow, we now have a new way to get assets from SP - revenue share. So, we need to update the `_getAssetGainFromSnapshots` function to reflect a new flow of an asset.
…shots As in a previous commit, it's a continuation of merging functions from KUMOStaking into StabilityPool functions.
The same as with asset gains, we now send all KUSD gains to the user if they call `provideToSP`, `withdrawFromSP` or `withdrawAssetGainToTrove` functions.
This line was meant to remove a front-end tag and make a deposit equal to zero, because `deposits` was a struct with two variables. But after removing front-end tags, and with the if condition in the line above, the deposit value is already equal to zero to that moment. So, this line is redundant.
To make the pipeline run correctly, I need to comment out KUMOStaking and related contracts
In changed lines, we minted KUSD for the KUMOStaking address every time a fee occurred. Now we mint the same fee for SP and also call `increaseF_KUSD` and `increaseF_Asset`.
After this commit, there's no other way for KUMO token to be issued.
Cleans up the contract and the interface.
The changes aim to address issues where jobs were skipped on a PR against KIP-3. The types attribute should cover all necessary states except drafts.
Variable G was used to track KUMO gains. Now we don't need it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.