Lending Protocol - Ripple

Prepared by:

HALBORN

Last Updated 12/04/2025

Date of Engagement: July 21st, 2025 - August 5th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary

2.1 Methodology

3. Risk methodology
4. Scope
5. Assessment summary & findings overview
6. Findings & Tech Details

6.1 Loan-set inside batch bypasses counter-party signature
6.2 Loanpay triggers unbounded loop in loancomputepaymentparts
6.3 Negative loanoriginationfee breaks accountsendmpt invariant
6.4 Zero interestrate in loanset causes loanpay divide-by-zero
6.5 Escrowfinish accepts unbounded size crypto-condition
6.6 Loanpay writes over-precision debtdecrease
6.7 Loanpay can drive totalinterestoutstanding below zero
6.8 Loanpay stores inconsistent principal
6.9 Loanpay writes over-precision totalprincipalpaid
6.10 Loanpay stores over-precision totalinterestpaid
6.11 Loanset allows an overflow in nextpaymentduedate
6.12 Loanset accepts out-of-range interestrate
6.13 Debtmaximum = 0 mistakenly blocks all loans

1. Introduction

XRPL Foundation engaged Halborn to conduct a focused security assessment of the current system, with particular emphasis on the new XLS-66 Lending Protocol. The engagement took place from 21 July 2025 to 05 August 2025. The scope, detailed in the scope section, encompassed all modules implementing or interacting with Lending functionality, including Loan, Vault, LoanBroker, batch helpers, invariants, and the supporting math/utilities—along with the unit-test harness and newly developed fuzzers.

The XRPL (XRP Ledger) is a decentralized layer-1 network supporting payments, tokenization, and, through recent amendments, increasingly sophisticated DeFi primitives. XLS-66 extends this stack with native collateralized lending: borrowers open Vaults, draw Loans, and interact with on-ledger Loan Brokers that manage interest, fees, and claw-backs.

While the amendment introduces powerful functionality, it also adds complex state machines, long-lived accounting fields, and precision-sensitive arithmetic—areas prone to subtle security vulnerabilities. Ensuring the protocol’s correctness is therefore critical to safeguarding user funds and maintaining XRPL’s low-latency, deterministic consensus guarantees.

2. Assessment summary

Halborn assigned a full-time senior security engineer specializing in C++ ledger internals, consensus protocols, and decentralized finance. The objectives were to:

• Verify that Lending logic strictly enforces its economic and safety invariants

• Identify vulnerabilities that could result in fund loss, ledger corruption, consensus failure, or denial of service

All identified issues are reproducible with single transactions at standard fees. Proof-of-Concepts (PoCs) have been provided. Full details and remediation guidance are available in the Findings section.

2.1 Methodology

Halborn employed a hybrid approach:

• Architectural review of XLS-66 data flow and state machines

• Manual source code inspection of C++ transaction paths, helpers, and invariants

• Differential analysis comparing pre-Lending behavior

• Custom invariant-enabled fuzzers

3. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

3.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A) Specific (AO:S)	1 0.2
Attack Cost (AC)	Low (AC:L) Medium (AC:M) High (AC:H)	1 0.67 0.33
Attack Complexity (AX)	Low (AX:L) Medium (AX:M) High (AX:H)	1 0.67 0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

3.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C)	0 0.25 0.5 0.75 1
Integrity (I)	None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C)	0 0.25 0.5 0.75 1
Availability (A)	None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C)	0 0.25 0.5 0.75 1
Deposit (D)	None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C)	0 0.25 0.5 0.75 1
Yield (Y)	None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C)	0 0.25 0.5 0.75 1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

3.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Severity	Score Value Range
Critical	9 - 10
High	7 - 8.9
Medium	4.5 - 6.9
Low	2 - 4.4
Informational	0 - 1.9

4. SCOPE

REPOSITORY

(a) Repository: ripple

(b) Assessed Commit ID: 72f33d8

Remediation Commit ID:

Out-of-Scope: New features/implementations after the remediation commit IDs.

5. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Security analysis	Risk level	Remediation Date
Loan-Set inside Batch bypasses Counter-party Signature	Critical	Solved - 07/29/2025
LoanPay Triggers Unbounded Loop in loanComputePaymentParts	Critical	Solved - 10/05/2025
Negative LoanOriginationFee Breaks accountSendMPT Invariant	Critical	Solved - 10/24/2025
Zero InterestRate in LoanSet Causes LoanPay divide-by-zero	Critical	Solved - 07/23/2025
EscrowFinish Accepts Unbounded Size crypto-condition	High	Not Applicable - 07/30/2025
LoanPay Writes Over-Precision debtDecrease	Medium	Solved - 10/16/2025
LoanPay Can Drive totalInterestOutstanding Below Zero	Medium	Solved - 10/21/2025
LoanPay Stores Inconsistent Principal	Medium	Solved - 10/21/2025
LoanPay Writes Over-Precision totalPrincipalPaid	Medium	Solved - 10/21/2025
LoanPay Stores Over-Precision totalInterestPaid	Low	Solved - 10/21/2025
LoanSet allows an overflow in NextPaymentDueDate	Low	Solved - 10/26/2025
LoanSet accepts out-of-range InterestRate	Low	Solved - 07/30/2025
DebtMaximum = 0 Mistakenly Blocks All Loans	Low	Solved - 07/30/2025

6. Findings & Tech Details

6.1 Loan-Set inside Batch bypasses Counter-party Signature

Critical

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:H/I:C/D:C/Y:N (10.0)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/9d1a23a811150994e0114c8ea8b07765b2a25613

6.2 LoanPay Triggers Unbounded Loop in loanComputePaymentParts

Critical

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:C/I:N/D:N/Y:N (10.0)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/f8b63228b61e252f3bff5e719dc7618b23cece9d

6.3 Negative LoanOriginationFee Breaks accountSendMPT Invariant

Critical

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:C/I:N/D:N/Y:N (10.0)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/fe4269cf8bcd673407a43f28b9c7c6079571ff5c

6.4 Zero InterestRate in LoanSet Causes LoanPay divide-by-zero

Critical

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:C/I:N/D:N/Y:N (10.0)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/1e7462606c14a7b0c1141ca310cc40126e13068f

6.5 EscrowFinish Accepts Unbounded Size crypto-condition

High

Description

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:H/D:N/Y:N (7.5)

Recommendation

Remediation Comment

6.6 LoanPay Writes Over-Precision debtDecrease

Medium

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:M/I:M/D:N/Y:N (6.3)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/dfc4933c3b4ec1be1e842200a4c214cb631d6005

6.7 LoanPay Can Drive totalInterestOutstanding Below Zero

Medium

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:M/I:M/D:N/Y:N (6.3)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/dfc4933c3b4ec1be1e842200a4c214cb631d6005

6.8 LoanPay Stores Inconsistent Principal

Medium

Description

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:M/I:M/D:N/Y:N (6.3)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/dfc4933c3b4ec1be1e842200a4c214cb631d6005

6.9 LoanPay Writes Over-Precision totalPrincipalPaid

Medium

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:M/I:L/D:N/Y:N (5.6)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/dfc4933c3b4ec1be1e842200a4c214cb631d6005

6.10 LoanPay Stores Over-Precision totalInterestPaid

Low

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:L/I:L/D:N/Y:N (3.1)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/dfc4933c3b4ec1be1e842200a4c214cb631d6005

6.11 LoanSet allows an overflow in NextPaymentDueDate

Low

Description

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:L/I:L/D:N/Y:N (3.1)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/commit/da14c6f0185f106e4c04bf3220dd0109d5859268

6.12 LoanSet accepts out-of-range InterestRate

Low

Description

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:L/D:N/Y:N (2.5)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/pull/5270/commits/84acebeb7fbcff5540418625abc2f945fd75e5b7

6.13 DebtMaximum = 0 Mistakenly Blocks All Loans

Low

Description

Proof of Concept

BVSS

AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:L/D:N/Y:N (2.5)

Recommendation

Remediation Comment

Remediation Hash

https://github.com/XRPLF/rippled/pull/5270/commits/d58399d417fba42a4e505b123ce60aa00b06516c

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

1. Introduction
2. Assessment summary

2.1 Methodology

3. Risk methodology
4. Scope
5. Assessment summary & findings overview
6. Findings & Tech Details

6.1 Loan-set inside batch bypasses counter-party signature
6.2 Loanpay triggers unbounded loop in loancomputepaymentparts
6.3 Negative loanoriginationfee breaks accountsendmpt invariant
6.4 Zero interestrate in loanset causes loanpay divide-by-zero
6.5 Escrowfinish accepts unbounded size crypto-condition
6.6 Loanpay writes over-precision debtdecrease
6.7 Loanpay can drive totalinterestoutstanding below zero
6.8 Loanpay stores inconsistent principal
6.9 Loanpay writes over-precision totalprincipalpaid
6.10 Loanpay stores over-precision totalinterestpaid
6.11 Loanset allows an overflow in nextpaymentduedate
6.12 Loanset accepts out-of-range interestrate
6.13 Debtmaximum = 0 mistakenly blocks all loans

// Download the full report

Lending Protocol

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed