Hi all,
I believe there might be more addresses seeing as mine is not part of those results. I was in the Dai pool pod.
Thanks
2 Likes
Can you please post or DM the address you believe is missing and I will investigate?
2 Likes
Please DM me on discord : Anonyme.eth#2513
I’m in. Thanks for your work!
i support this. those early users should be retroactively included
I am in support of this. I’ve seen other DAO projects willingly leave behind qualified users which not only sours the decentralized voting mechanics but also the community members that are left out. I’ve been on the side of missed airdrops, the financial value lost sucks but losing that voting right is even worse.
2 Likes
@ssSuttonSss has a friend who is a developer and is interested in helping out with the redistribution.
If they proceed, the community will need to decide:
The community will need to agree on:
- What the new distribution will be
- What the compensation is for the developer
1 Like
非常赞同这个提议，当池中只有5000美金时，我就试着加入1DAI，但是当空投代币是，我发现自己没有这让我非常沮丧。 
StakeDAO didnt include zkSync Gitcoin donors into their airdrop allocation initially even though a Gitcoin donation was part of their criteria for a drop. So while everybody got their tasty airdrop, i ended up with about half the amount i was initially qualified for as their airdrop value had a fall-off each day it went unclaimed. I COULDNT claim it!
I think its important we make users who qualified completely whole for the drop. At this point in the protocols life, i care more about fair treatment of our users than almost anything else. The protocol and its POOL voters need to be seen as a fair bunch who vote in the interests of the community and NOT themselves.
4 Likes
I’m not sure I can agree with this comment more! I had an extremely similar situation with StakeDAO as you and it was simply unfair.
I would want any form of drop to be fair to all qualified users. For this to be effective, having a clear understanding of the initial drop parameters is important. My Guess on the rewards (beyond the listed criteria) are:
- Amount of DAI/USDC held in PT
- Time with a PT deposit?
List of distribution as per the POOL token launch:
- 14% of total POOL supply distributed to all POOL depositors across the V1, V2, and V3 protocol up until January 14th 2021 at midnight UTC. This is 17,072 unique addresses.
- 12.44% of total POOL supply distributed to early core team contributors (locked for one year)
- 7.52% of total POOL supply distributed to PoolTogether Inc investors (locked for one year)
* 5% of total POOL supply allocated to an initial 14 week depositor distribution (details below)
* 2.5% of POOL supply allocated to onboarding and education of new users
* 1% of total POOL supply distributed to addresses that voted in the first two snapshot governance votes AND held a PoolTogether deposit at the time of voting.
@Leighton Do you have any other insights on how rewards were calculated, or is there data to apply the same parameters to a potential POD drop?
4 Likes
Do we have enough info to generate a proposal to fix this item? It appears to have unanimous support and getting this out there and supported can only be good for PoolTogether.
6 Likes
It takes a long time, it seems no one who has tokens cares about the injustice that happened in the distribution. That’s the way a community works.
2 Likes
reminds me on !inch Airdrop , where i qualified and was left out -like many more
2 Likes
@Leighton @aodhgan @Brendan : Can you provide what the initial drop parameters were for the original airdrop. I feel @AndyKaufman is onto something with:
@aodhgan do the results in the google doc cover everyone that was missed?
@gabor @0xSiam @Torgin @brian_rabbitholegg : Would any of you be willing to sponsor this if a PTIP gets put together? Is there anything else you’d need to know for this? Your the lucky few I could find at’s for on this forum. I’m willing to take a crack at getting a PTIP drafted.
2 Likes
The Google Spreadsheet has four sheets:
-
retro-query-fork: is the true distribution. Includes all past recipients and the pod users that missed out. -
retro-query: is the original distribution. This does not include certain Dai and USDC pod users. -
missing_usdc_pod_addresses: are USDC Pod addresses that missed out on some of the POOL. They may have received POOL for other reasons. -
missing_dai_pod_addresses: are Dai Pod addresses that missed out on some of the POOL. They may have received POOL for other reasons.
You may notice that the users in the original distribution all received a little more than in the amended “fork” distribution; that is because the POOL for the missed pod users was distributed over everyone else.
I think the simplest thing to do:
- For all of the addresses missing tokens calculate how much they each missed
- Create a new sheet with the updated amount
Then proceed as I outlined previously
1 Like
Thanks for that @Brendan, very helpful. I took a spin through the workbook to try and derive the total pool owed to those missed, from my current work it looks like just under 60k POOL will need to be distributed:
I encountered 5 different groups, can a developer check this over to ensure I’m looking at this correctly? It appears that some of the “missing wallets” weren’t missing, others were missing but not in either of the missing lists, and some wallets received partial distributions of POOL (both in and out of the missing lists):
- Highlighted in Purple: These wallets were identified as missing but do not appear to be
- Highlighted in Dark Green: These are the missing wallets that need a full distribution
- Highlighted in Light Green: Missing wallets that need a partial distribution
- Highlighted in Yellow: Wallets not identified as missing but require a partial distribution
- Highlighted in Red: Wallets not identified as missing but require a full distribution
A brief summary of my approach:
- I created a new sheet as a Copy of “retro-query-fork” and performed the following
- Columns A and B: AND and OR function on Column C and D to make sure everything makes sense.
- Columns C and D: MATCH on the missing address lists to pull out what addresses need to be reimbursed (in theory).
- Column G: Brought over the disbursed amount from “retro-query”
- Column H: Compared the amount actually disbursed to the amount that should’ve been disbursed
- Highlighted the five groups mentioned
- Column J: Brief comment to summarize thoughts
- Column K: The amount needed to disburse.
3 Likes
Great! Thanks for your work!
1 Like
@aodhgan are you the appropriate person to tag to review the worksheet? Want to ensure my interpretation is correct before moving forward with a PTIP.
Hey Everyone,
I’ve been working with a developer, @McOso to get this thing moving. We’re at a place now where we’re looking for those with technical know-how (forking git, merkle trees, Rinkeby testing, etc.) to validate the effort.
Oso’s forked git repo is here, please open it up and let us (me or Oso) know your thoughts or concerns:
- Does the README make sense?
- Are you able to recreate the Merkle Distribution file?
- Does everything look good, the file you created matches the file Oso created?
- Anything I may have not thought of?
If any of the previously missing wallets is comfortable with testing on Rinkeby
- Do the directions at the bottom of the README make sense?
- Are you able to claim your test tokens (WEENUS)?
Currently we’re looking at the claiming process for this. As it stands missed wallets would have to manually claim their POOL similar to what’s explained at the bottom of the README. However, Oso may be able to create a claims page, where a wallet would click a button on a page to claim their POOL - developing this would delay getting this vote on-chain.
Is there interest in the “one-click” claiming page?
- Yes, you can take some time to make that
- No, I want my missing POOL ASAP
- Abstain, I’m indifferent but thank you for everything
0 voters
3 Likes
Great work! Your work is awesome!
1 Like