Mobius is the RWA Prime Terminal on Robinhood Chain. It combines pooled lending, onchain collateral (including Robinhood Stock Tokens), and positions at external trading venues in a single Credit Account.

Venues still execute trades and enforce their own local margin. Mobius finances and evaluates the combined portfolio. Robinhood Chain remains the canonical layer for debt and portfolio risk.

• Terminal: app.mob.exchange
• Protocol docs: docs.mob.exchange
• Updates: @MOB_Exchange_

This document is a reading of the official Mobius documentation, not a description of any particular integration client.

Tokenized assets, lending markets, and perp venues each run an isolated margin system. A Stock Token on Robinhood Chain cannot ordinarily support a Hyperliquid or Aster position. A hedge on Lighter cannot reduce collateral required at another venue. Capital is posted repeatedly, hedges go unrecognized, and borrowing power cannot follow the portfolio.

Mobius’s answer: one credit and risk layer across those systems, without making every position interchangeable or every hedge creditworthy.

Mobius separates portfolio authority from venue execution (How Mobius Works):

Lenders → Lending Pool ──debt──► Credit Account ──► Onchain Risk Engine (global HF)
                              ▲
Robinhood Stock Tokens ───────┘
                              │ authorized intents
                              ▼
                     TEE-backed Executors
                              │
            Hyperliquid · Lighter on Robinhood · Aster
                              │ authenticated venue state
                              ▼
                     Onchain Risk Engine

• Lenders supply pool assets and earn interest from Credit Account debt.
• Account owners / strategists deposit collateral, borrow, and compose approved onchain + venue positions.
• TEE-backed Executors bind Venue Accounts, process authorized actions, and relay results.
• Liquidators repay unhealthy Credit Account debt and receive collateral per market rules.

From How Mobius Works:

1. Lenders supply a Robinhood Chain pool.
2. Owner opens a Credit Account and deposits approved collateral (e.g. Stock Tokens).
3. Account increases debt once, to the amount permitted by collateral and strategy.
4. Account binds Venue Accounts through the Venue Account Model.
5. Orders, deposits, withdrawals, and closures start as Credit Account–authorized intents.
6. An Executor executes the permitted action and reports the outcome.
7. The risk engine updates global HF from direct holdings, authenticated venue equity, and debt.
8. Risk-increasing actions are blocked on breach. If unhealthy, venue exposure is unwound and the Credit Account can be liquidated.

Onchain steps can be atomic in a Credit Account multicall. External venue actions cannot share that transaction. They follow:

AUTHORIZED → PENDING → CONFIRMED
                     → FAILED
                     → EXPIRED

Pending activity is not treated as a successful trade. Until the result is authenticated, the risk engine uses conservative accounting so an incomplete action cannot create unsupported borrowing power.

Lending pools live on Robinhood Chain and lend to Credit Accounts, not to venues.

Each pool accepts a defined asset set, issues pool shares, accrues interest on outstanding debt, and allows withdrawals when liquidity allows. Lenders do not pick which venue a borrower uses: the Credit Account stands between the pool and every venue.

Non-rehypothecation. Collateral posted to a Credit Account is not lent to another borrower. It stays in that account’s portfolio - onchain or allocated through an authorized Venue Account.

• Lender deposits = debt capital.
• Borrower collateral = security, not lendable supply.

A Mobius market defines pool assets, permitted Credit Account collateral, integrated venues, oracles / state inputs, liquidation thresholds, and strategy categories eligible for specialized risk treatment. Robinhood Stock Tokens are a canonical RWA collateral type; admission and borrowing power are market-specific.

Utilization for asset (a):

[ Utilization_a = \frac{Outstanding\ Debt_a}{Supplied\ Liquidity_a} ]

Rates rise with utilization and steepen above the kink to protect withdrawal liquidity. Accrued interest enters the denominator of global HF.

The Credit Account is the portfolio and authority boundary. It is a Robinhood Chain smart account.

It directly holds onchain assets (including supported Stock Tokens) and records:

• principal and accrued borrowing interest
• permissions for assets, adapters, venues, and strategies
• active Venue Account bindings
• pending and completed venue requests
• state required for global HF

External positions are not treated as if the onchain wallet held those assets. They enter only through authenticated Venue Account state.

Two controlled interfaces, neither open-ended:

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

The market defines which contracts, assets, venues, and actions are permitted. An Executor may process a venue intent only after the Credit Account has authorized it.

Every account belongs to a market with a defined universe. Assets outside that universe cannot contribute collateral. Unsupported venue state cannot enter HF. A strategy category can narrow this further (e.g. one Stock Token, matching hedge, approved venues, bounded hedge ratios). Those restrictions are what allow the risk engine to recognize a hedge.

