DEV Community: Dream

Put Factors Under Continuous Evaluation: Implementing the APFF Multi-Asset Perpetual Strategy on FMZ

Dream — Wed, 09 Sep 2026 09:15:16 +0000

Writing a momentum factor is not difficult. Writing a mean-reversion factor is not difficult either. The real hesitation begins when two factors give opposite opinions today: which one should the capital listen to? If a factor performs poorly for a while, should its weight be reduced, should it be temporarily disabled, or should its direction be reversed? And why should a newly discovered formula be allowed to control real positions at all?

These questions are difficult to solve simply by adding more indicators. The more factors a system has, the more it needs a unified set of rules for evaluating and using them.

APFF stands for Adaptive Perpetual Factor Factory. It is a multi-asset adaptive factor-factory strategy for perpetual futures. The system compares relative strength across a group of perpetual contracts, combines a small number of interpretable factors into a long-short portfolio, continuously records each factor's forward performance, gradually adjusts factor weights, and requires new candidates to pass through observation and small-weight trials before they can receive meaningful capital.

This article is based on the repaired and runnable FMZ JavaScript implementation. It walks through the full process from data and factors to actual orders. The corresponding version is v0.1.0, build 20260905-05, research-definition version 2. Current live-running and simulation tests have validated the main engineering workflow, while long-term return performance still requires further out-of-sample evidence.

1. First Turn the Trading Problem Into “Who Is Relatively Stronger?”

At every decision point, APFF works with a cross-section: a group of different contracts observed at the same time.

Suppose two baskets each start with 3,000 USDT of notional exposure. One basket is long and the other is short. Ignoring fees, funding, and rebalancing for the moment, if the long basket rises 4% while the short basket rises 1%, the price PnL is:

Long-basket profit = 3,000 × 4% = 120 USDT
Short-basket loss  = 3,000 × 1% =  30 USDT
Total PnL          = 120 - 30   =  90 USDT

If the long basket falls 2% while the short basket falls 5%, the price PnL can still be positive when both sides have the same notional size. The point is that a long-short portfolio cares about the return spread between two groups of assets.

But similar long and short notionals do not eliminate market risk. If the long side is concentrated in high-volatility assets while the short side is concentrated in low-volatility assets, a sudden market decline can still produce a severe imbalance between the two sides. For that reason, APFF adds volatility scaling, per-symbol caps, and a limited BTC beta hedge on top of relative-strength ranking.

The system operates on several different time scales:

Market data needs to be timely, but factor weights should move more slowly. Recomputing weights every time the order book ticks would turn a medium/low-frequency portfolio into a noise-chasing rebalancing system.

2. The Trading Universe Determines What the Factors Are Comparing

The current version supports only Binance USDⓈ-M USDT linear perpetual futures, with a default universe size of 30 symbols.

The program reads contract specifications through GetMarkets, while GetTickers and live market data are used to maintain volume, price, and spread information. The base filters include contract trading status, valid quotes, spread limits, and a 90-day listing-age requirement when listing time is available. Eligible contracts are then ranked by current 24-hour trading volume.

A ranking buffer is used to reduce unnecessary membership turnover. By default, an existing member is preferentially retained as long as it remains within the top 40 eligible contracts. The remaining slots are filled with the highest-ranked alternatives. This prevents two contracts with similar volume from repeatedly entering and leaving the portfolio merely because they swap daily ranking positions.

BTC is treated separately as the market benchmark and hedging instrument. Even if it is included in the trading universe, it is excluded from the ordinary alpha ranking. Actual portfolio decisions also require at least 15 non-BTC symbols that pass the data checks. The configured universe size and the number of symbols that are actually usable must therefore be treated as separate quantities.

This implementation has clear boundaries. The current version uses 24-hour trading volume and basic filters. The reference design's 30-day average volume, historical point-in-time universes, continuous-data completeness filters, and order-book-depth filters have not yet been fully implemented. If listing time is missing, the code also cannot independently prove that a contract has been listed for at least 90 days. These differences should be kept in mind when evaluating strategy results.

3. Five Seed Factors, Each Representing a Testable Hypothesis

The first set of seed factors comes from five families: momentum, reversal, funding, premium, and open interest.

In the table below, RET denotes log price return; RV denotes the sample standard deviation of 4-hour log returns within the corresponding window, not annualized volatility; and Z_TS denotes a time-series z-score computed separately for each symbol.

The price-direction term in the OI factor is +1 when the 24-hour return is non-negative and -1 when it is negative. These interpretations are research hypotheses; whether they hold must be answered by mature samples. For example, “high funding” does not mean price must fall immediately. Crowded trades can persist for a long time.

The core of the momentum factor can be seen directly in the source code:

var full = returnBars(prices, p.longBars)
var recent = returnBars(prices, p.skipBars)
var rv = realizedVol(prices, p.longBars)
return finite(full) && finite(recent) && rv > 0
    ? direction * (full - recent) / rv
    : NaN

The seed parameters use 42 four-hour candles to represent seven days and skip the most recent candle. Invalid data returns NaN and is then excluded from the valid-value set.

Funding Must First Be Put on a Common Time Scale
Funding settlement intervals can differ across records. The current implementation uses the observed settlement interval to normalize funding rates to a common 8-hour scale before computing time-series z-scores. The seed factor uses roughly 30 days of history and also checks whether historical coverage is sufficient and whether the most recent record is fresh enough.

The current-period funding rate and historical settled funding rates must also be kept separate. FMZ's GetFundings provides funding-rate data for the current period. APFF stores it as current-period information, while research returns and settlement accounting use separate historical records. See the FMZ GetFundings documentation.

Binance's /fapi/v1/fundingRate history endpoint provides fundingTime, fundingRate, and the markPrice associated with each funding settlement. This is the basis used by the current implementation to calculate historical funding cash flows. See the Binance USDⓈ-M Futures market-data documentation.

Premium and OI Require Careful Attention to Data Sources
In production, the Premium factor uses historical Premium Index Klines from the exchange. In simulation, the system gradually accumulates a proxy snapshot series based on Mark / Index - 1. The two series are not defined identically, so factor performance observed in the simulated environment cannot be directly treated as evidence for production performance.

Production OI history only accepts the quote-currency notional-value definition. Simulated snapshots are accumulated from available open-interest quantity and price data, then stored in 4-hour time buckets. This avoids accidentally treating six minute-level snapshots as six independent 4-hour observations.

If auxiliary history is insufficient, the corresponding factor can remain unavailable temporarily. For a system designed to run for a long time, explicitly knowing that “this factor does not yet have enough data” is more meaningful than forcing the program to produce a number.

4. Put Every Factor on a Common Ranking Scale So They Can Vote Together

The five raw factors have different units and cannot be added directly. APFF processes each factor cross-sectionally: invalid values are filtered out, the remaining values are winsorized at the 5th and 95th percentiles, and ranks are then mapped to [-1, +1].

If ranks start at 0, the mapping is:

Normalized score = 2 × rank / (number of valid symbols - 1) - 1

The highest score represents the symbol most favored by the factor, while the lowest score represents the least favored one. Equal raw values receive the average rank. If the entire cross-section has no meaningful variation, the factor is treated as invalid so that array ordering cannot manufacture a signal out of nothing.

A single factor must cover at least 80% of the symbols in the current round. When the combined alpha score is formed, each individual symbol must also have coverage from at least 80% of the currently valid factor weight. These two checks separately control whether a factor has enough cross-sectional information and whether a particular symbol has enough combined information.

For a symbol that passes the checks, the combined score is:

Alpha_i = Σ(available factor weight_j × normalized score_ij)
          / Σ(available factor weight_j for symbol i)

This score determines relative ranking. How much capital the portfolio is allowed to use depends on another quantity: the amount of factor budget that is actually available.

5. If Two Factors Are Missing, Why Should Total Exposure Shrink Too?

The five initial seed factors each receive a 20% budget. Suppose momentum, reversal, and funding are available, while Premium and OI have not yet accumulated enough history. The effective factor budget is then:

20% + 20% + 20% = 60%

If the remaining three factors are rescaled to 33.33% each, their weights sum back to 100%, but the same portfolio is now supported by less information and each factor is implicitly carrying more risk.

APFF preserves the original budget meaning of each factor and leaves the unallocated portion idle. The initial gross notional budget is calculated as:

Gross notional budget = account equity
                      × configured gross-exposure ratio
                      × selector confidence factor
                      × sum of effective factor budgets
                      × drawdown scaling factor

Consider an example used only to explain the arithmetic. Account equity is 10,000 USDT, configured gross exposure is 60%, the sum of effective factor budgets is 60%, and both the confidence factor and drawdown factor are 1:

Gross notional budget = 10,000 × 60% × 1 × 60% × 1
                      = 3,600 USDT

Initially, roughly 1,800 USDT is allocated to each side. Per-symbol constraints, hedging constraints, and turnover constraints are applied afterward. This number does not mean that the final orders are guaranteed to fill to the full amount, nor does it represent margin utilization.

Current effective weights are also subject to these caps:

These percentages constrain factor budgets. They further affect portfolio notional exposure and should not be interpreted directly as the percentage of account equity allocated to a particular coin.

The corresponding code is split into two steps. effectiveWeights extracts ACTIVE and TRIAL factors that have valid scores in the current round, then calls the budget-constraint function. The following excerpts show the connection between the two pieces; the second excerpt sits inside the factor loop of normalizeWeightTargets:

function effectiveWeights(matrix) {
    var raw = {}
    factorIdsByStatus(["ACTIVE", "TRIAL"]).forEach(function(id) {
        if (Object.keys(matrix[id] || {}).length)
            raw[id] = Math.max(0, num(G.registry[id].weight, 0))
    })
    return normalizeWeightTargets(raw, G.registry, true)
}

// Per-factor cap inside normalizeWeightTargets
var cap = factor.status === "TRIAL"
    ? FIXED.trialFactorCap : FIXED.activeFactorCap
result[id] = Math.min(
    cap,
    Math.max(0, num(raw[id], 0))
        / (preserveBudget ? Math.max(1, total) : total)
)

The key is the final true, which corresponds to preserveBudget. Suppose the sum of valid weights, total, is only 0.6. The denominator becomes Math.max(1, 0.6), so each 0.2 stays 0.2. If the code divided directly by 0.6, each factor would be inflated to approximately 0.3333. If total budget exceeds 1, the same denominator mechanism compresses it back into the total budget range. Later checks also enforce family caps and total trial-factor caps. Any budget clipped by these constraints is not redistributed to the other factors.

6. Save Today's Decision First, Then Wait for Tomorrow's Answer

One of the easiest mistakes in an adaptive system is to change the question while evaluating the answer.

Whenever APFF generates a new decision round, it stores the universe version, entry reference prices, factor scores, and coverage observed at that time, then creates a research sample that matures eight hours later. Factor performance is updated only after that sample matures.

After the first startup, seeing “valid samples: 0” in the status panel can be completely normal. Having enough historical candles to calculate momentum and having accumulated complete forward evaluation samples are two different conditions. The five seed factors being marked ACTIVE describes their initial operating status; it does not mean they have already passed a statistical test.

1. Freeze Sample Membership and Maturity Time
At entry, each factor's research portfolio uses the scores available at that moment to select approximately the top 20% of symbols for the long side and the bottom 20% for the short side. Half of the notional budget is allocated to each side, with equal weights within each side. Tied symbols on a quantile boundary are included together and side-level weights are then redistributed.

At maturity, a symbol cannot simply be removed because its terminal price is missing, followed by reranking and replacement with another symbol. Otherwise, a losing position that happens to have missing data could disappear from the statistics.

The current implementation allows at most a 60-second terminal-price collection window. Once a terminal price has been fixed, it is not replaced by a later price even if funding history arrives late. Funding history may be awaited until five minutes after the original maturity time; if the required data is still incomplete, the entire sample is invalidated.

This puts an explicit bound on timing error, but the label is still a mid-price research approximation. It cannot be treated as the realized return of a passive limit order in a real exchange queue.

2. Price Features and Trading Returns Use Different Return Definitions
Log returns are suitable for momentum and volatility features. For a fixed-quantity linear perpetual position, however, PnL should be calculated using simple price returns plus funding cash flows.

Let the entry reference price be P0, the terminal price be P1, the k-th funding settlement rate be f_k, and its settlement mark price be M_k. The long-side research return per unit of initial notional is:

r_long = P1 / P0 - 1 - Σ(f_k × M_k / P0)

When historical mark prices are available, the code uses this definition. If mark price is unavailable, the funding impact is approximated against the initial notional. Trading fees are not deducted at this stage.

The factor's long-short research portfolio then aggregates returns using signed weights and subtracts estimated turnover costs:

Turnover   = Σ |new weight_i - old weight_i|
Net return = Σ(new weight_i × r_long_i) - Turnover × one-way cost

For example, if a symbol moves from a +5% long weight to a -5% short weight, the absolute weight change is already 10%, which includes both closing the long and opening the short. Multiplying by 2 again would double-count the cost.

7. Make New Factors Pass Through Observation, Trial, and Exit

The current “factor factory” generates candidates from a finite set of templates. The templates cover momentum, reversal, Funding, Premium, OI, price-volume relationships, low-volatility ideas, and multiple lookback horizons.

Each batch can add at most 12 candidates that have not already been registered. Formula type, parameters, and direction together define a fixed identity used for deduplication. Once the template space is exhausted, later batches may generate no new candidates. The current version does not call a large language model online to generate trading code, nor does it perform open-ended formula search.

The main candidate lifecycle is:

The observation stage requires at least 180 valid 8-hour samples, which is about 60 days under ideal continuous conditions. After entering TRIAL, the candidate must independently accumulate at least another 90 valid samples, or roughly 30 days. Missing samples and weekly screening cadence can make the actual calendar time longer.

Trial-stage performance is recorded separately. Good performance accumulated during OBSERVING cannot be carried over to satisfy the TRIAL threshold.

What Does the Evaluation Look At?
The current evaluation mainly examines Rank IC, cost-adjusted long-short returns, subperiod stability, bucket monotonicity, turnover, and data coverage.

Rank IC measures whether the ranking of entry scores agrees with the ranking of subsequent returns. To reduce small-sample optimism, the mean IC is shrunk:

Shrunk mean IC = n / (n + 60) × mean IC

Stability divides the available return series into four time segments and measures how many segments have positive average net returns. This is a four-segment check; it should not be interpreted as having already survived four real calendar quarters or four complete market regimes.

Candidates must not only have positive shrunk IC but also pass a stricter cost test. The base net return has already deducted one estimated cost charge; promotion testing subtracts the same cost once more to check whether the factor remains positive under doubled costs.

The system also uses block bootstrap resampling to examine result stability. Separately, it estimates a tail probability under a zero-mean null and then applies a dependence-adjusted multiple-testing threshold. These two statistics must not be confused. The bootstrap positive-return frequency shown in the status panel describes the resampling results; it is not a “probability of future profitability.”

These rules are intended to reduce the influence of small samples, repeated screening, and accidental winners. Fixed block length, a finite number of resamples, and continuous online screening still introduce approximations and selection bias. The system therefore cannot claim that all false discoveries have been rigorously controlled.

In addition, if the absolute correlation between a candidate's contemporaneous research returns and those of existing portfolio factors exceeds 0.85, it is treated as highly redundant. At most two candidates from each batch can enter TRIAL, and at most one from the same family can do so. No more than two factors can be in TRIAL simultaneously, and no more than six factors can be ACTIVE.

The basic admission function used during screening is shown below. The original logic is preserved; only line breaks and comments are made clearer:

function factorPasses(factor, minimumSamples) {
    var s = summarizeFactor(factor)
    return s.samples >= minimumSamples
        && s.shrunkIc > 0
        // meanNet already includes the base cost deduction.
        // Subtract the same cost once more to test doubled costs.
        && s.meanNet - num(s.turnover, 0)
            * G.cfg.oneWayCostBps / 10000 > 0
        && s.stability >= 0.75
        && s.pPositive >= 0.90
        && s.coverage >= 0.98
}

All conditions must be satisfied simultaneously. stability >= 0.75 requires at least three of the four time segments to have positive average net returns. coverage >= 0.98 checks the average factor coverage across evaluation samples, which is stricter than the 80% threshold used for participation in a single round. During the observation stage, the function is called with a 180-sample threshold. During the trial stage, it uses independent trialMetrics and a 90-sample threshold. Even after this function returns true, the caller still checks the relevant multiple-testing criteria, correlation limits, and slot limits. A single true does not mean the factor has automatically been promoted.

8. Adaptive Reweighting Should Respond to Evidence With Restraint

When there are not enough samples, the system uses equal budgets for the seed factors. Only after the adaptive-sample requirements are met are target weights derived from each factor's evaluation results.

The implementation's evidence score combines scaled IC, net-return score, stability, and monotonicity, then subtracts turnover and missing-data penalties. It is an internal composite score, not a calibrated probability.

Target weights also take the volatility of factor research returns into account. The old and new target weights are then smoothed:

Smoothed weight = 70% × old weight + 30% × new target weight

During ordinary weekly reweighting, the change in any single factor is limited to 5 percentage points, after which all budget caps are applied again. Factor dormancy and hard constraints can reduce a weight faster, so this smoothing rule should not be interpreted as saying that exposure can only decrease slowly under all circumstances.

Once an ACTIVE factor has accumulated at least 180 valid samples, it enters DORMANT status and its weight is set to zero if both the mean IC and mean net return over the most recent 90 samples are negative. The current logic reduces or disables a factor; it does not automatically reverse the trading direction merely because recent performance has been poor.

Reversing direction is itself a new hypothesis and should be evaluated from scratch. Otherwise, the system can easily end up chasing noise back and forth across the positive and negative sides of a signal that has simply stopped working.

9. From Combined Scores to Executable Target Positions

The live portfolio differs from the equal-weight research baskets used earlier to evaluate individual factors.

The actual portfolio selects assets from both tails of the combined-score ranking. New targets are chosen from roughly the top and bottom 20%, with at most six symbols on each side. Existing targets are preferentially retained as long as they remain within roughly the corresponding 35% region of the ranking, reducing repeated turnover around the selection boundary.

The raw weight within each side is:

raw weight_i ∝ max(0.05, |Alpha_i|) / RV_7D_i

Stronger relative scores receive larger raw weights, while higher historical volatility reduces allocation. A per-symbol cap is then applied, with the default absolute target notional limited to 8% of account equity.

The BTC hedge estimates beta from aligned 4-hour returns. If the absolute estimated beta exposure of the portfolio exceeds 2% of equity, the program attempts to offset it with BTC. The hedge itself is capped and remains subject to per-symbol and total-portfolio exposure limits. Some residual beta can remain after clipping, so this is intentionally a limited hedge.

Turnover is handled last. Under normal target rebalancing, the notional amount changed in one decision is softly capped at 20% of account equity. If the desired adjustment exceeds that level, the portfolio moves proportionally toward the new target. However, if the current target already violates a hard risk limit, required deleveraging takes priority; excessive risk is not preserved merely to satisfy the turnover limit.

After all hedge and turnover adjustments, the program performs another check of per-symbol and total exposure. A target that passed earlier checks can become invalid again after subsequent transformations, so this final validation must occur before the executable target is finalized.

Because the actual portfolio uses volatility weighting, ranking buffers, BTC hedging, and turnover controls, individual factor research returns cannot simply be added together and treated as strategy-level account returns. The research layer evaluates ranking information; the execution layer must additionally determine whether that information can be converted into positions at a reasonable cost.

10. After an Order Fills, the Position Still Has to Give the Same Answer

Once a multi-asset strategy runs asynchronously, market data, order responses, fills, and position snapshots can arrive in different orders.

FMZ's exchange.Go can call trading interfaces asynchronously and retrieve results through the returned object's wait method. APFF uses this mechanism to stagger data and account queries. The current maximum number of concurrent tasks is 8. See the FMZ exchange.Go documentation.

Asynchronous execution creates another question that must be answered explicitly: did this request actually take effect on the exchange?

Save the Intent Before Sending the Order
Before every order is sent, the program first generates a client order ID and records the symbol, side, quantity, current position, and corresponding target, then persists that intent. If persistence fails, the order is not sent.

At most one active intent is allowed per symbol, and at most four can exist globally at the same time. When reversing direction, the program closes the original side before considering a new position on the opposite side. Normal execution uses GTX passive limit orders. New targets have a default execution window of 15 minutes. After that window expires, the strategy stops adding new risk, while required risk reduction and reconciliation continue.

If a Request Times Out, Verify the Result First
A definite rejection and an unknown result must be treated differently. Insufficient balance, precision errors, and similar responses can be handled as explicit rejections. A timeout, broken connection, or unknown response may occur after the exchange has already accepted the order.

The current implementation continuously reconciles by order ID or client order ID against order details, open orders, and historical orders. It does not release an unknown intent and submit the order again merely because “the open-order list is empty” or “tens of seconds have passed.”

After the Order Reaches a Terminal State, Confirm the Position Too
Suppose the original position is 100 contracts and a closing sell order accumulates 30 contracts of fills. The next position snapshot should confirm that roughly 70 contracts remain. This query must be initiated after the order reaches its terminal state; a late response from an older request cannot be used as confirmation. If the snapshot still reports 100 contracts, the program shows WAIT_POSITION, continues querying, and keeps the symbol locked.

The expected position is calculated as “initial position + signed cumulative filled quantity” and stored as barrier.expected. After a position response arrives, applyPositions checks whether the reconciliation lock can be released. The following excerpt shows the core order path in the current version, omitting diagnostic logs and legacy state-migration branches. positions is the already-parsed position map:

var snapshotAt = num(requestedAt, nowMs())
Object.keys(G.execution.positionBarriers || {}).forEach(function(symbol) {
    var barrier = G.execution.positionBarriers[symbol]
    // The query must have been initiated after the terminal state.
    // A symbol with simultaneous long and short positions cannot be unlocked.
    if (snapshotAt <= barrier.at || (G.actual.hedgedSymbols || {})[symbol])
        return

    var spec = G.universe.markets[symbol]
    var tolerance = Math.max(1e-12, num(spec && spec.step, 0) / 2)
    if (finite(barrier.expected)
        && Math.abs(num(positions[symbol], 0) - barrier.expected) > tolerance)
        return

    delete G.execution.positionBarriers[symbol]
    clearIssue("POSITION_RECONCILE_" + symbol)
})

snapshotAt uses the request-initiation time to determine ordering. Quantity comparison allows an error of half the order-size step and also applies a tiny numerical-error floor. If any check fails, the function returns early, the symbol lock remains in place, and the execution layer continues blocking new orders for that symbol. Only after all checks pass is positionBarriers[symbol] deleted. This avoids the classic duplicate-trading failure mode of “the order has filled, the position endpoint has not updated yet, so the strategy sends the same trade again.”

One Binance simulation test provides a concrete example. A TAC position-reduction order accumulated 17,990 contracts of fills, reducing the position from 37,062 to 19,072 contracts. During the process, a cancel request raced with the fill and produced one -2011 response. Subsequent order queries confirmed the remaining execution within about 2.17 seconds, completing reconciliation.

This test record shows how that particular race condition was recovered. The error message itself cannot prove that the order filled, nor can it prove that cancellation succeeded. Final confirmation still requires the terminal order state and the position quantity to agree with each other.

11. Risk Controls Must Work While the Program Is Still Running

APFF scales target budget according to drawdown from the historical equity peak:

The 4% and 7% tiers take effect on the current target immediately; the system does not wait for the next 8-hour decision. The zero-target state continues to prevent new exposure, while the execution layer reduces positions after it obtains the required market and account state. These controls constrain the program's targets and execution behavior; they do not guarantee that maximum loss in an extreme market will stop exactly at 10%.

The interactive controls distinguish three actions: PAUSE_NEW pauses new risk, RESUME resumes portfolio execution, and REDUCE_TO_ZERO cancels this strategy's orders, completes reconciliation, and then closes the positions managed by this strategy.

The strategy uses its own position-ownership markers to determine what it manages. If a target symbol already has a position that is not attributed to this strategy, or if simultaneous long and short positions are detected in the same symbol, automatic trading for that symbol is blocked.

Stopping the process does not automatically liquidate positions. If the intention is to flatten the portfolio, the flattening workflow should be allowed to complete and its result should be verified. Simply stopping the robot leaves positions in place. For a multi-asset portfolio, this distinction directly determines how much risk remains in the account after shutdown.

12. How to Interpret Run Modes and the Status Panel on FMZ

The current version provides three run modes:

LIVE uses the trading interface. If the exchange object is configured for the Binance simulated environment, orders are matched in the exchange's simulation environment. Only when the strategy is connected to a real-money account does LIVE correspond to real-money trading. Both the run-mode name and the account environment must be checked.

The current program depends on live WebSocket data and blocks entry into FMZ's historical backtest environment during initialization. Therefore, PAPER must accumulate forward results through real-time running. It is not a mode where one can simply select a historical date range and backtest it.

After importing the complete strategy file and adding a corresponding Binance futures exchange object, the main parameters are:

These values are program defaults and have not been certified as return-optimal parameters. Cost parameters in particular must be interpreted according to the run mode. The research layer deducts estimated cost from reference-price returns. In PAPER, buys use the Ask and sells use the Bid, so bid-ask spread is already reflected; the configured cost parameter is then charged additionally as a fee estimate. Cost calibration should avoid counting the same cost component twice.

When observing the strategy, the status panel can be read in this order:

Market data and data gates: Are both market-data connections updating continuously, and are enough tradable symbols available?
Research samples and maturity: Is the system merely warmed up on data, or has it already accumulated valid forward samples?
Configured weights and effective target weights: Which factors are actually participating in this round?
Targets and positions: Are deviations caused by the execution window, minimum order notional, exchange limits, or fills that are still awaiting confirmation?
Order intents and position-confirmation locks: Are UNKNOWN or WAIT_POSITION states persisting, and are the related reconciliation queries still progressing?

The PAPER ledger separates realized PnL, unrealized PnL, funding, and estimated fees. Funding is posted against the historical position that existed at settlement time; late-arriving funding records are not simply applied to the current position.

LIVE currently displays performance mainly as the difference between account equity and baseline account equity. It does not yet fully exclude deposits, withdrawals, or the effect of other strategies, and it does not fully separate actual realized PnL, unrealized PnL, and funding. Items that are not separately accounted for are shown as -; they must not be interpreted as zero.

13. What Has Been Validated So Far?

As of the build used in this article, the project has completed base logic checks, 23 order-regression checks, and 34 dedicated audit tests. The dedicated tests include 36 accelerated decision cycles and 500 randomized weight-constraint checks.

It is important to state what these numbers do and do not mean. The 36 cycles use synthetic data and a controlled clock to validate sampling, maturity, accounting, and recovery workflows; they are not a 12-day historical return backtest. The randomized constraint checks validate budget caps; they do not validate the predictive power of the factors.

Runtime retesting in the Binance simulated environment covers actual simulated matching, restart recovery, cancel/fill races, explicit order rejection, and position reconciliation. These results are enough to justify continuing to accumulate forward evidence, but they are not sufficient to report conclusions about annualized return, Sharpe ratio, or long-term win rate.

The highest-priority next steps are to add point-in-time historical data and independent rolling out-of-sample validation, calibrate execution costs by symbol and market regime, add correlation-cluster position limits, and introduce an entry threshold requiring expected return to cover trading costs. These directions already exist in the research design, but they have not all been fully implemented in the current code.

APFF has already encoded the lifecycle of a factor—from creation and performance recording, to receiving budget, participating in orders, and eventually leaving the portfolio—into a running program. The most valuable data from here will be the decision recorded at each point in time and the answer obtained eight hours later under the same rules: which signals remain effective, which work only in certain market regimes, and how much of their apparent edge survives actual execution.

FMZ Web3 in Practice — Riding the Robinhood Chain Wave: Build a Uniswap V4 New Pool Radar Step by Step

Dream — Wed, 09 Sep 2026 08:42:42 +0000

Robinhood Chain has recently seen a noticeable surge in on-chain activity. By late August 2026, transaction activity on the network had accelerated significantly. On August 30, Robinhood Chain processed approximately 5.52 million transactions in a single day, while daily DEX trading volume reached roughly $875 million. At the same time, token issuance also began to accelerate rapidly, with the Pons launch platform alone creating around 22,600 tokens that day.

For ordinary users, the most visible takeaway may simply be that Robinhood Chain has recently become very active and that a large number of new tokens are appearing. For quantitative developers, however, a more interesting question is:

Can we let a program monitor Robinhood Chain directly and detect a new Uniswap pool the moment it appears?

The answer is yes.

We do not need to keep refreshing web pages, nor do we need to rely on third-party new-token alert services. By reading on-chain events directly through Robinhood Chain's JSON-RPC interface, we can capture new pools at the data source itself.

In this article, we will use FMZ Quant to connect to Robinhood Chain mainnet through its JSON-RPC interface and monitor the Uniswap V4 PoolManager contract. Starting from scratch, we will build a Robinhood Chain new-pool radar.

Once running, the program continuously reads the latest blocks and uses eth_getLogs to monitor Uniswap V4 Initialize events. Whenever a new pool is created, it automatically decodes the trading pair, token information, fee, tick spacing, hook, and pool ID, with special attention given to pools pairing a new token with ETH or WETH.

For now, we will solve the most fundamental problem in the entire system:

How can we discover a newly created Uniswap V4 pool as early as possible?

Later, this framework can be extended with liquidity monitoring, swap monitoring, wallet analysis, risk detection, new-token scoring, automated trading, and more.

1. Why Is Robinhood Chain Worth Watching?

Robinhood Chain is an Ethereum Layer 2 network built on the Arbitrum technology stack. For developers building on-chain strategies with FMZ, one of its most important characteristics is that it is EVM-compatible.

That means standard JSON-RPC methods we already use on Ethereum and other EVM networks—such as eth_blockNumber, eth_getLogs, eth_call, eth_getBalance, and eth_getTransactionReceipt—can also be used on Robinhood Chain.

The current core parameters for Robinhood Chain mainnet are:

Robinhood provides a free public RPC endpoint, so during development you can start testing without purchasing access from a third-party node provider. However, Robinhood also states that the public RPC is rate-limited. If the strategy later needs to run continuously, perform large numbers of queries, or require higher reliability, a professional RPC provider such as Alchemy can be considered.

Reference: Robinhood Chain — Connecting to Robinhood Chain

From FMZ's perspective, connecting to Robinhood Chain is fundamentally no different from connecting to other EVM networks. We really need to solve only three problems:

connect to the correct RPC;
find the target smart contract;
monitor the correct on-chain event.

2. Why Choose New Uniswap V4 Pools as the Monitoring Target?

Our goal is not simply to know that Robinhood Chain has produced another block.

The information that is actually useful is:

Has a new token trading pool appeared?

For example, during real operation we have already captured V4 pools such as:

ETH / GREAT
ETH / MERRY
ETH / ANTIDOTE

If we can discover these pools immediately, we can then continue investigating what the token is, how much ETH liquidity has been added, what the initial price is, whether users have started trading, who the first buyers are, what the buy/sell ratio looks like, and whether the token itself shows any obvious risks.

New-pool discovery therefore acts as the entrance to a broader on-chain new-token monitoring system.

Uniswap is already deployed on Robinhood Chain, with V2, V3, V4, and UniswapX all part of the ecosystem. In August 2026, Uniswap Labs also launched Pools.trade for Robinhood Chain, providing infrastructure for new-token launches and liquidity creation.

