Aave DIVA Wrapper

Summary

The AaveDIVAWrapper contract allows users to create a contingent pool and add liquidity into it either initially or later after pool creation using functions AaveDIVAWrapper::createContingentPool and AaveDIVAWrapper::addLiquidity respectively. Both functions call their contract's parent AaveDIVAWrapperCore associated functions AaveDIVAWrapperCore::_createContingentPool and AaveDIVAWrapperCore::_addLiquidity respectively. Both functions AaveDIVAWrapperCore::_createContingentPool and AaveDIVAWrapperCore::_addLiquidity call a common function AaveDIVAWrapperCore::_handleTokenOperations which transfers collateral token from caller to this contract, supply to Aave, and mint wTokens with one condition it requires prior approval by the caller to transfer the collateral token to the AaveDIVAWrapper contract.

In the AaveDIVAWrapperCore::_handleTokenOperations function there's an external call to AaveV3 contract which helps to supply the collateral token to Aave and receive aTokens. It's also mentioned that approval to transfer the collateral token from this contract to Aave was given when the collateral token was registered via registerCollateralToken or when the allowance was set via approveCollateralTokenForAave.

However, the AaveV3::supply has a referralCode parameter with a fixed value 0 which could lead to miss future reward opportunities and potential fund loss. Since the "Aave Diva Wrapper Protocol" acts as a middle man between AaveV3 and Users so the referralCode value should be a dynamic userInput value because AaveV3 referral program could be activated anytime through governance proposal in future and the "Aave Diva Wrapper Protocol" is not an upgradeable proxified protocol so referralCode parameter worth to be a dynamic parameter.

Vulnerability Details

Code snippet:

IAave::supply:

The IAave is an Interface of AaveV3 Protocol where we can see the supply function requires a referralCode parameter of uint16 type.

AaveDIVAWrapperCore::_handleTokenOperations:

Passing a fixed value 0 in place of referralCode parameter which is the issue.

Proof of Concept

• Step 1: Initial Pool Creation (ReferralCode = 0)

  • User A (Alice) wants to create a pool using the createContingentPool function and adds some initial liquidity.

  • Input: Alice calls createContingentPool and the contract internally calls Aave V3’s supply function to deposit tokens into the Aave V3 pool.

  • ReferralCode Issue: The fixed referralCode = 0 is passed when calling the supply function.

• Step 2: User Adds More Liquidity (ReferralCode = 0)

  • Alice later wants to add more liquidity to pool using the addLiquidity function.

  • Input: Alice calls addLiquidity, which internally calls Aave V3’s supply function to add tokens to the pool.

  • ReferralCode Issue: The same fixed referralCode = 0 is used when calling the supply function.

• Step 3: Future Activation of Referral Rewards (Governance Proposal)

  • Governance Proposal: Later, Aave introduces a new governance proposal to allow users to earn referral rewards on liquidity added to pools. The referral system is activated and rewards are now available for users who use a valid referral code when interacting with Aave V3.

  • Referral Code Adjustment: In a properly designed system, the smart contract protocol would allow users to dynamically set the referralCode, enabling them to benefit from these rewards.

  • However, because our smart contract protocol is non-upgradeable, it cannot be modified to support the new referral rewards system or change the referral code for past transactions.

  Expected Outcome (Future State):

  • Alice miss out on all potential referral rewards because her initial and subsequent interactions were made with referralCode = 0.

  • Despite the referral rewards now being available in Aave V3, her past liquidity deposits (made with referralCode = 0) are not eligible for rewards.

  • No mechanism exists in the contract to “retroactively” apply a valid referral code for past transactions.

• Step 4: Fund Loss Due to Lack of Mitigation

  • Long-Term Impact:

  • Alice funds are still in the Aave V3 pool, but because she used referralCode = 0 and the protocol is non-upgradeable, she will never be able to retroactively claim any referral rewards that could have been earned from her initial and additional liquidity deposits.

  • This lack of reward eligibility represents a potential loss of future earnings for Alice, especially if the referral rewards system becomes a significant incentive in the future.

Impact

1. Missed Referral Rewards for Users:

   • Permanent Loss of Potential Earnings in future

   • Failure to Capitalize on Future Rewards: With the referral rewards system activated later, users could have benefited from the rewards if the referralCode were dynamic. However, the inability to modify the referral code leaves them with no way to earn rewards for their previous deposits.

2. Inflexibility Due to Non-Upgradeable Contract:

   • Inability to Adapt to Changes

   • No Retroactive Mechanism

3. Decreased User Engagement and Trust:

   • Negative User Experience

4. Risk of Competitive Disadvantage:

   • Loss of Market Competitiveness

   • Missed Revenue Opportunities

5. Long-Term Financial Impact:

   • Compounded Losses Over Time: As more users interact with the platform and deposit liquidity, the compounded effect of missed referral rewards will grow. The total value of the rewards lost across many users will accumulate, making the overall impact more severe over time. These missed opportunities could ultimately result in lower engagement and a negative financial outcome for the platform in the long run.

Tools Used

• Manaul Review

Recommendations

• Modify the contract to allow users to dynamically set or update the referralCode parameter, either through a manual process or a governance-driven system.

• Consider upgrading the contract to be upgradeable using proxy patterns (e.g., via OpenZeppelin's Proxy contracts). This would allow for future modifications to the contract logic, such as adjusting the referralCode mechanism or integrating new features, without requiring users to migrate their funds to a new contract.

• If upgrading the contract is not an option, consider implementing a retroactive reward adjustment feature, where users who interacted with the contract before the referral rewards were activated could still claim their rewards later.