> ## 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.

# Venue Accounts

> Controlled accounts at integrated trading venues whose authenticated state enters the Robinhood Chain Credit Account's global risk calculation.

A Venue Account is the Credit Account's controlled presence at an external execution venue. It can hold margin and positions under the venue's own account system while its authenticated net value and exposure enter the Mobius global Health Factor.

The venue remains responsible for trade execution and local margin. The Credit Account remains responsible for authorization, portfolio debt, and global solvency.

## Venue Account Model

The **Venue Account Model (VAM)** gives Robinhood Chain a common interface to venues with different APIs, account structures, settlement systems, and margin rules.

* **Venue Registry:** Maps each supported venue to its approved driver and risk configuration.
* **Venue Driver:** Translates the common Mobius interfaces into venue-specific operations.
* **Binder:** Creates or associates a venue account and records its relationship to the Credit Account.
* **Reader:** Normalizes venue balances, positions, PnL, margin, and other risk inputs.
* **Writer:** Submits authorized orders, deposits, withdrawals, cancellations, and closures.
* **TEE-backed Executor:** Runs the venue-specific workflow and reports results to Robinhood Chain.

Hyperliquid, Lighter on Robinhood, and Aster use the same Credit Account-facing model. Their drivers can differ without changing the lending or Health Factor interfaces.

## Binding

A binding establishes which venue account belongs to a Credit Account:

```text theme={null}
BIND_REQUESTED
      |
      v
Executor provisions or associates the venue account
      |
      +------------------+
      |                  |
      v                  v
   ACTIVE              FAILED
      |
      v
UNBOUND after positions and obligations are resolved
```

A binding alone does not authorize arbitrary venue activity. Every risk-impacting action still requires a permitted request from the Credit Account.

## Action Lifecycle

Venue activity follows an explicit asynchronous lifecycle:

```text theme={null}
Credit Account authorizes intent
              |
              v
           PENDING
              |
       TEE-backed Executor
       validates and submits
              |
     +--------+--------+
     |        |        |
     v        v        v
CONFIRMED   FAILED   EXPIRED
```

The request specifies the permitted action and its bounds. The Executor cannot replace it with a discretionary trade or withdrawal. Confirmation records the outcome; it does not allow the Executor to rewrite the original authorization.

Deadlines prevent requests from remaining pending indefinitely. A request that does not complete within its allowed window can expire without being counted as a successful portfolio transition.

## Authenticated Venue State

The Reader normalizes the venue information needed by the risk engine, including:

* cash and spot balances;
* open positions and their notional exposure;
* unrealized and realized PnL;
* margin requirements and withdrawable value;
* pending venue operations; and
* the observation time and freshness of the state.

This state produces a conservative risk-adjusted Venue Account value. Mobius does not assume that headline account equity is fully borrowable, nor that an intended trade has occurred before its result is confirmed.

If state becomes stale or unavailable, the venue contribution is reduced and risk-increasing activity is constrained. Degraded information cannot relax the account's limits.

## Liquidation Threshold

Venue Account equity is converted into risk-adjusted collateral through a single liquidation threshold, $LT_{VA}$. This threshold reflects both the volatility of the underlying positions and the leverage inside the Venue Account.

For Venue Account equity $E$:

$$
V_{VA}^{risk} = E \times LT_{VA}
$$

### Adjusting for Position Leverage

A 1x perpetual position begins with the same base liquidation threshold as its underlying asset. If asset $i$ has liquidation threshold $LT_i$, its maintenance margin is:

$$
M_i = 1 - LT_i
$$

For an $N$x leveraged position:

$$
M_{Ni} = N(1 - LT_i)
$$

The position's adjusted liquidation threshold is:

$$
LT_{Ni} = 1 - N(1 - LT_i)
$$

For example, a 3x BTC long with a base $LT_{BTC}=0.8$ has an adjusted threshold of:

$$
LT_{3BTC} = 1 - 3(1 - 0.8) = 0.4
$$

### Aggregating the Venue Portfolio

For a Venue Account with several positions, Mobius first calculates a notional-weighted threshold and the account's cross leverage:

$$
LT_{weighted}
=
\sum_{i=1}^{n}
\frac{S_i \times LT_i}{\sum_{i=1}^{n} S_i}
$$

$$
L_{cross}
=
\frac{\sum_{i=1}^{n} S_i}{E}
$$

$S_i$ is the notional size of position $i$, and $E$ is the Venue Account's authenticated equity.

The resulting Venue Account liquidation threshold is:

$$
LT_{VA}
=
1 - L_{cross}(1 - LT_{weighted})
$$

Consider a Venue Account with $1{,}000$ USDC of equity, a $1{,}000$ BTC long with $LT=0.8$, and a $2{,}000$ ETH long with $LT=0.7$:

$$
LT_{weighted}
=
\frac{0.8 \times 1{,}000 + 0.7 \times 2{,}000}{3{,}000}
=
0.733
$$

$$
L_{cross} = \frac{3{,}000}{1{,}000} = 3
$$

Therefore:

$$
LT_{VA} = 1 - 3(1 - 0.733) = 0.2
$$

The Venue Account contributes approximately $200$ of risk-adjusted collateral value to the Credit Account.

## E-Mode (Efficiency Mode)

The standard $LT_{VA}$ calculation treats venue exposure on a gross basis. E-Mode applies a higher strategy-specific threshold when an approved, tightly constrained relationship reduces the portfolio's market risk.

Selecting an E-Mode category restricts the eligible assets, venues, position relationships, hedge ratios, and leverage. Actions that would move the portfolio outside those constraints are blocked. If a constraint fails or required venue state becomes stale, the account loses the E-Mode treatment.

### Example: Leveraged RWA Carry

Consider a strategy with:

* 10 Stock Tokens worth \$30 each;
* an equal short perpetual with \$300 notional; and
* a base liquidation threshold of $LT=0.5$.

Under the standard calculation, gross exposure can drive $LT_{VA}$ toward zero even though the long and short offset directionally.

Under the approved RWA carry E-Mode, the risk engine recognizes the enforced hedge and can apply a higher threshold, such as:

$$
LT_{VA} \rightarrow 0.9
$$

The higher threshold supports a larger one-step debt increase while the account remains inside the strategy's guardrails.

The same mechanism can recognize equal and opposite positions in a leveraged funding-arbitrage category. Both venue legs must remain within their approved assets, notionals, funding instruments, and freshness bounds; positions do not receive unrestricted netting outside that category.

## Local Venue Risk

Every Venue Account remains subject to its venue's own maintenance-margin rules. A venue sees only the capital and positions held in its local account; it does not rely on collateral that remains on Robinhood Chain or at another venue.

As a result, a locally under-margined Venue Account can be liquidated even while the Mobius portfolio remains globally healthy. The resulting change in venue equity then feeds into the global Health Factor.
