Skip to content

Filter

The Filter is an essential part of the XCore and has to be configured carefully. Its purpose is to derive a clean stream of bid and ask prices from the configured liquidity sources (makers). Those filter bid and ask prices are then published into other components like for example the Account where they are used in calculations (pnl, margin, exposure) or the LiquidityPool where they are used as reference to correct or remove off market prices. The filter operates in two stages:

STAGE_1: This stage analyzes prices from makers based on most recent valid filter prices as well as historical market data. Prices that surpass the constraints set by both the tolerance and factor_1 are considered invalid by this filter stage and are excluded from further calculations in the current iteration. Invalid prices may recover in subsequent iterations. This filter stage can operate on any number of makers including a single maker, but becomes less relevant as the number of makers increases.

STAGE_2: This stage analyzes prices from makers based on standard deviation calculations on the most recent maker prices. Prices that surpass the constraints set by both the tolerance and factor_2 are considered invalid by this filter stage and are excluded from further calculations in the current iteration. Invalid prices may recover in subsequent iterations. This filter stage requires at least two makers and becomes more reliable as the number of makers increases.

Maker prices that pass both filter stages are used to create the filter_output which consists of:

  • filter_avg_bid, filter_avg_ask: The most recent average bid or ask price derived from all valid maker prices. Jointly referred to as filter_avg.
  • filter_best_bid, filter_best_ask: The most recent best bid or ask price derived from all valid maker prices. Jointly referred to as filter_best.
  • filter_worst_bid, filter_worst_ask: the same calculation on bottom-of-book prices; liquidity pools use it to clamp their reference price (see Liquidity Pool).
  • filter_delta: A calculated value that represents an estimation of the upper limit of valid price movement under current market conditions, derived from both current and historical market data.

Additional terms are defined as follows:

  • makers_avg: The current average bid or ask price, calculated from the valid makers' prices
  • maker_price: The current ToB price offered by an individual maker.

The Filter is configured by the below attributes via pending config.

attributes required default settings attribute type description
securities Y * VARCHAR Name pattern of the securities. This parameter can include a comma-separated list and may also use “*” as a wildcard.
symbols Y * VARCHAR Name pattern of the symbols. This parameter can include a comma-separated list and may also use “*” as a wildcard.
priority Y 1 INT The priority of the current row. If a symbol matches the securities and symbols pattern of more than one row then the configuration with the higher priority (bigger integer number) will be applied for this symbol.
tolerance Y 10 INT Minimum price-deviation allowance used when calculating the limits for STAGE_1 and STAGE_2, expressed in symbol.price_unit units.

Allowed values: -1 or an integer >= 1.

Setting -1 bypasses both price-deviation checks. Other source-validity checks remain.
factor_1 Y 5 DOUBLE Dimensionless sensitivity multiplier for STAGE_1, which checks maker-price moves against the recent filter reference and price history. It works together with the minimum allowance from tolerance; the full limits also depend on reference state and rounding.

Allowed values: -1 or a number >= 0. Setting -1 disables STAGE_1. Zero keeps the check enabled.
factor_2 Y 2 DOUBLE Dimensionless sensitivity multiplier for STAGE_2, which checks price outliers among the selected makers. It works together with the minimum allowance from tolerance; the full limits also depend on reference state and rounding.

Allowed values: -1 or a number from 2 to 3. Setting -1 disables STAGE_2.
makers Y – VARCHAR Name pattern of the makers (providers). This parameter can include a comma-separated list and may also use “*” as a wildcard. At least one configured provider must be selected when providers exist, even when tolerance is -1; an empty selection fails startup.

Both security and symbol patterns must match. The highest-priority matching row supplies the complete configuration; settings are not merged across rows. Cover every configured symbol, including inactive symbols, and use distinct priorities for overlapping rules.

Name patterns are case-sensitive, ordered comma-separated alternatives. * is a wildcard and a leading ! excludes a match. The first matching token decides: !ABC,* excludes ABC, while *,!ABC admits it. Use actual configured names and avoid spaces after commas.

Tolerance and filter limits

For a positive tolerance, the minimum allowance is tolerance × symbol.price_unit. For example, tolerance 2 with a price unit of 0.00001 gives an allowance of 0.00002.

The allowance is one part of the limit calculation:

  • STAGE_1 uses the recent filter reference, price history and factor_1.
  • STAGE_2 uses the prices from the selected makers, reference state and factor_2.

The resulting limits also depend on price rounding. Bids and asks are evaluated separately. With other conditions unchanged, a larger tolerance generally makes the checks more permissive. A price difference alone does not determine whether a maker's price will be rejected.

With tolerance -1, XCore still calculates the reference feed and applies separate source-validity checks. Liquidity pools have their own filtering settings; this value does not bypass every liquidity-pool check.

The filter log records prices rejected by STAGE_1 and STAGE_2 and can help when reviewing the settings.