KVORUM
aaveSource: Aave governor v2 · #411

Update GNO Risk Parameters on Aave V3 Gnosis Pool

executedDec 19, 2023, 01:30 AM UTCby570x57ab…2922

01Summary

AISummary by Kvorumclaude-haiku-4-5

This proposal enables GNO (Gnosis token) to be borrowed on Aave V3 Gnosis Pool by updating its risk parameters, while maintaining it in isolation mode with a 1100 GNO borrow cap. This aims to increase GNO utility and support Gnosis chain decentralization.

Type
parameter change

Key changes

  • Enable GNO borrowing by setting 'Enable Borrow' from No to Yes(high)
  • Set borrow cap at 1100 GNO to limit borrowing exposure(high)
  • Establish reserve factor at 20% for protocol revenue from borrowed GNO(medium)
  • Set interest rate parameters: uOptimal 80%, Base 0%, Slope1 15%, Slope2 80%(medium)
  • Maintain isolation mode status and collateral enabling while preventing stable borrows(medium)

Notable concerns

  • GNO remains in isolation mode, restricting its use as collateral for borrowing other assets
  • Borrow cap of 1100 GNO represents a conservative limit on total borrowing capacity
  • No stable borrow option available for GNO
Contracts0x9aee0b04504cef83a65ac3f0e838d0593bcb2bc70x9A1F491B86D09fC1484b5fab10041B189B60756b
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

275 words

Simple Summary

This AIP proposes to update GNO risk parameters on the Aave V3 Gnosis Pool to enable borrowing, fostering Gnosischain decentralization and use-cases for passive income and staking.

Motivation

The goal is to enhance GNO utility by allowing it to be a borrowable asset, thereby supporting Gnosischain’s decentralization. This adjustment also prepares for future GNO LSTs and a possible GNO-correlated e-mode, expanding utility and passive income opportunities for GNO holders.

Specification

The proposed changes aim to make GNO a borrowable asset outside of isolation mode with adjusted risk parameters to accommodate this new functionality:

Risk ParameterCurrent ValueProposed Value
Isolation ModeYesYES
Borrowable in IsolationNoNo
Stable BorrowNoNo
Enable BorrowNoYes
Enable CollateralYesYes
Loan To Value (LTV)31%31%
Liquidation Threshold36%36%
Liquidation Bonus10%10%
Reserve FactorN/A20%
Liquidation Protocol Fee10%10%
Supply Cap30000 GNO30000 GNO
Borrow CapN/A1100 GNO
Debt Ceiling1M$1M$
uOptimalN/A80%
BaseN/A0%
Slope1N/A15%
Slope2N/A80%

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The proposal follows the standard Aave Governance v3 cross-chain pattern: the mainnet vote only calls forwardPayloadForExecution to relay execution of a separately deployed payload contract on Gnosis Chain (identified by payload ID 100 and executor address 0x9A1F...). The decoded calldata does not expose the actual GNO risk-parameter changes (LTV, borrow cap, reserve factor, interest rate curve, etc.) described in the prose, because those are encoded inside the referenced payload contract, not in this forwarding call itself. This is normal and expected for Aave's cross-chain governance architecture, and the 'Implementation' link in the References section points to the actual Solidity payload that presumably implements the described parameters. Since the single decoded action here is just a generic bridge/forwarding call, there is no basis to detect a value mismatch, omitted action, or misleading phrasing — but there is also no way to independently confirm the specific numeric claims (reserve factor, borrow cap, rate curve, etc.) against on-chain calldata. Given this structural opacity, I cannot verify parameter-level correctness, so confidence is low. However, nothing in the visible calldata contradicts the description, and the pattern matches well-known legitimate Aave proposal tooling (bgd-labs aave-proposals-v3), so I do not flag this as a discrepancy.

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

04Actions

1 total
#0forwardPayloadForExecution((uint256,uint8,address,uint40))chain 0x1
Target
0x9aee…2bc7
Value
0 wei
Function
forwardPayloadForExecution((uint256,uint8,address,uint40))
Arguments
{
  "0": [
    "100",
    "1",
    "0x9A1F491B86D09fC1484b5fab10041B189B60756b",
    "1"
  ]
}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total
Filter:
VoterChoice% of totalRationale
570x57ab…2922For144.3K0.00%—3y ago
320x329c…3ed4For103.1K0.00%—3y ago
130x13bd…8548For60K0.00%—3y ago
230x2331…7e73For60K0.00%—3y ago
2C0x2cc1…4df1For43.7K0.00%—3y ago
B90xb933…8dd1For42.6K0.00%—3y ago
EZezr3al.eth0x8659…7d0eFor38.1K0.00%—3y ago
E40xe459…e666For20K0.00%—3y ago
180x1855…98baFor3.6K0.00%—3y ago
EA0xea17…6676For38.60.00%—3y ago
570x5762…a752For10.00%—3y ago
Showing 11

07Forum

No forum thread is confidently linked to this proposal.