The community vote showed a strong preference for having multiple winners in the weekly Dai pool. 76% of voters signaled a desire for 2-5 winners, the second most popular option was no change which 13% of voters signaled for. See full votes here.
Proposed Implementation
The proposed implementation is making three weekly winners, one winner would receive the Loot Box and the other two would split the interest prize. It’s possible that the winners of the interest prize could be increased later as the pool grows in size. However, for technical reasons it is important that one wallet wins the the full Loot Box.
The proposed implementation would also be structured so that the same wallet could not win more than one prize.
Timeline
Development work is commencing this week 11/16 with an audit starting next week 11/23. Assuming the audit goes smoothly it can be implemented shortly after.
Edit 11/17
I was slightly mistaken on how the code has been written for implementation. The actual code has been written so that all winners will split the interest prize and one winner will ALSO receive the external prizes (Loot Box). What that means is there will really be one grand prize winner who receives most the value and the second and third winners will be smaller prizes.
I’m totally onboard with multiple winners! However, forcing the prize to be won by 3 different players changes the expected value to unfairly favour addresses with fewer tickets.
Let’s take an extreme example:
Imagine there are $100 in the pool and three participants. For simplicity we assume the Loot box has the same value as the 2 interest prizes.
A has $90 in, B has $9 in, C has $1 in.
In the draw of the first prize, A wins.
In the draw of the second prize, A should once again have a 90% chance of winning but is now blocked as he already won a prize. So B wins.
In the draw for the third prize, only C is left. So C wins.
Now A,B,C each won 1/3 of the total prize, even though A contributed 90% of the interest that even made that prize possible, B contributed 9% and C only contributed 1%. Obviously, A is being taken advantage of.
This was not bad luck. In this situation the outcome would always be the same, no matter the randomness generated.
So what would A do if he was smart? He would spread his coins among a bunch of addresses that hold a few coins each. And B would do the same. Theoretically, distributing your tickets over infinite different addresses with a tiny sliver of a ticket is optimal (ignoring gas fees).
I don’t think incentivizing the creation of useless wallets is good for anyone. All it accomplishes is wasting gas and clogging up the Ethereum network even more than it already is.
Of course, this example I shared is an extreme case, but the same principles apply to any distribution where there are holders with different amounts of tickets.
It wasn’t working in the end on Ropsten cause I think you can’t have several RNG numbers.
So one way you can do this is get one random number and then split the number of tickets by the number of winners to get the next random number. It has his flows since the next random number isn’t totally random since it’s based on the first random number, so a whale with a lot of tickets could end up being the next winner most of the time.
Might actually be an interesting thing to experiment with using a time-weighted factor for choosing the winner of the loot box - wherein we’re incentivising people who deposit for longer time periods to be much more eligible for winning the loot box.
Any thoughts on whether this is possible @Leighton?
That would be cool, I don’t believe that is possible. I do like the idea though of essentially having a bonus prize for the ticket holders. @Brendan is this possible?
We divide the token supply by the number of winners, giving us an “offset”.
The first winner is selected using the random number
Each time we select a subsequent winner, we add the “offset” to the current random number.
Once all of the winners have been selected, the interest prize is evenly distributed among them.
The selection of a winner does not impact any subsequent winner selections, so we see that everyone has the same chance of winning for each winner drawn.
This is the fairest method to everyone, as it simply selects from the same Pool N times.
This may be possible, but we would need to some research to figure out a data structure to support that. At the moment dynamically changing the probability of winning is impractical.
That being said, we are exploring way to reward users continuously so that they benefit from being in the pool longer.
I think we have to go with some notion of practicality here. I do agree with @mitto’s standpoint that the outcome isn’t truly as random as choosing a 3-member subset out of n participants; but the difference in probabilities affected would be off only by a factor of roughly 6. This may seem large - but would tend towards the same outcome as the number of participants grows larger.
Furthermore, if we do end up seeing a lot of deposits to the pools (maybe the community could decide upon a certain prize threshold), maybe the PoolTogether team could evaluate the additional gas costs incurred in implementing some version of reservoir sampling and we should be good to go!
I must say, I was really disappointed to see the same wallet win twice in the same drawing. That’s NOT how I thought it was going to be implemented. Why can’t the little fish have a tiny bit of an edge by allowing a wallet to win at most 1 of the 3 prizes?
I understand this may incentivize people to break up huge wallets into multiple smaller wallets to play, but if they want to do all that extra overhead, then let them. Smaller wallets winning more often will attract more users.
That is all.
-Michael