Reference: Uniswap — Robinhood Chain is Live

For us, then, building a Uniswap V4 new-pool radar is a natural place to start.

3. Understanding Uniswap V4's PoolManager

Before writing code, we first need to understand one important difference between Uniswap V4 and the earlier V2/V3 architecture.

In Uniswap V2 and V3, we often think of different liquidity pools as separate pool contracts. Uniswap V4 introduces a Singleton Architecture, where the core state of many pools is managed by one important contract: PoolManager.

As a result, in V4 we do not need to search everywhere for newly deployed pool contracts. For new-pool monitoring, what matters more is monitoring the events emitted by PoolManager directly.

That makes the monitoring logic much simpler.

The Uniswap V4 PoolManager address on Robinhood Chain is:

0x8366a39cc670b4001a1121b8f6a443a643e40951

The Robinhood Chain WETH address is:

0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73

The program later in this article will use both addresses directly.

4. How Is a New Pool Discovered?

When a new Uniswap V4 pool is initialized, PoolManager emits a very important event:

Initialize

Its structure can be represented as:

event Initialize(
    PoolId indexed id,
    Currency indexed currency0,
    Currency indexed currency1,
    uint24 fee,
    int24 tickSpacing,
    IHooks hooks,
    uint160 sqrtPriceX96,
    int24 tick
);

This event already contains a large amount of information useful for monitoring a new pool, including:

Pool ID;
the two trading assets;
fee;
tick spacing;
hook;
initial price information;
initial tick.

The monitoring principle itself is not complicated.

When a user calls PoolManager.initialize() to initialize a new V4 pool, PoolManager emits an Initialize event. That event is then recorded in the block logs.

FMZ can query these logs through the standard JSON-RPC method eth_getLogs. As long as we specify both the PoolManager contract address and the Initialize event topic, the RPC node can filter out the new-pool events we need directly. There is no need to download every transaction in the block and analyze them one by one.

This is the core mechanism behind the new-pool radar in this article.

5. Adding Robinhood Chain to FMZ

Now we can start the actual setup.

First, add a Web3 exchange object on FMZ Quant.

Because Robinhood Chain is an EVM network, set ChainType to:

ETH

Note that selecting ETH does not mean we are connecting to Ethereum Mainnet. It tells FMZ to use the Ethereum/EVM-style Web3 interface.

For testing, set the RPC address to the official Robinhood Chain mainnet RPC:

https://rpc.mainnet.chain.robinhood.com

The final configuration is:

Although the new-pool radar in this article only reads public on-chain data and does not send transactions, the wallet private key will become involved in transaction signing if functions such as Approve or Swap are added later.

For development, it is therefore better to create a dedicated test wallet rather than using a main wallet that holds substantial assets. Never provide your private key or seed phrase to anyone.

6. Testing the FMZ–Robinhood Chain Connection

When developing Web3 strategies, I recommend starting with the smallest possible test. Do not begin by writing hundreds of lines of code. First verify that the most basic data path works:

FMZ → RPC → Robinhood Chain

Create a minimal FMZ JavaScript strategy:

function main() {

    var chainId = exchange.IO(
        "api",
        "eth",
        "eth_chainId"
    );

    var blockNumber = exchange.IO(
        "api",
        "eth",
        "eth_blockNumber"
    );

    Log(
        "Chain ID:",
        chainId
    );

    Log(
        "Block Number:",
        blockNumber
    );
}

After running it, we obtained:

0x1237 converted to decimal is 4663, which matches the Robinhood Chain Mainnet Chain ID exactly.

This means FMZ has successfully connected to Robinhood Chain mainnet through JSON-RPC.

The test is simple, but it is important. If new-pool monitoring later encounters a problem, we already know that the RPC connection itself is working.

7. Calculating the Uniswap V4 Initialize Event Topic

In an Ethereum event log, topics[0] is the Keccak256 hash of the event signature.

We can therefore calculate the topic for Initialize directly in FMZ:

function getInitializeTopic() {

    var signature =
        "Initialize(bytes32,address,address,uint24,int24,address,uint160,int24)";

    return (
        "0x" +
        Encode(
            "keccak256",
            "string",
            "hex",
            signature
        )
    );
}

The result is:

Later, when calling eth_getLogs, we only need to place this value in topics[0]. The RPC node can then filter Initialize events for us.

8. Querying New Pools with eth_getLogs

FMZ Web3 can call Ethereum JSON-RPC directly through exchange.IO().

For example:

var logs = exchange.IO(
    "api",
    "eth",
    "eth_getLogs",
    params
);

The query parameters mainly specify:

the starting block;
the ending block;
the PoolManager address;
the Initialize topic.

var params = {

    fromBlock:
        numberToHex(fromBlock),

    toBlock:
        numberToHex(toBlock),

    address:
        "0x8366a39cc670b4001a1121b8f6a443a643e40951",

    topics: [
        getInitializeTopic()
    ]
};

The RPC node will now return not every transaction in the block, but specifically the Initialize events emitted by Uniswap V4 PoolManager within the requested block range.

For a new-pool radar intended to run continuously, this is far more efficient than downloading every block's transactions and analyzing them individually.

9. Decoding the Initialize Event

Once we receive an event log, we still need to convert the raw hexadecimal data into human-readable information.

The first three parameters in Initialize are indexed parameters, so they appear in topics[1], topics[2], and topics[3]:

var poolId =
    log.topics[1];

var currency0 =
    topicToAddress(
        log.topics[2]
    );

var currency1 =
    topicToAddress(
        log.topics[3]
    );

The remaining parameters are stored in log.data:

var fee =
    wordToUint24(
        getWord(
            log.data,
            0
        )
    );

var tickSpacing =
    wordToInt24(
        getWord(
            log.data,
            1
        )
    );

var hooks =
    wordToAddress(
        getWord(
            log.data,
            2
        )
    );

After decoding, what originally looked like an unreadable blockchain log becomes structured information such as:

Pool ID;
token addresses;
fee;
tick spacing;
hook.

10. A Common Native ETH Pitfall in Uniswap V4

In Uniswap V4, native ETH can be used directly as a Currency.

Therefore, if the program sees:

0x0000000000000000000000000000000000000000

we cannot simply assume it is an invalid address. In this context, it may represent native ETH.

Our program therefore needs to recognize both native ETH and WETH.

Native ETH:

0x0000000000000000000000000000000000000000

Robinhood Chain WETH:

0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73

This allows the program to filter pools such as:

ETH / new token
WETH / new token

For a new-token radar, these pools are usually worth prioritizing over ordinary token/token pools.

11. Reading Token Information

Displaying only a token contract address is not very readable.

For example:

0xffb1e3a069d2060cf42247ed67a8e712a05064de

By looking at the address alone, we have no idea what the token is.

After detecting the token, we can continue by using eth_call to call the standard ERC20 functions symbol(), name(), and decimals().

First register a simple ERC20 ABI:

var ERC20_ABI = `[
    {
        "inputs": [],
        "name": "symbol",
        "outputs": [{"type":"string"}],
        "stateMutability":"view",
        "type":"function"
    },
    {
        "inputs": [],
        "name":"name",
        "outputs":[{"type":"string"}],
        "stateMutability":"view",
        "type":"function"
    },
    {
        "inputs":[],
        "name":"decimals",
        "outputs":[{"type":"uint8"}],
        "stateMutability":"view",
        "type":"function"
    }
]`;

Then:

exchange.IO(
    "abi",
    addr,
    ERC20_ABI
);

var symbol = exchange.IO(
    "api",
    addr,
    "symbol"
);

The original token address can now be displayed together with:

Symbol;
Name;
Decimals;
Contract Address.

In practice, there is no guarantee that every on-chain token implements the standard ERC20 ABI perfectly. The token-information query should therefore be wrapped in try...catch.

Even if a strange token fails to return symbol(), it should not cause the entire new-pool radar to stop running.

12. Running It for Real: We Actually Captured New Robinhood Chain Pools

After implementing the logic above, we ran the program on Robinhood Chain mainnet.

It quickly captured real Uniswap V4 Initialize events.

This means we have successfully completed the full data path:

Robinhood Chain
    ↓
Uniswap V4 PoolManager
    ↓
Initialize Event
    ↓
FMZ new-pool monitoring

13. Building a Real-Time New Pool Radar with LogStatus

If the program simply keeps calling Log(), after running for several hours the log output becomes very large and it becomes difficult to understand the current system state quickly.

So we continue by using FMZ's LogStatus() to build a simple real-time dashboard.

The dashboard mainly displays:

network status;
latest block;
RPC latency;
number of scans;
number of newly detected pools;
number of ETH/WETH pools;
recently discovered pools;
priority new-token information.

At this point, the program is no longer just a simple event-log script. It is beginning to take the shape of an actual on-chain monitoring system.

14. Choosing an RPC Provider and the Problems We Actually Hit

Robinhood Chain provides an official public RPC:

https://rpc.mainnet.chain.robinhood.com

In our real tests, the free official RPC was already able to handle both eth_blockNumber and eth_getLogs queries successfully, so it is perfectly usable during development.

However, if the program is expected to run 24/7 for long periods, or if we later add large numbers of Swap, Liquidity, and Token queries, RPC stability and rate limits become important considerations.

So we also tested Alchemy.

An Alchemy Robinhood Chain HTTP endpoint looks similar to:

https://robinhood-mainnet.g.alchemy.com/v2/YOUR_API_KEY

On FMZ, we only need to replace the Rpc Address with the corresponding endpoint. The strategy can continue using standard JSON-RPC calls, and the core logic does not need to be rewritten simply because the provider changed.

During testing, however, we encountered an interesting issue.

When Alchemy's Free Plan received an eth_getLogs request covering too large a block range, it returned:

400 Bad Request
Under the Free tier plan,
you can make eth_getLogs requests
with up to a 10 block range.

The original program used:

maxBlockRange: 100

This meant a single request could cover as many as 100 blocks, triggering the free-plan limit.

The solution was simple:

maxBlockRange: 10

Then let the program divide a larger scan automatically into batches.

For example, if the bot has been offline for a while and needs to catch up on 35 blocks, it can split the job into four eth_getLogs requests, each covering no more than 10 blocks.

This looks like a small change, but it is actually very valuable.

*An on-chain monitoring program cannot assume that RPC services will always be stable, and it cannot assume that every provider has exactly the same limits.
*
If the project is improved further, we can add mechanisms such as:

primary RPC;
backup RPC;
automatic failover;
retry handling for HTTP 429;
exponential backoff.

15. Complete FMZ New Pool Radar Code

Below is the complete strategy used in this article.

The role of this version is intentionally clear:

monitor only, no trading.

Robinhood Chain · Uniswap V4 New Pool Radar V2

It does not execute Approve, call Swap, or automatically purchase any token.

The first priority is to build the on-chain data layer correctly. Trading logic can then be added on top of that foundation.

16. Why Can't We Buy Immediately After Discovering a Pool?

Once we reach this point, it is easy to have another idea:

If we can already detect a new pool immediately, why not simply call Swap as soon as the pool appears?

In practice, we are still far from that point.

An Initialize event only tells us that the pool has been initialized. It does not mean the pool already has enough liquidity to be worth trading.

After a pool is created, liquidity may only be added later. Even after liquidity has been added, we still need to evaluate:

liquidity size;
initial price;
fee;
hook;
token contract risk.

Therefore, discovering a new pool and discovering a trading opportunity are two very different things.

We have solved the first problem.

The next step is to continue monitoring liquidity-related events after capturing Initialize.

When the program discovers ETH / GREAT, for example, it should no longer stop at displaying the token name. It should continue answering questions such as:

Has actual liquidity been added to this pool?
How much ETH liquidity has been added?
How many tokens were added on the other side?
What is the approximate initial price?

Once this step is complete, the new-pool radar begins to evolve into a true new-token radar.

17. Next Step: Add a Liquidity Radar

The code framework in this article is not a one-off script.

We already have:

Pool ID;
Currency0;
Currency1;
Fee;
TickSpacing;
Hook;
Block;
Transaction Hash;

basic token metadata.
All of these can become inputs to later modules.

The most useful next component to implement is a Liquidity Radar.

After Initialize detects a new ETH-token pool, the program can continue tracking changes in that pool's liquidity and attempt to calculate:

ETH liquidity;
token liquidity;
initial price;
speed of liquidity changes.

After that, we can continue monitoring Swap events.

Once swaps can be decoded in real time, the system can begin tracking:

the first trade;
the first 10 trades;
number of buys;
number of sells;
trading volume;
number of unique trading addresses;
early trading speed.

With these data points, the system is no longer limited to telling us that a new token has appeared. It can gradually build a richer profile such as:

Going further, we can research:

deployer addresses;
early buyers;
historical wallet behavior;
liquidity withdrawals;
token permissions;
abnormal trading patterns.

These modules can eventually feed into a unified Scoring Engine, allowing large numbers of new pools to be automatically classified into categories such as:

Ignore;
Watch;
High Priority.

Only after reaching that stage does it become more meaningful to discuss automated trading.

18. What Can We Research Next?

This entire series can continue expanding around the code built in this article instead of rewriting a completely different program each time.

Stage 1: Pool Discovery
This is the Initialize monitoring implemented in this article. It answers:

When did a new pool appear?

Stage 2: Liquidity Intelligence
The focus shifts to questions such as:

How much ETH was added to the new pool?
How many tokens were added?
When does liquidity increase?
When is liquidity withdrawn?

Stage 3: Trading Intelligence
Begin monitoring Swap events and measure:

early trades;
buy/sell direction;
trading speed;
transaction value.

Stage 4: Wallet Intelligence
Analyze:

who is buying;
who is selling;
whether the deployer is trading;
whether certain addresses repeatedly appear among the early traders of high-performing new tokens.

Stage 5: Risk Engine
Perform unified checks on:

token permissions;
hooks;
fees;
liquidity;
wallet concentration;
abnormal trading behavior.

Final Stage: Strategy Engine
Only then do we turn the previous on-chain data into rules or scores, decide whether a pool should enter a watchlist, and determine whether the strategy may eventually be allowed to execute swaps automatically.

In this way, a new-pool listener that initially contains only a few hundred lines of code can gradually evolve into a complete Robinhood Chain on-chain quantitative data and strategy system.

19. Conclusion

This exercise demonstrates something interesting.

For a new EVM chain, we do not necessarily need to wait until a complete SDK, third-party data platform, or ready-made quantitative framework becomes available before we begin development.

As long as the network exposes standard Ethereum JSON-RPC, FMZ can already read on-chain data directly from the underlying infrastructure.

The core interfaces used in this article are actually quite limited:

eth_chainId;
eth_blockNumber;
eth_getLogs;
ERC20 eth_call.

Yet with these very basic interfaces, we have already completed:

Robinhood Chain mainnet connectivity;
Uniswap V4 PoolManager monitoring;
Initialize event decoding;
token metadata queries;
ETH/WETH new-pool filtering;
a real-time dashboard.

More importantly, during actual operation we successfully captured newly created V4 pools such as:

ETH / GREAT;
ETH / MERRY;
ETH / ANTIDOTE.

Strategy description:

Robinhood Chain · Uniswap V4 New Pool Radar V2

This article is provided solely for Web3 technical research and software-development practice and does not constitute investment advice. Newly issued tokens and low-liquidity on-chain assets can involve substantial price, smart-contract, and liquidity risks. Before adding any automated trading functionality, the system should be thoroughly tested and equipped with comprehensive risk controls.

`The Bull Is Now` Got Listed on Binance Futures. I Was Afraid to Chase Highs or Buy Lows, So I Built a Strategy That Doesn't Bet on Direction

Dream — Fri, 04 Sep 2026 02:58:22 +0000

At 11:30 on August 30, Binance listed the USDT-margined perpetual contract for 牛来, whose contract symbol is literally the Chinese 牛来USDT. The coin comes from a Chinese animated film that two people spent five years making and that went viral partly because of its rough-looking visuals. On top of that, 牛来 sounds like “the bull market is coming,” and that is how the meme took off. On its first day of trading, its 24-hour amplitude reached 57.4%, it rose 28.7% in a single day, and its minute-based realized volatility reached 95.7 basis points. I compared it cross-sectionally against 612 perpetual contracts across the entire market, and it ranked first in both the depth and frequency of lower wicks.

That is also where the problem starts. With volatility like this, if you chase the long side, you do not know whether you are buying at the top; if you short it, one wick can blow you up. I was afraid of both the highs and the lows, so I did not dare take either side. But with roughly $400 million in daily turnover sitting there, I also did not want to just watch from the sidelines.

On this type of coin, I first tried several of the most intuitive approaches: placing low bids to catch wicks, running a two-sided grid, and arbitraging around funding settlements. None of them worked. Looking back, the reason for failure was the same in every case: they were all betting that “if price falls, it will bounce back.” Catching wicks bets on mean reversion after a deep wick; grids bet on price oscillating within a range; funding-rate sniping bets on a post-settlement price reversal. But the data gave a very consistent answer: the deep-wick reversion rate for 牛来 was only 0.31; shallow pullbacks had a reversion rate of 1.65, but the order-book queue made them practically impossible to fill; and in a 139-day grid sample, sideways and rising windows were almost always profitable, while large down-move windows had a win rate of only 8%.

High-volatility meme perpetuals are momentum assets, not mean-reverting assets. Once I understood that, only one direction remained: do not fight them; move with them.

The Strong Stay Strong, and How to Define “Strong”

The simplest form of a trend-following strategy is to buy the assets that have risen the most and sell the assets that have fallen the most. But looking only at returns has an obvious flaw: return is the result, not the cause. A coin may be up 20% because sustained new capital is pushing it higher, or it may be up because a few short-covering trades caused a temporary squeeze. The subsequent paths of those two situations can be completely different, even though the candles look identical.

So I added a second dimension: the funding rate.

The funding rate of a perpetual contract is essentially a mechanism for balancing the holding costs between longs and shorts. When the funding rate is pushed higher, it means a large number of traders are willing to keep paying to hold long positions. That is different from simply saying “the price went up.” A large order can push price higher, but the funding rate reflects the structure of open positions and therefore represents real willingness to pay to maintain that exposure.

Price momentum tells you, “it went up.” The funding rate tells you, “someone is willing to pay to stay in this direction.” Combine these two dimensions into a composite momentum score, go long the highest-scoring group and short the lowest-scoring group, with equal notional amounts on both sides. If the whole sector rises or falls together, the long and short legs offset each other. The return comes only from the relative performance between “the strongest group” and “the weakest group.” This directly avoids the original dilemma: you do not need to predict whether 牛来 will rise or fall; you only need to judge whether it is stronger or weaker than the other speculative coins.

How Much Weight Should Each of the Two Factors Get?

At first, I used fixed coefficients: 1.0 for price momentum and 0.6 for funding. Once I ran it, I immediately felt something was wrong. Those two numbers were chosen by intuition and had no real basis. Why 0.6 instead of 0.4?

The bigger problem is that even if I find the coefficients that are optimal right now, they may not remain stable. During testing I observed something interesting: for the very same funding-rate factor, changing the universe from 44 contracts to 35, or changing the time window from 41 days to 31 days, could flip the sign of its performance. If a factor can change sign as market conditions change, using a fixed weight effectively welds the characteristics of one historical regime permanently into the strategy.

So I changed the system to let the data decide. The method is rolling cross-sectional regression: at each period, use all candidate contracts available at that time to run a cross-sectional OLS regression of the next-period realized return on the z-scores of the two factors.

// Single-period cross-sectional OLS:
// fwd = a + b1*z(momentum) + b2*z(funding)
function crossSectionOLS(zm, zf, fwd) {
    var n = fwd.length; if (n < 10) return null;
    var A = [[0,0,0],[0,0,0],[0,0,0]], b = [0,0,0];
    for (var i = 0; i < n; i++) {
        var x = [1, zm[i], zf[i]];
        for (var r = 0; r < 3; r++) {
            b[r] += x[r] * fwd[i];
            for (var c = 0; c < 3; c++) A[r][c] += x[r] * x[c];
        }
    }
    return solve3(A, b);
}

Run this period by period over the past 120 periods (one period every four hours, or about 20 days), obtain a time series of coefficients for both factors, and then take the time-series mean. This is the Fama-MacBeth approach. The mean gives you the weight; the standard deviation gives you the significance.

The key question is how to use that significance. A coefficient mean can be large, but if it jumps around wildly over time, then the factor behaves very differently in different periods and should not receive a high weight. So the coefficient is shrunk using its t-statistic:

function shrink(r) {
    var k = Math.min(1, Math.abs(r.t) / T_SHRINK);   // Full weight when |t|>=2; otherwise shrink proportionally
    return r.m * k;
}
var w1 = shrink(r1), w2 = shrink(r2);
var scale = Math.abs(w1) + Math.abs(w2);
w1 = w1 / scale;  w2 = w2 / scale;                  // Normalize so |w1|+|w2|=1

This has three benefits. An insignificant factor is automatically downweighted, so I do not need to decide manually how much weight each one deserves. The sign is determined by the data: if, during some period, the correct use of the funding factor is contrarian, the regression will produce a negative coefficient and the strategy will follow it instead of stubbornly keeping the positive sign I originally wrote down. And once the weights are normalized, total exposure is unaffected; only the relative influence of the two factors changes.

The model is refit every 12 hours. The dashboard directly displays the β and t-values of the two factors, so you can see where the current weights come from. If one day the t-value of the funding factor drops to 0.3, you will see its weight automatically shrink close to the lower bound instead of remaining hidden from view.

A Pitfall That Must Be Fixed: The Time Basis of Funding Rates

This is something I ran into during implementation, and its impact is large enough to deserve its own section.

Different Binance contracts have different funding settlement intervals. Querying the fundingInfo endpoint, among the 768 contracts with records across the whole market, 440 settle every four hours, 324 every eight hours, and another four every one hour. 牛来 itself settles every four hours.

The problem is that a contract settling every four hours at a funding rate of five basis points and a contract settling every eight hours at five basis points display the same nominal number, but the true holding cost differs by a factor of two. The former charges six times per day; the latter only three times.

If raw funding rates are used directly for cross-sectional ranking, you are effectively comparing numbers with different units. This systematically pushes four-hour contracts lower and eight-hour contracts higher, even though more than half of the universe consists of four-hour contracts. The selected long and short legs become distorted.

The fix is simple, but it cannot be skipped:

// Pull each contract's settlement interval
var fi = api('fundingInfo');
for (var i = 0; i < fi.length; i++)
    _ivh[fi[i].symbol] = parseInt(fi[i].fundingIntervalHours || 8);

// ★ Normalize to an 8-hour basis before ranking
c.fund8 = c.fr * (8.0 / ivh(c.bin));

Risk Parity: Make Each Coin Contribute the Same Amount of Risk

Volatility differs enormously across a meme-coin universe. Within the same candidate set, four-hour volatility can range from 15 basis points to 200 basis points. If notional amounts are allocated equally, the two or three most volatile coins can contribute more than 80% of the portfolio's risk while the rest are effectively irrelevant. On paper you may hold ten coins, but in practice you are betting on only two of them.

So within each leg, weights are assigned inversely to volatility:

function riskParity(g) {
    var iv = [], z = 0;
    for (var i = 0; i < g.length; i++) { var x = 1 / Math.max(5, g[i].sigma); iv.push(x); z += x; }
    var w = []; for (var j = 0; j < g.length; j++) w.push(iv[j] / z);
    return w;
}

Among all the improvements I tried, this was the only one that improved all three metrics across the full sample at the same time: the median increased from 36.5 basis points to 68.0, the win rate rose from 53% to 57%, and the worst single result narrowed from -2021 to -1422. This is not parameter fitting; it is structural. Once risk is distributed more evenly, portfolio performance is no longer determined by the luck of one or two coins.

At the portfolio level, another layer of target-volatility scaling is added. First estimate the volatility level of the current candidate portfolio. If it is above the target, reduce total exposure proportionally; if it is below the target, keep exposure at the cap:

var pv = 0;
for (var a = 0; a < L.length; a++) pv += wl[a] * L[a].sigma;
for (var b = 0; b < Sh.length; b++) pv += ws[b] * Sh[b].sigma;
pv = pv / 2 * 0.6 / 1e4 * 100;                         // Residual volatility estimate after long/short hedging
var scale = pv > 0 ? Math.min(1, TARGET_VOL_PCT / pv) : 1;
var gross = GROSS_MAX_USDT * scale;

The point of this is to make the return distribution more predictable. Meme-coin markets can be extremely quiet at times and explode all at once at others. Fixed notional exposure means your true risk can drift by several multiples depending on market conditions. Target-volatility scaling smooths that drift, at the cost of automatically reducing positions when the market is at its most violent — which is exactly when they should be reduced.

Unified Account: Unrealized Losses on Long and Short Legs Offset Each Other

This is one of the easiest things to overlook in live trading for this kind of strategy, yet it has one of the largest impacts on survival.

Suppose you hold ten longs and ten shorts. Under isolated margin, maintenance margin is calculated independently for each leg. Any single leg that reaches its liquidation threshold can be forcibly liquidated — even if the portfolio as a whole is profitable. Intraday swings of 20% are common in meme coins, so under isolated margin this is almost guaranteed to happen eventually.

Under a unified-account cross-margin mode, unrealized profits and losses on the long and short legs offset each other at the account level. When the whole sector rises, unrealized profits on the long leg directly offset unrealized losses on the short leg. With the same notional exposure, the maintenance-margin ratio is far higher than under isolated margin. For a market-neutral long-short portfolio, this is not optional; it is required.

The strategy displays a reminder about this at startup. Leverage is also recommended to stay below 3x. Leverage is for improving capital efficiency, not for amplifying the signal. The strength of the signal itself does not become stronger just because leverage is higher.

Rotation Frequency: Faster Is Not Always Better

The composite score changes in real time, so in theory the portfolio could be reranked every five minutes. I tested this directly, running nine different rotation intervals from five minutes to 24 hours on the same batch of data. The conclusion was very clear:

Anything within one hour loses money. Turnover is extremely high at every interval — out of 20 legs, 16 to 19 need to be replaced each period, which shows that rankings are themselves highly unstable at short horizons. The higher the frequency, the more fees you pay, while the incremental signal you capture becomes smaller.

The 12-hour and 24-hour numbers are higher, but there are only 83 and 41 samples respectively, and the gap between median and mean is enormous (for the raw 24-hour signal, the median is -22.62 while the mean is +151.45). That means the return is supported by only a few large wins. The four-hour interval is different: median +12.23, mean +17.30, 53% win rate, and 249 samples. The median and mean have the same sign and are close to each other — the typical trade is profitable rather than the result being propped up by the tail.

There is also a structural reason for four hours: nearly half the contracts in the universe settle funding every four hours, so the rotation interval lines up with the funding settlement interval. That is why the default parameter is set to four hours.

Execution Layer: Incomplete Positions Are Not Allowed to Exist

The strategy is supposed to hold 20 legs at the same time. In a backtest, that is one line of code, and every leg is assumed to fill at the mid-price. Live trading is not like that.

At first I wrote a “failed leg counter.” If one leg could not be opened, I recorded the failure and abandoned the round after the count exceeded a threshold. After writing it, the design felt wrong. Eventually I realized why: a failed leg should not be counted. It should be eliminated.

This is a market-neutral strategy, and all of its safety comes from the two sides offsetting each other. If the plan is 10 longs and 10 shorts, but only nine longs and seven shorts actually fill, what you hold is no longer a neutral portfolio. It is a directional net-long bet of two legs — while you may still think you are neutral. The risk model becomes invalid at that moment. Worse, the imbalance does not heal itself. Until the next rotation, you may carry that incorrect exposure for the entire four-hour period.

So the first layer is in the planning stage: untradeable legs are removed directly, and the opposite side is trimmed at the same time to guarantee that the number of legs and notional amounts on both sides remain strictly equal. If one side cannot assemble enough valid contracts, reduce the number of legs for the entire portfolio and try again — from 10 pairs to 9 pairs, then 8 pairs — until both sides qualify.

The second layer is in the execution stage, looping until the actual positions match the targets exactly:

function strictOpen(targets) {
    S.execState = 'OPENING'; _targets = targets; saveState();
    while (n++ < MAX_REPAIR_LOOP) {
        if (!cancelAll(list)) { Sleep(ORDER_SETTLE_MS); continue; }   // Cancel orders first and confirm nothing remains
        var pq = queryPos(true);
        if (!pq.ok) { Sleep(ORDER_SETTLE_MS); continue; }             // Position query failed → never submit orders
        if (exactMatch(pq.positions, targets)) {
            var v = queryPos(true);                                    // Second confirmation
            if (v.ok && exactMatch(v.positions, targets)) {
                S.execState = 'HOLDING'; saveState(); return true;
            }
            continue;
        }
        submitDiff(pq.positions, targets, LIMIT_FIRST && n <= 2);       // Submit only the position difference
    }
    strictClose('Entry failed to converge');
    return false;
}
// Quantity comparisons must convert values to integers at the instrument precision;
// direct floating-point equality comparisons will never match reliably.
function qtyU(f, q) { return Math.round(Math.abs(q) * Math.pow(10, spec(f).ap)); }

There is one rule here that cannot be omitted: if the true positions cannot be queried, all order submission must be prohibited. API errors, malformed responses, rate-limit rejections — under any of those conditions, do nothing. Sending orders when you do not know what positions you actually hold is one of the most classic types of trading-system accidents.

Finally there is a net-exposure guard. Every time positions are reconciled, the strategy calculates the deviation between total long notional and total short notional. If it exceeds 8%, all positions are immediately closed and the system starts again. This also determines an execution trade-off: limit orders can reduce fees but may fail to fill; failed fills mean the legs are unbalanced. So the first two repair rounds use limit orders in an attempt to obtain maker execution, while the third round onward switches to market orders to force completion. For a neutral strategy, exposure imbalance is more dangerous than paying a little more in fees. That priority must not be reversed.

牛来 is only the starting point. On the day it listed, its amplitude, volatility, and lower-wick depth were all near the top of the market. It is simply the newest sample in this category of speculative coins. The strategy itself does not depend on it at any point. The target is not one specific coin; it is the entire cross-section. Today the strongest name may be 牛来. Next week it may be another newly listed meme. The week after that, it may be an old coin that suddenly attracts capital again. You do not need to know which one comes next. You only need to ask every four hours: “Who is strongest now, and who is weakest?” Then let the positions follow the answer.

That is also the difference between this strategy and “chasing hot themes.” Chasing a theme is a bet on one specific asset, and your odds depend on whether you picked the right one. Cross-sectional rotation is a bet on the statistical property that “dispersion between strength and weakness will persist.” If you choose one individual name incorrectly, the other nine legs dilute the mistake. The more volatile the meme-coin sector becomes, the more visible this dispersion tends to be. The high volatility that most strategies fear is precisely the fuel for this type of strategy.

Can the Displayed 24h Change Affect Short-Term Prices? — Implementing a Roll-Out TradFi Strategy in FMZ Rust

Dream — Fri, 04 Sep 2026 02:19:53 +0000

This article studies a behavioral-finance hypothesis created by a rolling statistical window. Instead of directly forecasting future prices, we calculate in advance how the 24h percentage change traders will see over the next several dozen minutes will mechanically evolve, and then observe whether price responds to that change in attention. The current strategy does not directly measure aggressive order flow, so the transmission mechanism discussed here is a plausible pathway rather than a proven causal relationship between order flow and price.

1. A Number That Looks Almost Too Ordinary to Matter

