Payback of tokens in AaveHub can be predictably blocked by well capitalized attacker

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0x0bff71d438794b2542cee8434661d625d03184a40372c6f7bbb1d206658a3dbb Severity: high

Description: Description\

An attacker can front-run a user that wishes to payback tokens on the AaaveHub and supply enough tokens to fill the max supply and as a result block the payback.

To payback an AaveHub the underlying token has to be supplied to AAVE. In AAVEHub.sol payback is done through paybackExactAmount() where the _wrapAaveReturnValueDeposit() function is called

    function _wrapAaveReturnValueDeposit(
        address _underlyingAsset,
        uint256 _depositAmount,
        address _targetAddress
    )
        internal
        returns (uint256 res)
    {
        IERC20 token = IERC20(
            aaveTokenAddress[_underlyingAsset]
        );

        uint256 balanceBefore = token.balanceOf(
            address(this)
        );

        AAVE.supply(
            _underlyingAsset,
            _depositAmount,
            _targetAddress,
            REF_CODE
        );

        uint256 balanceAfter = token.balanceOf(
            address(this)
        );

        res = balanceAfter
            - balanceBefore;
    }

We see that the underlying has to be deposited into AAVE with AAVE.supply().

In AAVE supply() fails if the max supply is reached

require(
      supplyCap == 0 ||
        ((IAToken(reserveCache.aTokenAddress).scaledTotalSupply() +
          uint256(reserve.accruedToTreasury)).rayMul(reserveCache.nextLiquidityIndex) + amount) <=
        supplyCap * (10 ** reserveCache.reserveConfiguration.getDecimals()),
      Errors.SUPPLY_CAP_EXCEEDED

If the attacker is well capitalized and the user is close to liquidation the attacker can perform the attack with the intention of liquidating the user and earn a profit.

The current capital required for some tokens:

UNI: Attacker needs ~$15M to block payback Dai: Attacker needs ~$200M to block payback

The attacker does not risk any funds since they are simply supplied into AAVE and can be withdrawn after the attack.

The capital requirements depends on how close we are to the supply max. Payback can also be blocked if this naturally happens but this is a less severe issue since users and wise has time to adapt as this approaches.

Attack Scenario\

1. User Bob borrows from AaveHub
2. Bob position can soon be liquidated so Bob decides to call payBackExactAmount()
3. Attacker Alice is monitoring positions on and is ready to front-run calls to paybackExactAmount().
4. Alice sees Bobs call in the mempool and front-runs with flashbots to block the payback by supplying underlying tokens to AAVE up to the max supply limit.
5. Bobs calls to payBackExactAmount() fail and Alice is able to liquidate the position.

[vm06007]

I think you are missing the point and adding a lot of IFs and assumptions here. To give you a bit food for thoughts:

• Bob can also add more collateral and does not need to payBackExactAmount in order to be solvent for his position.
• Alice cannot liquidate Bob just by blocking supply, unless his position is already insolvent, hence Alice (or anyone else) can just liquidate without blocking. If we are talking about DOS for payback it can also happen naturally as you've stated (in this case Bob can simply add more collateral using other tokens) or reduce borrow amount if Bob has borrowed any other tokens as well.
• Alice can only block but it does not guarantee her to liquidate Bob (since this is also a topic of who gets to do it first) -> hence even if possible to liquidate it is only possible for a small amount until Bobs position is solvent again (not entire position is liquidated especially if on the edge).

[vm06007]

Naturally I would say its users choice to either supply to Aave pools (AaveHub) that does come with a bit more risk, or supply into WiseLending Native pools (for same asset) where its not expose to any risk from Aave (Aave can freeze pools, or not enough supply to mint, or Aave upgrading their interface etc)

[vm06007]

If this can happen also naturally its not really an attack, it can't also be prevented especially if naturally AavePools can be saturated. Fact that someone deliberately or not deliberately blocks supply does not mean they are instantly liquidating someone or guaranteed to liquidate any portion of their position. In fact position owner always has ability to add more collateral and its up to position owner to maintain their position healthy. I will let @vonMangoldt add more to this topic if there's anything else that I'm missing here.

[QandisaThird]

Hi, thanks for the comments.

Yes, I am stating the assumptions and requirements for an edge case. I will expand on it here with the hope of making it clear. I will also add another example showing that depositing collateral is not always a viable option.

• Alice cannot liquidate Bob just by blocking supply, unless his position is already insolvent, hence Alice (or anyone else) can just liquidate without blocking. If we are talking about DOS for payback it can also happen naturally as you've stated (in this case Bob can simply add more collateral using other tokens) or reduce borrow amount if Bob has borrowed any other tokens as well.
• Alice can only block but it does not guarantee her to liquidate Bob (since this is also a topic of who gets to do it first) -> hence even if possible to liquidate it is only possible for a small amount until Bobs position is solvent again (not entire position is liquidated especially if on the edge)

There is no guarantee but that is not required for it to be an incentive. If the attacker can increase the probability of liquidation and they expect to capture a certain % of them it can still be worthwhile. Especially given that the cost of performing the attack is essentially zero.

Direct profit from liquidation is not the only possible incentive. What about sabotage from a competitor or somebody that has a short positions on WISE's DAO token and is attempting to force liquidate as many users as possible to tank the token.

• Bob can also add more collateral and does not need to payBackExactAmount in order to be solvent for his position.

A user wishing to totally remove exposure from a token X that they borrowed will need to pay back that debt. The example I gave is an edge case where they fail to do so in time because the payBack() mechanism is blocked.

I will give another scenario where depositing collateral is not a viable alternative:

1. Token X is borrowed, token X increases in value aggressively.
2. Bob attempts to remove their exposure such that they are not liquidated if the price increases more.
3. payBack() is blocked by attacker.

What does Bob do to remove exposure to asset X? Depositing any token that is not the AAVE token or the underlying token as collateral is not in line with his goal given that he is still exposed to X, instead it increases the total amount of capital at risk. If X continues to increase in value he still gets liquidated. What Bob wanted to do was to remove exposure to X completely. This is not achieved.

Bob can not deposit the AAVE token as collateral since AAVE.supply() is still blocked.

Bob now tries to deposit the underlying as collateral but that is also blocked. The attacker has also filled the underlying pool on wise up to the max as seen here:

    function _checkMaxDepositValue(
        address _poolToken,
        uint256 _amount
    )
        private
        view
    {

        bool state = maxDepositValueToken[_poolToken]
            < globalPoolData[_poolToken].totalBareToken
            + lendingPoolData[_poolToken].pseudoTotalPool 
            + _amount;

        if (state == true) {
            revert InvalidAction();
        }

5. Bob is unable to remove his exposure to X because he can neither payBack() nor deposit collateral X or the underlying token.

Attacker can block both payBack() and deposit of the underlying token to wise. It will therefore not be possible for the user to remove exposure to X.

Naturally I would say its users choice to either supply to Aave pools (AaveHub) that does come with a bit more risk, or supply into WiseLending Native pools (for same asset) where its not expose to any risk from Aave (Aave can freeze pools, or not enough supply to mint, or Aave upgrading their interface etc)

Sure, that is why I am pointing to the fact that this can be triggered by an attacker at an opportune moment. Freezing is a "black-swan" event that is mentioned as a known issue.

The fact that we can naturally be blocked is a big issue too as I mention but not as serious since it requires both a volatile market AND reaching the limit at the same time. An attacker can trigger the block during a volatile market event and as I show they can also block deposit of the underlying simultaneously.

[vm06007]

Hi @QandisaThird in your yet another attempt to draw this grim scenario you've missed the point that when Bob has borrowed token X and now this token grows in value making Bob's position closer to liquidation nothing stops Bob from supplying that amount back into Native Pool (non-Aave) using it as a collateral, that normally has same (or can have higher) collateral ratio as Aave pool.

You've also mentioned that attacker can block both payback and deposit, but it is not true if user can supply into Native pool same token they have borrowed. Please note that to fill native pool would require way more collateral provided by the attacker than to Aave pools.

Bob can also supply to ANY other token to corresponding pool making this scenario unlikely because attacker would have to max out ALL pools.

If we are discussing sabotage from a competitor I also don't see how is this not possible to be applied to a competitor it self then. This competition is for finding bugs in execution, not drawing scenarios.

Keep in mind that I think you've missed the point that deposit limit is updatable value and can be increased by the owner of the contract. I would rather focus on calculation bugs, than describing and debating on how the protocol works, especially when protocol clearly has options to address this scenario. (ability to supply to other pools, ability to increase deposit limit)

At the end its up to the user to maintain their position with given tools I think it is achievable and does not counts as high issue!

[vm06007]

@vonMangoldt will provide more in depth details on this as well.

[vonMangoldt]

This is equivalent to this scenario mentioned in scope description.. I quote: "If Aave freezes pools where we use the underlying as a pool new aTokens cant be minted and thus open borrow positions cant pay it back. If Aave unfreezes the pool the functionality is restored. This can be mitigated in the future by wrapping the aTokens into new tokens which also accept the underlying. Then after adding that to a pool this is mitigated. So the risk is known and not considered a bug and can be migrated after launch while its still not frozen."

And therfor out of scope.

Still my thoughts:

On arbitrum the sequencer doesnt allow for front running and on ethereum we dont plan aave pools anyway because of extra gas. The opportunity cost for someone to use flashbots to do that e.g for eth would require hundreds of millions of dollars sitting idle just so a user pays 14$ that his transaction fails while the attacker loses Tens if not Hundreds of Millions of Dollars for needing the capital in their wallet. Anyway this is just a theoretical and unpracticle scenario anyway and as above mentioned out of scope with the quote.

[QandisaThird]

Hi @QandisaThird in your yet another attempt to draw this grim scenario you've missed the point that when Bob has borrowed token X and now this token grows in value making Bob's position closer to liquidation nothing stops Bob from supplying that amount back into Native Pool (non-Aave) using it as a collateral, that normally has same (or can have higher) collateral ratio as Aave pool.

Yes, I am once again pointing to a edge case that can lead to losses for users. Mitigating possible unwanted states of the protocol is part of building mission critical code.

And no I did not miss the point that they can deposit collateral. Read the rest of the post where I show that there is a possible state where they are unable to unwind their exposure to a specific asset.

Keep in mind that I think you've missed the point that deposit limit is updatable value and can be increased by the owner of the contract. I would rather focus on calculation bugs, than describing and debating on how the protocol works, especially when protocol clearly has options to address this scenario. (ability to supply to other pools, ability to increase deposit limit)

At the end its up to the user to maintain their position with given tools I think it is achievable and does not counts as high issue!

I have not missed that point, take a look at the following hats judging criteria for a medium issue:

- Attacks that make essential functionality of the contracts temporarily unusable or inaccessible

- Short-term freezing of user funds

I have shown that core functionality is temporarily blocked and that liquidations can happen as a result of it. Are you arguing that core functionality is not temporarily blocked?

I do not know if Hats ranks forced liquidation as a High but the issue does fit the requirements for the above criteria for a Medium.

This is equivalent to this scenario mentioned in scope description..

This is not true, In your own quote "So the risk is known and not considered a bug and can be migrated after launch while its still not frozen.". What I have shown is separate and more sever since it can be trigger by an attacker at ANYTIME, this is obviously not the same a freezing a pool by AAVE governance.

On arbitrum the sequencer doesnt allow for front running and on ethereum we dont plan aave pools anyway because of extra gas. The opportunity cost for someone to use flashbots to do that e.g for eth would require hundreds of millions of dollars sitting idle just so a user pays 14$ that his transaction fails while the attacker loses Tens if not Hundreds of Millions of Dollars for needing the capital in their wallet. Anyway this is just a theoretical and unpracticle scenario anyway and as above mentioned out of scope with the quote.

This is not true, an attacker can have the assets invested in another protocol and remove them to perform the attack in the same transaction. Failing the attack does not lose them anything it simply deposits the assets into lending protocols where they earn yield during the period of the attack.

AAVE not being on mainnet is not mentioned anywhere so that can not a good-faith argument.

And even then the issue is not mitigated since the attackers sees the debt ratios on-chain and can perform the block during a volatile market to target all user that are reasonable close to being liquidated due to exposure to asset X.

[vm06007]

So @QandisaThird then what about my comment on that first of all design questions are out of scope (we focus on actual code bugs) - and the fact that maximum deposit can be increased? In this case how would attacker prevent user to supplying ANY other asset supported by the protocol to increase their collateral level avoiding liquidation. Knowing that user can supply ANY other asset including the one they just borrowed back to the protocol into native pool (that is basically unblockable by the attacker) why would attacker perform such attack? This sort of an issue you are arguing about Is easly mitigatable within the protocol by having native pool for same asset without a deposit limit. Also you've missed the point on the scope that design questions of the protocol not really in the scope. Would you not agree that current design where user can use depositExactTokens() on WiseLending in case Payback and Deposit are blocked on AaveHub would not mitigate this? You've brought a point that it might have a limit, but this is only theoretical since limit is adjustable or can be set to extremely high value should the protocol decide to do so, therefor it would not be considered as a design flaw. Technically AaveHub is sort of 2nd layer on top of WiseLending top functionality.

[QandisaThird]

So @QandisaThird then what about my comment on that first of all design questions are out of scope (we focus on actual code bugs)

If a less severe issue is mentioned as a known issue and the one pointed out can be triggered - then it is by your own word a unknown issue. If it had been a design choice then a less severe issue would not have been mentioned as known issue.

You can mitigate this issue in the contract this requires allowing paybacks even when supply is blocked in the underlying and then syncing supply when when possible. This of-course requires quite bit of re-engineering to get the accounting right.

Or what you will most likely do: Inform users about the risk and state is as a limitation such that the do not rely 100% on payBack() in conjunction with strict monitoring of both AAVE and wise deposit limits.

Also you've missed the point on the scope that design questions of the protocol not really in the scope. Would you not agree that current design where user can use depositExactTokens() on WiseLending in case Payback and Deposit are blocked on AaveHub would not mitigate this? You've brought a point that it might have a limit, but this is only theoretical since limit is adjustable or can be set to extremely high value should the protocol decide to do so, therefor it would not be considered as a design flaw. Technically AaveHub is sort of 2nd layer on top of WiseLending top functionality.

Is it really theoretical when any serious lending protocols has these limits AND you yourself have implemented this functionality? I am assuming you will be increasing the limits responsibly as any other respectable lending protocol. It being adjustable means functionality can be temporarily inaccessible until it is adjusted. How long would it have taken to identify the issue and adjust the limit, was somebody wrongfully liquidate during this period?

Is your counter argument here that you will just have uncapped deposit limits on all supported tokens? And that you knew that this was a requirement before my submission?

It is clear to me that I have shown that multiple core functionality can be "temporarily unusable or inaccessible".

In example 1 I showed that payBack() can be blocked if done in the right moment a user that would have otherwise settled their debt can now be liquidated. Is it guaranteed? No, but is a possibly that should at minimum be mentioned such that user don't rely on it 100%. This shows that core functionality is blocked. With all information provided a user believes they can settle their debts by simply paying them back as long as AAVE has not frozen the pool. CORE functionality is blocked.

In example 2 i show that removing exposure from a borrowed asset X can be completely blocked in certain states of the pool. Great, you now know that you should be careful with AAVE tokens and their underlying pools in wise and strictly monitor their limits such that both can not be blocked at the same time.

[vm06007]

So @QandisaThird then what about my comment on that first of all design questions are out of scope (we focus on actual code bugs)

If a less severe issue is mentioned as a known issue and the one pointed out can be triggered - then it is by your own word a unknown issue. If it had been a design choice then a less severe issue would not have been mentioned as known issue.

You can mitigate this issue in the contract this requires allowing paybacks even when supply is blocked in the underlying and then syncing supply when when possible. This of-course requires quite bit of re-engineering to get the accounting right.

Or what you will most likely do: Inform users about the risk and state is as a limitation such that the do not rely 100% on payBack() in conjunction with strict monitoring of both AAVE and wise deposit limits.

Also you've missed the point on the scope that design questions of the protocol not really in the scope. Would you not agree that current design where user can use depositExactTokens() on WiseLending in case Payback and Deposit are blocked on AaveHub would not mitigate this? You've brought a point that it might have a limit, but this is only theoretical since limit is adjustable or can be set to extremely high value should the protocol decide to do so, therefor it would not be considered as a design flaw. Technically AaveHub is sort of 2nd layer on top of WiseLending top functionality.

Is it really theoretical when any serious lending protocols has these limits AND you yourself have implemented this functionality? I am assuming you will be increasing the limits responsibly as any other respectable lending protocol. It being adjustable means functionality can be temporarily inaccessible until it is adjusted. How long would it have taken to identify the issue and adjust the limit, was somebody wrongfully liquidate during this period?

Is your counter argument here that you will just have uncapped deposit limits on all supported tokens? And that you knew that this was a requirement before my submission?

It is clear to me that I have shown that multiple core functionality can be "temporarily unusable or inaccessible".

In example 1 I showed that payBack() can be blocked if done in the right moment a user that would have otherwise settled their debt can now be liquidated. Is it guaranteed? No, but is a possibly that should at minimum be mentioned such that user don't rely on it 100%. This shows that core functionality is blocked. With all information provided a user believes they can settle their debts by simply paying them back as long as AAVE has not frozen the pool. CORE functionality is blocked.

In example 2 i show that removing exposure from a borrowed asset X can be completely blocked in certain states of the pool. Great, you now know that you should be careful with AAVE tokens and their underlying pools in wise and strictly monitor their limits such that both can not be blocked at the same time.

Yes in fact now we are getting there where you've starting to realize this is just a discussion of the design for 2nd layer and not an exploit or bug find. We've stated that these theoretical debates are out of question just questioning how the protocol is functioning without providing any code changes.

Yes, it is already been well known before that there are limits, hence we've already stated that AAVE can freeze pools for example and this should not be in the scope for this campaign. For same reasons we've also decided to put ability to increase cap of the native protocol pools and put a warning for particiapans that this topic is out of scope. Similar AAVE can also increase/decrease cap in their protocol which affects our 2nd layer for AaveHub. Nothing new here.

Again this can be mitigated in different scenarios just like you've also mentioned, but I don't think this submission brings anything new to the table to uncovers a bug in the code, just a discussion on the design like capping/not capping the pools and dependency on AaveHub (which again was already mentioned not to be in the scope)

Again, users can provide extra collateral in these conditions keeping their position healthy by supplying to ANY of the pools even re-supplying same asset they have borrowed in case they cannot pay it (resupply into native pool). It is extremely unlikely ALL pools even native pools would be all full at least one can always remain with higher cap making sure users can deposit. (Keep in mind there is also solely deposit functionality present on native pools)

The rest is all known same as dependency on Aave freezing pools or changing cap on their supply. We've already seen this when users were not able to even deposit because Aave pools were full. Hence this one is now closed. I would suggest to take a look at other submissions that remained opened. (or learn more from others thats also been closed for similar reasons)

[QandisaThird]

I am sorry but you are showing that you don't understand the issue

Again, users can provide extra collateral in these conditions keeping their position healthy by supplying to ANY of the pools even re-supplying same asset they have borrowed in case they cannot pay it (resupply into native pool). It is extremely unlikely ALL pools even native pools would be all full at least one can always remain with higher cap making sure users can deposit. (Keep in mind there is also solely deposit functionality present on native pools)

What you are saying is not true. Depositing into pool that is not the underlying of the AAVE token that has been blocked does not remove exposure to specific token at hand. If that is not core functionality of a lending protocol then I do not know what is.

[vm06007]

What you are saying is not true. Depositing into pool that is not the underlying of the AAVE token that has been blocked does not remove exposure to specific token at hand. If that is not core functionality of a lending protocol then I do not know what is.

I'm not saying it removes exposure, I'm saying user can supply same fund to native pool to increase collateral level or ANY other pool asset to increase collateral level making this attack obsolete.

[vm06007]

I am sorry but you are showing that you don't understand the issue

Again, users can provide extra collateral in these conditions keeping their position healthy by supplying to ANY of the pools even re-supplying same asset they have borrowed in case they cannot pay it (resupply into native pool). It is extremely unlikely ALL pools even native pools would be all full at least one can always remain with higher cap making sure users can deposit. (Keep in mind there is also solely deposit functionality present on native pools)

What you are saying is not true. Depositing into pool that is not the underlying of the AAVE token that has been blocked does not remove exposure to specific token at hand. If that is not core functionality of a lending protocol then I do not know what is.

@QandisaThird here is example ... I've borrowed tokenA from AavePool, now this token grows in value and I'm approaching liquidation. Now let's say the pool is blocked due to any reason (Aave froze, decreased cap level, or as you said attacker for some reason decided to block) - my option is to use native pool to resupply the asset I've borrowed as collateral increasing my collateral level hence I won't be liquidated any time soon. My other option is to supply ANY other token to any other pool that is not full or blocked yet (plenty of options) .. then I have plenty of time also to wait till I can repay back that tokenA eventually (again once Aave unfreeze the pool, or increased cap, or attacker realized its pointless to block because as as user I have too many options to keep my positions collateral levels at bay)

[vm06007]

When user supplies ANY token thats supported by the protocol, their collateral level (supply position) is increased in value (USD Equivalent) thus liquidation becomes not possible if entire position is below liquidation level.

Let's say: --> I've supplied tokenX to borrow tokenY, now I might not be able to repay tokenY right away due to different reasons mentioned above, but I can supply more of tokenX or tokenZ (or any other token in any pools, AaveHub or WiseLending) etc to keep my position healthy.

[vm06007]

When user supplies ANY token thats supported by the protocol, their collateral level (supply position) is increased in value (USD Equivalent) thus liquidation becomes not possible if entire position is below liquidation level. I've supplied tokenX to borrow tokenY, now I might not be able to repay tokenY right away due to different reasons mentioned above, but I can supply more of tokenX or tokenZ (or any other token in any pools, AaveHub or WiseLending) etc to keep my position healthy.

I can also supply that borrowed tokenY into native pool. Hence if it keeps growing in value so does my supply position accordingly/proportionally. Keep in mind at least one of the pools would definitely have capacity for a supply. It is extemely unlikely that ALL of the pools would be fully saturated that user cannot supply anything to keep their position healthy makaing this attack obsolete especially when WiseLending (native pools) can increase cap for at least one of the pools allowing more collateral to come in.

[vm06007]

If that is not core functionality of a lending protocol then I do not know what is.

Indeed maybe you do not understand how entire position works here, so I've provided some example above where user can keep their position healthy.

I would also suggest to play around with our pools on Arbitrum here: https://app.wiselending.com/ and see what happens when you've borrowed to the max and approaching liquidation levels for any reason (for example you don't have capital to pay back that borrowed token or simply blocked by Aave, but you have plenty of options to supply other tokens including same token you've borrowed into native pool)

Example: You've borrowed DAI from aaveDAI pool, but its blocked and you can't payback... maybe your collateral asset is dropping in value and you are approaching liquidation. Now you can supply that borrowed DAI back to native pool that will increase your collateral levels. Or use any other pool to keep your position healthy so it can't be liquidated.

Notice that exposure to borrowed DAI is not an issue in this scenario, but rather that asset you've borrowed drops in USD value instead.

As for the sceanrio where someone trying to block someone from paying back its not a great plan since it is assumption that user would try to payback in order to keep position non-liquidatable. Instead user can resupply same asset into native pool or supply ANY other asset to keep position safe.

[QandisaThird]

I am not sure if you are purposefully miss-representing what I am saying or you don't understand it.

Once again I will explain why there exist a LOW likelihood but HIGH impact issue:

Low likelihood prerequisites:

• A well capitalized attacker exists.
• Deposit limit on AAVE and deposit limit on wise are both reachable with the attackers capital such that deposits can be blocked.
  • Market event such that X is increasing very aggressively.

High impact scenario:

All users on wise that have borrowed X have positions that are getting closer to liquidation as the price of X is increasing.

The only way to decrease or remove exposure to X is to either payback the debt or deposit the underlying X natively.

Given that both are momentarily blocked they are forced to be exposed to asset X.

You mention they can deposit any other token. That makes no sense, that is not equivalent to removing exposure to X.

Example:

• User has $100 worth of aX borrowed.
• Immediately accessible capital is $50 such that they can payback a portion or deposit more collateral.
• Their X debt position is aggressively increasing in value, debt now worth $130.
• They wish to payback debt and decrease their exposure to X.
• Paying back through AaveHub is blocked AND depositing X natively is also blocked.
• Only option is to deposit collateral other than X to improve the positions health.
• They deposit $50 extra collateral.
• If X increase in price they will be liquidated earlier than if they had been able to remove half of their exposure to X.
• Instead of decreasing exposure to X they had to double down and risk more capital. The inverse of what they wanted to do.

[vm06007]

That's a lot of IFs stacking up... but yes your scenario is correct now, yet as you've mention user always has ability to supply collateral other than X, also depositing X natively is in control of the protocol to increase the cap, decreasing likelihood of such scenario since it is in control of the protocol and thus protocol has native response to this scenario. Again I don't see an issue or a solution to this due to exposure to external protocol such as Aave and being dependent on it.

So to sum-up:

• a lot of things MUST happen for this to even be considered issue (very low likelihood) (Aave must be bloced, native pool for same asset must also be blocked, asset X must go high in value than any other asset available to be supplied etc)
• even if these IFs do happen, protocol has natural way to defend against this, so even in this scenario protocol has ability to response by increasing deposit limit for asset X to unlock ability to deploy fund in native pool for same token X.
• this means the impact is low since not entire position would be liquidated but only small portion to restore borrow limit to below liquidation level therefor it is not as high impact as described.

I don't know why we are discussing design of the protocol that has natural dependency on 2nd layer Aave in particularly where users has ability to address this and even choose not to deploy funds in Aave pools to begin with, not only because of this but because with the same effect Aave can freeze pools, or change max cap on them, it can also increase max cap, but this is clearly out of scope for this contest .

Here is a paragraph from out-of-scope part:

taken from: https://app.hats.finance/audit-competitions/wise-lending-0xa2ca45d6e249641e595d50d1d9c69c9e3cd22573/scope

[vm06007]

On arbitrum the sequencer doesnt allow for front running and on ethereum we dont plan aave pools anyway because of extra gas.

also @QandisaThird your issue starts with words such as An attacker can front-run a user that wishes to payback tokens on the AaaveHub did you see response from @vonMangoldt already?

recapping for you:

• we dont use aave hub on eth main
• and arbitrum doesnt have front run

doc reference on arbitrum txs: https://docs.arbitrum.io/tx-lifecycle or https://docs.arbitrum.io/sequencer and https://docs.arbitrum.io/sequencer

[QandisaThird]

We are simply looping around here.

I make a valid argument that its in scope:

If a less severe issue is mentioned as a known issue and the one pointed out can be triggered - then it is by your own word a unknown issue. If it had been a design choice then a less severe issue would not have been mentioned as known issue.

you ignore it and instead claim it is not an issue because it is possible to simply deposit an non correlated token as collateral.

Then I show that is not correct:

Example:

• User has $100 worth of aX borrowed.
• Immediately accessible capital is $50 such that they can payback a portion or deposit more collateral.
• Their X debt position is aggressively increasing in value, debt now worth $130.
• They wish to payback debt and decrease their exposure to X.
• Paying back through AaveHub is blocked AND depositing X natively is also blocked.
• Only option is to deposit collateral other than X to improve the positions health.
• They deposit $50 extra collateral.
• If X increase in price they will be liquidated earlier than if they had been able to remove half of their exposure to X.
• Instead of decreasing exposure to X they had to double down and risk more capital. The inverse of what they wanted to do.

Then you go back to claiming out of scope.

Changing max-cap to solve it means core functionality was blocked for a while. Freeze is obviously not the same since this can be triggered when the market moves which is the requirement for it to be an issue in the first place.

On arbitrum the sequencer doesnt allow for front running and on ethereum we dont plan aave pools anyway because of extra gas.

also @QandisaThird your issue starts with words such as An attacker can front-run a user that wishes to payback tokens on the AaaveHub did you see response from @vonMangoldt already?

recapping for you:

• we dont use aave hub on eth main
• and arbitrum doesnt have front run

doc reference on arbitrum txs: https://docs.arbitrum.io/tx-lifecycle or https://docs.arbitrum.io/sequencer and https://docs.arbitrum.io/sequencer

Already answered here:

AAVE not being on mainnet is not mentioned anywhere so that can not a good-faith argument.

And even then the issue is not mitigated since the attackers sees the debt ratios on-chain and can perform the block during a volatile market to target all user that are reasonable close to being liquidated due to exposure to asset X.

[vm06007]

But it is out-of-scope not matter how you put it, I'm just giving you more example why would it not matter even IF it would be in scope as it is pretty much the same as Aave freezing pools (hence for ANY reason why the pool is not capable to perform mint on Aave) -> in out of scope paragrpaph it is also mentioned should such scenario occur (due to freezing or its irrelevant) there is also a natural answer with wrapped token:

Also you are saying that you ignore it and instead claim it is not an issue because it is possible to simply deposit an non correlated token as collateral. -> this is not true, because if user provides a different asset as collateral it is mitigated to certain degree, sure it is a question how much collateral that other token provides but again this is all theoretical.

Then you claim that Changing max-cap to solve it means core functionality was blocked for a while. - this is a false statement because you're suggesting max-cap can be increased ONLY if pool was already blocked for a while. In reality certain monitors/workers can perform this step automatically way before pool gets clogged up especially if same token X AavePool is already full, so its possible to increase cap in advance or in case of such scenario where AavePool is blocked.

I don't understand why are you keep pushing this idea when it clearly is same scenario where Aave can simply be the one changing caps even without attacker trying to do anything. We've already explained that in such scenario it would be identical response either increasing our caps or wrapping token just like described in NO-SCOPE part about almost identical SCENARIO.

In fact I could even find some old transactions showing we've already encountered similar scenario where pools were frozen and it was not possible to payback for certain assets in AavePool (payback was failing due to this) making us come to this conclusion and eventually putting this into out scope knowing payback can be blocked for AavePools, it is not that important how it is blocked. What is important this is already knows issue and limitation for AavePools, having that in mind that payback can be blocked for various reasons on AavePools. For that reason we've already raised solutions before even approaching this competition with addressing this through deploying wrapped token additional pool like mentioned in the NO-SCOPE part.

[QandisaThird]

You forgot to highlight "can be migrated after launch while its still not frozen". This is the exact point why it is not the same, double cap can be triggered by an attacker and it can be done during market volatility which is when it is an actual issue.

Also you are saying that you ignore it and instead claim it is not an issue because it is possible to simply deposit an non correlated token as collateral. -> this is not true, because if user provides a different asset as collateral it is mitigated to certain degree, sure it is a question how much collateral that other token provides but again this is all theoretical.

Great, now you are stating your standards in clearer terms: being unable to decrease/remove exposure from a borrowed token is acceptable.