Amendment XLS: Collateral Lock for Loans

[baali-who]

Summary

XLS-66 loans carry no on-ledger collateral by design. Builders who want collateral pair a loan with an XLS-85 token escrow that does not know the loan exists, so release depends on a key holder, a secret, a bot or a timer.

On Devnet (stock rippled 3.4.1) we reproduced three failures, each tesSUCCESS:

• a pledged escrow released while its loan was unpaid: 3B32B17240A4BD0E8D6D75DA97D813040B6124C90151E8B06EBAF9AD14D79D26;
• the borrower cancelling it mid-loan, after a CancelAfter that fell before the loan's maturity, with the loan unpaid: 8E74D68A1EF3DC23DFF3FB32B827BD3855BDEF37252729E1813F20446876700B;
• the collateral taken after the loan was repaid: E100E8DDDE102306067F3BF20E6EC6058E7E348B5E4E2E4A8D91FE7D27358FEB.

Devnet resets, so the submit and tx JSON for all three, and the standalone and two-validator run logs, are at https://github.com/LiquidTeams/collateral-lock-evidence.

Proposal: CollateralLock

• One optional field, Loan.CollateralID, set by LoanSet, names a token escrow owned by and payable to the borrower. The escrow's existing LoanID field (added to the Escrow format) points back.
• While the loan is unpaid, EscrowFinish and EscrowCancel on that escrow fail for every account with a new result code, tecPLEDGED, until the escrow's own CancelAfter passes.
• After payoff, the normal escrow rules apply again.
• On LoanManage with tfLoanDefault, the same transaction moves the escrowed amount to the loan broker's owner and deletes the escrow. The sweep behaves exactly as an EscrowFinish submitted by the broker owner as destination (XLS-85 rules).
• No oracle, no new ledger object, and one invariant (ValidCollateralLock). A loan without CollateralID behaves exactly as today.

Loan state	EscrowFinish / EscrowCancel on the pledged escrow
Unpaid, before the escrow's CancelAfter	tecPLEDGED (checked in preclaim, for every account)
Unpaid, after CancelAfter (the broker never defaulted)	the pledge lapses: normal escrow rules, the borrower can cancel
Paid off, or deleted after payoff	normal escrow rules
LoanManage tfLoanDefault	the default sweeps it to the broker owner in the same transaction

Reference implementation

• Branch: collateral-lock-develop on https://github.com/LiquidTeams/rippled. It is six commits on top of develop, with the amendment at Supported::No. Draft PR: feat: Add CollateralLock amendment rippled#8652.
• Tests, on the develop-based branch: a CollateralLock jtx suite of 11 cases, 1,377 checks and 0 failures (including IOU collateral and the lapse rule); the full xrpld --unittest run, 260 suites, 5,361 cases, 1,309,095 checks, 0 failures.
• Earlier runs (rippled 3.4.1 branch, built at XRPL Hackathon NYC, Oct 24–25 2026): a standalone node, and a private two-validator test network running the same binary. All 23 transactions agreed on both nodes.

The draft spec follows the XLS template, with ## Ledger Entry: and ## Transaction: sections for Loan, Escrow, LoanSet, EscrowFinish, EscrowCancel and LoanManage. We will open it as a Draft PR after this discussion.

Two design choices we'd like reviewed

1. Liveness: the pledge lapses at the escrow's own CancelAfter. LoanSet requires the escrow to have a CancelAfter no earlier than Maturity + GracePeriod, so the broker always has at least one grace period after maturity in which only it can act (default and sweep). If it never defaults, the borrower can cancel the escrow after CancelAfter, as with any XLS-85 escrow; the loan stays unpaid and can still be defaulted for the cover and vault accounting. We rejected a margin after NextPaymentDueDate + GracePeriod (it needs a new constant or field, and keys off a value the borrower resets by paying) and letting anyone trigger the default (it changes XLS-66's broker-only default and forces the broker's cover to be liquidated). Is one GracePeriod the right protocol floor?
2. The sweep is an EscrowFinish by the destination. The broker owner signs the LoanManage, so XLS-85's "recipient submits" rules apply: RequireAuth, deep freeze and MPT lock on the broker owner block it, the holding is created if missing, and the trust-line limit is not checked. We rejected a pledge-time capacity check because limits, balances and issuer rates can change before default, and duplicating the delivery arithmetic in preclaim risks divergence. Does reusing the XLS-85 destination rules read right to you?
3. Recovery priority. The default pays the broker owner (the first-loss capital), because an XLS-65 vault is single-asset and can't hold a different collateral asset. Is that the right default, with senior-first recovery as a follow-up?
4. Shape. Should this be a separate XLS (requires: XLS-66, XLS-85) or a nested patch under XLS-66, like the two-step loan creation in PR XLS-65/66: Two-step loan creation (LendingProtocolV1_2) #570? If two-step creation lands, CollateralID would move to LoanAccept.

Authors: Alexander Baalmann (@baali-who), Harry Malinski (@hmalinski), LiquidAcre.