Hubble Exchange Litepaper


  • Mark price [MP]: Market price of futures
  • Position unrealized PnL: positionSize * (future mark price - position entry price)
  • Position notional: position size * MP
  • Total account value: collateral + unrealized PnL
  • Total position notional: sum of abs(position notional) across all positions
  • Margin fraction [MF]: total account value / total position notional
  • Maintenance Margin Fraction Requirement [MMF]: the minimum MF needed to avoid getting liquidated.

Margin Account

Users will post collateral in one or more of the whitelisted tokens. Each whitelisted token will have a collateralFactor associated with it. For e.g. the collateralFactor for USDC can be 1 and for BTC can be 0.8. For reference, these are the collateral factors used on ftx. Whitelisted tokens and their respective collateral factors will be determined by governance.

The account’s total weighted collateral (Cw) is the sum over all spot tokens:

Cw = ∑ collateralAmount * oraclePriceusd * collateralRatio [1]

Then total account value is given by:

Total account value = Cw + unrealizedPnLUSD [2]

Funding Payment

Every hour, each perpetual contract has a funding payment where longs pay shorts if perpetual is trading at a premium to the index, and shorts pay longs if trading at a discount to the index. This funding payment is equal to:

hourly funding payment = (mark_price_1_hour_twap - index_price_1_hour_twap) / 24

This payment is added/deducted to the account's vUSD balance.

Virtual USD (vUSD)

vUSD will be the intermediate unit of accounting for collateral value and Profit & Loss (PnL) calculations. Any positive PnL will be paid out in vUSD regardless of which type of collateral is used. Negative realized PnL will be represented as a negative vUSD balance in the user’s account. Trading and liquidation fees will also be deducted from the vUSD margin.

oraclePriceusd and collateralRatio for vUSD will be fixed at 1. Therefore, any positive or negative vUSD balance will contribute to collateral value. See [2].

A negative vUSD balance is essentially a debt owed to the system. Users can pay back this debt in USDC at a 1:1 ratio. Similarly, a positive vUSD balance is the system’s debt owed to the user. Users can redeem vUSD for USDC at any time.

Note that, if a big chunk of users come to redeem vUSD all at once, it’s possible that the system doesn’t have enough USDC to fulfill the obligation at any given time. This is because the system supports multi-collateral - A user might be using BTC for margin but has a negative vUSD balance that needs to be burnt in USDC. In this sense, the system is operating on fractional USDC reserves.

We tackle this in 2 ways:

1. Secondary Markets

We hope to see a secondary market for vUSD, specifically a vUSD : USDC curve pool. If the system doesn’t have enough USDC; users who want out of vUSD can exchange vUSD for USDC from this pool. Liquidity providers of this pool can even be incentivized with a portion of trading fees.

2. Disincentivize negative vUSD balances

This can be achieved in a couple of ways:A. Disallow transferring out any collateral when the user has a negative vUSD balance even if the user is well above the maintenance margin ratio.B. Charge interest on negative balances past a default threshold. This approach is more nuanced since it can be difficult to accurately determine the rate of interest, so we leave this exploration for later.

C. Collateral Conversions - Allow liquidators to convert user’s collateral to vUSD after the negative balance crosses a certain threshold percentage of their portfolio.

Insurance Fund (IF)

The insurance fund acts as a backstop for bad system debt. This arises from failing to liquidate an account at the opportune moment when it has fallen below the Maintenance Margin Fraction. The insurance fund will be denominated in vUSD. To incentivize the IF LPs, they’ll receive the majority of the trading fee and a 50% share in the liquidation fee alongside the liquidator.


The user’s weighted collateral is given as Cw and the spot value of the collateral is given as Cusd. Say, the user has negative unrealized PnL (denoted as PnL).

  • The user is safe from liquidations as long as they satisfy the margin maintenance requirement.
  • As the -ve unrealized PnL increases (becomes more negative), the trader will approach a liquidation point. For a maximum allowable 10x leverage, Maintenance Margin Fraction (MMF) = 0.1.At liquidation,(Cw + PnL) / notionalPosition < 0.1

=> PnL < 0.1 * notionalPosition - Cw

  • When the user is liquidated, their positions are closed, hence notionalPosition becomes 0. They also pay a liquidation fee (Lfee). PnL And Lfee are realized as deductions from the vUSD margin.


vUSD margin + PnL - Lfee = vUSD

  • If vUSD >= 0, the trader is safe from further liquidations.
  • If vUSD < 0, there are several scenarios:

a. |vUSD| <= CwThe user is safe because their obligation to the system |vUSD| is less than their weighted collateral.b. Cw < |vUSD| <= Cusd

At this point, the user’s margin account can be liquidated. This liquidation is exactly like what you’d expect in a compound or aave like system. The maximum liquidation incentive per dollar that can be awarded to the liquidator is Cusd - |vUSD|. The system can impose an upper on the liquidation penalty, say 5%.Liquidation incentive is,min(.05, (Cusd - |vUSD|) / |vUSD|)

c. Cusd < |vUSD|This situation will arise if liquidations are not performed in time. At this point, the trader’s obligation to the system is greater than the spot value of their collateral so there is no incentive for them to settle the negative vUSD balance. So, the insurance fund pays the deficit of |vUSD| - Cusd.

Virtual Automated Market Maker (vAMM)

As the “virtual” part of vAMM implies, there is no real asset pool stored inside the vAMM itself. Instead, the real asset is stored in a smart contract vault that manages all of the collateral backing the vAMM; and the vAMM is just used for pricing the perps. In fact, that is how the mark price is determined. More details about our vAMM were published here.

Makers in Hubble vAMM