DEV Community: Dream

No Explanations, Just Decisions: Plugging Jev into a Perpetual Strategy — Run It First, Talk Later

Dream — Wed, 23 Sep 2026 02:46:37 +0000

Last year, when Alpha Arena was making the rounds, several AI models were put into live trading environments, and every gain or loss sparked another round of discussion. Quant traders paid especially close attention: after spending so much time researching models and strategies, it was fascinating to see someone simply give the models capital and let them trade.

This year, Jev arrived. I recently came across an open-source project that connects Jev to Kuru's order book on Monad and makes a trading decision roughly once every 300 milliseconds, in step with Monad's block cadence. Both the code and front end are open source. One widely circulated screenshot was especially eye-catching: on one side, people were impressed by the technology; on the other, it said something along the lines of "ran for 14 hours and lost more than 300%." But the screenshot was marked as a dry run, meaning the fills were simulated, and that percentage also depends on the P&L calculation method. It should not be interpreted as a real account literally losing more than three times its initial capital.

Alpha Arena coverage · On-chain trading project source code

After watching all that, I naturally wanted to try it myself. Last year AI trading went viral; this year we have a model designed specifically to make structured judgments. As quant traders, it is hard not to plug something like that into our own strategy and see what happens.

That led to this Binance USDT-margined perpetual strategy running on FMZ. It is currently being tested live on ONE_USDT. Recently I have mainly used it to observe the kind of high-volatility, fast-moving market conditions traders often call "monster-coin" behavior. In these markets, changes in the order book and short-term price action are easier to see, and it is also easier to spot where the strategy and execution logic fail to cooperate.

Below, I will walk through how Jev was integrated, why the strategy was modified along the way, and what became visible only after it started running.

Let Jev Watch the Order Book, but Keep the Division of Labor Clear

Jev's role can be summarized in one sentence: give it the current state, ask several clearly defined questions, and let it return choices, probabilities, or scores that the program can use downstream. For this experiment, that interface is enough.

Short-term traders are familiar with situations like these: the bid side looks thick, yet the price refuses to rise; offers keep getting lifted, but new sell orders keep appearing; the market is quiet, then several aggressive buys hit in succession and the price starts stepping higher. Each of these observations can be turned into an indicator on its own. The difficult part is deciding what they mean when several appear at the same time.

What I wanted to test was whether these clues could be organized into a clean market state and handed to Jev as several specific judgments.

Official quick start

The input sent to Jev mainly includes the order book, recent trades, short-window price changes, and volatility. Missing data is explicitly marked as missing; "we did not receive the data" must not be silently converted into "buying and selling pressure is balanced."

Account positions, order sizes, and trading restrictions are kept local. That way, when a trade does not happen, we can still determine whether the model failed to produce a strong enough signal or whether the order was blocked by fees, position limits, stale market data, or another execution rule.

For execution, the strategy uses passive Maker orders in the hope of getting a better fill price. But anyone who has placed Maker orders knows the trade-off: being right does not guarantee a fill, and when you finally do get filled, it may be because the market has already started moving against you. Most of the later changes revolved around this problem.

The Most Useful Change Was Splitting "Should I Trade?" into Separate Questions

The easiest first attempt is to put market data, fees, and positions into one request and ask, "Should I buy, sell, or wait?" You get an answer, but if the model keeps saying "wait," it is hard to know why.

Does it expect the price to fall? Does it think the upside is too small to cover fees? Is it worried about chasing the move? Is the current position affecting the answer?

After reading How to Use Jev: Three Question Primitives and Layered Thresholds and comparing that approach with the official documentation, the division of labor became much clearer. The most useful idea was to split a large trading decision into several smaller judgments and then combine the answers in code.

The snippets below are taken from the core strategy logic. Some field descriptions, logs, and surrounding checks are omitted for readability.

Official design patterns

First, ask about direction and magnitude with a Choice question. For example: 30 seconds from now, is the return more likely to fall into a large decline, small decline, narrow-range move, small rise, or large rise?

The program defines these ranges in advance, and the model assigns a probability to each one.

Why ask about magnitude as well as direction? Because we have all seen trades where the direction was correct but there was almost nothing left after costs. Knowing only up or down is not enough.

The strategy asks the same type of question over several horizons. The main trading horizon is 30 seconds; the other horizons are kept mainly for comparison.

