Bond Asset Analysis Guide

How traders read bond_yield performance on TradeArena: what you're pricing, which endpoints to use, and how to interpret the numbers.

Core doctrine: trade the asset, not the subscriber

Every bond_yield order is one month of yield from one financed subscription (ARENA-BOND-{pool}-M{month}). But what you're pricing is the underlying asset's ability to produce yield across all its subscriptions:

• One pool == one subscription (own credit score, deposit, payment stream).
• One asset == every pool and month the same real asset backs — e.g. two guests in short-let ABJ-SL-003 list as two separate M1 chains, but the asset view shows the home's combined occupancy and collections.
• GPU allocations roll up by quote (split pools share one quoted asset).

A month is listed only after that subscription's upfront deposit is confirmed on-chain, so every open order you see is already deposit-backed.

Default view: asset rollup

GET /api/arena/bonds/assets — start here. Optional product_type filter (real_estate, gpu_cloud).

Field	Meaning
asset_key	The asset: home_ref for homes, quote_ref for GPU
pools	Payer mix — how many subscriptions back this asset
orders_listed / months_settled	Coverage of the order chain
occupancy	Settled ÷ listed — the single most important number
total_receivable / total_collected	Billed vs actually received
min_credit / max_default	Risk glance across payers

High occupancy + collected ≈ receivable + stable payer mix = healthy asset. Falling occupancy or a widening receivable/collected gap = price it accordingly.

Drill-down: one asset, every payer

GET /api/arena/bonds/assets/{asset_key} returns each pool's month grid (order, status, monthly yield, settlement) plus asset totals. Use it to check why an asset scores as it does — e.g. one defaulting guest among three paying ones, or a single strong payer carrying the whole allocation.

Pool-level detail (financing params, full ledger) stays on /api/arena/bonds/{bond_id} and /api/arena/bonds/{bond_id}/performance.

Reading the risk flag

Each order carries risk_flag in asset_details:

• within_be — contract rate at or under the model's break-even; no spread.
• above_be — contract exceeds break-even (+N bps in risk_factors); spread_add_bps widens accordingly. It still lists — the flag is information, not a block.

Per-type parameters are locked (GPU types and RENT / MORTGAGE / SHORT_LET share the same triple); spread_params_source tells you which row applied.

Flavour notes

• Real estate — subtypes RENT, MORTGAGE (tenure_months 12–120), SHORT_LET (airbnb, 12-mo). Monthly slices (principal / interest / insurance / life cover) plus underwriting refs are in asset_details. Mortgage slices decline over the amort life — compare like months, not first vs last.
• GPU cloud — gpu_type (RTX_PRO_6000, A100, L40S), flat hourly rate, SLA-backed availability. Month-1 is typically net-$0 (down-payment credit covers it); yield starts month 2.

Worked example: one home, two guests

1. GET /api/arena/bonds/assets?product_type=real_estate → find ABJ-SL-003: pools: 2, occupancy: 0.5, total_collected vs total_receivable.
2. GET /api/arena/bonds/assets/ABJ-SL-003 → guest A's 3 settled months vs guest B's open M1 — the asset is half-occupied with one proven payer.
3. Commit on B's M1 accordingly: proven asset, unproven payer — check min_credit and the pool detail before sizing.