[Tapanito]

High Level Overview of Change

Specifies cash-basis (principal-only) Vault and LoanBroker accounting under the LendingProtocolV1_1 amendment, as two nested patches:

• XLS-0065-single-asset-vault/65.1/65.1.3-vault-cash-basis.md: adds Vault.LEVersion. VaultCreate sets it to 1 while the amendment is enabled. Absent means instant interest recognition (pre-amendment Vaults); 1 means cash basis. Also amends the XLS-65 LoanSet cap invariant (item 11) and adds LEVersion to vault_info.
• XLS-0066-lending-protocol/66.1/66.1.1-loan-cash-basis.md: for a Vault with LEVersion == 1, LoanBroker.DebtTotal tracks principal only and Vault.AssetsTotal takes interest only when it is paid.
  • LoanSet: no InterestDue in AssetsTotal or DebtTotal. Checks 6 and 14 do not apply. Checks 19 and 20 drop InterestDue.
  • LoanPay: DebtTotal decreases by principalPaid, AssetsTotal increases by interestPaid. valueChange is not applied to either.
  • LoanManage: DefaultAmount, LossUnrealized and LossReversed are Loan.PrincipalOutstanding, and impair check 8 matches.
  • Appendix formula (34) and the valueChange statements are scoped. Includes a worked example of a default under both models.

These fill the 65.1.3 and 66.1.1 numbers that master reserved. The 65.1 and 66.1 index tables, and the amendment lists and changelogs in the base READMEs, now link them.

The base XLS-65 and XLS-66 READMEs match master, apart from those links and two base-spec fixes in XLS-66 that apply to every Vault:

• DefaultCovered in §3.1.11 and Appendix formula (35) is also capped by CoverAvailable, as §3.10.5 already is.
• Appendix A-3.2.2 now says late-payment valueChange is reflected in LoanBroker.DebtTotal through the totalToVault - valueChange reduction in §3.11.5.

Out of scope: moving existing Vaults to cash basis (pre-amendment Vaults keep instant interest recognition), and changes to Loan fields.

Type of Change

• XLS Update (changes to an existing XLS)

[Copilot]

🟡 Changes recommended

There is a spec inconsistency in XLS-65 where cash-basis accounting is described as LEVersion = 2 in one section but LEVersion = 1 everywhere else, which would make amendment gating ambiguous.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the XLS-65 and XLS-66 specifications to define LendingProtocolV1_1 accounting behavior where Vault.AssetsTotal and LoanBroker.DebtTotal become principal-only (excluding interest), while preserving pre-amendment behavior for legacy (LEVersion absent) vaults.

Changes:

• Adds LendingProtocolV1_1-scoped Failure Conditions and State Changes for LoanSet, LoanPay, and LoanManage to implement principal-only AssetsTotal/DebtTotal accounting and remove valueChange reconciliation under the amendment.
• Introduces Vault.LEVersion (protocol-set) in XLS-65 to gate legacy vs cash-basis accounting behavior, plus corresponding VaultCreate state-change semantics.
• Adds an extended worked example comparing pre- vs post-amendment trajectories for LoanSet → LoanPay → LoanManage(tfLoanDefault).

File summaries

File	Description
XLS-0066-lending-protocol/README.md	Adds amendment-specific Failure Conditions/State Changes and clarifies valueChange becomes dead output under principal-only accounting.
XLS-0065-single-asset-vault/README.md	Defines Vault.LEVersion and documents cash-basis vs accrual-basis accounting and amendment-gated creation behavior.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xrplf-ai-reviewer]

LEVersion spec inconsistency - see inline.

[xrplf-ai-reviewer]

Doc-only spec amendment (XLS-65/XLS-66) defining principal-only Vault/LoanBroker accounting under LendingProtocolV1_1. The worked numeric example in §3.10.5.2 checks out arithmetically for both pre- and post-amendment trajectories, and the new patch-changelog README pattern is consistent with the #570 convention. Found one internal inconsistency: the amended AssetsMaximum failure-condition check in LoanSet keeps a parenthetical description referencing 'interest' even though the whole point of the amendment is that AssetsTotal no longer includes interest at LoanSet time.

[xrplf-ai-reviewer]

This is a documentation-only change adding two amendment patches (XLS-65.1 and XLS-66.1) plus corresponding cross-linked sections in the XLS-65/XLS-66 top-level READMEs. The worked numeric example in the LoanManage section was checked line-by-line and the arithmetic (LoanSet → LoanPay → default, pre- vs post-amendment) is internally consistent. Cross-reference anchors (GitHub heading-slug format) all resolve correctly to the new subsections they point to. Three issues are worth a second look: the MR description's stated non-goal ('no new Vault-level field') is contradicted by the diff, which does add Vault.LEVersion; the new LEVersion field's stated default value disagrees between the XLS-65.1 patch doc ('absent') and the consolidated XLS-65 README ('0'); and the LoanBrokerSet closed-ended check is spliced directly into the existing numbered failure list instead of following the dedicated 'amendment subsection' pattern (X.X.X.3 (LendingProtocolV1_1)) used consistently everywhere else in this same diff.

[xrplf-ai-reviewer]

This is a doc-only spec amendment (XLS-65.1 / XLS-66.1) defining principal-only accounting for LendingProtocolV1_1. The worked numeric example in XLS-66's LoanManage section was checked end-to-end and is internally consistent (all arithmetic ties out across pre- and post-amendment trajectories). Cross-references and anchors between the two top-level READMEs and their new subpages line up correctly. One concrete inconsistency was found: the new LEVersion field is documented as immutable in prose and in an explicit invariant, but the field table in the main XLS-65 README marks it as non-constant (mutable), while the parallel table in the new XLS-65.1 file marks the same field as constant.

[xrplf-ai-reviewer]

This is a documentation-only PR (three new/updated XLS spec files) with no source code changed. The math in the worked LoanManage default example checks out exactly, and nearly all new cross-reference anchors/relative links resolve correctly, and steps replacing the base spec's numbered items (3.2.6.1, 3.8.6.1, 3.10.5.1, 3.11.5.1) correctly preserve the original item numbers. The one clear defect found is a self-inconsistent list numbering in the new 66.1 patch doc's Failure Conditions section, which says checks '19 and 20' are being replaced but then labels the replacement items '1.' and '2.' instead — inconsistent both internally and against the main README's §3.8.5.3, which correctly keeps '19.'/'20.'. Separately, the MR description states LoanBrokerSet now requires attaching only to a closed-ended Vault, but no such change appears anywhere in the provided diff — worth double-checking that this part of the change wasn't dropped from the submitted diff.

[Copilot]

🟡 Changes recommended

Two remaining documentation conflicts make the cap and default-example semantics inconsistent.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

XLS-0065-single-asset-vault/README.md:118

• The new canonical definition makes AssetsMaximum a deposit cap that interest may exceed, but the unchanged VaultSet field table at line 481 still calls it “the maximum asset amount that can be held in a vault.” These definitions conflict and can lead clients to treat an interest overrun as invalid; update the VaultSet description to use the same deposit-cap semantics while retaining its rule against setting a nonzero cap below current AssetsTotal.

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

[xrplf-ai-reviewer]

This is a documentation-only change adding the LendingProtocolV1_1 cash-basis accounting amendment (XLS-65.1.3, XLS-66.1) plus corresponding edits to the XLS-65/XLS-66 base specs. I traced the amendment gating logic (LEVersion branches in LoanSet/LoanPay/LoanManage failure conditions and state changes) and re-derived the numeric worked example in §3.10.5.1 step by step (100,000 → 100,090/100,000 → 99,550.45/99,550) — all arithmetic and cross-reference anchors check out and are internally consistent between the main README and the new 66.1/65.1.3 sub-specs. I did not find a confident correctness bug in the changed (+) lines.

[Copilot]

🟡 Changes recommended

Remaining cap and valueChange descriptions conflict with the newly specified cash-basis behavior.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

XLS-0065-single-asset-vault/README.md:118

• should-fix: Although the canonical and VaultCreate rows now define AssetsMaximum as a deposit cap that interest may exceed, the VaultSet field row at line 481 still calls it “the maximum asset amount that can be held.” That remaining hard-cap definition contradicts the reachable interest-over-cap states documented by invariant 11 and cash-basis LoanPay. Update the VaultSet row to use the same deposit-cap semantics while retaining its rule against setting a nonzero cap below the current total.

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

[xrplf-ai-reviewer]

Documentation-only PR (XLS-65.1.3 / XLS-66.1) that defines cash-basis (principal-only) accounting for Vault/LoanBroker under LendingProtocolV1_1. The core amendment logic (LEVersion gating, DebtTotal/AssetsTotal changes for LoanSet/LoanPay/LoanManage, and the added CoverAvailable cap on DefaultCovered) is internally consistent and the worked numeric example checks out arithmetically. One notable inconsistency: the base Vault field table's 'Constant' column was bulk-edited to mark several fields as unconditionally immutable, which contradicts the amendment-gated immutability described elsewhere in the same document for those same fields.

[Copilot]

🔵 Needs a closer look

Consensus-critical accounting changes require final human validation against the corresponding rippled implementation.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[xrplf-ai-reviewer]