forecastHorizons().forEach(function (h) {
    questions["market_" + h] = {
        type: "choice",
        instructions: {
            question: "At " + h / 1000 +
                " seconds after state.timestamp, which interval will " +
                "R = 10000*(future mid price/state.mid - 1) fall into?"
        },
        criteria: criteria  // Five predefined return intervals
    };
});

Next, ask whether getting filled is likely to hurt. This uses a Score question.

A common Maker-order problem on the buy side is that the order refuses to fill, and then the moment it finally fills, the price drops. On the sell side, the mirror image happens: you finally sell, and the price keeps rallying.

So I evaluate the two sides separately and ask how severe the adverse-selection risk would be over the next few seconds after a passive fill.

The score levels should not be vague labels such as "low," "medium," and "high." Each level needs a concrete description: do aggressive trades and price movement point in the same adverse direction? Is there only one warning sign, or are several independent clues pointing the same way?

In the snippet below, book is the best quote on that side. adverse means a decline for a buy order and a rise for a sell order.

questions["toxicity_" + side] = {
    type: "score",
    instructions: {
        question: "If an order at " + book + " is filled, how severe is the risk " +
            "that price moves " + adverse + " by more than " +
            bounds.neutral + " bps within 5 seconds?"
    },
    criteria: [
        "Microprice, aggressive trades, and the realized price path do not point " + adverse,
        "Evidence is conflicting, or there are too few trades / too little depth to judge",
        "Microprice shifts toward " + adverse + " and aggressive flow keeps hitting that side",
        "Microprice, aggressive trades, and the realized price path all point " + adverse
    ]
};

We also need to ask whether the order is likely to fill at all. For that I use Noul.

Noul returns a number between 0 and 1 representing the model's estimated probability that a yes/no statement is true. A value close to 0.5 means the model has no strong preference between yes and no.

Here, that estimate is used to filter entry candidates that appear unlikely to fill and also helps determine the quote placement.

However, the model does not know our true queue position, and a single order-book snapshot cannot reconstruct the full sequence of cancellations and fills. So the number has to be checked against actual order records later rather than treated as ground truth.

questions["fill_" + side] = {
    type: "noul",
    instructions: {
        question: "If we place at " + book + ", will the order be filled within the next " +
            Math.round(CFG.signalTtlMs / 1000) + " seconds?"
    },
    criteria: {
        "true": "The passive order will be hit by the opposing side",
        "false": "The passive order will remain unfilled"
    }
};

Putting these three question types into one request gets much closer to the way a trader actually thinks while watching the book:

What do direction and magnitude look like?
If I place the order, is it likely to fill?
If it fills, am I likely to regret the fill immediately?

Once the answers come back, the program uses them in different places: whether the directional signal is strong enough to open a position, whether fill probability is too low, and whether higher adverse-selection risk should move the quote to a more favorable price.

Splitting the decision this way also gives us something concrete to debug. If quoting is too aggressive, inspect the risk score and quote-placement logic. If no orders ever appear, inspect which condition keeps failing.

The three question primitives

When the Market Gets Wild, a Fixed Ruler Stops Working

While running the strategy on ONE, one thing became obvious: short-term market features are easier to see. Changes in buying and selling pressure, bursts of trades, sharp rallies, and pullbacks all become visible over relatively short windows.

But large moves also magnify the weaknesses in passive quoting and exits.

The first thing that needed to change was the ruler used to define price-move magnitude.

A move that counts as a meaningful rise in a quiet market may be nothing more than ordinary noise in a token that is moving violently. If every instrument uses the same fixed boundaries, the model may still answer "large rise," "small rise," or "sideways," but those labels correspond to very different market conditions.

The strategy previously spent long periods doing nothing. After checking the logic, the reason was fairly straightforward: on one hand, we were asking the model to predict a fairly large move over a very short horizon; on the other, we also required the model to be quite confident about it. When those conditions do not match the current volatility regime, waiting for a long time without a trade is perfectly normal.

The return-interval boundaries were therefore changed to adapt to recent volatility, while preserving a floor based on fees and safety buffers.

The lines below determine the initial boundary for a "large move." Upper and lower constraints are applied afterward. The volatility scaling is only an approximation, especially in markets with jumps and abrupt reversals; it should not be interpreted as a precise forecast of future move size.

VOL.sigmaHorizonBps = VOL.sigma1mBps *
    Math.sqrt(CFG.signalHorizonMs / 60000);

var z = inverseNormal(1 - CFG.tailTargetRate);

var outer = Math.max(
    z * VOL.sigmaHorizonBps,
    minimumEdgeBps()
);

