A potential solution for duplicate winners

1

I have seen some discussions around this topic with some various solutions. Spanning from preventing someone winning more than once, to creating specific pools where you can’t have too many tickets.

I’m personally of the opinion that it’s unfair to prevent someone from winning multiple times. I appreciate that the pools are worth what they are due to the high numbers of tickets bought by a small handful of addresses. Without them the prizes wouldn’t be as impressive.

Similarly creating a separate pool with ticket caps might just achieve two things:

  1. The larger investors don’t take an interest

  2. They simply spread their tickets across multiple addresses.

I was thinking about this issue and came up with a slightly different approach. I haven’t seen this in the forum yet, so I apologise if it has already been raised previously.

My idea was to have subsequent wins decrease slightly in value, by some X percent, which scales with the subsequent number of wins. With the value of these decreases being distributed among all ticket holders, proportional to their position.

For example,

The current setup is

Total winnings per winner = (prize / numberOfWinners) + (loot box [if first])

For the purpose of this example I’ll ignore the loot box, but the first winner will still always receive it.

Proposed setup

This will only occur if the same address wins at least twice.

Say there are 3 winners in the pool and each winner receives 33%, the new setup would look like:

Win #1

Address receives 33%, as normal

Win #2

The second subsequent win is decreased slightly in value and the difference is distributed proportionally.

Say the decrease factor, X, = 5%

Address receives 33% minus (5% of 33%), which is 33% - 1.65% which is 31.35% of the prize and 1.65% of the prize is distributed proportionally.

Say then that they win all 3

Win #3

Address receives 33% minus (2 times 5% of 33%), which is 33% - 3.3% which is 29.7% of the prize and 3.3% of the prize is distributed proportionally.

Hypothetically if there was a 4th win in a row then it would be 3 times the X factor, and so on.

Using a real example if the prize was $100,000 and the X rate was 5%

Win #1 = $33,000 with no distribution

Win #2 = $33,000 minus 5% of $33,000 = $31,350 and $1,650 is distributed.

Win #3 = $33,000 minus 2*5% of $33,000 = $29,700 and $3,300 is distributed.

In this example the duplicate winner will receive $94,050 of the $100,000 prize and the other $5,950 is distributed proportionally.

Things to consider

  1. What should the factor of X be? 1%, 5%, 10%?

  2. Should X increase for each consecutive win?

  3. Should the duplicate winner also receive part of the distribution? I personally think they should, as again, they are largely contributing to the prize.

I love the concept of Pool Together and I feel this change might attract more players. Looking at the odds of the high holders can be a little daunting sometimes. This at least gives people the chance to earn even a small amount in the event that a large holder wins multiple times.

For those who stuck around long enough to read all this I appreciate it and welcome any feedback.

7 Likes
2

Good proposal, I think something like this could work v well

  • The distribution of “retained winnings” to everyone would incur a high gas cost, so prob better to rollover to the next prize
  • An alternative could be, if address ABC has won in the past [insert time period] then reduce winnings by X% and rollover to next prize
1 Like
3

Hi and welcome to the forum! Unfortunately, your post must have gotten burried in all other proposals.

It’s certainly an interesting take, but unfortunately, I think there are a couple of drawbacks:

  1. First, you’d have to keep a ledger of past winners, which I assume will be costly (in terms of gas the contract has to spend), but maybe I’m overestimating the gas costs of implementing something like this.
  2. This proposal seems to suffer from a similar issue as others, namely that it is not really possible to enforce playing within the proposed rules. Big players could still split up their deposit or once they have won, withdraw and redeposit it (from a different address). The only thing we can currently do to prevent the latter is set a high early-exit fee, but that is limited to three weeks, so it does not help that much.

Note that the PoolTogether devs are currently looking at redesigning the complete system to be much more flexible in terms of prize allocation strategies and in the future we may be able to experiment with fun proposals like this.

1 Like
4

