Perpetual Contracts

Non-custodial leverage trading up to 100x — with oracle-grade pricing, autonomous funding, and liquidation that can't be front-run.

Core Insight

Long = Bid. Short = Ask. A perpetual contract is just an orderbook with margin-aware settlement. The matching engine is identical to spot — what changes is what happens after the match: margin locks replace asset swaps, mark price replaces last trade, and funding payments keep the contract tethered to reality.

Why On-Chain Perpetuals?

Perpetual contracts are the highest-volume instrument in crypto — often exceeding spot volume by 3-5x. Yet every major perps venue has the same fundamental problem: trust.

Centralized exchanges (Binance, Bybit) hold custody of funds and can manipulate liquidation. Decentralized alternatives solve custody but introduce new trade-offs — MEV extraction, keeper dependencies, and oracle vulnerabilities.

Vortum eliminates all three.

	CEX (Binance)	dYdX v4	Hyperliquid	Vortum
Custody	Exchange holds funds	Self-custodial	Self-custodial	Self-custodial
Orderbook	Off-chain	Off-chain (Cosmos appchain)	On-chain (own L1)	On-chain (ICP canister)
Oracle	Internal	Multi-source (Slinky)	Validator-run	Multi-source median via HTTPS outcalls
Liquidation	Opaque	Validators	Validators	Canister-executed, deterministic
MEV	Operator advantage	Validator ordering risk	Validator ordering risk	No mempool, no front-running
Funding settlement	Centralized	Validator consensus	Validator consensus	Canister timer — autonomous
Multi-chain deposits	Yes (custodial)	Bridge required	Bridge required	Native via Chain Fusion
Cross-margin with spot	Yes	Perps only	Spot available, margin separate	Unified — one engine, one account

The ICP Advantage

dYdX built a Cosmos appchain with off-chain orderbook matching on validators. Hyperliquid built an entirely custom L1 with its own consensus protocol. Both required launching and securing a new blockchain just to run a derivatives exchange. Vortum achieves fully on-chain matching on ICP — with native multi-chain settlement included. No custom chain, no validator set to bootstrap, no bridge infrastructure.

Architecture

One Engine, Two Settlement Modes

A perpetual market is an orderbook — the same order types (Market, Limit, Stop), time-in-force options (GTC, GTD, IOC, FOK), and self-trade prevention all carry over from spot. The difference is entirely in settlement: spot trades swap assets, perpetual trades adjust margin positions.

Markets
├── BTC_USDC          → Spot orderbook
├── BTC_USDC_PERP     → Perpetual orderbook (same engine)
├── ETH_USDC_PERP     → Perpetual orderbook
└── SOL_USDC_PERP     → Perpetual orderbook

Five perpetual-specific systems layer on top of the existing matching engine and settlement infrastructure:

This is the same pattern used for lending (settlement creates loan positions) and predictions (settlement locks outcome collateral). Each new product extends the settlement layer — the matching engine and risk infrastructure are shared.

Mark Price & Index Price

Index Price

The index price reflects true spot value, aggregated from multiple independent sources via ICP's native HTTPS outcalls:

Source Type	Examples	Method
CEX APIs	Binance, Coinbase, Kraken	HTTPS outcalls
DEX aggregators	Jupiter, CoinGecko	HTTPS outcalls
On-chain feeds	Pyth, Chainlink	HTTPS outcalls to price endpoints

The canister takes the median across all sources — no single oracle can be manipulated to move the index.

Mark Price

Mark price blends the index with the contract's current premium, smoothed by a decay factor:

Mark Price = Index Price + Decayed Basis

Where:
  Basis = Contract Mid Price − Index Price
  Decayed Basis = Basis × decay_factor

Every critical decision — margin health, liquidation triggers, unrealized PnL — uses the mark price rather than the last traded price. This prevents liquidation by wick: a single aggressive trade on a thin book cannot trigger cascading liquidations.

No MEV on Oracle Updates

On Ethereum, oracle price updates are public transactions that MEV bots front-run for profit. On ICP, the canister fetches prices directly via HTTPS outcalls — no mempool exposure, no front-running opportunity, no value extraction from oracle updates.

Margin System

Isolated & Cross Margin

Traders choose their risk profile per position:

Mode	Mechanics	Trade-off
Isolated	Each position has its own dedicated margin	Losses contained to that position's collateral
Cross	All positions draw from a shared margin pool	Higher capital efficiency — gains offset losses across positions

Cross margin becomes especially powerful in a unified platform — unrealized gains from a spot position or lending yield can offset perpetual margin requirements. This is the kind of capital efficiency that fragmented DeFi can't offer.

Initial & Maintenance Margin

Two thresholds govern every position:

Margin Type	Purpose	Example (10x)
Initial Margin (IM)	Required to open a position	10% of notional
Maintenance Margin (MM)	Required to keep a position open	5% of notional