Cancel-and-requote logic has the same problem. If the strategy cancels every time the price moves slightly, it may look responsive while constantly throwing away queue position.

So the requote distance also needs to account for volatility and the instrument's minimum tick size.

I will not go through every parameter one by one. Price precision, quantity precision, and minimum-order requirements should be read from the exchange whenever possible. Distances that can be estimated from live market data should adapt automatically. The human mainly decides what to trade, how much to trade each time, and the maximum allowed position.

That reduces manual configuration mistakes when switching instruments, although the actual behavior still needs to be evaluated instrument by instrument.

A Bearish Model Does Not Automatically Mean "Open a Short Now"

Another useful idea from the reference material is that different actions should have different thresholds.

Suppose we already hold a long position and the model starts leaning bearish. That evidence may not yet be strong enough to justify opening a new short position, but it may already be strong enough to reduce part of the long.

The code therefore separates the directional probability threshold for opening a new position from the threshold for reducing an existing position.

Opening new exposure requires a stronger judgment. The strategy also checks whether the probability distribution is too diffuse and whether the passive fill probability is too low.

Reducing exposure uses a lower directional threshold.

The lines below show the core threshold-selection logic. Market-data validity, signal freshness, and the other safeguards still run around this block.

Official confidence documentation

var required = plan.reducing
    ? CFG.reduceThreshold
    : CFG.openThreshold;

decision.requiredProbability = required;

if (tail < required) {
    decision.reasonCode = "probability";
    return decision;  // Keep the default action: wait
}

The dashboard follows the same division of labor.

The Signals & Decisions panel puts the directional probability, entry and reduction thresholds, fill estimates for both sides, and adverse-selection scores in one place. The final column states why the current decision was made.

With that table, we can trace a local execution decision back to the model outputs instead of guessing why the system keeps waiting.

The Prediction Probabilities by Horizon section expands the different time scales so we can compare the model's view over short and slightly longer horizons.

One distinction matters here: the directional probabilities correspond to specific market events, while confidence measures how concentrated the answer distribution is. Confidence should not be interpreted directly as a trading win rate.

Likewise, a bullish or bearish prediction still has to pass the local execution checks before it can become an order.

Figure 1: Signal section captured from the live strategy dashboard. The upper section checks trading conditions; the lower section compares market judgments across multiple horizons. Values update while the strategy is running.

Once It Is Running, You Need to See What It Is Actually Doing

The strategy is already running live, and the dashboard is mainly there to help identify problems.

For example, when the model makes a prediction, once the forecast horizon has elapsed the strategy records which interval the realized price actually landed in. This appears in the Prediction Validation section.

For each horizon, it shows the sample count and five-class accuracy. It also includes a simple baseline that always predicts the narrow-range class.

A Brier score is displayed alongside the accuracy figures to evaluate the error of the full probability distribution. Non-overlapping samples are also tracked to reduce the problem of many consecutive forecasts covering nearly the same market interval.

Each metric tells us something different. No single number should be used to judge the entire strategy. Looking at them together makes it easier to identify which horizons and which market regimes deserve deeper investigation.

Figure 2: Prediction-validation panel. It uses the same return-interval definitions to compare the model's judgments with realized price action, while retaining a simple baseline and non-overlapping samples for later review.

Passive fill quality needs to be evaluated separately, so the dashboard also contains a Post-Fill Price Performance section.

It records the price move at several timestamps after a fill is detected. After a buy, a price rise is considered favorable; after a sell, a decline is favorable. The opposite direction is adverse.

If the market frequently moves against the order immediately after a fill, we can go back and check whether the quote was too aggressive or whether the adverse-selection score actually helped.

This measurement starts from the time the local program detects the fill. It does not subtract fees. Its purpose is to observe whether passive Maker orders are systematically exposed to adverse selection, not to report the net P&L of each trade.

Figure 3: Post-fill price-performance panel. It keeps the short-term price path after each fill so it can be compared with the earlier risk score and quote-selection logic.

When debugging, I also compare the Order Book & Order Flow, Data & Request Health, and order-history sections.

The first tells us what the model was seeing at the time. The health checks tell us whether the data was fresh and whether requests were failing. Position and order records tell us how far the execution actually progressed.

If there was a signal but no order, first inspect the decision reason and the data state. If an order was placed but never filled, then inspect the quote and the fill-probability estimate.

Read this way, each dashboard panel maps back to a specific piece of strategy logic described earlier.

There are still important things missing from the current implementation.

