5263343 (2026-09-12T22:20:22Z) against Devnet rippled 3.4.0-rc5. Nothing here is a projection. The two haircut figures in Use Case 2 are arithmetic performed on that reading rather than a captured response body, and the text says so where they appear.
The thesis all four cases share: the party who decides when a vault recognises a loss is the same party who decides in what order those losses are realised. The LoanBroker owner is necessarily the vault owner — a protocol fact, not a configuration choice. Both decisions move money from unit holders to that party. Orma measures both from public ledger state, publishes the result where it can be acted on, and lets an independent third party enforce it.
Use Case 1: An LP Choosing Between Two Facilities
Two closed-ended XRP facilities, both in the Investment phase, both scored by the same code path with no weights applied anywhere.
The two columns disagree in exactly the way that matters. Kestrel reports zero NAV divergence. Calder reports 19.61%. A screener that ranks by divergence puts Kestrel on top — Kestrel is the worse facility by a wide margin. The reason is mechanical: divergence only becomes non-zero once a manager has declared a loss. Kestrel’s manager never declared one. They went straight to default, at which point the loss was realised,
LossUnrealized never moved off zero, and the book read clean again. This is why GET /api/vaults sorts by gradeNumeric ascending and not by divergence.
What Kestrel’s manager actually did
Reconstructed from three transactions on the public record viaGET /api/vaults/:vaultId/broker-history:
The 30 XRP loan was declared first, then the 10 XRP loan. Cover liquidated on a default is:
where is the broker’s total book, not the defaulting loan’s principal, and decrements after each default. At (both in units, so the effective coefficient is ), the two possible orderings give:
The manager’s own first-loss capital absorbed 0.50 XRP instead of 0.70 XRP. The 0.20 XRP difference did not disappear — it fell on the unit holders. The API reports this as
ordering.costToDepositors: "200000" with fairness: "0.0000", placing the sequence at the investor-worst end of the range.
Conduct score: 100, minus 35 for a sequence score below 0.25, minus 20 for each of two exposures written off with no prior impairment — giving 25 and a grade of E.
What Calder’s manager actually did
One loan, 10 XRP, went past due. The manager impaired it (transactionBD18EFB9…F52D5F4F), which moved LossUnrealized from 0 to 10000000 and took the honest unit value from 1.000000 down to 0.803922. No default has been declared. The ordering rule requires two defaults before it applies, no exposure was written off without warning, and no first-loss capital has been withdrawn — nothing deducts from the starting 100, and the conduct grade is A.
The vault itself is graded AA, not AAA. The notch trace explains why:
API calls
Conduct is reconstructed from
account_tx, which Devnet retains for roughly 29 days. The API returns that caveat in the response body rather than burying it in a footnote. Conduct before the retention window is not visible, and Orma does not claim that it is.Use Case 2: A Second Lender Pricing Pledged Shares
An LP holds units of Calder’s share token and wants to borrow against them from a different broker. The units are escrowed on-ledger: XLS-85TokenEscrow accepts MPT amounts, and vault shares are MPTs, so EscrowCreate with Amount: { mpt_issuance_id, value } returns tesSUCCESS. The pledge is then a public object. What it is worth is the open question.
The second broker starts from the only identifier they have — the issuance id — and runs the resolution loop. Every step is on the ledger, or on a URL the ledger itself names.
Token metadata resolution
http://localhost:8787/api/mpt/{mpt_issuance_id}/nav was written into MPTokenMetadata at VaultCreate. The broker substitutes the token’s own id and follows it.
The valuation
A pledge of 1,000,000 units, priced both ways. Values are integer strings in the vault’s asset base unit (drops for an XRP vault):Why a haircut does not save you
A haircut applies to the held value, never to the reported one: At on this pledge,maxLendable is 643138 drops. A lender applying the same 20% to the reported value lends 800000 drops against collateral genuinely worth 803922. They intended a 20% cushion. They have 3,922 drops of it — 0.49% of the true value. The haircut was consumed entirely by the misstatement before it absorbed a single tick of volatility.
API calls
Use Case 3: A Vault Owner Attracting Graded Capital
Being measured looks adversarial. It is not. The chain is short:1
Write the pointer
The share token carries a pointer to an honest valuation, written once at
VaultCreate into MPTokenMetadata.2
Any counterparty can price the units
No cooperation from the holder, the manager, or Orma is required.
3
Priceable units are usable as collateral
A unit that cannot be independently valued is refused by a careful lender. One that can be valued is accepted.
4
Collateral-eligible units are worth more to hold
The facility raises capital from lenders who know what they are buying.
5
Cite Orma's issuer in a PermissionedDomain
Name
rKQjjU5KFs9RAZCDvYVjcaoVK5gGsCJgkP in a PermissionedDomainSet. Orma signs nothing and cannot decline to be cited — the grade is Orma’s opinion, and the domain is the owner’s.MPTokenMetadata at VaultCreate. Five XLS-89 fields so explorers will list the token, then one namespaced block that does the work:
The grade is an asset, not a threat
Calder’s manager holds a conduct score of 100 / 100, grade A, earned by impairing a loan rather than sitting on it. That grade has three properties an honest manager wants:Not self-reported
It is rebuilt from transaction hashes anyone can fetch. A competitor cannot claim it, and the manager cannot be talked out of it.
Disclosure doesn't cost it
Realised capital destruction is measured against total assets, not net assets. Recognising a loss early cannot worsen your grade.
Passport to gated capital
A grade A manager can reach allocators whose domain names Orma’s issuer. A grade E manager cannot.
API call
Use Case 4: An LP Checking Entry to Thorne Senior Secured I
Thorne Senior Secured I (4A5A8E37…B00190DF5) is verified end to end on Devnet. The setup requires four transactions; the deposit check requires two.
Setup sequence
Resulting state from
GET /api/vaults/4A5A8E37.../gate:
Why this is a rating and not a private arrangement
Step 3 is signed by the vault owner alone. Orma signs nothing, is not consulted, and cannot decline to be cited.issuerNamed: true in the response above is Orma answering a question about itself that it was never asked. That asymmetry is the difference between a rating and a bilateral deal — and it is how incumbent rating agencies work: an issuer references a rating, and the agency gets no veto over being referenced.
Step 2 is the mirror asymmetry. Issuance alone grants nothing. Without CredentialAccept the deposit is still tecNO_AUTH, so a credential cannot be done to someone.
Credentials are keyed to the bar, not to the facility.
ORMA-IG means “may enter facilities graded BBB- or better” and is reusable across every vault that names Orma’s issuer. One credential per facility would be a whitelist wearing a credential’s clothes. CredentialType is a hex blob of 1 to 64 bytes; ORMA-IG serialises to 4F524D412D4947.Revocation is one-directional, on purpose
Steps 8 and 9 are the sharpest pair in the sequence. AfterCredentialDelete, the LP’s next deposit bounces immediately and their existing position is untouched — they withdraw in full, tesSUCCESS. The gate controls who may enter, never who may leave. The alternative is a rater who can trap capital, which nobody should accept and which Orma does not implement.