XRPL's closed-ended vault draft is dissolved into patches on XLS-65 and XLS-66
Victoria Shinder2 min readPR #636 from Tapanito has landed in XRPL-Standards, restructuring the closed-ended vault specification across eight files with 453 additions and 620 deletions - a net reduction of 167 lines. What disappears is a standalone XLS-draft-closed-ended-vault; what appears is a set of nested patches against the documents the feature actually modifies: 65.1.1-unmodifiable-vault-fields.md and a new 65.1.4-closed-ended-vault.md under XLS-0065 single-asset vault, plus 66.1.2-closed-ended-loan-gates.md under XLS-0066 lending protocol.
The commit trail names the review outcomes rather than hiding them: the 65.1.1 abstract was clarified and now links the parent XLS-65 sections from the closed-ended patch; the loan maturity invariant wording was fixed; the requirement was clarified as between VaultCreate and LoanBrokerSet; Test Plan sections were added; code-span formatting corrected.
What it means
Deleting more than you add while adding test plans is a good sign about a specification, and the reason is structural. A standalone draft describing a variant of an existing feature has to restate the base behaviour in order to describe its deviations, and every restatement is a copy that can drift from the original. Expressing the variant as patches on XLS-65 and XLS-66 means the base text is cited rather than reproduced - so a later change to the single-asset vault cannot silently contradict the closed-ended description, because there is no second description to contradict.
That is the same disease this industry keeps rediscovering in code: two descriptions of one thing, and the second one rots. Here the fix was applied to prose before anyone implemented against the duplicate.
The VaultCreate versus LoanBrokerSet clarification is the detail implementers should read first. "Which transaction carries the closed-ended requirement" determines where validation must live and what an existing vault can be turned into after the fact - and an ambiguity there produces two clients that disagree about whether a given state is reachable. The added Test Plan sections are what make that answerable from the document rather than from the first implementation to ship.