GET /api/vaults/:vaultId/broker-history — Conduct Record
Reconstructs the broker’s public transaction history, scores the default ordering against the fair sequence, and returns a reputation grade with findings.
Use this endpoint to examine what a vault manager actually did with their cover pool. The response reconstructs the full default and impairment history from public ledger transactions, computes what the fair declaration order would have paid depositors, and grades the manager’s conduct against that benchmark. If two or more distressed loans are currently standing, it also recommends which to declare next to maximise depositor recovery.
Whether the broker’s book state before and after this event could be reconstructed. false for impairments, because LoanImpair does not touch the LoanBroker object.
Number of distressed loans currently eligible for declaration.
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.