Verified Enterprise Features
Our perpetual trading engine includes fully implemented, production-ready risk management:
| Component | Status | Implementation |
|---|---|---|
| Insurance Fund | Production Ready | Per-asset tracking with contribution/payout history |
| Auto-Deleveraging (ADL) | Production Ready | Rank-based selection with user indicators |
| Liquidation Engine | Production Ready | 5-second monitoring with partial liquidation |
| Cross Margin | Production Ready | Shared balance across positions |
| Isolated Margin | Production Ready | Dedicated margin per position |
| Funding Rates | Production Ready | 8-hour settlement with automatic payments |
| Mark Price Oracle | Production Ready | 6-exchange aggregation with outlier filtering |
These aren’t marketing claims - they’re verified through code audit and database analysis.
What is a Perpetual Trading Engine
A perpetual trading engine is the core system that powers cryptocurrency futures exchanges. Unlike spot trading engines that simply match buyers and sellers, perpetual engines must handle:
- Leveraged position management
- Continuous margin monitoring
- Automated liquidation processing
- Funding rate calculations
- Insurance fund operations
- Auto-deleveraging mechanisms
Our perpetual trading engine provides all these capabilities in a production-ready package.
Core Engine Components
Order Matching
The order book processes incoming orders with deterministic matching:
Matching Logic
- Price-time priority for fair execution
- Support for all order types (limit, market, stop, etc.)
- Immediate-or-cancel and fill-or-kill options
- Post-only flag for maker orders
- Reduce-only flag for closing positions
Order Management
- Real-time order status updates
- Partial fill handling
- Order amendment without losing queue position
- Bulk cancellation capabilities
Position Management
Positions are tracked and updated in real-time:
Position Tracking
- Entry price calculation (average cost basis)
- Unrealized and realized P&L
- Position size in contracts and notional value
- Liquidation price per position
- Margin allocation (cross or isolated)
Position Operations
- Open new positions (long or short)
- Add to existing positions
- Reduce or close positions
- Transfer margin between positions
Margin System
The margin system determines trading capacity and risk:
Margin Calculations
- Initial margin for opening positions
- Maintenance margin for holding positions
- Available margin for new orders
- Margin ratio (current margin / maintenance)
Margin Modes
- Cross margin pools all available balance
- Isolated margin dedicates funds per position
- Mode switching for existing positions
Liquidation Engine
Production-ready continuous monitoring protects platform solvency:
Liquidation Process
- Background worker monitors all positions every 5 seconds
- Compares mark price against calculated liquidation price
- Position locked for atomic updates when triggered
- 1.5% liquidation fee deducted from notional value
- Insurance fund receives surplus or covers deficit
- WebSocket events published for real-time updates
Partial Liquidation
- Enabled by default with 25% threshold
- Large positions liquidated incrementally
- Reduces market impact during volatility
- Gives traders time to add margin
- Configurable threshold per symbol
Insurance Fund
The insurance fund provides loss protection and is fully implemented:
Fund Operations
- Accumulates surplus from profitable liquidations (50% contribution rate)
- Covers negative equity when positions liquidate below bankruptcy price
- Prevents socialized losses - only triggers ADL when fund insufficient
- Per-asset balance tracking with complete audit trail
Fund Management
- Automatic contribution from liquidation surplus
- Automatic payout for negative equity coverage
- Admin dashboard for fund monitoring and injection
- Historical tracking with contribution/payout records
- Alert thresholds for low balance warnings
Auto-Deleveraging (ADL)
When insurance fund is insufficient, fully implemented ADL protects platform solvency:
ADL Mechanism
- Calculates ADL score: PnL Percentage × Position Leverage
- Ranks all opposing positions by score (highest first)
- Deleverages profitable positions to recover losses
- Closes at bankruptcy price of liquidated position
- Processes up to 10 positions per execution cycle
User Experience
- 0-5 light indicator showing ADL priority ranking
- Higher lights = higher chance of deleveraging
- Real-time WebSocket updates on ranking changes
- Notification after deleveraging occurs
Funding Rate System
Perpetual price convergence mechanism:
Rate Calculation
- Computed every 8 hours
- Based on premium/discount to spot index
- Clamp mechanisms prevent extreme rates
- Historical rate data available
Payment Processing
- Automatic collection from paying side
- Distribution to receiving side
- No platform fee on funding
- Applied to all open positions
Mark Price Oracle
Fair price for liquidation calculations:
Price Sources
- Aggregated from major spot exchanges
- Outlier filtering for manipulation resistance
- Time-weighted averaging
- Fallback mechanisms for outages
Usage
- Liquidation trigger price
- Unrealized P&L display
- Separate from last traded price
- Protects against wicks
Admin Capabilities
Symbol Configuration
- Create perpetual contracts
- Set leverage brackets
- Configure margin requirements
- Define position limits
- Enable/disable trading
Risk Dashboard
- Platform exposure monitoring
- Large position alerts
- Liquidation queue visibility
- Insurance fund status
- System health metrics
Manual Intervention
- Force-close positions
- Adjust user balances
- Modify leverage limits
- Pause trading markets
- Insurance fund injection
Integration APIs
Trading API
- Order placement and management
- Position queries
- Account balance information
- Trade history retrieval
Market Data API
- Real-time price streams
- Order book snapshots
- Recent trades feed
- Funding rate information
Admin API
- User management operations
- Symbol configuration
- Risk parameter adjustment
- Report generation
Performance Benchmarks and Stress Testing
The perpetual trading engine has been benchmarked under simulated market crash conditions to validate its behavior under extreme load:
| Metric | Normal Load | Peak Load (10x) | Stress Test (50x) |
|---|---|---|---|
| Order processing throughput | 5,000 orders/sec | 25,000 orders/sec | 50,000+ orders/sec |
| Order-to-trade latency | <3ms | <8ms | <15ms |
| Liquidation scan cycle | 5 seconds | 5 seconds | 5 seconds |
| Mark price update frequency | 1 second | 1 second | 1 second |
| WebSocket broadcast latency | <10ms | <50ms | <100ms |
| Concurrent open positions | 100,000+ | 100,000+ | 100,000+ |
The engine maintains liquidation scan consistency regardless of load — positions are evaluated every 5 seconds whether the system is processing 100 or 50,000 orders per second. This deterministic behavior is critical during cascading liquidation events when the engine is under maximum stress.
Failure Scenarios and Recovery
A production perpetual trading engine must handle every failure gracefully. Here’s how each scenario is managed:
Insurance fund depletion: If the insurance fund balance drops to zero during a liquidation cascade, the ADL (auto-deleveraging) system activates automatically. Profitable counter-positions are ranked by PnL % × leverage and closed against the bankrupt position. No losses are ever socialized across all users — only the specific ADL-targeted positions are affected.
Mark price oracle failure: If one or more of the 6 reference exchanges becomes unreachable, the mark price calculation excludes the unavailable source and continues with remaining exchanges. If fewer than 3 sources are available, the engine falls back to the exchange’s own last traded price with additional safety margins on liquidation thresholds.
Database failover: The engine writes all position and order state to the primary database with synchronous replication to a standby. On primary failure, the standby promotes automatically. No open positions are lost, no pending orders are dropped. The recovery time objective (RTO) is under 30 seconds.
Network partition: If the API layer loses connectivity to the matching engine, all new order submissions are rejected with a clear error message. Existing positions and pending orders remain intact. The system resumes normal operation automatically when connectivity is restored.
Real-World Example: Liquidation Cascade Walkthrough
Here’s a concrete example of how the engine processes a cascading liquidation event:
- Trigger: BTC/USDT drops from $60,000 to $54,000 (-10%) in 15 minutes
- Detection: Mark price updates catch the move within 1 second via 6-exchange median
- Scan: Liquidation engine identifies 847 positions below maintenance margin threshold
- Partial liquidation: 612 positions are partially liquidated (25% per cycle) — enough to bring them above maintenance margin
- Full liquidation: 235 positions require full liquidation at their bankruptcy prices
- Insurance fund: Absorbs $127,000 in losses (gap between liquidation and bankruptcy prices), fund balance remains positive
- ADL: Not triggered — insurance fund was sufficient
- Total time: 4 liquidation scan cycles (20 seconds) to process all 847 positions
- User notifications: All affected users received push notifications within 2 seconds of liquidation
Why Perpetual Contracts Dominate Crypto Derivatives
Perpetual futures contracts account for over 75% of all crypto trading volume globally — far exceeding spot markets. Unlike traditional futures that expire on specific dates, perpetuals have no expiry, making them the preferred instrument for both retail traders seeking leverage and institutional market makers seeking hedging tools.
For exchange operators, perpetuals represent the highest-revenue product per user. A trader using 20x leverage generates 20x the notional volume compared to the same trader in spot markets, dramatically increasing fee revenue. The funding rate mechanism (settled every 8 hours) creates an additional revenue stream that has no equivalent in spot trading — the exchange collects fees from every open position, whether the trader is actively trading or not.
The technical barrier to offering perpetuals is also the competitive moat. Building a reliable perpetual trading engine requires solving liquidation cascades, mark price manipulation resistance, insurance fund management, and auto-deleveraging — problems that take years of production testing to get right. Operators using Codono’s verified perpetual engine skip this development entirely and launch with infrastructure that has already survived real market crashes.
Deployment
The perpetual trading engine deploys alongside spot trading or as a standalone derivatives platform. It shares user accounts and wallet infrastructure with other Codono modules for a unified platform experience. The engine is included in all Codono licenses — contact us for a technical deep-dive or explore the live demo to see it in action.