Airdrop Issues Solution Proposal (Rough Draft)

[CPix18]

Instadapp Governance Proposal

Summary

-Since the launch of $INST there have been several DeFi users with active positions in MakerDAO, Compound, and/or Aave V2 who’ve been unable to receive the full amount of their allotted token airdrop. One of the common occurrences stems from users importing a fraction of their current position to Instadapp as a test trial then no longer being able to claim the full amount of $INST.

Proposal

Create a request form for any DeFi user who had a rightful claim at tokens but did not receive the full amount. The user will need to provide on-chain proof of meeting requirements to be eligible as well as on-chain proof of the partial tokens received.

Reason

The Instadapp community benefits from fair and wide distribution of the $INST token. The more unique token holders, the better liquidity in Uniswap V3, better chance at reaching quorum on voting proposals, and most importantly a more diverse community of happy token holders.

Code
???
(If there is a way to fix this by updating a smart contract rather than doing a request form that could probably be more efficient)

Links

Discord - A New Way to Chat with Friends & Communities

Discord - A New Way to Chat with Friends & Communities

Discord - A New Way to Chat with Friends & Communities

Result

If passed, this proposal will ensure strong ties with the Instadapp community members who may have otherwise felt cheated by the airdrop. After all, the Instadapp community shouldn’t penalize those who have the patience and wherewithal to send a test transaction first.

Polls

Twitter Poll (Instadapp Account) gauging how many DeFi users were affected by this issue

Which category best fits your experience with the $INST airdrop?

-Received full amount allotted (position was already in Instadapp)

-Received full amount allotted after importing full position into Instadapp

-Received partial airdrop due to import issues

-Did not receive airdrop even though I own an Instadapp DSA

Snapshot Vote to gauge voting sentiment before a formal vote
snapshot.org/#/setup

[Seb_EthMonk]

Hey this is a good looking first draft - I think that twitter polling may not be necessary to gauge how many were affected, the team can read the data and get an accurate number.

If the unclaimed INST were to be pushed; it would be done within the GUI and made so that it would be easily claimable on-chain and would not require any gathering of information or any type of request form.

Here is a slightly re-formatted Result Section:

• All current DSA v.2 users who migrated previously into Instadapp would receive the maximum allotted tokens no matter what balance they used to migrate or if they claimed before.
• All future DSA v.2 accounts that had claimable allotments would simply receive their full claim by creating an account - no import required.

Awesome work!

[Doo_StableLab]

Thank you for the proposal. We would like to add clarifications and suggestions to improve the proposal.

1.Stable Node proposes to add AAVE V1 users at the time of the snapshot to be included in this updated airdrop.

Considering many early pioneers and adopters of DeFi users still use AAVE V1, we believe including them will ensure more users can receive the token for their contribution as well as encourage them to participate in Instadapp governance and ecosystem. There is around 300m worth of liquidity there, and it could be good to get them to migrate to AAVE V2 / Instadapp.

2.Stable Node also wants to propose for this updated airdrop to have an expiration date of around 90 days.

The ecosystem and the governance should reward active participation, and we believe that after 90 days, unclaimed airdropped tokens can be sent to the treasury for the ecosystem to grow and reward active participants and partners.

This will also encourage DeFi users to migrate to Instadapp sooner and thus helping to grow the ecosystem and users more rapidly.

[CPix18]

(2nd Draft)
After hearing some suggestions from the community, here is an updated proposal:

Title: Make all snapshot INST claimable (remove net value) (rename) & Include Aave V1 Users (users migrate to Aave V2 and DSA v.2) & Addition of 90 Day Expiration Period To Claim Airdrop (remaining balance sent to treasury)

Summary

Push remaining partially unclaimed $INST tokens to all DSA v.2 accounts regardless of net value;

users would receive the total amount of claimable $INST.

Allot additional $INST for Aave V1 users who migrate to Aave V2 and create DSA v.2 Account.

Create 90 day expiration for claimable tokens. Remaining tokens sent to treasury.

Proposal

Several users, some with large CDPs, did the unusually responsible action of reducing their positions before migrating into Instadapp to claim their $INST, many were not aware that the claimable $INST was based specifically on the net value of the position at the time of the snapshot.

Some users wanted to test the migration and initiated a claim without their total balances, making it impossible for them to claim again. This will allow users who modified their net value prior to importing to receive a more appropriate amount of tokens.

I propose we push forward partially unclaimed $INST tokens to users who already migrated and make their remaining $INST claimable within their DSA v.2 account.

There were also many Aave V1 users who were left out of the airdrop who could be incentivized to move liquidity to Aave V2 and DSA v.2 account if allotted an airdrop.

I propose we push a maximum of 300,000 $INST to Aave V1 users who migrate their position to Aave V2 and create an DSA v.2 account.

