Leading up to the Instadapp airdrop there were DeFi users, some of whom are Instadapp users, lending/borrowing in Aave V1. These users were left out of the initial Instadapp airdrop allocated to MakerDAO, Compound, and Aave V2 users. To help optimize capital within DeFi, the Instadapp community can incentivize those Aave V1 users to migrate to Aave V2 and create a DSA v.2 smart contract. DSA v.2 will enable all migrated Aave position holders to be eligible for a token allocation similar to those who able to claim for MakerDAO, Compound, Aave V2 positions. This will unlock additional $INST tokens that can be used to enhance liquidity on Uniswap V3 or voting on upcoming proposals.
Proposal
I propose the Instadapp Treasury allocate $INST to incentivize all Aave V1 position holders to migrate there position to Instadapp DSA v.2 and Aave V2.
To receive an airdrop allocation Aave V1 users must:
-Create Instadapp DSA v.2
-Migrate Aave V1 positions to Aave V2 using Instadapp refinance bridge.
The amount of $INST allocated to Aave V1 users will coincide with the previous airdrop formula. We will compare the TVL of Aave V1 to the overall TVL in DeFi at the time of the original MakerDAO, Compound, and Aave V2 snapshots. Aave V1 position holders within Instadapp during the snapshot will receive double the amount or Aave V1 position holders who held the position in their personal EOA.
Reasons
Aave V1 is a great product, but Aave V2 allows for more functionality and composability within Instadapp and the entire DeFi space. To align incentives by allotting Aave V1 users a financial/governance incentive to migrate their positions to Aave V2 and DSA v.2, Instadapp will strengthen its ties with another group of DeFi users and absorb additional liquidity to beef up Instadapp network TVL.
Result
All Aave V1 users who migrate their position into Instadapp creating a DSA v.2 and migrating their Aave V1 positions to Aave V2 will be eligible for a $INST token allocation funded by the Instadapp Treasury. The $INST will not come with any lockups and will be liquid the moment it is claimed. This process will also enable $INST Liquidity Mining for all the new Instadapp DSA v.2 users with an Aave V2 position.
Hello, thank you for proposing but just curious, it was my understanding that we were waiting for Instadapp team to figure out implementation before proceeding with the proposal, let me know if I am missing updates in between.
“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.”
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.
Imo Aave v1 users had quite a lot of opportunities to migrate their assets. When Aave v2 launch there was a migration bridge on Aave and at Instadapp. Aave Governance started AAVE LM and one of the reason for that was to incentivize users to migrate their liquidity for LM incentives. I’m not sure if adding an additional rewards here would make sense as I think the Aave v1 users are not much active. It might just impact a very small set of users (maybe $50-100M). Plus there are some more complexities on the token distribution as in what block to take for snapshot? A recent snapshot will make users to deposit assets on Aave v1 an old snapshot might result in a change in position. The airdrop we did was taken the snapshot on the same day.
It is true Aave V1 users had a lot of opportunities/time to migrate but that doesn’t necessarily mean they are opposed to migrating/importing at some point in the future. So wouldn’t it be best to incentivize them to import liquidity into the Instadapp ecosystem in the event they do?
If you have a good relationship with several Aave V1 users (I do not) and think this token allocation is a waste of resources then I’m happy to dismiss it for now.