Almost every crypto trading interface places the 24-hour percentage change in a highly visible position. Top-gainer lists, top-loser lists, contract tables, and mobile market pages all keep reinforcing this number.

We usually interpret the 24h change as “what happened over the last day,” but it is actually a continuously moving window:

Its evolution is jointly determined by two components:

What the current price (P_t) does next — unknown.
How the price from 24 hours ago, P_{t-24h} , leaves the rolling window — already observed and therefore known.

Suppose price rallied sharply yesterday between 14:00 and 14:30. When the market reaches the same time today, that rally gradually rolls out of the 24-hour window minute by minute. Even if the current price does not move at all, the displayed 24h gain will mechanically decline. Conversely, when a sharp selloff from yesterday rolls out, the displayed return will mechanically improve.

That fact by itself is only a mathematical identity, not Alpha. The hypothesis that actually needs to be tested is:

Predictable change in the displayed statistic
                ↓
Changes in rankings, screeners, and trader attention
                ↓
Trading behavior may change
                ↓
Potentially tradable price drift

In other words, the strategy is not directly predicting price. It is predicting what market participants are about to see.

2. What Public Research Gives Us as a Starting Point

The idea was popularized by Robot James in the article A Truly Idiotic Crypto Trade, and was later reproduced on a large historical sample by the open-source project OctopusTakopi/24h-rollout-effect, using Binance USDT perpetual-futures archives.

Robot James article:

https://robotjames.substack.com/p/a-truly-idiotic-crypto-trade

Public replication:

https://github.com/OctopusTakopi/24h-rollout-effect

The coarse-grained public rule is simple:

When the largest positive hourly candle from exactly 24 hours ago begins to roll out, short for one hour.
When the largest negative hourly candle from exactly 24 hours ago begins to roll out, go long for one hour.

The replication covers 788 Binance USDT perpetual contracts from 2020 to 2026, including delisted contracts. Its results support the presence of a 24h Roll-Out anomaly in the historical sample. Placebo tests over candle ages from 1 to 24 hours show that the effect is concentrated specifically around the 24th hour.

But the research also provides a conclusion that matters more than the headline return: the raw signal is thin.

High turnover allows fees to consume much of the gross edge, funding costs erode it further, and spectacular results from concentrated full-capital backtests often mix together path luck, compounding mathematics, and tail risk. In the public sample, most of the more recent edge is concentrated on the short side, while a single extreme move against a short position can wipe out the profits from a large number of ordinary trades.

So the public result is enough to justify further research. It is not enough to declare that a production-ready strategy already exists.

The original contribution of this article is not to rediscover the 24h anomaly. It is to convert the idea into a continuous minute-level model, transfer it into Binance's TradFi perpetual market, and implement a complete FMZ Rust prototype that is observable, simulatable, and capable of live execution.

3. Why Not Simply Short Anything That Is Up a Lot Over 24 Hours?

The current 24h percentage change can be used as an attention signal, but it does not determine the trading direction.

Suppose a contract is currently up 20%, but the corresponding price path 24 hours earlier was almost flat. In that case there is no meaningful Roll-Out catalyst scheduled to occur over the next half hour. Shorting merely because the asset is “up a lot” would be nothing more than a conventional reversal strategy.

This strategy therefore keeps two concepts strictly separate:

Current 24h Change       = Attention Filter
Expected Roll-Out Shock = Alpha Trigger

The first is used to reduce the universe that requires deep monitoring. The second is what determines the candidate direction.

4. Turning a Single Hourly Candle into a Continuous Roll-Out Curve

An hourly rule implicitly assumes that all the information arrives at the top of the hour. Real price paths are continuous.

Price changes from yesterday at 14:05, 14:12, and 14:27 roll out of the 24h calculation today at the corresponding times. They do not disappear all at once at 14:00.

Let the current price be P(t) , and let the current starting point of the 24-hour window be P(t-24h). Assume, only for the purpose of calculating the mechanical display effect, that the current price remains unchanged over the next h minutes. The mechanical change in the displayed 24h return is then:

Therefore:

Shock(30) > 0: the displayed return is expected to mechanically improve, so the candidate direction is Long.
Shock(30) < 0: the displayed return is expected to mechanically deteriorate, so the candidate direction is Short.
Shock(5) and Shock(30) must have the same sign, so the old price path does not first move against the eventual direction.
The five-minute shock must also reach a minimum intensity, so the 30-minute signal is not concentrated almost entirely at the far end of the window.

A simplified example:

Current price                               120
Current start of the 24h window            100
Price 24h ago, 30 minutes later            115

Displayed 24h gain now                   +20.0%
Displayed gain in 30m if price is flat    +4.35%
Shock(30)                                -15.65 percentage points
Candidate direction                       SHORT

The -15.65 percentage points represent the mechanical change in the displayed statistic. They do not mean that price is forecast to fall by 15.65%.

How much, if any, of that display shock is reflected in price must be answered empirically.

The strategy's core calculation maps directly to the formula. The final direction is determined solely by the sign of Shock(30):

signal.shock_5_pct =
    100.0 * current * (1.0 / old_5 - 1.0 / old_now);

signal.shock_30_pct =
    100.0 * current * (1.0 / old_30 - 1.0 / old_now);

signal.direction = if signal.shock_30_pct > 0.0 {
    1
} else if signal.shock_30_pct < 0.0 {
    -1
} else {
    0
};

5. Why the First Version Targets TradFi Perpetuals

Binance TradFi perpetuals map equities, ETFs, commodities, and other traditional-market exposures into USDT-margined perpetual contracts.

This environment is interesting for several reasons:

The products are still presented inside a crypto-style interface with 24h percentage changes and rankings.
Traditional-market opens, closes, pre-market, after-hours, and overnight sessions may create more structured historical price paths.
TradFi perpetuals have different participant mixes, liquidity profiles, and information rhythms from purely crypto-native assets, making them useful for testing whether the mechanism transfers.
On the test account used during development, the displayed maker fee for these products was zero. That makes it easier to observe a thin gross signal at the research stage. This was only the fee state of a specific account at a specific point in time and must not be generalized to other accounts or future fee schedules.

A zero maker fee does not mean zero trading cost.

Queue failure, adverse selection, bid-ask spreads, funding, and emergency-exit slippage still exist. The prototype therefore uses real order-book data and maker-fill constraints instead of assuming that sending a resting order means it has been filled.

More importantly, the public historical replication validates Binance crypto USDT perpetuals, not the TradFi submarket studied here.

Transferring the mechanism to TradFi perpetuals is a new hypothesis that still needs to be validated. The historical crypto results cannot be borrowed as evidence of profitability in the TradFi market.

6. Data Architecture of the FMZ Rust Prototype

The first version uses a light full-market scan + deep tracking of a small candidate set architecture:

Binance exchangeInfo
        │
        └── Dynamically discover TradFi perpetuals

Binance all-market WebSocket 24h ticker
        │
        └── Attention Scanner
                 │
                 └── Top-N candidates
                        ├── ~25h of recent 1m klines
                        ├── ticker
                        ├── bookTicker
                        ├── aggTrade
                        └── 1m kline
                                  │
                                  └── Roll-Out Engine

At startup, REST is used only to read the contract directory.

During normal operation, all-market market data and incremental candidate data are primarily consumed over WebSocket. The main loop uses non-blocking reads, so waiting for market data does not stop order reconciliation or state updates.

The universe is not based on a manually maintained whitelist. Instead, the strategy reads contract metadata and keeps only instruments that are actively trading, quoted in USDT, and identified as TradFi perpetual products:

let subtype_tradfi = subtypes.map(|values| values.iter().any(|value| {
    value.as_str()
        .map(|text| text.eq_ignore_ascii_case("TradFi"))
        .unwrap_or(false)
})).unwrap_or(false);

let tradfi_contract =
    contract_type.eq_ignore_ascii_case("TRADIFI_PERPETUAL")
    || subtype_tradfi;

if !tradfi_contract || status != "TRADING" || quote != "USDT" {
    continue;
}

The entire market is rescanned once per minute.

By default, the strategy first requires the absolute current 24h change to be at least 4%, then ranks candidates using the absolute 24h change plus a modest quote-volume weight. Only the top six candidates maintain minute history and detailed data streams.

This avoids repeatedly downloading roughly 1,500 one-minute bars for hundreds of contracts.

A candidate must have at least 1,475 valid one-minute bars, deduplicated by timestamp.

When calculating the Roll-Out window, the implementation prefers the actual rolling-window start and end times reported by the ticker instead of blindly assuming that the window is always aligned with the local minute boundary.

There is one v0.1.6 implementation boundary worth monitoring: if the initial history bootstrap for a candidate fails, bootstrap_requested_at is not automatically cleared within the current process, so the strategy will not automatically issue a second bootstrap request.

If SHADOW mode remains stuck at HISTORY_NOT_READY, first check the network and API response, then restart the strategy. A future version should replace this behavior with automatic retry and backoff.

7. Signal Rules in the First Version

Under the default parameters, a candidate must satisfy all of the following conditions:

abs(Current24hChange) >= 4%
abs(Shock30) >= 0.8 percentage points
abs(Shock5) >= 0.8 × 0.08 percentage points
Shock5 and Shock30 have the same sign
The ticker is no more than 20 seconds old
Immediately before entry, book and trade data are no more than 5 seconds old
Bid-ask spread is no wider than 30 bps

The design is intentionally simple.

The original research material also discusses rank effects, open interest, funding, aggressive buy/sell flow, and Probe-then-Build position scaling. All of those modules are deliberately postponed in the first version.

Otherwise, if performance changes, it becomes difficult to determine which component was responsible.

The gating order in code is also kept interpretable: first attention, then 30-minute shock intensity, then confirmation that the first five minutes do not point in the opposite direction.

if signal.current_change_pct.abs() < AttentionThresholdPct {
    signal.reason = "ATTENTION_LOW".to_string();
} else if signal.shock_30_pct.abs() < MinShock30Pct {
    signal.reason = "SHOCK_LOW".to_string();
} else if signal.shock_5_pct.abs() < MinShock30Pct * 0.08 {
    signal.reason = "EARLY_INTENSITY_LOW".to_string();
} else if signal.shock_5_pct.signum() != signal.shock_30_pct.signum() {
    signal.reason = "PATH_NOT_MONOTONIC".to_string();
} else {
    signal.ready = true;
    signal.reason = "READY".to_string();
}

8. Three Operating Modes

The strategy supports three modes:

PAPER mode does not simply assume that a signal is filled at the displayed quote.

In v0.1.6, the strategy first leaves a two-second propagation grace period, then compares newly observed aggTrade prices with the resting order price.

For a buy order, the observed trade price must be no higher than the resting buy price. For a sell order, the opposite condition applies.

A single entry order may wait for up to 90 seconds, but it is canceled early if the signal becomes invalid, data becomes stale, or the resting price falls more than 10 bps behind the current best quote.

let is_buy =
    (execution.order_purpose == "ENTRY" && execution.direction == 1)
    || (execution.order_purpose == "EXIT" && execution.direction == -1);

if is_buy {
    symbol.last_trade <= execution.order_price
} else {
    symbol.last_trade >= execution.order_price
}

This is still only an approximate fill model.

It does not simulate queue position, and the current version does not record a per-order trade sequence number at order creation. Therefore, it cannot strictly prove that the trade used to infer a fill occurred after the simulated order entered the queue.

PAPER results are appropriate for screening implementation problems. They should not be treated as an exact historical reconstruction of real maker fills.

9. Maker Execution and the Single-Position State Machine

The first version allows at most one event position at a time:

IDLE
  └── READY ──> ENTRY_WORKING (GTX Maker)
                    ├── Timeout without fill ──> IDLE
                    └── Filled ──> POSITION
                                  └── Exit condition ──> EXIT_WORKING
                                                        ├── Maker fill ──> IDLE
                                                        └── Residual position
                                                            ──> Market cleanup

Normal entry and exit orders use GTX/Post-Only orders to prevent a limit order from accidentally becoming a taker.

The default target notional is 50 USDT.

Order quantity is not sent simply as:

notional / price

Instead, the strategy first reads CtVal, amount step, price step, and minimum notional from GetMarkets(), then converts the desired quote-currency notional into the actual number of exchange contracts.

let quote_per_contract =
    contract_quote_value(spec, meta, price)?;

let amount =
    round_amount(spec, notional / quote_per_contract);

let actual_notional =
    amount * quote_per_contract;

if actual_notional + 1e-9 < spec.min_notional {
    return Err(format!(
        "notional {} < MinNotional {}",
        actual_notional,
        spec.min_notional
    ));
}

The first version uses the following fixed exit conditions:

Position return at or below -0.4%: stop loss
Position return reaches +0.6%: take profit
Maximum holding time of 30 minutes
Signal direction reverses
Remaining 30-minute Shock falls below 20% of its value at entry, meaning the catalyst has largely decayed

The stop loss is treated as an emergency exit and may use a market order to remove the remaining position immediately.

Normal exits first attempt to use a maker order.

The objective is to control tail risk, not to preserve a zero-fee assumption at all costs.

10. Why “Order Not Found” Immediately After Submission Does Not Mean the Order Does Not Exist

There can be a short propagation delay between:

the exchange accepting an order;
the order becoming visible in the open-order list;
the order becoming queryable through historical-order endpoints.

Therefore, querying immediately after submission and receiving null or “order not found” does not prove that the order was never created.

It certainly does not justify blindly sending another identical order.

The prototype uses a two-second propagation grace period, but it does not block the strategy with Sleep(2000).

The order state machine continues running. During the grace period, temporary invisibility is treated as propagation rather than failure.

After the grace period, the strategy checks, in sequence:

Current open orders
Recent historical orders
Single-order query

This allows WebSocket data, the status panel, and other reconciliation tasks to continue operating while reducing the risk of duplicate orders caused by temporary invisibility.

11. In Live Trading, the Hard Part Is Not Sending an Order — It Is Managing Uncertainty

In LIVE mode, the strategy persists the order intent before calling CreateOrder.

Only after it receives a non-empty order ID and persists the updated state does it clear the pending intent.

The core sequence is only three steps, but the order matters:

Persist the Intent
Send the order
Update local order state only after the result is unambiguous

The following code is a compressed version of the critical path. The full strategy later distinguishes between an explicit maker rejection, a known failure, and an unknown result:

state.pending_intent = Some(intent);
save_state(runtime, state)?;

let create_result = exchange.CreateOrder(
    symbol.meta.fmz.as_str(),
    side.as_str(),
    price,
    amount
);

If the network fails at the exact moment when the exchange has accepted the order but the strategy has not yet received the order ID, the strategy does not blindly resend.

Instead, it enters an automatic reconciliation state and uses non-blocking queries against open orders, recent order history, and positions.

If the original order is found, the strategy takes ownership of it.

If a matching position is found, the local position state is reconstructed.

Only after three consecutive reconciliation attempts succeed and the account is confirmed clean does the strategy conclude that the request did not create an order and resume normal operation.

There is another narrower edge case.

If CreateOrder follows its success-return path but returns an empty order-ID string, v0.1.6 retains the Intent and enters a conservative halt state.

Automatic reconciliation still continues, but the halt flag may not clear automatically in exactly the same way as an ordinary “unknown result” branch.

Before unattended LIVE deployment, this empty-ID path should be tested explicitly.

If it occurs, first verify open orders, historical orders, and positions. Do not simply restart and resend.

This design addresses one of the most dangerous realities in automated execution:

A failed return value
        ≠
The exchange definitely did not execute

The strategy also refuses to enter automatically if the target contract already has an external order or external position.

Cancellation uses only strongly typed order IDs obtained from the current reconciliation query.

Closing direction is delegated to FMZ's closebuy / closesell semantics instead of manually assembling reduceOnly flags.

12. Why There Are Only Four Parameters

The deep-tracking candidate count is fixed at six and is not exposed as a tuning parameter.

Runtime interaction is also deliberately limited to a single pause/resume-entry control.

Having few parameters does not mean the model is simplistic.

The goal is to make the first batch of samples interpretable.

At this stage, the most important questions are not about optimizing the backtest curve. They are:

Does the displayed Shock in TradFi perpetuals correspond to subsequent price drift?
Is there a stable gradient as Shock intensity increases?
After accounting for unfilled orders, funding, and emergency exits, is any return left?

13. A Real WebSocket Failure and How It Was Fixed

A LIVE screenshot from v0.1.1 once showed:

LIVE / v0.1.1                 RUNNING
TradFi 174 / selected 0
WS age = 2100 ms
reconnects = 2
scan #1 / RUN
execution = IDLE
halt = false

The REST contract-directory logic and execution state machine had indeed started.

However, continued observation showed that the reconnect counter increased approximately every 20 seconds.

After checking Binance's current WebSocket documentation, the issue became clear.

v0.1.1 had mixed the all-market !ticker@arr, symbol ticker, aggTrade, kline, and bookTicker subscriptions on /public/stream.

The current USDⓈ-M WebSocket interface separates the stream paths: ticker, trade, and kline-style market streams belong to the market path, while order-book streams such as bookTicker belong to the public path.

Therefore, the screenshot's WS age only showed recent connection or control-message activity. It did not prove that valid market data was being received.

Likewise, selected 0 could not be interpreted as evidence that no contract had crossed the 4% attention threshold.

This incident demonstrates an important principle:

A successful WebSocket handshake does not prove that the subscription is valid. Liveness monitoring should be refreshed only by real business data.

v0.1.2 made four changes:

Market and Book data use two separate WebSocket connections and subscription sets.
Subscription acknowledgements, error replies, and actual market-data messages are handled separately.
After reconnection, status shows WAIT_DATA rather than pretending that the connection timestamp is the latest market-data timestamp.
When candidates change, detailed streams for candidates that leave the tracked set are unsubscribed so the subscription set does not grow indefinitely.

The healthy-state criteria after the fix are:

Market status remains DATA_OK.
Market age repeatedly falls back toward zero as new data arrives.
Reconnect count does not increase on a fixed ~20-second cycle.
When candidates exist, Book status should also remain DATA_OK.
With no candidates, Book status should display IDLE.

Subsequent LIVE validation exposed another important boundary: a GTX Maker order can be explicitly rejected because the market moves while the request is in transit.

That situation is fundamentally different from a network timeout that leaves the execution result unknown.

Starting in v0.1.3, the strategy preserves both the Rust Err and GetLastError() evidence.

An explicit maker rejection only triggers a short cooldown.

v0.1.4 then removed the manual recovery mechanism for genuinely unknown execution outcomes.

An unresolved Intent is latched, and a non-blocking state machine automatically queries open orders, recent order history, and positions.

If an order is found, the strategy adopts it.

If a matching position is found, the local position state is reconstructed.

Only after three consecutive successful reconciliation cycles show a clean account is the request classified as not having created an order, after which the strategy automatically resumes.

LIVE testing also exposed a repeated-order problem under persistent signals:

Rest order for 20 seconds
→ cancel
→ submit again
→ cancel
→ submit again

This strategy is a time-effect-driven directional strategy, not a market maker that continuously maintains the best quote.

Frequent cancel-replace behavior sacrifices queue priority and can end up chasing a price that has already moved.

v0.1.6 therefore changed the logic so that each continuous signal may create only one maker entry order.

That order may wait for up to 90 seconds.

It is canceled early if:

the signal becomes invalid;
market data becomes stale;
the order falls more than 10 bps behind the current best quote.

Whether the order fills or not, the strategy must then wait until either:

the direction reverses; or
attention/Shock falls back into a lower hysteresis reset zone

before the signal is armed again.

This prevents threshold noise from repeatedly generating new orders.

Partial fills are converted directly into a position. The strategy does not chase the remaining target quantity.

The Paper PnL field remains zero in LIVE mode.

It is only a simulation-performance field retained in the shared status layout and should not be used to judge real-account performance.

A future version would benefit from separate LIVE realized-PnL and fee accounting.

Even after the data path is functioning correctly, a runtime screenshot proves only that the system is receiving and processing data.

It does not prove that the signal is valid, and it certainly does not prove that the strategy is profitable.

14. How the Strategy Should Be Validated Instead of Looking Only at Total Return

The most useful next step is to accumulate event-level observations and evaluate them using the following structure.

1. Shock-Intensity Gradient
Bucket events by abs(Shock30) and measure side-adjusted 5-, 15-, and 30-minute forward returns.

A credible mechanism should generally strengthen as Shock intensity rises.

If only one isolated bucket happens to be profitable, that is not stable evidence.

2. Separate Long and Short
The public crypto research shows strong directional asymmetry and regime changes.

TradFi samples must also be evaluated separately by side.

A combined average can easily hide the failure of one side.

3. 24h Placebo Tests
Repeat the same calculation using neighboring windows such as 20h, 21h, 22h, and 23h.

If every horizon appears “effective,” the observed return may simply be trend, reversal, or intraday seasonality rather than a mechanism tied specifically to the 24-hour display window.

4. Fills and Trading Costs
At minimum, record:

Number of maker orders, fill rate, and timeout rate
Delay from signal creation to actual fill
Maximum favorable and adverse movement after entry
Funding cost, share of emergency market exits, and realized slippage
Performance under different bid-ask spread conditions

5. New Information Overwhelming the Weak Catalyst
Roll-Out is only a weak catalyst.

Earnings, macroeconomic data, company news, or broad crypto-market moves can completely dominate it.

Event-level samples should therefore tag traditional-market sessions and unusual market conditions so that stronger information shocks are not incorrectly attributed to the display statistic.

15. What the Current Version Explicitly Does Not Do

To avoid misunderstanding, v0.1.6 does not implement:

Multi-symbol concurrent positions
Probe / Build / Core staged scaling
Averaging down against the signal
Prediction of future full-market ranking positions
Open-interest, funding-rate, or aggressive-flow filters
A TradFi return model already proven by historical samples
A complete queue-position and market-impact model
Automatic backoff retry after the first historical-data bootstrap failure
Forced retention of bookTicker, aggTrade, and kline detailed subscriptions when an instrument with an active order or position falls out of the Top 6 candidate set

These are not “missing advanced features” that must be added immediately.

They are deliberately postponed until the basic hypothesis has been validated.

If there is no stable gradient from:

Shock → Future Return

then adding more parameters will only create more opportunities to overfit.

16. Conclusion

The most interesting part of the 24h Roll-Out effect is not that it appears strange.

It is that it turns a vague behavioral-finance story into an event that can be calculated in advance:

We already know which segment of historical price action will be removed from the rolling statistic next.

But there is still a long chain between a mathematically predictable change in a displayed statistic and genuinely tradable return:

Displayed-number change
        ↓
Attention
        ↓
Order flow
        ↓
Fill probability
        ↓
Fees and funding
        ↓
Tail risk
        ↓
Realized return

Public crypto research suggests that the historical anomaly exists but is fragile.

The TradFi prototype in this article attempts to answer the next question using a more continuous, restrained, and observable implementation.

A credible first version should not rush to prove that it makes money.

It should first ensure that:

the data path is reliable;
the signal has a clear meaning;
every order state can be reconciled;
failures do not create duplicate orders;
both positive and negative results are recorded in a form that can be explained later.

That is the role of this FMZ Rust prototype.

Strategy

The strategy is still a prototype and may be adjusted or upgraded as more real-world observations are collected.

It is shared as a research implementation for discussion and learning. Anyone considering live deployment should independently evaluate, analyze, and optimize it.

Risk Warning: This article and the accompanying strategy are intended solely for quantitative research and engineering validation and do not constitute investment advice. Perpetual contracts can experience large gaps, liquidity collapse, abnormal funding rates, and forced liquidation. As more participants discover a historical anomaly, the effect may weaken or disappear.

Adaptive Conditional Probability Modeling: A Practical Exploration and Implementation for Binary Markets

Dream — Thu, 27 Aug 2026 08:24:09 +0000

I had wanted for some time to build a relatively complete model for binary markets.

At first glance, these markets look simple. Take Polymarket's 15-minute BTC Up/Down market as an example: each round has only two outcomes. If the settlement price finishes above the benchmark price, Up wins; otherwise, Down wins. There is no complex payoff curve, nor the large matrix of strikes and maturities found in traditional options.

But once you try to turn the idea into a quantitative system, it becomes surprisingly difficult to find the right entry point.

If the task is reduced to predicting whether BTC will rise or fall next, the problem quickly becomes another moving-average, momentum, breakout, or order-flow strategy. If we simply treat the Polymarket contract price as the probability, it becomes difficult to answer another important question: has the market price already incorporated the information we currently observe?

When I revisited Bayesian ideas recently, a different framing occurred to me: perhaps what a binary market really requires us to model is not direction, but conditional probability.

Here,Y is the final settlement outcome, while X_t represents the information observable at time t, including BTC's position relative to the benchmark price for the current round, remaining time, volatility across multiple horizons, short-term drift, the price path, and the uncertainty of the information currently available.

The question therefore changes from:

Will BTC go up?

to:

Given the conditions that have already occurred, what is the probability that BTC will ultimately finish above the benchmark price?

This may sound like a simple change in wording, but it determines the architecture of the entire system.

Why Conditional Probability Fits Binary Markets

Suppose the Up contract can currently be bought at 0.58. Temporarily ignoring trading frictions, we can interpret that as the market assigning Up a price of roughly 58%.

If our model also estimates the probability at 58%, then even if the directional conclusion is Up, there is no trading value. A trade becomes potentially interesting only when the model's conditional probability differs sufficiently from the price we can actually execute.

We therefore need two separate quantities:

The second quantity,q_t , cannot simply be the best Ask displayed on the page. A real order may consume multiple levels of the order book, while fees and slippage also matter.

The implementation therefore walks through Ask depth using the intended purchase quantity, calculates the full VWAP, and then computes the expected absolute profit per token:

The corresponding code is:

fn expected_value(prob: f64, buy_vwap: f64) -> f64 {
    prob * (1.0 - FEE_RATE)
        - (buy_vwap + SLIPPAGE) * (1.0 + FEE_RATE)
}

A winning binary contract ultimately pays 1, while a losing contract pays 0. The expression above therefore represents the expected number of dollars earned per token rather than an abstract rate of return.

The current entry threshold is 0.025. In other words, after estimated fees and slippage, each token must still retain at least 2.5 cents of expected edge.

This is also the most important difference between a conditional-probability model and an ordinary directional indicator.

A directional indicator tells us whether the market currently leans bullish or bearish. A probability model tries to answer how likely a specific final outcome is under the current state. The execution layer then asks whether that probability can actually be monetized at prices available in the real order book.

Polymarket prices naturally contain a great deal of information, but there is an easy circularity trap here. If the market price is used as an input feature and the model output is then compared with that same market price to calculate EV, the model can end up in a circular argument: the market price helps generate the forecast, and the forecast is then used to claim that the market price is wrong.

For that reason, I keep the two information paths separate:

Binance market data and the official benchmark price generate an independent terminal probability.
The Polymarket order book is used only for trading prices, depth, spread, and execution cost.

Finding OpenMarket: A Research Framework Honest Enough to Be Useful

While looking for related work, I came across Gregory Young's open-source OpenMarket project and the paper OpenMarket: A Synchronized Polymarket-Binance Dataset for High-Frequency Prediction-Market Research.
OpenMarket GitHub:

https://github.com/gregyoung14/openmarket

Paper:

https://arxiv.org/abs/2607.26245
The project studies exactly the relationship between Binance BTC/USDT market data and Polymarket's 15-minute BTC binary markets.

The author built a fairly complete research framework: millisecond-level Binance trades and Polymarket order books are collected and synchronized; 43 features are constructed across time, returns, volatility, order flow, and market microstructure; and terminal probabilities are then evaluated using Logistic Regression, Platt Scaling, and walk-forward validation.

What I find especially valuable is that the author does not package the results as a story about having discovered stable arbitrage.

The paper's conclusion is much more honest: the public 43-feature model does not consistently outperform the probability implied by the Polymarket order book out of sample. After fees, spreads, and slippage are included, the model also does not produce a trading edge that can simply be declared effective.

That does not make the framework less useful. For quantitative research, a negative result with public features, data, model parameters, calibration methods, and out-of-sample results is often more valuable than a "successful strategy" that shows only an equity curve and cannot be reproduced.

At a minimum, OpenMarket answers three important questions:

What data should be collected?
How can short-horizon market state be transformed into a conditional probability?
How should probability-fitting ability be separated from actual tradability?

I retained the data-collection part of this research framework. The 43 stage features are written to the database every five seconds, and the final label is added after settlement. These records can later be used for stage-bucketed training and out-of-sample validation.

For now, however, the fixed feature weights do not directly participate in the live trading probability.

The reason is concrete. At the 60-second mark, a 180-second return does not yet exist, and a feature called "180-second volume" actually contains only 60 seconds of data. By the tenth minute, that same feature name finally refers to a complete 180-second window.

If one uncalibrated set of weights is used from a few seconds after market open all the way to minute 14, the feature names may stay the same while their statistical meaning changes substantially.

So this implementation does not rush a complex model into the production decision path. Instead, it starts from the terminal event itself and builds a transparent probability baseline that can be inspected directly.

Starting with the Distance to the Terminal Event

Predicting the 15-minute result at minute 1 does not mean knowing the future. It means estimating a terminal probability under the current information set:

where:

K is the official Price-to-Beat for the current round;
S_t is the current BTC reference price;
\tau is the remaining time;
\sigma_t is the estimate of future volatility;
\mathcal represents the information already available at time t.

The most basic standardized distance is:

The formula itself is not complicated. The difficult part is estimating volatility and drift.

If a round has been open for only 15 seconds and we extrapolate those 15 seconds of volatility over the remaining 885 seconds, the result can be seriously distorted. If the most recent seconds happen to be quiet, the denominator becomes too small. If those seconds happen to be strongly directional, the drift estimate can become too large.

The combination can easily create false certainty shortly after market open.

For that reason, volatility is not estimated only from data inside the current round.

The system builds one-second closes from the Binance real-time trade stream and combines realized volatility over 60-second, 5-minute, 15-minute, and 30-minute windows:

let windows = [
    (60usize, 0.15),
    (300usize, 0.25),
    (900usize, 0.30),
    (1800usize, 0.30),
];

for &(window, weight) in windows.iter() {
    if available >= window * 3 / 4 {
        let vol = realized_vol(&close, window);
        variance += weight * vol * vol;
        total_weight += weight;
    }
}

This allows the model to use pre-open price history to estimate remaining volatility even when a new round has just started.

The system also imposes a conservative floor on per-second volatility so that an accidentally quiet short sample does not push the estimated probability toward an extreme.

Drift is handled even more conservatively.

The average return over the most recent 60 seconds is not simply multiplied by the entire remaining time. Instead, it is shrunk toward zero according to the number of effective observations:

The total contribution of drift to the terminal distribution is then capped at 0.25 times the remaining volatility:

let reliability = n as f64 / (n as f64 + 300.0);
let drift_total = drift_per_sec * remaining * reliability;

let drift = clamp(
    drift_total,
    -0.25 * remaining_sigma,
     0.25 * remaining_sigma,
);

Short-term trend is allowed to adjust the probability, but it is not allowed to turn a single trade into something that appears almost certain on its own.

During the first five minutes after market open, the system also reduces confidence in the probability's log-odds.

This is not an arbitrary rule saying that no trades are allowed during the first few minutes, nor does it force the probability to remain at 50%. It simply recognizes that the same price distance carries different information quality at different stages of the round.

As the stage data becomes more complete, the confidence coefficient gradually returns to 1.

The Central Probability Is Not Necessarily the Probability You Should Trade On

