Market Parameters and Controls Schedule
Updated: 9 May 2026
1. Status of these rules
1.1 This Market Parameters and Controls Schedule forms part of the Trading Rules incorporated into the Terms of Use.
1.2 This schedule describes categories of market parameters, controls, limits, thresholds, and operational settings that may apply to the Application or Derive Protocol. Specific values may be published in the Application, documentation, API documentation, governance dashboard, risk dashboard, or other live parameter service. Some parameters and controls operate at the Application layer and may be set or modified by us. Others operate at the protocol level and may require governance decisions, smart contract updates, or DAO-approved processes to implement or change. Parameters shown on this page may be updated dynamically and may differ by market, account, instrument, expiry, collateral type, trading mode, user type, market condition, or risk state. Where available, this page should link to or render live values for open interest caps, RFQ bands, orderbook price bands, API limits, market maker protection limits, oracle-distance controls, margin parameters, liquidation parameters, and settlement parameters. Where there is inconsistency between this page and live values displayed in the Application, API, governance dashboard, risk engine, or other live parameter service, the live values may prevail.
2. Parameters and controls
2.1 Parameters and controls may include RFQ price bands, orderbook price bands, maximum RFQ size, maximum order size, minimum order size, tick size, contract specifications, expiry settings, near-expiry controls, open interest caps, position limits, account limits, subaccount limits, collateral limits, margin parameters, liquidation parameters, settlement parameters, oracle parameters, oracle-distance controls, API rate limits, quote-to-fill ratios, RFQ-to-trade ratios, order-to-volume ratios, cancellation limits, message rate limits, market maker protection settings, kill switches, quote exhaustion limits, max delta limits, max loss limits, and other settings.
2.2 Different parameters and controls may apply by market, product, instrument, expiry, collateral type, account, subaccount, user, liquidity provider, market maker, API user, transaction type, jurisdiction, risk profile, market condition, or other relevant criteria.
3. Updates and discretion
3.1 We may set, update, suspend, replace, widen, narrow, disregard, or apply fallback parameters or controls where we reasonably consider this necessary or appropriate through available Application functionality and where applicable through protocol governance, smart contract mechanics, risk parameters, or governance-approved processes for market integrity, liquidity, risk management, technical operation, settlement, liquidation, security, compliance, oracle operation, abnormal market conditions, or orderly operation.
3.2 Parameter changes may be made prospectively, immediately, temporarily, during a Fast Market or Disrupted Market, or as part of a Mistrade, Erroneous Transaction, market integrity, oracle, settlement, liquidation, or emergency process.
3.3 We are not required to disclose confidential parameters, thresholds, risk criteria, surveillance criteria, security settings, compliance criteria, market maker settings, or internal controls where disclosure could compromise security, market integrity, legal compliance, financial crime prevention, orderly operation, or risk management. We will not invoke this section 3.3 to withhold from a participant the general category of parameter or control that has been applied to their account, market access, or transactions, where we are reasonably able to provide that general category without compromising specific confidential criteria or processes.
4. No guarantee
4.1 No parameter, control, limit, threshold, market maker protection setting, price band, rate limit, risk check, margin check, oracle check, or other control guarantees that losses, Mistrades, Erroneous Transactions, disorderly trading, excessive activity, liquidation, settlement disruption, or other issues will be prevented, limited, cancelled, adjusted, or reversed. This applies whether the relevant parameter or control operates at the Application layer or the protocol level, and whether any failure to prevent, limit, or reverse an issue results from a technical failure, operational failure, governance delay or failure, or other cause.
