Should Compound Retroactively Airdrop Tokens to Early Users?

Hi all, I’ve pushed a few updates to the project github and thought I’d accompany that with a progress report here.

The introduction of cTokens in V2 marked a significant shift in how interest is managed in Compound, so I’ve found it easiest to analyze early user interactions with V1 and V2 separately with intent to merge the results at the end.

For each version of the protocol, I’ve separated the process into four steps:
(1) Pull all early-user transactions on-chain with relevant Compound contracts within the early-user window, whether EOA or contract-mediated
(2) Determine the end user associated with proxy contracts so that the underlying user is credited, while ensuring credit for smart contract wallets remains with the contract which represents the user
(3) Calculate each early user’s cumulative supply and borrow interest in each asset from raw transaction data
(4) Use price history data to translate cumulative supply and borrow interest into a single USD- (or ETH-)equivalent interest.
I believe it may eventually prove easier to perform steps (3) and (4) in tandem, but I’m separating them for now to make it easier to check the accuracy of each step independently.

The final cumulative interest serves as a “capital weight” for each user, replacing the cruder metric described in my earlier proposal for defining a capital-weighted component of an early-user COMP distribution.

Steps (1) and (2) are currently in good shape, other than some clean-up and provision of a more automated workflow for others to reproduce the csv files.

Steps (3) and (4) are on their way but still in-progress.

  • For step (3) in V1, CompoundV1.interest.py is a working implementation for V1 that passes my sanity checks and is available for public review. I’d be especially grateful for any feedback from devs familiar with the interest calculation for V1 to let me know of any potential edge cases I might have missed. I’m aware of one minor edge case involving liquidators that I have a solution in the works for.
  • For step (3) in V2, I’m troubleshooting an issue with CompoundV2.interest.py that appears to be contract-related, but a basic approach to computing V2 acculumated interest is implemented there and available for review as well.
  • For step (4) in V1, CompoundV1.USDvalue.py offers a proof-of-concept for appending USD price data to the raw transaction histories using the CoinGecko API for historical market data. If anyone has concerns with using daily CoinGecko price history data instead of using the on-chain Compound open price feed, please speak up! So far I am going with this approach because it is easier and more intuitive for me to implement while having negligible impact on accuracy, but I am willing to take the time to figure out how to do it with on-chain data if that’s what folks need to see in order to support an eventual proposal.

I’ll report back on steps (3) and (4) as they come closer to fruition. In the meantime, I think it could be constructive to have some parallel effort on crafting a clear, organized, and concise rationale for governance to support an early user distribution. Anyone want to start collecting the relevant input from this thread and merging it into a collaboratively editable document?

17 Likes

How will the amount of distributed COMP relate to your weights analysis?

1 Like

I’ve created a repo to create a rationale.md file collaboratively with the community.

2 Likes

No issues with using coin gecko.

2 Likes

Here’s the latest on the early user analysis:

  • At each transaction in the early-user history, accrued interest is now converted into a USD equivalent based on the price of the asset on the date of the transaction from the CoinGecko API. This is now implemented for both V1 and V2.
  • For both V1 and V2, the most complicated step IMO is the reconciliation of interest accumulated in the period between the last transaction as an early user and the EarlyUserCutoffBlock. This step is essential for proper handling of users who deposited/borrowed very early on and simply held their position(s) through and beyond the EarlyUserCutoffBlock. The updated scripts now handle reconciliation of outstanding early-user supply and borrow interest for both V1 and V2.
  • I’m continuing to sanity-check the output for addresses with increasingly complex transaction histories.
  • For V2 interest, I’ve traced back the contract-related issue from the previous update to whether to credit borrow interest on RepayBorrow() events to the payer or to the borrower in the event that these are different addresses. I had initially chosen to credit the payer, but I realize now that it needs to be credited to the borrower (sorry payer), otherwise we mess with the tracking of accountBorrows in a way that causes certain contracts to get showered with more accrued interest than they should.

Once the results are updated to account for this latest change, I’ll post output with a list of users and their accrued supply+borrow interest (in USD-equivalent at the time of accrual) across all V1 and V2 assets during the early-user window.