This is one of the most important steps in the entire framework.

The model's central probability tells us where the current estimate is centered. It does not imply that the estimation error is zero.

This matters especially just after market open, when volatility history is incomplete, or when the estimated probability itself is changing rapidly. If the central probability is used directly to calculate EV, the system can easily confuse uncertainty with certainty.

For the side the strategy is considering buying, it therefore uses a probability discounted by uncertainty:

The current implementation uses z_u=1.
The uncertainty term u_t has three components:

recent volatility of the probability sequence itself;
information deficiency during the early stage of the round;
the amount of volatility history currently available.

This is not another hard rule such as "wait for N warm-up observations before trading."

The first valid probability estimate is still calculated immediately. The difference is that less information leads to a lower tradable probability. Only if EV remains positive after this conservative discount does the candidate continue to the next stage.

One simulated log entry illustrates the distinction well.

At the 15-second mark, the central probability of Down was approximately 49.75%, while the contract Ask was 0.43. Looking only at the central probability, the system appeared to have more than six percentage points of room.

But after taking VWAP and slippage into account, the effective entry cost was approximately 0.435, while the full-position liquidation value was only 0.42. The position therefore started with an immediate mark-to-market loss of 5.36%.

After stage uncertainty was included, if the bot had a complete 30-minute volatility history, the tradable probability fell to approximately 44.81%, and fee-adjusted net EV was only 0.0043, below the 0.025 threshold.

If the bot had just started and only 15 seconds of volatility history were available, the tradable probability fell to approximately 41.96%, and net EV became negative.

The trade would therefore fail at the probability layer before reaching execution.

The point of adaptation here is not that the model continuously changes all of its parameters. The important adaptation is that the credibility of the probability changes with information quality.

FMZ Happened to Add Rust Support at the Right Time

Once the modeling framework was defined, the next question was how to implement something suitable for continuous operation.

FMZ happened to add Rust support, which made this architecture much easier to implement cleanly.

Rust is well suited to real-time data handling, fixed-dimension numerical work, and complex state management. Its compiler also catches many field, type, and ownership errors before the strategy is allowed to run.

The current framework requires only one Polymarket exchange object to be configured in FMZ.

Binance BTC/USDT data is consumed directly through the public WebSocket:

const BINANCE_WS_URL: &str =
    "wss://stream.binance.com:9443/ws/btcusdt@trade";

let mut binance_ws = Dial(BINANCE_WS_URL);

The Polymarket BTC 15-minute market is assembled deterministically from UTC time:

let start = (now_ms() / 900_000) * 900_000;
let slug = format!("btc-updown-15m-{}", start / 1000);

The system validates the market and retrieves token information through the Gamma Market API.

At the same time, it subscribes to Chainlink and TWAP60 data from Polymarket RTDS, keeping four concepts separate:

Binance real-time trade price;
Chainlink reference price;
current 60-second TWAP;
the fixed official Price-to-Beat for the current round.

These prices must not be treated as interchangeable.

The real-time price describes the current state. The Price-to-Beat defines the terminal event:

If the benchmark K is wrong, every probability calculation downstream becomes meaningless.

For that reason, the trading path requires the official openPrice. Alternative sources may be stored for research and comparison, but a current price near settlement must never be substituted for the official opening benchmark.

Multi-horizon volatility is updated and cached once per second. Terminal probability is recalculated roughly every 200 milliseconds, while the main loop polls data and manages state at approximately 50-millisecond intervals.

The implementation deliberately does not confuse "record features every five seconds" with "make a decision only every five seconds."

Five seconds is the research snapshot frequency, not the trading-response frequency.

Passing the Probability Test Still Does Not Mean an Order Will Be Sent

Even if uncertainty-adjusted EV reaches 0.025, the system does not immediately trade the first frame that appears profitable.

When a new market opens, the order book is often still being assembled. Quotes on both sides, available depth, and market-maker inventory can change very quickly.

A single qualifying EV observation means only that a candidate opportunity exists at that moment. It does not prove that the edge persists.

The system therefore maintains a very short entry-evidence state.

The candidate direction must remain unchanged, net EV must remain above the threshold for at least 1.2 seconds, and the signal must accumulate at least five valid updates.

If the direction changes, EV disappears, or an order-book check fails, the evidence counter is immediately reset.

let ready = evidence_count >= 5
    && now_ms - evidence_first >= 1_200;

if !ready {
    signal.decision = "EV confirmation pending";
    return;
}

The 1.2-second requirement is not a slow warm-up period. It is simply a way to distinguish persistent edge from a momentary order-book dislocation.

Immediately before submitting an order, the system reloads both the Up and Down books, checks whether their timestamps are synchronized, and validates the complementary relationship of the binary market:

It then calculates the fee-adjusted round-trip loss of buying now and immediately selling the entire position.

This check incorporates Ask depth, Bid depth, slippage, and fees on both sides. The current maximum allowed loss is 4%.

The earlier example that would begin with an immediate 5.36% loss would therefore be rejected by the execution layer even if the probability EV barely passed.

Position size uses one-fifth Kelly:

The final allocation is capped between 0.1% and 3% of account equity.

Therefore, if the simulation account has 100 USDC, the maximum capital committed to a single position is 3 USDC.

This is not a balance-reading error. It is an intentional cap on per-trade risk.

The probability model is not responsible for submitting orders directly.

It proposes a probability view that can be tested. The order book determines whether execution is available at acceptable terms. Persistent evidence, round-trip cost, and position sizing determine whether the probability view is worth expressing with real capital.

After Entry: Prediction Makes the Decision, Price Provides the Backstop

After a position has been opened, the system continuously calculates the VWAP at which the entire position could actually be sold instead of looking only at the best Bid.

Actual PnL is measured using the current executable liquidation value and the true cost basis:

The prediction side continuously calculates the EV of the current position:

A normal prediction-based exit is not triggered simply because the probability falls by a few percentage points.

Instead, the current holding EV must fall below -0.005 and decline by at least 0.025 relative to its prior level. This condition must then be confirmed three consecutive times for at least 600 milliseconds.

Once all conditions are met, the strategy exits with:

PREDICTED_EV_SHOCK_NEGATIVE

This means that if probability declines but the position's EV remains positive, the strategy continues to hold.

Conversely, even a probability change that does not look large can trigger an exit if it is sufficient to turn the original trading thesis into negative expected value.

On the price side, the system retains only one fixed stop line, determined at entry and never moved afterward:

The code is:

let fixed_stop_price =
    (position.vwap - 0.50).max(0.35);

The stop is not based on a percentage of entry cost, and it does not follow the highest Bid observed during the holding period.

This avoids triggering a trailing stop simply because the order book briefly spikes and then normalizes.

The strategy uses the executable VWAP obtained by walking through the entire Bid side to determine whether the stop has actually been breached.

A fixed take-profit at 0.95 is also retained.

This stop is better understood as catastrophe protection than as the normal prediction-management mechanism.

When the entry price is below 0.85, the stop line remains 0.35. With an entry price of 0.915, the stop becomes 0.415.

That can correspond to a large percentage loss on the token, which is why normal exits still rely primarily on predicted EV turning negative.

Whether this fixed stop is appropriately calibrated still needs to be tested against real holding paths and maximum adverse excursion.

The Database Gives the Research Time Continuity

A system like this loses much of its value if it cannot persist state.

If the bot restarts and all probability history, positions, and simulated-account state disappear, the research process itself becomes discontinuous.

The system uses FMZ DBExec to persist:

each market round;
the official benchmark price;
stage-feature snapshots;
probability sequences;
orders;
positions;
exit reasons;
settlement outcomes;
simulated balance;
risk state.

After a restart, the bot can recover unsettled positions instead of pretending that already-existing risk no longer exists.

Paper trading and live trading use the same state machine.

The difference is that paper fills do not send real orders. Instead, they update the internal ledger using full VWAP, slippage, and estimated fees.

Real-time logs explicitly display simulated buys and sells, position direction, quantity, cost, executable liquidation value, actual PnL, central probability, tradable probability, predicted EV, fixed stop price, and exit reason.

The status panel continuously shows:

Binance, Chainlink, TWAP, and the official benchmark price;
Up/Down central probabilities, stage uncertainty, and tradable probabilities;
real Ask prices on both sides, full VWAP, and fee-adjusted net EV;
accumulated entry evidence and reasons why no order has been sent;
current position cost, executable full-position value, and actual PnL;
holding EV, EV shock magnitude, exit-confirmation count, and fixed stop price;
recent trades, simulated balance, and cumulative realized PnL.

These records are not there to make the status table look complicated.

They are needed to answer one key research question:

Did the strategy lose because the probability forecast was wrong, or because the order book, slippage, liquidity, and execution costs prevented the forecast from being monetized?

If those two categories cannot be separated, later model optimization can easily move in the wrong direction.

This Is Still Only a Practical Research Experiment

I prefer to think of the current system as an adaptive conditional-probability experimentation platform rather than a fully validated trading strategy.

"Adaptive" here does not mean changing the model after every outcome, nor does it mean continuously feeding the market price back into the forecast.

What really needs to adapt is information quality.

The same price distance should not carry the same credibility at second 30 and minute 13.

Likewise, the same 50% central probability should not produce the same tradable probability or position size when one estimate has 30 minutes of volatility history behind it and another has only 15 seconds of data.

The current implementation first trades using a transparent terminal-distance model while continuing to store the 43 stage features and the final settlement label.

Once enough data has accumulated, the dataset can be divided into stage buckets such as:

0–1 minute;
1–3 minutes;
3–6 minutes;
6–10 minutes;
10–14 minutes.

Each bucket can then be evaluated out of sample using calibration curves, Brier Score, Log Loss, and actual executable trading returns.

Only if a feature set continues to provide incremental information beyond the Polymarket order book during the corresponding stage should it be allowed into the production probability model.

Otherwise, a more complex model merely adds more parameters to a simple hypothesis.

Future work can also explore:

conditional distributions across different market regimes;
jump risk caused by macroeconomic releases and breaking news;
First-Passage Probability;
regime-specific Logistic models;
dynamic volatility models;
nonlinear models.

But continuous validation matters more than adding complexity:

Are the probabilities calibrated?
Does the edge exist at prices that can actually be executed?
Can the expected return survive fees, spreads, slippage, and execution latency?

For a binary market, the difficult part is not simply deciding Up or Down.

The real challenge is repeatedly answering three questions:

Given the current conditions, what is the probability of the event?
How much confidence should we place in that probability?
Can the probability difference be realized after actual trading costs?
Placed back into the trading pipeline, the structure is roughly:

Central Probability
        ↓
Stage Uncertainty
        ↓
Tradable Probability
        ↓
Real VWAP + Fees
        ↓
Persistent EV Evidence
        ↓
Position Sizing and Exit

The prediction model proposes a view.

Market prices define the trading terms.

The execution layer determines whether that view can be monetized.

The risk layer limits losses when the view is wrong.

At the current stage, the system should still be used primarily for paper trading and data collection.

A logically complete system is not the same thing as a statistically validated one.

Whether this framework can ultimately produce a stable edge can only be answered through stage-specific out-of-sample results and returns measured at genuinely executable prices.

Risk Warning: This article discusses quantitative research and engineering implementation only and does not constitute investment advice. Binary contracts can expire worthless. Liquidity deterioration, order-book jumps, model failure, and settlement-rule changes can all cause significant losses.

The Grid Shouldn't Determine Position Size: Adding a Fractional Kelly Capital Budget to a Long-Only Grid Strategy

Dream — Thu, 27 Aug 2026 06:04:59 +0000

A grid answers the question, “At what price should the strategy take an action?” Kelly answers a different question: “How much capital may the entire strategy use at most?” Only by separating these two responsibilities can a grid evolve from a set of averaging-down rules into a system that can be backtested, reconciled, and knows when it should stop taking additional risk.

This article discusses a long-only dynamic grid prototype for linear perpetual contracts supported by FMZ. It can be used with traditional crypto assets, and it can also be used to study TradFi-mapped perpetual products such as NVDA, without relying on any exchange-specific private interface.

First, a boundary condition: this article presents the strategy architecture and an FMZ engineering implementation. It makes no promise of profitability, nor does it use an attractive in-sample equity curve as a substitute for out-of-sample validation. A grid strategy accumulates inventory during prolonged declines, while Kelly estimates are themselves affected by sampling error. Combining the two does not automatically produce a low-risk strategy.

The strategy is only an implementation of the ideas discussed in this article and should be treated as a research prototype. It may require further upgrades and revisions. It is intended solely for learning and discussion.

1. What I Really Want to Solve Is Not “How Wide Should the Grid Be?”

When people build grid strategies, it is easy to focus almost entirely on grid spacing: 0.5% or 1%, five levels or ten, equal spacing or exponential spacing.

But what determines whether the strategy can survive is often not one of those parameters. It is a more fundamental question:

If price keeps falling, how much capital is this entire grid allowed to consume at most?

Traditional grids often tie “how much to buy at each level” directly to “how far price has fallen.” One contract on the first level, two on the second, four on the third. On the surface, this seems to optimize the average entry price. In practice, it automatically expands the risk budget as price moves against the strategy.

This prototype deliberately separates these responsibilities:

The grid layer decides when to buy and when to exit.
The Kelly layer decides the total fraction of capital that the entire grid is currently allowed to use.
The execution layer converts a quote-currency budget into contract quantity and handles partial fills and order reconciliation.
The risk-control layer has the authority to stop adding new risk and, when necessary, exit positions batch by batch.

The grid is not allowed to increase the total budget on its own. Even if price crosses five grid levels in succession, the combined capital allocated to those five levels may not exceed the ceiling provided by the Kelly layer.

2. Why the Strategy Is Long-Only

This is not based on the assumption that “long-only always makes money.” The purpose of the strategy is to study a specific structure: on assets for which there is a hypothesis of long-term positive drift, use a pullback grid to improve entries and exits instead of maintaining two opposing inventories at the same time.

For stock-mapped perpetuals such as NVDA, that hypothesis may come from the possibility of long-term growth in the underlying company’s value. For major crypto assets, it comes from a different and less stable assumption about long-term adoption. In either case, positive drift is a hypothesis to be tested, not a law of nature.

Long-only also does not mean “always keep buying.” The prototype requires:

FastEMA >= SlowEMA
and Close >= SlowEMA

Only when this bullish regime is satisfied may the strategy add new grid positions. When price crosses downward through a grid level, the strategy buys. If price later rebounds by one entry-time grid spacing, the corresponding batch is closed.

Each batch has its own actual average fill price and exit target:

TargetPrice = ActualEntryPrice × (1 + EntrySpacing)

There is an easily overlooked detail here: once a batch has been filled, its target is no longer modified by ATR.

ATR may change grid levels that have not yet been filled, but it must not retroactively alter the plan of a trade that is already carrying risk. Otherwise, when volatility expands, the take-profit line keeps moving farther away, and a dynamic parameter becomes an excuse to postpone exits.

The anchor is also allowed to move upward only when the strategy is flat, has no active order, and the trend is healthy. While holding positions, the anchor does not chase price downward. This prevents the grid from moving its “reference starting point” lower and lower during a decline until even the hard-stop benchmark loses its meaning.

3. Grid Spacing Should Cover Costs Before It Tries to Model Volatility

If the grid is too narrow, the trade count may look impressive, but gross profit can be completely consumed by fees and slippage. If the grid is too wide, the strategy may remain inactive for a long time.

The prototype defines grid spacing as the maximum of three constraints:

Spacing = clamp(
    max(
        MinGridPct,
        ATR / Price × AtrMultiplier,
        2 × (FeePerSide + SlippagePerSide) × CostFloorMultiple
    ),
    MinGridPct,
    MaxGridPct
)

The three components answer three different questions:

What is the minimum operational grid spacing the strategy is willing to use?
What is the current scale of market volatility?
Given the estimated cost of one entry plus one exit, how much safety margin should be left?

Suppose one-way fees and slippage are both estimated at 0.05%, and the safety multiple is 2. Then the cost floor is:

2 × (0.05% + 0.05%) × 2 = 0.4%

Even if ATR becomes temporarily very low, the grid will not shrink below 0.4%.

This does not guarantee that every completed trade will be profitable. It simply avoids designing a grid whose expected gross spread is already smaller than its assumed transaction costs.

4. Do Not Use the “Win Rate of Completed Grid Trades” to Calculate Kelly

This is the most important part of the entire design.

A grid trade that has completed is usually a small winner. The inventory with the largest losses is often precisely the inventory that has not yet completed.

If we count only batches that have already exited, we can easily obtain data like this:

Completed grid trades: 93
Winning trades:        90
Losing trades:          3
Win rate:             96.8%

If that win rate is then plugged into the classic binary Kelly formula, the result may recommend an extremely aggressive position size.

The problem is that the unrealized losses still sitting in the account are excluded from the sample.

The strategy is hiding unrealized losses outside the statistical sample and then using a selectively inflated win rate to guide position sizing. That is a textbook form of self-deception.

For this reason, the prototype does not treat “one completed grid cycle” as a Kelly event. Instead, it periodically samples mark-to-market equity, including unrealized PnL:

EquityReturn = Equity_t / Equity_(t-1) - 1

AverageExposure =
    (ExposureFraction_t + ExposureFraction_(t-1)) / 2

UnitRiskReturn = EquityReturn / AverageExposure

ExposureFraction is the current notional exposure divided by a fixed reference equity.

The purpose is to normalize equity changes observed under different position sizes into something closer to the empirical return distribution generated by one unit of risk exposure.

Instead of using the simplified Kelly formula designed for a binary gamble, the prototype searches directly over historical empirical samples:

f_raw = argmax mean(log(1 + f × UnitRiskReturn))
        f ∈ [0, 1]

If a candidate f would make 1 + f × r <= 0 for any observation, that candidate is invalid.

If the average log growth of every positive-position candidate is no better than staying flat, the optimum becomes:

f_raw = 0

That still does not mean the estimate is reliable enough to use directly. The actual allocation is discounted further:

Confidence = min(1, SampleCount / (2 × MinSamples))

f_used = min(
    MaxStrategyEquityPct,
    f_raw × KellyFraction × Confidence
)

By default, the prototype uses one-quarter Kelly:

KellyFraction = 0.25

When the sample count has only just reached the minimum requirement, the confidence multiplier is still only 0.5. The discount is gradually relaxed only as more valid samples accumulate.

Before there are enough Kelly samples, the strategy uses a small warm-up allocation.

Without that step, the strategy would fall into a paradox: without exposure there are no strategy-return samples, and without samples the strategy would never be allowed to create exposure.

5. Kelly Controls the Total Budget, Not Each Individual Grid Level

Assume the fixed reference equity is 100,000 USDT and the warm-up allocation is 10%. The entire grid is therefore allowed a maximum notional budget of 10,000 USDT during the warm-up phase.

The five grid levels do not increase in size as price falls. Instead, their weights decrease by a factor of 0.85:

1.0000, 0.8500, 0.7225, 0.6141, 0.5220

After normalization, the allocation looks approximately like this:

This design is not claiming that deeper grid levels are inherently “safer.” It is explicitly rejecting the traditional Martingale structure: the more adverse the price movement becomes, the smaller the incremental risk added by each new level.

Suppose the later empirical return distribution produces:

f_raw = 40%

and the one-quarter Kelly multiplier is 0.25, while the current confidence discount is 0.75:

f_used = 40% × 0.25 × 0.75 = 7.5%

The total grid budget is now reduced to 7,500 USDT.

If existing notional exposure is clearly above the new budget plus a rebalancing buffer, the strategy reduces positions batch by batch, starting with deeper lots, rather than continuing to wait for every batch to reach its original take-profit target.

One point deserves emphasis: reducing exposure when the Kelly estimate falls also creates turnover and slippage. A buffer is therefore important. A noisy estimator should not trigger a trade every time it changes slightly.

6. Converting a Quote-Currency Budget into FMZ Contract Quantity

The strategy interface takes a capital budget as input, while the amount passed to an FMZ contract order is usually the number of contracts.

You cannot simply pass 1,000 USDT as the amount argument of an order function.

The prototype uses exchange.GetMarkets() to inspect market metadata, focusing on:

CtVal: how much base asset each contract represents;
CtValCcy: the currency in which the contract value is expressed;
AmountSize: quantity precision or step size;
MinQty: minimum order quantity;
MinNotional: minimum notional value.

Version v0.1.0 accepts only linear contracts for which CtValCcy is the base asset.

In that case, the quantity can be estimated as:

RawAmount = QuoteBudget / (Price × CtVal)
Amount = floor_to_step(RawAmount, AmountStep)

After rounding the quantity downward to the valid step size, the strategy checks the minimum quantity and minimum notional requirements.

If the contract-value unit cannot be confirmed, the strategy refuses to start instead of guessing how the conversion should work.

The symbol also uses the full FMZ format, for example:

BTC_USDT.swap

When researching stock-mapped perpetuals, this only needs to be replaced with the actual full symbol provided by the target FMZ exchange.

The strategy itself does not switch exchanges, modify leverage, change isolated/cross-margin settings, alter one-way/hedge position modes, or pass exchange-specific order parameters inside the code.

7. The Hard Part Is Not the Formula — It Is Order State

Once the strategy formulas are written, only half of the engineering work is done.

A single exchange.CreateOrder() request can produce several different situations:

The exchange returns an order ID, but the order is only partially filled.
The request reaches the exchange, but the response times out.
A cancellation request succeeds, but part of the order fills before cancellation takes effect.
The strategy process restarts after sending an order.
The account contains manual orders or positions created by another strategy.

If the program blindly sends another order whenever it gets an empty response, it can easily create duplicate orders.

The prototype therefore follows a more conservative path:

Persist PendingIntent first
        ↓
Call CreateOrder
        ↓
Valid order ID received
        → Save ActiveOrder
        → Clear PendingIntent
        ↓
No valid ID received
        → Keep PendingIntent
        → Enter SAFE_HALT
        → Do not blindly resend

Partial fills must also be processed carefully.

DealAmount is typically cumulative, so the program must not add the full value again on every polling cycle. It should process only the increment:

DeltaAmount = CurrentDealAmount - PreviousDealAmount

If AvgPrice is also a cumulative average price, the fill price of the newly added quantity can be derived as:

DeltaPrice =
    (CurrentDealAmount × CurrentAvgPrice
     - PreviousDealAmount × PreviousAvgPrice)
    / DeltaAmount

After an order timeout, the strategy sends a cancellation request only if the order still appears in GetOrders(Symbol).

The return value of CancelOrder does not mean the order has already reached a final state. The next cycle must still query the final cumulative filled quantity.

To reduce ambiguity about order ownership, the prototype allows only one active order at a time and strongly recommends using a dedicated account or sub-account.

Generality does not mean the strategy can safely take over an account that contains manual positions and orders from other strategies.

Three Types of “Stop” Must Not Be Collapsed into One Switch

The prototype divides abnormal states into three layers:

function runtimeStateName(runtime) {
    var state = runtime.state
    if (state.safeHalt) { return "SAFE_HALT" }
    if (state.riskHalt) { return "RISK_HALT" }
    if (state.dataFreeze) { return "DATA_FREEZE" }
    if (state.activeOrder) { return state.activeOrder.intent.kind + "_PENDING" }
    if (state.lots.length) {
        if (runtime.trendBroken) { return "DEFENSE" }
        return runtime.trendHealthy ? "HOLDING" : "PROBE_HOLDING"
    }
    if (runtime.trendHealthy) { return "GRID_READY" }
    return runtime.probeEligible ? "PROBE_READY" : "WAIT_TREND"
}

1. DATA_FREEZE
Triggered by repeated market-data errors, unknown open orders, or a mismatch between account positions and the local ledger.

It freezes only the addition of new risk. Exits from existing positions, active-order checks, and reconciliation continue to run.

After several consecutive healthy cycles, the strategy may recover automatically.

2. RISK_HALT
Triggered when price reaches the hard-stop threshold relative to the anchor, or when session equity drawdown from its peak exceeds the configured limit.

The strategy exits positions batch by batch and remains latched in the halted state.

Even after all positions have been closed, it does not automatically recover. The operator must first arm the reset and then confirm it a second time within 60 seconds.

3. SAFE_HALT
Triggered when the result of an order submission is unknown, persisted state is corrupted, or a short/unknown-direction position is detected.

This state should not be automatically cleared merely because the network later recovers, because the program can no longer prove that it knows the true state and ownership of orders and positions.

The difference among the three states can be summarized as:

DATA_FREEZE:
The data is temporarily untrustworthy.
Do not add new risk.

RISK_HALT:
A strategy risk condition has been triggered.
Exit and remain halted.

SAFE_HALT:
Order or state ownership cannot be proven.
Do not guess or recover automatically.

9. Whether This Structure Has a Trading Edge Must Be Tested This Way

Kelly can scale an existing return distribution up or down. It cannot turn a negative-expectancy strategy into a positive-expectancy one.

A dynamic grid may look more intelligent, but that does not mean it actually outperforms a simple long position.

At minimum, five baseline variants should be compared:

Evaluation should not focus only on cumulative return. It should also include:

maximum drawdown, annualized volatility, and Calmar ratio;
average log growth;
total turnover and transaction costs as a percentage of gross profit;
average and maximum number of active grid levels;
number of trend exits and risk halts;
number of times the Kelly estimate falls to zero;
parameter stability across neighboring ranges, timeframes, and instruments.

Training and testing must not be mixed together.

A more appropriate process is:

Estimate parameters on the training window
        ↓
Freeze parameters and run the next out-of-sample period
        ↓
Roll the window forward
        ↓
Aggregate all out-of-sample results
that were never used for fitting

If only the best full-sample parameters look good, while small changes in the ATR multiplier, EMA periods, or cost assumptions make the result disappear, then the strategy is more likely adapting to historical noise than discovering a robust edge.

10. What Else Is Needed for Stock-Mapped Perpetuals?

This general prototype intentionally avoids hard-coding the product mechanics of any single platform.

Therefore, if it is applied to TradFi-mapped perpetual products such as NVDA, several second-stage issues still need to be addressed:

Trading-session differences: the perpetual product may trade continuously, while the underlying stock has a clearly defined primary price-discovery session.
Overnight and weekend pricing: after the reference market closes, order-book depth, spreads, and price-anchoring mechanisms may change significantly.
Earnings and corporate events: gap risk cannot be fully absorbed by an ATR-based grid.
Funding rates and premium: the carrying cost of staying structurally long may consume the grid’s gross profit.
Product-tracking mechanism: index prices, oracles, suspension handling, and listing/delisting rules may differ across platforms.

These components should be added only after stable and verifiable data interfaces are available.

Reading exchange-private fields merely to make the implementation “look complete” would instead weaken the strategy’s general design boundary.

Conclusion: Kelly Is Not the Accelerator — It Is the Budget Approver

I prefer to think of Kelly in this strategy as a budget approval mechanism, not an automatic accelerator.

The grid says:

“Price has reached the second level. I want to buy again.”

The Kelly layer does not answer:

“How many times larger should the next order be?”

Instead, it asks:

How much total risk budget is currently supported by the sample? Will this action push total exposure beyond that budget?

If the sample does not support positive log growth, the answer may be zero.

If existing exposure is already above the newly estimated budget, the answer may be to reduce the position first.

Only by separating when to trade from how much total risk the strategy is allowed to take can a grid avoid automatically granting itself a larger risk budget precisely when the market is moving most strongly against it.

The next genuinely valuable step is not to add more formulas. It is to complete FMZ import validation, establish the five baseline variants, and place fees, slippage, funding costs, and out-of-sample periods into the same results table.

Only then can we answer the most important question behind this idea:

Does adding fractional Kelly to a grid strategy actually improve the trade-off between capital growth and drawdown, or does it merely make the strategy look more sophisticated?

Risk Warning: This article is intended solely for research on quantitative strategies, program design, and platform-interface discussion. It does not constitute investment advice. Perpetual contracts may involve leverage, liquidation, funding rates, liquidity risk, gap risk, tracking error, and platform technical failures. A research prototype must go through backtesting, out-of-sample validation, paper trading, and extremely small-capital testing before it can be considered for production use.

Thank you for reading and for your support.

You Got the Direction Right—Why Can Options Still Lose Money? A Four-Dimensional Crypto Options Selector Based on Deribit, Binance, and OKX

Dream — Thu, 27 Aug 2026 03:37:13 +0000

This article focuses on the contract-selection problem in directional options trading: once you already have a bullish or bearish view, how do you choose the contract that best expresses that view from an entire option chain spanning different expiries, strikes, and exchanges?

The thresholds and examples in this article are for explaining the methodology only. They are not fixed parameters or investment advice. API fields and trading rules should always follow the latest official exchange documentation. Information in this article was checked in August 2026.

Many people approach options for the first time with a very simple idea:

If you are bullish, buy a Call.
If you are bearish, buy a Put.

As long as the direction is right, the option should make money.

After trading options a few times, however, you quickly discover that reality is not that simple.

BTC may rise while the Call you bought barely moves. ETH may fall while your Put is still losing money. In a more extreme case, you may even get both the direction and the magnitude roughly right, yet still lose because time value decays, implied volatility collapses, and the bid-ask spread eats away the rest.

The reason is not mysterious.

Over a short horizon, the change in an option's value can be approximated as:

Direction determines only part of the first term.

What you are really buying is a bundle of Delta, Gamma, Vega, Theta, and liquidity exposure.

That is why I prefer to split options trading into two layers:

The first layer answers:

Where are BTC or ETH likely to go next?

The second layer answers:

Which option should I use to express that view?

This article focuses only on the second layer.

I organize the problem into a four-dimensional selection framework:

Convexity: Delta, Gamma, and Speed — which Strike should I choose?
Timing: DTE, IV Term Structure, Basis/Funding — which Expiry should I choose?
Valuation: IV Smile / Skew / Surface — is this option expensive or cheap?
Execution: Spread, Depth, OI, Volume — can the theoretical edge actually be executed?

Finally, Deribit, Binance Options, and OKX Options are placed into the same candidate pool for cross-venue comparison.

Because this is a selector strategy designed mainly for research, analysis, and testing, the implementation directly calls public exchange APIs.

function httpJson(url, source) {
    var raw = null
    try {
        G.requestCount++
        raw = HttpQuery(url, {
            method: "GET",
            timeout: G.cfg.requestTimeoutMs,
            headers: {"User-Agent": "FMZ-Four-Dimensional-Option-Selector/1.0"}
        })
        if (!raw) throw "Empty response"
        var parsed = typeof raw === "string" ? JSON.parse(raw) : raw
        if (parsed && parsed.error) throw JSON.stringify(parsed.error)
        if (parsed && parsed.code !== undefined && String(parsed.code) !== "0" && !Array.isArray(parsed)) {
            throw "code=" + parsed.code + ", msg=" + safeText(parsed.msg)
        }
        return parsed
    } catch (e) {
        throw source + " request failed: " + e + ", url=" + url
    } finally {
        Sleep(G.cfg.requestGapMs)
    }
}

1. First, Make Data From Three Exchanges Speak the Same Language

This step is more important than the formulas.

Deribit, Binance, and OKX all provide relatively complete options-market data, but their field names, quoting conventions, contract specifications, and Greek conventions are not identical.

If you directly compare values such as gamma, premium, or open interest returned by the three venues, you can easily end up comparing quantities that are not economically equivalent.

At the time this article was checked, the public APIs could be summarized roughly as follows:

That is already enough to build an automated option selector.

Before feeding the data into the model, however, I would not keep the venue-specific raw structures. I would normalize them into one standard record:

