KVORUM
aaveSource: Aave governance v3 · #175

Onboard USDS on Aave V3 Ethereum Main and Lido Instance

executedOct 1, 2024, 04:21 PM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

Proposal to onboard USDS (Sky's rebranded DAI token) to Aave v3 Ethereum Main and Lido Pool with identical supply/borrow caps (50M/45M) but different collateral treatment: Main instance allows collateral use with 75% LTV, Lido instance disables collateral functionality. Interest rate parameters adjusted across both pools with lower reserve factors (10%) and slightly higher borrowing rates compared to initial proposals.

Type
protocol addition

Key changes

  • Onboard USDS to Aave v3 Ethereum Main with collateral enabled (75% LTV, 78% LT, 7.5% liquidation bonus)(high)
  • Onboard USDS to Aave v3 Ethereum Lido Pool with collateral disabled (0% LTV/LT)(high)
  • Set supply cap at 50,000,000 USDS for both pools(high)
  • Set borrow cap at 45,000,000 USDS for both pools(high)
  • Implement CAPO DAI/USD oracle for USDS pricing to manage launch liquidity conditions(medium)
  • Reduce reserve factor from 25% to 10% on both pools(medium)
  • Increase base variable borrow rate from 0% to 0.75% on both pools(medium)
  • Increase variable rate slope 1 from 5.5% to 6.25% on both pools(medium)

Notable concerns

  • Lido Pool instance has no collateral functionality despite being added to protocol
  • Different risk parameters between Main and Lido instances may create complexity for users
  • Reliance on CAPO DAI/USD feed for pricing during launch phase introduces dependency on specific oracle implementation
ContractsAave V3 Ethereum Main InstanceAave V3 Ethereum Lido Pool
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

521 words

Simple Summary

This proposal aims to onboard USDS, the rebranded DAI token to Aave v3 Ethereum Main and Lido Pool.

Motivation

DAI has been a cornerstone asset in the Aave ecosystem, with a long and successful history of supply across various versions of the protocol. MakerDAO marked a significant milestone with a rebranded to Sky, introducing USDS as the new iteration of DAI. Given the established track record and widespread adoption of their predecessors, we propose to onboard these new assets to Aave v3.

By integrating USDS into Aave v3, we aim to maintain continuity for users who have relied on DAI while embracing the evolution of these assets under the Sky brand.

Specification

Risk Parameters for *USDS**

ParameterUSDS (Aave V3 Main Instance)USDS (Lido Pool)
Isolation Modefalsefalse
BorrowableENABLEDENABLED
Collateral Enabledtruefalse
Supply Cap50,000,00050,000,000
Borrow Cap45,000,00045,000,000
Debt CeilingUSD 0USD 0
LTV75 %0 %
LT78 %0 %
Liquidation Bonus7.5 %0%
Liquidation Protocol Fee10 %10 %
Reserve Factor10 %10 %
Base Variable Borrow Rate0.75 %0.75 %
Variable Slope 16.25 %6.25 %
Variable Slope 275 %75 %
Uoptimal92 %92 %
Stable BorrowingDISABLEDDISABLED
FlashloanableENABLEDENABLED
Siloed BorrowingDISABLEDDISABLED
Borrowable in IsolationDISABLEDDISABLED
Oracle*0x4F01b76391A05d32B20FA2d05dD5963eE8db20E60x4F01b76391A05d32B20FA2d05dD5963eE8db20E6

USDS (Lido and Main Instances) Changes

Oracle Updates:

  • USDS: Implementing a CAPO DAI/USD feed due to expected liquidity conditions on launch and bidirectional migration with DAI.

Interest Curve and Reserve Factor Modifications:

Following discussions with Sky teams and Aave DAO service providers, the following parameters have been adjusted to better suit the expected use cases of this integration:

USDS (Lido Pool):

  • Reserve Factor: Decreased from 25% to 10%
  • Base Variable Borrow Rate: Increased from 0% to 0.75%
  • Variable Rate Slope 1: Increased from 5.5% to 6.25%
  • Optimal Usage Ratio: Increased from 90% to 92%
  • Collateral Usage: Disabled
  • LTV, Liquidation Threshold, and Liquidation Bonus: All reduced to 0%.

USDS (Main Pool):

  • Reserve Factor: Decreased from 25% to 10%
  • Base Variable Borrow Rate: Increased from 0% to 0.75%
  • Variable Rate Slope 1: Increased from 5.5% to 6.25%
  • Optimal Usage Ratio: Increased from 90% to 92%
  • Supply cap improved to 50M
  • Borrow cap improved to 45M

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal describes onboarding USDS to two separate Aave v3 instances (Main and Lido Pool) with distinct, detailed risk parameters, oracle updates, and interest curve changes for each. The decoded calldata contains exactly two actions, each calling execute() (a bare fallback) on two different payload controller contracts. This structural pattern — two actions, one per pool — is consistent with the proposal's two-instance scope and matches the two GitHub implementation links provided (AaveV3Ethereum and AaveV3EthereumLido), which is the standard Aave governance pattern where a Payloads Controller executes a pre-audited implementation contract's `execute()` function containing the actual listing/parameter logic. However, because the calldata only shows opaque `execute()` fallback calls with no decoded arguments, it is impossible to verify from the calldata alone whether the specific numeric parameters (LTV, caps, rates, oracle address, etc.) in the description actually match what the underlying implementation contracts will set. There is no evidence of a mismatch, but there is also no way to confirm exact parameter fidelity without inspecting the bytecode/source of the target payload contracts. Given this limitation, confidence is set to low and no specific discrepancies are flagged, since the visible on-chain structure (two payloads for two pools) is consistent with the description's claims, but full verification is not possible from calldata alone.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

2 total
#0fallback()chain 0x1
Target
0xac08…6140
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x87bc…cfba
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.