-
Notifications
You must be signed in to change notification settings - Fork 2
Extract ALP components into separate contracts #160
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
Changes from all commits
8068f3e
4495f56
0e0971f
9c6a872
14efe59
20f7c06
6d9797e
959f911
9a9c7eb
9608242
0b642e0
dc21efb
27eeb56
d54d045
736c525
1d499a4
06ea494
ed7e79b
9c857c9
e34490b
1594fba
48f6f13
31c1881
8b97782
beb8344
a8cac7a
fbbd96c
426b45d
b33abcf
56377c8
6b9ea32
fe5101c
9176c85
2668f7b
5ebf9b2
4edda6f
8e02c11
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,131 @@ | ||
| import "FlowALPMath" | ||
|
|
||
| access(all) contract FlowALPInterestRates { | ||
|
|
||
| /// InterestCurve | ||
| /// | ||
| /// A simple interface to calculate interest rate for a token type. | ||
| access(all) struct interface InterestCurve { | ||
| /// Returns the annual interest rate for the given credit and debit balance, for some token T. | ||
| /// @param creditBalance The credit (deposit) balance of token T | ||
| /// @param debitBalance The debit (withdrawal) balance of token T | ||
| access(all) fun interestRate(creditBalance: UFix128, debitBalance: UFix128): UFix128 { | ||
| post { | ||
| // Max rate is 400% (4.0) to accommodate high-utilization scenarios | ||
| // with kink-based curves like Aave v3's interest rate strategy | ||
| result <= 4.0: | ||
| "Interest rate can't exceed 400%" | ||
| } | ||
| } | ||
| } | ||
|
|
||
| /// FixedCurve | ||
| /// | ||
| /// A fixed-rate interest curve implementation that returns a constant yearly interest rate | ||
| /// regardless of utilization. This is suitable for stable assets like MOET where predictable | ||
| /// rates are desired. | ||
| /// @param yearlyRate The fixed yearly interest rate as a UFix128 (e.g., 0.05 for 5% APY) | ||
| access(all) struct FixedCurve: InterestCurve { | ||
|
|
||
| access(all) let yearlyRate: UFix128 | ||
|
|
||
| init(yearlyRate: UFix128) { | ||
| pre { | ||
| yearlyRate <= 1.0: "Yearly rate cannot exceed 100%, got \(yearlyRate)" | ||
| } | ||
| self.yearlyRate = yearlyRate | ||
| } | ||
|
|
||
| access(all) fun interestRate(creditBalance: UFix128, debitBalance: UFix128): UFix128 { | ||
| return self.yearlyRate | ||
| } | ||
| } | ||
|
|
||
| /// KinkCurve | ||
| /// | ||
| /// A kink-based interest rate curve implementation. The curve has two linear segments: | ||
| /// - Before the optimal utilization ratio (the "kink"): a gentle slope | ||
| /// - After the optimal utilization ratio: a steep slope to discourage over-utilization | ||
| /// | ||
| /// This creates a "kinked" curve that incentivizes maintaining utilization near the | ||
| /// optimal point while heavily penalizing over-utilization to protect protocol liquidity. | ||
| /// | ||
| /// Formula: | ||
| /// - utilization = debitBalance / (creditBalance + debitBalance) | ||
| /// - Before kink (utilization <= optimalUtilization): | ||
| /// rate = baseRate + (slope1 × utilization / optimalUtilization) | ||
| /// - After kink (utilization > optimalUtilization): | ||
| /// rate = baseRate + slope1 + (slope2 × excessUtilization) | ||
| /// where excessUtilization = (utilization - optimalUtilization) / (1 - optimalUtilization) | ||
| /// | ||
| /// @param optimalUtilization The target utilization ratio (e.g., 0.80 for 80%) | ||
| /// @param baseRate The minimum yearly interest rate (e.g., 0.01 for 1% APY) | ||
| /// @param slope1 The total rate increase from 0% to optimal utilization (e.g., 0.04 for 4%) | ||
| /// @param slope2 The total rate increase from optimal to 100% utilization (e.g., 0.60 for 60%) | ||
| access(all) struct KinkCurve: InterestCurve { | ||
|
|
||
| /// The optimal utilization ratio (the "kink" point), e.g., 0.80 = 80% | ||
| access(all) let optimalUtilization: UFix128 | ||
|
|
||
| /// The base yearly interest rate applied at 0% utilization | ||
| access(all) let baseRate: UFix128 | ||
|
|
||
| /// The slope of the interest curve before the optimal point (gentle slope) | ||
| access(all) let slope1: UFix128 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should these be called gentleSlope and steepSlope instead?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any thoughts about my comment here? I still think we should rename these
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with this and the entitlement rename. Just aiming to keep changes beyond the refactor itself outside the scope of this PR. I want to make as many changes here as possible move-only (not move+modify) to make review easier. I can address these as a follow-up.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that makes sense. I'll keep that in mind |
||
|
|
||
| /// The slope of the interest curve after the optimal point (steep slope) | ||
| access(all) let slope2: UFix128 | ||
|
|
||
| init( | ||
| optimalUtilization: UFix128, | ||
| baseRate: UFix128, | ||
| slope1: UFix128, | ||
| slope2: UFix128 | ||
| ) { | ||
| pre { | ||
| optimalUtilization >= 0.01: | ||
| "Optimal utilization must be at least 1%, got \(optimalUtilization)" | ||
| optimalUtilization <= 0.99: | ||
| "Optimal utilization must be at most 99%, got \(optimalUtilization)" | ||
| slope2 >= slope1: | ||
| "Slope2 (\(slope2)) must be >= slope1 (\(slope1))" | ||
| baseRate + slope1 + slope2 <= 4.0: | ||
| "Maximum rate cannot exceed 400%, got \(baseRate + slope1 + slope2)" | ||
| } | ||
| self.optimalUtilization = optimalUtilization | ||
| self.baseRate = baseRate | ||
| self.slope1 = slope1 | ||
| self.slope2 = slope2 | ||
| } | ||
|
|
||
| access(all) fun interestRate(creditBalance: UFix128, debitBalance: UFix128): UFix128 { | ||
| // If no debt, return base rate | ||
| if debitBalance == 0.0 { | ||
| return self.baseRate | ||
| } | ||
|
|
||
| // Calculate utilization ratio: debitBalance / (creditBalance + debitBalance) | ||
| // Note: totalBalance > 0 is guaranteed since debitBalance > 0 and creditBalance >= 0 | ||
| let totalBalance = creditBalance + debitBalance | ||
| let utilization = debitBalance / totalBalance | ||
|
|
||
| // If utilization is below or at the optimal point, use slope1 | ||
| if utilization <= self.optimalUtilization { | ||
| // rate = baseRate + (slope1 × utilization / optimalUtilization) | ||
| let utilizationFactor = utilization / self.optimalUtilization | ||
| let slope1Component = self.slope1 * utilizationFactor | ||
| return self.baseRate + slope1Component | ||
| } else { | ||
| // If utilization is above the optimal point, use slope2 for excess | ||
| // excessUtilization = (utilization - optimalUtilization) / (1 - optimalUtilization) | ||
| let excessUtilization = utilization - self.optimalUtilization | ||
| let maxExcess = FlowALPMath.one - self.optimalUtilization | ||
| let excessFactor = excessUtilization / maxExcess | ||
|
|
||
| // rate = baseRate + slope1 + (slope2 × excessFactor) | ||
| let slope2Component = self.slope2 * excessFactor | ||
| return self.baseRate + self.slope1 + slope2Component | ||
| } | ||
| } | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are the parameters here for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://github.com/onflow/FlowALP/pull/160/changes/BASE..dc21efb1e2fefca3fd6435033e721c0b468b9f97#diff-b68530c0b2e0dcf9d373ec5938f2b1f6222bb11bfb19e8dc333bcae7e48e9e35R10-R11.
(I'm trying to mainly move existing code and not add anything right now to keep the diff clean, but agree there should be documentation here.)