venue              Deribit / Binance / OKX
underlying         BTC / ETH
symbol             Original contract symbol
expiry             Expiration timestamp
DTE                Days to expiry
option_type        Call / Put
strike             K
forward            F
bid_price_usd      Standardized USD bid value
ask_price_usd      Standardized USD ask value
mid_price_usd      Mid price
bid_iv             Bid IV
ask_iv             Ask IV
mark_iv            Mark IV
delta_norm         Normalized Delta
gamma_norm         Normalized Gamma
theta_norm         Normalized Theta
vega_norm          Normalized Vega
open_interest_usd  Standardized OI
volume_24h_usd     Standardized 24h volume
spread_ratio       Relative bid-ask spread
depth_slippage     Estimated slippage for target notional
quote_age_ms       Quote age

There are two important principles here.

First, normalize prices into a common USD economic value before comparing them.

Premium quotes, contract multipliers, and settlement assets may differ across venues. Seeing 0.02 on one venue and 800 on another does not mean the first contract is cheaper.

Second, I prefer to recalculate the Greeks using one common model.

Exchange-provided Greeks are extremely useful for validation and real-time display, but for cross-venue ranking I would rather use the same Forward, IV, DTE, and pricing model to recompute the Greeks.

At least then, the Delta and Gamma being compared are defined on the same basis.

For crypto options, it is often more natural to compare strikes against the corresponding forward price F, rather than simply using spot S .

A unified moneyness coordinate can therefore be written as:

Once this variable is available, different strike grids across the three venues can be mapped into the same coordinate system.

2. Dimension One: Delta, Gamma, and Speed — Do Not Buy "Cheap"; Buy Convexity

One of the easiest mistakes in directional options trading is to treat out-of-the-money as equivalent to high payoff potential.

A very deep OTM Call may indeed look cheap, but at the same time it may have:

very low Delta;
poor liquidity;
rapid time decay.

The underlying may rise and the option can still behave as though almost nothing happened.

The question I care about more is:

If BTC moves in my predicted direction, will this option's Delta increase quickly?

Delta is the first-order sensitivity of the option price to the underlying:

Taken together, these three quantities help describe how an option can move from "not yet following the underlying very much" toward becoming increasingly sensitive to the underlying.

Suppose I buy a BTC Call with a Delta of only 0.18.

Initially, if BTC rises by $100, the first-order price exposure of the option is only about $18 per standardized unit of underlying exposure.

But if BTC continues moving toward the strike, Gamma can increase and Delta may move from:

0.18
→ 0.25
→ 0.35
→ 0.50

The interesting part is not the number 0.18 by itself.

The important question is whether the Delta path is accelerating.

Do Not Treat Delta = 0.15 as a Magic Number
Many traders favor OTM options with Delta in the 0.10–0.20 range because they often provide attractive leverage characteristics.

But no fixed Delta should be treated as a mathematical law.

The location of the Speed extreme moves with:

IV;
DTE;
Forward;
Strike;

model assumptions.
The best region for BTC under low volatility with 30 days to expiry is not necessarily the best region for ETH under high volatility with only 3 days to expiry.

So in the program, I only use Delta as a first-stage candidate filter.

For a bullish view, for example:

0.10 <= Delta <= 0.30

For a bearish view:

-0.30 <= Delta <= -0.10

This is not the final answer.

It simply removes contracts that are extremely far out of the money or already too close to behaving like in-the-money options.

After that, I look at Gamma, Speed, and premium cost.

You Do Not Have to Trust the Exchange for Speed — Just Bump the Model
Speed can be calculated analytically, but a finite-difference approximation is often more practical.

Bump Forward slightly upward and downward by a small percentage
, then recalculate Gamma:

This has an important advantage:

Deribit, Binance, and OKX do not need to provide Speed natively.

As long as we have Strike, DTE, IV, and Forward, we can calculate it ourselves using the same model across all three venues.

I Prefer to Ask: "How Much Convexity Did I Buy per Dollar of Premium?"
Comparing Gamma alone also has a problem.

ATM options often have high Gamma, but they are also expensive.

So we can build a rough but practical convexity-efficiency ranking metric:

This is not a new law of finance.

It is simply a ranking measure:

For each dollar of premium, which contract gives me more second-order exposure?

The goal of the first dimension is therefore not to find the smallest Delta or the largest Gamma.

It is to find a contract where:

Directional exposure has not yet been fully released, Gamma is in a favorable region, Speed has acceleration potential, and convexity is not too expensive relative to premium.

There is another common misconception worth stating explicitly:

A doubling of Delta does not mean the option price doubles.

Delta is a marginal sensitivity, not a price multiplier.

Explosive option behavior emerges from the interaction of:

continued movement in the underlying;
Gamma convexity;
remaining time;
IV changes.

3. Dimension Two: DTE — Do Not First Ask "How Many Days Should I Buy?" Ask "When Should My View Be Realized?"

Traditional options textbooks often summarize DTE with one sentence:

The closer an option gets to expiration, the faster Theta decays.

That is correct, but it is not enough for real contract selection.

Suppose one view is:

BTC may break out within the next 48 hours.

Another view is:

Risk appetite may continue recovering over the next month.

Both are bullish views, but they should not use the same expiry.

In crypto markets, I combine four groups of information when choosing expiry:

Expected realization horizon + ATM IV term structure + futures basis + perpetual funding

1. Start With Your Own Forecast Horizon
This is one of the most overlooked inputs.

If your model only has directional edge over the next 3–5 days, buying a 90-day option may mean paying for far more long-dated time value than you actually need.

On the other hand, if your thesis requires two weeks to play out but you buy an option expiring tomorrow, you can be directionally correct and still be wiped out by Theta before the move arrives.

The first rule for expiry selection is therefore not:

Near-dated options have more Gamma.

It is:

DTE must cover the forecast horizon, with some additional room for timing error.

Forecasting when something may happen is part of options trading.

2. Then Look at the ATM IV Term Structure
Connect the ATM implied volatility for each expiry and you get the simplest form of volatility term structure.

For example:

3D ATM IV     78%
7D ATM IV     72%
14D ATM IV    61%
30D ATM IV    58%
60D ATM IV    56%

This tells us that the market is paying a large premium for near-term risk.

If my view is merely "short-term bullish," buying the 3D Call may mean making two bets at the same time:

buying direction;
buying very expensive short-term volatility.

Suppose BTC rises, but after the event passes IV falls from 78% to 60%.

The Vega loss can easily consume part of the Delta gain.

That is why DTE selection is not only about Theta management.

It is also about managing the price of volatility across maturities.

3. Use Basis and Funding as Crowding Indicators, Not Direct Directional Signals

One of the major differences between crypto and traditional commodity futures markets is the importance of perpetual contracts and funding rates.

Suppose we observe:

Persistently high perpetual funding
+
Clearly positive forward basis
+
Expensive near-term Call skew

At minimum, this tells us that bullish positioning is crowded.

Even if I remain bullish, I should ask again:

Am I paying the highest price to express the market's most popular direction?

The opposite is also true.

Very negative funding does not automatically mean we should buy Calls.

Funding and basis can remain extreme for long periods.

They describe:

positioning demand;
financing;
term pricing.

They are not standalone signals that reliably predict direction.

In this framework, they act more like maturity and crowding filters.

What Should the Second Dimension Output?
I would not let the program simply say:

Buy the 7-day option.

Instead, it should calculate a Timing Score for each expiry, incorporating at least:

Does DTE cover the forecast horizon?
Is Theta / Premium excessively high?
Is ATM IV unusually expensive at this expiry?
Do Basis / Funding indicate excessive directional crowding?
Does this expiry have enough liquidity?

The output should be two or three candidate expiries, which then move to the next dimension.

4. Dimension Three: IV Smile / Skew / Surface — Even If the Direction Is Right, Do Not Buy the Most Expensive Option

If the first dimension decides which part of the strike range to consider, and the second dimension decides which expiry to use, the third dimension asks:

Within the same direction and expiry, is the volatility price of this option reasonable?

For crypto options, I think this is where systematic selection becomes much more interesting than simply screening by Delta.

Stop Using Strike Directly; Use Log-Moneyness

This makes curves across different expiries easier to handle within a common framework.

Why You Should Not Force a Symmetric "Smile"
BTC and ETH option surfaces are often asymmetric.

At one point, Puts may become much more expensive because of hedging demand.

At another point, far OTM Calls may be bid up by speculative demand or structured-product flows.

If the model forces:

Call at +10% from ATM
=
Put at -10% from ATM

it will erase information contained in the skew.

For a formal implementation, I therefore prefer a skew-capable volatility parameterization such as SVI.

The classic SVI total-variance form can be written as:

It is not the only possible choice.

If an expiry has very few valid quotes, a simpler asymmetric quadratic or cubic smoother may be more robust.

The goal is not to use the most complicated model.

The goal is to avoid forcing a clearly asymmetric market into a symmetric curve.

"Cheap" Does Not Mean Low IV — It Means Low Relative to the Surface
Suppose a BTC Call has an IV of 55%.

The number 55% means very little by itself.

If neighboring contracts at the same expiry imply a fair surface level around 62%, the option may be relatively cheap.

If the fair surface level is only 48%, the same 55% option is actually expensive.

Define:

For a contract I intend to buy, I care even more about:

because I pay the Ask when entering.

I do not pay Mark IV, and I do not trade at a beautiful theoretical mid curve.

This is an easy detail to overlook in live trading.

An option may display:

Mark IV    52%
Fair IV    54%

It appears to be "2 vol cheap."

But the real order book may be:

Bid IV     48%
Ask IV     58%

If I am the buyer, my executable volatility is close to 58%.

The supposedly cheap option is not cheap at all.

Add 25-Delta Skew
For directional trading, the 25-Delta Call and Put are useful reference points for seeing which wing the market is charging more for.

Two simple metrics are:

RR is closer to a directional-skew measure.

BF is closer to the relative richness of the wings versus ATM.

Suppose I am bullish BTC, but 25D Calls are already much more expensive than 25D Puts.

That does not mean I cannot express a bullish view.

It means I should acknowledge that I am buying an expensive Call wing.

Moving closer to ATM, switching expiry, or even switching venue may be more efficient than blindly chasing the deepest OTM Call.

5. Deribit, Binance, and OKX Should Not Be Three Separate Strategies — They Should Be One Candidate Pool

At this point, using three exchanges starts to become genuinely useful.

If I look at only one venue, I can answer:

Is this option expensive or cheap relative to other options on the same exchange?

Once I add two more venues, I can ask another question:

Is the same BTC risk exposure cheaper somewhere else?

But I cannot simply place the premiums of the same strike across three exchanges side by side.

The correct approach is to fit each venue's own volatility surface first, then project those surfaces into the same (k_T) coordinate system.

For example, at a target point such as:

BTC
DTE ≈ 14 days
Delta ≈ 0.20 Call

we may obtain:

Deribit Fair IV
Binance Fair IV
OKX Fair IV

From these, we can build a liquidity-weighted Cross-Venue Consensus IV.

Then every candidate contract receives two residuals:

Local Residual
= Current Ask IV - Venue Fair IV

Cross-Venue Residual
= Current Ask IV - Three-Venue Consensus Fair IV

This allows us to distinguish two very different meanings of "cheap."

One contract may simply fall into a local depression in its own venue's Smile.

Or an entire section of one venue's volatility surface may be cheaper than the equivalent region on the other two venues.

The latter may come from:

genuine cross-market supply and demand;
contract specification differences;
margin rules;
settlement methods;
participant structure.

So I would not automatically call it arbitrage.

A cross-venue IV difference is useful selection information.

It is not automatically a risk-free arbitrage opportunity.

Actual cross-market arbitrage must also deal with:

capital distribution;
margin;
trading fees;
contract multipliers;
settlement rules;
transfer time;
leg risk.

That is a different system.

This article only asks one question:

If I already want to buy a directional option, which contract among the three venues deserves to enter the final candidate set?

6. Dimension Four: Liquidity — "Undervalued" Means Nothing if You Cannot Trade It

One of the easiest places for an option surface to generate false signals is in far-out, inactive contracts with little or no trading.

A Call may have an extremely attractive Mark IV, while the order book looks like:

Bid      20
Ask      35

An algorithm looking only at Mark IV may rank it first.

In reality, the 15-point spread can consume the theoretical edge immediately.

That is why I prefer to use hard filters for liquidity rather than assigning liquidity a small score that other attractive features can offset.

1. Relative Bid-Ask Spread

For a directional option buyer, the spread is effectively part of the loss you absorb immediately after entering.

A reasonable threshold varies across DTE and Delta.

So I would not hard-code a permanent 3% or 5% rule.

A more adaptive approach is to rank spreads among nearby contracts within the same expiry and keep, for example, only the best 60%–70% by liquidity.

2. Real Slippage for the Target Position
A good Best Ask does not mean enough size is available there.

If I intend to buy $20,000 of premium, I should actually walk the order book and calculate:

instead of assuming the entire position can be filled at level one.

All three exchanges provide order-book endpoints, so this cost can be estimated before the trade.

Look at OI and Volume Separately High Open Interest means existing positions are present.

High 24-hour Volume means people have actually been trading recently.

I prefer to use both rather than rely on only one.

High OI + Low Volume

may simply indicate a large number of old positions.

Low OI + Suddenly High Volume

may indicate:

a new contract;
an event-driven burst;
temporary short-term activity.

A more stable candidate should generally satisfy:

There is an existing position base + recent trading activity + no obvious break in the order book.

4. Quotes Must Be Fresh
Timestamps are especially important in cross-venue scanning.

If one exchange is a few seconds behind the others, that alone can create a fake IV depression during a fast market.

So every normalized candidate record should keep:

quote_age_ms

Quotes older than the accepted threshold should be discarded.

They should not be used for:

surface fitting;
candidate ranking;
cross-venue comparison.

7. Connect the Four Dimensions: From "Bullish BTC" to a Final Top 3

Suppose the upstream strategy provides only three inputs:

Underlying: BTC
Direction:  Long
Horizon:    7 days

It does not tell me which Call to buy.

The full selector can be expressed as:

                Directional View: BTC Bullish, Expected Horizon 7 Days
                                      │
                                      ▼
                 Deribit + Binance Options + OKX Options
                                      │
                                      ▼
                       Load All Tradable Call Options
                                      │
                                      ▼
          Normalize Prices, Contract Multipliers, Forward, DTE, Greeks
                                      │
                                      ▼
             Layer 1: Delta Filter (for example 0.10–0.30)
                                      │
                                      ▼
               Rank Gamma / Speed / Convexity Efficiency
                                      │
                                      ▼
          Layer 2: DTE + ATM IV Term Structure + Basis/Funding
                                      │
                                      ▼
                    Keep the Best-Matched 2–3 Expiries
                                      │
                                      ▼
               Layer 3: Fit IV Surface for Each Exchange
                                      │
                                      ▼
        Use Local Residual + Cross-Venue Residual for Relative Value
                                      │
                                      ▼
          Layer 4: Spread / Depth / OI / Volume / Staleness
                                      │
                                      ▼
                                  Final Top 3

I do not recommend compressing everything into one "magic total score" from the beginning.

A more robust process is:

Hard filters first, layered ranking second.

For example:

# Pseudocode: illustrates the process only

candidates = load_options_from_deribit_binance_okx("BTC")
candidates = normalize_contracts(candidates)

# Direction and minimum tradability
candidates = [x for x in candidates if x.option_type == "CALL"]
candidates = [x for x in candidates if 0.10 <= x.delta_norm <= 0.30]
candidates = [x for x in candidates if not x.stale]
candidates = [x for x in candidates if x.depth_slippage <= MAX_SLIPPAGE]

# Convexity
for x in candidates:
    x.speed = calc_speed_by_bump(x)
    x.gamma_eff = x.gamma_norm * x.forward**2 / x.ask_price_usd

# Timing
expiries = rank_expiry_by_horizon_term_structure_basis(
    candidates,
    horizon_days=7
)
candidates = keep_selected_expiries(candidates, expiries)

# IV Surface
surfaces = fit_surface_by_venue_and_expiry(candidates)

for x in candidates:
    x.fair_iv = surfaces[x.venue, x.expiry].iv(x.log_moneyness)
    x.ask_residual = x.ask_iv - x.fair_iv

# Liquidity and execution cost
candidates = hard_liquidity_filter(candidates)

# Final ranking
top3 = rank_candidates(candidates)[:3]

In a real implementation, fixed thresholds can be replaced with percentiles.

That allows the selector to adapt across:

BTC;
ETH;
high-volatility regimes;
low-volatility regimes;

instead of relying on values that remain hard-coded forever.

8. I Would Not Place an Order After the Four-Dimensional Filter — I Would Run Scenario Repricing First

After the four-dimensional screen, there is still one critical check:

If my directional view actually plays out, how much will this option make?

High Gamma, cheap IV, and good liquidity still do not guarantee that the return profile meets the trading objective.

Suppose the upstream model provides:

Current BTC Forward: F
Expected in 5 days:  F × 1.06
Expected IV change:  -3 vol / 0 / +3 vol

I would run at least three IV scenarios:

Direction realized + IV falls
Direction realized + IV unchanged
Direction realized + IV rises

If a Call only produces an attractive result when:

BTC rallies sharply and IV continues rising,

then the position is really a demanding two-factor bet.

In contrast, if BTC rises as expected and the option still maintains an acceptable return even after IV falls by several vol points, that contract is more consistent with the original purpose:

expressing a directional view through options.

This step also puts the Greeks back into their proper role.

Greeks are local sensitivities.

The final trade decision should return to:

full repricing;
realistic execution costs.

9. What Role Should Each Exchange Play in the System?

When building the model, I would not simply ask which venue is "best."

I would rather treat the three venues as markets that can validate one another.

Deribit: Suitable as a Primary Surface and High-Frequency Greeks Source
Deribit's ticker / WebSocket ticker provides:

bid IV;
ask IV;
mark IV;
Greeks;
OI;
market data.

Its options toolchain is highly concentrated, which makes it suitable as one of the primary data sources for BTC/ETH volatility surfaces.

Deribit also provides historical volatility and volatility-index-related interfaces.

So if the model later expands from:

Is current IV expensive?

to:

IV vs. realized volatility;
DVOL;
historical IV percentiles;

the extension path is relatively straightforward.

Binance Options: Useful as a Second Quote Center and USDT-Ecosystem Reference
Binance /eapi/v1/mark provides:

bidIV;
askIV;
markIV;
Delta;
Gamma;
Theta;
Vega.

ticker, openInterest, and depth add:

trading activity;
open interest;
order-book depth.

For the selector, the value of Binance is not merely that it is "another exchange."

It helps answer a more useful question:

If one region of the Deribit Smile looks cheap or expensive, is that a Deribit-specific phenomenon, or is the broader market pricing the same way?

OKX Options: Useful as an Independent Surface and Forward Cross-Check
OKX /api/v5/public/opt-summary is particularly useful for this framework.

Its output includes fields such as:

Delta / Gamma / Vega / Theta;
deltaBS;
gammaBS;
thetaBS;
vegaBS;
markVol;
bidVol;
askVol;
fwdPx;
ATM volatility-related fields.

In one request, the system can obtain much of the data required for:

Smile construction;
Skew analysis;
Forward checks;
Greek validation.

Combined with public/open-interest and order-book endpoints, OKX can form a complete independent candidate pool.

The goal is for all three venues to cross-check one another, not replace one another.

10. What Is Really Worth Automating Is Not "Predicting Up or Down" — It Is Translating a View Into a Contract

Many quantitative strategies spend most of their effort on directional signals:

trend;
momentum;
machine learning;
order flow;
on-chain data.

The final output is often just:

Long

or:

Short

But once the execution instrument changes from futures to options, the directional signal has only completed half the job.

The same view:

BTC is bullish over the next week

can be translated into very different risk structures:

3D 40Delta Call
7D 20Delta Call
14D 15Delta Call
30D ATM Call
Call Spread

All of these positions are "bullish."

Yet their sensitivity to:

price;
time;
volatility;

is completely different.

A more reasonable system architecture is therefore:

Directional Model
   ↓
Output:
Direction + Confidence + Forecast Horizon + Expected Move
   ↓
Option Selector
   ↓
Delta / Gamma / Speed
DTE / Term Structure
IV Surface / Skew
Liquidity / Cost
   ↓
Scenario Repricing
   ↓
Top 3 Contracts
   ↓
Risk Budget Determines Final Position Size

The key shift is this:

We stop asking:

Which option is the cheapest?

and start asking:

Which option is the best instrument for expressing this particular forecast?

Those are completely different questions.

11. Risk: Limited Maximum Loss for the Buyer Does Not Mean the Strategy Is Low Risk

One of the major advantages of directional long-option positions is that the maximum loss on a single trade can usually be constrained explicitly through the premium budget.

But this creates another illusion:

If I can only lose the premium, I can just keep buying.

The real danger is a sequence of small losses that go to zero.

A model that repeatedly buys low-Delta, short-DTE options may exhibit a distribution like:

Small maximum loss per trade
Low win rate
Persistently negative Theta
Persistently negative spread cost
Occasional very large winner

Whether this return distribution has positive expectancy cannot be proven simply by saying:

Losses are limited.

The four-dimensional selector only solves one problem:

Once the decision has been made to express a directional view through options, reduce obviously poor contract choices.

It does not replace:

statistical edge in the directional model itself;
per-trade premium budgets;
daily / weekly maximum-loss rules;
same-direction concentration limits;
cross-exchange capital and operational risk management;
stress tests for extreme markets, IV collapse, and disappearing liquidity.

It is especially important to remember:

"Undervalued IV" is only a relative value under the model.

It does not mean IV must revert toward the fitted value.

The entire volatility surface can move.

Conclusion: An Option Is Not a "Future With Insurance" — It Is a Payoff Curve You Can Design

If I had to summarize the framework in one sentence:

Getting the direction right only means you solved the sign of Delta. The quality of the option trade depends on how much Gamma you bought, how much Theta you paid, whether Vega was expensive or cheap, and whether you can actually execute the position at a reasonable price.

One major advantage of crypto options is that these data are highly structured.

Deribit, Binance Options, and OKX Options all provide sufficiently complete public APIs to turn the traditional process of:

staring at an option chain and choosing contracts from experience

into a repeatable program:

Direction
→ Strike
→ Expiry
→ IV Surface
→ Liquidity
→ Cross-Venue Compare
→ Scenario Repricing

If I continue developing this framework, I am less interested in adding a fifth indicator than in fully separating the selector from the upstream directional model.

The directional model should only predict:

Where?
How long?
How far?

The option module should specialize in finding the most appropriate risk expression.

At that point, options stop being a simple trading button where:

bullish = buy Call
bearish = buy Put

and become what they really are:

a payoff function that can be calculated, filtered, compared, and designed.

Win Rate, Payoff Ratio, Frequency, and Position Sizing: The Four Dimensions That Really Matter in Quantitative Trading

Dream — Wed, 26 Aug 2026 08:47:28 +0000

A quantitative strategy can be as complex as you like, but complexity alone does not tell you whether the strategy is worth trading.

Moving averages, RSI, machine-learning models, and even more sophisticated Agents all eventually come down to a few very simple questions:

How likely is the strategy to make money? How much does it make when it wins? How often do such opportunities appear? How much risk does it take each time?

In actual strategy operation, these correspond to the four dimensions that are most worth monitoring continuously:

win rate, payoff ratio, trading frequency, and position sizing.

These four dimensions do not describe every risk in a trading system, but they are extremely useful for answering one practical question:

How does a strategy's statistical edge ultimately translate into returns and drawdowns?

Using the cryptocurrency market and an FMZ strategy implementation as examples, this article focuses on how these four dimensions interact and how to turn them into live-trading monitoring metrics and risk constraints.

This article is for strategy research and software development purposes only and does not constitute investment advice.

1. Before Looking at Returns, Look at Net Expectancy per Trade

Let:

the win rate be E;
the average winning trade be p times the average losing trade;
commissions, slippage, and funding costs per trade equal c times the average loss.

If we normalize the average loss to one unit of risk, the net expectancy per trade can be written as:

This formula puts win rate, payoff ratio, and trading costs into the same framework.

For example, consider a BTC perpetual strategy with:

a 42% win rate;
a realized payoff ratio of 2.2:1;
total trading costs of approximately 0.08 risk units per trade.
Then:

In other words, if these statistical characteristics can be maintained, each completed trade has an average net expectancy of approximately 0.264 risk units.

If the strategy plans to risk 0.5% of account equity per trade and produces 12 valid trades per month, then under the simplified assumptions of no compounding and no overlapping risk:

This is not a return forecast.

What it really tells us is:

Win rate alone is meaningless, and payoff ratio alone is also meaningless. What matters is their combined expectancy after costs.

2. Win Rate and Payoff Ratio Must Be Evaluated Together

Among the four dimensions, this pair is probably the easiest to optimize incorrectly.

Many strategies can increase their win rate simply by changing the exit logic.

For example:

taking profits earlier;
widening stop losses;
continuing to wait after a trade moves into a loss;
averaging down to reduce the average entry price.

The result is often:

The win rate improves, but the average winner becomes smaller, the average loser becomes larger, and tail losses become more dangerous.

Consider a strategy with an 85% win rate, an average winner of 0.3R, and an average loser of 2.5R:

It still has negative expectancy.

Conversely, a trend-following strategy may have a win rate of only around 30%–40%, yet a small number of large trends can compensate for many small losses.

So in live trading, it is not enough to save only one overall win-rate number. The following metrics are much more useful:

Here, using R-multiples is especially useful because directly comparing USDT profit and loss can be misleading.

Define:

For example:

A trade earns 100 USDT while the original planned risk was only 50 USDT. The result is therefore +2R.

Another trade earns 300 USDT but takes 500 USDT of planned risk. Its result is only +0.6R.

The second trade makes more money in absolute terms, but the first trade uses risk much more efficiently.

3. What Really Matters About Frequency Is the Number of Effective Opportunities

Frequency should not simply mean how many times a strategy trades per day or per month.

At a minimum, three different concepts should be distinguished:

signal frequency, order frequency, and completed-trade frequency.

A strategy may have only 20 genuine entry opportunities in a month while submitting, modifying, and canceling thousands of orders.

In that case, what increases may not be Alpha, but instead:

commissions;
bid-ask spread costs;
slippage;
API and order-state-management pressure;
the probability of duplicate orders;
market impact.

So a more important question than "How many trades are there?" is:

Does each additional trade still have enough net edge?

Suppose a minute-level strategy has an average gross edge of only 0.06% per trade, while the complete round-trip trading cost has already reached 0.05%.

Only 0.01% of edge remains.

A small deterioration in live execution may be enough to eliminate the positive expectancy entirely.

On the other hand, trading frequency cannot be reduced indefinitely either.

If a strategy produces only a few trades per year, then even if all of them are profitable, it is difficult to determine whether the strategy has a persistent long-term edge or whether that particular market regime simply happened to suit it.

Therefore, what should actually be optimized is neither "high frequency" nor "low frequency," but:

obtaining as many relatively independent positive-expectancy opportunities as possible while keeping trading costs manageable.

The word independent is important here.

If BTC, ETH, and SOL all generate long signals at the same time, that may look like three separate opportunities, but they may simply be three manifestations of the same crypto-market risk factor.

Opening three positions does not necessarily mean that you have obtained three independent sources of edge.

That is why a live system should also monitor:

same-direction risk;
cross-asset correlation;
concentrated signals within the same time window;
total notional exposure;
total planned stop-loss risk.

4. Position Sizing Is Not Leverage; It Is Risk Budgeting

Position sizing is the variable among the four dimensions that actually converts a statistical edge into an account-level result.

The correct calculation sequence should be:

First decide the maximum amount you are willing to lose, then work backward to determine how much you should buy.

For example:

Account equity:10,000 USDT
Maximum planned risk per trade:0.5%
The risk budget is therefore:10,000 × 0.5% = 50 USDT
If the distance between the entry price and the stop-loss price is 2.5%, the approximate notional position size is:

What actually determines the risk here is:

stop distance × notional position size.

Leverage mainly affects how much margin is occupied.

Of course, real markets also involve slippage, price gaps, insufficient liquidity, and liquidation risk. So "planning to lose 50 USDT" does not mean the actual loss will always be exactly 50 USDT.

This is why the system should record not only planned risk, but also:

If a strategy is designed to lose no more than 1R per trade but live trading repeatedly produces losses of -1.5R or -2R, the first thing to inspect is not the signal logic but execution and risk control.

Portfolio Risk Must Also Be Controlled

Suppose the system simultaneously holds:

a BTC long position;
an ETH long position;
a SOL long position.

Each trade has a planned risk of 0.5% of account equity.

Viewed independently, none of them appears large.

But if all three positions are fundamentally exposed to the same market direction, the real issue is what happens if all three stop losses are triggered together.

Therefore, position management should have at least three layers of risk limits:

The exact numbers are not the point.

The important principle is:

It is not enough to limit the size of each individual trade. The system must also limit portfolio risk after correlated positions are stacked together.

5. The Four Dimensions Form a Profitability Chain

Putting the relationships above together, a simplified expectancy over a given period can be written as:

where:

E_R: average net expectancy per trade, measured in R;
N: number of effective trading opportunities;
r: risk per trade as a percentage of account equity.

More generally, if the amount of risk differs from trade to trade, the relationship is closer to:

This reveals an important point:

The four dimensions cannot be maximized independently.

Raising the profit target may increase the payoff ratio but reduce the win rate.

Relaxing signal conditions may increase trading frequency but reduce expectancy per trade.

Increasing position size can amplify returns, but it also amplifies drawdowns and model error.

Reducing the use of stop losses may improve the short-term win rate while transferring risk into a small number of extreme losses.

What really needs to be optimized is:

The overall structure formed by all four dimensions under trading-cost, drawdown, and execution constraints.

6. In FMZ, You Do Not Actually Need to Record Very Much

If the complete strategy source code already exists, there is little value in explaining GetTicker(), GetDepth(), or order-placement APIs one by one.

What the four-dimensional framework really needs is a unified trade record.

After every fully closed trade, at least the following data should be saved.

Group 1: Trade Identity and Time

Group 2: Risk Baseline at Entry

Group 3: Realized PnL and Trading Costs

Slippage is best stored separately as an execution-quality metric.

One definition requires particular care:

If grossPnl is already calculated from actual execution prices, the impact caused by execution prices deviating from theoretical prices has already entered the trading PnL.

Subtracting the same slippage from netPnl again may therefore result in double counting.

The system should clearly distinguish between:

cash costs and execution-attribution costs.

A More Robust Four-Dimensional Statistics Function

The principle is actually very simple.

Instead of reconstructing expectancy from the win rate and average win/loss, it is more robust to directly average the already standardized realizedR values of all trades.

function average(arr) {
    if (!arr || arr.length === 0) {
        return 0
    }

    return arr.reduce((sum, x) => sum + x, 0) / arr.length
}

function calcFourDimensions(trades) {
    if (!trades || trades.length === 0) {
        return null
    }

    const rs = trades.map(t => t.realizedR)
    const wins = rs.filter(r => r > 0)
    const losses = rs.filter(r => r < 0)

    const avgWinR = wins.length ? average(wins) : 0
    const avgLossR = losses.length ? Math.abs(average(losses)) : 0

    return {
        count: trades.length,

        winRate:
            wins.length / trades.length,

        payoffRatio:
            avgLossR > 0
                ? avgWinR / avgLossR
                : null,

        expectancyR:
            average(rs),

        avgRiskRate:
            average(
                trades
                    .filter(t => t.equityAtEntry > 0)
                    .map(t => t.plannedRisk / t.equityAtEntry)
            )
    }
}

