Lending Protocol Audit | Ripple | Halborn Audit Reports

Summary

100% of all REPORTED Findings have been addressed

About this report

Assessment Type

Assurance Assessment

Date of Engagement

July 21st, 2025 - August 5th, 2025

Source Code

ripple

Assessed Commit ID

72f33d8

Severity Breakdown

0Risk Accepted
1Not Applicable
12Solved
13All Findings

Critical4
- 4Solved
High1
- 1N/A
Medium4
- 4Solved
Low4
- 4Solved
Informational0

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.

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.

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

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)	1
Attack Origin (AO)	Specific (AO:S)	0.2
Attack Cost (AC)	Low (AC:L)	1
	Medium (AC:M)	0.67
	High (AC:H)	0.33
Attack Complexity (AX)	Low (AX:L)	1
	Medium (AX:M)	0.67
	High (AX:H)	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)	0
	Low (C:L)	0.25
	Medium (C:M)	0.5
	High (C:H)	0.75
	Critical (C:C)	1
Integrity (I)	None (I:N)	0
	Low (I:L)	0.25
	Medium (I:M)	0.5
	High (I:H)	0.75
	Critical (I:C)	1
Availability (A)	None (A:N)	0
	Low (A:L)	0.25
	Medium (A:M)	0.5
	High (A:H)	0.75
	Critical (A:C)	1
Deposit (D)	None (D:N)	0
	Low (D:L)	0.25
	Medium (D:M)	0.5
	High (D:H)	0.75
	Critical (D:C)	1
Yield (Y)	None (Y:N)	0
	Low (Y:L)	0.25
	Medium (Y:M)	0.5
	High (Y:H)	0.75
	Critical (Y:C)	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)	1
	Partial (R:P)	0.5
	Full (R:F)	0.25
Scope ( $s$ )	Changed (S:C)	1.25
Scope ( $s$ )	Unchanged (S:U)	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.

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

Scope#

(a) Repository:ripple

(b) Assessed Commit ID:72f33d8f3b6ff3c12b4a2d7ee4b75ffccc537894

9d1a23a811150994e0114c8ea8b07765b2a25613 f8b63228b61e252f3bff5e719dc7618b23cece9d fe4269cf8bcd673407a43f28b9c7c6079571ff5c 1e7462606c14a7b0c1141ca310cc40126e13068f dfc4933c3b4ec1be1e842200a4c214cb631d6005 da14c6f0185f106e4c04bf3220dd0109d5859268 84acebeb7fbcff5540418625abc2f945fd75e5b7 d58399d417fba42a4e505b123ce60aa00b06516c

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

Assessment Summary & Findings Overview#

#	Title	Severity	Score	Status
HAL-01	Loan-Set inside Batch bypasses Counter-party Signature	Critical	10.0	Solved07/29/2025
HAL-02	LoanPay Triggers Unbounded Loop in loanComputePaymentParts	Critical	10.0	Solved10/05/2025
HAL-03	Negative LoanOriginationFee Breaks accountSendMPT Invariant	Critical	10.0	Solved10/24/2025
HAL-04	Zero InterestRate in LoanSet Causes LoanPay divide-by-zero	Critical	10.0	Solved07/23/2025
HAL-05	EscrowFinish Accepts Unbounded Size crypto-condition	High	7.5	Not Applicable07/30/2025
HAL-06	LoanPay Writes Over-Precision debtDecrease	Medium	6.3	Solved10/16/2025
HAL-07	LoanPay Can Drive totalInterestOutstanding Below Zero	Medium	6.3	Solved10/21/2025
HAL-08	LoanPay Stores Inconsistent Principal	Medium	6.3	Solved10/21/2025
HAL-09	LoanPay Writes Over-Precision totalPrincipalPaid	Medium	5.6	Solved10/21/2025
HAL-10	LoanPay Stores Over-Precision totalInterestPaid	Low	3.1	Solved10/21/2025
HAL-11	LoanSet allows an overflow in NextPaymentDueDate	Low	3.1	Solved10/26/2025
HAL-12	LoanSet accepts out-of-range InterestRate	Low	2.5	Solved07/30/2025
HAL-13	DebtMaximum = 0 Mistakenly Blocks All Loans	Low	2.5	Solved07/30/2025

Findings & Tech Details#

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

Description

Proof of Concept

Recommendation

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

d58399d417fba42a4e505b123ce60aa00b06516c

Disclaimer#

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.