Open Discussion/Research Issues

--- tags: Spec-Revenue-Sharing --- # Open Discussion/Research Issues ## Syncing Revenue ### Initial Thoughts - Revenue is not known to a broker pool until it is claimed - This makes an incentive to make sure the revenue is claimed when you withdraw, and the opposite when you deposit - There is a consideration of gas costs to how often you sync up - Should the person calling for the revenue just pay gas costs? - Should anyone be able to call this function to make the revenue sync? ## Replacement of DATA Debits with Withdraw Queue ### Initial Thoughts During the 7/7/2022 meeting, it was brought up that a withdraw pool token queue would likely be better than DATA based debit queue ### Edge Case There is an edge case with this as detailed here: https://blockscienceteam.slack.com/archives/C010U62AG07/p1657226500088599 ### Interest - This mechanism would take care of interest in a sense because the tokens still earn profits while active - Question of whether there should also be interest from waiting ## Stake Withdraw Debit Repayment This topic has to deal with the idea that if a broker pool has debits, when it withdraws, it could technically have a mechanism to divert all withdrawn stake to pay off debits. ### Initial Thoughts - [Scenario 6](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-6---Debit-Close-Out-w-Stake) gives a good example of how this would work. - There are three possible options: - Withdraw of stake does NOT hit debits ever - Withdraw ofs take ALWAYS pays off debits first - There is a policy that determines how to pay off debits versus return to the pool funds based on any combination of things including current state or heuristics (i.e. only a maximum of half of the stake withdrawn can be put towards debit repayment) - Question of incentives, will brokers always try to keep stake to avoid paying off the debts? ### 7/7 Meeting Discussion - What are the game theoretic implications? - We probably should track how long debt has been outstanding - Good starting points for further research: Elevator problem, penalty, quadratic, longer the wait, longer the accumulation ## New Capital -> Debit Payout ### Initial Thoughts When a delegator adds new capital to a broker pool, should this automatically pay out any debits outstanding? This would be essentially like swapping in and out who owns the tokens. ## Vault Factory ### Initial Thoughts - There is a question of whether the vault could be used as a factory for creating pool contracts - Idea would be to give you clones of template for creating the broker pool ## Pool Value > 0, 0 Token Balance This topic is on what happens when we get in a scenario above. ### Initial Thoughts - [Scenario 7](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-7---Debit-Paid-Down-Through-Revenue) provides an example of this - This does not have a clear answer but it is feasible that this can happen. ## 0 Pool Value, > 0 Token Balance This topic is on what happens when pool value is 0 for there is still token balances. ### Initial Thoughts - This is a dicey edge case and there are a bunch of different considerations - The following scenarios pertain to different considerations and examples: - [Scenario 8](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-8---Slashing-Failure) - [Scenario 9](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-9---Pool-Rescue-Failure) - [Scenario 10](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-10---Pool-Rescue-Failure-from-Bad-to-Worse) - [Scenario 11](https://hackmd.io/QFmCXi8oT_SMeQ111qe6LQ?view#Scenario-11---Pool-Rescue-Exploit) ## Funds & Vault Internal Balances or Just Vault Internal Balances Itamar had brought up that maybe there should not be a funds attribute within the simulation and everything should just be keyed off of DATA balances in the vault. ### Initial Itamar General Thoughts: - the vault is a contract that sits on top of the token contract - the token contract has basic transfers etc, and “more complex transfer logic” is implemented in the vault - thats the idea of the vault, that you can reprogram the logic without changing the state (i.e. the balance map that’s actually in the token contract) Sean General Thoughts: - Isn't the vault more like a custody bank, so funds still exist outside of the vault, and we still need to mock them up? ## Idea of a Lien ### Initial - Z brought up a good twitter thread on the idea of liens - Sean thoughts are that it doesn't quite apply the same way because that capital needs to go to work but it is interesting to think about it this way - Link to tweet: https://twitter.com/lex_node/status/1542214455517388803?s=20&t=QTWqb4JcUz03RYvtDkTJZA - Link to slack discussion: https://blockscienceteam.slack.com/archives/CU5FDDF36/p1656530001576439 # Past/Resolved/On Hold Discussion Topics ## Broker Self Delegation The topic is about the ability of brokers to delegate to their own broker pool. Currently this is not a high priority question and is being pushed down the road for further thought. ### Original Question by Juuso Broker's own stake in a BrokerPool: right now, all capital that a broker deploys comes from delegators; in other words, delegators bear all the risk for broker misbehaviour. Of course the broker itself can also be a delegator (I guess?) and put in a starting capital. Question: should broker's equity be "special" in the sense that it would get slashed first, or at least that prospective delegators would be able to see how much broker has its own bacon on the line? Should there be (from the start in the MVP) different "seniority levels" of equity in case of slashing? ### BSCI Thoughts - This is a good idea, while it may add complexity, it probably is worth the cost of complexity to add safety to the pools - Would likely function similar to first loss accounts in a fund - Generally, it probably makes sense to have a separate variable to track broker stake - When slashing occurs, there would be a waterfall of payments such that first broker funds are taken out, then pool value is decreased - Also likely there would be an additional action when yield is collected whereby if the broker stake < minimum broker stake, all their earnings get diverted back into the pool as funds and it increases this broker stake account value - Would yield need to be weighted differently based upon the amount a broker puts in then? ### 6/16 Discussion Points - The brokers may be well enough incentivized because they have the broker share earnings - This can probably be a future point of iteration but does not require current attention