Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MaxVariableBorrowRate Limitations in AaveSteward #434

Closed
DhairyaSethi opened this issue Jan 2, 2025 · 0 comments · Fixed by #436
Closed

MaxVariableBorrowRate Limitations in AaveSteward #434

DhairyaSethi opened this issue Jan 2, 2025 · 0 comments · Fixed by #436

Comments

@DhairyaSethi
Copy link
Member

DhairyaSethi commented Jan 2, 2025

In GhoAaveSteward, among the checks done in _validateReservesUpdate there are two which might be conflicting to achieve the same result.
The first is maxAllowed change on the individual borrowRateConfigs (optimalUsageRatio, baseVariableBorrowRate, variableRateSlope1, variableRateSlope2) and the maxVariableBorrowRate (baseVariableBorrowRate + variableRateSlope1 + variableRateSlope2).
The former is configurable (with borrowRateConfig) but the latter has a hard cap of 25%

uint32 public constant GHO_BORROW_RATE_MAX = 0.25e4; // 25.00%

which does not make sense practically for remote chains (arb currently is at 52.5%) as the value seems too low.
One suggestion is to remove the maxVariableBorrowRate check or make the maxAllowed value configurable which can be adjusted on a market-to-market basis.

require(
_updateWithinAllowedRange(
currentRates.variableRateSlope2,
newRates.variableRateSlope2,
_borrowRateConfig.variableRateSlope2MaxChange,
false
),
'INVALID_VARIABLE_RATE_SLOPE2'
);
require(
uint256(newRates.baseVariableBorrowRate) +
uint256(newRates.variableRateSlope1) +
uint256(newRates.variableRateSlope2) <=
GHO_BORROW_RATE_MAX,
'BORROW_RATE_HIGHER_THAN_MAX'
);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant