# Overview
Source: https://docs.mob.exchange/overview
Mobius is the RWA Prime Terminal on Robinhood Chain, combining portfolio credit, onchain collateral, and cross-venue execution in one account.
Mobius is the **RWA Prime Terminal on Robinhood Chain**. It combines pooled lending, onchain collateral, and positions at external trading venues in a single credit account.
Robinhood Stock Tokens are the canonical collateral for this architecture, but the system is not limited to RWAs. Any asset or venue admitted by a Mobius market fits the same portfolio, authorization, and risk model.
## Why Mobius Exists
Tokenized assets, lending markets, and trading venues operate as separate margin systems. A stock token held on Robinhood Chain cannot ordinarily support a position on Hyperliquid or Aster. A hedge on Lighter cannot reduce the collateral required by another venue. Each system sees only its own account.
This fragments one economic portfolio into several isolated balance sheets. Capital is posted repeatedly, hedges go unrecognized, and borrowing power cannot follow the portfolio to the venue where it is needed.
Mobius provides a common credit and risk layer across those systems. Venues continue to execute trades and enforce their own local margin rules; Mobius finances and evaluates the combined portfolio.
## Architecture
* **Lending pools** on Robinhood Chain supply debt capital and accrue interest from credit-account borrowing.
* A **Credit Account** holds onchain assets, debt, permissions, and the portfolio's canonical risk state.
* **Onchain collateral**, including Robinhood Stock Tokens, is held directly by the Credit Account and valued by the onchain risk engine.
* **Venue Accounts** represent the Credit Account at integrated execution venues such as Hyperliquid, Lighter on Robinhood, and Aster.
* The **Venue Account Model** gives each venue the same binding, state, and action interfaces while keeping venue-specific mechanics behind a driver.
* **TEE-backed Executors** process actions authorized by the Credit Account and relay authenticated venue state. They cannot originate discretionary trades or withdrawals.
The Credit Account remains the source of authority throughout. External venues receive only the capital and permissions required for authorized activity, while Robinhood Chain remains the canonical layer for debt and portfolio risk.
## One Portfolio
The risk engine calculates one global Health Factor from:
* risk-adjusted assets held directly by the Credit Account;
* risk-adjusted equity reported by its Venue Accounts; and
* principal and accrued interest owed to its lending pool.
Venue equity does not receive unconditional collateral credit. Its contribution depends on the venue state being authenticated, sufficiently fresh, and permitted by the account's risk configuration.
Hedge and correlation benefits are also **strategy-scoped**. An approved strategy may recognize a defined relationship between a Stock Token and its corresponding perpetual hedge, for example, while enforcing limits on assets, venues, hedge ratios, and deviations. Positions outside those constraints receive the market's standard conservative treatment.
## What the Terminal Enables
* **Leveraged RWA carry:** Finance a hedged Stock Token position and earn the strategy's carry over borrowing costs.
* **Leveraged funding arbitrage:** Finance equal and opposite positions at venues with different funding rates.
* **Portfolio credit:** Borrow against the combined value of approved onchain assets and authenticated venue equity.
* **Cross-venue execution:** Access integrated venues through one authorization and risk system instead of funding each account as an isolated portfolio.
Mobius does not make every position interchangeable or every hedge creditworthy. It provides credit that reflects an approved portfolio's economic structure while preserving explicit asset, venue, strategy, and solvency constraints.
# Credit Account
Source: https://docs.mob.exchange/protocol/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.
# TEE Executors
Source: https://docs.mob.exchange/protocol/executors-and-rebalancers
Hardware-isolated services that process Credit Account-authorized venue actions and relay authenticated venue state.
TEE-backed Executors connect the Robinhood Chain control plane to integrated execution venues. They translate authorized intents into venue-specific operations and return the results and state needed by the onchain risk engine.
Executors are an execution boundary, not a second source of portfolio authority. The Credit Account determines what may happen; the venue determines how the action executes locally; the Executor connects the two.
## Responsibilities
Executors perform five protocol functions:
1. **Bind accounts:** Provision or associate a Venue Account and finalize its relationship to the Credit Account.
2. **Process actions:** Submit authorized orders, cancellations, deposits, withdrawals, and position closures.
3. **Observe results:** Determine whether the requested venue operation succeeded, failed, or exceeded its deadline.
4. **Relay state:** Normalize venue balances, positions, PnL, margin, and freshness inputs for the Robinhood Chain risk engine.
5. **Coordinate unwinds:** Close or reduce venue exposure when the Credit Account enters a risk-driven unwind.
Drivers isolate venue-specific APIs and signing rules. The rest of Mobius consumes the same binding, action, state, and request-status model for every venue.
## Authority Boundary
An Executor may process only an intent already authorized through the Credit Account. The authorization specifies the action and its permitted bounds.
An Executor cannot:
* originate a discretionary trade;
* withdraw assets without an authorized request;
* add an unsupported venue or asset;
* change the Credit Account's debt or risk configuration; or
* treat an unconfirmed venue outcome as completed onchain state.
Sensitive venue credentials and signing operations remain inside hardware-isolated execution. This reduces exposure of the keys needed to operate Venue Accounts without granting those keys broader portfolio authority.
## Request Processing
```text theme={null}
Onchain authorization
|
v
PENDING
|
Executor validates request and current account state
|
Executor submits the bounded venue operation
|
Executor observes the resulting venue state
|
+-----+-----+
| | |
v v v
CONFIRMED FAILED EXPIRED
```
Each request has a stable identifier and deadline. Stable identifiers make retries idempotent: an interrupted process can resume without intentionally submitting the economic action twice.
## Fail-Closed Behavior
Executor or venue failures restrict the portfolio instead of creating additional borrowing power:
* stale venue state receives reduced risk value;
* pending actions remain pending until their outcomes are established;
* failed and expired actions are not credited as successful transitions;
* risk-increasing requests are rejected while an account is being unwound; and
* unsupported or malformed state is rejected rather than interpreted through a fallback.
The onchain authorization and request records remain the canonical history even when a venue or Executor is unavailable.
## Execution Topology
The protocol's safety model depends on hardware-isolated execution, bounded authority, authenticated results, explicit request states, and fail-closed risk treatment. It does not depend on the documentation prescribing how many Executor operators exist or how they coordinate.
That separation allows the execution topology to evolve without changing the Credit Account's authority or the risk engine's invariants.
# How Mobius Works
Source: https://docs.mob.exchange/protocol/how-it-works
The end-to-end architecture connecting Robinhood Chain lending pools, Credit Accounts, Venue Accounts, TEE-backed Executors, and integrated trading venues.
Mobius separates portfolio authority and risk from venue execution. Robinhood Chain hosts the lending pools, Credit Accounts, and canonical risk engine. Integrated venues execute trades, while TEE-backed Executors carry authorized actions and authenticated state between the two.
## Participants
* **Lenders** supply assets to Mobius lending pools and earn interest from Credit Account debt.
* **Account owners and strategists** deposit collateral, borrow, and compose approved positions across onchain protocols and integrated venues.
* **TEE-backed Executors** bind Venue Accounts, process authorized venue actions, and relay their results and state.
* **Liquidators** repay unhealthy Credit Account debt and receive collateral according to the market's liquidation rules.
## Portfolio Lifecycle
1. **Supply liquidity.** Lenders deposit assets into a lending pool on Robinhood Chain.
2. **Open a Credit Account.** An account owner deposits approved collateral, such as Robinhood Stock Tokens.
3. **Increase debt.** The Credit Account borrows from its associated pool within the market's risk limits.
4. **Bind Venue Accounts.** The account establishes controlled connections to venues through the Venue Account Model.
5. **Authorize actions.** Venue orders, deposits, withdrawals, and closures begin as intents authorized by the Credit Account.
6. **Execute and confirm.** A TEE-backed Executor performs the permitted action and reports its outcome.
7. **Update portfolio risk.** The onchain risk engine combines direct holdings, authenticated Venue Account equity, and debt into one global Health Factor.
8. **Protect solvency.** Risk-increasing actions are blocked when constraints are breached. If the account becomes unhealthy, venue exposure is unwound and the Credit Account can be liquidated.
## Architecture
```mermaid theme={null}
flowchart TB
LP["Lenders"] --> Pool["Lending Pool"]
RWA["Robinhood Stock Tokens
and other onchain assets"] --> CA
subgraph RH["Robinhood Chain"]
Pool -->|Debt capital| CA["Credit Account
Assets · Debt · Permissions"]
CA --> Risk["Onchain Risk Engine
Global Health Factor"]
end
CA -->|Authorized intents| Exec["TEE-backed Executors"]
Exec -->|Venue operations| Venues["Hyperliquid · Lighter on Robinhood · Aster"]
Venues -->|Results and state| Exec
Exec -->|Authenticated venue state| Risk
```
The arrows between Executors and venues represent venue-specific execution and state retrieval. They do not change the authority boundary: the Credit Account originates permissions, and the onchain risk engine determines whether the portfolio can support its debt.
## Execution Is Asynchronous
Onchain operations can execute atomically within a Credit Account multicall. An action at an external venue cannot be part of that same transaction. It follows an explicit request lifecycle:
```text theme={null}
AUTHORIZED -> PENDING -> CONFIRMED
-> FAILED
-> EXPIRED
```
Pending activity is not treated as a successful trade. Until the result and resulting venue state are authenticated, the risk engine uses conservative accounting so an incomplete action cannot create unsupported borrowing power.
## Example Portfolio
Consider a Credit Account that holds a Robinhood Stock Token and borrows stablecoins from a Mobius pool. The account uses part of its capital as margin for a corresponding short perpetual at an integrated venue.
The Stock Token remains direct onchain collateral. The short and its margin appear as authenticated Venue Account state. Under an approved RWA carry strategy, the risk engine can recognize the constrained hedge when calculating the global Health Factor. Both legs remain subject to their own pricing, freshness, hedge-ratio, and venue-margin requirements.
The result is one financed portfolio even though its assets and positions settle in different systems.
# Lending
Source: https://docs.mob.exchange/protocol/lending
Pooled lending on Robinhood Chain supplies the debt capital used by Mobius Credit Accounts.
Mobius lending pools provide a common source of credit for portfolios that span onchain assets and integrated trading venues. Pools live on Robinhood Chain and lend to Credit Accounts, not directly to individual venues.
## Pool Model
Each pool:
* accepts a defined set of assets from lenders;
* issues pool shares representing each lender's claim;
* lends only through the Mobius credit system;
* accrues interest as debt remains outstanding; and
* supports withdrawals when sufficient pool liquidity is available.
Lenders receive interest paid by Credit Accounts. They do not need to choose which external venue receives a particular account's execution flow: the Credit Account and its global risk controls stand between the pool and every venue.
## Non-Rehypothecation
Collateral posted to a Credit Account is not supplied to another borrower. It remains within the account's controlled portfolio: held directly on Robinhood Chain or allocated through an authorized Venue Account.
This separates the two sides of the lending market:
* lender deposits supply debt capital; and
* borrower collateral secures that debt but is not added to the lendable pool.
The distinction keeps collateral attributable to its Credit Account and available to the portfolio's unwind and liquidation process.
## Markets
A Mobius market defines the assets accepted by its lending pools, the collateral permitted in its Credit Accounts, and the risk parameters connecting the two. Its parameters include:
* the asset set accepted by each lending pool;
* permitted Credit Account collateral;
* integrated venues and recognized venue assets;
* price and state inputs;
* collateral and liquidation thresholds; and
* strategy categories eligible for specialized risk treatment.
Robinhood Stock Tokens are a canonical form of onchain RWA collateral. Their admission, valuation, and borrowing power remain specific to the market that supports them.
## Credit and Portfolio Risk
A pool extends credit to the Credit Account as a whole. The account's ability to borrow depends on one global Health Factor that includes direct onchain assets, authenticated Venue Account equity, and all outstanding pool debt.
Venue equity receives conservative collateral treatment. Stale, unavailable, or unrecognized venue state cannot increase an account's borrowing power. Likewise, a hedge improves risk treatment only when it remains inside the constraints of an approved strategy.
These rules allow one lending relationship to finance several execution venues without turning venue-reported balances into unconditional collateral.
## Interest Rate Model
Borrowing rates respond to utilization for each asset in the pool. For asset $a$:
$$
Utilization_a = \frac{Outstanding\ Debt_a}{Supplied\ Liquidity_a}
$$
* At **low utilization**, the asset's rate remains lower to encourage borrowing.
* As utilization rises, its rate increases to attract liquidity and encourage repayment.
* Above the **kink**, the curve steepens to protect that asset's withdrawal liquidity.
Interest accrues to the account's debt and therefore enters the denominator of its global Health Factor.
# Liquidation
Source: https://docs.mob.exchange/protocol/liquidation
Venue-native and global liquidation protect a Mobius portfolio across Robinhood Chain and integrated trading venues.
Mobius portfolios span systems with separate solvency boundaries. Each venue protects its local account, while the Robinhood Chain risk engine protects the Credit Account and its lending-pool debt.
## Venue-Native Liquidation
A Venue Account must satisfy the execution venue's own maintenance-margin requirements. The venue does not rely on Stock Tokens held by the Credit Account or profits held at another venue.
If the Venue Account breaches its local requirement, the venue can close or liquidate its positions directly. That action changes the account's realized PnL and remaining equity. The updated venue state then enters the Mobius global Health Factor.
A local liquidation does not automatically close the Credit Account, but the resulting loss can make the global portfolio unhealthy.
## Global Liquidation
The Credit Account is globally liquidatable when:
$$
HF = \frac{Risk\text{-}Adjusted\ Portfolio\ Value}{Principal + Accrued\ Interest} < 1
$$
The global calculation includes direct Robinhood Chain collateral and conservative, authenticated Venue Account values.
Global liquidation proceeds through four stages:
1. **Restrict activity.** New risk-increasing actions are blocked, and pending requests cannot be used to create additional borrowing capacity.
2. **Unwind venue exposure.** Authorized closure actions reduce open positions and prevent the account from taking new venue risk during the unwind.
3. **Recover value.** Assets made withdrawable by the venue closures return through the Venue Account workflow and re-enter the onchain portfolio.
4. **Repay debt.** A liquidator repays the outstanding pool debt and receives the account's collateral according to the market's liquidation parameters.
Venue actions settle asynchronously, so the account remains restricted while the unwind is incomplete. Stable request identifiers, explicit statuses, and current venue state prevent a delayed confirmation from being mistaken for a new action.
## Liquidation Incentives
Liquidators receive collateral at a discount defined by the liquidation bonus:
$$
Liquidator\ Cost = Collateral\ Received \times (1 - Liquidation\ Bonus)
$$
The market calibrates the bonus alongside liquidation thresholds, execution costs, and the time required to resolve venue exposure. The incentive must be large enough to attract repayment without extracting unnecessary value from healthy accounts.
## Fail-Closed Safeguards
* **Freshness requirements:** Stale or unavailable venue state cannot preserve enhanced borrowing power.
* **Strategy enforcement:** A portfolio outside its strategy constraints loses strategy-specific risk treatment.
* **Operation checks:** Unhealthy accounts cannot authorize new risk-increasing activity.
* **Unwind guard:** New venue actions are rejected while positions are being closed.
* **Non-rehypothecation:** Direct collateral remains attributable to its Credit Account throughout liquidation.
These controls do not prevent every venue-local liquidation. They ensure that uncertainty, incomplete execution, or stale information cannot make the global portfolio appear safer than it is.
# Venue Accounts
Source: https://docs.mob.exchange/protocol/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.
# Leveraged Funding Arbitrage
Source: https://docs.mob.exchange/strategies/leveraged-funding-arbitrage
A cross-venue strategy that finances equal and opposite perpetual positions to capture a funding-rate difference.
Leveraged funding arbitrage captures the difference between funding rates for the same perpetual exposure at two venues. The strategy shorts where short funding is higher and takes an equal long where funding is lower.
## Economic Flow
1. The account owner deposits collateral into one Credit Account on Robinhood Chain.
2. The Credit Account increases debt once to the amount permitted by the strategy.
3. The account allocates its capital as margin across two integrated venues.
4. TEE-backed Executors open equal-notional long and short positions on the same underlying exposure.
5. The Robinhood Chain risk engine evaluates both legs under one strategy-scoped Health Factor.
The opposing positions offset directional price movement. The remaining economic exposure is primarily the difference between their funding payments.
## Economics
For equal position notionals:
$$
Gross\ Funding\ Income =
Position\ Notional
\times
(Short\ Funding\ Rate - Long\ Funding\ Cost)
$$
The strategy's net result deducts Credit Account borrowing interest and execution costs from that funding income.
## Example
Consider an account with **\$10,000 of starting equity**. It draws its permitted debt once and deploys margin for:
* a **\$50,000 ETH short** on Hyperliquid receiving 15% annualized funding; and
* a **\$50,000 ETH long** on Aster paying 5% annualized funding.
The illustrative annualized gross funding income is:
$$
\$50{,}000 \times (15\% - 5\%) = \$5{,}000
$$
Borrowing interest and execution costs are deducted from the \$5,000 gross amount. The example demonstrates the capital and cash-flow structure rather than a return forecast.
# Leveraged RWA Carry Trade
Source: https://docs.mob.exchange/strategies/leveraged-rwa-carry-trade
A hedged Stock Token position financed through one Mobius Credit Account.
A leveraged RWA carry trade pairs a Robinhood Stock Token with an equal-notional short perpetual. The long preserves the RWA exposure while the short offsets its directional price movement and generates funding income when shorts receive funding.
## Economic Flow
1. The account owner deposits an approved Stock Token into a Credit Account on Robinhood Chain.
2. The Credit Account increases debt once to the full amount permitted by the strategy and its collateral.
3. The account deploys its capital across additional Stock Token exposure and the venue margin required for the hedge.
4. A TEE-backed Executor opens a short perpetual equal to the strategy's total RWA exposure.
5. The Robinhood Chain risk engine evaluates the long and short as one constrained portfolio.
The target leverage is constructed from one borrowing decision followed by deployment of the complete account balance.
## Economics
The position is designed to keep the long and short notionals aligned:
$$
RWA\ Long\ Notional \approx Perpetual\ Short\ Notional
$$
Price gains on one leg are therefore offset by losses on the other. The principal economic return is:
$$
Net\ Carry =
Funding\ Income
+ Asset\ Carry
- Borrowing\ Cost
- Execution\ Costs
$$
Asset carry applies only where the Stock Token or its underlying economic structure provides it.
## Example
Consider an account with **\$10,000 of starting equity**. It draws its permitted debt once and deploys the resulting balance to construct:
* **\$50,000** of Stock Token exposure; and
* a **\$50,000** short perpetual on the same equity exposure.
If the short receives 11% annualized funding and borrowed capital costs 8%, the simplified 5x carry calculation is:
$$
5 \times 11\% - 4 \times 8\% = 23\%
$$
The figures illustrate the economic flow. The account's actual allocation depends on venue margin requirements, and realized carry depends on funding, borrowing, and execution costs.
# Fund & Move
Source: https://docs.mob.exchange/user-guide/fund-and-move
Deposit into Lighter RH or Hyperliquid, withdraw to your wallet, and bridge funds to another chain.
**Fund & Move** routes capital between your wallet and a venue account. Lighter RH receives USDG on Robinhood Chain. Hyperliquid receives USDC in its HyperCore trading account.
Funding one venue does not fund the other.
## Deposit into a venue
1. Open **Fund & Move**.
2. Choose **Lighter RH** or **Hyperliquid** on the **To** side.
3. On the **From** side, select the chain and token you want to pay with.
4. Enter the amount you want the venue account to receive.
5. Review the required input, route, fees, and estimated time.
6. Confirm the wallet prompts and wait for the venue balance to update.
Mobius uses Relay to complete the swap and bridge when the source asset is not already on the venue's settlement chain. The quote includes the route's fees. Available origins, minimums, and estimated times come from the live quote.
Keep the page open while the transfer is running. A confirmed source-chain transaction does not mean the destination venue has credited the account yet.
### Lighter RH
A first USDG deposit opens the Lighter RH account associated with your wallet. Once the deposit settles, return to **Trade**, select Lighter RH under **Execute on**, and activate trading.
### Hyperliquid
Hyperliquid perpetuals trade from the perpetual balance. If your wallet already has USDC in its Hyperliquid spot balance, Mobius may offer **Move to perps** instead of asking for another deposit.
## Withdraw from a venue
1. Select Lighter RH or Hyperliquid on the **From** side.
2. Enter the amount to withdraw.
3. Choose the destination chain and asset.
4. Confirm the venue withdrawal.
5. If you selected another chain, complete the Relay bridge after the funds reach your wallet.
### Withdrawal and bridging are separate
Venue withdrawals always return to the owner wallet first:
* Lighter RH returns USDG to your wallet on Robinhood Chain.
* Hyperliquid returns USDC to your wallet on Arbitrum.
If you choose a different destination chain, Mobius then starts a second transaction through Relay. This separation keeps the funds recoverable: if the bridge is interrupted, they remain in your wallet on Robinhood Chain or Arbitrum.
Before trading or withdrawing again, confirm the resulting balance at the destination.
# Getting started
Source: https://docs.mob.exchange/user-guide/getting-started
Connect a wallet, fund a venue account, activate trading, and place your first trade through Mobius.
Mobius brings markets from multiple trading venues into one interface. You connect one wallet, choose where to trade, and monitor the resulting accounts and positions together.
Venue accounts remain independent. Capital held at one venue does not create buying power at another, and each venue applies its own margin and liquidation rules.
## Quick start
1. Open [app.mob.exchange](https://app.mob.exchange/) and connect an EVM wallet.
2. Use **Fund & Move** to fund Lighter RH or Hyperliquid.
3. Select the venue under **Execute on** and activate trading.
4. Choose a market, prepare the order, and submit it.
5. Follow the result under **Positions**, **Open orders**, or **History**.
## Trading venues
Mobius currently routes orders to:
* **Lighter RH**, which uses USDG on Robinhood Chain and supports the spot and perpetual markets shown in its market directory.
* **Hyperliquid**, which uses USDC on HyperCore and supports the perpetual markets available in the terminal.
The application is the source of truth for current markets and execution availability. A market appearing in the market directory does not necessarily mean every venue can execute it.
## Fund, then activate
Funding and activation are separate steps:
* **Funding** transfers capital into a venue account.
* **Activation** authorizes a trading key for the current device.
After funding a venue, select it under **Execute on**. If the account is not active, the order ticket shows **Activate trading**. Confirm the request in your wallet and wait for Mobius to load the venue balance and buying power.
The trading key can place orders but cannot withdraw funds. Withdrawals can only return to the connected owner wallet. You may need to activate again when using another browser or device.
## Where to find things
* **Trade** contains the market selector, execution-venue selector, chart, order book, order ticket, and trading activity.
* **Fund & Move** handles deposits, withdrawals, and cross-chain transfers.
* **Portfolio** combines balances and positions from your live venue accounts.
* **Strategy** contains the cross-venue funding-arbitrage workflow.
Continue with [Fund & Move](/user-guide/fund-and-move) to add capital, or go to [Trading](/user-guide/trading) if your venue accounts are already active.
# Portfolio
Source: https://docs.mob.exchange/user-guide/portfolio
Review equity, exposure, and positions across your live venue accounts.
Portfolio combines your venue balances and open positions into one view. It is a reporting layer: the underlying capital and risk remain at each venue.
## Overview
The overview reports:
* total equity across live venue accounts;
* unrealized PnL; and
* total notional exposure.
Accounts that are still syncing or offline are excluded until they report current data.
## Venue accounts
Each venue card shows its current status, account equity, quote asset, free margin, and open-position count. Use **Trade** on a venue card to return to that venue's terminal.
Common account states include **live**, **syncing**, **no account**, and **offline**.
## Positions
The positions table combines supported venue positions and shows side, leverage, size, value, entry and mark prices, unrealized PnL, and liquidation price. Select **Manage** to open the correct venue and market under Trade.
Portfolio totals do not pool collateral. Equity at one venue does not create buying power or protect a position at another venue. Use [Fund & Move](/user-guide/fund-and-move) to move capital between venue accounts.
For order-level status and history, use the activity panel described in [Trading](/user-guide/trading).
# Trading
Source: https://docs.mob.exchange/user-guide/trading
Select a market and execution venue, submit orders, and manage activity across venue accounts.
The Trade terminal combines market data, venue execution, and account activity in one workspace.
## Terminal layout
* The top bar selects the market and execution venue.
* The chart and order book show the selected market.
* The order ticket uses the selected execution venue.
* The activity panel tracks positions, open orders, and history across your venue accounts.
## Choose a market
Open the market selector to search by symbol or browse by product and asset category. Each listing shows the market type and available statistics, such as price, volume, open interest, or funding. You can save frequently used markets as favorites.
Market availability changes over time, so use the directory rather than a fixed asset list.
## Choose where to execute
The two selectors at the top serve different purposes:
* **Market** chooses the chart, order book, and market statistics you are viewing.
* **Execute on** chooses the venue that receives your order.
Selecting an execution venue does not transfer capital. The venue must already be funded and activated, and it must support the selected market. If setup is incomplete, the order ticket shows the required funding or activation step.
## Prepare and submit an order
The ticket exposes the controls supported by the selected venue and market. These can include:
* market and limit orders;
* buy/long and sell/short;
* sizing in quote or base units, including percentage sizing;
* leverage and margin mode;
* reduce-only and take-profit/stop-loss controls; and
* slippage, post-only, time-in-force, or expiry settings.
Before submitting, check the venue name, available buying power, order value, required margin, estimated execution price, slippage or price impact, liquidation price, and fees. Mobius pauses submission when required venue data is unavailable rather than filling in an estimate.
## Manage positions and orders
The activity panel has three tabs:
* **Positions** shows the venue, side, leverage, size, value, PnL, accumulated funding where available, and liquidation price. Use **Close** to submit a reduce-only order.
* **Open orders** shows working and partially filled orders. Resting orders can be canceled from the table.
* **History** shows completed, canceled, and rejected orders.
Selecting a position's market opens the matching market and venue in the terminal.
## Understand order status
Mobius distinguishes submission from venue confirmation:
* **Pending** means the action was submitted but is not yet confirmed in venue state.
* **Confirmed** means the venue reports the order or fill.
* **Rejected** means the venue refused the order.
* **Ambiguous** means Mobius cannot yet determine whether the venue accepted the submission.
If an order is ambiguous, check all three activity tabs and wait for a venue update before sending the same order again. Submitting a duplicate may create unintended exposure.
Use [Portfolio](/user-guide/portfolio) for an account-level view across venues.