Lending Protocol (Re-Audit) - Ripple

1. Introduction

Ripple engaged Halborn to perform a diff-based re-audit of the Lending Protocol following significant code changes since the prior summer audit. The engagement ran from December 16, 2025, to January 12, 2026, spanning 20 days with a complexity rating of 3. The scope focused on reviewing code changes to the Lending Protocol implementation and related specification materials, referencing the XRPL-Standards specification (XLS-0066d) and relevant rippled pull requests. Test directories were excluded from line-count metrics to concentrate on production code.

The objective was to validate the security and correctness of the updated protocol implementation against prior audit findings and the specification. This included verifying transaction validation logic, ensuring state consistency and accounting accuracy, checking parameter validation and access controls, and identifying any discrepancies between the specification and implementation or undocumented behaviors introduced in the recent changes.

2. Assessment Summary

The engagement was scoped as a focused re-audit to verify changes introduced since the prior review. Neither the exact duration nor the number of specialists assigned was specified in the provided materials; therefore, staffing and schedule details are not reported here. The principal objectives were to confirm conformance with the XLS-0066d specification, validate state invariants and transitions, verify parameter and bounds checking, and ensure correct permission semantics and freeze behavior.

The overall security posture was assessed as requiring targeted remediation: multiple issue categories were identified that impact validation logic, state invariants, permission and check enforcement, and timing or edge-case behavior. Recommendations were concentrated on restoring consistent validation, enforcing invariant-preserving checks, improving failure modes to support recoverability, and hardening input and configuration validation to prevent inconsistent protocol states.

- Validation Logic Gaps: Missing checks identified in LoanBrokerSet (vault freeze validation), LoanSet (AssetsMaximum enforcement), and LoanBrokerSet::preflight() (CoverRateMinimum vs CoverRateLiquidation relationship validation), creating inconsistent enforcement of protocol constraints and allowing economically irrational configurations.

- State Invariant Violations: Degraded state design flaw discovered where partial liquidation CoverRateLiquidation < 100%) can break the CoverAvailable >= DebtTotal × CoverRateMinimum invariant, causing protocol freeze while allowing further defaults. Additionally, DebtMaximum validation missing allows unlimited debt when set to zero, and AssetsMaximum bypass via loan interest accumulation.

- Permission and Freeze Enforcement: Inconsistent freeze handling between LoanBrokerSet and LoanSet transactions, with missing vault pseudo-account freeze checks in broker creation. Null pointer dereference vulnerability in SetTrust::preclaim() when both AMM and SingleAssetVault amendments are disabled, potentially causing node crashes.

- Edge Cases and Timing Issues: GracePeriod == PaymentInterval edge case creates cascading payment timing where grace period end coincides with next payment due date. Payment processing limits (100 payments per transaction) cause fee overcharge when users submit amounts exceeding the cap, and overpayment functionality is blocked at the limit even when explicitly requested.

- Specification-Implementation Mismatches: Undocumented behaviors identified including degraded state mode, 100-payment transaction limits, and fee calculation discrepancies. Formula inconsistencies found (e.g., AssetsMaximum check uses AssetsAvailable in spec but should use AssetsTotal). Missing specification coverage for degraded state recovery mechanisms and partial liquidation consequences.

3. Test Approach and Methodology

A layered analysis approach was applied, combining specification review, code-diff analysis, manual code inspection, and automated static analysis. The methodology was structured around the XRP Ledger's three-stage transaction processing model preflight, preclaim, doApply) and emphasized invariant verification, state transition analysis, and cross-referencing between the XLS-0066d specification and C++ implementation. Preparation included scoping the code diff against the previously audited baseline and excluding test-only directories src/test) from metric calculations.

- Transaction Processing Stage Analysis: Each transaction handler was analyzed across preflight() (static validation), preclaim() (ledger-dependent checks including freeze states, null pointer safety, and amendment gating), and doApply() (state mutations and accounting updates), with emphasis on cross-field relationship validation and invariant preservation.

- State Transition and Invariant Verification: Complete workflows were traced (loan lifecycle, broker operations, vault integration) while verifying protocol invariants such as CoverAvailable >= DebtTotal × CoverRateMinimum, AssetsTotal <= AssetsMaximum, and debt limit constraints, including analysis of degraded state scenarios and edge cases like GracePeriod == PaymentInterval and partial liquidation configurations.

- Specification-Code Cross-Reference: Mathematical formulas from XLS-0066d (amortization, interest calculations, first-loss capital liquidation) were validated against implementation, failure conditions were verified for enforcement, and undocumented behaviors (degraded state mode, 100-payment transaction limits) were identified and documented.

- C++ Implementation-Specific Analysis: Memory safety issues were examined including null pointer dereferences with conditional amendment guards, inconsistent null handling patterns, and signal vs exception handling. Amendment gating dependencies were verified for potential bypass paths when features are disabled.

- Coverage Emphasis: Priority was placed on vault and broker workflows, all state update paths in doApply() methods, parameter validation branches including edge cases, failure case handling ensuring proper fee charging, and asset type-specific code paths (XRP, IOU, MPT) for freeze checks and precision handling.