FLO-12: Fee Calculation Diverges From Rate Allocation Formula

[liobrasil]

Severity: Medium

Files Affected

• cadence/contracts/FlowALPv1.cdc

Description

updateInterestRates` allocates fees as an instantaneous rate-based deduction:

// FixedRate path: 
creditRate = debitRate * (1 - protocolFeeRate)

// KinkCurve path: 
debitIncome = totalDebitBalance * debitRate creditRate = (debitIncome - protocolFeeAmount) / totalCreditBalance 

But the actual collection functions compute fees using compounding over the elapsed period:

// collectInsurance (line 1098):
debitIncome = totalDebitBalance * (currentDebitRate^timeElapsed - 1.0) 
insuranceAmount = debitIncome * insuranceRate

// collectStability (line 1168):
interestIncome = totalDebitBalance * (currentDebitRate^timeElapsed - 1.0) 
stabilityAmount = interestIncome * stabilityFeeRate 

These diverge for three reasons:

• totalDebitBalance changes between collections. The collection formula uses the current totalDebitBalance as if it were constant over the entire period, but deposits, withdrawals, and liquidations change it continuously.
• currentDebitRate changes between collections. Utilization changes trigger updateInterestRates, which updates currentDebitRate. The collection formula compounds the current rate over the full elapsed period, not the historical rates that were actually in effect.
• Compounding vs. rate allocation. The rate allocation is a continuous reduction of credit income. The collection formula is a discrete, retroactive calculation applied at collection time. These produce different results for the same inputs. The net effect: the amount collected can be more or less than what was actually allocated through the credit rate reduction, creating accounting drift over time.

Recommendation

Consider using the same formula in both the allocation and collection paths.

---

Parent Issue: #209

[mts1715]

Fix for "3. Compounding vs. rate allocation."

Credit rate calculations:

Сurrent: calculate debitRate (yearly rate) -> calculate creditRate (yearly rate) -> calculate currentCreditRate (per Second Rate) and currentDebitRate (per Second Rate) by dividing 31_557_600.0

Proposed: calculate debitRate (yearly rate) -> calculate currentDebitRate (per Second Rate) -> calculate currentCreditRate (per Second Rate)

Then calculation in updateInterestRates will be:

self.currentDebitRate = FlowALPMath.perSecondInterestRate(yearlyRate: debitRate)
let debitRatePerSecond = self.currentDebitRate - 1.0

// FixedRate path:
self.currentCreditRate = debitRatePerSecond * (1 - protocolFeeRate)

// KinkCurve path:
self.currentCreditRate = debitRatePerSecond * (1 - protocolFeeRate) * totalDebitBalance / totalCreditBalance

But in this case at collectInsurance and collectStability:

because of creditIncome == debitIncome - protocolFeeIncome:

debitIncome = totalDebitBalance * (currentDebitRate^timeElapsed - 1.0)
creditIncome = totalCreditBalance * (currentCreditRate^timeElapsed - 1.0)
protocolFee = debitIncome - creditIncome

insuranceAmount = protocolFee * insuranceRate / (insuranceRate + stabilityFeeRate)
stabilityAmount = protocolFee * stabilityFeeRate / (insuranceRate + stabilityFeeRate)

Example of calculated effective rates for FixedRate path and for KinkCurve (totalDebitBalance / totalCreditBalance == 1/2):

N = 31557600 // seconds in year
effectiveDebitRate = (1 + debitRate / N) ^ N - 1
effectiveCreditRate = (1 + creditRate / N) ^ N - 1 = (1 + debitRate * (1 - protocolFee) / N) ^ N - 1
effectiveProtocolFee = (effectiveDebitRate - effectiveCreditRate) / effectiveDebitRate

KinkEffCreditRate = (1 + kinkCreditRate / N) ^ N - 1 = (1 + debitRate * (1 - protocolFee) *  (totalDebitBalance / totalCreditBalance) / N) ^ N - 1
KinkEffProtocolFee = (effectiveDebitRate - KinkEffCreditRate) / effectiveDebitRate

debitRate	protocol fee	effDebitRate	effCreditRate	effProtocolFee	KinkEffCreditRate	KinkEffProtocolFee
0,05	0,05	0,05127	0,04865	0,0512	0,02403	0,0625
0,05	0,1	0,05127	0,04603	0,1023	0,02276	0,1124
0,05	0,15	0,05127	0,04342	0,1532	0,02148	0,1622
0,05	0,2	0,05127	0,04081	0,2040	0,02020	0,2120
0,05	0,25	0,05127	0,03821	0,2547	0,01893	0,2617
0,1	0,05	0,10517	0,09966	0,0524	0,04865	0,0749
0,1	0,1	0,10517	0,09417	0,1046	0,04603	0,1247
0,1	0,15	0,10517	0,08872	0,1564	0,04342	0,1744
0,1	0,2	0,10517	0,08329	0,2081	0,04081	0,2239
0,1	0,25	0,10517	0,07788	0,2595	0,03821	0,2733
0,15	0,05	0,16183	0,15315	0,0536	0,07385	0,0873
0,15	0,1	0,16183	0,14454	0,1069	0,06983	0,1370
0,15	0,15	0,16183	0,13598	0,1597	0,06583	0,1865
0,15	0,2	0,16183	0,12750	0,2122	0,06184	0,2358
0,15	0,25	0,16183	0,11907	0,2642	0,05786	0,2849
0,2	0,05	0,22140	0,20925	0,0549	0,09966	0,0998
0,2	0,1	0,22140	0,19722	0,1092	0,09417	0,1493
0,2	0,15	0,22140	0,18530	0,1630	0,08872	0,1986
0,2	0,2	0,22140	0,17351	0,2163	0,08329	0,2476
0,2	0,25	0,22140	0,16183	0,2691	0,07788	0,2964
0,25	0,05	0,28403	0,26807	0,0562	0,12609	0,1121
0,25	0,1	0,28403	0,25232	0,1116	0,11907	0,1615
0,25	0,15	0,28403	0,23677	0,1664	0,11210	0,2106
0,25	0,2	0,28403	0,22140	0,2205	0,10517	0,2594
0,25	0,25	0,28403	0,20623	0,2739	0,09829	0,3079

Possible cases for fix "1. totalDebitBalance changes between collections" and "2. currentDebitRate changes between collections."

A) Collect at every utilization change — call _collectInsurance/_collectStability inside updateForUtilizationChange(), right before updating rates. This shrinks timeElapsed to near-zero at each balance change, making the approximation essentially exact. Downside: insurance requires a DEX swap on every borrow/repay, which is expensive and can fail.

B) Track protocol fee via a separate index — maintain a protocolFeeIndex (like debitInterestIndex) that compounds at the rate debitRate * protocolFeeRate. At collection: feeAccrued = totalDebitBalance_atLastCollection * (feeIndex_now / feeIndex_then - 1). This eliminates Divergence 2 and 3 but still approximates Divergence 1.

C) Split insurance from stability — stability can be collected at every utilization change (no DEX dependency), while insurance collection stays governance-triggered. This handles the majority of drift cheaply.

@liobrasil @jribbink @vishalchangrani @Kay-Zee @nialexsan @holyfuchs

[jribbink]

Something like Option B generally makes sense to me. The edge case that would need to be handled if we track a single "accrued fees" index, instead of separating insurance/stability, would be governance changes (if ratio of insurance/stability fees changes between collections). We would need to make sure that insurance & stability fees are collected any time the protocol fees are updated.

Like you mention, options A/C seem fairly expensive to be running constantly, and maintaining a lazy accounting index seems like the simplest fix to me.

[holyfuchs]

B and C help but don't fully solve the problem.

I would suggest using A but:

• Split _collectInsurance into _withdrawInsurance (no swap) and _swapInsuranceFund (called on schedule).

If moving vault resources around is gas expensive, might be enough to keep a virtual balance, which is then withdrawn from main vault.

[jribbink]

@holyfuchs Isn't "virtual balance" ( or "protocolFeeIndex") what is suggested in approach B?

My understanding is that B would fully solve the problem, as it would exist through the same code path as the existing debit/credit indicies.

I think things like debit balance changes is the purpose of updateForUtilizationChange/updateForTimeChange functions - where these rates/integrals update every time that components in the interest calculations could have changed, but please correct me if I'm wrong.

[holyfuchs]

Since B stated: This eliminates Divergence 2 and 3 but still approximates Divergence 1.
I assumed we would just take the average to calculate divergence 1, but since we have to update the rates anyways every single time someone withdraws / deposits it doesn't make a difference to also have an index on every utilization change.

I think things like debit balance changes is the purpose of updateForUtilizationChange/updateForTimeChange functions - where these rates/integrals update every time that components in the interest calculations could have changed, but please correct me if I'm wrong.

I agree.

[mts1715]

Resume after discussion at team call:

Fix for "3. Compounding vs. rate allocation."

The formula is correct; the new method of protocolFee calculation is acceptable.

Fix "1. totalDebitBalance changes between collections" and "2. currentDebitRate changes between collections."

A) or B) — both are acceptable, but in case of A), without using DEX each time: call _collectInsurance/_collectStability inside updateForUtilizationChange(), use DEX periodically, not every time.
Decide what is easiest to implement — probably it's B).