Outcome Risk Object
The versioned object CUSP Risk publishes to make every supported position legible to anyone.
The Outcome Risk Object is one published, versioned object that says everything an underwriter needs to know about a position. It is the published output of CUSP Risk. A vault, a liquidator, an outside lender, or a builder can read that single object and act on it, without rebuilding the valuation or guessing at the terms.
What it carries
Four groups of fields.
- Identity: what the position is, which market and outcome it references, its payoff structure, which venue it settles against, and the resolution source.
- Verdict: the eligibility decision from the risk engine, and the reason for it.
- Valuation: the conservative mark, the executable value for the position's size, and the stressed collateral value the engine will defend.
- Limits: maximum safe borrowing capacity, market and category exposure caps, and the supported liquidation route in force.
Each object carries its parameter version, and every value it has ever carried is kept in the historical calibration record. Executable value quoted at multiple position sizes is planned; today the object carries the depth-walked value for the position's full size.
Who reads it, and for what
A vault reads it to decide what to finance. A liquidator reads it to price a lot. An outside lender reads it to underwrite without rebuilding any of the valuation. A builder reads it to display or integrate a position from a single source of truth. The point of one standard is that none of them has to agree on anything beyond the object. It is the common risk language that lenders, curators, vaults, exchanges, and external applications share.
How to integrate against it
Three fields are enough to act safely: read the verdict, read the stress value, read the limits. Reject any object that is stale, and inherit the engine's gates by reference rather than reimplementing them. Field-level documentation will be published separately.
Why anyone should believe it
Every value the object carries is checked against the outcome that actually happened, and the protocol keeps the full history. So the object is not asking to be trusted; it is offering a record to verify. That history is the whole reason an outside party can build on the standard at all. See transparency.