# \[Discussion\] Prioritizing Cap Space for stkAAVE Holders **URL:** \ **Category:** General\ **Created:** [May 24, 2023, 9:47pm UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202 "2023-05-24T21:47:12Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Portkey](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/portkey/32/3415_2.png) [@Portkey](https://governance.aave.com/u/Portkey)\ **Post date:** [May 24, 2023, 9:47pm UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/1 "2023-05-24T21:47:12Z")
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](https://governance.aave.com/t/arfc-gauntlet-e-mode-methodology-aave-v3-liquid-staking-tokens/12700) and [Chaos Labs](https://governance.aave.com/t/chaos-labs-supply-cap-methodology/12842). 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. ## Context 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. ![marketz](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/0/0d3bde2b73bee90733e58644843474b70e09bde2.jpeg) > [@\[ARFC\] Polygon & Arbitrum v3 Supply Cap Update 19.05.2023](https://governance.aave.com/t/arfc-polygon-arbitrum-v3-supply-cap-update-19-05-2023/13133/5): > > Now the question is how we can prevent such whale’s action after this new proposal is passed. > [@\[ARFC\] Polygon & Arbitrum v3 Supply Cap Update 19.05.2023](https://governance.aave.com/t/arfc-polygon-arbitrum-v3-supply-cap-update-19-05-2023/13133/3): > > I would like to see this increased but: > > 1. There is nothing stopping these users from paying back their ETH and then taking USD/other denominated assets meaning we’ve got a high supply cap and the risk is increased. > > 2. I don’t believe that using the supply on a given network provides any solid risk analysis here given that the 4650 wstETH on Arbitrum was bridged from Ethereum 2 days before this passed. > > On the second point it feels somewhat like a fools errand to be basing limits using the circulating supply on a network given that it is so easy for any user to increase or decrease this supply by bridging. Available liquidity feels like the better metric for derivation of the cap. > > Personally I’m desparate to see this limit be increased as much as possible but I believe there should be two supply caps, one for ETH denominated borrowing (which basically will never be liquidated) and another for BTC/USD. The comments referenced above are in response to the [ARFC](https://governance.aave.com/t/arfc-polygon-arbitrum-v3-supply-cap-update-19-05-2023/13133/2), 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. ## Analysis 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](https://arbiscan.io/tx/0xcbced4d7183e32df41c53c449f9818fa03799af25286bc359015f443a0f2e322) 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](https://arbiscan.io/address/0x7d9103572be58ffe99dc390e8246f02dcae6f611#events) event to be emitted. ![actset](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/4/40dc294f45df550fd4420122d6a43441fe56a3b7.png) 1b.Once emitted, look into the transaction [Log](https://arbiscan.io/tx/0x4a457b8ee76d9f7fa301d7c316dcfbb50619e73fd9ac4ef7c0fcf7df32acd91d#eventlog) and see the time of executionTime represented as a Unix timestamp. ![extTime](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/e/e9bae52271750877fc40fa2eadf2f85adb309e62.png) 1. You could also monitor the PoolConfigurator and schedule a supply transaction to execute as soon as the [SupplyCapChanged](https://arbiscan.io/address/0x8145edddf43f50276641b55bd3ad95944510021e#events) event is emitted. ![event](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/7/7066c4948ed314950dea565e2431e9599d37cdcd.png) ## 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. ---
**Author:** ![pcx](https://avatars.discourse-cdn.com/v4/letter/p/a9a28c/32.png) [@pcx](https://governance.aave.com/u/pcx)\ **Post date:** [May 24, 2023, 10:28pm UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/2 "2023-05-24T22:28:09Z")
Interesting 🧐 I will vote to limit a single deposit transaction or wallet balance to a pre-determined percentage of the circulating aToken supply. ---
**Author:** ![WintermuteGovernance](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/wintermutegovernance/32/9926_2.png) [@WintermuteGovernance](https://governance.aave.com/u/WintermuteGovernance)\ **Post date:** [May 25, 2023, 7:12am UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/3 "2023-05-25T07:12:31Z")
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 ---
**Author:** ![MarcZeller](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/marczeller/32/7124_2.png) [@MarcZeller](https://governance.aave.com/u/MarcZeller)\ **Post date:** [May 25, 2023, 8:43am UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/4 "2023-05-25T08:43:42Z")
Hello, 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! ![Nay](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/1/110db90cc11acc53185b2eb19c961fcbc4718cd6.png) ---
**Author:** ![0xkeyrock.eth](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/0xkeyrock.eth/32/6082_2.png) [@0xkeyrock.eth](https://governance.aave.com/u/0xkeyrock.eth)\ **Post date:** [May 26, 2023, 12:34pm UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/5 "2023-05-26T12:34:28Z")
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, ---
**Author:** ![Portkey](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/portkey/32/3415_2.png) [@Portkey](https://governance.aave.com/u/Portkey)\ **Post date:** [May 30, 2023, 12:28am UTC](https://governance.aave.com/t/discussion-prioritizing-cap-space-for-stkaave-holders/13202/6 "2023-05-30T00:28:29Z")
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](https://twitter.com/chainlink/status/1662193771142868993?s=20) 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 🤝 Portals 🧑‍🚀🛸