Should Compound Retroactively Airdrop Tokens to Early Users?

[Javelin]

So how has this proposal changed now during the dip, guessing its way cheaper for 100 Comp to get governance opportunity?

[CryptoCraig]

20 COMP, IMO, is perfectly fine for early users. Maybe even 5 or 10 COMP. I understand that COMP holders need 100 COMP to have increased utility, but I think less is better because COMP’s token value is quite substantial. Airdrop tokens to as many users as possible for decentralization purposes. I’m not sure exactly how much liquidity addresses provided to COMP during the early stages. I keep looking at the current COMP value and thinking, Compound is seriously talking about AIRDROP-ing over $40,000 worth of COMP tokens to early users?!?

I believe that Compound has problems brewing on the horizon due to lack of decentralization of the COMP token itself. I’m for anything that can further decentralize the token.

I’m saying it was AWESOME for those early users to get the protocol started, truly it is awesome. However, those people chose to use the Compound Protocol because it was developed nicely and made liquidity easy while providing them with interest on their crypto. Early users didn’t use Compound thinking “one day I will get an airdrop for using Compound”. And really, if they did expect an airdrop, those are gonna be the people who do EXACTLY what Compound does NOT want… Dump tokens.

[dabar90]

I agree, it doesn’t matter so much whether the airdrop will be 5, 10 or 20 or 100 COMP tokens if the distribution is largely social weighted. Dump can be expected with higher capital weighted parameter

[bulajacky]

thank for your helping
is any good news?

[CryptoCraig]

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.

[allthecolors]

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?

[ogamiitto]

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

[ogamiitto]

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

[Fishbtc]

No issues with using coin gecko.

[allthecolors]

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.

[ken-galaxy]

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!

[blyprot]

@ken-galaxy

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.

[allthecolors]

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:
Early-user addresses by total interest accrued
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 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.

[prestonvanloon]

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.

[allthecolors]

@prestonvanloon

9555730

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!

[allthecolors]

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.

[voodoorider]

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 !

[Andre1]

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

[massnomis]

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

[CryptoCraig]

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.