--- tags: Legacy --- # Broker Self-Staking Proposal The following is a proposed set of policies and mechanisms for broker self staking on broker pools in revenue sharing. It will require that the brokers have "skin in the game". ## Rationale 1. The "skin in the game" aspect will increase difficulty for brokers to act maliciously 2. It makes it much easier to penalize brokers directly for things such as being slashed in a stream 3. It prevents the edge cases where a single delegator in a withdraw queue will receive dividends infinitely and never be cashed out ## Broker Pool Initialization Requirement - On broker pool initialization, the requirement would be an amount of DATA to be put in from the broker's own stake - This would create pool tokens just the same as other delegators - There would be a minimum but no maximum ## Withdraw Requirements - The broker would only be able to withdraw tokens up to what would leave the minimum amount - The only exception is a broker closing out the broker pool at which point they can close out and get back all of it ## Slashing - Slashing could possibly effect the broker stake more harshly or have it as a first loss account - This would lead to possible better alignment with incentives, and make brokers keep up with stream agreements ## Relation to Variation Margin in Traditional Finance - One implementation pattern that might make sense to make it less frequent for brokers to need to top up would be replicating how central counterparties use variation margin - Start out with an intial margin X - Also set a variation margin Y, where Y < X - Once the broker stake is lower than variation margin, the broker is required to top up to the initial margin ### Possible Problems - **What happens if the broker does not top up** - **There is a question of how to be checking this within the context of it being pool tokens, not DATA, once it gets swapped** ### Proposed Solutions - When brokers do not top up, their broker share gets diverted to be put into the stake, possibly with a penalty - It probably would be best to do this with pool token requirements instead of DATA token requirements