Create mock for the vault liquidation feature #419
Comments
|
See mock: https://whimsical.com/makerdao-vaults-SgfmKedbUSoRS4FFvbnvTG MOCK v1
|
Therefore, the only important information for a vault is:
The rest are technical details of the vault that doesn't make a difference to me, at least according to the investigation. |
Agree, let's include a proposal on how this transition could be handled to the Mock
To be verified: If no address is specified the one that calls the function to liquidate will be the one to receive the incentive
Unaware of what we will be able to fetch in the end I would see the following values as relevant in that regard:
This is the incentive that is referenced in the investigation issue. Here I would like to understand: What determines the height of the incentive? Is it always the same?
Agree that this would be very helpful for the user to know (and coincides with the OSM price updates - AFAIK happen every hour)
|
I was doing some research into this and I think there is not defined time space in which the prices are recalculated (correct me if I am going off on a limb here). In this text, they talk about their rates module, that is in charge or recalculating debt on vaults. From what I understand, the numbers are only recalculated every time someone calls This is also why when looking at the rate graphs of vaults, they appear as follows:
|
How would you recommend handling MOCK v2
|
State of the
Well, it's a great find, in the direction of general understanding of liquidation mechanism that I've been pushing in #363. Since documentation explicitly says
Regarding OSM prices it's still unclear to me when and how they are updated and how they affect vaults.
|
Until now I have not focused on writing texts concerning how the liquidation of vaults work. I agree that all the points you mentioned will need to be addressed. How does the writing of texts work normally when you were designing previous UI? Did you write an initial draft and hand it of to Lukas for review?
As far as I can see I did take your feedback into account. From the comment Lukas left it appeared to me that:
These were some of the important points for the first page, and then that
would be added to the Transaction page. Is that wrong? For the other points:
I feel like we need to do some further investigation, as I have no idea right now, what and how we would calculate this data.
From what I saw on the BlockAnalytica page, the values provided for the vaults were set in USD. Is this also the data we recieve or did they do some kind of conversion? If we do have to use USD, should I write USD behind it as a currency?
Sounds good! Ill make a mock (based on the old SurplusEvents table) and include it underneath the link! |
|
Questions that need to be addressed:
|
While in other questions you not explicitly hint what you would like to have, here you can also give a hint on what information you would like to have: or just avoid using a closed question. Eg: "How can we get information about vaults that are about to be in 'ready to liquidate' state, not only the ones that are in this state already?" Besides that, you should better post those questions to the investigation issue: to keep answers in one place. |
the minimal desired result is to have the vaults that are ready to be liquidated. the best case scenario is to also list vaults that are at risk. vaults at risk are the vaults that might soon become ready to be liquidated. Vaults that are liquidated are not in scope because these vaults are alcready being auctioned and this is covered by our ui.
historical data might be useful at some point, but is not required for the minimal functionality and it's questionable wether we should use it for displaying vaults at risk. reason for that is the fact that we maybe could just orient ourselves on the current collateralization ratio and the value that is queued in the osm contract.
technically yes, but my question would be "how far in advance" would you like to make this prediction? First we have to define the "at risk" margin that we are going to use. e.g. with margin 10% we would consider predictions for all vaults that are within 10% from being underwater.
Yes, the values are stored in the clipper contract of the collateral (link)
we have a collateralization and liquidation ratios. in contract terms these are the formulas: |
|
Thank you for your answers @KirillDogadin-std! I have copied your answers and responded here. |
|
As I am getting to a point where I am ready to draft texts, I will use this comment to outline what I think would make sense to include: View 1 (Vault table):
View 2 (Vault page):
View 3 (Vault Transaction page):
|
|
This morning I focused on redesigning the vault page (SplitView 2). Taking previous feedback into account I decided to add the following information to the Vault Table:
|
|
I updated the entire mock to reflect the new information we learned about the Vaults. As @LukSteib also requested here is an overview of the most important components:
New version of the mock
|
valiafetisov
changed the title
And other minor things. I will try to update the mock based on those points right away |
|
Also, there is no proposal on how to integrate |
|
Updated mock. Notes:
New version
@KirillDogadin-std please validate feasibility of the mock (ie if it's actually possible to implement proposed solution, based on your technical understanding) |
|
Some remarks
|
Agree, renamed. The leading indicator is [temporary] named
Eg
Partial liquidation logic is below linked require statement, so I don't think it's true. Investigation result
In case of the down arrow the
I think showing prices can be too raw: what user actually needs to know is the difference between current OSM price and expected OSM price in percentage. And I think we might need to explain OSM update logic somewhere in the text (possibly related to the |
Updated mock
|
Great new naming
sounds good
Are you planning to include this concrete percentage indicator to the "Next Price Update" row in addition to the arrow that indicates the direction?
Agree, I would like to improve our understanding of |
|
I have the following questions:
Apart from this, the mock looks solid. That is, if the following holds true:
|
😓 yes, I meant
No idea. The dog contract might not need authorization, but the underlying calls of the contracts (eg vat.grab or vow.fess or clip.kick, underlying calls of those methods) might need.
|
already done!
Ill remove it right now! |
|
@valiafetisov, what does this panel look like in the incorrect state? I don't know what it represents/looks like in other states. |
|
This comment explains what it does: basically it fetches some values from the chain to make sure they are correct. So the expanded panel should explain what it checks, maybe show them in a table (or the derived values that makes sense, eg |
|
Updated Mock: |
|
Regarding limits: it's not the amount of liquidations, It's 2 numbers per limit, both in DAI: https://github.com/makerdao/dss/blob/fa4f6630afb0624d04a003e920b0d71a00331d98/src/dog.sol#L77 You can either display and explain both of them or display |
|
I updated it to the following: When hovering over the icon, you get a small explain field, with your explanations (rewritten a bit to make them more understandable) |
|
I was in a call with @LukSteib, we were thinking if we can show the Liquidation Limits in the following way:
It would look as following in the mock:
I believe this makes more sense, as the user is informed how much they are adding and how much DAI is left to liquidate. Is this technically possible @KirillDogadin-std and @valiafetisov? From my rough understanding we would need to fetch all active auctions (which we do anyway) and add their DAI amounts together right? |
The limits are already tracked by the respective contracts as the contract itself have them. We just need to fetch those 4 numbers: Regarding the mock:
Suggestion: Where each of the numbers ( |
Goal
Mocked vault liquidation feature
Context
When a vault becomes underwater, it can be liquidated and a collateral auction can be started. Beforehand the vault can be at risk for a certain amount of time. With this addition we hope to give users insight into what vaults are at risk and help them liquidate underwater vaults.
Tasks
The text was updated successfully, but these errors were encountered: