On-chain lending is arriving on the XRP Ledger in earnest. XLS-65 (Single Asset Vault) and XLS-66 (Lending Protocol) bring native lending and borrowing into the protocol, and they shipped through one of the most rigorous review processes in XRPL's history.

Most of the conversation so far has been about the happy path: how vaults aggregate capital, how loans get originated, how interest accrues. That's the easy 95%. This post is about the other 5% — the part that's actually hard, and that determines whether the whole system is trustworthy: what happens when a loan defaults.

I want to do two things here, as concretely as I can: walk through how default actually works mechanically in this kind of system, where it goes wrong, and then lay out the real options for resolving it — with honest tradeoffs, not a single answer.

Part 1: How a default actually happens

A loan in this model isn't a single object doing everything. There are a few moving pieces:

• A Vault (XLS-65) holds pooled assets from depositors. Depositors get shares; the vault tracks total assets and any unrealized loss.
• A Loan Broker sits between the vault and borrowers. It originates loans against the vault's capital and, importantly, can post First-Loss Capital — a cushion that absorbs initial losses so depositors aren't the first to take the hit.
• A Loan is the agreement itself: principal, interest rate, payment schedule, the parties.

Default isn't a flag that magically appears. In the XLS-66 model, when a borrower fails to meet their obligations, the loan can be moved into a defaulted state through a management action by the broker (a LoanManage-type transaction), typically after a grace period. That's an important design point: default is an explicit, observable on-chain event with an actor and a transaction behind it — not an ambient condition.

So far, so clean. The mechanics are well-defined. The hard part isn't detecting that a default happened. The hard part is everything that comes after.

Part 2: Where it actually goes bad

Default detection is the easy part. Loss allocation is where the complexity — and the risk — lives. Several things have to be answered, and each is a place where systems break.

1. How much was actually lost?

This sounds trivial and isn't. The loss isn't just "the loan amount." It's the outstanding principal and interest, minus whatever First-Loss Capital absorbs, minus any recovery. Get the order of operations wrong — for instance, paying out on the gross loan instead of the net loss after first-loss capital — and you over-distribute, draining the vault beyond the real loss. This is a correctness bug that looks fine in the happy path and only bites on default.

2. Who absorbs it, and in what order?

First-loss capital, then equity tranches, then senior depositors — the waterfall. In TradFi securitizations this is spelled out in hundreds of pages of legal documents and executed by a servicer. On-chain, it has to be encoded somewhere, and the question is where, and who can change it.

3. Who computes and executes the resolution?

This is the real fork in the road, and it's where the design choices diverge sharply. Someone — or something — has to look at the facts, compute the outcome, and move the funds. That decision is the rest of this post.

The failure modes cluster around #3. The XRPL lending protocol's own security process surfaced exactly these kinds of issues during testing — an inverted invariant that could have let phantom collateral go undetected, rounding errors, and specification-vs-implementation discrepancies. Those are the bugs that live in the resolution path, not the origination path. Default is where subtle errors become expensive.

Part 3: The options for resolving it

Here are the real approaches, with what each is good and bad at. None is strictly correct — they trade off differently depending on who's lending, to whom, and under what trust assumptions.

Option A: Off-chain servicer / workout process

A human or institution decides the outcome, the way TradFi does today.

• Good: handles ambiguity and edge cases human judgment is suited to; legally familiar; flexible.
• Bad: slow; opaque; discretionary. The affected parties have to trust the servicer's decision, often without being able to independently verify it. It's also a single point of pressure — a servicer can be lobbied, captured, or simply wrong. And it doesn't match the settlement speed of the rails the asset now lives on.

Option B: Admin / multisig discretion

A privileged key or a multisig of insiders executes resolution.

• Good: fast to build; flexible; can correct mistakes.
• Bad: the privileged key is the attack surface. If it's compromised, it can release or freeze funds outside any rule. Even when honest, it asks every other participant to trust that the insiders won't act against them. This is the pattern behind a large share of DeFi loss events — the trusted party was the failure.

Option C: Pure smart-contract automation

The resolution logic is encoded in a contract that holds the funds and executes automatically.

• Good: deterministic; no human in the loop; fast.
• Bad: the contract now holds value, which makes it the honeypot. Bugs are exploitable for real money (see: most of DeFi's exploit history). Upgradeability reintroduces an admin key — and the discretion problem with it. And encoding a full loss waterfall correctly in-contract is genuinely hard, as the testing findings above suggest.

Option D: Native protocol primitives (first-loss capital)

The protocol itself absorbs some loss via built-in mechanisms like First-Loss Capital.

• Good: built-in, battle-tested as part of the amendment, no extra trust assumption.
• Bad: it's a cushion, not a full resolution. It absorbs initial loss to protect depositors, but it doesn't by itself answer multi-party waterfalls, disputes, or produce an auditable record of why a given party received what they did. It's necessary, not sufficient, for complex structures.

Option E: A deterministic, non-custodial resolution layer

A separate layer reads ledger state, computes the outcome by fixed rule, and returns an unsigned result the rightful party signs — holding no funds or keys itself.

• Good: deterministic (same facts, same outcome); re-derivable by any third party (you can check it rather than trust it); non-custodial, so there's no honeypot and no admin key to steal or override. Errors are detectable because the result can be replayed against the ledger.
• Bad: it's a newer pattern with less production history; it depends on the relevant facts being fully on-chain and verifiable (if a key input lives off-chain or is asserted rather than derived, the guarantee is only as good as that input); and for simple single-lender vaults it may be more machinery than the situation needs.

So which is right?

Honestly: it depends, and most real deployments will combine several. Native first-loss capital (D) is almost certainly part of any serious design. Simple vaults may be fine with protocol primitives plus minimal automation. Complex, multi-party, institutional structures — where auditability and non-discretion are requirements, not nice-to-haves — are where the deterministic, verifiable approaches (E) earn their complexity. And there will be cases where genuine ambiguity means a human (A) or an arbiter still belongs in the loop, ideally bounded by rules rather than given open discretion.

The honest open questions, for me, are:

• How much of real-world loss allocation can actually be made deterministic, versus how much genuinely requires judgment?
• When an input to resolution isn't natively on-chain, what's the right way to bind it so the resolution stays verifiable?
• How do you handle disputes without reintroducing exactly the discretionary trust you were trying to remove?

I'm building one of the approaches above — a deterministic, non-custodial resolution layer (Ward) — so I have a horse in this race, and I'll be transparent that it's early and still being aligned to the finalized XLS-66 model. But I'm genuinely more interested, right now, in the shape of the problem than in selling a single answer to it. The resolution layer of on-chain lending is underexplored relative to how much it matters, and I'd rather see it figured out well than figured out fast.

If you're working on any part of this — origination, vaults, risk, resolution, or the messy default path specifically — I'd like to compare notes.

---

If you spot something wrong in the mechanics above, tell me — I'd rather be corrected than confident.