How It Works

An oracle price, not an order book

On a traditional exchange your order rests in a book until another trader takes the other side, and your price depends on who is willing to match you. Levant has no book and no matching engine. Prices come from a verified price oracle, and the Levant Vault is the counterparty to every trade. Because the vault is always on the other side, there is always liquidity and there is nothing to match — you fill at the oracle mid price, adjusted only by a deterministic spread.

• Unified liquidity — all 20 crypto markets (BTC, ETH, SOL, BNB, XRP, DOGE, ADA, TRX, AVAX, LINK, DOT, SUI, LTC, BCH, NEAR, APT, UNI, ATOM, ARB, OP) draw on the same vault, so even long-tail assets trade with size.
• Deterministic pricing — your fill is the oracle mid plus a known, formula-driven spread, not an auction outcome.
• No order-book MEV — with no resting orders there is nothing to sandwich, front-run, or last-look.
• Always a counterparty — the vault takes every trade, so a fill is never blocked waiting for someone to match you.

The vault is your counterparty

The Levant Vault is a shared ERC-4626 liquidity vault denominated in USDG. It takes the other side of every position: it pays trader profits, absorbs trader losses, and collects every fee — the open and close fees, the funding paid by the crowded side, and the remainder of a liquidated position's collateral. Liquidity providers deposit USDG and receive lvUSDG shares. Their return is the fees plus net trader losses; their risk is that traders are net profitable — LPs are effectively short the traders' aggregate PnL. Trader losses first fill a protocol loss buffer that absorbs payouts before LP principal is touched.

For each open position the vault reserves exactly margin × 9 — 900% of your net margin — as locked liquidity. This is what guarantees the vault can always pay out that position's maximum-profit cap. LPs can only withdraw unlocked liquidity, and withdrawals are instant up to that unlocked amount, so open positions can never leave the vault unable to settle a winning trade.

The two-step keeper flow

Every trade executes in two on-chain steps separated by an off-chain keeper. This split is what lets Levant price your trade against a fresh, verified oracle report instead of a stale on-chain number. Your funds are escrowed by the Diamond contract the whole time — the keeper never holds them.

1. 1You escrow collateral and submit an intent. submitOpenIntent posts a market order; submitLimitIntent posts a limit or stop. You commit market, direction, collateral, leverage, and a mandatory max-slippage tolerance, and your collateral is transferred into escrow. Nothing has filled yet.
2. 2A keeper fills it at the next verified price. The keeper calls executeOpen with a signed oracle price report; the contract verifies it and mints your position at that price. A market order fills at the next verified mid. A limit or stop fills only once the verified oracle mid crosses your trigger — and that check runs on-chain, so the keeper can neither fill it early nor fabricate the cross.

Closing is symmetric. You flag the position with closePosition (full) or closePartial (a 0.01–99.99% slice), then a keeper settles it with executeClose against a signed report. An unfilled open intent — for example a limit that never triggered — can be withdrawn any time with cancelIntent, which refunds the full escrow.

How your fill price is set

Your fill is the oracle mid plus or minus a spread in basis points, and the spread is fully deterministic — there is no random slippage. It is a constant plus a price-impact term that grows with your trade size relative to market depth, plus a skew term that grows with how far your trade pushes the long/short book from balance. It is always applied worse-for-trade: opening a long or closing a short is a buy and fills *above* mid; opening a short or closing a long is a sell and fills *below* mid. The total is floored at 0 (a fill is never better than mid) and hard-capped at 5% (500 bps).

spread(bps) = constant + priceImpact + skew

  constant    = 2                                 (0.02%, always)
  priceImpact = notional * 100 / depth1pct         (depth1pct = 10,000,000 USDG)
  skew        = skewCoeff * imbalance / oiCap       (skewCoeff = 100 bps, oiCap = 2,000,000 USDG)
                (imbalance = signed net OI + half of your own size)

  total floored at 0 (never better than mid), capped at 500 (5%)
  entry / exit = mid * (1 +/- spread/10,000)        (+ for buys, - for sells)

Worked example: open a 1,000,000 USDG long on BTC into a balanced book. The constant contributes 2 bps; price impact is 1,000,000 * 100 / 10,000,000 = 10 bps; skew is 100 * 500,000 / 2,000,000 = 25 bps (the imbalance counts half your own size, 500,000). Total spread = 37 bps, so you fill at mid × 1.0037, about 0.37% above the oracle mid. Cutting your size shrinks the price-impact term, and opening on the book's underweight side reduces or zeroes the skew term — though the total is floored at the mid, so it never becomes a rebate.