In the meantime, I should note that in cleaning/reorganizing the early user analysis Github repo, the location of the version 1 distribution lists has changed. The link posted earlier in this forum will no longer work. These obsolete files are still available in the version_1 folder in the Github repo in case you have reason to refer back to them.

16 Likes

We have also posted an idea about the loyalty NFT badges for community members. Project Galaxy - Helping to build Compound's first NFT-based Loyalty Campaign!

It can be done along with the token airdrop to early adopters!

3 Likes

I think that’s pretty cool.

1 Like

Hey everyone! The challenges and edge cases highlighted in my previous post are now all accounted for in the latest update to the early user interest analysis.

Here is the key result:
:comp: Early-user addresses by total interest accrued :comp:
Here is the same information in histogram and pie chart formats:


TotalUSDinterest.piechart

The USD equivalence is based on the USD value of the asset in which interest was accrued, on the date of accrual, as reported by the CoinGecko API. The analysis includes outstanding interest from supplies/borrows still active at the early user cutoff block which would otherwise have been neglected since there’s no associated on-chain event in this case.

A few notes about this new list:

  • This is not a proposal for how much COMP to distribute to early user addresses. Rather, this tally is intended to provide a more precise way of assessing early user capital deployed to the protocol during the early user window relative to the crude capital weights introduced in the April model.
  • The median address’ accrued interest over the early user period was approx. 35 cents (0.35 USD).
  • Fully 20% of early user addresses accrued interest that, rounded to the nearest cent, is zero. However, every address on this list interacted with the protocol during the early user window, resulting in formally non-zero accrued interest.
  • Many of the addresses whose accrued interest rounds to 0.00 deposited hundreds of USD worth of value to the protocol for a few minutes or hours; others deposited smaller amounts for much longer periods of time. This may be useful information for the community in reflecting on whether to adopt any minimum on accrued interest for inclusion in a proposal.
  • The parent script runAnalysis.sh includes a line implementing the request from @CryptoCraig regarding an inaccessible early-user address. Recognizing the potential for controversy over any direct modifications to the list, I felt it was important to explicitly point it out for the sake of transparency.
  • Because this address list no longer makes any distinction between contracts and EOAs, we can expect that the composition and weighting of addresses with the largest capital weights will look quite different from that of the previous model, and indeed it does. That said, several EOAs from the previous list remain in the top ten.

The tool now passes my sanity checks, so I’m hoping others will think of sanity checks orthogonal to mine to further boost confidence in the results and detect/fix any remaining issues. FWIW my checks have mostly taken the form of manual inspections of hand-picked addresses with specific types of transaction histories across V1 and/or V2, via etherscan. Examples: only supply/redeem interactions; only borrow/repay interactions; addresses that have done all four of these actions in just one or two assets; addresses that have been on one side, the other, or both, of a liquidation; addresses with outstanding supply or borrow balances at the EarlyUserCutoffBlock to check reconciliation of outstanding interest; and last but unfortunately not least, addresses that have traded cTokens on secondary markets, as those trades – to my chagrin – throw off internal balance tracking in ways that can falsely imply a negative interest if not accounted for.

I’ll be here to field questions and revisions based on community feedback. Thanks again to the Compound Grants program for supporting the early user interest analysis!

What comes next?

  • Community review of this analysis and requests for follow-ups. What other summary or detailed early usage info, if any, should we be extracting from here? Identification of the largest contracts seems worth pursuing, to get a better idea of whether the proposal needs to contemplate handling these differently from simple addresses.
  • Community development of a brief written rationale summarizing the case and value proposition for an early user distribution of COMP. I think it makes sense to build momentum on this before returning to consensus-building on the specific details of the proposed distribution, to avoid “putting the cart before the horse”: The rationale should inform the shape of the distribution, not the other way around.
  • @ogamiitto set up a github repo for collaborating on a rationale (thanks!), but it hasn’t had any activity in the two weeks since it was set up. I’m guessing that’s in part because it’s a little more involved to make edits/comments and less accessible for many among us who aren’t using github on a regular basis. We could use a collaborative editor like a Google doc, or maybe CryptPad if folks would prefer something more privacy-oriented?
  • I think it is a good time to pick up on this thread’s previous discussion of a mechanism for realizing an early user distribution of COMP. Several good ideas have been floated, with key features including some kind of vesting. I have a couple of ideas here which I’ll save for a separate post after folks have a chance to digest this analysis.
