DeFiScan pfp
DeFiScan
@defiscan
PART 2/2 Aave V3's decentralization review: Stage 0 Direct minting and burning of $GHO through the Risk Council is managed through the GhoDirectMinter contract and limited by minting caps which are controlled by the Aave Governance. Both the GhoStabilityModule and the GhoDirectMinter as well as the respective aToken and variableDebtToken contracts are upgradeable by the Aave Governance opening the possibility of uncontrolled minting or burning of GHO in case of an unintended upgrade. If abused, this control thus introduces a risk of loss of funds, loss of unclaimed yield (accrued interest in GHO) or an otherwise material impact on the expected protocol performance for GHO holders and Aave users.
0 reply
0 recast
1 reaction
DeFiScan pfp
DeFiScan
@defiscan
Aave Governance Aave Governance refers to Aave v3's onchain governance system which controls contract upgrades as well as other critical permissions as outlined above. We discuss the governance process itself in the Exit Window section and here focus on upgradeability and control in this module itself. This governance process is implemented in the GovernanceV3 contract which is fully upgradeable through a permissionless governance proposal. Hence, an unintended proposal could change the Aave Governance system and reassign its control to a less robust or fully centralized setup. In order to mitigate this risk, upgrades to the GovernanceV3 contract, as well as the AAVE token, require passing a 7 day Exit Window (https://defiscan-git-add-aave-v3-defiscan.vercel.app/protocols/aave#exit-window).
0 reply
0 recast
0 reaction
DeFiScan pfp
DeFiScan
@defiscan
During this window, users can exit the Aave v3 protocol. Furthermore, the Aave Governance v3 Guardian (https://defiscan-git-add-aave-v3-defiscan.vercel.app/protocols/aave#security-council) multisig account, adhering to the Security Council requirements, can cancel the execution of unintended proposals. On the other hand, this control can be abused to censor regular proposals with majority support. Also note that the (current) implementation of GovernanceV3 enables a native multi-chain governance process. Specifically, this process enables proposals to designate a different chain for holding governance votes. While Aave v3's proprietary cross-chain messaging protocol, called a.DI, itself does not exhibit centralized control, it makes the governance process susceptible to control over the designated chain (where voting occurs) itself. Aave V3 Governance can always decide to host the vote on Ethereum Mainnet.
0 reply
0 recast
0 reaction
DeFiScan pfp
DeFiScan
@defiscan
⛅Autonomy 🔴High Autonomy Score Oracle and Prices The Aave V3 protocol relies on Chainlink oracle feeds to price collateral and borrowed assets in the system. The protocol does currently have limited validation on asset prices provided by Chainlink. These checks include upper caps for stablecoins and LSTs and a sanity check that the price is above 0 for all assets. If the reported price by the price feed was below 0, a fallback oracle would be queried. Aave has currently no fallback oracle price feeds instantiated. As a consequence if the price was equal to or below 0, user actions on the Pool contract that require a price would revert. The replacement of a stale or untrusted oracle price feed requires a governance vote on permission level 1. The Chainlink oracle system itself is upgradeable without decentralized ownership over those permissions. This dependency thus introduces centralization risk in the Aave V3 protocol.
0 reply
0 recast
0 reaction
DeFiScan pfp
DeFiScan
@defiscan
Cross-chain vote Votes are currently held on Polygon by using a system called a.DI for cross-chain communication developed by the Aave Community (BGD Labs). The a.DI does not rely on a single bridge provider to move messages across different networks, but uses a x/y threshold, sending the messages in parallel via different bridge providers, reducing the dependency on a single provider. If the community cannot or does not want to use the a.DI or the other voting networks, then the community still can carry out the vote on Ethereum Mainnet. This would eliminate the cross-chain dependencies for voting. The cross-chain voting system has low centralization risk because of its fault tolerant design, while the oracle system is currently unmitigated.
0 reply
0 recast
0 reaction
DeFiScan pfp
DeFiScan
@defiscan
🪟Exit Window 🔴High Exit Window Score Critical permissions, including protocol upgrades, are controlled by Aave Governance and an Emergency Admin multisig account. Two levels of permissions are separated in the (current) implementation of Aave Governance: -Level 2 defines permissions on the governance system itself and on the AAVE token contract -Level 1 covers the remaining permissions. AAVE holders (also stkAAVE, aAAVE) are able to: -Create new proposals (requires 80,000 / 200,000 votes for Level 1 / Level 2) -Vote on proposals. A valid proposal must have at least 320,000 / 1,040,000 votes with a voting differential (YAE minus no votes) of 80,000 / 1,040,000 votes). -Votes start 1 day after proposal creation and the voting period is 3 / 10 days -The execution of successful votes is blocked by an Exit Window with a delay of 1 / 7 days.
0 reply
0 recast
0 reaction
DeFiScan pfp
DeFiScan
@defiscan
While hese Exit Windows do not qualify for a Low or Medium score, the risk of unwanted updates is further mitigated by the Aave Governance V3 Guardian multisig, which adheres to the Security Council requirements, and can cancel unintended governance proposals. However, these safeguards do only apply to permissions controlled by Aave Governance. The Emergency Admin multisig too holds critical permissions which are not protected with an Exit Window or Security Council setup. Specifically, the Emergency Admin is able to pause individual Aave markets or the entire protocol as well as disabling the liquidation grace period. If compromised e.g. during a high-volatility market, these permissions could be taken advantage of, in order to execute controlled liquidations. Meanwhile the permissions of multisig accounts Risk Council for GHO and for the Pool contract are sufficiently restricted by steward contracts in terms of frequency of updates and magnitude of the updates, such that an exit window is not required.
0 reply
0 recast
0 reaction