Skip to main content

​
Role

A Venue Account is a trading account on a venue’s execution layer, controlled by the borrower’s Credit Account. It can trade spot, perps, and deposit into vaults while its total equity is recognized as collateral in the Credit Account. Every Venue Account action passes a pre-check to ensure the global HF stays at or above 1; risky transactions are blocked before they reach the venue.

​
Venue Account Model (VAM)

Venue Accounts are managed through the Venue Account Model — a modular framework for connecting Credit Accounts to external trading venues. The VAM consists of:
  • VenueRegistry: An onchain catalog of registered venues. Each venue has an ID, a driver, and a margin type.
  • VenueDriver: A per-venue contract implementing three interfaces:
    • Binder: Account lifecycle (bind, finalize, unbind)
    • Reader: State queries (snapshots, margin allocation, positions)
    • Writer: Action submission (orders, deposits, withdrawals)
  • Executor: An offchain service that bridges onchain intents to the venue’s API and confirms results back onchain.

​
Binding Lifecycle

1. bindAccount(hubAccount, venueId)     -> Pending binding
2. [Executor provisions account at venue]
3. finalizeBind(hubAccount, venueId, accountRef) -> Active binding
4. [Trading via submitAction / submitBatch]
5. unbindAccount(hubAccount, venueId)   -> Unbound

​
Action Flow

User submits action onchain -> Event emitted
                                    |
                        Executor picks up event
                                    |
                        Executor calls venue API
                                    |
                        Executor calls confirmAction()
                                    |
                        Onchain status updated
All requests are tracked with statuses: PENDING, CONFIRMED, FAILED, or EXPIRED. Expired requests can be marked by anyone after the deadline passes.

​
Liquidation Threshold

Venue Account equity must be converted into a single liquidation threshold (LTVALT_{VA}) that reflects leverage and volatility inside venue positions.

​
1. Adjusted LT for Leverage

We assume a 1x perp position carries similar risk to the spot asset. If spot BTC has an LTBTC=0.8LT_{BTC} = 0.8, a 1x Long BTC perp also has LT=0.8LT = 0.8. Let asset ii have base liquidation threshold LTiLT_i and Maintenance Margin Mi=1−LTiM_i = 1 - LT_i. For an NNx leveraged perp position: MNi=N(1−LTi),LTNi=1−MNi=1−N(1−LTi)M_{Ni} = N(1 - LT_i), \quad LT_{Ni} = 1 - M_{Ni} = 1 - N(1 - LT_i) Example: A 3x BTC Long (where base LTBTC=0.8LT_{BTC}=0.8) has an effective LT=1−3(0.2)=0.4LT = 1 - 3(0.2) = 0.4.

​
2. Portfolio Aggregation

For multiple positions, compute the weighted LTLT and cross leverage LcrossL_{cross}: LTweighted=∑i=1nSi⋅LTi∑i=1nSi,Lcross=∑i=1nSiELT_{weighted} = \sum_{i=1}^n \frac{S_i \cdot LT_i}{\sum_{i=1}^n S_i}, \quad L_{cross} = \frac{\sum_{i=1}^n S_i}{E} SiS_i is position size and EE is total Venue Account equity.

​
3. Final Liquidation Threshold

LTVA=1−Lcross(1−LTweighted)LT_{VA} = 1 - L_{cross}(1 - LT_{weighted}) Example: A Venue Account with 1000 USDC equity holds a 1000 USD BTC long (LT=0.8LT = 0.8) and a 2000 USD ETH long (LT=0.7LT = 0.7): LTweighted=0.8×1000+0.7×20003000=0.733,Lcross=30001000=3LT_{weighted} = \frac{0.8 \times 1000 + 0.7 \times 2000}{3000} = 0.733, \quad L_{cross} = \frac{3000}{1000} = 3 Therefore LTVA=1−3(1−0.733)=0.2LT_{VA} = 1 - 3(1 - 0.733) = 0.2, allowing roughly 200 USDC of borrow capacity against the Venue Account.

​
E-Mode (Efficiency Mode)

E-Mode boosts LTVALT_{VA} for tightly constrained strategies that reduce market risk (e.g., correlated hedges). Opting in restricts the Venue Account to a specific strategy category; transactions that would break the category are blocked.

​
Example: Leveraged Carry Trade

  • Holdings: 10 tokens spot
  • Position: 10 tokens short perp
  • Price: $30 (spot + short notional each $300)
  • Base LT=0.5LT = 0.5
Normal mode: gross exposure drives LcrossL_{cross} high enough that LTVALT_{VA} collapses to 0 — no borrowing headroom despite the hedge. E-Mode: the protocol recognizes perfect correlation and overrides to LTVA→0.9LT_{VA} \rightarrow 0.9, enabling up to 10x looping to maximize funding-rate yield while staying within the strategy guardrails.

​
Venue Integration Patterns

The VAM is designed to accommodate venues with fundamentally different architectures. How Mobius connects to a venue depends on whether the venue has a native bridge to the hub chain or requires API-based access.

​
Venues with Native Bridge

When a venue provides a native bridge between its execution layer and the hub’s smart contract layer (e.g., a shared-consensus programmable environment), Mobius can interact directly:
  • Binding: Native subaccount creation in a single transaction
  • Reads: Synchronous onchain state via precompiles or system contracts — high-confidence, block-fresh data
  • Actions: Direct calls that settle within the same block
  • Margin model: Physical — tokens move to the venue onchain
  • Confidence: HARD_ANCHORED — verifiable against the chain’s own state

​
API-Based Venues

When the venue is on a different chain or only exposes an API, Mobius connects through an executor relay:
  • Binding: Multi-step flow — the executor provisions credentials offchain and finalizes the binding onchain
  • Reads: Polled from the venue’s API with inherent latency — soft-attested data
  • Actions: Submitted by the executor to the venue’s API, confirmed back onchain asynchronously
  • Margin model: Escrowed — tokens are locked on the hub chain and relayed to the venue
  • Confidence: SOFT_ATTESTED — based on API responses, not onchain proofs

​
Executor Trust Model

A natural question: what if the executor reports false data? The design limits the executor’s power through several constraints:
  • No custody: The executor never holds user funds. Tokens are always in a hub-chain contract or at the venue.
  • Confirm-only: The executor can only confirm hub-initiated requests — it cannot create new ones or move funds independently.
  • Fail-closed staleness: If the executor stops reporting, snapshots go stale and the hub automatically tightens the account’s leverage limits. Silence hurts the account, not the protocol.
  • Deadline expiry: Any pending request that the executor does not confirm before its deadline can be marked as expired by anyone.
  • Rotation: The hub owner can rotate the executor address onchain if a key is compromised.
For native-bridge venues, the executor is not needed at all — reads and actions are verified directly against the venue’s own state.

​
What Stays the Same

Regardless of integration pattern, the hub-facing abstraction is identical:
  • Same Binder / Reader / Writer interfaces
  • Same action vocabulary (deposit margin, open position, close position)
  • Same risk surface (equity, margin, exposure, withdrawable)
  • Same request lifecycle (pending / confirmed / failed / expired)
Only the driver implementation differs — the hub never branches on venue type.

​
How This Affects Risk

The hub applies different risk policies based on venue confidence:
ConfidenceRisk Treatment
HARD_ANCHOREDStandard leverage limits, full collateral credit
SOFT_ATTESTEDTighter leverage limits, staleness checks, conservative margin buffers
NONE (unreachable)Account constrained — no new positions until data returns
This fail-closed design means degraded information always restricts the account, never relaxes it.