After a position exceeds its time budget, the strategy attempts to place a Reduce Only Maker order, but placing the order does not mean the position will be closed immediately. A complete hard stop-loss, daily-loss circuit breaker, and liquidation-distance check have not yet been added.

As I continue running the strategy, what I most want to understand is where Jev provides useful information about order-book states, and how much of that value survives the transition from a model judgment to a real passive order.

By keeping the input, judgment, execution, and validation records, there is something concrete to review afterward—and a much clearer answer to what should be changed next.

FMZ Web3 in Practice: Lessons from New-Pool Pitfalls — Building an Automated V3/V4 LP Strategy

Dream — Wed, 23 Sep 2026 01:54:53 +0000

In the previous article, we connected FMZ to Robinhood Chain and built a Uniswap V4 new-pool radar. Once a new pool appeared, the program could quickly capture information such as the trading pair, fee tier, and liquidity. That part went smoothly. With the pools now discoverable, the next question was obvious: could we provide liquidity when trading activity is high and earn some fees?

So I continued modifying the code, adding simulated entries, position valuation, and exit logic. The first results looked quite good—the simulated equity curve climbed almost all the way up. That was tempting enough that I went on to add approvals, token purchases, liquidity provision, liquidity removal, and token selling, completing the live-trading workflow.

After launching the bot, I was excited to watch the returns keep rising. Instead, I quickly learned that there are bad actors out there.

1. Three Tokens, Two Could Not Be Sold

Of the first three tokens I tried, two became impossible to sell after the purchase. I had barely used ETH to buy the target token when the liquidity on the other side was removed. It almost felt as if someone had been waiting specifically for my order. I had entered the pool hoping to earn trading fees, but before earning anything, I was already left holding tokens in the wallet.

My first reaction was that I had run into a honeypot token. But after checking the on-chain transactions, the causes still needed to be separated clearly. A token contract that restricts selling and a pool whose liquidity has been drained can both make a token effectively unsellable, but they are not the same problem.

The perp case was especially obvious. Roughly two seconds after the purchase, the original LP removed its liquidity. Our own LP position had not even been established yet. I later tried reducing the sell amount, but the quote still reported insufficient liquidity. Increasing slippage and repeating approvals did not help—the counterparty liquidity required for the swap was simply no longer there.

Looking back at the simulation curve at that point made it clear that I had celebrated too early. A simulation can value assets using the pool price, but whether that price is actually executable and whether sufficient liquidity will still exist at exit must be validated separately. Appreciation in the target token also cannot simply be counted as LP fee income. There is a full execution process between seeing a profit on paper and actually getting the capital back.

So I first changed the accounting model. Estimated income, position valuation, realized LP fees, and final cash flows are now recorded separately. If the token has not yet been sold or the transaction has not been confirmed, the round cannot be considered successfully completed and profitable.

For incomplete transactions, the program also preserves execution progress. After a restart, it first checks previously submitted transactions so that a temporarily missing receipt is not misclassified as a failure and the same purchase is not sent again.

2. Stop Racing into Brand-New Pools and Look for Pools That Can Keep Trading

After taking that loss, I changed direction. A newly created pool has very little history, and its liquidity can disappear at any moment. No matter how carefully we check before buying, there is no guarantee that the state will not change one second later.

Since the goal is to earn trading fees continuously, it makes more sense to start with pools that have already been operating for some time and still have ongoing trading activity. At least then, the main challenge is no longer fighting for the first few seconds after a pool is created.

The first version of the filter, however, was too strict: the pool had to be at least seven days old, TVL had to be at least $500,000, the fee tier could not exceed 0.3%, and additional volume and price conditions were layered on top. Each rule made sense individually, but after combining them, very few V4 pools survived the filter. The bot was certainly cautious—it just rarely opened a position.

After breaking the problem down, I found that some pools were excluded because the thresholds were too strict, some were never discovered by the program, and some belonged to protocols that were not yet supported.

So while loosening the pool-age, liquidity, and short-term volume thresholds, I also added V3 support. In practice, V3 contained more pools worth further review. Focusing only on V4 unnecessarily narrowed the candidate universe.

Adding V3 did not simply mean inserting pool addresses into a list. The V3 workflow also required identity verification, quoting, approval, entry, position creation, and exit logic.

Here, a “stable pool” means a pool whose trading activity and liquidity are relatively stable. It does not mean that we only trade stablecoin pairs. What matters is whether continuing volume can plausibly support fee income and whether capital can enter and exit under reasonable conditions.