The most important line is:

expectancyR = average(realizedR)

A breakeven trade is therefore simply 0. There is no need to artificially classify every trade as either a "win" or a "loss" before calculating expectancy.

It is also advisable to maintain at least two rolling windows, for example:

Most recent 20–30 trades
Most recent 100 trades

Then compare them with the historical backtest baseline.

Full-history statistics are useful only for answering:

"How has this strategy performed overall in the past?"

Rolling statistics are more useful for answering:

Is it still behaving the way it used to?

7. Testing the Four-Dimensional Framework With a Simple Strategy

There is no need to use a complicated signal model just to observe these four dimensions.

In fact, the Alpha component should be kept as simple as possible.

For example, we can use the following research strategy:

The strategy itself is not the Alpha this article is trying to prove.

It is only an experimental vehicle.

What we actually want to observe is:

What happens to the four dimensions after the signal passes through position sizing, costs, and execution?

For example, suppose the backtest shows:

Win rate               41%
Payoff ratio            2.4
Average trades/month    11
Average risk             0.5%

But the rolling live-trading window suddenly changes to:

Win rate                34%
Payoff ratio             1.3
Monthly trade frequency 27
Actual risk               0.8%

At this point, the issue is no longer simply "recent bad luck."

It may mean:

More false breakouts are reducing the win rate.

Earlier exits or shorter trends are reducing the payoff ratio.

Range-bound conditions are creating repeated entries and rapidly increasing trade frequency.

Slippage and execution anomalies are causing actual risk to exceed planned risk.

This is where a four-dimensional health check becomes genuinely useful.

8. Strategy Failure Should Be Divided Into Two Different Cases

One of the easiest mistakes to make in live trading is to confuse:

statistical strategy degradation with system execution failure.

They should be handled very differently.

Type 1: Statistical Degradation
For example:

rolling expectancy continues to decline;
win rate and payoff ratio deteriorate at the same time;
effective opportunity frequency declines;
costs consume a significantly larger share of gross profit;
drawdown moves outside its historically normal range.

This type of situation usually still leaves room for observation.

Risk can be reduced first while the system continues collecting samples.

Type 2: System Failure
For example:

abnormal market data;
local position records do not match exchange positions;
duplicate orders;
order status cannot be confirmed;
stop orders were not actually submitted or executed;
actual risk repeatedly exceeds the system limit.

These problems do not require waiting for statistical significance.

The system should immediately stop adding new risk.

At that point, the question is no longer whether the Alpha is still valid, but whether the system can still execute correctly.

The Response Mechanism Can Be Compressed Into Three Levels

There is another important principle:

Do not immediately re-optimize parameters simply because the strategy has recently lost money.

Otherwise, it is easy to mistake normal random variation for strategy failure and then continuously chase the most recent market regime.

9. A Backtest Really Needs to Pass Only Three Gates

Instead of stacking up a large number of attractive-looking performance metrics, focus on three questions.

Gate 1: Does the Edge Still Exist After Costs?
After commissions, slippage, funding costs, and bid-ask spread are included, does the strategy still have positive expectancy?

If the strategy fails as soon as realistic trading costs are added, the original edge may have existed only because of idealized execution assumptions.

Gate 2: Does the Edge Exist Only for One Specific Parameter Set?
Change the breakout lookback from 20 bars to 18, 19, 21, and 22.

Change the ATR stop from 2 to 1.8 or 2.2.

Test a different time period.

Test BTC and ETH separately.

Then run the test again.

If only one extremely narrow parameter combination performs well, overfitting should be treated as a serious risk.

Gate 3: Can the Backtest Statistics Be Reproduced Under Real Execution?
During the small-capital live-trading stage, what actually needs to be verified is:

whether realizedR matches expectations;
whether actual costs are close to the assumptions;
whether order states are reliable;
whether stop-loss risk remains under control;
whether trading frequency becomes abnormal;
whether portfolio risk is calculated and controlled correctly.

The key at this stage is not how much money the strategy makes.

The real objective is to confirm:

Does the four-dimensional structure observed in the backtest still exist in the real market?

Conclusion

Quantitative trading is not a "price-guessing contest."

A strategy does not need to be right every time.

What really needs to be built is a stable profitability chain:

Signals with a statistical edge

↓

A reasonable realized payoff ratio

↓

Enough effective trading opportunities, but not too many

↓

Position sizing that can survive consecutive losses and model error

Win rate tells us how often we make money.

Payoff ratio tells us how many losing trades one winning trade can cover.

Frequency determines whether the statistical edge can be realized within a finite amount of time, while also determining whether trading costs will consume that edge.

Position sizing determines whether the account can survive long enough for the edge to materialize.

The code simply keeps executing these rules consistently.

A mature quantitative trading system should always know three things:

How much am I prepared to lose on this trade at most?
Why might this strategy make money over the long run?
Under what conditions should the system stop taking additional risk?

From Pairs to Matrices: Let the Machine Find the Arbitrage Basket

Dream — Wed, 26 Aug 2026 07:23:25 +0000

I have recently become interested in relative-value and arbitrage strategies. In an earlier example, we traded EWY against Samsung Electronics and SK Hynix. That trade, however, depended on a human being first recognizing the economic relationship.

Can we automate the search itself—screening the market for baskets that may contain a tradable relative-value structure?

This article develops one possible workflow.

1. What Did the EWY Trade Really Cost?

Let us first clarify the earlier example.

EWY is a South Korea ETF, and Samsung Electronics and SK Hynix are among its most important constituents. If EWY becomes expensive relative to those constituents, the trade is to short EWY, go long the constituents, and wait for the relative prices to move back toward their previous relationship.

There is nothing wrong with that idea. But it contains a hidden cost that is rarely measured: how much prior knowledge did you need before you could even identify those three instruments?

You had to know that EWY tracks South Korea. You had to know that Samsung and SK Hynix carry large weights. You had to understand how the memory-chip cycle propagates through the group. You also had to estimate how much the Korean won could contaminate the spread.

None of that information sits directly inside a price matrix. It sits in your head.

That knowledge is an asset accumulated over many years. But precisely because it is a human asset, it is difficult to replicate, scale, or delegate to a machine.

That is the motivation for the entire strategy:

A market may contain hundreds of instruments, tens of thousands of pairs, and millions of three-name combinations. How many can one person examine?

The ceiling of pair trading is not necessarily its return. The ceiling is that a human can only reason carefully about a limited number of relationships at once.

The goal here is to take the step of deciding which instruments belong together away from manual selection and turn it into a process that can be rerun every day.

2. Step One: Arrange Prices as a Matrix

Everything begins with a simple operation: place prices into a table.

Rows represent time.
Columns represent instruments.
Each cell contains a log price.

P = np.array([[series[s][t] for s in kept] for t in ts], dtype=float)
L = np.log(P)          # T × N log-price matrix

The logarithm is not cosmetic. Relative-value trading is fundamentally concerned with ratios, and logarithms convert ratios into differences.

A move from 10 to 20 and a move from 100 to 200 produce the same log return. Only after this transformation do later linear operations—weighting, projection, and regression—have a consistent interpretation.

This matrix, with T rows and N columns, becomes the object on which the rest of the workflow operates. Its structure determines whether the instruments contain a potentially tradable relative relationship.

3. Ten Semiconductor Instruments May Really Be One

Consider a ten-instrument semiconductor-related basket. A typical candidate set may include AMD, ARM, ASML, INTC, MRVL, NVDA, TSM, QQQ, SPY, and another instrument admitted by the screen.

Visually, the columns often look highly similar: when one rises, most of the others rise; when one falls, most of the others fall.

In linear algebra, this is described as low rank. The matrix may have ten columns, but its effective number of common degrees of freedom may be much smaller.

Singular value decomposition provides a way to separate those directions:

_, S, Vt = np.linalg.svd(Xc, full_matrices=False)
V  = Vt.T
Vf = V[:, :k]      # estimated common-trend directions
Vn = V[:, k:]      # estimated residual subspace

Choosing k is the first genuinely difficult question.

If k is too small, real common movement is treated as noise and directional market exposure remains in the basket.
If k is too large, noise is promoted to a factor and the system trades a structure that may not exist. The implementation uses a Marchenko–Pastur upper-edge rule as a practical factor-count heuristic. Under its random-matrix assumptions, eigenvalues above the noise edge are treated as candidate common factors:

def mp_factor_count(returns):
    T, N = returns.shape
    q = float(N) / float(T)
    upper = (1.0 + math.sqrt(q)) ** 2    # upper edge under the noise model
    ev = np.linalg.eigvalsh(C)
    return int(np.sum(ev > upper))       # count eigenvalues above the edge

This rule automatically responds to sample size through q = N/T. A shorter training window or a larger universe raises the noise edge and makes the filter stricter.

That is directionally sensible: when data are scarce, the model should be less willing to believe that an apparent structure is real.

In one run, the result was k = 1.

In other words, the basket was largely driven by one common movement, with the remaining dimensions representing relative deviations.

The Marchenko–Pastur edge should still be treated as a heuristic rather than a proof. Financial returns are not independent Gaussian noise, and temporal dependence, heavy tails, and volatility clustering can change the empirical eigenvalue spectrum.

4. The Residual Subspace: Several Distinct Relative-Value Directions at Once

This is where the approach begins to differ from ordinary pair trading.

If N = 10 and the estimated number of common trends is k = 1, the remaining N - k = 9 dimensions lie outside the leading common direction.

Under a valid common-trend and cointegration structure, portfolios formed in this residual subspace can suppress much of the shared market movement and leave mainly relative deviations.

If the entire semiconductor group rises 5%, a well-constructed residual portfolio should move much less. If the group falls 8%, the same should be true. What remains is the question of which member moved away from the others.

The earlier EWY trade can be understood as a manually discovered direction in such a space. A human chose weights intended to cancel the broad South Korea exposure and isolate a relative mispricing.

SVD provides multiple candidate directions at once.

However, one distinction matters:

Orthogonal directions are not automatically statistically independent bets.

They are geometrically distinct coordinates in weight space. Their realized residual time series may still be correlated, especially outside a Gaussian model. Covariance whitening and out-of-sample validation are therefore still necessary.

The practical change from pair trading to matrix trading is not merely that more instruments are involved. It is that the strategy monitors a multidimensional residual structure rather than a single spread.

Figure 1 | Matrix arbitrage increases the number of relative-deviation dimensions that can be monitored outside the dominant common trend.

5. Whether the Space Is Usable Depends on Spectral Separation

The output of SVD should not be accepted without a stability check.

SVD orders directions by singular value. The first k directions are assigned to the common-trend space and the remainder to the residual space. The question is whether the boundary between the two is stable.

Suppose the k-th singular value is 100 and the next is 20. The separation is large, so a moderate perturbation is unlikely to change the subspace dramatically.

If the values are 51 and 49, the boundary is fragile. On the next rebuild, a direction may rotate from the residual space into the factor space. A carefully calculated portfolio from yesterday may then represent a substantially different exposure today.

Perturbation results such as the Davis–Kahan and Wedin sin Θ theorems can be summarized schematically as:

subspace rotation  ≤  perturbation size / absolute spectral separation

The denominator is the separation between the relevant singular-value groups. It is a quantitative stability concept, not a metaphor.

The implementation uses a singular-value ratio as a convenient scale-free proxy:

gap = float(S[k - 1] / S[k])

if gap < MIN_GAP:                 # default: 1.30
    return None, "insufficient singular-value separation {:.2f}<{:.2f}".format(
        gap, MIN_GAP
    )

Strictly speaking, the perturbation theorem depends on absolute separation relative to perturbation magnitude, not on the ratio alone. The ratio is therefore an engineering filter, not a theorem-level guarantee.

The theoretical screen is followed by an empirical one. The training window is split into two halves, the residual subspace is estimated separately in each half, and the principal angle between the estimates is measured:

half = eff // 2
angles = []

for seg in (train[:half], train[half:]):
    Sc = seg - seg.mean(axis=0)
    _, _, vt = np.linalg.svd(Sc, full_matrices=False)
    angles.append(principal_angles_deg(Vn, vt.T[:, k:]))

if max(angles) > MAX_ANGLE_DEG:   # default: 20°
    return None, "subspace rotation {:.1f}°>{:.1f}°".format(
        max_angle, MAX_ANGLE_DEG
    )

This test asks a sharp question:

Do the first and second halves of the sample point toward approximately the same relative-value space?

A small angle suggests temporal consistency. A large angle suggests that the apparent structure may be specific to one section of the sample.

Examples rejected by this filter included:

6   BMNR,COINX,CRCLX,HOODX,MSTRX,ORCLX     subspace rotation 49.6° > 20.0°
6   AMZNX,GOOGLX,IBM,METAX,MSFT,PLTRX      subspace rotation 87.0° > 20.0°
13  AAPLX,AMZNX,BABA,CXMT,FUTUON,GOOGLX    subspace rotation 80.0° > 20.0°

An angle of 87 degrees means the two estimated spaces are almost orthogonal.

This filter often rejects the baskets that look most convincing to the eye. Large technology stocks may be highly correlated, but high correlation is not the same as a stable tradable relationship.

Figure 2 | Singular-value separation tests the boundary between factor and residual spaces; principal angles test whether the estimated residual structure rotates over time.

6. Two Statistics: One Finds Misalignment, the Other Avoids Catching a Falling Knife

Once a basket is admitted, it enters real-time monitoring.

Two statistics are used, and they serve different purposes.

Q-score: How Deep Is the Structural Misalignment?
Project the current log-price vector into the residual subspace and measure its Mahalanobis distance using the residual covariance estimated in training:

rvec = xc @ Vn
q_raw = float(rvec @ np.array(model["resid_inv"]) @ rvec)

Why use Mahalanobis distance rather than Euclidean distance?

Because residual directions naturally have different volatility scales. One may be highly active while another remains close to zero most of the time. A single absolute threshold would mainly monitor the largest-variance directions and largely ignore the rest.

Mahalanobis distance normalizes the directions by their covariance and places them on a common scale.

If the residual vector is approximately multivariate Gaussian and the covariance matrix is known—or estimated accurately from a much larger sample—the squared Mahalanobis distance is approximately distributed as χ²(r).

This gives distribution-based reference levels:

"q_entry": float(sps.chi2.ppf(0.995, r)),   # 99.5th percentile: alert
"q_exit":  float(sps.chi2.ppf(0.80,  r)),   # 80th percentile: exit

This is useful because every parameter that can be grounded in a distribution leaves less room for manual optimization.

The qualification matters: cointegration by itself does not imply Gaussian residuals, and using an estimated covariance matrix, autocorrelated observations, heavy tails, or seasonal rescaling makes the exact χ² calibration only approximate. In production, empirical quantiles and forward false-alarm rates should be compared with the theoretical thresholds.

F-shock: Is the Entire Factor Space Being Repriced?
The purpose of this statistic is to prevent the system from taking the right action at the wrong time.

Suppose the Q-score triggers and the system prepares to trade mean reversion. But the Federal Reserve has just released an unexpected statement and the entire semiconductor sector is being repriced.

The prices may not return, because the new level may be economically justified.

The strategy therefore monitors the speed of movement in the common factor itself:

f = xc @ Vf                          # factor score
d = f - np.array(prev["f"])          # first difference
fshock = float(d @ np.array(model["f_inv"]) @ d)

An entry requires both conditions:

"alarm":   q > model["q_entry"],      # residual structure is displaced
"blocked": fshock > model["f_limit"], # factor is moving violently: do not enter

The two statistics describe two sides of the same question:

High Q, low F: the systematic environment is relatively calm, but the relative positions are displaced. This is the intended setup.
High Q, high F: the systematic environment itself is changing. This is more likely repricing than temporary misalignment. Classical multivariate statistical process control often assumes stationary variables. Log prices are generally modeled as integrated processes, so the classical formulation cannot simply be copied.

Here, Q is constructed from residual directions that have passed stationarity screening, while F is constructed from first differences of factor scores. Both statistics are moved onto approximately stationary inputs before distance thresholds are applied.

Figure 3 | The preferred region has a large structural displacement but a calm common factor. A simultaneous factor shock is more consistent with event-driven repricing.

7. Attribution: A Residual Belongs to the Basket, Not to One Instrument

A Q-score alert only says that the basket is displaced. It does not identify which instrument caused the displacement.

The residual is created by projection, so it is a property of the portfolio as a whole.

The implementation uses leave-one-out regression for attribution:

for i in range(N):
    others = [j for j in range(N) if j != i]

    A = np.column_stack([np.ones(eff), train[:, others]])
    b, _, _, _ = np.linalg.lstsq(A, train[:, i], rcond=None)

    res = train[:, i] - A @ b

    loo.append({
        "i": i,
        "others": others,
        "beta": b.tolist(),
        "sd": float(res.std(ddof=1))
    })

The idea is to reconstruct instrument i using the other N - 1 instruments.

If reconstruction is accurate, instrument i has little idiosyncratic displacement.
If its reconstruction residual becomes unusually large, the displacement is attributed to i. At run time, each instrument receives a z-score:

pred = b[0] + float(b[1:] @ x[rec["others"]])
z = (x[rec["i"]] - pred) / rec["sd"]

One live output looked like this:

ARM:-5.604   NVDAX:-3.099   INTC:2.548   ASML:1.564

ARM was 5.6 standard deviations below the price implied by the other instruments.

The proposed position was therefore:

long ARM;
hedge with the remaining legs using the regression coefficients.

sgn = 1.0 if top["z"] > 0 else -1.0

w = {top["symbol"]: -sgn}

for pos_j, j in enumerate(rec["others"]):
    w[model["members"][j]] = sgn * float(b[1 + pos_j])

The OLS normal equations guarantee that the in-sample regression residual is orthogonal to the regressor columns. That is useful, but it should not be overstated.

It does not by itself guarantee that the live portfolio is neutral to every latent market factor out of sample. A stronger implementation should verify the final weights against the estimated factor loadings or explicitly project the executable portfolio back into the residual subspace.

The leave-one-out residual should also receive its own stationarity check. A basket-level stationary residual space does not automatically imply that every leave-one-out regression residual is stationary.

This is the automated analogue of the EWY triangle—except that it may contain many legs and is rebuilt repeatedly from data.

8. Three Traps: Perfect In Sample, Persistent Losses Out of Sample

The previous sections describe the method. The following traps are more important because each can produce an attractive backtest and a slow live loss.

Trap 1: Path Dependence in Leveraged ETFs
SOXL targets three times the daily return of a semiconductor index. TQQQ targets three times the daily return of the Nasdaq-100.

Their short-horizon correlation with the underlying market can approach 0.99, which makes them appear to be ideal relative-value partners.

But daily rebalancing means:

ln(3× leveraged ETF)  ≠  3 × ln(underlying)

The difference is path dependent and is influenced by volatility, return autocorrelation, financing costs, fees, and the daily reset mechanism.

In volatile or mean-reverting markets, this often appears as volatility drag. In strongly trending markets, a leveraged ETF may instead outperform a simple long-horizon multiple.

The key point is not that the drift is always deterministically negative. The key point is that high correlation does not imply a stable cointegrating relationship.

One practical screen marks a near-duplicate with much higher volatility as a potential leveraged version:

if abs(C[i, j]) >= DEDUP_RHO:                    # ρ > 0.97
    hi, lo = (i, j) if vol[i] > vol[j] else (j, i)

    if vol[hi] / vol[lo] >= DEDUP_VOL_RATIO:     # volatility ratio > 1.40
        drop_idx.add(hi)

# Drop SNXX, keep SNDK:
# correlation 0.9813, volatility ratio 2.15×

This only catches pairwise near-duplicates.

SOXL may not reach a correlation of 0.97 with any single constituent, so a second basket-level filter is used:

med_vol = float(np.median(vols))
out = [
    i for i in range(len(kept))
    if vols[i] > VOL_OUTLIER_MULT * med_vol
]

One log entry showed:

6  AMD,ARM,INTC,MRVL,SOXL,TSM
   basket too small after removing abnormal-volatility member ['SOXL']

The entire basket was rejected.

That is a reasonable trade-off. The expected damage from a structurally contaminated basket can be larger than the opportunity cost of losing one candidate.

Trap 2: Earnings Gaps Look Exactly Like “Misalignment”
U.S. companies often release earnings after the cash market closes, while these perpetual contracts trade around the clock.

At that moment, the rest of a sector may remain nearly unchanged while one instrument jumps 8%.

To the Q-score and leave-one-out attribution, this can look identical to a textbook relative-value opportunity:

basket residual surges;
one instrument's z-score exceeds 6;
the remaining legs barely move.

But the move may represent permanent repricing. The price does not need to return.

The distinction is not necessarily the size of the move, but its speed. A liquidity imbalance may widen progressively, whereas an event-driven repricing may occur in one step.

if q - prev["q"] > model["q_entry"] * JUMP_MULT:
    # one-cycle jump exceeds 60% of the alert threshold
    jump_until = now + JUMP_COOL_S    # four-hour cooldown

This filter is imperfect. It will reject some genuine fast dislocations.

But the cost of missing one opportunity is not comparable to the cost of repeatedly fading a permanent earnings repricing. Under that asymmetry, a conservative filter is rational.

Trap 3: Intraday Seasonality Requires More Than One Scale
The perpetual contracts trade 24 hours a day, but the underlying U.S. equities have a defined cash session.

Residual volatility during the U.S. trading session can differ by an order of magnitude from volatility during quiet Asian hours.

If one threshold is estimated from the combined sample:

it may be too loose during the active session and miss genuine dislocations;
it may be too tight overnight and create a large number of false alerts.

Simply discarding off-hours data is tempting, but it removes some of the most informative observations. Earnings releases often occur outside the cash session, producing the pure pattern of “one leg jumps while the rest remain still.”

The implementation gives each intraday slot its own scale:

