MUX core features are supported by four unique mechanisms:
Liquidity pools on trading protocols are usually fragmented from chain to chain, leading to inconsistent liquidity depths. MUX unifies liquidity across networks by using a broker module, which is a bot that monitors total liquidity and the liquidity reserved for margin trading. After a trader places an order, the broker will calculate the available liquidity across deployed networks and fill the order if it can meet position size. The universal liquidity mechanism offers higher capital efficiency on all deployed networks without moving pooled assets around.
Let’s assume the pools on Arbitrum, Avalanche, BSC and Fantom each hold 10 ETH, and 5 ETH are currently reserved for active positions. As the broker observes all deployed networks, it will determine the total universal liquidity as 40 ETH, and the available liquidity as 35 ETH. If a trader places a 20 ETH long order on Arbitrum, the following process will take place:
- 1.After the order is submitted on the chain, the broker proceeds to deal with it.
- 2.The broker will check if the universal liquidity meets the order size requirements.
- Total universal liquidity is 40 ETH (10 + 10 + 10 + 10), and the available universal liquidity is 35 ETH (40 - 5)
- 35 ETH is greater than the order’s required 20 ETH and as such the broker will proceed to fill the order
After opening this long position, the 20 ETH will be reserved until the position is closed. On the LP side, after LPs supply ETH on Avalanche, BSC or Fantom, trading activities on Arbitrum can utilize these ETH without actually moving them.
In the rare cases when the pooled liquidity on a chain can’t fully cover traders’ profits, the traders will receive muxTokens as profits. After receiving muxTokens, users can redeem them into related tokens on other chains. For example, if the pool on Arbitrum only holds 10 ETH while a trader tries to withdraw 20 ETH profits from a related position on this chain, the trader will receive 10 ETH and 10 muxETH. Meanwhile, the pool on Avalanche has 50 ETH, so the trader can bridge the 10 muxETH to Avalanche, then redeem them into 10 ETH.
The word "multiplexing" (abbreviated as muxing) is a telecommunication term, and it means combining various signals into one composite signal through a shared medium, aiming to share valuable resources. Using the same concept, MUX dynamically shares liquidity across multiple utilization routes, including on-platform margin trading and third-party DEX mining, seeking to significantly increase the utilization rate.
MUX will allocate pooled liquidity for margin trading and third-party DEX mining across networks to maximize utilization. The protocol will preferentially reserve liquidity for traders and earn fees while using idle assets for DEXes mining to generate yield; when the margin trading demand increases, the MUX broker will channel the liquidity back from DEXes and reserve it for traders.
During the multiplexing process, the assets used for trading and mining can overlap, and the protocol restricts the overlapping proportion with a cap, currently at 80%. The restrictions help to ensure the pooled assets can fully cover traders' potential profits. For example, suppose the total pooled liquidity is 1 ETH, and it's used for third-party DEX mining; when a trader opens a position with the size of 0.81 ETH, the liquidity will be channeled back from mining and solely reserved for the position.
In terms of funding payments, the funding rate will be calculated based on margin trading liquidity utilization; liquidity multiplexing will not affect the rate.
The MUXLP pool, which is the counterparty of traders, is always fully collateralized with a portfolio of blue-chip assets and stablecoins. When traders open leveraged positions, the pool will reserve required assets until the position is closed; meanwhile, the pool will hold positions against traders in the opposite direction. If a trader's position is in profit, upon closure, the trader can withdraw the collateral and profits from the reserved assets. If the trader's position is at a loss, upon closure, traders will pay for the losses with the collateral.
For risk management, long and short positions under each market will have open interest caps. The caps won't exceed pooled liquidity capacity, so the pool is always capable of paying for the trader's profits; therefore, the traders don't have counterparty risks.
Let's assume 1 ETH is priced at $1000, the MUXLP pool has 4 ETH, and a trader uses 1000 USDC as collateral to open a 3x ETH long position. In this trade, the MUXLP pool reserves 3 ETH (worth $3000) for the trader. Meanwhile, the pool simultaneously opens a 3 ETH (worth $3000) short position with 1x leverage. At this moment, the MUXLP pool is reserving 3 ETH while shorting 3 ETH, resulting in 1 ETH net exposure.
ETH price then rises to $2000, and the USD value of this position becomes $6000; the unrealized profits are $3000. The trader now closes this position and can withdraw the 1000 USDC collateral and 1.5 ETH (worth $3000) from the reserved ETH as profits. In this example, the pool loses 1.5 ETH from this trade, but the USD value of pooled ETH remains unchanged since 1.5 ETH is now worth $3000. When it comes to long positions, the MUXLP pool can suffer Coin-denominated losses but remains delta neutral.
When traders open short positions, the MUXLP pool will reserve stablecoins for traders. In this case, the pool is exposed to USD-denominated losses. However, since there are open interest caps under each market, the pool will always manage the capacity at a level where all trader's profits can be fully covered. Also, the market is usually skewed; the total open interest of longs is greater than shorts in most circumstances, so the MUXLP pool mostly holds net short positions, which are less than the assets in the pool.
MUX uses a dark oracle that aggregates price feeds from multiple sources, including Binance, Coinbase and Bitfinex to ensure pricing accuracy and stability. A dark oracle is a private price oracle which does not publicly display the prices of assets in the pool, and the primary purpose is to prevent front-running. In addition, the dark oracle eliminates nearly all room for toxic arbitrage, further enabling zero price impact trading. When traders place orders, the MUX broker module will obtain prices from the dark oracle and fill the orders with zero price impact.