its very reasonable… it should use to compound directly and not via other platform.
1 Like
I agree with you, obviously no one has anything against retroactive distribution (airdrop). I think a good question is in what social: capital weighted ratio would the potential distribution be?
My view is that retroactive distribution should be more user-oriented than capital-intensive. A large share of capital weighted distribution potentially leads to even greater governance cartelization.
I think it doesn’t matter with what type of wallet the users interacted to protocol. I’ve never used SC wallets so I don’t know if there is any big difference but EVM also treats external and contract accounts? If the distribution is social in any proportion, exclude the SC wallet is nonsense.
2 Likes
@allthecolors we made a pull request to update the DetectContracts.py script
see: Include Argent wallets
We didn’t resubmit all the CSV files as we assumed you’d run all the scripts once again but we can do it if needed. Let me know if you need anything else.
2 Likes
@Mr_Drongo you don’t interact via a Proxy in Argent, using Compound within the Argent app or using wallet connect in Argent would be exactly the same. So I don’t see any rationale to exclude them.
This would be like excluding Windows users, or Firefox users. Users were interacting with Compound directly, with Compound branding all over the place and getting ctoken in their wallet, no intermediary.
I think a lot of people seem confused about what Compound is. Compound is a decentralised protocol, not a centralised front-end.
7 Likes
Excluding smart contracts is a dangerous approach that disenfranchises most users, and I will actively fight against it. Any address (msg.sender) that supplied assets or borrowed from the protocol is a user.
From day 0, Compound was designed as a protocol for developers to build interfaces and applications on top of. The interface built by Compound Labs was one of many ways to access Compound.
Tons of different users & wallets use Compound with a smart contract (Gnosis multi-sigs, InstaDapp, Argent, Dharma, etc). Rather than excluding smart contract users, and forcing applications to “whitelist” themselves, all addresses (msg.sender) should be included; excluding them is an arbitrary, political, and incorrect decision.
13 Likes
@rleshner I understand and support the philosophy behind an approach that’s agnostic to how the user interacted with the protocol.
My approach to identifying early users picks up EOAs and contract addresses from the account (V1) and minter/redeemer/borrower/payer (V2) arguments from the event associated with the transaction. So while I agree with you, @Itamar, and others that there ought not to be a difference in principle, in practice there simply is a difference in the event data that requires contracts be handled differently, lest COMP be allocated to contracts from which, in some cases (though not Argent, for example), it may not be retrievable.
I’ve gone ahead and added my prior effort at unwinding contract interactions to the Github repo. FindContractCallers.py examines early interactions with the protocol by smart contracts and recursively replaces the contract’s address with the from field of the transaction receipt. If there is a better way to get the originating msg.sender for contract-based early interactions with the protocol, I would appreciate a link or resource suggestions for how to do this.
One question I have for @Itamar (thank you for the pull request, it’s merged!): is there a general solution for the isArgentWallet() function that would work for any team’s smart wallets? This is the piece I was missing to handle the case where the contract is the user’s wallet, and I don’t know how to generalize it without input from every affected project and contract – which is functionally equivalent to “whitelisting” projects in my view. Perhaps I’m missing something, but I don’t see how it can be avoided unless all contracts are treated as users, which will result in some of the COMP being allocated to contracts that can’t do anything with it, and those contracts’ users being left out.
I will reiterate my concern that the recursive address solution can only properly account for contracts that function as one-to-one proxies (or are their users, as in Argent’s case). If a project does any meta-commingling of user funds, for example by issuing their own IOU tokens and pooling users’ collateral, then it seems to me like a truly agnostic approach relies on trusting those third parties to distribute their allocations properly. Is this not the concern that I think it is?
It would be harsh but fair to characterize my rationale for leaving smart contract interactions off prior draft lists as ignorance, incompetence, or laziness. Calling the decision arbitrary and political, though, that really stung. I hope it’s clear now that it wasn’t arbitrary, though it may feel that way at a high level.
12 Likes
I appreciate the efforts to including Argent addresses in the early users list (is there an updated full list @allthecolors?), and I fully support your arguments for limiting support to one-to-one proxies (where the only difference in interaction is truly through the method of linking a wallet (e.g. using the wallet interface vs compound interface) when further transactions are involved I support the opportunity for an individual allocation being assigned to these proxy addresses to be distributed by the projects themselves as they see fit.
An important point is regarding the intent of the airdrop, and depending on the response I see different models as most relevant:
- The intent is to improve decentralization and allow early users to submit proposals → result is cut-off number of accounts to ensure every address can receive 100 COMP (no need for social weighting etc)
- The intent is to reward early users → result is cut-off accounts by specific date and split rewards across that list of addresses whether that’s a minimum of 20 or 18.57373 doesn’t matter, all that matters is that a clear cut-off date is aligned on.
Just my 2 cents, I fully support an airdrop, but mixing the two intents doesn’t work, there is a need to clearly pick a direction.
9 Likes
Unfortunately it’s not a generic solution for all smart wallets, it’s custom to Argent, I don’t think there is a generic way to differentiate a smart wallet from a smart contract.
Maybe we could accept all addresses but adapt the formula so that someone depositing 1bn$ doesn’t get much more than someone depositing 1m$ or 100k$, so some sort of cap on the allocation or limit the impact of deposit size.
2 Likes
OK - I see what your saying (and others) and agree that’s there no reason to exclude them.
1 Like
To back track a little, surely those addresses that interacted natively with the Comp protocol, no matter what wallet was used e.g Argent, is already listed?
1 Like
endless topic
There s a time for everything
conduct early airdop via official funtion user first and then open a other proposal on other proxy airdrop
6 Likes
I agree on this. Seems like we will be on this forever. Whats wrong with turning this into a 2 part proposal. Reward the direct users since it was the easiest to find. Then coordinate with all the proxy wallets so they can make sure all of their users get included as well.
7 Likes
It seems easier to simply not censor any user.
@allthecolors query already includes every DIRECT interaction with Compound. Argent, Gnosis and probably many other users are all included. Just don’t censor smart contract interactions and it will be fair.
But arbitrarily deciding to censor some users doesn’t seem to make much sense.
I’d suggest caping the reward per address to avoid having 1 contract collecting most of the reward.
4 Likes
These discussions going nowhere, there should be concrete decisions to be made. I strongly support for airdrop to early users which used the protocol directly.
After the airdrop to direct protocol users are completed, There could be proposal for other proxies(argent, etc).
5 Likes
Hang tight everyone, I know this feels circular but we really are making progress. @Itamar is correct that the early user interactions script already has the capability to include all smart-contract interactions. I filtered out contracts in my initial proposal because I’ve seen so many situations wherein tokens get sent to contracts from which they cannot be easily retrieved (including on Compound, where depending on what went wrong, the funds are either irretrievable or have to go through a somewhat onerous governance process to be retrieved). To me, this possibility seemed like a worse outcome than tallying EOAs (simple addresses) first and worrying about contracts later. Imagine the negative impact it would have on a team that integrated Compound early if it can’t distribute early user COMP to its own users. Again, maybe this isn’t the problem I think it is; if you represent a team that integrated Compound early and this would describe the situation if COMP were to be airdropped to your contract, please speak up! 
Clearly we don’t have a broad consensus on this question. I think we need more information: specifically, let’s go ahead and see what a distribution would look like if we include all EOAs and contracts. That will help us better understand the extent to which contract-mediated interactions delivered early user capital to the protocol. If the largest-capital-weight contracts can be associated with the major integrations, as we anticipate they will be, it stands to reason that it is in those integrations’ best interest as a business (or DAO, etc) to forward distributions proportionally to their users’ interactions with the protocol.
This approach will break any socially-weighted component of a distribution, in the sense that a single contract that served 1000 users would get the same weight as any direct user. Maybe that knowledge can help reassure folks who are concerned about bringing contracts into the picture.
I’m happy to do this analysis, but one temporary hitch is that I don’t have a local node to run the analysis on. @grasponcrypto helped me out on the first analysis by running the scripts on a local node. I have a pending application with the grants program that includes a request for a Quiknode or Infura subscription to make the necessary calls. If someone else with a local node want to keep things moving and is willing to piece together the steps to generate a distribution list from the scripts I posted, you can download them from Github and run them after removing the step that removes contract.interactions (i.e. skip DetectContracts.py and IsolateDirectUsers.sh) The repo needs some more automation/cleanup, which will certainly be part of the effort if the grant is supported.
8 Likes
I get FileNotFoundError: [Errno 2] No such file or directory: ‘CompoundV1.abi.json’ when.I try to run it. I dont see ‘CompoundV1.abi.json’ at all. All other json files are there. Thoughts?
1 Like
Weird, sorry about that – it should be there now, thanks!
1 Like
Thank you @allthecolors . I have my node (geth) in a ubuntu server 20.04 (192.168.0.55). I can access it using local macbook pro (192.168.0.15). If you wouldnt mind me asking, thoughts on what my local ethereum IPC would be? Also, my ubuntu machine has username password, I assume I will have to pass it somehow when running the py file (from mac command line)? Sorry if these are silly questions. Trying to learn while I try to help as well : /
1 Like
Sure, I’ll share what I think should work and refer you here for more details.
For a local node you should just need to change the line
w3 = web3.Web3(web3.Web3.HTTPProvider('https://mainnet.infura.io/v3/YOUR-PROJECT-ID'))
using IPCProvider instead of HTTPProvider. Instead of a URL, you’ll just give the full path to the geth.ipc for your node.
1 Like
I’m a bit confused on the actual announcement date of COMP. Was it Feb 26 when the medium article was published or Feb 20 as written in this python script from @allthecolors?
Thanks for all of the efforts!
2 Likes