---
# System prepended metadata

title: Forced Take-out Solutions V3/Final
tags: [Spec-Revenue-Sharing]

---

---
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?