Upgrade the safety module to v1.5 PART 2
01Summary
Upgrade the Aave Safety Module to v1.5, introducing a new slashing mechanism (exchange rate-based instead of governance-dependent), a revised cooldown mechanism (20 days instead of 10, with minimum balance tracking), and UX improvements like permit support and claim-stake bundling. Part 2 upgrades stkABPT with max slashing set to 30%.
- Type
- contract upgrade
Key changes
- New slashing mechanism using exchange rate tracking between staked AAVE and stkAAVE, eliminating need for ad-hoc governance proposals for slashing(high)
- Cooldown period increased from 10 days to 20 days with new mechanics allowing redemption of minimum balance held during cooldown window(high)
- Max slashing parameter for stkABPT set to 30%(high)
- UX improvements including permit support, claim-and-stake bundling, and preview() methods following ERC-4626 standard(medium)
- Transfer of stkABPT ownership to ProxyAdmin controlled by SHORT_EXECUTOR(medium)
Notable concerns
- Cooldown mechanic change could affect withdrawal dynamics and system protection
- Increased slashing authority granted to SHORT_EXECUTOR as SLASHING_ADMIN
- 30% max slashing parameter introduces significant potential loss for stakers
Generated by Kvorum
02Description
Summary
This AIP presents the community with the opportunity to upgrade the safety module to v1.5 which introduces:
- a new slashing mechanism
- new cooldown mechanism
The new version also adds some convenience features like permit support or the ability to claim and stake in a single transaction.
Motivation
On September 2020, the Aave Safety Module was introduced into the ecosystem, to improve the protection of the liquidity protocol, adding an extra utility for the AAVE token: AAVE or AAVE/WETH BPT holders stake their assets to act as a defensive layer in front of any shortfall event.
Since then, apart from really minor upgrades, the contracts have remained the same and in parallel, the system has been adopted by other communities.
As part of our engagement with Aave, we identified that the Safety Module is a clear area of improvement in the ecosystem, from 2 different standpoints:
- Technical. Improving the basic existing mechanisms of the contracts, but without disrupting radically the current design of the SM.
- Conceptual. Making more efficient the SM dynamics (e.g. slashing, rewards distribution rules, etc), by modifying the whole design.
New slashing mechanism
On the running SM v1, in order to slash, an ad-hoc governance proposal is required, involving important development overhead, which is not ideal.
The new SM v1.5 adds an enhanced mechanism to facilitate slashing of the underlying by tracking an exchange rate between the staked AAVE and the stkAAVE received by stakers. The mechanism is simple: when somebody stakes AAVE, they receive a certain amount of stkAAVE, which no longer is 1:1 equivalent, as it keeps track of slashing (meaning with the same stkAAVE, stakers are able to claim less AAVE).
New cooldown mechanism
The current cooldown on SM v1 consists of a time delay of 10 days to be respected whenever anybody wants to redeem the staked AAVE. At the moment, this cooldown is affected by in/outflows of stkAAVE, both via transfer() and stake()/redeem(), in order to protect the system from being gamed. Even with this protection mechanism the mechanism is currently gamable, by staking aave within the active cooldown window to extend the window.
This mechanism is not really optimal and adds important complexity, so on v1.5 has been changed to the following: after activation of cooldown, a staker will be able to redeem the minimum balance he will hold between cooldown activation and redeem window. Apart from the user-level cooldown new mechanics, we also propose to increase the cooldown period from 10 days to 20 days.
Misc
The upgrade also allowed us to add some smaller ux improvements:
preview*()methods have been added to follow the4626standard more closely, even if there's no objective to be compliant
Specification PART 2
The proposal is split in two parts, as currently the stkAAVE is controlled by the LONG_EXECUTOR where stkABPT is controlled by the SHORT_EXECUTOR. As there's a single executor per proposal Part 1 upgrades the stkAAVE implementation and targets the LONG_EXECUTOR. Part 2 upgrades the stkABPT implementation and targets the SHORT_EXECUTOR.
The proposal will:
- transfer ownership of
stkABPTto aProxyAdmincontrolled by theSHORT_EXECUTOR.
IInitializableAdminUpgradeabilityProxy(STK_ABPT).changeAdmin(
address(AaveMisc.PROXY_ADMIN_ETHEREUM)
);
- deploy the new implementation while maintaining the current values:
StakedAaveV3 newImpl =new StakedTokenV3(
IERC20(ABPT),
IERC20(AaveV2EthereumAssets.AAVE_UNDERLYING),
GenericProposal.UNSTAKE_WINDOW,
GenericProposal.REWARDS_VAULT,
GenericProposal.EMISSION_MANAGER,
GenericProposal.DISTRIBUTION_DURATION
);
- upgrade
stkABPTimplementation. TheSLASHING_ADMIN,COOLDOWN_ADMINandCLAIM_HELPERare all initialized as theSHORT_EXECUTOR.MAX_SLASHINGis set to30%,COOLDOWN_SECONDSis increased to20 days:
ProxyAdmin(AaveMisc.PROXY_ADMIN_ETHEREUM).upgradeAndCall(
TransparentUpgradeableProxy(payable(STK_ABPT)),
address(newImpl),
abi.encodeWithSignature(
'initialize(address,address,address,uint256,uint256)',
GenericProposal.SLASHING_ADMIN,
GenericProposal.COOLDOWN_ADMIN,
GenericProposal.CLAIM_HELPER,
GenericProposal.MAX_SLASHING,
GenericProposal.COOLDOWN_SECONDS
)
);
References
A list of relevant links like for this proposal:
- ProposalPayloads
- StakedTokenV3
- StakedAaveV3
- sigma prime audit
- Certora audit
- Certora specs
- Test Cases
- Technical review by aave companies
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded on-chain action is a single generic execute() call to what is presumably the AIP's payload/executor contract, consistent with the standard Aave governance execution pattern where the actual logic (changeAdmin, deploying a new implementation, and calling upgradeAndCall with specific initialize parameters) lives inside the payload contract's bytecode rather than being visible as decoded arguments at the top level. Because the calldata trace provided here contains no decoded arguments — only a bare fallback/execute() call — there is no way to directly verify the specific numeric claims in the description (e.g., MAX_SLASHING = 30%, COOLDOWN_SECONDS = 20 days, admin role assignments to SHORT_EXECUTOR) against on-chain parameters. Nothing in the decoded action contradicts the description, and the single action matches the expected 'Part 2' execution pattern for an Aave short-executor proposal, so I am not flagging any discrepancies. However, since the calldata does not expose the underlying business logic for independent verification, my confidence in this comparison is low rather than high — this is a limitation of the available decoded data rather than evidence of a problem with the proposal itself.
Generated by Kvorum
04Actions
- Target
- 0xe63e…5c88
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedUpgrade the safety module to v1.5 PART 198%
- aaveexecutedUpgrade Aave instances to v3.7 Part 278%
- aaveexecutedAave v3.1 upgrade77%
- aaveexecutedUpgrade Aave instances to v3.477%
- aaveexecutedUpgrade Aave instances to v3.577%
- aaveexecutedUpgrade all Aave instances to 3.276%
- aaveexecutedAave V1 Deprecation Phase 276%
- aaveexecutedAave V2 deprecation76%
- aaveexecutedUpgrade Aave instances to v3.6 Part 275%
- aaveexecutedAave V1 Deprecation Phase 375%