Risk Parameters & Mitigation

Margin Requirements: We define:

• Initial Margin (IM): e.g., 5% for 20x max leverage on major assets, maybe higher for volatile or low-liquidity markets.

• Maintenance Margin (MM): e.g., 3% on major markets. If equity falls below 3%, liquidation triggers.

• The required margin can be dynamic based on position size (larger positions require higher margin% due to price impact risk).

For a given account, maintenance margin check: Equity=Collateralvalue+∑positions(unrealized PnL)−funding fees owed.\text{Equity} = \text{Collateral}_{\text{value}} + \sum_{\text{positions}} (\text{unrealized PnL}) - \text{funding\ fees\ owed}.Equity=Collateralvalue​+∑positions​(unrealized PnL)−funding fees owed. Unrealized PnL is calculated with respect to the mark price (likely the index price or slightly conservative). If Equity < $\sum |\text{position}_i| \times \text{Price}_i \times MM_i$, then the account is below maintenance.

Position Risk Limits: To prevent one account from accruing an unmanageable position, we can set tiered position size limits. E.g., first 1,000 contracts at 5% IM, next 1,000 at 10% IM, etc. This approach is used on some exchanges to manage risk of huge traders.

Price Banding: We refuse or auto-cancel orders that are far from the current price (to prevent someone from placing an absurd order that manipulates mark). For example, limit orders more than 20% away from last trade could be disallowed or require a keep-alive heartbeat (to ensure they are intended).

Slippage Tolerance: For market orders, users can set a max slippage. If the CLOB + AMM cannot fill within that, the trade aborts. This protects users and also prevents scenarios where the AMM could be drained at a bad price on one huge order. Risk Mitigation Strategies

Oracle Integrity: The dual oracle approach (TWAP + Chainlink) protects against manipulation of either source alone. The protocol might use Chainlink as primary and TWAP as sanity check – e.g., if a price feed diverges by >1% from the 5-min TWAP, flag an anomaly and temporarily weight more on the TWAP or pause funding calculation. This prevents short-term oracle attacks from massively impacting funding or liquidations. In addition, MegaETH’s on-chain order flow itself provides price signals; we could incorporate the last trade prices (excluding outliers) into the index if external feeds fail.

Price Band & Circuit Breakers: Similar to traditional markets, if the index price of the underlying moves too fast (say > X% in a minute), the protocol can trigger a circuit breaker: temporarily pause new trades and only allow closing trades for a short period. This can prevent cascading liquidations from an oracle glitch or a sudden crash. Given MegaETH’s speed, even a 1-minute pause is significant (120 blocks) – enough for human intervention or oracle recovery if needed.

Toxic Flow Reduction: “Toxic flow” refers to informed traders trading against the AMM right before price moves (often harming LPs). We mitigate this with:

• Dynamic Fees: as noted, fees that increase with volatility or if the AMM is heavily one-sided. Toxic flow typically comes in volatile times; higher fees then make it less profitable to snipe the AMM.

• Just-in-Time (JIT) Liquidity: Inspired by Drift’s approach, when a market order comes in, we can allow a short time window (a few seconds or in our case, maybe a single block or a fraction of a block if MegaETH allows) for professional makers to step in and fill the order at a better price than the AMM. Essentially, an on-chain “flash auction”: the trade is not immediately executed against the AMM if some maker is willing to take it. In MegaETH context, we might implement this as: the market order tx hits the contract, which then emits an event or enters a very short bidding phase (maybe using MegaETH’s parallel execution, or simply makers monitor mempool and have the ability to pre-empt the AMM by submitting their own matching orders in the same block). This way, toxic order flow that would have eaten the AMM is often intercepted by arbitrageurs/makers who willingly take the other side (because they may have better information or hedging ability). This was shown to reduce AMM’s load and improve prices on Drift.

• Maker Order Oracles: We allow oracle-pegged limit orders – makers can specify orders like “sell 10 stETH perp at OraclePrice + 0.5%”. This uses the real-time oracle in the order price computation. It enables automated strategy where makers basically say “I’ll always be x% above the true price.” As the oracle moves, the order’s price updates (we can implement this by allowing a formula in the order that the contract evaluates each block). This keeps the order book tight to the oracle without makers constantly re-posting, and it reduces latency arbitrage opportunities. It also helps ensure that if the AMM is off, these oracle-following orders will arbitrage it.

• Inverted Maker/Taker Roles: Typically, a taker pays fees and a maker earns fees. We keep that, but we also leverage the concept from Drift where takers submit the order and then makers compete to fill it. In our context, the “taker” (market order) is automated and might allow a slight improvement by any maker willing to beat the AMM price. This inversion means makers don’t have to pre-position liquidity and expose themselves continuously; they can react when there’s actual order flow, which avoids having stale quotes that toxic traders exploit. This alignment encourages more maker participation and ensures the best possible execution for takers.