Leverage is established with a single debt increase to the full amount permitted by collateral and strategy, then the resulting balance is deployed across onchain assets and Venue Accounts. While venue actions are pending, conservative treatment applies; the intended final position is not assumed.

• Onchain multicalls revert if the final state is not permitted.
• Venue actions must match an authorized pending request.
• Failed or expired requests are not completed positions.
• Risk-increasing actions are blocked when the account is unhealthy, stale, or being unwound.

At time (t) (Credit Account):

• (Q_i(t)), (P_i(t)), (LT_i) - quantity, price, and liquidation threshold of onchain asset (i)
• (V_j^{risk}(t)) - conservative risk-adjusted net value of Venue Account (j)
• (d(t)) - principal debt
• (b(t)) - accrued interest

[ C(t) = \sum_i Q_i(t),P_i(t),LT_i + \sum_j V_j^{risk}(t) ]

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

Liquidatable when (HF < 1).

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

The standard HF does not assume separate exposures offset. An approved strategy may recognize a Stock Token long vs matching perpetual short only while instruments, venues, oracles, hedge ratio, leverage limits, and freshness all hold. If a constraint fails, strategy treatment is lost. Correlation alone is not enough.

A Venue Account is the Credit Account’s controlled presence at an execution venue. It holds margin and positions under that venue’s account system. Authenticated net value and exposure enter global HF.

• Venue: execution and local margin.
• Credit Account: authorization, portfolio debt, global solvency.

A common Robinhood Chain interface over venues with different APIs, accounts, settlement, and margin:

Hyperliquid, Lighter on Robinhood, and Aster share this Credit Account–facing model. Drivers differ; lending and HF interfaces do not.

BIND_REQUESTED → Executor provisions / associates
                      ├─ ACTIVE
                      └─ FAILED
ACTIVE → UNBOUND after positions and obligations are resolved

A binding does not authorize arbitrary trading. Every risk-impacting action still needs a permitted Credit Account request.

Cash/spot, open positions and notional, UPNL/RPNL, margin and withdrawable, pending ops, observation time and freshness. Headline equity is not assumed fully borrowable. Intended trades are not assumed complete before confirmation.

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

[ V_{VA}^{risk} = E \times LT_{VA} ]

A 1x perp starts at the underlying asset’s (LT_i). For (N\times) leverage:

[ LT_{Ni} = 1 - N(1 - LT_i) ]

Example: 3x BTC with (LT_{BTC} = 0.8) → (LT_{3BTC} = 0.4).

Across several positions, Mobius uses a notional-weighted threshold and cross leverage (L_{cross} = \sum S_i / E):

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

Example from the docs: $1,000 equity, $1,000 BTC ((LT=0.8)) and $2,000 ETH ((LT=0.7)) → (LT_{weighted} \approx 0.733), (L_{cross} = 3), (LT_{VA} = 0.2). The Venue Account contributes about $200 of risk-adjusted collateral.

Standard (LT_{VA}) is gross. E-Mode applies a higher strategy-specific threshold when an approved, tightly constrained relationship reduces market risk (eligible assets, venues, hedge ratios, leverage). Leaving those constraints, or going stale, drops E-Mode.

RWA carry example in the docs: 10 Stock Tokens at $30 and an equal $300 short, base (LT = 0.5). Gross treatment can drive (LT_{VA}) toward zero; approved E-Mode can apply something like (LT_{VA} \rightarrow 0.9).

The same idea can net equal-and-opposite legs in funding-arbitrage E-Mode. No unrestricted netting outside the category.

A venue sees only local capital and positions. It does not rely on Stock Tokens left on Robinhood Chain or equity at another venue. A locally under-margined Venue Account can be liquidated while the Mobius portfolio is still globally healthy. The loss then feeds global HF.

Executors are an execution boundary, not a second source of authority.

They bind accounts, process authorized orders/cancels/deposits/withdrawals/closures, observe success/fail/deadline, relay normalized state, and coordinate unwinds. Credentials stay in hardware-isolated execution.

An Executor cannot: originate a discretionary trade; withdraw without an authorized request; add an unsupported venue or asset; change Credit Account debt or risk config; treat an unconfirmed venue outcome as completed onchain state.

Each request has a stable identifier and deadline. Retries are idempotent: an interrupted process can resume without intentionally submitting the economic action twice.

Fail-closed: stale state gets reduced risk value; pending stays pending until established; failed/expired are not credited; risk-increasing requests are rejected during unwind; malformed state is rejected, not guessed.

How many Executor operators exist is deliberately not part of the safety model.

Two independent solvency boundaries (Liquidation):

Venue-native. The venue can close/liquidate if local maintenance margin fails. That changes realized PnL and equity, which then enter global HF. Local liquidation does not automatically close the Credit Account, but the loss can make the global portfolio unhealthy.

