docs: order book risk management

.gitbook/SUMMARY.md

@@ -5,6 +5,11 @@
   * [Wallet](defi/wallet/README.md)
     * [Create a wallet](defi/wallet/create.md)
     * [Accounts](defi/wallet/accounts.md)
+  * [Token Standards](defi/tokens/README.md)
+    * [INJ coin](defi/tokens/inj-coin.md)
+    * [Token Factory](defi/tokens/token-factory.md)
+    * [CW20 Standard](defi/tokens/cw20-standard.md)
+  * [Order Book](defi/order-book/README.md)
   * [Trading](defi/trading/README.md)
     * [Order Types](defi/trading/order-types.md)
     * [Trading Fees and Rebates](defi/trading/fees.md)
@@ -19,10 +24,6 @@
     * [Pre-Launch Futures](defi/trading/derivatives-pre-launch-futures.md)
     * [Index Perpetual Futures](defi/trading/derivatives-index-perpetual-futures.md)
     * [iAssets](defi/trading/derivatives-iassets.md)
-  * [Token Standards](defi/tokens/README.md)
-    * [INJ coin](defi/tokens/inj-coin.md)
-    * [Token Factory](defi/tokens/token-factory.md)
-    * [CW20 Standard](defi/tokens/cw20-standard.md)
   * [Bridge](defi/bridge/README.md)
     * [From Ethereum](https://blog.injective.com/en/how-to-bridge-from-ethereum-to-injective-using-metamask/)
     * [From Solana](https://blog.injective.com/en/how-to-bridge-from-solana-to-injective-using-phantom/)

.gitbook/defi/order-book/README.md

@@ -0,0 +1,14 @@
+# Central Limit Order Book (CLOB)
+
+The cryptocurrency industry is experiencing a renewed fascination with Central Limit Order Books (CLOBs). Across crypto social media, research reports, and development communities, on-chain orderbook infrastructure has emerged as one of the most discussed topics of 2024 and 2025. New projects are launching with significant fanfare, promising to bring "institutional-grade" trading experiences to decentralized finance. Venture capital is flowing toward CLOB-focused startups, and the narrative has crystallized around the idea that on-chain orderbooks represent the next evolutionary leap for decentralized exchanges: a sophisticated alternative to the Automated Market Maker (AMM) model that has dominated DeFi since Uniswap's rise.
+
+Yet this narrative treats on-chain CLOBs as a recent innovation, with most discourse focusing on newly-launched projects. The industry speaks of "pioneering" new approaches to orderbook infrastructure, connoting that the concept of on-chain CLOB infrastructure is being invented for the first time. This framing, while understandable given the current hype cycle, obscures a crucial historical reality.
+
+Injective has been operating a decentralized, fully on-chain CLOB infrastructure since its inception. Founded in 2018 and incubated by Binance Labs that same year, Injective launched with comprehensive orderbook functionality supporting spot trading, perpetual futures, expiry futures, and binary options markets. For seven years, Injective has been quietly solving the technical challenges that the broader crypto community has only recently begun to grapple with.
+Most CLOB-based projects emerging on the scene face fundamental constraints, as they are built within virtual machine (VM) environments. These solutions, whether on Ethereum, Solana, Aptos, Sui, or other execution environments, suffer from gas economics, computational overhead, and architectural boundaries. Additionally, many implementations rely on Layer-2 scaling, off-chain components, or hybrid architectures that compromise the decentralization that motivated moving away from centralized exchanges. 
+
+To be fair, Injective is not the only project to recognize these architectural limitations. Hyperliquid, which launched in 2022 and has captured massive attention in the current CLOB narrative, has also built a custom L1 to avoid VM constraints. However, it employs a dual architecture, splitting state execution between HyperCore and HyperEVM, introducing development complexity and performance implications for applications hoping to leverage the CLOB.
+
+Injective's approach is fundamentally different: implementing orderbook functionality as a native blockchain module rather than an application layer. This enables permissionless plug-and-play access for any application built on Injective, eliminating cross-layer complexity while executing sophisticated financial operations without gas optimization constraints or architectural compromises.
+
+This paper provides a comprehensive examination of Injective's on-chain CLOB infrastructure, explaining both how it works and why its architectural approach offers inherent advantages over alternative implementations. We will explore the Exchange module's (Injective’s CLOB infrastructure) design, detail its key innovations such as the Frequent Batch Auction mechanism for front-running prevention, and analyze how chain-level implementation enables capabilities that remain difficult or impossible to achieve within virtual machine environments. By understanding Injective's technical architecture, we can better appreciate both its significance as the original on-chain CLOB implementation and its strategic positioning as the crypto industry rediscovers the power of decentralized orderbook infrastructure.

.gitbook/defi/order-book/risk-management.md

@@ -0,0 +1,75 @@
+# Risk Management & Margin System in Injective CLOB
+
+Sophisticated trading systems require equally sophisticated risk management capabilities. Injective's Exchange module implements comprehensive risk controls through native blockchain functions, enabling real-time position monitoring, automated liquidations, and system-wide risk protections that would be difficult or impossible to coordinate across multiple smart contracts.
+
+## Margin System Architecture
+
+The Exchange module supports both cross-margin and isolated margin modes, allowing traders to choose the risk profile that best suits their trading strategy. In cross-margin mode, all positions within a subaccount share the same margin pool, enabling profits from one position to support losses in another. This capital-efficient approach allows traders to maintain larger overall positions while reducing the likelihood of individual position liquidations.
+
+Isolated margin mode operates differently, allocating specific margin amounts to individual positions. This approach limits the risk exposure of each position to its allocated margin, preventing losses in one position from affecting others. Traders often use isolated margin for speculative positions or when testing new trading strategies with limited downside risk.
+
+The margin calculation system operates continuously, updating position values and margin requirements with each new block. Unlike smart contract implementations that might require external calls to update position health, the native module approach enables real-time margin monitoring without additional transaction costs or latency.
+
+## Real-time Position Monitoring
+
+Position health monitoring represents one of the most critical functions of any derivatives trading system. The Exchange module continuously tracks unrealized profit and loss for all open positions, comparing current mark prices from the Oracle module against entry prices to determine real-time position values.
+
+<!-- The system calculates maintenance margin requirements based on position size, market volatility, and other risk factors. -->
+As positions move against traders, the system monitors when available margin approaches maintenance requirements. This monitoring occurs automatically with each block, ensuring that position health assessments remain current even during periods of high market volatility.
+
+<!-- When positions approach liquidation thresholds, the system can provide early warnings through standard interfaces, allowing trading applications to alert users or implement automated risk reduction strategies. -->
+This real-time monitoring capability stems directly from the native module implementation, which can access and process position data without the overhead of cross-contract communication.
+
+## Liquidation Engine
+
+The liquidation engine operates as an integrated component of the Exchange module, automatically triggering position closures when margin requirements can no longer be met. Unlike systems that rely on external liquidation bots or manual intervention, Injective's liquidation process occurs deterministically through blockchain state transitions.
+
+When a position falls below maintenance margin requirements, the liquidation engine automatically places market orders to close the position at the best available prices in the orderbook.
+<!-- The system prioritizes minimizing losses to both the position holder and the broader system, using sophisticated algorithms to determine optimal liquidation sizes and timing. -->
+
+For large positions that might affect market prices significantly, the liquidation engine can implement partial liquidations, closing only enough of the position to restore adequate margin levels. This approach minimizes market impact while protecting system stability. The atomic nature of blockchain transactions ensures that liquidation processes either complete successfully or fail entirely, preventing partial executions that could leave positions in inconsistent states.
+
+## Insurance Fund Operations
+
+The insurance fund serves as the backstop for the entire derivatives system, absorbing losses that exceed position margin when liquidations cannot cover full deficits. The Exchange module integrates tightly with the Insurance module to manage fund contributions, deficit coverage, and socialized loss distribution.
+
+During normal operations, the insurance fund accumulates contributions from trading fees and liquidation surpluses. When liquidations result in deficits (typically during extreme market conditions where positions cannot be closed at favorable prices), the insurance fund automatically covers these shortfalls to prevent socialized losses among other traders.
+
+The native module integration enables sophisticated insurance fund management policies. For example, the system can automatically adjust contribution rates based on current fund levels, market volatility, or other risk factors.
+<!-- During extreme stress scenarios, emergency protocols such as modified liquidation parameters or temporary trading restrictions can be implemented [TBD - governance vs automated mechanisms], with changes coordinated atomically across all native module functions. -->
+
+## Cross-Portfolio Risk Management
+
+One of the significant advantages of implementing risk management at the native module level is the ability to assess and manage risk across entire portfolios rather than individual positions.
+<!-- The system can calculate portfolio-level value-at-risk, implement position concentration limits, and coordinate risk controls across different market types. -->
+
+For example, a trader with both spot and futures positions in the same underlying asset can benefit from portfolio-level margin calculations that recognize natural hedging relationships.
+<!-- The system can also implement sophisticated risk controls such as maximum leverage limits per asset class, concentration limits to prevent over-exposure to individual markets, and dynamic risk adjustments based on market conditions. -->
+
+This portfolio-level risk management extends to applications built on Injective.
+<!-- Trading platforms can leverage the Exchange module's risk calculation functions to implement custom risk controls, portfolio optimization algorithms, or automated risk reduction strategies that operate across multiple positions and market types simultaneously. -->
+
+<!-- ## Circuit Breakers & Emergency Controls
+
+The Exchange module implements various circuit breaker mechanisms to protect against extreme market conditions or system anomalies. [TBD - specific details on automated vs governance-controlled emergency measures, price movement limits, volume-based circuit breakers, and system-wide emergency controls]
+
+Unlike external circuit breaker systems that might require coordination across multiple components, Injective's native implementation can coordinate emergency protocols uniformly across all markets and position types. This ensures consistent protection and prevents arbitrage opportunities that might arise from inconsistent emergency responses across different system components. -->
+
+## Integration with Oracle Infrastructure
+
+Risk management quality depends heavily on accurate and timely price data. The Exchange module's integration with Injective's Oracle module ensures that position valuations, margin calculations, and liquidation triggers use consistent, high-quality price feeds across all operations.
+
+The Oracle module aggregates price data from multiple sources and applies sophisticated filtering and validation algorithms to ensure price feed integrity. This integration occurs at the native module level, eliminating the latency and reliability concerns that might affect smart contract-based systems that must make external oracle calls for price updates.
+
+<!-- During extreme market conditions when oracle price feeds might become unreliable or stale, the risk management system can implement fallback procedures such as using alternative price sources, widening liquidation thresholds, or implementing temporary trading restrictions. These emergency procedures activate automatically through native module logic without requiring external intervention or coordination. -->
+
+## Advantages of Native Implementation
+
+The native module approach provides several crucial advantages for risk management compared to smart contract implementations. First, all risk calculations and controls operate without gas cost constraints, enabling sophisticated algorithms and frequent updates that would be economically prohibitive in virtual machine environments.
+
+Second, the atomic execution guarantees of blockchain transactions ensure that complex risk management operations either complete entirely or fail entirely. This eliminates scenarios where partial executions might leave the system in inconsistent or vulnerable states.
+
+<!-- Third, the integration between risk management and other protocol functions enables coordinated responses to emergency situations. For example, a large liquidation event can automatically trigger insurance fund distributions, adjust system-wide risk parameters, and activate emergency protocols through a single set of coordinated transactions. -->
+
+Finally, the deterministic nature of native module execution ensures that all network validators apply identical risk management policies, eliminating potential disputes about liquidation timing, or margin calculations. <!--, or emergency procedure activation. -->
+This consistency is crucial for maintaining trader confidence and system integrity during stressful market conditions.