This is a documentation-only change to the XLS-65/XLS-66 spec adding LEVersion-gated cash-basis accounting for Vault/LoanBroker under LendingProtocolV1_1. I traced the new worked numeric example in 66.1 §3.10.5.1 end-to-end (LoanSet → LoanPay → LoanManage default) for both the legacy and cash-basis trajectories and all arithmetic checks out (100,090/1,090 pre-amendment vs 100,000/1,000 post-amendment at origination; 99,550.45 vs 99,550 at default). I also cross-checked that every failure-condition and state-change branch introduced for LendingProtocolV1_1 in the main XLS-65/XLS-66 READMEs has a matching, consistent counterpart in the new 65.1.3 and 66.1 sub-spec files (checks 6/14/19/20 on LoanSet, check 8 on LoanManage, DefaultAmount/LossUnrealized/LossReversed on LoanManage, and the LoanPay valueChange vs principalPaid/interestPaid split), and found no missed branches or contradictions. The unrelated-looking 'Constant' column churn in the Vault field table and the added CoverAvailable cap in the DefaultCovered formula both appear to be legitimate, self-consistent corrections (matching the already-documented 65.1.1 immutability list and the worked example, respectively) rather than bugs introduced by this diff. I did not find any correctness, security, or consistency issues worth flagging in the changed lines.

[Tapanito]

@frytegg This is obsolete now. The §2.7 deferral line to #587 was removed when this PR was split into 65.1.3 / 66.1.1. On master, the closed-ended LoanBrokerSet rule is in 66.1.2 Closed-Ended Loan Gates §3.3.

[xrplf-ai-reviewer]

Specification cross-reference error - see inline.

[xrplf-ai-reviewer]

Normative cross-reference error: 'check 14' doesn't exist in enumeration (checks 6–7 above). Change '14' to '7':

Suggested change

Checks 6 and 14 do not apply to a cash-basis Vault because origination does not credit `InterestDue` into `Vault.AssetsTotal`. A replacement such as `Vault.AssetsTotal > Vault.AssetsMaximum` is not used: it would reject origination from a Vault that is over the cap only because of collected interest. The matching change to the Vault cap invariant is in [XLS-65.1.3](../../XLS-0065-single-asset-vault/65.1/65.1.3-vault-cash-basis.md) §3.1.4.

Checks 6 and 7 do not apply to a cash-basis Vault because origination does not credit `InterestDue` into `Vault.AssetsTotal`.

Suggested change

Checks 6 and 14 do not apply to a cash-basis Vault because origination does not credit `InterestDue` into `Vault.AssetsTotal`. A replacement such as `Vault.AssetsTotal > Vault.AssetsMaximum` is not used: it would reject origination from a Vault that is over the cap only because of collected interest. The matching change to the Vault cap invariant is in [XLS-65.1.3](../../XLS-0065-single-asset-vault/65.1/65.1.3-vault-cash-basis.md) §3.1.4.

Checks 6 and 7 do not apply to a cash-basis Vault because origination does not credit `InterestDue` into `Vault.AssetsTotal`. A replacement such as `Vault.AssetsTotal > Vault.AssetsMaximum` is not used: it would reject origination from a Vault that is over the cap only because of collected interest. The matching change to the Vault cap invariant is in [XLS-65.1.3](../../XLS-0065-single-asset-vault/65.1/65.1.3-vault-cash-basis.md) §3.1.4.

[Copilot]

Copilot review overview

🟡 Changes recommended

The amended checks are misnumbered, and both implementation-affecting patches lack mandatory test plans.

Review effort: Balanced
Findings: 1 · 2

Open (3)

• Preserve parent check numbering · New
• Add implementation test plan for Vault changes · New
• Add implementation test plan for loan accounting · New

[mvadari]

This is a reasonable suggestion

[mvadari]

Link won't work here

[xrplf-ai-reviewer]

This is a documentation-only MR adding two new XLS spec patches (65.1.3 and 66.1.1) plus index/README wiring and two base-spec fixes to XLS-66 (capping DefaultCovered by CoverAvailable, and clarifying that late-payment valueChange is reflected in LoanBroker.DebtTotal). I checked the worked example in 66.1.1 §3.5 arithmetic end-to-end (LoanSet, LoanPay, LoanManage default under both the legacy and cash-basis models) and all intermediate figures (AssetsTotal, AssetsAvailable, DebtTotal, DefaultAmount, MinimumCover, DefaultCovered, VaultLoss, CoverAvailable) are internally consistent and reconcile correctly. The cross-references between the two new files (65.1.3's LoanSet cap invariant rewrite vs. 66.1.1's checks 6/14/19/20) are mutually consistent, and the two base-spec fixes in XLS-66 README correctly match their stated rationale (capping DefaultCovered by CoverAvailable prevents it from driving CoverAvailable negative; the A-3.2.2 clarification matches the actual §3.11.5 state-change formula). No logic errors, broken cross-links, or arithmetic mistakes were found in the changed content, so no actionable issues are being raised.