sDAI onboarding
01Summary
Proposal to onboard sDAI (liquid DSR deposit tokens) as a collateral-only asset in Aave V3 Ethereum pool with specific parameters (77% LTV, 80% LT, 4.5% liquidation penalty), while adjusting parameters for wETH and DAI across V2 and V3 pools to facilitate integration and create synergies with MakerDAO ecosystem.
- Type
- protocol addition
Key changes
- Onboard sDAI as collateral-only asset in Aave V3 Ethereum pool with LTV of 77%, LT of 80%, and 4.5% liquidation penalty(high)
- Increase wETH optimal ratio from 80% to 90% on V3(medium)
- Decrease wETH slope 1 from 4.8% to 3.8% on V3(medium)
- Increase DAI reserve factor from 15% to 25% on V2 and from 10% to 20% on V3(medium)
- Increase DAI optimal ratio from 80% to 90% on both V2 and V3(medium)
- Increase DAI slope 1 from 4% to 5% on both V2 and V3(medium)
- Disable DAI stable borrow on V2(medium)
Notable concerns
- sDAI integration complements but does not replace separate DSR integration in aDAI reserve proposal
- Current engineering constraints noted for short-term implementation difficulty
- Both sDAI and DAI will coexist as reserves with different use cases (sDAI as collateral, DAI as borrowable)
Generated by Kvorum
02Description
Simple Summary
This proposal seeks to onboard sDAI as a collateral-only asset into the Aave V3 Ethereum pool. It outlines the specific parameters for integration and aims to create new synergies with the MakerDAO ecosystem.
Motivation
The recent increase in the DSR (Dai Savings Rate) to 8%—though anticipated to decrease to 5%—presents a unique opportunity for Aave to forge new synergies with the MakerDAO ecosystem. By integrating liquid DSR deposit tokens (sDAI) as a collateral-only asset in the Aave V3 Ethereum pool, Aave can offer users the dual benefit of earning DSR yield while utilizing their assets as collateral. In the context of GHO, this integration would create a yield-generating stablecoin with a higher yield than the GHO borrow cost. It's important to note that this proposal does not conflict with the DSR integration in aDAI reserve proposal, but rather complements it. However, current engineering constraints make immediate integration difficult in the short-term. Should governance approve this proposal, both sDAI and DAI would serve as reserves in the Aave V3 Ethereum pool, with sDAI primarily used as collateral and DAI as a borrowable asset.
Specification
We propose the following modifications to the Aave V3 & V2 Ethereum pools:
sDAI contract: 0x83F20F44975D03b1b09e64809B757c47f942BEeA
| Parameter | Value |
|---|---|
| wETH Optimal Ratio on V3 | from 80% to 90% |
| wETH slope 1 on V3 | from 4.8% to 3.8% |
| DAI RF on V2 | from 15% to 25% |
| DAI RF on V3 | from 10% to 20% |
| DAI optimal ratio on V3 | from 80% to 90% |
| DAI Slope1 on V3 | from 4% to 5% |
| DAI optimal ratio on V2 | from 80% to 90% |
| DAI Slope1 on V2 | from 4% to 5% |
| DAI stable Borrow | disabled on V2 |
| sDAI parameters | same as DAI but as collateral only |
| LTV | 77% |
| LT | 80% |
| Liquidation penalty | 4.5% |
References
- Implementation: Ethereum
- Tests: Ethereum
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded calldata consists of only two generic execute() fallback calls to two separate payload contract addresses. This is the standard Aave governance pattern where the executor delegatecalls into a purpose-built payload contract that contains the actual parameter-setting logic (rate strategies, LTV, reserve factors, asset listing, etc.). Because the decoded_arguments are empty and no granular parameters (rates, LTV, RF, optimal ratios) are exposed in the provided calldata, it is not possible to directly verify each specific numeric claim in the proposal description (e.g., wETH optimal ratio 80%->90%, DAI RF changes, sDAI LTV/LT/penalty) against on-chain values. This lack of visibility is a limitation of the decoded data rather than evidence of a mismatch — the pattern (two payload execute() calls, matching two pools/asset sets referenced in the spec) is consistent with what the proposal describes (V3 sDAI onboarding plus V2 parameter changes). Given the inability to confirm exact parameter values from the calldata alone, confidence is low and no discrepancies are flagged, since flagging would require speculation beyond the provided data.
Generated by Kvorum
04Actions
- Target
- 0x5bfb…fd01
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
- Target
- 0xf2a9…edf7
- 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
- aaveexecutedAave Ethereum V375%
- aaveexecutedAave V3.3 Soneium Activation75%
- aaveexecutedAave v3 Gnosis Activation74%
- aaveexecutedAave V3.3 Sonic Activation73%
- aaveexecutedAave v3 Linea Activation72%
- aaveexecutedAdd DeFi Saver to Aave V3 FlashBorrowers72%
- aaveexecutedDeFi Saver Aave V3 FlashBorrowers Whitelist Part II71%
- aaveexecutedAave V3.6 MegaETH Activation71%
- aaveexecutedAave V3 Aptos Activation71%
- aaveexecutedAave V3.6 Mantle Activation71%