# Kinetic Alpha — Synthetic Access Monitor

## Dashboard blueprint for the CXMT pre-IPO perpetual case study

Version: 1.0  
Case snapshot: July 15, 2026  
Status: implementation outline; the embedded page preview is static and is not live market data.

## 1. Product objective

Build a reusable market-structure monitor for pre-IPO and restricted-equity perpetuals. The dashboard should answer one operating question:

> Where can the next forced price come from?

It should separate four things that are easy to confuse in a synthetic market:

1. The traded price.
2. The oracle/reference price.
3. The mark price used by the risk engine.
4. The cash or event anchor that may eventually force convergence.

This is a monitoring and research surface, not an execution interface. The first version should not route orders, hold credentials, or imply that displayed liquidation levels are guaranteed.

## 2. Core operator questions

- How far is the synthetic market from the best available cash or event anchor?
- Is that gap widening because of new information, thin liquidity, or leverage?
- Which side is paying funding, and how quickly is carry consuming collateral?
- How close is the mark to a concentration of estimated liquidation levels?
- Is the oracle behaving normally, stale, internally anchored, or transitioning to an external source?
- Which scheduled event can change the reference regime?

## 3. Recommended modules

| Module | Primary inputs | Derived measures | Best visual | Alert examples |
|---|---|---|---|---|
| Premium compression | Perp mid/mark, IPO reference, live cash price, FX | Access premium, cash basis, convergence velocity | Multi-line time series with event markers | Premium moves 2 standard deviations; convergence accelerates into a listing event |
| Funding and carry | Current and historical hourly funding, position direction | 24h/7d cumulative carry, annualized rate, payer state | Funding bars aligned beneath price | Funding changes sign; cumulative 24h carry exceeds a user threshold |
| Liquidation ladder | Public positions where observable, leverage assumptions, mark price | Estimated liquidation notional by price band, distance to nearest cluster | Horizontal ladder / depth profile | Mark enters a dense liquidation band; forced-flow estimate exceeds visible book depth |
| Oracle integrity | Oracle, mark, external price, update timestamps, discovery bounds | Mark/oracle basis, update latency, external staleness, bound proximity | State panel plus basis history | Updates stale; basis breaches threshold; discovery bound re-anchors; feed regime changes |
| Liquidity and flow | L2 book, trades, OI, volume, liquidation prints | Spread, depth within 25/50/100 bp, imbalance, OI-price divergence | Compact depth and flow panels | Depth collapses; OI rises while price falls; liquidation print exceeds percentile |
| Event clock | Subscription, pricing, listing, cash-market hours, oracle handoff | Time to event, session state, reference regime | Timeline with current state | Cash open approaches; oracle handoff confirmed; market enters unanchored session |
| Comparable value | CXMT implied value, Micron/SK Hynix/Samsung metrics, FX | Relative market cap and sales/earnings multiples where valid | Small multiples, never a single opaque score | Synthetic valuation crosses a selected peer or multiple range |

## 4. Data sources and contracts

### Hyperliquid / HIP-3

Use the official Hyperliquid information endpoint for the market context. The relevant response fields include:

- `markPx`
- `oraclePx`
- `midPx`
- `funding`
- `openInterest`
- `dayNtlVlm`
- `premium`
- `impactPxs`

Add L2 order-book snapshots, recent trades and public liquidation/fill events where available. Store the raw payload alongside normalized fields so methodology changes can be replayed.

### TradeXYZ contract metadata

Maintain a versioned instrument registry with:

- HIP-3 deployer and DEX name.
- Collateral and settlement currency.
- Maximum leverage and margin mode.
- Oracle updater address.
- Internal versus external pricing session.
- Discovery-bound percentage, level and remaining re-anchors.
- Scheduled transition rule and settlement/halt status.

### External/cash references

For CXMT after listing, use a licensed or otherwise permitted Shanghai STAR Market quote source plus a timestamped USD/CNY feed. Before listing, record the official IPO offer price as an event anchor, not as a live oracle.

Every displayed reference should carry:

- `source`
- `observed_at`
- `received_at`
- `currency`
- `session_state`
- `quality_flag`

## 5. Derived metrics

Use visible formulas in methodology tooltips and documentation.

```text
offer_usd = offer_rmb / usd_cny

access_premium_pct = (perp_mark / offer_usd - 1) × 100

mark_oracle_basis_bps = (mark_px / oracle_px - 1) × 10,000

cash_basis_bps = (perp_mark / cash_fx_adjusted - 1) × 10,000

annualized_funding_simple = hourly_funding × 24 × 365

cumulative_carry = Σ(position_notional_at_interval × hourly_funding)

convergence_velocity = change(access_premium_pct) / elapsed_hours

bound_proximity_pct = distance_from_reference / active_discovery_bound
```

Do not annualize funding without labeling it as a simple extrapolation. It is useful as a crowding indicator, not a forecast.

## 6. Liquidation-ladder methodology

A market-wide liquidation ladder is an estimate unless complete position data and margin state are available.

Recommended hierarchy:

1. Use public on-chain position and margin data when it is complete enough to compute liquidation prices.
2. Tag cross-margin positions separately because other account P&L and funding can move the actual liquidation point.
3. When account data is incomplete, infer scenarios from open interest split across leverage buckets; label the result `modelled`.
4. Aggregate into stable price bands rather than publishing false precision at individual ticks.
5. Compare estimated forced notional with visible executable depth to produce a cascade ratio.