18 Likes

Thanks so much for this report. I am still wondering about the value for EarlyUserCutoffBlock. It seems to be Feb 20, 2020, but the COMP announcement wasn’t until Feb 26, 2020. I’ve left some feedback earlier in the thread about this to consider block 9555730 as the canonical “latest block before the information became public”. As we do not know the exact time the announcement was made, the oldest block prior to Feb 26, 2020 00:00:00 seems to be the most logical choice. Should Compound Retroactively Airdrop Tokens to Early Users? - #295 by prestonvanloon

Is there any reason for Feb 20? If you could, link to the timestamped announcement that occurred on Feb 20.

2 Likes

Good catch, sorry about that – I had meant for EarlyUserCutoffBlock to be 9555731 throughout, and it is in the USDinterest scripts, but the first script of the pipeline is still using the earlier block which cuts out interactions in the Feb 20-26 window. I’ll update the source and link above once those are back in, thanks!

3 Likes

An additional issue with the reconciliation step was brought to my attention by a Compound Discord member that should only affect addresses that only received cTokens via direct ERC-20 transfer (i.e. not mediated by Compound), and nothing else. If these are self-transfers, e.g. to/from cold storage, the issue only affects how your accrued interest is assigned across your accounts, but not the total interest. Still, it’s a relatively easy fix; I will update when this is corrected.

2 Likes

Why hasn’t the cutoff date been set to:

idgm
Let’s keep @alive date.
June 8, 2020
Don’t change it.

? I though this date was kind of agreed on already.

And thanks for the amazing work @allthecolors !

2 Likes

Thank you allthecolors, appreciate the quality of the work you provided. This is a beautiful pie chart with a much more spread distribution.

These data that you gathered permits now to remove any arbitrary in the results. With this it become much easier to come up now with a discussion as they permit to measure the usage of the protocol for the interest rate market which is Compound. It will need then to be decided the importance of the capital weighted part of the allocation.

I sent a pm to avoid to fog this thread, about the preparation you mentionned, trying to gather all the ideas of this thread.

(For what it’s worth : I could not check the code used itself but tried to hand pick a dozen adresses, the biggests and randoms : the numbers seemed to match up with etherscan datas.)

2 Likes

speaking of comp, Add markets: stETH we would love feedback

1 Like

This proposal has turned out to be huge and very detailed. Thanks @allthecolors for your work on supplying the Compound Community the data needed to make an informed decision!

This is what the community needs to figure out from this data in order to submit the proposal: (my opinion)

  • Weight distribution:
  1. Percentages based on social and capital provided? (90% social, 10% capital. With the cutoff for getting the capital distribution being addresses which earned greater than $100 interest. Just by eyeballing the list, those addresses represent about 10% of all accounts.)

  2. Should we handle contract addresses differently than individual accounts? (No, unless the capital distribution is diluted by not having a minimum amount of interest earned.)

  3. Any other metrics that need to be considered, based on this data? (Probably a lot of different metrics could be considered, but I feel these 2 metrics are the most important, and therefore, all that’s needed for Compound’s early user distribution.)

The Compound Community’s input is always welcome and encouraged!

EDIT:
Maybe since such a large number of addresses earned $0.00 interest we could use the median interest earned ($0.35). Addresses below this threshold will be distributed 30% of the social distribution. Addresses above would get 70% of the social distribution. This would effectively distribute more to users who risked more capital, without it being to skewed.

2 Likes

Oldest block prior to public announcement is obvious choice block 9555730 as @prestonvanloon references above and @allthecolors cites from a couple days ago. (Feb. 26th, 2020). Awesome work @allthecolors !

1 Like

I still don’t really get why the date was set to public announcement of COMP. Could someone elaborate a bit more why that is such a good candidate?

1 Like
  1. Percentages based on social and capital provided? ( 90% social, 10% capital. With the cutoff for getting the capital distribution being addresses which earned greater than $100 interest. Just by eyeballing the list, those addresses represent about 10% of all accounts. )

