# Unified account risk engine — proposed specification v0.1

Status: design proposal, September 10, 2026. The shipped implementation is an isolated-margin paper exchange. This document is not a claim that cross-margin, GPU credit or UniFi settlement is deployed.

## Thesis and differentiation

One account should present balances, liabilities, reservations and restrictions together. It must not make every asset equally spendable. Separate trading and slow-recovery credit facilities can share an account identity without sharing losses automatically.

The proposed differentiator is a **risk decision that considers both recovery time and settlement certainty**, with a replayable explanation. UniFi is a candidate settlement adapter, not the risk engine. Unified accounts and portfolio margin already exist elsewhere; novelty and commercial advantage remain hypotheses to validate.

## Implementation boundary

| Capability | Current POC | Proposed extension |
| --- | --- | --- |
| Accounting | Server-authoritative, six-decimal BigInt paper ledger | Versioned multi-asset ledger and custody reconciliation |
| Trading | Synthetic BTC/ETH quotes; market, limit and conditional orders; isolated margin | Real execution venues, portfolio scenarios and supervised liquidation workers |
| Funding | Simulated deposits/withdrawals; order reserves constrain withdrawals | Verified deposits, withdrawal reservations and settlement reconciliation |
| Risk | Margin checks, stale-price gate, funding and liquidation simulations | Multiple independent oracles, recovery horizons, stress portfolios and concentration caps |
| GPU collateral | None; zero eligibility | Separate underwritten credit facility, subject to recovery and enforceability gates |
| UniFi | Not connected in this exchange | Verified cross-domain collateral adapter |

Current engine parameters: leverage 1–10; initial margin rate is the greater of 1/leverage and the notional tier (10%, 15% above $50k, 20% above $100k). Maintenance is half the tier rate. Additional entry buffers apply. Maker/taker fees are 1/4 basis points; the synthetic bid/ask spread is 4 basis points. Stale prices beyond 15 seconds block new exposure and liquidation. These are simulation settings, not calibrated production recommendations. Risk evaluation is request-driven; browser polling is not an always-running liquidator.

## State and decision contract

An account holds asset lots, liabilities, positions, orders and reservations. Each lot has an asset ID, quantity, custody location, settlement reference, eligibility class and encumbrance. Every decision consumes an immutable snapshot with ledger sequence, timestamp, oracle rounds, policy version and settlement observations.

A receipt contains action/request ID, pre-state hash, post-state hash, snapshot references, accepted/rejected result, binding limit, stress scenario, required/available margin and reason codes. Hashes support replay integrity; a hash alone is not proof of correct computation or collateral ownership.

Use fixed-point arithmetic, conservative rounding (assets down; liabilities and required margin up), bounded inputs and deterministic ordering. Commit ledger mutation, reservation, receipt and idempotency record atomically. Retry against a fresh snapshot on a compare-and-swap conflict. The same request ID and payload has one effect; a reused ID with different content is rejected.

## Collateral credit

For asset lot i and allowed recovery horizon H:

    recovery_i = max(0, conservative_exit_value_i(H) - recovery_cost_i - senior_claims_i)
    credit_i = eligibility_i * min(recovery_i * (1 - haircut_i), remaining_asset_cap_i)

Eligibility is zero unless custody, transfer rights, settlement state and valuation freshness satisfy policy. Haircuts cover risks not already embedded in exit value: avoid unintentionally counting the same stress twice. Apply aggregate issuer, custodian, geography, hardware model, maturity and correlated-factor limits after lot valuation. Cap consumption must be deterministic across lots.

Do not count a GPU and a receivable secured by the same GPU twice. Maintain an underlying-claim graph and encumbrance register. Ownership tokens and signed operator attestations cannot, by themselves, establish an unencumbered recoverable claim.

## Portfolio margin and actions

For the future trading facility, compute scenario equity from eligible collateral, marked positions and all liabilities. Let maintenance requirement be the largest modeled portfolio loss plus liquidation costs and concentration/liquidity add-ons, subject to a minimum floor. Initial requirement adds a buffer for execution, funding and price movement before the next safe liquidation opportunity. Explicitly define scenarios for spot shocks, volatility/basis shifts, correlation breakdown, liquidity disappearance and oracle/settlement outages.

Reserve the worst permitted exposure from executable pending orders. OCO offsets apply only when the execution system guarantees atomic exclusion. Recalculate on placement, fill, cancellation, funding, price update and collateral-state change. A reduce-only order must never reverse a position. Reject increasing exposure when inputs are stale; permit cancellations and safe reductions under explicitly defined degraded execution rules.

Withdrawals simulate the post-withdraw account and all existing reservations at a single snapshot. Reserve the amount before dispatch; do not release the reservation merely because a network request timed out. Resolve transaction status before retrying. Mark-to-market gains are not automatically withdrawable cash.

On maintenance breach: cancel exposure-increasing orders, reduce liquid positions according to a deterministic cost-aware schedule, reassess after each fill and escalate residual losses through a disclosed insurance/default waterfall. Production operation requires persistent workers independent of the user's browser. No assumption of guaranteed liquidation liquidity is permitted.