Q_train = np.einsum("ij,jk,ik->i", Rn, resid_inv, Rn)
slots = ((ts[-eff:] // 3600000) % VOL_SLOTS).astype(int)

for h in range(VOL_SLOTS):
    sel = Q_train[slots == h]

    if len(sel) >= MIN_SLOT_BARS:
        slot_scale[str(h)] = float(np.median(sel)) / q_med_all

The effect appears directly in the monitoring panel:

Q (seasonally normalized)  10.17
Q (raw)                    14.78
slot factor                 1.453

The raw score was 14.78, but baseline volatility for that time slot was already about 45% higher. After normalization, the score fell to 10.17 and remained below the 18.55 alert line.

Without this adjustment, the same false signal could recur every day.

This median rescaling improves comparability, but it does not preserve an exact chi-square distribution. The final threshold should therefore be validated against empirical false-alarm frequencies.

9. In-Sample Mean Reversion Can Contain Almost No Information

This point deserves to be stated directly:

A beautiful in-sample mean-reversion chart is not evidence that the relationship will mean-revert in the future.

When a residual or z-score is centered and standardized using the same sample, its in-sample mean is forced to zero by construction. That is an algebraic property, not a discovered trading edge.

Even unrelated integrated series can produce attractive fitted residual charts over a selected window.

The only informative test is:

Freeze the parameters estimated from the training window, then observe whether future dislocations actually return.

For that reason, the system places forward validation statistics at the top of the dashboard:

def validation_stats(store):
    done = [
        a for a in store["alerts"]
        if a.get("resolved") is not None
    ]
    ok = [a for a in done if a["resolved"]]

    return {
        "rate": len(ok) / len(done),  # did Q actually return after the alert?
        "median_min": times[len(times) // 2],
        "excursion": np.mean([
            a["peak_q"] / a["q0"] for a in done
        ]),
    }

The current implementation calls the final field mae, but it computes the mean peak-Q multiple across completed alerts, not the maximum adverse excursion. The label should be changed or the calculation should be changed.

The three statistics answer different questions:

The last metric is easy to overlook.

A strategy may show an 80% reversion rate but still experience excursions of three times the entry displacement. With excessive leverage, it can fail before convergence even when the long-run direction is correct.

Being right and surviving are separate problems.

No singular-value gap, ADF statistic, or attractive chart can override the forward table. Those are admission filters, not conclusions.

Because the system screens many baskets and many residual directions, multiple-testing and selection bias also matter. Forward validation must use genuinely future observations, and the reported reversion rate should be accompanied by sample size and uncertainty intervals rather than treated as certain after only a small number of alerts.

10. The Last Mile: A Correct Signal Can Produce the Wrong Orders

One non-mathematical detail can destroy the entire construction.

Contracts trade in integer quantities.

Suppose the target for one leg is 3.7 contracts. Applying floor produces 3 contracts, an error of about 19%. Repeat that across ten legs and the executable portfolio may no longer resemble the intended neutral portfolio.

The consequence is worse than simply earning slightly less.

Once the hedge ratios are distorted, directional market exposure remains. The strategy may appear to be betting that ARM will converge toward the basket while actually carrying a large semiconductor-sector bet.

Before entry, the implementation measures the cosine similarity between target and executable signed notionals:

tgt = np.array([w.get(sy, 0.0) for sy in w])

act = np.array([
    legs[sy]["notional"] * (1 if long else -1)
    ...
])

fidelity = float(
    tgt @ act / (norm(tgt) * norm(act))
)

if fidelity < MIN_HEDGE_FID:      # default: 0.97
    return                        # cannot match the hedge: do not enter

This constraint can be inverted to estimate the minimum gross exposure required for the basket to be represented with sufficient accuracy:

needs.append(float(
    np.max(
        FID_TARGET_CT * gran[nz] * aw.sum() / aw[nz]
    )
))

min_gross = float(np.median(needs))

The dashboard can then show:

BB136E8   minimum gross exposure $11,938   currently tradable ✅
B90094A   minimum gross exposure  $4,597   currently tradable ✅

If the account is too small, the basket should not be traded.

Forcing the trade does not create “a smaller arbitrage.” It creates a directional position dominated by rounding error.

Funding is another frequently omitted cost.

Carry does not automatically cancel across long and short legs because the contracts may have different funding rates. TradFi perpetuals cannot necessarily be arbitraged directly against the underlying shares, so their basis may contain persistent structural differences.

Funding is therefore a deterministic component of realized spread P&L and must be booked explicitly:

for sym, leg in pos["legs"].items():
    rate = (
        mk["fundingRate"]
        * dt
        / mk["fundingInterval"]
    )

    acc += (
        notional * rate
        if leg["side"] == "long"
        else -notional * rate
    )

pos["funding_paid"] += acc

11. The Complete Pipeline

Figure 4 | Screening, validation, monitoring, execution, and forward statistics form a closed loop. Every earlier filter is ultimately judged by out-of-sample results.

Hundreds of contracts across the market
      ↓  Liquidity gate: open interest and long/short user count
      ↓  Exclude pre-IPO synthetic products
         (no external price anchor, so convergence has no firm basis)

Approximately 120 candidate instruments
      ↓  Hierarchical clustering
         distance = √(2(1−ρ))
         no manually supplied industry labels

Approximately 150 candidate baskets
      ↓  Remove potential leveraged duplicates
      ↓  Estimate factor count k with the MP rule
      ↓  Singular-value ratio ≥ 1.30
      ↓  First-half/second-half principal angle ≤ 20°
      ↓  ADF screening + OU half-life

Approximately 2–6 admitted baskets
      ↓  Real-time Q-score / F-shock monitoring
      ↓  Event-jump filter and intraday seasonal normalization
      ↓  Leave-one-out attribution
      ↓  Integer-contract rounding + hedge-fidelity check

Order construction
      ↓
Forward validation statistics  ← final judge

A sample live output:

ID       N   k factors   r residual dirs   σ ratio   subspace angle
BB136E8  10  1           6                 4.476     11.96°

best ADF t   half-life   stability score
-5.704       17.8 bars   0.807

AMD, ARM, ASML, INTC, MRVL, NVDA, QQQ, SPY, TSM, ...

The row means:

the ten instruments were modeled as being driven largely by one common factor;
six retained residual directions passed the implementation's stationarity screen;
the singular-value ratio was about 4.5;
the first-half/second-half residual spaces differed by about 12 degrees;
the estimated displacement half-life was about 18 bars, or 4.5 hours on 15-minute data.

This is the machine-generated analogue of the EWY triangle: a multi-leg relative-value basket with several residual directions, discovered without manually specifying the economic relationship in advance.

Human choices still remain in universe construction, thresholds, statistical assumptions, execution constraints, and risk limits. The machine automates the search; it does not remove model risk.

12. Four Things That Must Be Stated Clearly

First: There Is No Forced Convergence Mechanism
True arbitrage often has a physical or contractual convergence channel:

an ETF can be created or redeemed;
a futures contract expires or settles;
a convertible claim has enforceable cash flows.

These TradFi perpetual contracts cannot necessarily be exchanged for the underlying U.S. shares.

Their relative prices are constrained mainly by funding rates, market-maker inventory, and quoting conventions. That mechanism is much weaker than physical arbitrage.

This is therefore statistical arbitrage. Convergence is probabilistic, not guaranteed.

Second: Sample Length Is the Largest Weakness
Many of the contracts have short histories and may not have passed through a full earnings cycle.

The current sample cannot establish whether the estimated relationships remain stable across earnings seasons, index rebalances, corporate actions, or changing liquidity regimes.

Forward statistics must continue to accumulate. A few days of paper results are not enough.

Third: Every Theorem and Filter Only Raises the Probability of Forward Validity
The singular-value separation, principal-angle screen, ADF test, OU half-life, and Marchenko–Pastur rule all serve one purpose: improve the chance that the structure survives out of sample.

None provides a guarantee.

They are necessary engineering filters, not sufficient evidence of profitability.

Fourth: Large-Scale Screening Creates Multiple-Testing Risk
The process evaluates many clusters, baskets, directions, thresholds, and attribution candidates.

Even if every individual test uses a 5% significance level, the best-looking survivors can appear significant purely because so many alternatives were tried.

The forward period must remain untouched, rolling evaluation must avoid leakage, and performance claims should include the number of candidates searched and the uncertainty around the observed reversion rate.

The system ultimately reduces to one table:

🔬 Forward Validation

alerts   completed   reversion rate   median reversion time
1        0           —                —

peak adverse excursion   conclusion
—                        insufficient sample; keep collecting

An operating rule might be:

if the reversion rate remains above 60% with a sufficiently large sample and acceptable adverse excursion, the premise is worth further risk-budget discussion;
if it remains below 50%, stop the strategy rather than continuously retuning parameters.
The thresholds themselves are not universal truths. They should be interpreted together with sample size, confidence intervals, transaction costs, and drawdown.

Using parameter changes to manufacture a better historical reversion rate is the definition of overfitting.

Strategy Source
TradFi Matrix Statistical Arbitrage

The strategy is configured for Gate.io by default. Other exchanges may require symbol, metadata, fee, funding, and contract-quantity adaptations.

The default mode is paper, so it does not place real orders.

Accumulate enough out-of-sample evidence before discussing live capital.

Technical Review Notes Before Live Use

The published source should be corrected or strengthened in several places before live deployment:

Recompute half-life only from the residual directions retained after ADF screening.
Calculate the ADF pass ratio before overwriting r; otherwise pass_adf / r becomes 1 whenever any directions are retained.
Rename the current mae field or calculate a true maximum adverse excursion; the code currently averages peak_q / q0.
Test each leave-one-out trading residual for stationarity and verify executable factor exposure; OLS residual orthogonality alone does not ensure live factor neutrality.
Treat chi-square thresholds as approximate and compare them with empirical forward false-alarm rates after covariance estimation and seasonal normalization.
Correct the universe-size/member-list inconsistency in the example output.
Apply multiple-testing controls or nested forward validation when selecting among many baskets and residual directions.

This article is for quantitative research and software-design discussion only. It is not investment advice.

Implementing the D-Man V3 Bollinger Band Reversal DCA Strategy in Rust on FMZ

Dream — Wed, 26 Aug 2026 06:31:10 +0000

This strategy is intended solely for quantitative research and software design discussion. It does not constitute investment advice. DCA can accumulate exposure during one-way markets, and stop-loss orders cannot eliminate the risks of gaps, liquidation, poor liquidity, or exchange failures.

1. Three Problems with Fixed Grids in Live Trading

A fixed grid looks intuitive: add another layer whenever price falls by a fixed percentage, then close all layers together after a rebound. The problem is that market volatility is constantly changing, so the same spacing rarely remains effective for long.

The first problem is distorted grid spacing. During a low-volatility phase, ETH may fail to move even 1% for several days, so a grid that is too wide may barely trade. During an event-driven market, however, price can move several percentage points within minutes, making the same grid far too dense and causing every layer to fill in a very short time.

The second problem is that the “averaging rule” often has no explicit total budget. Some implementations define only how much larger each layer should be than the previous one, without locking in the maximum capital commitment before the cycle starts. During a continuous decline, the strategy may appear to be lowering its average entry price, while in reality it is continuously expanding an unaffordable tail-risk exposure.

The third problem is that orders and positions can become disconnected. Partial fills, unconfirmed cancellations, process restarts, or manual intervention can leave old orders active on the exchange. If the program simply creates a new grid from the latest signal, it may produce ghost orders, duplicate exits, or accidentally take over an external position.

The value of D-Man V3 is that it places all three problems inside a single cycle-management framework: Bollinger Bands define the current volatility scale, the DCA budget is fixed before entry, and all filled layers exit as one basket. The engineering implementation then uses order ownership and a persistent state machine to handle abnormal paths. This article presents a practical Rust implementation for FMZ.

2. What Exactly Is Dynamic About D-Man V3?

This implementation is based on Hummingbot’s publicly available directional_trading.dman_v3 framework. It is not simply a “buy more when price falls and sell when it rises” strategy. Instead, Bollinger Bands perform two separate tasks:

Bollinger Band percentage identifies whether price has entered a statistical extreme region.
Bollinger Band width determines how far each DCA level should be placed from the anchor price.

This means that grid spacing is no longer fixed. The grid contracts automatically in low-volatility conditions and expands in high-volatility conditions.

3. Calculating the Bollinger Reversal Signal from Closed Candles Only

Let the Bollinger middle, upper, and lower bands be Middle, Upper, and Lower:

BB% = (Close - Lower) / (Upper - Lower)

The meaning of BB% is straightforward:

0 corresponds to the lower band.
0.5 corresponds to the middle band.
1 corresponds to the upper band.
A value below 0 means the candle closed below the lower band.
A value above 1 means the candle closed above the upper band.

The practical version exposes only BBLength in the interface. The remaining signal rules are fixed as tested internal constants:

Interface parameter: BBLength = 100
Internal rules: BB_STD = 2.0, LONG_THRESHOLD = 0, SHORT_THRESHOLD = 1
Internal rule: REQUIRE_CROSS = true

FMZ’s GetRecords(symbol, period, limit) function can request candlestick data directly for a specified contract and timeframe. The Rust implementation uses the second-to-last candle as the current closed candle; the last candle, which is still forming, does not participate in signal generation.

The signal function itself is small:

fn detect_signal(
    current: &Bands,
    previous: &Bands,
    long_threshold: f64,
    short_threshold: f64,
    require_cross: bool,
) -> i32 {
    let mut long_now = current.bbp <= long_threshold;
    let mut short_now = current.bbp >= short_threshold;

    if require_cross {
        long_now = long_now && previous.bbp > long_threshold;
        short_now = short_now && previous.bbp < short_threshold;
    }

    if long_now && !short_now {
        1
    } else if short_now && !long_now {
        -1
    } else {
        0
    }
}

The “first crossing” rule is important. If price remains outside the lower band for several consecutive candles, a mean-reversion strategy should not start a new cycle on every candle. This filter cannot determine when a trend will end, but it can prevent repeated exposure from growing without limit.

4. Bollinger Half-Width Defines the DCA Grid Scale

First calculate the raw Bollinger half-width as a percentage of the middle band, then clamp it to the dynamic scale actually used by the strategy:

HalfWidthRatio = (Upper - Lower) / (2 × Middle)
ScaleRatio = clamp(HalfWidthRatio, 0.2%, 8%)

Using the latest traded price when the signal appears as the anchor:

LongPrice[i]  = AnchorPrice × (1 - Factor[i] × ScaleRatio)
ShortPrice[i] = AnchorPrice × (1 + Factor[i] × ScaleRatio)

The baseline uses four distance factors:

0.05, 0.35, 0.75, 1.25

Suppose ETH is trading at 3,000 USDT and the Bollinger half-width is 2% when the signal appears. The approximate long-side plan is:

ScaleRatio corresponds to scale_ratio in the Rust source code. The upper and lower bounds serve two purposes. In a very narrow-band environment, several theoretical prices may collapse to the same value after tick-size quantization. In an extreme-volatility environment, the grid may otherwise expand so far that it loses practical execution value.

Price quantization is not ordinary rounding:

fn round_price(runtime: &Runtime, price: f64, buy: bool) -> f64 {
    round_decimals(
        quantize(
            price,
            runtime.market.price_step,
            !buy, // round buy orders down and sell orders up
        ),
        decimal_places(
            runtime.market.price_step,
            runtime.market.price_precision,
        ),
    )
}

Buy orders are rounded down and sell orders are rounded up, preventing quantization from pushing orders to a more aggressive price. Prices across all configured layers must remain strictly monotonic. If any two layers quantize to the same price, the entire cycle is rejected.

5. A Budget Cap Matters More Than the “Averaging Multiplier”

Dynamic DCA is often misunderstood as unlimited averaging. In this implementation, the maximum budget is fixed when the cycle is created:

CycleBudget = min(
    TotalCycleQuote,
    AccountEquity × MaxCycleEquityPct
)

The default capital weights are:

1, 1, 1.5, 2.5

The four default layers therefore receive approximately 16.67%, 16.67%, 25%, and 41.66% of the cycle budget. Deeper levels receive more capital, but the strategy never adds temporary layers beyond the configured set, nor does it expand the total budget after a loss.

For FMZ futures interfaces, amount usually represents contract quantity rather than a USDT notional value. A quote-currency budget therefore cannot be passed directly to the order function. The Rust implementation reads the following fields from GetMarkets():

TickSize / AmountSize
PricePrecision / AmountPrecision
MinQty / MaxQty
MinNotional / MaxNotional
CtVal / CtValCcy

It then converts the quote-currency budget into a contract quantity.

The core planning logic can be simplified as follows:

let scale_ratio = clamp(
    bands.half_width_ratio,
    DCA_SCALE_MIN_PCT / 100.0,
    DCA_SCALE_MAX_PCT / 100.0,
);

let budget = TotalCycleQuote.min(
    equity * MaxCycleEquityPct / 100.0,
);

for (spread, weight) in spreads.iter().zip(weights.iter()) {
    let raw_price = if signal == 1 {
        anchor_price * (1.0 - spread * scale_ratio)
    } else {
        anchor_price * (1.0 + spread * scale_ratio)
    };

    let quote = budget * weight / weight_total;
    let amount = amount_from_quote(runtime, quote, raw_price)?;
    // Then validate price, quantity, and notional constraints.
}

If any single layer falls below the minimum quantity, exceeds the maximum quantity, or violates a notional constraint, the program rejects the entire cycle rather than leaving behind an incomplete plan.

6. Exit All Filled Layers as One Basket

Not every DCA layer will necessarily fill. Managing take-profit separately for each layer can easily leave fragmented positions and isolated orders. This implementation instead uses the average position price returned by the exchange and merges all filled layers into a single basket.

The dynamic exit distances use the same ScaleRatio fixed when the signal appeared:

Stop-loss distance          = 3.00 × ScaleRatio
Take-profit distance        = 1.00 × ScaleRatio
Trailing activation level   = 0.80 × ScaleRatio
Trailing pullback allowance = 0.25 × ScaleRatio

The strategy also supports the following exit conditions:

Exit when price returns to the middle band and basket profit is no lower

than the internal constant MIN_PROFIT_PCT=0.15%.
Exit after holding for more than MaxHoldingBars.
After the internal trailing-profit activation level is reached, calculate the permitted pullback using ScaleRatio.

Returns for long and short positions must be calculated separately:

fn position_return(position: &PositionView, price: f64) -> f64 {
    if position.price <= 0.0 {
        0.0
    } else if position.side == 1 {
        price / position.price - 1.0
    } else {
        1.0 - price / position.price
    }
}

If a short position also uses price / entry - 1, a price increase would incorrectly appear as a profit. Directional mistakes of this kind are well suited to being locked down with Rust unit tests.

7. From Signal to Exit: Treat Each Trade as a Complete Cycle

A reliable DCA strategy cannot treat “order submitted successfully” as its only state. Orders may be partially filled, requests may time out, and the strategy process may terminate after an order has already reached the exchange. The Rust implementation therefore models each reversal trade as a complete cycle:

IDLE
  -> PLACING
  -> ACTIVE
  -> CANCELING_FOR_EXIT
  -> SUBMITTING_EXIT
  -> EXITING
  -> IDLE

Before entry, the strategy first persists the PLACING state and the layer currently waiting to be submitted. Only after receiving a valid order ID is the order formally attached to the cycle. If a request has been sent but no order ID is returned, the strategy pauses instead of assuming failure and submitting the order again.

The exit path also follows a strict sequence: stop increasing exposure, cancel the remaining DCA entry orders, confirm that cancellation has completed, and then submit one basket-closing order based on the actual position size returned by the exchange. The cycle ends only after the position has been confirmed as zero twice in succession.

Order IDs are persisted together with the cycle. After a restart, the strategy restores order ownership before reconciling open orders and positions. If it finds an order that cannot be proven to belong to the current cycle, or if the actual position direction does not match the cycle direction, it enters HALT and waits for manual intervention. This conservative design sacrifices some automatic recovery capability in exchange for avoiding blind order resubmission.

8. The Core Parameters That Are Actually Worth Adjusting

More parameters do not automatically make a strategy more professional. For this strategy, the settings that truly affect behavior can be grouped into four categories: signal speed, cycle budget, DCA shape, and exit scale.

Parameter tuning should respect these dependencies. SignalPeriodMinutes and BBLength jointly determine the real-time span covered by the statistical window. DCA distances and capital weights should be adjusted together. The fixed quote budget and equity percentage jointly determine the actual capital cap. Take-profit and stop-loss multipliers are both based on the same dynamic volatility scale.

Rules such as the Bollinger standard deviation, first-crossing requirement, bandwidth filter, upper and lower DCA scale limits, order lifetime, cooldown period, and trailing-profit logic remain fixed. This removes a large number of difficult-to-explain parameter combinations. A rule should be exposed separately only when it is the explicit subject of a research experiment.

9. Which Markets Suit It, and Which Markets Are Dangerous?

D-Man V3 remains, at its core, a mean-reversion strategy. It is best suited to liquid markets where volatility repeatedly expands and contracts and price often returns from outside the bands toward the middle band. A dynamic grid can adapt to changes in volatility scale, but it cannot determine whether a breakout is false or the beginning of a new trend.

The most dangerous environment is a persistent one-way market. As price moves farther away, deeper DCA layers bring the average entry closer to the market, but they also concentrate notional exposure at the point of greatest risk. A budget cap can limit the amount committed, but it cannot turn a negative-expectancy countertrend trade into a safe trade.

The second source of risk is a sudden volatility regime shift. Bollinger half-width is calculated from the historical window around the signal, while an event-driven market may instantly move future volatility into an entirely different range. Even with a stop-loss, actual execution may deviate significantly because of slippage, liquidity, or exchange constraints.

The third source of risk is cost erosion. Four entry layers, cancellations, and a basket exit all incur fees. Perpetual contracts may also incur funding costs. If the target profit per cycle is too small, execution costs can easily consume the gross profit.

10. What Should a Backtest Actually Answer?

For a DCA strategy, final net profit alone is far from sufficient. A more useful approach is to split the backtest into independent cycles and observe how the strategy uses capital under different market regimes.

At minimum, the following metrics should be recorded:

Maximum capital committed and maximum margin usage per cycle.
Trigger rate and fill contribution of each DCA layer.
Maximum adverse excursion and final profit or loss for each cycle.
Longest holding period and the proportion of time-based exits.
Number of consecutive losing cycles.
Fees, slippage, and funding costs as a percentage of gross profit.
The contribution of stop-loss, take-profit, trailing-profit, middle-band, and time-based exits.

The sample should also be divided by market regime instead of testing only one long period:

Parameter sensitivity analysis should come last. If only one highly specific parameter set is profitable while nearby values all fail, the result usually depends on sample coincidence rather than a stable mechanism.

11. Engineering Reliability Is Part of the Strategy

The mean-reversion formula is short, but the live-trading path is long. Partial fills, failed order queries, cancellation delays, process restarts, and manual orders can all change the real risk. This strategy therefore enforces several boundaries:

Manage only one active cycle per symbol at a time.
Do not automatically take over positions or open orders whose ownership cannot be proven.
Do not blindly resend a request when its outcome is uncertain.
Cancel all remaining entry orders before exiting.
Close the actual position size rather than the planned quantity.
Leverage and position mode must be defined in advance and should not be treated as strategy parameters to optimize.

These rules do not improve the signal win rate, but they reduce the gap between “the backtest formula is correct” and “live orders are out of control.” For a strategy that increases exposure layer by layer, this reliability is itself part of risk management.

12. Conclusion

Strategy Source Code

The core of D-Man V3 can be summarized in three sentences: BB% identifies statistical extremes, Bollinger half-width defines the DCA scale, and all filled layers exit as one basket based on the average position price.

Compared with a fixed grid, it adapts better to changes in volatility and uses a cycle budget to prevent unlimited averaging. However, it still cannot eliminate the tail risk of mean reversion during a persistent trend. Whether the strategy can remain usable over the long term depends not only on the entry formula, but also on budget constraints, execution costs, state recovery, and conservative handling of abnormal orders.

When evaluating this type of strategy, “how much it earned” should come only after “how much capital it used,” “how much adverse movement it endured,” and “under which market conditions it failed.” The value of dynamic DCA is not that it predicts every reversal, but that it makes the risk path as clear as possible both when the reversal hypothesis succeeds and when it fails.

Thank you for reading.

Updating the Model on Every Bar: Is It Adapting to the Market, or Chasing Noise? An FMZ Rust Online Learning Comparison

Dream — Wed, 26 Aug 2026 06:01:02 +0000

A Comparative Online Learning Experiment Based on FMZ Rust

Online learning is easily presented as a natural advantage in quantitative research: markets are non-stationary, so models should continuously absorb new data.

That line of reasoning is only half complete.

Faster model updates may indeed help a model move away from historical relationships that have already broken down. But the same update mechanism can also write short-term random fluctuations into the parameters more quickly. For a trading strategy, the latter does not merely appear as unstable predictions. It also turns into higher turnover, greater sensitivity to costs, and stronger path dependence.

This article therefore does not attempt to prove that “online models are better than fixed models.” The experiment asks a more specific question:

When the model structure, features, trading rules, and cost assumptions are held completely constant, how does changing the speed at which the model absorbs new samples affect out-of-sample loss, parameter stability, turnover, and simulated equity?

To avoid mixing model differences with differences in the backtesting environment, four models run in parallel inside the same Rust strategy process. They read the same bars and use the same features and simulated execution rules. The strategy does not send orders to an exchange; it maintains four shadow accounts only.

This article includes one actual backtest to verify whether the time alignment, label distribution, predictive loss, turnover, and trading costs behave as expected. However, a single backtest is not treated as a general conclusion. The main value of the strategy is still to establish a reproducible comparison framework.

1. Research Question: Update Speed Is Itself a Source of Model Risk

Online learning usually follows the sequence “predict first, observe the label, then update.” When sample
arrives, the model first makes a prediction using its current parameters. After the true outcome becomes available, the loss is calculated and the parameters are updated.

The advantage of this approach is that new information can be absorbed incrementally without repeatedly saving and retraining on the entire history. The problem is that every new sample immediately affects the parameters.

The update mechanism can be understood as a continuous speed axis:

Never update
  ── Periodic rolling retraining
  ── Update after loss deterioration
  ── Update after every bar
  ── Update after every tick

The farther left a model sits, the more stable its parameters are, but the slower it responds to structural change. The farther right it sits, the more flexible it becomes—and the more easily it can be pushed around by short-term noise.

The experiment therefore proposes three hypotheses to test in advance, rather than assuming an answer:

Per-bar online updates may shorten the model’s recovery time after a regime change.
The same mechanism may also amplify parameter fluctuations, signal reversals, and trading costs.
Model performance may not improve monotonically with update frequency; an intermediate speed may be more stable.

2. Experimental Design: Change Only How the Model Absorbs New Samples

All four models share the same initialized parameters.

The fourth group can only be called an error-gated update mechanism. It cannot be described as a strict concept-drift detector.

An increase in predictive loss may result from a change in the conditional distribution, but it may also come from higher volatility, outliers, label randomness, or poor model calibration. This article uses loss deterioration only as an engineering trigger. It does not infer from that trigger alone that concept drift has occurred in the market.

To keep the comparison as clean as possible, all four models use exactly the same:

initial training samples;
features and standardization parameters;
logistic-regression structure;
long and short probability thresholds;
return calculation method;
one-way turnover-cost assumption.
The four simulated accounts are also settled synchronously on the same bar. As a result, differences in the outcomes mainly come from the update mechanism rather than from data segmentation, API timing, or backtest-matching differences.

3. Time Alignment: Resolve Look-Ahead Bias and Execution Assumptions First

The easiest place to make a mistake in an online model is not the gradient formula, but sample timing.

Strictly speaking, class 0 means non-up, because a bar with an opening price equal to its closing price is also encoded as 0.

The label function is:

fn make_label(
    bars: &[Bar],
    feature_index: usize,
) -> f64 {
    let next_bar =
        bars[feature_index + 1];

    if next_bar.close > next_bar.open {
        1.0
    } else {
        0.0
    }
}

The process is:

Bar t closes
        ↓
Calculate x_t and predict the direction of bar t+1
        ↓
Assume a position is established near the open of bar t+1
        ↓
Bar t+1 closes, producing the label and open-to-close return
        ↓
Evaluate the original prediction first, then allow the model to update

This is still a simplified model. A real order may not fill at the opening price of the next bar, and order-book impact, latency, and slippage will not remain fixed. The cost in the code is only a standardized stress-test assumption and does not represent the actual fee schedule of any exchange.

3.1 Identifying Completed Bars Separately in Backtesting and Live Trading
The first version of the strategy used the current time in every environment to determine whether a bar had finished. In the actual backtest, this caused a still-forming bar to be treated prematurely as a completed sample. A large number of bars therefore appeared with Open == Close, and model accuracy became abnormally close to 100%.

The corrected version uses IsVirtual() to distinguish between runtime environments:

In backtesting, it conservatively uses the second-to-last bar in the market-data array.
In live trading, it checks whether the start time of the last bar plus the bar duration is no later than the current time.
If the final bar returned by the live API has not finished, the function falls back to the second-to-last bar.

fn latest_closed_index(
    bars: &[Bar],
    is_backtest: bool,
    bar_seconds: i64,
) -> Option<usize> {
    if bars.len() < 2 {
        return None;
    }

    if is_backtest {
        return Some(bars.len() - 2);
    }

    let last_index = bars.len() - 1;
    let period_ms = bar_seconds * 1000;
    let current_time_ms =
        (UnixNano() / 1_000_000) as i64;

    if bars[last_index].time + period_ms
        <= current_time_ms
    {
        Some(last_index)
    } else {
        Some(last_index - 1)
    }
}

The cost of processing one fewer bar is far smaller than the cost of mistakenly treating incomplete data as a label.

3.2 Test-Then-Train
Whenever a new label appears, the processing order is strictly maintained as follows:

Use the previously stored prediction to calculate accuracy and Log Loss.
Use the previously determined position to calculate the return on the current bar.
Add the current sample to the training data.
Update each model according to its own rule.
Use the current completed bar to generate the prediction for the next bar.

In other words, test first and train afterward. The current sample is not fed into the model before the same sample is used to evaluate it.

4. Model: Simple Logistic Regression Is Enough for This Experiment

This article does not use a neural network or a tree model. It uses logistic regression with L2 regularization:

fn predict(
    &self,
    features: &[f64; N_FEATURES],
) -> f64 {
    let mut linear_value = self.bias;

    for j in 0..N_FEATURES {
        linear_value +=
            self.weights[j] * features[j];
    }

    Self::sigmoid(linear_value)
}

fn update(
    &mut self,
    features: &[f64; N_FEATURES],
    label: f64,
    learning_rate_scale: f64,
) {
    let probability = self.predict(features);
    let error = probability - label;
    let step =
        self.learning_rate
            * learning_rate_scale;

    for j in 0..N_FEATURES {
        let gradient = clip(
            error * features[j]
                + self.l2_penalty
                    * self.weights[j],
            -5.0,
            5.0,
        );
        self.weights[j] -= step * gradient;
    }

    self.bias -=
        step * clip(error, -1.0, 1.0);

    self.updates += 1;
}

Choosing a simple model does not imply that logistic regression is sufficient to describe the market. The purpose is to reduce confounding factors in the experiment.

If the network structure, training epochs, number of features, and update frequency are all changed at the same time, it becomes difficult to determine where the difference in returns comes from. Parameter changes in a linear model can be measured directly, making it easier to observe whether “model adaptation” is accompanied by excessive weight drift.

The code also clips individual gradients and standardized features. The purpose is not to improve returns, but to prevent an extreme bar from pushing the parameters too far in a single update.

5. Features: Retain Only Basic Price-Structure and Volume Information

The model uses eight features:

one-bar log return;
log return of the candle body;
log range between the high and low;
relative upper-wick length;
relative lower-wick length;
log change in volume;
three-bar momentum;
realized volatility of returns over the most recent five bars.

No derived indicators such as RSI, MACD, or moving-average crossovers are included, and the model does not use dozens of lagged terms.

The main part of the feature calculation is shown below:

fn raw_features(
    bars: &[Bar],
    index: usize,
) -> [f64; N_FEATURES] {
    let current = bars[index];
    let previous = bars[index - 1];
    let epsilon = 1e-12;

    let log_return_1 =
        (current.close.max(epsilon)
            / previous.close.max(epsilon))
            .ln();

    let candle_body =
        (current.close.max(epsilon)
            / current.open.max(epsilon))
            .ln();

    let range =
        (current.high.max(epsilon)
            / current.low.max(epsilon))
            .ln();

    let upper_wick =
        (current.high
            - current.open.max(current.close))
            .max(0.0)
            / current.open.max(epsilon);

    let lower_wick =
        (current.open.min(current.close)
            - current.low)
            .max(0.0)
            / current.open.max(epsilon);

    let volume_change =
        ((current.volume + epsilon)
            / (previous.volume + epsilon))
            .ln();

    let momentum_3 =
        (current.close.max(epsilon)
            / bars[index - 3]
                .close
                .max(epsilon))
            .ln();

    // Realized volatility of returns over the most recent five bars
    // The full implementation continues the calculation over the same window.

    [
        log_return_1,
        candle_body,
        range,
        upper_wick,
        lower_wick,
        volume_change,
        momentum_3,
        realized_volatility,
    ]
}

The initial samples are divided chronologically into the first 80% and the final 20%. The standardizer fits its means and standard deviations using only the first 80% of the features and then remains fixed. All four models always use the same standardizer.

The standardizer is deliberately not updated online. Otherwise, the per-bar model would receive not only parameter updates but also an additional layer of feature-distribution adaptation, and the comparison would no longer isolate a single variable.

A fixed standardizer helps keep the four models comparable, but it may also produce scale mismatch when the feature distribution changes over a long period. Therefore, the results of this experiment contain the combined effects of model-relationship failure and fixed-standardization scale mismatch. The two effects are not separately identified.

6. Initialization: All Four Models Must Start from the Same Line

By default, the code prepares 320 initial supervised samples.

Initialization is performed in two stages:

Run six epochs of batch training on the first 80% of samples.
Process the final 20% one by one using “predict—record loss—update.” The average pre-update Log Loss produced by the second stage is used as the reference loss for the error-gated model. Only after this segment has been processed is the resulting model used as the shared initial parameter state for all four models.

fn fit_initial_model(
    samples: &[Sample],
    split_index: usize,
    config: &Config,
) -> (LogisticModel, f64) {
    let mut model =
        train_model(
            &samples[..split_index],
            config.initial_epochs,
            config,
        );

    let mut loss_sum = 0.0;
    let mut count = 0usize;

    for sample in &samples[split_index..] {
        let probability =
            model.predict(&sample.x);

        loss_sum +=
            log_loss(
                probability,
                sample.y,
            );

        count += 1;

        model.update(
            &sample.x,
            sample.y,
            1.0,
        );
    }

    let baseline_loss =
        if count == 0 {
            0.69314718056
        } else {
            loss_sum / count as f64
        };

    (model, baseline_loss)
}

This treatment resolves two problems.

First, the reference loss is not an in-sample retrospective loss calculated on data the model has already trained on. It is a pre-update loss obtained in chronological order.

Second, all four models begin from the same parameter state, which has already absorbed all initialization samples. This prevents a situation in which the fixed and online models use different initial training data while later differences are still attributed to the update method.

7. Four Update Mechanisms

7.1 Fixed Model
The fixed model no longer modifies its weights after initialization.

It provides the benchmark. If subsequent performance continues to deteriorate, the relationship learned during initialization cannot be stably extrapolated. If the fixed model is instead the most stable, the additional updates have not provided enough incremental information.

It is important to note that a fixed model only means its weights and bias are no longer updated. It does not mean the predicted probability or position remains unchanged. Input features change on every bar, so fixed parameters can still generate frequent turnover.

7.2 Per-Bar Online Model
One gradient update is performed after each label becomes available:

online_model.update(
    &previous_features,
    label,
    1.0,
);

This model reacts fastest to a new environment, but it is also the most likely to interpret a short run of accidental samples as a structural change.

The learning rate is the most important risk parameter for this model. The larger the learning rate, the stronger the influence of a new sample on the parameters. This article uses the interface default of 0.02 and performs no in-sample optimization.

7.3 Rolling-Retraining Model
Under the default settings, the rolling model stores the most recent 240 samples. After every 32 new samples, its parameters are reset and the model is retrained from scratch on the samples in the window.

if processed_bars
    % config.retrain_every
    == 0
{
    periodic_model =
        retrain_from_window(
            &rolling_samples,
            &config,
        );

    periodic_retrains += 1;
}

This method has two characteristics:

Old samples are explicitly removed from the training set.
A single new sample does not immediately change the model. Instead, it takes effect together with a batch of recent samples at the next retraining point. Its adaptation is delayed, but parameter changes are usually not driven entirely by the final observation in the same way as per-bar updates. Both the rolling window and retraining interval can be adjusted in the strategy interface.

7.4 Error-Gated Model
The gated model maintains an exponential moving average of its own predictive Log Loss:

Only when recent loss exceeds the initialization reference loss by a specified proportion, and the model is not in a cooldown period, does it update at a low learning rate using a small batch of the most recent samples.

let current_gated_loss =
    log_loss(
        gated_old_probability,
        label,
    );

gated_loss_ema =
    (1.0 - config.loss_ema_alpha)
        * gated_loss_ema
        + config.loss_ema_alpha
            * current_gated_loss;

let gate_threshold =
    baseline_loss
        * config.gate_loss_multiplier;

if gate_cooldown_left == 0
    && gated_loss_ema > gate_threshold
{
    let batch_start =
        rolling_samples
            .len()
            .saturating_sub(
                config.gate_batch
            );

    for (sample_index, sample)
        in rolling_samples
            .iter()
            .enumerate()
    {
        if sample_index >= batch_start {
            gated_model.update(
                &sample.x,
                sample.y,
                config.gated_lr_scale,
            );
        }
    }

    gate_events += 1;
    gate_cooldown_left =
        config.gate_cooldown;
}

The interface defaults are:

Loss threshold: 1.10 times the reference loss.
Update batch: the most recent 32 samples.
Learning-rate scale: 0.25 times the base learning rate.
Post-update cooldown: 32 bars.

These values are only unoptimized experimental defaults. Their purpose is to define a repeatable gating rule, not to represent statistically optimal thresholds.

8. Trading Mapping and Costs

Model probabilities are mapped into three positions:

fn position_from_probability(
    probability: f64,
    config: &Config,
) -> i32 {
    if probability >= config.long_threshold {
        1
    } else if probability
        <= config.short_threshold
    {
        -1
    } else {
        0
    }
}

The default rule is:

p >= 0.55: long
p <= 0.45: short
otherwise: flat

The neutral range from 0.45 to 0.55 is intended to reduce the conversion of small probability fluctuations around 0.5 directly into trades.

The position-change amount is defined as:

Therefore:

flat to long has turnover of 1;
long to flat has turnover of 1;
a direct flip from long to short has turnover of 2. The cost is configured as an interface parameter rather than a hard-coded constant:

let cost_bps = float_parameter(
    "CostBps",
    CostBps,
    0.0,
    100.0,
    true,
)?;

cost_per_turnover:
    cost_bps / 10_000.0,

CostBps defaults to 5, meaning that 5 basis points are deducted for each unit of one-way turnover. This is an experimental parameter that can be adjusted in the strategy interface. It does not represent the actual fee rate of any specific exchange.

9. Evaluation Metrics: Do Not Look Only at Accuracy

All four models record the following metrics:

Parameter displacement is defined as the Euclidean distance of the differences in the weights and bias. Because the features use the same fixed standardizer, the four models can be compared on a relative basis.

A large parameter displacement is not an error by itself. If the market structure truly changes, the model needs to move. The combination that should raise concern is:

Parameter displacement rises rapidly
+ Turnover increases materially
+ Log Loss does not improve
+ Net equity after costs deteriorates

This looks more like the model is chasing recent samples than acquiring stable adaptive ability.

10. One Actual Backtest Under the Default Parameters

After correcting the completed-bar logic, a baseline backtest was run under the following conditions:

Instrument: ETH_USDT.swap
Timeframe: 15 minutes
Backtest period: 2025-07-09 to 2026-06-21
Initialization samples: 320
Out-of-sample bars: 33333
Base learning rate: 0.02
Rolling window: 240
One-way turnover cost: 5 bps

In the out-of-sample statistics, there were 16,644 up labels and 16,689 non-up labels. Among them, 36 bars had identical opening and closing prices. The status panel currently displays the latter category as “down,” but the actual code definition is Close <= Open; the remainder of this article therefore uses the term non-up.

10.1 The Time-Alignment Problem Has Been Corrected
The up and non-up labels are nearly balanced, and model accuracy has returned to 49%–52%. The initialization reference Log Loss is 0.6988. The earlier accuracy close to 100% did indeed come from processing incomplete bars prematurely, not from the model suddenly acquiring extremely strong predictive ability.

10.2 More Frequent Updates Did Not Improve Out-of-Sample Probability Forecasts
For a naive probability model that always outputs 0.5, the Log Loss on every sample is approximately 0.6931.

In this backtest, the average Log Loss of all four models was above that benchmark. The error-gated model was closest to 0.6931, but it still cannot be said that the model had acquired effective predictive ability.

Both per-bar online updating and rolling retraining produced clear parameter displacement, but their Log Loss rose to 0.7203 and 0.7301 respectively, both worse than the fixed model. At least for the current instrument, timeframe, features, and default parameters, more frequent model updates did not improve out-of-sample probability forecasts.

10.3 The Gating Mechanism Reduced Noise Reactions but Did Not Create a Trading Edge
The error-gated model triggered only eight updates. Its cumulative turnover fell to 6,190, and it recorded only 142 direct long-short flips, both markedly lower than the other three models.

This shows that the gating mechanism at least achieved its engineering objective: reducing the frequency with which the model changed its mind because of short-term errors.

However, its post-cost equity still fell by approximately 98%. The correct conclusion is not that “error gating has already become effective,” but rather:

Controlled updating is more stable than unconditional updating, but stability itself has not yet translated into a trading edge.

The final status display of “update threshold not reached” only means that the loss EMA was below the threshold at the end of the backtest. It does not contradict the fact that eight updates were triggered earlier in the historical path.

10.4 A Fixed Model Can Still Generate Frequent Turnover Without Updating Its Parameters
The fixed model’s parameter displacement is 0, yet its cumulative turnover is the highest of all four models.

There is no contradiction. A fixed model only means that the weights and bias no longer change. The input features x_t are still different on every bar. Fixed parameters combined with changing inputs can still produce changing probabilities and positions.

10.5 Once Equity Approaches Zero, Return Metrics Become Saturated
All four models suffered severe losses under a 5 bps one-way cost. The primary problem was not a single large loss, but the accumulation of substantial turnover across more than 30,000 bars.

Once equity approaches zero, net return and maximum drawdown both approach their limiting values, making it difficult to continue distinguishing the models economically.

A later version should at least add:

gross return before costs;
cumulative costs;
net log return;
turnover per 1,000 bars;
multiple cost scenarios at 0, 2, 5, and 10 bps.

These results cannot prove that online learning is ineffective in other markets. They only show that, under the conditions of this experiment, updating the model more frequently did not demonstrate stronger market adaptation. Controlled updating reduced reactions to noise, but the added stability did not translate into a trading edge.

11. Complete Rust Implementation

The complete strategy only reads bars and maintains four models and four simulated accounts in memory. It contains no real order-placement logic.

Strategy Code: Online Bar-by-Bar Learning Comparison Experiment (Rust)

12. How to Tell Whether a Model Is Adapting or Chasing Noise

The online model having the highest equity in a single backtest does not directly prove that online updating is effective. More informative evidence comes from the relationship between metrics and from whether the conclusion can be repeated across different periods.

Case 1: Log Loss Improves Without a Material Increase in Turnover
If the per-bar model reduces Log Loss relatively quickly after a regime change, while parameter displacement stabilizes and cumulative turnover remains close to that of the fixed model, this is stronger evidence of adaptation.

The important point is not that “the parameters moved,” but that predictive quality improved persistently after they moved.

Case 2: Accuracy Improves, but Log Loss and Equity Deteriorate
Accuracy only considers whether the predicted probability crosses 0.5. It does not account for how confident the model is.

A model may increase a probability from 0.51 to 0.90 while remaining directionally correct. But once the prediction is wrong, Log Loss deteriorates significantly. In trading, this kind of overconfidence is also more likely to push a signal across the long and short thresholds.

Therefore, it is not contradictory for the online model to have slightly higher accuracy while showing worse Log Loss, drawdown, and post-cost returns.

Case 3: An Advantage Exists at Zero Cost but Disappears After Costs Are Added
This usually means that online updating generated more marginal signals, but the edge per trade was not large enough to cover trading frictions.

The model may indeed have captured a small amount of short-term predictability, but that predictability did not reach tradable strength. An improvement in gross return cannot be equated with an effective strategy.

Case 4: Rolling Retraining or Gated Updating Is More Stable
If these two groups consistently show lower Log Loss, smaller drawdown, and lower turnover across multiple instruments and timeframes, the useful adaptation speed may lie somewhere between “never update” and “update after every bar.”

It is still important to remember that the rolling window, retraining interval, and gating threshold are themselves hyperparameters. Only the best-performing setting cannot be retained.

Case 5: The Fixed Model Performs Best
This does not mean the market is stationary. It only means that, for the current features, model, and sample period, new samples did not provide sufficiently stable information, or the online update rule did not extract that information correctly.

Stable fixed-model parameters do not imply fewer signals. In this backtest, the fixed model actually recorded the highest cumulative turnover of all four models.

13. How the Results Should Be Recorded

At a minimum, the following table should be saved separately by instrument, timeframe, and date range instead of retaining only one aggregate equity curve:

Three categories of robustness checks should also be added.

13.1 Cost Scenarios
At a minimum, compare:

0 bps
2 bps / one-way turnover
5 bps / one-way turnover
10 bps / one-way turnover

If the online model wins only with zero costs, the conclusion should be written as “it generated more gross signals,” not “it adapted better to the market.”

13.2 Neighboring Parameters
Do not perform large-scale optimization. Only check whether the conclusion is stable under neighboring parameter values, for example:

Online learning rate: 0.01 / 0.02 / 0.04
Retraining interval: 16 / 32 / 64
Rolling window: 120 / 240 / 480
Gating loss multiplier: 1.05 / 1.10 / 1.20

If an advantage appears only at one very narrow parameter point, it is more likely to be sample fitting.

13.3 Regime-by-Regime Observation
Break the results down by volatility, trend strength, or natural time periods.

Aggregate-sample returns may conceal two completely different behaviors: the model may recover faster during transitions, while continuously leaking performance in stable periods because of frequent updates. Only regime-by-regime observation can reveal where the benefits of adaptation and the costs of noise occur separately.

14. Remaining Limitations of the Experiment

First, simulated execution is not exchange matching. Entry near the next bar’s open, fixed basis-point costs, and the absence of order-book impact are all simplifying assumptions.

Second, the model predicts only the open-to-close direction of the next bar. This target makes time alignment convenient, but it does not mean it is the most economically meaningful forecasting target.

Third, the fixed standardizer preserves consistency across the model comparison, but it does not solve feature-distribution drift. Online standardization can be studied as another experiment, but it cannot be added only to the per-bar model.

Fourth, error gating is only a heuristic rule and does not carry the statistical guarantees of a drift-detection algorithm. To study formal drift identification, methods such as ADWIN and DDM should be implemented separately, with false alarms and detection delay controlled.

Fifth, a single instrument, timeframe, or backtest interval cannot answer the question “Is online learning better?” Questions of this kind can only be answered through stability across markets, regimes, and neighboring parameter settings.

Sixth, conclusions from logistic regression should not be directly extrapolated to deep models. Complex models have greater expressive power and more degrees of freedom in their updates. The noise risk of online updating does not automatically disappear as a result.

Seventh, the current simulated equity approaches zero rapidly under high turnover costs, causing net return and maximum drawdown to become saturated. Future research should report gross return, cumulative costs, net log return, and turnover per 1,000 bars at the same time, avoiding a situation in which different models all display returns close to -100% and can no longer be compared.

Conclusion

Markets change, but that does not mean a model should change immediately after every bar.

A fixed model bears the risk of “remaining trapped in an old relationship.” A per-bar online model bears the risk of “placing too much trust in the most recent samples.” There is no universal answer independent of the data, costs, and forecasting target.

For online updating to be valuable, at least three conditions should hold simultaneously:

After a new environment appears, predictive loss recovers more quickly.
Parameter changes do not evolve persistently into higher signal reversal and turnover.
The improvement survives costs and can be repeated across instruments, timeframes, and neighboring parameter settings.
In this default-parameter backtest, both per-bar online updating and rolling retraining produced clear parameter movement without lowering out-of-sample Log Loss. Error gating reduced turnover and direct long-short reversals, but it still did not produce a tradable edge.

If a model merely updates more frequently, moves its parameters farther, and trades more often—without persistently reducing out-of-sample loss—it has not adapted better to the market.

It has only learned what happened most recently, faster.

A New Arbitrage Play: After the SK Hynix Arbitrage Frenzy, Are There Still Opportunities Hidden in EWY?

Dream — Wed, 26 Aug 2026 03:47:24 +0000

SK Hynix has recently put the word “arbitrage” back in the spotlight.

With stock perpetual contracts going live, instruments such as SK Hynix and Samsung Electronics—which previously traded only through the KRX order book—gained an additional USDT-margined exposure channel with continuous 24-hour quotes. Public information shows that Binance listed SKHYNIXUSDT, SAMSUNGUSDT, and HYUNDAIUSDT on June 2, 2026. An industry report published in July noted that, during certain periods, the basis between SK Hynix’s Korean cash-market closing price and the Binance contract reached 3%–5%, while contract price differences across crypto platforms also exceeded 2% at one point. Once those spreads appeared on the screen, quantitative teams naturally rushed in. But after walking through that route myself, I did not ultimately trade it. Instead, I chose a quieter combination whose three legs could all be executed in the same account: EWY, Samsung Electronics, and SK Hynix.

This article explains the logic of the strategy: why I gave up on the cross-market basis trade, what makes the relationship among these three instruments potentially tradable, what the regression equation is doing, why the residual—not the price—is the actual trading object, how position ratios are determined, which data conditions must cause the strategy to refuse trading, and what is still missing before the current version can be considered suitable for live deployment. The strategy has been running in simulation on the FMZ Quant platform, and the source code is provided at the end.

1. The Basis Everyone Is Talking About—and the Timing Mismatch Behind It

The first point to clarify is a common wording error: listing stock perpetual contracts did not extend the trading hours of SK Hynix’s cash shares.

After the KRX closes, the underlying stock remains frozen at its final traded price, while the perpetual contract that references it continues to quote and absorb overnight macro data, movements in the Philadelphia Semiconductor Index, and exchange-rate changes. The reference asset is frozen while the derivative continues to price new information. This timing mismatch is the main source of the recent basis.

For the same reason, the so-called “fair price” after the cash market closes is unobservable. A deviation in the perpetual contract may arise from two completely opposite causes:

It may be pricing overnight information in advance → the cash market could move toward it at the next open, in which case trading convergence means catching a falling knife against the trend.
It may simply have been pushed away from its anchor by thin liquidity → the cash-market open could pull it back, in which case a convergence trade may be valid.

These two situations look exactly the same in the order book. If you cannot distinguish between them and place a bet anyway, you are not trading convergence—you are taking the other side of a new round of price discovery for the market.

2. Why I Did Not Pursue Cross-Market Arbitrage

Even if we set aside the ambiguity in pricing, building the “Korean cash equity ↔ crypto perpetual” trade requires passing through every one of the following frictions:

A nominal 3% spread does not mean 3% will end up in your pocket. And the most visible crack is usually also the most crowded one.

So I changed the approach: keep the relative-value methodology, but place every leg in the same execution environment. This cannot eliminate strategy risk, but it can first remove several layers of engineering friction—accounts, funding channels, time zones, and settlement currencies—allowing the research to focus on the statistical relationship itself.

3. The Instruments: EWY and Its Two Heaviest Weights

Figure 1: EWY is like an asset basket containing multiple Korean companies, with Samsung Electronics and SK Hynix as its two heaviest weights. The regression attempts to use those two weights to explain the basket’s main movements, while the orange fluctuation represents the temporarily unexplained residual.

EWY is an ETF that tracks the South Korean equity market. According to the holdings disclosed by iShares on July 17, 2026:

Together, the two companies account for nearly 45% of the fund—enough to explain a large share of EWY’s directional movement, but far from enough to determine it completely. The remaining components, together with exchange rates, timing mismatches, capital flows, and the basis specific to each contract, create the deviations that may be traded.

The reason for choosing this combination is not that “the three curves look similar.” The deviation has an economic attribution: the two stocks are genuinely core holdings of the ETF. Because the statistical relationship is supported by the portfolio structure, it makes sense to discuss “convergence.” If you simply brute-force correlations across thousands of contracts, it is easy to find attractive but economically meaningless spurious relationships. Once the market regime changes, those relationships disappear.

The research question therefore becomes specific:

When EWY deviates from the “implied price” given by Samsung Electronics and SK Hynix, does that deviation tend to revert?

The strategy trades three USDT-margined linear contracts within the same account:

var SYMBOLS = "EWY_USDT.swap,SAMSUNG_USDT.swap,SKHYNIX_USDT.swap";
var LABELS  = "EWY,Samsung Electronics,SK Hynix";   // The 1st is the target leg; the others are hedge legs

This must be stated clearly: it is not risk-free arbitrage. It is a relative-value trade that bets on the continuation of a statistical relationship.

4. The Model: Explaining the Basket with Two Weights

4.1 The Regression Equation—and Why It Uses Log Prices

ln(EWY) = c + β₁·ln(Samsung Electronics) + β₂·ln(SK Hynix) + ε

There are two practical reasons for using log prices rather than raw prices.

First, β becomes an elasticity coefficient. β₁ = 0.5 means that “when Samsung rises by 1%, EWY rises by 0.5%,” regardless of the absolute price levels of the three instruments. The resulting hedge ratios can be converted directly into notional amounts without multiplying by price ratios.

Second, the residual ε becomes a relative deviation. ε = 0.008 means that “EWY is approximately 0.8% more expensive than the value implied by the model.” It is a percentage. With a regression on raw prices, the residual is an absolute price difference whose units change as price levels change. It cannot be compared across time, and the standardized z-score loses its meaning.

4.2 Code Implementation
The mathematical core of the strategy is a single function. It returns not only β₁ and β₂, but also the full residual series for every K-line in the window—because the trading signal comes from the residual sequence, not from the coefficients themselves:

function regressSpread(lnTarget, lnRefs) {
    var k = lnRefs.length, n = lnTarget.length, dim = k + 1;
    var XtX = [], Xty = new Array(dim).fill(0);
    for (var i = 0; i < dim; i++) XtX.push(new Array(dim).fill(0));

    function col(j, t) { return j === 0 ? 1 : lnRefs[j - 1][t]; }

    // Accumulate the normal equations XᵀX and Xᵀy
    for (var t = 0; t < n; t++) {
        for (var i = 0; i < dim; i++) {
            Xty[i] += col(i, t) * lnTarget[t];
            for (var j = 0; j < dim; j++) XtX[i][j] += col(i, t) * col(j, t);
        }
    }
    var beta = solveLinearSystem(XtX, Xty);
    if (!beta) return null;

    // Reconstruct the residual bar by bar: actual value − model-implied value
    var resid = [];
    for (var t = 0; t < n; t++) {
        var pred = beta[0];
        for (var j = 0; j < k; j++) pred += beta[j + 1] * lnRefs[j][t];
        resid.push(lnTarget[t] - pred);
    }
    return { c: beta[0], betas: beta.slice(1), resid: resid };
}

solveLinearSystem() uses Gaussian elimination with partial pivoting. If the absolute value of a pivot is below 1e-12—meaning the two hedge legs are highly collinear and the normal equations are nearly singular—it returns null directly and invalidates the signal for that cycle. This is not numerical fussiness: Samsung and SK Hynix are both part of the Korean semiconductor sector, so collinearity is naturally high. A single ill-conditioned solution can push β to absurd magnitudes.

4.3 The Trading Object Is ε, Not Price
ε is “the part of EWY’s price that cannot be explained by the synchronized movement of Samsung and SK Hynix.” It may come from the ETF’s other constituents, such as Hyundai Motor and financial stocks, or from exchange rates, timing mismatches, funding rates, or liquidity noise.

This is the dividing line between this strategy and directional trading. We are not predicting whether the Korean stock market will rise or fall. We are betting only that “a short-term dislocation between the basket and its weights will converge.” The common movement of Samsung and SK Hynix is offset by the hedge legs, leaving only ε as the intended exposure.

The strategy runs a rolling regression on the most recent 480 fifteen-minute K-lines—approximately five trading days—and standardizes the latest residual:

z = (latest residual − mean residual over the window) / residual standard deviation over the window

There is a methodological flaw that must be acknowledged. The regression is fitted on the full sample within the window, and the latest residual participates in that fit. It is therefore naturally “pulled toward” the regression surface, systematically compressing the z-score. At the same time, the window rolls forward on every K-line, so β also changes. Strictly speaking, the residual sequence is not a set of comparable residuals generated by one fixed model. This is not fatal—rolling OLS is common in pairs trading—but it means the absolute z-score cannot be interpreted as a standard normal variable. Thresholds must be calibrated empirically; textbook conclusions such as “±2σ corresponds to 95%” cannot simply be applied.

5. The Signal: A Three-State Machine

Figure 2: A spread position is opened when the residual enters the upper or lower extreme region and closed when it returns near the mean. The reversion arrows in the chart represent the trading hypothesis; they do not mean the residual is guaranteed to converge.

The signal is a small state machine. When flat, the strategy opens a position only after the entry threshold is crossed. Once a position is open, it does not keep adding just because z remains on the same side. It waits for z to return inside the exit band or for the maximum holding period to be reached.

var state = _G('bh_state') || 'FLAT';
var holdHours = state !== 'FLAT' ? (now - entryTime) / 3600000 : 0;
var forceExit = state !== 'FLAT' && MAX_HOLD_HOURS > 0 && holdHours > MAX_HOLD_HOURS;

var newState = state;
if (state === 'FLAT') {
    if (zLatest > ENTRY_Z)       newState = 'SHORT_SPREAD';  // EWY expensive → short EWY, long both hedge legs
    else if (zLatest < -ENTRY_Z) newState = 'LONG_SPREAD';   // EWY cheap → long EWY, short both hedge legs
} else {
    if (forceExit) { newState = 'FLAT'; Log('⏰ Maximum holding time exceeded; forcing exit'); }
    else if (Math.abs(zLatest) < EXIT_Z) { newState = 'FLAT'; Log('✅ z has reverted into the exit band; closing positions'); }
}

The asymmetric entry and exit thresholds—1.0 and 0.5—are deliberate. If they were equal, z would oscillate near the threshold and repeatedly open and close positions, allowing fees to consume the entire profit. The 0.5 buffer ensures that every trade must complete at least half a standard deviation of reversion before the gain is realized.

This state machine contains two design trade-offs that need to be stated explicitly:

There is no z-based stop-loss. If z continues to widen against the position—for example, z rises from 1.2 to 3 while holding SHORT_SPREAD—the code neither adds to the position nor stops out. It waits only for |z| < 0.5 or for the 48-hour timeout. This is the classic form of a mean-reversion strategy, and also the classic way such a strategy dies: once the relationship truly breaks, the loss has no upper bound.
The strategy does not reverse. If z crosses directly to −1.5 while holding SHORT_SPREAD, the else branch checks only |z| < 0.5 and the timeout.

Neither condition is met, so the position remains unchanged until the 48-hour limit. This is an explicit behavioral boundary, not a bug, but it should be reassessed before live trading.
The purpose of MAX_HOLD_HOURS = 48 is precisely to prevent a short-term dislocation from turning into a long-term belief. In this version, it is the only hard mechanism for admitting that “the relationship may already have failed.”

6. Positioning: β Determines the Ratios

The easiest mistake in a three-leg strategy is to get the direction right but the ratio wrong.

6.1 Where the Hedge Ratios Come From
Suppose the signal says EWY is expensive and we short one unit of EWY notional. What risks is the portfolio exposed to? According to the regression equation, β₁ units of EWY’s movement come from Samsung and β₂ units come from SK Hynix. To offset those two common factors, we must simultaneously buy β₁ units of Samsung notional and β₂ units of SK Hynix notional.

In the code, it is this line:

var wr = -reg.betas[j] * wTarget;   // Direction and size of each hedge leg are determined inversely by β

The notional ratio of the three legs is therefore 1 : β₁ : β₂, after which the whole portfolio is normalized to the gross exposure budget:

var dir = state === 'SHORT_SPREAD' ? -1 : 1;
var wTarget = dir * 1.0;
var wRefs = [], gross = Math.abs(wTarget);
for (var j = 0; j < reg.betas.length; j++) {
    var wr = -reg.betas[j] * wTarget;
    wRefs.push(wr); gross += Math.abs(wr);
}
var scale = gross > 0 ? (GROSS_EXPOSURE / gross) : 0;   // Normalize Σ|w| to 0.7
weights[0] = wTarget * scale;
for (var j = 0; j < wRefs.length; j++) weights[j + 1] = wRefs[j] * scale;

The strategy then converts weights into order quantities using notional amount = weight × LEVERAGE × equity, with leverage set to 3×.

The goal of this step is not to make the portfolio incapable of losing money. It is to make the portfolio sensitive only to ε. Broad moves in Korean equities, semiconductor-sector co-movement, and USD/KRW fluctuations—the factors acting simultaneously on all three legs—are theoretically offset by the β-based ratios. What remains is the relative-value component we actually want to trade.

6.2 When Orders Are Actually Placed
β and the weights are recalculated in every loop, but the strategy does not rebalance every time. Rebalancing is triggered only in two situations:

// ① The direction of any leg flips
if ((sig.weights[i] >= 0) !== (lastWeights[i] >= 0) && (sig.weights[i] !== 0 || lastWeights[i] !== 0)) {
    needRebal = true; break;
}
// ② The absolute weight of any leg drifts by more than 20%
var lw = Math.abs(lastWeights[i]);
if (lw > 1e-9 && Math.abs(Math.abs(sig.weights[i]) - lw) / lw > DRIFT_THRESHOLD) {
    needRebal = true; break;
}

β drift is captured through condition ②: β changes → weights change → the 20% threshold is exceeded → the hedge is rebalanced. This throttling layer acknowledges that “small fluctuations in β are estimation noise, not information.” If every minor change triggered a rebalance, trading fees would drain the account before the residual had time to converge.

MIN_REBAL_USDT = 3 serves two roles. It is both the threshold below which “the deviation is too small to act on” and the closing switch on exit. After the state changes to FLAT, the weights of all three legs become zero, making their target notionals fall below 3 USDT; the rebalancing logic then closes all positions.

7. Data Hygiene: Conditions That Must Block Trading

Newly listed TradFi contracts have short histories, prices may freeze during market closures, and the hedge legs are highly collinear. A single abnormal price can push β and z to absurd levels, causing the system to believe it has found a once-in-a-century opportunity.

For that reason, the code places several hard gates before a signal can be formed. They do not create returns. Their only job is to refuse trading when the data is clearly unreliable:

// ① Price-freeze detection: a hedge leg barely changes over the entire window
//    (market closed / mark price frozen). This destabilizes the regression,
//    compresses residual standard deviation toward zero, and can explode z.
if (refMax - refMin < MIN_REF_LOGRANGE) {          // 1e-6
    Log('⚠️ ' + LABELS[j + 1] + ' price barely changed within the window (possibly closed/frozen); skipping this cycle');
    return null;
}

// ② Collinearity detection: the normal equations are nearly singular,
//    so Gaussian elimination returns null
var reg = regressSpread(lnTarget, lnRefs);
if (!reg) { Log('⚠️ Regression matrix is singular; skipping this cycle'); return null; }

// ③ Minimum residual standard deviation: a very small value means the regression
//    is unreliable and the z denominator will amplify noise into a signal
var sd = stdev(reg.resid);
if (!(sd > MIN_RESID_STD)) { return null; }        // 5e-4

// ④ z-value sanity cap: an extreme value is more likely to be bad data
//    than a genuine opportunity
if (!isFinite(zLatest) || Math.abs(zLatest) > Z_SANITY_CAP) {   // 15
    Log('⚠️ Abnormal z value (' + zLatest + '); treating it as a calculation fault and ignoring the signal');
    return null;
}

Gate ① and gate ③ address opposite ends of the same risk. When Korean equities are closed, the reference contracts may remain unchanged for a long period, compressing the residual standard deviation within the window toward zero. The denominator of z then approaches zero, and any tiny numerator is magnified into an astronomical value. A seemingly “once-in-a-lifetime” z = 40 may simply be the result of dividing by a number that should never have appeared. If such signals are not blocked, the first trigger may be enough to wipe out the account.

The full data chain is also aligned. alignData() takes the intersection of timestamps across the three K-line series, keeps only times for which all three instruments have closing prices, and requires at least 490 common K-lines before any calculation is allowed. If any leg contains a zero, negative, or non-numeric price, the entire cycle is invalidated.

All intermediate values are logged with the [DEBUG] prefix: latest close, the log-price range of every leg within the window, regression coefficients, residual mean and standard deviation, and the raw z-score. If z becomes abnormal, the logs reveal exactly which stage caused the problem, without guesswork.

8. Risk Boundaries

Apart from z-based exits and the 48-hour timeout, the only active risk control in the code is a per-leg emergency reduction. If an open leg experiences an adverse move of more than 6% between two checks, the strategy cuts that leg’s position by half.

var drop = pos.side === 'long' ? (last - cur) / last : (cur - last) / last;
if (drop >= EMERGENCY_DROP) {                    // 0.06
    Log('🚨 Emergency risk! [' + label + '][' + pos.side + '] adverse move:', _N(drop * 100, 2) + '%');
    // ... reduce the position by 50%
}

Three boundaries of this mechanism must be made clear:

① It evaluates each leg individually, not the portfolio. In a hedged portfolio, one leg falling by 6% may be completely normal if another leg rises at the same time and the portfolio’s net exposure remains unchanged. In that situation, the circuit breaker damages the hedge structure. After half of a hedge leg is removed, the remaining exposure is no longer the residual; it becomes naked directional risk. This is the part of the current version that most urgently needs to be changed.

② The reference price is updated conditionally. bh_lastCheckPrices is updated as a whole only when no leg triggers during the current cycle. Once a trigger occurs, the reference price remains unchanged, and the next cycle still compares against the old price. In a one-way market, this can cause repeated triggers and repeated halving. This is intentionally conservative, but it can make the reduction much more aggressive than expected.

③ It is an after-the-fact defense. The three legs cannot fill in the same microsecond at the same ideal price. Once the first leg fills, the other two legs still leave the portfolio exposed to the market. That is leg risk. The faster the market moves, the more likely execution error is to consume the small residual the strategy is trying to earn. A per-leg circuit breaker reduces exposure only after a loss has already occurred. It cannot replace a genuine three-leg execution-coordination mechanism.

9. Parameter Summary

⚠️ In the source code, the comment for POLL_MS says “5 minutes,” but the actual value is 1 * 60 * 1000—one minute. Polling once per minute while using 15-minute K-lines means the same unfinished bar is recalculated repeatedly. As a result, DRIFT_THRESHOLD carries a heavier throttling responsibility than originally intended. The implementation and the comment should be made consistent before live trading.

10. Two Days of Simulation—and What It Cannot Prove

The prototype ran in simulation on FMZ Quant with initial capital of 400 USDT. After two days of testing, the account recorded a certain amount of positive return.

This is enough to justify continued research, but nowhere near enough to prove profitability:

The sample is too short. Two days may cover only one market regime, or perhaps just one conveniently successful convergence. With a maximum holding period of 48 hours, the sample contains very few complete trade cycles.
Simulated execution is friendlier than the real market. Orders are filled immediately and in full at the latest price, with no fees, no slippage, and no simulation of queue priority or partial fills. Three-leg strategies are especially sensitive to exactly these issues.
Funding rates are not modeled at all. Funding rates across the three legs will not be identical. A long-short portfolio generates additional carry P&L that does not automatically cancel. The longer the holding period, the larger this bias becomes.
Leg risk is not included. In the simulation, all three legs fill “simultaneously.” Real execution does not work that way. The correct interpretation of the positive return at this stage is simply this: the workflow runs end to end, no abnormal circuit breaker was triggered, and z and β remained within reasonable ranges. Nothing more.

11. What the Current Version Does Not Implement

The difference between “the formula runs” and “capital can be entrusted to it” is the following checklist. None of these items is included in the current code, and every one of them must be completed before live deployment.

Statistical Validity

No cointegration test. The code runs rolling OLS, but “running a regression” is not the same as “establishing cointegration.” An ADF or Engle–Granger test is needed to confirm that the residual is stationary. Otherwise, the supposed mean reversion may be nothing more than a visual illusion in a short sample.
No half-life estimate. The residual has not been fitted to an OU process to estimate its reversion half-life. MAX_HOLD_HOURS = 48 is currently an arbitrary choice; it should instead be derived from the half-life.
No out-of-sample validation. There is no rolling walk-forward test and no parameter-stability analysis across market regimes. Neither ENTRY_Z = 1.0 nor LOOKBACK = 480 has been calibrated out of sample.
Costs and Execution
Fees and slippage are not modeled. The average convergence amplitude of the residual must be reevaluated to determine whether any safety margin remains after costs.
Funding-rate carry is not modeled. Funding rates for the three contracts must be tracked separately to determine whether the portfolio has a persistent carry bias toward one side.
There is no three-leg execution-coordination mechanism. The system does not specify how to complete or unwind the whole portfolio within a limited time when legs fill separately, orders are rejected, execution is delayed, or fills are partial.
Order precision is not aligned. Quantities are not rounded according to each contract’s stepSize and minimum notional requirement.
There is no trading calendar. The system does not identify KRX holidays, earnings windows, index rebalances, or other events during which β may change abruptly.

12. Where This Framework Can Be Extended

The same framework is not limited to the Korean market:

Index vs. a basket of heavily weighted sectors: short-term deviations between the S&P 500 and several high-weight sector ETFs.
Rotation among market leaders: relative dislocations between leaders and followers within the “Magnificent Seven.”
Sector ETF vs. core constituents: constructing an implied value for an ETF from several of its largest holdings.

The model also does not have to remain a three-leg structure. The instrument pool can be expanded into “one target plus multiple explanatory factors.” But a larger portfolio is not automatically more sophisticated. Every additional leg introduces another order book, another fill process, another funding rate, and another failure point. Execution error on every leg directly erodes the small residual the strategy is trying to capture.

A genuinely tradable portfolio should satisfy all three conditions at the same time:

The economic relationship makes sense—the deviation has an explanation and is not spurious correlation.
The statistical relationship survives out-of-sample testing—it is not a coincidence in a short sample.
Execution costs do not consume the expected return—net, not gross. If even one is missing, the idea is research material, not a tradable opportunity.

Conclusion
The SK Hynix basis reminded the market that new trading vehicles create new price fractures. But arbitrage opportunities do not exist only in the most crowded fracture. Indices and constituents, ETFs and baskets of leading stocks, and leaders and followers within the same theme can all temporarily lose synchronization.

Formulas describe the deviation, tools discover and execute it, and risk controls give us a chance to survive until the next deviation appears. As for the small simulated profit in front of us, the right response is not celebration. It should be treated as the starting point for the next optimization checklist.

References
Binance Academy: How to Trade SK Hynix (SKHY) on Binance
ChainCatcher: Report on the Current Development Status of the Stock Perpetual Contract Market (July 2026)
iShares: EWY Fund Information and Latest Holdings
Risk Notice: The content of this article is provided solely as a record of strategy research and simulated testing. It does not constitute investment advice. Statistical arbitrage is not risk-free arbitrage. Historical relationships, simulation results, and short-term returns do not guarantee future performance. The strategy runs in simulation mode by default. Complete every validation item listed above before switching to live trading.