—-My recommendation would be $50 in interest where those that may have not provided as much collateral but may have used the protocol longer and would be more inclined to continue supporting the protocol.

  1. Should we handle contract addresses differently than individual accounts? ( No, unless the capital distribution is diluted by not having a minimum amount of interest earned. )

—Agreed

  1. Any other metrics that need to be considered, based on this data? ( Probably a lot of different metrics could be considered, but I feel these 2 metrics are the most important, and therefore, all that’s needed for Compound’s early user distribution. )

—- Agreed that these two basic metrics provide the most universal way to apply for distribution.

1 Like

The proposed date of June 8th 2020 was quite widely publicised around the Ethereum community. It seems a shame to change it now. It would likely create a negative sentiment towards the Compound protocol amongst a number of early users, who are now going to miss out. I know many who have been following this thread closely for many months.

I am one of the users who would stand to benefit from a June 8th date, so I am of course somewhat biased. But I am also conscious of the 23.1k views on this thread, and how widely it was shared on Reddit, Discord, and other crypto communities. So it wouldn’t just be me missing out! Many in the community checked their address against the previously posted distribution list. They would now be disappointed to be cut out.

I should also note, that in a informal poll in this very same thread, the original distribution list was widely supported: Should Compound Retroactively Airdrop Tokens to Early Users? - #232 by allthecolors

This also creates a “black hole” between February 2020 - June 2020 where no Comp was distributed to users during that period (before distribution begun, but apparently too late for an early user airdrop).This seems strange to omit this one time period. The logic only appears to be on the basis of the announcement of an upcoming COMP token on Feb 26th. But there was absolutely no indication of a retrospective airdrop being on the cards at that time.

So, why now change the date, when the originally suggested date appeared to be widely supported? There is not really any clear indication in this thread as to why the date was changed since that poll was conducted back in April. A date change was suggested by one user in the thread following the poll, and it is in fact the suggested change of date which appears to be the main point of contention for some posters here. Nobody seemed to have a major issue with the originally suggested date.

I totally support the work to include more accurate capital weights, and make sure anybody who used the contract is included. But it seems we have included those extra users, at the expense of others included in the previously proposed distribution list.

It is clear a lot of time and effort has gone into making this proposal work. Thanks @allthecolors for the great work. I am sure the governance process will come to a sensible decision on these matters, and get this proposal into motion. These are just my thoughts (as a biased person admittedly!)

-Sku

3 Likes

Increased COMP distribution to large funded groups/individuals that already received and continue to receive a large portion of COMP through interest generated payments would not achieve/drive the overall goal of a decentralized governance but rather lead to increased centralized control.

Which legally and from a conflict of interest perspective may be detrimental to the future of the protocol as we saw with EtherDelta and Uniswap respectively.

I.E.
“Parties with conflict of interest pushing through pro- posals (Uniswap-Dharma): A recent example of conflict of interest took place during Uniswap’s first proposal, made by Dharma, to reduce Uniswap’s existing governance thresholds. Dharma had 32% of the voting power at the time of the proposal while the second biggest voter had 30%. Dharma’s made two proposals. One was for a reduction of the amount of tokens needed, in order to submit a proposal, from 1% to 0.3%. The second one was for a reduction in quorum, or the percentage of the total supply which must vote on a proposal in order to pass, from 4% to 3%. Dharma claimed that these two proposals would give the ability to smaller token holders to make proposals and also it would be easier for important proposals to not get rejected since many token holders do not bother voting. Dharma might have had the right intentions but looking at the numbers many could infer that these proposals could easily give more power to Dharma itself on governing Uniswap’s protocol. Uniswap total (not circulating) supply is 1 billion. Under the initial protocol rules, 10 million tokens would be needed in order to submit a proposal and 40 million tokens for the proposal to pass. Dharma’s proposal was for a reduction of these two numbers to 3 million tokens and 30 million tokens, respectively.
Considering that Dharma’s voting power is 15 million tokens or 32% [8] of the total voting power, while the second biggest voter has 30% of the votes or 14 million votes, by reducing the quorum threshold to 30 million, Dharma and the second biggest voter (Gauntlet) could combine voting power to push through any proposal these two believe would be best for Uniswap or them.”