Skip to content

Latest commit

 

History

History
73 lines (50 loc) · 3.91 KB

077.md

File metadata and controls

73 lines (50 loc) · 3.91 KB

Glamorous Plum Baboon

Medium

Centralization Risks Due to Configurable Critical Parameters

Summary:

The contract includes critical parameters, such as REBALANCE_UP_LIQUIDITY_RATE_THRESHOLD and MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD, that are currently implemented as hardcoded constants. While this design choice ensures immutability and predictability, making these parameters configurable in the future could introduce centralization risks if not properly managed.

Description:

In the current implementation, the constants REBALANCE_UP_LIQUIDITY_RATE_THRESHOLD and MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD are hardcoded in the contract. These parameters are crucial for the protocol's functionality, as they control rebalancing behavior and liquidation thresholds.

If these constants were made configurable, the following risks could emerge:

  1. Centralized Control: The protocol’s functionality could be altered arbitrarily by privileged actors, leading to potential misuse.
  2. User Trust: Users could lose confidence in the system due to fear of tampering or governance overreach.
  3. Security Risks: Poorly managed access to modify these parameters could result in malicious or accidental updates that harm the protocol.

Root Cause:

The hardcoded constants are defined at:

  • REBALANCE_UP_LIQUIDITY_RATE_THRESHOLD
  • MINIMUM_HEALTH_FACTOR_LIQUIDATION_THRESHOLD

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/logic/ValidationLogic.sol#L43

https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/logic/ValidationLogic.sol#L53

These constants are defined directly in the code and cannot be modified after deployment.

Impact:

  1. If left as hardcoded constants:
    • Pros: Immutability ensures no single entity can change the system, promoting decentralization.
    • Cons: Lack of flexibility to adapt to market conditions or unforeseen situations.
  2. If made configurable:
    • Pros: Flexibility to adjust parameters dynamically as needed.
    • Cons: Introduces governance overhead and centralization risks.

The trade-off must be carefully managed based on the protocol’s needs.

Proof of Concept (PoC):

  1. Deploy the current contract with the hardcoded parameters.
  2. Simulate a scenario where changing economic conditions (e.g., fluctuating liquidity rates or health factors) make the hardcoded thresholds suboptimal.
  3. Observe that the inability to modify these constants impacts the protocol’s efficiency and usability.

Alternatively, if configurability is introduced:

  1. Grant privileged actors the ability to update these parameters.
  2. Observe how this introduces the potential for abuse or governance issues if not properly decentralized or protected (e.g., via multi-sig, DAO governance, or timelocks).

Recommended Mitigation:

To balance flexibility and decentralization risks, consider one of the following approaches:

  1. Leave the Constants Hardcoded:

    • This ensures the protocol remains immutable and decentralized.
    • Suitable for scenarios where these values are unlikely to need adjustment post-deployment.

  2. Make the Parameters Configurable with Safeguards:

    • Introduce multi-signature wallets for admin privileges to prevent unilateral changes.
    • Require decentralized governance (for example DAO votes) for parameter updates.
    • Implement a timelock mechanism to provide users sufficient notice of any upcoming changes, allowing them to react.

  3. Hybrid Approach:

    • Keep the parameters hardcoded initially, but allow governance to decide on future upgrades through a decentralized voting mechanism.

By adopting one of these approaches, the protocol can maintain a balance between flexibility and decentralization, reducing potential risks.