The current thresholds—such as a minimum pool age of 12 hours and TVL of $20,000—are only research settings for this stage and still need to be calibrated against live operating data.

3. The Pool Is Clearly Visible on the Website, but the Program Cannot Find It

After expanding the search scope, another frustrating problem appeared: some pools were clearly visible when opened manually in the browser, yet the program never placed them into the candidate list. MOO was one example.

Early on, when we queried related pools through the ETH, WETH, and USDG token addresses, each API call returned only a limited number of results, and MOO was not among them. When we queried using the MOO token address itself, however, the pool appeared immediately.

The problem was simple: it had never entered our pool directory in the first place. No matter how sophisticated the downstream filtering logic was, the pool could never reach that stage.

We later added a hot-pool list and also tried reconstructing the historical directory from V3 and V4 pool-creation events. Technically, this works. But the node plan we were using allowed each eth_getLogs request to cover only ten blocks, making a historical backfill expensive in both request count and waiting time.

For a new-pool radar, following the latest events forward is a good fit. But once the goal becomes finding already-active pools, rebuilding the full directory from historical blocks turns into a separate infrastructure project.

After going around in circles, we eventually adopted the KyberSwap Earn pool-directory API. Without specifying MOO by name or address, the pool appeared in ordinary pagination.

From that point on, we separated pool discovery, market statistics, and on-chain verification:

Each directory page retrieves 100 pools. After completing one full pass, the program waits 30 minutes and then paginates again, merging and refreshing the results.

Market statistics come directly from the available API fields, while on-chain requests are concentrated on candidate verification and position management. This way, the bot does not need to spend its first hour accumulating its own market history after startup, nor does it need to repeatedly scan historical blocks just to filter existing pools.

Pagination itself also caused problems. The API sorts pools by real-time TVL, so the order can change while the program is moving through pages. As a result, the number of unique pools after deduplication may not exactly match the total reported by the API.

If the program rigidly requires those numbers to match, it may keep restarting from page one forever. We therefore retained discrepancy logging, retry handling, and periodic refreshes, while separating the idea of “this pagination pass has finished” from “the entire chain has been covered completely.”

The API provides a much broader candidate universe, but indexing delays and omissions can still occur, so continued rechecking is necessary.

4. Testing with Only 3U — So How Did Gas Reach 2.33U?

Once the pools could be discovered reliably, the next step was to measure costs seriously.

During simulation, gas was mostly treated as an estimate. In live execution, however, one LP cycle can involve wrapping ETH, approvals, swaps, adding liquidity, removing liquidity and collecting fees, selling back, and unwrapping. V3 and V4 also use different approval paths, so it is not accurate to estimate both with a rough fixed number of transactions.

We therefore wrote a standalone fee-measurement script. Using a principal budget of roughly 3U (~$3), it performed short-duration entry and exit cycles in pools pairing USDG with ETH/WETH.

The tests were designed to answer two questions first: can the entire workflow complete successfully, and how much does each individual step actually cost?

Gas is calculated from the actual usage and gas price recorded in the transaction receipt rather than from the configured estimate:

// Actual gas expenditure, in wei
var gasWei =
    BigInt(receipt.gasUsed) *
    BigInt(receipt.effectiveGasPrice);

totalGasWei += gasWei;

In the tests, the first complete V3 cycle consumed about 0.326U in gas, while a later V3 cycle reached approximately 2.33U. That result was surprising: with just a little over three dollars in principal, how had gas suddenly climbed above two dollars?

Comparing the transactions showed that the later round required more approval steps and also ran during a period of significantly higher gas prices.

In both rounds, wrapping ETH used exactly 57,647 gas, yet the actual cost was approximately 0.0139U in one round and 0.1545U in the other.

Even the same operation can cost very different amounts. We cannot simply reuse the previous result as the next transaction's expected cost.

A subsequent standalone V4 test consumed about 0.226U for the full cycle. Again, that number is only a cost sample from that particular execution.

With these measurements available, the production code was changed to reserve gas separately for each operation—wrapping, approval, swapping, LP creation, and liquidity removal—while also considering the current gas price and a safety buffer.

For token operations that have not yet been measured in live conditions, the program still keeps a relatively conservative fallback budget. What we are calibrating here is the budgeting model. Actual expenditure is still calculated from receipts, rather than hard-coding one historical test result into the strategy.

