> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mob.exchange/llms.txt
> Use this file to discover all available pages before exploring further.

# Credit Account

> The Robinhood Chain smart account that holds portfolio assets, debt, permissions, and the canonical global Health Factor.

A Credit Account is the portfolio and authority boundary of Mobius. It holds approved onchain assets, borrows from a lending pool, authorizes activity at integrated venues, and remains subject to one global risk calculation.

## What the Account Holds

The Credit Account directly holds assets that exist on Robinhood Chain, including supported Robinhood Stock Tokens. It also records:

* principal and accrued borrowing interest;
* permissions for approved assets, adapters, venues, and strategies;
* active Venue Account bindings;
* pending and completed venue requests; and
* the state required to calculate the global Health Factor.

External positions are not represented as if their assets were held by the onchain wallet. They enter the portfolio through authenticated Venue Account state.

## Controlled Interactions

The account reaches other systems through two controlled interfaces:

* **Adapters** translate calls to approved onchain protocols into Credit Account operations.
* The **Venue Account Model** translates authorized intents into venue-specific binding, trading, margin, and withdrawal operations.

Neither interface grants open-ended control. The market defines which contracts, assets, venues, and actions are permitted. A TEE-backed Executor can process a venue intent only after the Credit Account has authorized it.

## Permitted Portfolio

Every Credit Account belongs to a market with a defined asset and venue universe. Assets outside that universe cannot contribute collateral value, and unsupported venue state cannot enter the Health Factor.

A strategy category can further narrow the permitted portfolio. A leveraged RWA carry strategy may constrain the account to a specified Stock Token, corresponding hedge instruments, approved venues, and bounded hedge ratios. Those restrictions are what allow the risk engine to recognize the hedge.

## Global Health Factor

At time $t$, define:

* $Q_i(t)$: quantity of supported onchain asset $i$;
* $P_i(t)$: price of asset $i$;
* $LT_i$: its standard liquidation threshold;
* $V_j^{risk}(t)$: the conservative risk-adjusted net value of Venue Account $j$;
* $d(t)$: outstanding principal debt; and
* $b(t)$: accrued borrowing interest.

Risk-adjusted collateral value is:

$$
C(t) =
\sum_{i=1}^{n} Q_i(t)P_i(t)LT_i
+
\sum_{j=1}^{m} V_j^{risk}(t)
$$

The global Health Factor is:

$$
HF(t) = \frac{C(t)}{d(t) + b(t)}
$$

An account is liquidatable when $HF < 1$.

$V_j^{risk}$ is not the venue's headline equity copied onchain. It reflects authenticated balances, PnL, liabilities, exposure, state freshness, and the market's venue parameters. Missing or stale state reduces the value available to support debt.

## Strategy-Scoped Risk Treatment

The standard Health Factor values positions conservatively without assuming that separate exposures offset. An approved strategy can apply different treatment to a precisely defined portfolio relationship.

For example, a Stock Token long and a corresponding perpetual short may receive hedge recognition only while:

* both instruments remain eligible for the strategy;
* their venues and price inputs remain approved;
* the hedge ratio stays within its allowed band;
* position and leverage limits are respected; and
* all required venue state remains fresh.

If a constraint fails, the account loses the strategy-specific treatment. The risk engine does not extend the same benefit to arbitrary positions that merely appear correlated.

## Borrow Once, Then Deploy

A Credit Account establishes leverage with a single debt increase. It borrows the full amount permitted by its collateral and strategy constraints, then deploys the resulting account balance across the intended onchain assets and Venue Accounts.

Onchain steps can be combined in a multicall and validated against the resulting account state. External venue actions remain asynchronous. While those actions are pending, the risk engine uses conservative treatment rather than assuming the intended final position already exists.

## Operation Checks

Every operation must preserve the account's invariants:

* onchain multicalls revert if their final state is not permitted;
* venue actions must match an authorized pending request;
* failed or expired requests are not treated as completed positions; and
* risk-increasing actions are blocked when the account is unhealthy, stale, or being unwound.