One of the most discussed topics I have ever seen on this forum is the possible dilution of shares.
I've read dozens of posts and excellent points were made for both sides.
By now I came to the following conclusions:
1. Dilution is an extremely powerful tool to fund development for a DAC/ecosystem. It might not be needed today or tomorrow but to maintain and expand a billion dollar DAC some serious funds are needed.
2. As already stated above dilution might not be needed at all times. Therefore a variable rate is needed.
3. Why are many users (including me) so scared of dilution? IMO this is due to (seemingly) lacking predictability and controllability. That's why it must be priority
to build a transparent, not overly complex, system that guarantees long term predictability.
With this points in mind I would like to propose the following system:
1. Stake can vote on a dilution rate. (As I have no insight into the implementaion I don't know how this can be realized best. (Some set options, Int between 0 and 100 etc.))
2. Stake can vote independently of step 1 on business delegates. Business delegates have to publish details like requested pay per block and time period.
The system works like this:
The dilution rate is fixed for a certrain time interval e.g. one week. With begin of a new time period the dilution rate is adjusted. There are three possible events: either the rate goes up/down by a fixed percentage (e.g. 0.1%) or stays at its current value. All stake that voted on a rate below the current one implicitly votes for an decrease, analogous all stake that voted on a higher rate for an increase and the rest for an unchanged rate. The biggest of the three groups wins. This way the rate slowly tracks the median of the votes.
With the fixed dilution rate it can be calculated how much the network can pay at most to all business delegates together.
Now the business delegates get ranked by approval. This list is traversed starting with the highest approval. If the dilution rate is sufficient to fund the specific business delegate the requested pay per block will be executed and the remaining funds/dilution rate is calculated. If the requested payment is too high and thus the dilution rate would be exceeded the business delegate doesn't get funding. This is done until there is only a certain fraction of funding left (e.g. less then 10% of funds not used) or there are no business delegates left with an approval higher than X%. This has the effect that the real dilution rate is always a little bit smaller than the voted rate. This "buffer" is very important because slight fluctuations in (voted) delution rate don't result in business delegates getting fired.
1. Simple and transparent from a user standpoint.
2. Users can vote explicitly on a dilution rate without analyzing projects, delegates etc. This should ensure high participation.
3. Slow changes in dilution rate which leads to great predictability.
4. Higher payed business delegates tend to need higher approval to get voted in. This supports business delegates that don't have funding in advance for massive PR campaigns.
I guess implementing something like this would be rather complex but hopefully not impossible.