--- tags: Spec-Revenue-Sharing --- # Forced Take-out Solutions V3/Final ## Summary The following is meant to be the last iteration on the forced take-out proposal in a more simplified formalization from prior iterations which were more complex. ## Parameters | Name | Description | Type | | -------- | -------- | -------- | | grace_period | The number of days before a call can be made to force withdraw, should be greater than or equal to maximum_of_minimum_staking_time | Days | | maximum_of_minimum_staking_time | The global maximum value for the minimum number of days of staking until slashing will not occur | Days | ## Behavioral Actions/Prior Actions ### Withdraw Queue - When withdrawing funds, the only difference will be that the time at which a withdraw was created at will be stored ### Trigger Force Withdraw - Anyone with a stake in the pool can call this function - The function takes an argument of one given stream to force out of - First, the revenue earning functionality is called to see if any of the withdraw queue gets cashed out - Next, there is a check that the oldest withdraw queue item is older than the grace period - If this is true, then the entire stream agreement stake is unstaked and payments are done in a waterfall based on the age in the withdraw queue ## Policies ### Withdraw Waterfall - After a force withdraw happens, this policy pays out all of the DATA (to pay out the withdraw queue in the normal order) - While there is still something in the withdraw queue and there is still DATA left over, the minimum of the leftover funds and withdraw queue amount is paid out - If there is any left over funds after the withdraw queue is emptied, it goes into free funds ## Mechanisms ### Force Stream Withdraw - The mechanism which forces an unstaking on a stream ### Pay off Debt - The mechanism which transfers unstaked DATA to delegators to pay off debts ## System Guarantees 1. Delegators are able to get back their funds at a maximum time of the <code>grace_period</code> 2. Brokers are able to choose which streams to unstake from as long as it is before <code>grace_period</code> 3. The withdraw queue keeps the ordering the same no matter what of who gets paid out ## Possible Issues 1. Is there an attack vector where someone has a withdraw queue item less than the grace period in age, but calls the function with the biggest possible payout and then it gets cashed out in the process as well? - Basically would allow for forcing withdraw early in some scenarios - Do we care since this is supposed to be punitive anyways?