Preventing Oracle Manipulation of Yield Assets: Some yield-bearing tokens (like cTokens) might have complex pricing (depending on interest rate models) or lower liquidity. We’ll only list such assets if we have robust price oracles. For stETH, a combination of Chainlink price and the stETH/ETH Curve pool TWAP is reliable. For something like cUSDC (a Compound interest-bearing token), its price is algorithmic (grows based on interest rate); we can calculate it on-chain from the interest rate model plus get the underlying USDC price. These redundant checks mean the perp index is hard to spoof.

Contract Security: All smart contracts will undergo audits. The hybrid model has more surface area (CLOB, AMM, margining, etc.), so testing in various scenarios (including economic exploits) is crucial. We will implement safeties like:

• Re-entrancy guards, especially around vaults.

• Caps on maximum withdrawal per block from vaults (to avoid draining via a bug).

• Emergency pause: governance multisig or a guarded launch with ability to pause markets if something’s clearly wrong (to be removed or time-locked after proving stability).

Insurance Fund and Backstops: The insurance fund collects a portion of fees (e.g., 10% of all trading fees or all liquidations fines). It’s invested in safe yield (perhaps the same yield-bearing assets). In a crisis (e.g., a huge gap move causing many accounts to go negative), the insurance fund covers losses. If it’s not enough, the protocol can have a temporary debt token issuance or a social loss mechanism:

• Socializing loss: All profitable traders in that interval give up some profits to cover the loss, or all remaining margin is haircut by a small percentage. This is last resort; ideally avoid through conservative risk management.

• We could also introduce a backstop stakers program: users stake the protocol’s governance token or stablecoins into a safety module and earn rewards, but are on the hook to cover extreme losses.

Compliance with MegaETH Execution Model: We ensure that our protocol plays nicely within MegaETH’s consensus and execution rules:

• Avoid excessive state bloat: The order book could theoretically hold many orders (each an entry in storage). We will periodically clean up expired or far-off orders and perhaps charge a small gas deposit for placing orders that is refunded when the order is removed, to discourage spam. MegaETH likely has generous block gas limits, but we still economize on data structures.

• MEV and Front-running: Because everything is on-chain, order flow could be susceptible to MEV bots trying to sandwich trades. MegaETH’s high speed reduces the window for this, but we also consider using batch auction methods (all trades in a block share one pricing tick) to mitigate sandwich attacks. Additionally, the inverted role mechanism (makers responding to takers) inherently makes traditional sandwiches harder, since the taker’s order isn’t public until it’s executed, giving no time for a third-party to insert themselves in between.

• Validator Incentives: If MegaETH validators see the mempool, they might try to pick off large orders. We can mitigate by encrypting order details (using commit-reveal for limit orders: user commits a hash of order, reveals in a subsequent tx) if needed. However, commit-reveal might add latency; given our reliance on speed, we might only use this for very large orders or for stop orders, etc.

Scenario: Oracle Price Rapid Change: Suppose a sudden large price drop in stETH spot by 20%. The Chainlink oracle updates after 1 minute with the new price, but our on-chain TWAP might lag 5 minutes. To protect the system in that 1 minute:

• We might have a failsafe to pause new longs on stETH-PERP if the on-chain price has dropped more than, say, 10% without a corresponding oracle update. Shorts can still open (since that helps push price down toward oracle expectation) but longs are restricted (to avoid someone entering long at a stale high price index and then the index updates low causing immediate underwater position).

• Liquidations would use whichever price is more current. Perhaps use the lowest of (current AMM price, last trade price, oracle price) for liquidation checks to be safe.

• Once oracle updates, the index realigns, funding will spike (shorts owe longs since perp likely went below index in the interim or vice versa) and the system rebalances.

Stress Testing: We simulate extreme conditions: high volatility, large position liquidation cascades, oracle failure, etc., to ensure the combination of the above mitigations are sufficient. For instance:

• Black Thursday scenario: 50% market crash in minutes. Our circuit breakers halt trading momentarily, insurance fund and liquidators handle positions, and any shortfall is covered by backstop without collapsing the system.

• Yield spike scenario: Underlying yield (say a cToken interest rate) suddenly spikes from 5% to 30% (could happen if Compound rates change). Our interest rate $r_{base}$ gets updated (perhaps through governance or automatic feed). This would make funding highly positive for longs (longs pay much more). We cap the rate change per interval to not shock users (maybe gradually increase it or announce it). And ensure UI communicates these changes.

Comparison to Prior Models: Unlike purely vAMM-based perps (Perp v1) which suffered when long-short imbalance grew and had to pay out of the insurance fund, our hybrid model avoids the protocol bearing funding costs – funding is strictly exchange between traders (longs and shorts) or mitigated by external liquidity. The AMM liquidity is balanced by order book liquidity, greatly reducing the chance of the protocol itself owing money to traders. Drift v1’s failure with LUNA crash (bad debt due to imbalance) is addressed by having the order book and JIT makers step in, plus robust liquidation logic to not allow unbounded bad debt. Essentially, multiple lines of defense (makers, funding, liquidations, insurance) ensure stability.

Finally, governance and upgrades: Because MegaETH is new and this design is complex, we likely launch under timelocked upgradeable contracts or controlled by a multisig initially, to allow quick patches if necessary. Over time, as the system proves robust, we transition to full on-chain governance with decentralized control of parameters.