AAVE DAO requests a capped minter of 8,301,475 ZK, as allocated but not claimed from the ZK airdrop with ZK to be distributed to AAVE users and partner protocols on ZKsync.
Proposal Author
@ACI - ACI (Aave Chan Initiative) is a service provider to Aave DAO (aavechan.com)
Proposal Sponsor:
Stani
Date Created
2025-JAN-14
Version
1.0
Summary of Action
Assign MINTER Role to new AAVE DAO ZK Capped Minter with cap of 8,301,475 ZK.
TPP: AAVE DAO airdrop claim extension via new ZK capped minter for user incentives
Simple Summary
The AAVE DAO requests a new capped minter to enable access the ZK airdrop allocated to AAVE DAO. All ZK will be distributed to AAVE users and partner protocols on ZKsync.
Abstract
The motivation for this extension request is to ensure ZKsync Community don’t miss out on the expected allocated tokens due to the complexity and thoroughness required in implementing the Aave DAO’s claiming mechanism.
Because airdropped tokens were allocated to the Aave Collector Contract address on ZKsync, a full AIP on-chain proposal was required to claim them. Further, the claim had to be processed through Ethereum mainnet governance to then call a specific DAO-owned contract on the L2. This has not been a trivial development task. Aave v3 ZKsync Activation wasn’t executed until 2024-09-20 which didn’t allow as much time to be functional.
This proposal asks to assign the unclaimed airdropped ZK to to a new capped minter to allocate the planned airdrop directly to the AAVE DAO by a multisig of relevant service providers.
Impact
The claimed tokens will be dedicated to planned incentive programs and cross-protocol collaborations. This aligns with ongoing governance initiatives for new asset onboarding and expansion of Aave instance borrow and supply caps on the network. The original plan was to use the airdrop allocation to bolster ZK incentive programs like the Ignite program and co-incentivize with partner protocols like Ethena and EtherFi. There was also discussion in the DAO to use airdrop allocation to help bootstrap GHO on the network. All tokens are to be distributed to ZKSync users through the aforementioned programs.
Mechanic
The representatives of the AAVE DAO have deployed a new ZK Capped Minter V2. Upon approval of this proposal, the MINTER role will be assigned to the Capped Minter. This will enable AAVE to mint ZK and distribute it to AAVE users on ZKsync.
The tokens will be used to incentivize users of the Aave ZKsync instance.
The main points of the plan are:
All tokens will be distributed to Aave users on ZKsync.
None of the tokens will be used to pay for operations, analytics, interfaces, implementation or any other expenses.
Metrics used to determine the rewarded user actions will mirror those used by the Ignite program, focussing on growth.
Service providers will coordinate to ensure emissions are used effectively, and will be adjusted alongside deposit and borrow cap updates for individual assets.
Best efforts will be made to coordinate with partner protocols to co-incentivize users of specific pools.
Accountability Framework
The ZK Capped Minter admin will be composed of a 3/5 multisig, including 3 independent accountability partners:
The ACI will act as main representative of the multisig with Karpatkey and Tokenlogic serving as independent parties to ensure ZK tokens minted from the Capped Minter are distributed to AAVE users on ZKsync.
Not Only AAVE DAO Some Eligible users miss to claim this Airdrop,
In my case as a Security Reseacrcher Username JAYSHREERAM on code4rena , allocated 16174 Zk tokens , Zk collected our address from code4rena , code4rena provide eligible users address as the wardens set for payment address.
The problem in my case is i set my Binance spot wallet address as an payment address on code4rena as C4 payment token is USDC , and from this my binance spot wallet is Eligible for the ZK Airdrop . 16174 tokens were allocated to my binance spot wallet ( 0x9ff9ac1f4219725d97a9cc8d053d519a6ee3b428 ) but not able to claim the airdrop token because i cannot sign the transcation through the binance spot wallet address.
Sent a Mail to Zk & Binance to Help to claim this airdrop but no one help to claim those airdrop and i missed the Airdrop .
If Zk Nation consider to Send Allocated tokens directly to eligible users i will receive. my funds .
I have been thinking about this proposal for some days now - and I am still not 100% sure how much I like it.
Pro:
AAVE is an important player in the ecosystem we generally should support
users shouldn’t be in a worse position because of the complexity of the AAVE DAO
“None of the tokens will be used to pay for operations, analytics, interfaces, implementation or any other expenses.”
Contra:
This TPP passing could set a precedence for the future and could potentially lead to high governance/ coordination efforts if more (and especially smaller/ less relevant) protocols create similar proposals
Distributing these 8M tokens to AAVE users mirroring the Ignite program might influence the Ignite analytics/ outcome
My gut feeling right now is that I would support this proposal because of AAVEs significance. At the same I also would love to highlighting that AAVE is an exception and that similar future proposals might be treated differently.
Also we should consult with Merkle / OBL if rewarding these 8M on top of the Ignite program is the best way to make use of the funds.
I don’t think this should be handled on a case-by-case basis where governance decides to favor one group over others. Doing so sets a bad precedent, increases governance overhead, and raises ethical concerns about fairness.
If an airdrop claim extension is to happen, it should be for all users who haven’t claimed yet, not just AAVE users. The slightly shorter claim window for AAVE users doesn’t justify making an exception for them alone. Many others missed out for various reasons - whether it’s waiting for the next tax year, unforeseen circumstances, or simply being late by a few days.
I’m broadly supportive of extending the claim window for everyone, as it would help create a stronger, more inclusive community by ensuring a higher claim rate. That’s ultimately in the best interest of the protocol and aligns with ZKSync’s values.
I disagree that AAVE should be treated differently to other ecosystem users. Extension should be granted fairly to all users or not at all. Choosing AAVE over the rest leads to gnarly ethical implications and fails to support decentralisation values of ZkSync.
It would be great to hear Matter Labs feedback on this since this matter is related to the system (airdrop) designed before ZK Nation existed. Can you arrange that @rafa ?
Could you clarify when the Aave DAO first initiated governance or technical actions to implement the necessary adjustments for claiming these tokens? Additionally, could you provide an outline of the steps taken during the claim window to move Aave towards being able to claim these tokens?
Any supporting information that highlights Aave’s timely efforts to secure the airdrop—despite encountering technical or governance challenges—would be greatly appreciated. This context would help the Token Assembly logically differentiate this request from future potential requests for unclaimed airdrop allocations from teams that did not face these same challenges.
The development on this AIP started in September with discussions with the ZKsync team and the relaunch of Aave v3 on the network. The transaction required numerous steps to effectively pass a message from mainnet to ZKsync. A proposal and required payload was implemented in November and pushed for internal final testing in December (Claim ZKSync ZK airdrop by MartinGbz · Pull Request #550 · bgd-labs/aave-proposals-v3 · GitHub) but further issues during final review led to delays which pushed us over the deadline.
In this case, a transaction needed to be made from the Aave Collector Contract, a contract which contains circa $40m of DAO funds, and which requires onchain governance for any transactions to be made. Alongside this, the claim transaction itself was complex and novel to the development team. This presented some delays in the development, testing, and review process which unfortunately pushed us over the claim deadline. In addition, due to the extra work required in identifying and rectifying issues with the Aave deployment on ZKsync, backlog had accumulated which increased the workload on relevant teams, some of which required prioritisation. More information on the deployment issues can be found here: BGD. Aave v3 ZKSync activation issue report - Development - Aave
Despite these challenges, during the time since Aave has been deployed on ZKsync, the technical teams and service providers to Aave DAO have been busy working to the benefit of ZKsync users through ensuring the safe and efficient management of Aave’s ZKsync instance. Since August 2024 Aave service providers have made 18 forum posts about ZKsync on the Aave governance forums, 4 Snapshot votes, 4 on-chain votes, and numerous parameter updates.
Thanks for sharing the detailed update @ACI, clearly you have made a concerted and sustained effort to claim the aidrop well before the claim window deadline.
Given that additional context, Treasure’s Delegate Council (TDC) intends to vote FOR this proposal.
I think it is a good move. AAVE is a big part of the ZKsync ecosystem, and supporting it will help grow the whole community. The tokens will only be used to reward users and encourage more activity, which benefits everyone in the long run.
It’s deeply concerning to see AAVE attempting to extend the claim period for their airdrop tokens, especially when it’s clear that such a move would disproportionately advantage them in the ongoing Ignite initiative.
Allowing this extension would not only skew the competitive balance but also undermine the fairness of the Ignite program. The sheer size of their airdrop would grant AAVE an unfair monopoly, leading to significantly higher APYs on their markets, which would be detrimental to other Ignite participants.
This would set a dangerous precedent, effectively rewarding a single project with an outsized advantage. Such favoritism could stifle innovation and competition within the ecosystem.
I strongly urge the community not to support this extension to ensure a level playing field for all participating projects.
Based on the provided information in this topic thread and also on the standing delegate call, the Aave DAO has done everything they could (without compromising security) to claim tokens onchain, but due to technical challenges they weren’t able to. Since the ZK claim period is over, there’s no fear that Aave DAO would claim the tokens the old way (and 2x the ZK token amount in case this proposal goes through), so I have no reservations voting FOR this proposal.
Disclosure: I am AAVE token holder. At this time, I do not have any deposits in the Aave protocol on ZKsync, nor do I have any plans to make a deposit.
While exceptions in general are difficult, I agree with the other delegates. The ACI / AAVE has shown they made the effort, but could not claim in time due to technical difficulties. Therefore, I’m supporting as well.
We’re in favor of this proposal since the reasoning makes sense, and the amount requested is in line with what’s already being allocated. Plus, @ACI has shared plenty of details, so we have no concerns!
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR the proposal.
While we can understand other delegates’ concerns about extending the airdrop claim window for Aave and the precedent it might set for other parties to request similar treatment, we do not fully share those concerns.
Firstly, we believe that the position Aave found itself in is unique, and it’s not the same as a user forgetting about the claiming window and requesting a second chance. Additionally, as pointed out by @ACI, Aave has been discussing the issue with the zkSync team for quite some time since September.
Lastly, after inquiring with the zkSync Governance Team, it appears that there is no other protocol in a similar position that could use this proposal passing as a stepping stone to make a similar request.
With that in mind, we’re inclined to vote in favor of the proposal as we value Aave and their community and we believe we shouldn’t let a technical difficulty get in the way of claiming their airdrop.
Having said that, however, we want to ask that Aave somehow officially acknowledges this move from the DAO as a favor and does something in return as a gesture to signal appreciation.