This repository has been archived by the owner on Oct 8, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 9
Cropper tack shutdown #34
Open
talbaneth
wants to merge
3
commits into
master
Choose a base branch
from
cropper-tack-shutdown
base: master
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 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
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
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
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.
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.
Also...is this a good assumption?
freeEth
andfreeGem
do not seem totack
to the End, although maybe it is in some external dependency like the Cropper.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.
It can be added to the
_free
function after skimming the vaultThere 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.
It can, but do you think it should be done? My intuition is "yes" since we're assuming it here, but I haven't thought about the Cropper code in a while so I may be missing something.
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.
Let's separate the 2 questions:
The current cashETH/cashGem implementation bundles vat.flux to the redeemer's urnProxy and cropper.flee from the urnProxy. Only in between these calls does the redeemer's urnProxy has enough collateral to allow tacking to it, so the tacking has to take place there.
One option was to tack in cashETH/cashGem from a list of addresses that have excess stake without necessarily involving the end, but that is messy as there could be multiple such fragmented addresses and having the redeemer looking for them is cumbersome.
The preferred option imo is to force tacking from the end. In case there is not enough stake in the end then the action would just fail, forcing tacking from more vaults to the end.
This might be less efficient in some scenarios but is better imo since it can all be done permissionlessly at a single point in time (after skimming all vaults). Trying to concentracte as much stake at the End is also a desired property for tracking purposes and would make our life easier.
Note that it is similar to the existing situation (though not identical*) where you might not be able to cash if not enough vaults were skimmed (here you cannot cash if not enough vaults were tacked to end).
*It's not identical (and a bit more tricky) since a vault which is skimmed would not necessarily be the source of the tacking to end -
A vault owner can call cropper.quit as part of the shutdown process (can do it before or after skimming).
That vat.forks the vault but does not immediately move the stake along. The original vault's stake can then be explicitly tacked along to the forked destination (or not).
So as mentioned this means that a vault that is skimmed would not necessarily be the direct source of the tacking to end (as it might be forked beforehand without tacking the stake along).
That makes it less convenient for shutdown tacking keepers/scripts, and in some cases, the keepers/scripts will need to track the actual stake before tacking it to end (and not simply follow only
Skim
events).(@julienmartinlevrai , we need to discuss how sophisticated we want the current keeper to be).
tacking
tofreeEth
andfreeGem
?freeEth
andfreeGem
are for vault owners to exit their excess collateral.Tacking the non-excess collateral to end would not help the vault owners, so adding it here as a "volunteering" / "system good" step seems weird. Note that this is different from skimming, which does benefit the vault owners (as it is a pre-condition for End.free).
Moreover, given the discussion in (1) which claims that the skimmed vault is not necessarily the source of the needed tacking (since the position might have been forked without tacking) I'd say not to do it here.
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.
If the vault has
stake < ink
,freeETH
andfreeGem
will fail because they callexit
. So we can safely assumestake >= ink
. Then we could justtack(stake - ink)
.Let’s make our life easier. Vault owners will have no issue contributing a bit of gas to the "system good" if we suggest they should. And if they really don’t want to, they can always do their own thing.
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 wouldn't tend to do that just because
tack
ing to theend
is not part of the interest of thefree
user (as Tal mentioned) but also because it would give a false assumption. If users would end up using a custom proxy action that doesn't do it then the keeper would be assuming something that hasn't been enforced.Anyway I don't have a super strong opinion on this, so if you want to add it, I won't opposed either.
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.
We are already making a false assumption as we
tack
from the End. Adding atack
to the End makes that assumption less false.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.
It is the same than assuming the
End
has enoughink
for cashing (enough CDPs were skimmed). That's work for the keepers.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.
The Keeper cannot assume it in any case, agreed. But I'm somewhat partial to trying to make things as smooth as possible, given how chaotic any real ES is bound to be.
Except that in this same contract, the assumption that
tacking
was done is made. So to me doing thetacking
infreeEth
/freeGem
makes sense, and can serve as a guide for other integrators to know at least what needs to happen eventually. The argument against this that makes the most sense to me is that Vault holders don't have any obligation to pay for this operation (strictly speaking, it is DAI holders who have an incentive to care). But as pointed out, no one has to use this contract, and I don't think the cost will be too extreme.So ultimately it doesn't seem like a big deal. Either more work for Keepers/DAI redeemers, or a little more cost for Vault holders to exit. I guess it's probably most consistent with the design philosophy of other Maker contracts to omit the
tack
calls here.