ML Features That Actually Predict Solana AMM Price Moves

Most Solana ML pipelines I've reviewed fail at the same place: the feature set is borrowed from CEX equity research, shoehorned onto on-chain data, and validated with a naive chronological split that leaks future information into training. The result is backtests that look compelling and live books that bleed. What follows is a concrete accounting of which feature families actually carry predictive signal on Jupiter aggregator swaps, how they're constructed, and how they hold up under a walk-forward purge-and-embargo evaluation.

The Baseline and Evaluation Protocol

The target variable is mid-price return over the next 10 slots (~4 seconds) on a SOL/USDC route through Orca Whirlpools. The baseline model is XGBoost with default hyperparameters, trained on 90 days of 400ms snapshot data pulled from a self-hosted Geyser gRPC feed. Walk-forward folds are 7-day training windows with a 2-day embargo followed by a 1-day test window. The embargo eliminates autocorrelation leakage — a gap that most teams skip and then wonder why their Sharpe collapses in week two.

Fourteen feature families were evaluated. Lift is reported as information coefficient (IC) improvement over the raw lagged-return baseline.

CLOB Imbalance and Quote Pressure

Serum-style CLOB data is gone post-migration, but Phoenix and OpenBook v2 still expose full order books. Bid-ask imbalance — (bid_vol - ask_vol) / (bid_vol + ask_vol) — computed at the top three levels, is the single strongest predictor in the set: IC of 0.041 in-sample, 0.029 out-of-sample after embargo. The degradation is meaningful but the signal survives. Stacking exponentially weighted versions at 5, 20, and 60-slot horizons adds another 0.006 IC without overfitting, as long as you standardize within each fold rather than globally.

Quote refresh rate — how many times the best bid or ask updates per slot — is weaker (IC 0.011) but orthogonal enough to include. It proxies informed trader activity without requiring you to identify wallets.

Liquidity-Pool Reserve Ratios

For AMM-routed flow, pool reserve imbalance is the equivalent of CLOB depth. On a constant-product pool, ln(reserve_A / reserve_B) - ln(fair_value) gives you a real-time measure of how far the pool has drifted from equilibrium. This feature carries IC 0.023 on its own, and it's particularly useful in multi-hop routes where the intermediate pool is the binding constraint on price.

One trap: Orca Whirlpools are concentrated liquidity, so naive reserve ratios are misleading outside active tick ranges. You need to reconstruct virtual reserves for the current tick range. It's an extra 40 lines of math but it doubles the feature's predictive value.

Validator Vote Counts and Slot Timing

This one surprises most people. The number of validators that have voted on the current slot, available from the VoteState accounts, is a proxy for how close the network is to confirming the block. When vote count is low relative to the slot age, latency is elevated, and price discovery lags. This feature doesn't predict direction — it predicts when not to trade. Filtering out periods where vote count is below the 20th percentile for that slot age improves net Sharpe by roughly 0.15 without touching the directional model at all.

Slot timing jitter — variance in slot duration over the trailing 30 slots — is a related signal. High jitter correlates with validator instability and wider effective spreads even when quoted spreads look normal.

On-Chain Program Call Frequency

Counting Jupiter program invocations per slot gives you a rough order-flow proxy. High call frequency means more routed volume is hitting the pools you're trading against, which compresses the mean-reversion half-life. We bin this into three regimes (quiet / normal / congested) and fit separate XGBoost models per regime rather than using frequency as a raw feature. Cross-entropy loss drops 8% with that regime split versus a single model with frequency as an input. The failure mode of a single model is that it learns an average behavior that's wrong in all three regimes.

Program call frequency for adjacent programs — marginfi, Kamino, drift — adds marginal IC (0.008 combined) because leveraged position changes upstream tend to ripple into AMM routes within 5-15 slots.

Features That Failed the Embargo Test

Three families looked strong in-sample and didn't survive:

• Wallet-level behavioral clustering: IC 0.038 in-sample, 0.004 out-of-sample. Wallet fingerprints are non-stationary; new wallets appear, old ones rotate. The feature was memorizing specific wallets rather than learning a behavior pattern.
• Raw transaction fee percentiles: Correlated with congestion but dominated by the slot-timing features above. Redundant after SHAP analysis.
• Token transfer graph centrality: Interesting research direction, 200ms compute latency per snapshot. Not usable in a 400ms loop on current hardware.

Combining Features: What the Ablation Shows

Running sequential feature ablation on the full 14-family set, the marginal IC contribution flattens sharply after the first five families. Adding features 6 through 14 collectively adds 0.003 IC at the cost of a 40% increase in training time and a measurable increase in out-of-sample variance. The practical takeaway: build a tight, interpretable set around CLOB imbalance, virtual reserve drift, and slot timing before reaching for exotic signals. A model you can explain and debug in production is worth more than one with a marginally better backtest.

The trading bots we build and operate at TierZero go through exactly this kind of feature-selection discipline before any capital is committed. Signal that can't survive an embargo split doesn't make the cut.

---

If you're building a Solana execution system and want to pressure-test your feature set or evaluation methodology, reach out to the team — we're available for technical consulting and co-development engagements.