Should Compound Retroactively Airdrop Tokens to Early Users?

As I have stated earlier in the thread, I have lost access to my wallet 0xe84d25b1C4fe0E5A9bEe95934AB24C9867Aac2cc which was used to interact with Compound.

I can prove that the address belongs to me by showing that I sent the USDC from my Coinbase account and then used to supply on Compound.

SCREENSHOT of Coinbase account showing tx hash.

SCREENSHOT of Etherscan showing incoming txns and supplying txns.

I know it’s a lot to ask for, but is there any way that I request the airdrop (if it happens) go to my current Ethereum address 0x7d355f8b12d15213e3C6b187Cb5ca348EcD725f8? I love using Compound and would like to obtain more COMP to vote or delegate votes to be a part of Compound’s governance.

1 Like

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, 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 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, 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?


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

1 Like

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


No issues with using coin gecko.


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.


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!


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:


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 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.

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.


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!


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.


Why hasn’t the cutoff date been set to:

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 !


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.)


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!

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.


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. )


  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!)