Lastly it makes sense to reward active participation and to do so I propose we create a 90 day expiration period for the community to claim the remaining $INST tokens.

Reasons

The DAO currently has a high threshold for passing proposals and achieving quorum; no matter the outcome if claimed $INST is held or dumped in the market, increasing the claimable $INST will still make more $INST available and help with having more voting tokens in circulation.

Current Governance Parameters:

• 1% of INST supply required to submit a proposal.

• 4% of INST supply needed to reach quorum.

• ~3 day voting period.

• ~2 day timelock delay on execution.

Result

All current DSA v.2 users who migrated previously into Instadapp would receive the maximum allotted tokens no matter what balance they used to migrate or if they claimed before.

All future DSA v.2 accounts that had claimable allotments would simply receive their full claim by creating an account - no import required.

All Aave V1 accounts at the time of the original snapshot (mainnet) could receive an airdrop by migrating their position to Aave V2 and creating a DSA v.2 account.

A 90 day expiration period will be put in place to incentivize active participation and push the remaining tokens back to the treasury.

• In Favor

• Against

[miscao]

A couple of clarifying questions:

1. This may just be grammar usage, but when we say “push” the INST to the users, are we saying we will make it accessible to claim versus actually sending it to the wallet? I would be in favor of the former (making it available to claim during the 90 day period).

2. Will the 90 day period apply to the original air drop claims on 6/17/2021 or is the 90 days applicable only to the newly proposed claim on rewards? i.e. are we proposing to add a 90 day time limit to all claims or just the unclaimed delta?

3. How are you determining how many INST or USD to reward AAVE v1 users? I don’t know the exact value on v1, but if there was 300 million, then it seems like the math would roughly be:

$300,000,000 AAVE v1 TVL / $5,000,000,000 TVL = .06 (6 percent) * 10,000,000 INST (original drop) = 600,000 INST

We would need to confirm the TVL of AAVE v1 during snapshot, but I think that would reward them the same as others.

[Doo_StableLab]

1. From what I understand from the original proposal, yes they have to claim it.

2. To make it simpler, expiration will apply only for the new airdrop (But others can voice their opinions. Happy to discuss).

3. For this part, I would leave it to Instadapp team to think of fair solution (if it’s possible to implement). But I think to make it simpler, for the new airdrop, treating AAVE V1 like how the team would reward V2 at the snapshot makes sense.

[CPix18]

1. I think they should claim as well. Personally, I’m interested in why the Instadapp team didn’t include Aave V1 in the first place. Not a huge fan of changing initial rules of an airdrop but if doing this incentivizes Aave V1 users to migrate to Aave v2 and DSA v.2 which makes the overall lending/borrowing market more efficient then I get it.

2. Regarding the 90 day expiration, I think there are a fair amount of Maker/Compound/Aave positions that don’t have plans to ever accept so it kind of makes sense to put some timer on that so those tokens can be put to good use. Although it is throwing out the endless opportunity for those users to one day switch due to an upgrade or something like that. So I am more in favor of an expiration on only the new airdrop for now. Can always make a new proposal later in time to set an expiration of the original airdrop.

3. I just threw 300k $INST out as a starting point, agree with @Doo_StableLab let the team provide some input on a number.

[Seb_EthMonk]

1. Time Limit for New Claims
   I like the idea of having a time limit to claim however, it would be a bit complicated to separate out those who claimed before and don’t have a time expiration, vs those that never claimed and adding a time expiration to them. I think its too complicated. I would suggest we agree on a hard date to claim for all participants. Probably a year from the original airdrop. (Maybe a small decay function to encourage claiming - not sure about this but open to it. )

2. INST for AAVE v.1
   (pardon I wrote this a bit before scrolling all the way down, but it also answers @CPix18 question too)
   I like the idea of including AAVE v.1 however, I think we need to consider the lifespan of AAVE v.1 and what it means to support a slightly older contract / marketplace like AAVE v.1.
   From a product prospective, its clunky to include because it doesn’t have the same functions as AAVE v.2 and is not receiving as many updates; there are use-cases and other functions that will not work on AAVE v.1.
   There needs to be some consideration around the technical time/debt it will take to continue to support AAVE v.1. Another way we can approach this is maybe by encouraging v1 users to migrate to v2 in order to receive their INST; this will remove the clunkiness of having to support AAVE v1 into the future. This is what @CPix18 suggested in the second draft I agree with this proposition.

3. Language check
   I agree ‘Push forward’ is not clear enough; it could be changed to ‘make entirely claimable’ or something similar

