In order to have multiple shareholders and distribute the mixer’s income in a decentralized manner, we propose a fairly simple approach.
Let’s say we issue share tokens with the quantity of 1000, meaning that the mixer has 1000 shares. In this approach, shareholders keep their share tokens in their wallet (doesn’t matter where) and receive the mixer’s profit proportionate to their tokens every week for example.
The most important aspect of this approach is the income contract. A contract that mixer’s income will be sent to. In this contract, it is being enforced that the income (erg and token incomes) be distributed to all share token holders proportionately every 7000 blocks for example. To enforce the first part, the contract requires all boxes containing share tokens as data input. In other words, it requires the sum of share tokens in data input boxes to be some constant (the amount that we have issued, like 1000). Then, the rest is some simple mathematical calculation and enforcing the proper distribution to the same propositionBytes of the data input boxes.
In the mathematical calculations, only divisible amounts will be distributed and the rest will be kept for the next round. For example, if there are 1000 share tokens and 1500 USD tokens in the income box, then only 1000 USD tokens will be distributed and the rest 500 will be kept for the next time!
Also, there are some parts for the contract to allow the merging of the income boxes.
Moreover, an off-chain code is required to create the distribution tx periodically.
There is one potential issue for this approach; if someone burns some of his share tokens, then the protocol will stop functioning. To handle this, we propose two approaches, a simple one that will be used for v1 and a more generalized one for the future i.e., v2.
-
V1: The amount of circulating share tokens is written in one of the registers of the income boxes. If someone intentionally or unintentionally burns some of the share tokens, then mixer developers can reduce that constant in the register with their private key. There some approaches to prevent the developers to do harm to the protocol; for example, the contract can allow anyone to increase this constant by providing proof that that amount of tokens exist (by providing boxes as data inputs)
-
V2: The second generalized approach involves voting by shareholders. Shareholders can vote on parameter changes in the mixer (this also can involve other mixer’s parameters like current tx fee rate, mixing fee, …)
The main limitation of this approach can be that the distributing tx can be large due to data inputs and outputs of the tx. So the amount of issuing share tokens should be chosen conservatively.
Also, this approach has assumed that duplicate data inputs are not possible in transactions. If this is not the case, additional overhead must be added to the contract to avoid duplicates.
Any comments appreciated.