Parameters
string
required
64-character hex object ID of the
Vault ledger entry. The first LoanBroker associated with the vault is used. Case insensitive.Request
Response
Response Fields
string
64-character hex object ID of the
LoanBroker whose history was reconstructed.string
XRPL address of the vault manager who controls this broker.
array
All default, impairment, and cover-deposit events found in the broker’s public transaction history, in chronological order.
object
Analysis of how the manager’s declaration order compared to the sequence most beneficial to depositors.
object
Composite reputation grade and supporting findings.
object
Forward-looking advice on which distressed loan to declare next.
The cover liquidated on any one default is
T(p) = min(⌈D × c_min × c_liq⌉, p, C) where D is the broker’s total book — not the principal of the exposure that defaulted — and D decrements as each default lands. Declaring the largest exposure first consumes the least first-loss capital. In the captured example, declaring 30 XRP first then 10 XRP consumed 500 000 drops of cover; the reverse order would have consumed 700 000. The 200 000 drop difference falls on unit holders despite identical total losses.LoanManage carries no LoanBrokerID, and an impairment does not touch the LoanBroker object at all — so a naive filter over account_tx silently drops every impairment. The join that recovers them is Loan.FinalFields.LoanBrokerID in the same transaction’s metadata. Without this join, every unsignalled default looks like the manager was penalised for disclosing; with it, the record is complete.