4. How much INST for AAVE v.1
   @miscao’s approach here is good I think in trying to figure out how much AAVE v.1 should get - did you use Instadapp’s TVL to determine the rate for AAVE v.1? We used overall defi market initially so it we need to do some math that looks more like: AAVE v.1 TVL / sum of [COMP TVL, AAVE v2 TVL, MAKER TVL]

[Doo_StableLab]

1. Then yes, it makes sense to set time expiration for all. I thought it would be difficult to set time expiration for already sent airdrops, but do agree that if that’s possible, then it makes sense to apply that to all. 1 year is quite generous and that should be enough to get a majority of active participants.

2. Agree with the suggestion as well. That’s a good way to reward AAVE V1 users but also encourage them to migrate to V2.

3. Calculating based on TVL of AAVE V1 / Sum of (COMP, Maker, AAVE V2, AAVE V1) makes sense.

[CPix18]

1. Expiration date 1 year from original airdrop sounds fair/appropriate.

2. Big fan of incentivizing Aave v1 users to migrate to v2, overall helpful to the DeFi space bc of better functionality and if someone doesn’t want to migrate they don’t have to.

3/4. So would the math looks something like 300M / (6.5B + 6.4B + 9.8B) ? (Used TVL from DeFi Pulse but not sure on exact v1 number)

[miscao]

I agree that 1 year is generous and maybe having a decay to Seb’s point will encourage more participation. These funds could then be funneled back into the treasury over time or used for other proposals.

Is there an address/contract where we can see how many INST have been claimed from the initial drop? The Instadapp contract only shows total tokens and number of holders.

The math proposed is another way to get to the same results I had, so I’m good with either. It sounds like we just need to get the TVL of AAVE v1.

[Daa]

All current DSA v.2 users who migrated previously into Instadapp would receive the maximum allotted tokens no matter what balance they used to migrate or if they claimed before.

I agree with it from Japanese community. Because we have difficulty to claim all INST token at once because of tax issue.

[CPix18]

How do we feel about 90 days from original airdrop, a decay on the unclaimed tokens begins for 90 more days. So by 180 days if a user hasn’t claimed, they will be unable to and remaining tokens sent to Treasury?

[Daa]

I’m sorry for multiple posts but I agree with 1 year decay. Because 2021 is a good year for crypto currency prices, and some people want to avoid claiming INST token within 2021. Because it makes additional tax from profit in law of Japan. 1 year decay is generous for every participant.

[CPix18]

So the entire airdrop is claimable for eligible accounts until after 1 year (from original airdrop) when a decay process kicks in? How long should decay be for claimable balance take to drop to 0?

[Seb_EthMonk]

TLDR: Create a simple separate AAVE v.1 allocation proposal now; and circle back on INST claim decay and INST partial claims after Liquidity Mining period

Upon further review there are still lots of accounts that haven’t claimed yet and the amount of accounts that appear to have missed part of the claim seems a bit insignificant when compared to the number of accounts that have yet to claim. We have seen good distribution and overall growth we think from the Liquidity Mining rewards; here is my suggestion on how we could break this proposal down a bit.

Create a separate proposal for: INST distribution for AAVE v.1 positions
Let’s have the team review how to implement this first part; the team can create a distribution list for AAVE v.1 and then we can vote for this in one proposal. We could get this done relatively fast.

Create a separate proposal that creates a decay on the unclaimed tokens
I would suggest circling back to this maybe after the liquidity mining rewards/Post-DeFi Summer and then create a slow decay where those tokens are reclaimed by the treasury over the following 9 months. The community can re-think on this when we are closer to this time period.

Find an opportune time for misclaimed tokens
The number of unclaimed tokens remains much higher than the number of users that mis-claimed. There is a lot of complexity/time required to recalibrate the claim for this smaller group of users and there is not enough incentive for these users not to immediately sell their tokens. I would suggest waiting for another opportunity to satisfy these users; such as when the token has a built in fee model or other revenue generating sources, integrated into lending DApps, etc.

[CPix18]

Thanks Seb, I agree completely. Let’s stick to incentivizing migration from Aave V1 to Aave V2 and DSA v.2 for now. Airdrop for misclaimed and decay period can happen at any time in the future but best to align all defi apps/protocols to migrate where collateral/debt have the most functionality.

[miscao]

Agree that the number of unclaimed tokens versus the number of users/tokens affected by the airdrop is significant enough that we can circle back to this in the future. The landscape could be vastly different once enough time has passed to generate liquidity.

[Seb_EthMonk]

The resulting proposal from this discussion is now here:

Allocate $INST For Aave V1 Position Holders

Hey Doo, yeah so I wanted to create a separate discussion for strictly the allotment of $INST tokens for Aave V1 position holders who migrate to Aave V2 and DSA v.2. I am still waiting for a more technical reply from the team on how to implement this as that is not my strong suit. It is my understanding they are already working on it.