Global. When (HF < 1):

1. Restrict activity - no new risk-increasing actions; pending requests cannot create extra borrow capacity.
2. Unwind venue exposure - authorized closures only.
3. Recover value - withdrawable assets return through the Venue Account workflow.
4. Repay debt - a liquidator repays the pool and receives collateral per market parameters.

Venue actions are asynchronous, so the account stays restricted until unwind completes. Stable request ids and explicit statuses prevent a delayed confirmation from being mistaken for a new action.

Liquidators buy collateral at a discount:

[ Liquidator\ Cost = Collateral\ Received \times (1 - Liquidation\ Bonus) ]

Fail-closed safeguards: freshness, strategy enforcement, operation checks, unwind guard, non-rehypothecation. These do not prevent every venue-local liquidation. They prevent uncertainty from making the global book look safer than it is.

Both strategies borrow once, then deploy. HF is strategy-scoped only while constraints hold.

Docs. Deposit a Stock Token, borrow the permitted amount, add RWA exposure plus venue margin, Executor opens a short perp equal to total RWA notional.

[ RWA\ Long\ Notional \approx Perpetual\ Short\ Notional ]

[ Net\ Carry = Funding\ Income - Asset\ Carry - Borrowing\ Cost - Execution\ Costs ]

Illustrative docs example: $10k equity, $50k Stock Token + $50k short. If the short receives 11% funding and borrow costs 8%: (5 \times 11% - 4 \times 8% = 23%) annualized illustration, not a forecast. Actual allocation depends on venue margin.

Docs. Same Credit Account, margin on two venues, equal-notional long and short on the same underlying. Short where short funding is higher.

[ Gross\ Funding\ Income = Position\ Notional \times (Short\ Funding\ Rate - Long\ Funding\ Cost) ]

Illustrative docs example: $10k equity, $50k ETH short on Hyperliquid at 15% vs $50k ETH long on Aster at 5% → $5,000 gross, then minus borrow and execution.

The live product is documented in the user guide. It is a multi-venue execution UI. Protocol Credit Account unification and the current terminal’s capital movement are not the same thing.

Per Getting started, orders currently route to:

The application is the source of truth for which markets a venue can actually execute. A symbol in the directory does not mean every venue can trade it.

Protocol docs also describe Aster in the Venue Account Model. It is part of the architecture; it is not listed as a live Execute on target in the current getting-started guide.

1. Open app.mob.exchange and connect an EVM wallet.
2. Fund & Move - fund Lighter RH or Hyperliquid.
3. Select the venue under Execute on and Activate trading.
4. Choose a market, submit the order.
5. Follow Positions, Open orders, or History.

Funding and activation are separate. Funding moves capital into a venue account. Activation authorizes a trading key for this device. That key can place orders but cannot withdraw. Withdrawals return only to the connected owner wallet. Another browser or device may need activation again.

Fund & Move routes wallet ↔ venue. Funding one venue does not fund the other.

Deposits: choose destination venue, source chain/token, amount; review route, fees, time. Non-native assets go through Relay (swap + bridge). Keep the page open: a confirmed source-chain tx is not yet a venue credit.

• First USDG deposit opens the Lighter RH account for that wallet, then activate under Trade.
• Hyperliquid perps use the perpetual balance. Spot USDC on Hyperliquid may offer Move to perps instead of a new deposit.

Withdrawals always hit the owner wallet first:

• Lighter RH → USDG on Robinhood Chain
• Hyperliquid → USDC on Arbitrum

A different destination chain is a second Relay transaction. If the bridge fails, funds remain in the wallet on Robinhood Chain or Arbitrum.

Trading: Market selects chart/book/stats; Execute on selects who receives the order. Changing Execute on does not move capital. The venue must already be funded, activated, and support that market.

Ticket controls depend on venue/market (market/limit, long/short, quote or base size, leverage/margin mode, reduce-only, TP/SL, slippage, post-only, TIF, expiry). Mobius pauses submission when required venue data is unavailable rather than inventing an estimate.

Order status is submission vs venue confirmation:

If Ambiguous, check Positions / Open orders / History and wait before sending the same order again.

Portfolio is a reporting layer. Totals are equity, UPNL, and notional across live venue accounts. Syncing or offline accounts are excluded.

Portfolio totals do not pool collateral. Equity at one venue does not create buying power or protect a position at another venue.

That is the current terminal. Cross-venue credit (one HF, authenticated venue equity as collateral) is the protocol Credit Account model above, not this UI total.

Strategy in the app is the cross-venue funding-arbitrage workflow.

Figures and formulas in this README are taken from those pages. Markets, venues, and parameters change; the live app and docs are authoritative.