Opening a $100,000 BTC-PERP position at 10x:

  Initial Margin:      $10,000  (10% × $100K)
  Maintenance Margin:   $5,000  (5% × $100K)

  Margin Ratio = Account Equity / Position Notional
  Liquidation triggers when Margin Ratio < Maintenance Margin %

Leverage Tiers

Maximum leverage scales inversely with position size — retail-friendly access at smaller sizes, institutional-grade risk controls at larger ones:

Position Size	Max Leverage	Initial Margin
< $50K	100x	1%
$50K – $250K	50x	2%
$250K – $1M	20x	5%
$1M – $5M	10x	10%
> $5M	5x	20%

Funding Rate

The Price Anchor

Funding is a periodic payment between longs and shorts that keeps the contract price aligned with the index:

• Contract trading above index → positive funding → longs pay shorts → incentive to sell
• Contract trading below index → negative funding → shorts pay longs → incentive to buy

Rate Calculation

Funding Rate = Clamp(Premium Index + Interest Rate, -0.75%, +0.75%)

Where:
  Premium Index = (Contract TWAP − Index TWAP) / Index Price
  Interest Rate = 0.01% per interval (base rate)

The TWAP (time-weighted average price) resists spot-price spikes. Clamping at ±0.75% prevents extreme payouts during volatile periods.

Autonomous Settlement

On Ethereum, funding settlement requires external keeper bots — infrastructure that must be incentivized, monitored, and trusted to stay online. On Vortum, the canister settles funding autonomously:

• Automatic: Canister timer fires every 8 hours — no external dependency
• Atomic: All positions settled in a single execution — no partial or inconsistent state
• Transparent: Every payment recorded with full audit trail

Liquidation

Protocol-Executed, Not Bot-Raced

When a position's margin ratio falls below maintenance, the canister liquidates it directly — no external bots compete for the privilege. Liquidation follows a graduated cascade designed to minimize trader impact while protecting the system:

Step	Trigger	Action
Partial liquidation	Margin ratio drops below MM	Close 25-50% of position at mark price
Full liquidation	Still below MM after partial	Close entire position
Auto-deleveraging (ADL)	Position goes to negative equity	Reduce most profitable opposing positions
Insurance fund	ADL insufficient	Cover shortfall from protocol reserve
Socialized loss	Insurance fund depleted	Distribute remaining loss across profitable positions

On Ethereum, liquidation is a race — MEV bots compete to liquidate first, extracting value from distressed traders. On ICP, there is no mempool. The canister determines the outcome, and every liquidation is logged with full transparency.

Insurance Fund

The insurance fund absorbs losses when liquidated positions go underwater — the critical backstop that separates robust exchanges from fragile ones.

	Details
Funded by	Liquidation penalties, trading fee allocation, protocol revenue
Triggered when	A liquidated position's loss exceeds its posted margin
Purpose	Prevent socialized losses from reaching profitable traders

Without a healthy insurance fund, a single black swan event can cascade into socialized losses across all traders. The fund is continuously replenished from protocol revenue, creating a growing buffer over time.

Risk Controls

Control	Purpose
Position limits	Cap individual exposure per user per market
Open interest caps	Limit total market-wide exposure
Leverage tiers	Scale down max leverage as position size grows
Price bands	Reject orders deviating too far from mark price
Circuit breakers	Halt trading on extreme moves (>10% in 5 minutes)
Funding rate caps	Clamp to ±0.75% per interval to prevent extreme payouts
Margin requirements	Tiered initial and maintenance margin by position size

All controls are configurable per market. A liquid BTC-PERP market can support 100x leverage with wide price bands, while a nascent market might cap at 20x with tighter guardrails.

Fee Model

Fee	Amount	Paid By	Purpose
Taker fee	0.05%	Taker	Trading revenue
Maker fee	0.02%	Maker	Trading revenue (or rebate)
Funding payment	Variable	Longs or shorts	Contract-index price convergence
Liquidation penalty	1-5%	Liquidated trader	Insurance fund contribution

Maker fees can go negative (rebates) on specific markets to incentivize liquidity provision and tighter spreads.

Challenges

Challenge	Approach
Oracle reliability	Multi-source median pricing; mark price smoothed via decayed basis
Liquidation cascades	Graduated approach (partial → full → ADL) avoids cliff-edge events
Funding rate manipulation	TWAP-based calculation resists spot spikes; rate clamped to ±0.75%
Insurance fund capitalization	Seeded from protocol treasury; continuously replenished from fees and penalties
High-leverage risk	Tiered leverage limits inversely proportional to position size; circuit breakers on extreme moves
Oracle latency	ICP's 1-2s consensus sufficient for 8-hour funding intervals; sub-second not required
Liquidity bootstrapping	Unified engine means spot market makers can extend to perps with minimal additional effort