I don’t know if you need a ledger, I interpreted this as awarding in a box. Each award would only consider that award. So if the same wallet won two weeks in a row it wouldn’t make a difference. Like if Yearn won all 3 prizes for 2 weeks, the first prize nets 100%, second 95%, third 90% each time. Which I think is certainly an interesting idea.

For you second point, I can’t imagine that being a large problem. With the percent “cut” (5% for each consecutive win in a single awarding) the return for multiple wallets would be awful small. But if that “cut” gets outsized say 10% compounding for each consecutive win in an awarding, I think there’s an increasing change that multiple wallets becomes a more sustainable return on investment. It’d just be another balancing act for governance to try and maintain.

It should be interesting to see if this is something we’d be able to experiment with in the next iteration from PoolTogether Inc., I think this approach is really interesting. Downside for me is if this were the USDC pool, which has like 2100 unique wallets in it, everyone would receive about 2 USDC for that week where the same winner won all 3 prizes. Not very exciting, but I suppose it’s better than 0.

2 Likes
5

I interpreted the proposal as diminishing returns per prize spread over multiple weeks, hence the need for a ledger. If that’s not the goal, the implementation does indeed simplify a lot.

My second concern of this being gameable is also less relevant if we are just looking on a per-week basis. You are correct that in the end it all depends on the cut-percentage. But, no matter what the actual idea looks like if a big player like Yearn tries to maximise profits (which is what their vaults attempt I think), they can easily circumvent this by cutting their total deposit in a couple of parts.

I am al up for trying things like this though and I am quite curious if PoolTogether v4 will allow something like this. :slight_smile:

2 Likes
6

Yeah to clarify I was thinking multiple winners in the same draw, sorry if that wasn’t clear. Although I don’t see why you couldn’t apply this over multiple draws. I’m assuming this data is stored somewhere since you can currently see winners going back historically in each pool. I liked it being in the same draw because it seemed fairer than cutting winnings a week later. I would only think it would be reasonable to carry it over a week max anyway. I definitely see the concerns about them just spreading their tokens multiple wallets (your point #2), but I think this’ll just always be a concern no matter the proposal. I have a full appreciation now for how complicated this problem is :smiley:

3 Likes
7

Other side thought I had, if redistribution to everyone is impractical then perhaps that extra X% could just be diverted into the pool as extra interest generating capital.

1 Like
8

The winners are elected through a transaction and stored on the blockchain. You can see them easily on a website like the one that PoolTogether provides because the website queries the blockchain. However, a smart contract can see only see its own local state. As far as I know, it cannot access the past transactions it executed on the blockchain or any data outside of its own contract code and variables (which is why I was saying you need to save the past winners in some contract-local ledger) without the help of an oracle.

Depositing it into the reserve would certainly be possible and a lot less costly for the contract.

1 Like
9

I like this idea!

I 100% agree with the main principle behind it – we need to have more people winning.

The V4 prize pool design is currently being built it – it doesn’t function exactly like this but I think it will reach your goals :slight_smile:

3 Likes
10

Unfortunately I don’t think this is very different from not allowing the same address to win several times.
It has the same issues of being unfair to large depositors and being able to be circumvented by using multiple accounts (Sybil attack).

11

I feel like the gain they would get from multiple small wallets to harvest, on top of the whale wallet to win reliably becomes prohibitive due to gas. On L2’s it could certainly be an issue, but on Ethereum… To be a whale that’s say 33% of the total pool, and then have 100s of sub-wallets to farm the residual disbursement from the 5-10% the whale didn’t get from already winning multiple times seems a little outlandish. Especially when taking into account the recurring argument that whales are here to farm POOL not collect prizes.

1 Like
12

Well said, Whales don’t create 1000’s accounts in Ethereum and claim from each wallet just circumvent the 2nd prize they are anticipating. Gas fees too high to do Sybill attack. I think the dev team may have challenge implementing this proposal.
Small fish loose hope on prize if yearn win 3 out of 5 prizes every week . Big whales just dumping pool tokens on small fish.

1 Like