Slippage protection and the open guards

Every open and limit intent carries a mandatory max-slippage tolerance in the range 1–500 bps — there is no silent default. In the app you pick a Max slippage (for example 0.10%, 0.30%, 0.50%, or 1.00%). At fill time, if the spread would push your entry further from the mid than your tolerance, executeOpen reverts with SlippageExceeded. The intent is *not* consumed — it stays pending, the keeper can retry when the spread narrows, and your escrow remains fully reclaimable with cancelIntent.

There is a second guard at open. executeOpen refuses to mint a position that would already be at or under its maintenance margin at the price it filled against, reverting LiquidatableAtOpen. At very high leverage the entry spread alone can put a position underwater on the first block — the engine will not open a trade that is dead on arrival, and because the transaction reverts, no open fee is taken.

Settlement and PnL

Two fees frame a position. The open fee is 0.08% of your *gross* notional (deposit × leverage) and is deducted from your deposit; what remains is your net margin. Your position size — its notional — is net margin × leverage. PnL is simply your notional times the percentage move in the oracle price from entry to exit, in your direction. Margin is isolated per position: the most you can ever lose is your margin.

net margin = deposit - openFee            (openFee = 0.08% of deposit x leverage)
notional   = net margin x leverage

Long  PnL = notional * (exit - entry) / entry
Short PnL = notional * (entry - exit) / entry

net close PnL = min(PnL, margin x 9)  -  funding  -  closeFee

At close, gross profit is capped first at 900% of your margin (the reserved margin × 9), then funding accrued since open is subtracted, and the 0.08% close fee is charged on your *adjusted size* (notional after realized PnL). The net result settles directly against the vault in USDG — it pays you if you won, or keeps your loss out of your margin and returns the rest if you lost.

Funding

Funding keeps the two sides balanced: the crowded side pays the underweight side. The rate is base × utilization × skew per second, where utilization is the market's open interest over its 2,000,000 USDG cap (clamped to 1) and skew is the normalized long/short imbalance (0 to 1). It runs from ~0.01%/hr at a fully utilized, fully skewed book down toward 0 as the book balances, and is hard-capped at ~0.1%/hr. It accrues continuously and is settled into your PnL at close (or at liquidation), always as a cost to the crowded side.

Liquidation and early close

Liquidation is permissionless: anyone can close an underwater position by submitting a signed price report to liquidatePosition. It is allowed only once the position's equity falls to or below the 10% maintenance margin — that is, a 90% loss on collateral. The liquidator is paid 5% of the position's collateral; the remaining collateral funds the LP loss buffer. No adverse spread is applied on the liquidation mark (it settles at the raw oracle price), and because margin is isolated, only the liquidated position is affected.

A position can also close early via take-profit or stop-loss. You set the trigger prices on-chain with setTpSl, and a keeper closes the position through executeCloseTrigger once the mark crosses one — no further action from you.

Key parameters

The oracle and the keeper

Prices come from a self-hosted EIP-712 signed-price oracle. The signing domain binds the chainId and the Diamond address, and each report binds the market, the price, and a publish time. Reports older than a 60-second max age are rejected, and a report dated meaningfully in the future — beyond a few seconds of clock-skew tolerance — is rejected too. It is 1-of-1 today — the keeper is the sole signer — with m-of-n signing across independent machines on the roadmap. Prices are sourced from a multi-source feed (Gate.io, then KuCoin, then CoinGecko as fallback) and signed in chain time, so a chain clock running behind wall-clock does not stale out fresh prices.

The keeper is an off-chain service that runs on a server, not on your machine. It watches for intents, take-profit/stop-loss triggers, and liquidatable positions, and fills, closes, or liquidates them by submitting signed prices. It is non-custodial and fully bounded by the on-chain guards: it can only ever fill at a verified price within your slippage tolerance and the liquidatable-at-open check, and it never holds your funds.

Architecture

Levant is an EIP-2535 Diamond — one contract address routes to many facets (trading, oracle, ownership), so every user action goes through a single entry point while the logic stays modular. Storage is append-only Diamond-Storage, ownership is ERC-173 two-step, and the contracts are built with Foundry on solc 0.8.28 with 171 passing tests. Upgrades are performed with diamondCut, which preserves the vault, LP shares, and all open positions.