The accounting scope also needs to be clear. In the standalone fee-measurement script, the roughly 3U principal was tracked separately from gas. In the production strategy, the current 3U budget per position already includes entry gas and execution reserves.

The net change over a full cycle also mixes swap loss, price movement, and LP income. The amount remaining after subtracting gas cannot simply be labeled “swap fees.”

These rounds successfully validated the V3 and V4 capital-in/capital-out workflow and fee accounting, but they were not long-term profitability tests.

With such a small position, fixed execution costs represent a very large percentage of capital. Increasing the principal may dilute those fixed costs, but it will also change price impact, the strategy's share of liquidity, and the amount of capital at risk. Those effects still need to be evaluated separately.

5. Estimate What This Position Can Earn Before Deciding Whether to Open It

A pool can have a lot of trading activity without necessarily generating much fee income for our position.

For a concentrated-liquidity position, revenue also depends on the selected price range, current active liquidity, and the positions of other LPs. The current model therefore estimates our share of active liquidity before estimating fee income instead of directly using the APR displayed on a webpage.

For volume, the model uses the smaller of the one-hour trading volume and the six-hour average hourly trading volume. This avoids making an overly optimistic decision based only on a recent one-hour spike.

After combining the fee tier, the share of fees distributable to LPs, and the position's expected liquidity share, the estimated fee income is compared with the full round-trip cost. The core logic can be simplified as follows:

// Revenue and costs are normalized to ETH
var hourlyVolumeUSD = Math.min(volume1hUSD, volume6hUSD / 6);
var share = myLiquidity / (poolLiquidity + myLiquidity);

var expectedFeesETH = hourlyVolumeUSD / ethUSD
    * feeRate * lpFeeShare * share * 0.5;

var totalCostETH =
    quoteLossETH + slippageReserveETH + gasBudgetETH;

var requiredFeesETH =
    totalCostETH * 1.5 + principalETH * 0.01;

var incomeConditionMet = expectedFeesETH >= requiredFeesETH;

The revenue side applies a 50% discount factor. On the cost side, expected fees must cover 1.5× the total cost, with an additional 1% of principal reserved for inventory risk.

Even after that condition is met, the position must still pass capital and execution checks.

These coefficients are still model assumptions and are not supported by a sufficiently large sample of profitable trades. The discount factor and buffers are used to leave room between historical trading activity and future realized income—not to guarantee that a position will cover its costs after entry.

After a position is opened, we also need to check whether the original assumptions are actually being realized. Price deviation, net loss, and declining liquidity can all trigger an exit. Once a position has been held for ten minutes, the strategy begins checking whether actual fee accumulation is materially lagging behind expectations.

At entry, we rely on estimates. Once the position is live, actual data is available, so that data should be used to continue validating the thesis.

The earlier design of forcing an exit after a fixed 30 minutes was removed. If pool conditions have not changed, repeatedly entering and exiting simply because a timer expired adds unnecessary costs. If conditions have already deteriorated, the strategy should not wait for the timer either.

One hour is still used as the revenue-evaluation window, but it is no longer treated as a mandatory holding period.

6. What to Optimize Next After Completing This Version

At this point, the complete strategy workflow is in place: the API supplies candidates, V3 and V4 use separate execution paths, expected revenue and costs are evaluated before entry, positions are continuously checked while open, and exits are settled using actual cash flows.

Unconfirmed transactions and unresolved assets remain in the ledger. After a restart, the strategy first resumes existing workflows so that an interruption does not leave behind an untracked position.

In addition to small-scale full-cycle live tests, code checks now cover directory-pagination anomalies, pool-identity mismatches, quote failures, insufficient budgets, delayed transaction receipts, and restart recovery.

The priority is to make sure the program stops opening new positions when conditions are not satisfied and, when transaction state is unclear, verifies already-submitted transactions before sending anything again.

Only after the execution process is sufficiently robust does it make sense to evaluate the real effectiveness of pool selection and the revenue model.

Future adjustments will therefore revolve around actual operating data. In particular, we need to avoid a common trap: lowering thresholds simply because the strategy is not opening positions, then immediately tightening them after a loss, until the system is just oscillating between parameter sets.

Every change should correspond to a specific problem and have a measurable comparison metric:

Looking back, the main value of this experiment was that it forced us to fill in the parts that simulations easily gloss over: where the pool comes from, how capital actually enters, how costs are calculated, and whether the exit is truly completed.

With those pieces now represented explicitly in the strategy, later optimization can build on a stable foundation instead of redesigning the entire system every time a new problem appears.

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.