[Discussion] Prioritizing Cap Space for stkAAVE Holders

Author: Kentrell - Research Analyst | Messari
Date: May. 24, 2023

Simple Summary

This post aims to initiate a discussion surrounding the increasing demand within select Aave markets, which are currently constrained by supply and borrow caps. It also explores potential strategies to alleviate concentration within these capped markets. It is important to note that any proposed changes to a market’s supply and borrow caps are currently evaluated using methodologies from Gauntlet and Chaos Labs. These methodologies consider several factors such as on-chain liquidity and historical price variance to establish parameters that strive to maintain a smooth liquidation process even under extreme market conditions.


Following the successful Shanghai upgrade, the demand for collateralizing Liquid Staking Tokens (LSTs) on Aave V3 has surged, leading to full capacity or near-full capacity in 5 out of the 6 LST markets.

The comments referenced above are in response to the ARFC, authored by @Llamaxyz, which proposed an increase in the wstETH Supply Cap on both Arbitrum and Polygon markets. Before the supply cap was raised for these markets on May 19, they had been operating at maximum capacity for weeks. The aftermath of these increases was remarkable, with both markets reaching their new capacities in an unprecedentedly short time - Arbitrum in 24 seconds and Polygon in 7 minutes. On Arbitrum, a single entity (0xccfa), was responsible for supplying the entirety of the increase, and now possesses 50% of the aArbwstETH supply. Meanwhile, on Polygon, another address (0x1dc6) contributed to 89% of the corresponding increase. It’s evident that these markets are in high demand, not only from large-scale investors, but potentially from other protocols as well. In its current state, this could disadvantage smaller and less sophisticated investors, leaving them on the sidelines.


The rapid utilization of the newly increased cap space along with the previously mentioned comments, led me to look into how such a scenario could occur. Based on my current understanding it seems challenging to prevent a whale from taking such actions, as seen recently by 0xccfa’s deposit to the wstETH market on Arbitrum. This deposit, amounting to 4,650 wstETH (approximately $9.5M), was made a mere 24 seconds (or 91 Arbitrum blocks) after the Chainlink Keeper contract updated the supply cap parameter via the PoolConfigurator. I’ve identified a few potential strategies that the whale, or indeed any investor, could employ to accurately time transactions following a supply cap increase:

1a. Once the vote is executed on Ethereum, one can watch the ArbitrumBridgeExecutor and wait for the ActionsSetQueued event to be emitted.

1b.Once emitted, look into the transaction Log and see the time of executionTime represented as a Unix timestamp.

  1. You could also monitor the PoolConfigurator and schedule a supply transaction to execute as soon as the SupplyCapChanged event is emitted.

Driving Additional Utility to AAVE

Given the persistent demand for these positions, it may be worthwhile to explore strategies that the protocol could adopt to balance the concentration of depositors within these markets. One intriguing approach could simultaneously balance concentration and offer additional utility for stkAAVE holders by providing them with limited access to a percentage of future cap space. Another approach could be to limit a single deposit transaction or wallet balance to a pre-determined percentage of the circulating aToken supply. However, this latter approach may be less effective in practice due to the difficulty in preventing sybil attacks.

Consider, for instance, a market that has consistently operated at full capacity. This market could reserve the final 5-10% of the supply or borrow cap exclusively for stkAAVE holders. Theoretically, this arrangement could serve as a non-monetary method of reducing the cost of insurance for users. Moreover, the Safety Module’s 10-day cool-down period could function as a natural deterrent against malicious actors, requiring those who seek priority access to assume some insurance risk. One potential downside of this gated or priority access is that the reserved allocation might remain unused. However, this issue could be mitigated by implementing a time check (e.g., a 10-day gate) that could then be lifted. I’m sure there are many other ideas on how to balance concentration within the markets and I’d love to discuss more options the community comes up with. It’s also worth considering whether any changes are necessary at all, depending on the collective perspective.

Final Thoughts

Overall, there appears to be a feasible approach to shift the demand and mitigate concentration, while simultaneously driving additional value to stkAAVE holders. Ideally, the design presented would help balance user demand for cap increases, as some of the focus shifts to acquiring stkAAVE for priority access to gated cap space. Should the community express interest in pursuing any of these ideas, the direct next steps would be to consult with @bgdlabs on feasibility, as well as scoping out the resources that would be required to implement any changes.

I believe there is already work underway on creating special permissions for stakers for GHO borrowing, which may have potential overlap with these ideas.

Thank you for taking the time to read this discussion post. I hope it serves as a catalyst for a productive conversation.


Interesting :face_with_monocle:
I will vote to limit a single deposit transaction or wallet balance to a pre-determined percentage of the circulating aToken supply.

1 Like

Interesting post @Portkey, thanks!

We agree that this would hinder UX on Aave, but we are not too sure if token gating would be very effective. Assuming there is a check to make sure a user balance of stkAAVE is > 0, the whale could just buy and stake 1 AAVE

Then if we think about increasing this threshold to a level that is large enough for this whale to be deterred, other stkAAVE users get priced out. Another option would be to scale the required stkAAVE balance based on a % of the deposit amount which could work, but it might just end up leading to an annoying UX

It might also be better to have a shorter window for the time-check e.g. 1-2 days, this still provides an opportunity for stkAAVE users and limits the amount of potential revenue Aave misses out on

Having caps filled immediately is not a terrible outcome and arguably pretty good from a revenue standpoint for Aave, but it obviously sucks for users who simply want to use the platform without battling to get in before it fills up



we might be AAVE-Maxi at the ACI, we are attached to the neutral nature of protocol.
One of the core ethos of DeFi is that rules are the same for everyone and everyone gets the same cost/yield no matter if they have 10$ or 1M$ if they own AAVE or not.

While it make sense to provide benefits to stkAAVE holders in the context of GHO, we’re opposed to gatekeeping at the protocol level.

oracle upgrades are ongoing for LSTs that will allow to raise caps significantly if they’re approved by governance in the immediate term. just a bit a patience frens!



an intriguing idea for sure @Portkey!

On the other hand, we do agree with @WintermuteGovernance here that this would create complexities on the UX and with @MarcZeller it strives away from the core ethos of DeFi,


Appreciate your responses!

As a leader and base layer of DeFi, I agree that maintaining the neutrality of the protocol’s core functionality is imporant. My initial suggestion contradicts this, but was more so intended to conceptualize additional ways for stkAAVE to accrue value as the market evolves. A brief stkAAVE priority window, perhaps lasting only a couple of hours, might have been a more fitting approach to mitigate potential revenue implications. However, as pointed out, the potential for ux confusion and the need for additional development resources likely outweigh the benefits of such a limited advantage.

On an exciting note, recent developments suggest a forthcoming solution. A couple of days ago, Chainlink released the Cross-Chain Interoperability Protocol (CCIP) code base and initiated a public audit via Code4rena. CCIP stands ready to address the issue of fractionalized liquidity, which is currently the main bottleneck for supply cap methodologies. Drawing from the historical timeline of Chainlink Staking, we could anticipate a solution as early as this summer, especially considering that Aave was one of the protocols testing in Beta. And coupled with the upcoming launch of GHO, I’m sure there will be many more opportunities to explore fresh avenues for value capture.

Thanks again. Portkey :handshake: Portals :astronaut::flying_saucer:

1 Like