## GPU collateral facility

| Claim | Verification required | Recovery concern |
| --- | --- | --- |
| Physical hardware | Serial inventory, condition, custody/control, ownership and senior claims, independent resale bids | Seizure/access, transport, downtime, depreciation, resale depth |
| Prepaid compute credits | Provider acknowledgement, transferability, expiry, redemption rules | Credits may be nontransferable and expire; provider insolvency |
| Earned receivables | Delivered service evidence, debtor confirmation, assignment rights, dispute/dilution history | Debtor default, offsets, collection time and legal recovery |

Start with zero eligibility for all three. A future pilot needs independent underwriting, jurisdiction-specific legal review, a servicing/recovery operator and evidence of executable recovery—not just an NFT mint or a benchmark price.

Model utilization, power cost, hardware obsolescence, vendor/customer concentration and wrong-way risk between compute demand and crypto prices. Stress collection delays and recoveries of zero. Keep lending against slow assets in a separately capitalized facility with term, maturity and liquidity matched to recovery. Only settled loan proceeds may enter the trading facility; the hardware valuation itself is not instant perp margin. Track the borrowing liability and pledged claim in the unified account so the UI does not present debt proceeds as net wealth.

Hypothetical example: a displayed $40,000 equipment valuation with no verified custody or transfer rights contributes $0 trading collateral. Even after underwriting, a loan limit requires recovery evidence and approved parameters; this specification supplies no default loan-to-value for GPUs.

## UniFi integration hypothesis

UniFi's documentation describes gateway sequencing/preconfirmations and illustrative L1-to-L2 same-slot signaling. It explicitly distinguishes design from implementation. Test whether authenticated collateral lock signals can reduce time to useful credit compared with a conventional bridge while preserving the same risk guarantees.

Proposed flow: L1 collateral lock → authenticated message → observed/preconfirmed lot → validated settlement policy → eligible lot → reservation → execution. A preconfirmation is not L1 finality. Start with zero withdrawable credit for unsafe/preconfirmed deposits. Any later limited preconfirmation credit requires a separately funded loss budget, exposure ceiling and measurable reorg recovery policy.

Cross-domain identity must bind source/destination chain, contract, asset, amount, beneficiary, nonce, source block hash and expiry. Verify origin, proof and replay protection; a public RPC response alone is insufficient. Invalidation freezes dependent credit, cancels increasing orders and invokes recovery policy. Preserve the lineage of every reservation. Never release the L1 lock while an L2 loan, trade or withdrawal still consumes its credit.

Do not claim atomic cross-layer transactions from illustrative examples. Validate ordering, finality, failure handling and the deployed contracts on testnet. The faucet only funds gas; it does not supply a custody vault, exchange, oracle or GPU lending protocol.

## Services and controls

Build adapters for custody/settlement and price feeds around a deterministic risk core. Add an append-only event ledger, reconciler, liquidator, withdrawal dispatcher and decision-replay endpoint. Persist all financial state in a durable transactional backend; local files are development-only. Parameter changes are versioned, authorized, audited and tested against existing portfolios. Emergency controls can freeze new credit and withdrawals while preserving a documented recovery path; no silent balance edits.

The current POC uses local file storage or Redis CAS. It does not establish production matching fairness, independent custody, authenticated end-user identities or continuously supervised solvency.

## Acceptance gates

1. Property tests: conservation; no negative spendable balance; reservation release exactly once; no double pledge; deterministic replay; rounding boundaries; reduce-only cannot reverse exposure.
2. Concurrency: order/withdraw races, duplicate requests, CAS exhaustion, process failure between reservation and settlement, restart and replay.
3. Stress: correlated collateral and position crash, stale/manipulated oracle, evaporating liquidity, funding shock, insurance exhaustion and illiquid collateral with zero recovery.
4. Settlement: forged/replayed/out-of-order messages, expiry, reorg after preconfirmation, dropped callbacks, chain outage, failed withdrawal and locked collateral reconciliation.
5. GPU pilot: independently demonstrated inventory/claim verification and recovery; no eligibility before every required gate passes.
6. Benchmark UniFi and a conventional EVM/bridge baseline with identical collateral policies: median/p95 time to eligible credit, worst-case stranded capital, reorg loss, fees and recovery time. Publish measured outcomes; do not promise latency or capital-efficiency gains before testing.

## Source basis

- UniFi gateway design and preconfirmation boundaries: https://docs-unifi.puffer.fi/developers/concepts/gateway
- UniFi illustrative composability examples: https://docs-unifi.puffer.fi/developers/reference/L1-to-L2-composability-examples
- Existing portfolio-margin comparison: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/portfolio-margin
- Existing unified account modes: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/account-abstraction-modes
- Isolation precedent: https://aave.com/help/supplying/isolation-mode

These sources motivate architecture choices; they do not establish that this project's risk model is unique or production-ready.