fix: Cap the base fee for LoanPay - #6969
Conversation
|
I've got a handful of failing unit tests. I'll fix those on Monday. |
vlntb
left a comment
There was a problem hiding this comment.
The proposed change fixes the root of the problem by capping the fee at loanMaximumPaymentsPerTransaction * normalCost, avoiding fee calculation for impossibly high payment counts that could cause overflow.
I'll review again once unit tests are finalised. The current Loan_test.cpp lacks explicit coverage for the fee capping logic. Please add tests for:
- Amount exactly at threshold → capped fee
- Amount below threshold → normal calculation
- Amount well above threshold → capped fee
- Amendment guard (
fixSecurity3_1_3on/off)
Note: testDosLoanPay() verifies payment capping but not fee capping.
mathbunnyru
left a comment
There was a problem hiding this comment.
The name of this PR will have to be changed along with the on based on develop, to follow conventional commit rules
- Old and busted: Computing max fee as loanMaximumPaymentsPerTransaction * normalCost; - New hotness: Computing max fee increments as loanMaximumPaymentsPerTransaction / loanPaymentsPerFeeIncrement, then computing max fee as maxFeeIncrements * normalCost, if payment amount >= maxFeeIncrements * periodicPayment.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## ripple/staging-313 #6969 +/- ##
==================================================
Coverage 80.4% 80.4%
==================================================
Files 840 840
Lines 75347 75352 +5
Branches 8200 8200
==================================================
+ Hits 60585 60590 +5
Misses 14762 14762
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR adjusts LoanPay::calculateBaseFee to cap the minimum fee when the transaction amount implies more payments than can actually be processed per transaction, specifically when fixSecurity3_1_3 is enabled.
Changes:
- Introduces a computed
maxFeeIncrementsbased on protocol limits. - Adds an early-return cap intended to prevent charging more fee increments than the transaction can consume in work.
- Adds an
XRPL_ASSERTto enforce the (intended) invariant that fee increments do not exceed the cap under the amendment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Add test cases to exercise the LoanPay fee cap calculation - Fix a bug in the fee cap calculation.
b3d6f82 to
d3e31de
Compare
| NumberRoundModeGuard mg( | ||
| tx.isFlag(tfLoanOverpayment) ? Number::upward : Number::downward); | ||
|
|
||
| static_assert( |
There was a problem hiding this comment.
Why is this using static assert instead of XRPL_ASSERT?
There was a problem hiding this comment.
Because static_assert fails at compile time. If the values are ever changed to something that doesn't match this expectation, it won't build, and thus will fail immediately.
vlntb
left a comment
There was a problem hiding this comment.
The changes since my last approval look correct. All the missing test cases that I highlighted have been addressed.
Approving.
Co-authored-by: Bart <bthomee@users.noreply.github.com>
Co-authored-by: Bart <bthomee@users.noreply.github.com>
High Level Overview of Change
If a
LoanPaypays more thanperiodicPayment * loanMaximumPaymentsPerTransactioncalculate the maximum fee asmaxFeeIncrements * baseFee.maxFeeIncrementsisloanMaximumPaymentsPerTransaction / loanPaymentsPerFeeIncrement.developport: #6970