```text
cascade_ratio = estimated_forced_notional_in_band / executable_book_depth_to_next_band
```

Show the underlying assumptions beside the ladder: leverage distribution, margin mode, observation time, and excluded positions.

## 7. Oracle-risk framework

Avoid a single unexplained “oracle health score.” Show the components first:

- Update latency.
- Consecutive missed updates.
- Mark/oracle basis.
- Oracle/external basis, when an external price exists.
- External price staleness.
- Discovery-bound level and proximity.
- Relayer or updater identity.
- Current regime: `internal`, `handoff`, `external`, `halted` or `settled`.

If a composite score is later required, publish its weights and keep the raw components visible.

Suggested default alerts, all configurable:

- Oracle age greater than 10 seconds.
- Absolute mark/oracle basis greater than 100 bp for three consecutive observations.
- Bound proximity greater than 85%.
- New discovery-bound re-anchor.
- Feed regime change.
- Post-handoff cash basis greater than 300 bp during cash-market hours.

## 8. Interaction model

- Default to the risk view; do not bury the mark/oracle relationship behind a tab.
- Align price, funding, OI and liquidation events on one time axis.
- Hover or keyboard focus on any timestamp should synchronize every panel.
- Let users pin an event window around subscription, pricing, listing or oracle handoff.
- Add scenario controls for leverage, mark shock and funding carry; keep scenario values visually distinct from observed data.
- Provide a methodology drawer with the exact source timestamp and formula for every metric.
- Export the current window as CSV and a citation-ready PNG only after live data is implemented.

## 9. Suggested technical shape

```mermaid
flowchart LR
  H[Hyperliquid API\nmark · oracle · funding · OI · book] --> I[Ingestion workers]
  T[TradeXYZ metadata\nregime · bounds · contract spec] --> I
  C[Cash / FX references\nSTAR quote · USD/CNY] --> I
  E[Event registry\nsubscription · listing · handoff] --> I
  I --> N[Normalizer + quality flags]
  N --> R[Raw event store]
  N --> M[Metric engine]
  M --> A[Alert engine]
  M --> Q[Time-series query API]
  A --> W[WebSocket / push stream]
  Q --> D[Dashboard]
  W --> D
```

For a proof of concept, 2–5 second polling and one-minute aggregates are sufficient. For production, keep raw ticks in a time-series or columnar store and use a separate cache/stream for the latest state. Do not make the browser the system of record.

## 10. Front-end component map

```text
SyntheticAccessMonitor
├── InstrumentHeader
│   ├── RegimeBadge
│   ├── SessionClock
│   └── SourceFreshness
├── MetricStrip
├── SynchronizedTimeSeries
│   ├── PriceAndReferenceChart
│   ├── FundingTrack
│   ├── OpenInterestTrack
│   └── EventMarkers
├── LiquidationLadder
├── OracleIntegrityPanel
├── LiquidityAndFlowPanel
├── ComparableValuePanel
├── EventClock
└── MethodologyDrawer
```

On narrow screens, preserve the metric strip, price/reference chart and oracle integrity panel first. Collapse secondary panels into a linear reading order; do not reduce them to unreadable miniatures.

## 11. Delivery phases

### Phase 1 — Observable market

- Instrument registry.
- Live mark, oracle, funding, OI, volume and book depth.
- Article/offer anchor and access-premium series.
- Event clock and source freshness.
- Historical storage and CSV export.

### Phase 2 — Risk engine

- Funding carry calculator.
- Mark/oracle anomaly alerts.
- Discovery-bound monitoring.
- Modelled liquidation ladder with published assumptions.
- OI/price/depth divergence views.

### Phase 3 — Cross-market system

- Licensed A-share and FX reference feeds.
- Automated internal-to-external oracle regime detection.
- SpaceX, Cerebras and future IPOP comparison library.
- Configurable alert delivery and shareable research snapshots.
- Backtesting for premium compression and cascade conditions.

## 12. Acceptance criteria

- Every metric displays a source and timestamp.
- Observed, derived and modelled values are visually distinct.
- The dashboard remains useful when the cash market is closed or does not yet exist.
- Feed staleness never silently presents as a current value.
- An oracle regime change is recorded as a first-class event.
- Keyboard users can inspect the same timestamp details as pointer users.
- Mobile layouts retain the mark/oracle relationship and source status.
- Historical replay reproduces any published chart from stored raw inputs.

## 13. Source references

- [crypto.news — Hyperliquid lists CXMT pre-IPO perpetual at 526% premium](https://crypto.news/hyperliquid-lists-cxmt-pre-ipo-perpetual-at-526-premium/)
- [TradeXYZ — Perpetual mechanics overview](https://docs.trade.xyz/perp-mechanics/overview)
- [Hyperliquid — HIP-3 builder-deployed perpetuals](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals)
- [Hyperliquid — Funding](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/funding)
- [Hyperliquid — Liquidations](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/liquidations)
- [Hyperliquid — Perpetuals information endpoint](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint/perpetuals)

This blueprint is for research and product design. It is not investment, trading or legal advice.