What you are looking at

This page is a reference implementation of trustless, fully on-chain machine-learning inference on the GenesisL1 blockchain. Six independently trained gradient-boosted decision tree (GBDT) classifiers — three asset pairs of long/short models — are stored as on-chain NFTs on chain id 29. Their weights, tree topology, split thresholds, and leaf values live in contract storage, not on a private API or someone's GPU server. Any caller can submit a feature vector and receive a deterministic prediction by invoking predictView(modelId, packedFeatures) on the ForestRuntime contract.

For a wider context on what this enables and where it's going, see the GL1F protocol pitch deck, the GenesisL1.com chain documentation, and the L1coin.com ecosystem page.

The two innovations that matter

How an inference flows

1. Feature computation The browser (or off-chain daemon) fetches recent OHLCV candles + funding-rate history from a market data source. From this it computes the model's input features locally — 33 strictly causal features for XRP/ZEC, 26 or 27 for ETH. Every operation uses only data observable at the candle's open time; there is no peek-ahead.
2. Quantization & packing Each feature is multiplied by scaleQ = 10⁶, rounded to int32, and packed in little-endian byte order in the schema's exact feature order. The result is a flat byte string handed to the contract.
3. On-chain eth_call The dApp invokes ForestRuntime.predictView(modelId, packedFeatures) as a view call — gas is free, no transaction is mined, but execution is verified against the same EVM rules. The runtime contract walks the tree ensemble identified by modelId, descending each tree via the quantized feature thresholds, summing leaf values, and returning the raw logit as int256.
4. Sigmoid & presentation The dApp divides the returned logit by scaleQ to recover a real number, applies σ(x) = 1/(1+e−x) to get a probability, and renders it. The same dApp can re-run any past candle (see Blockchain inference tab) or replay the full history (see Predictions history).

GBDT: AI for tabular data

Gradient-boosted decision trees are the methodology of choice for predictive modeling on tabular data — the kind of data this dApp works with: OHLCV candles, funding rates, derived volatility and momentum features arranged as rows × columns. The model is an ensemble of shallow decision trees built sequentially, each one trained to correct the residual error of the trees that came before. The final prediction is the sum of every tree's contribution, then mapped through the sigmoid to yield a probability.

What makes GBDTs the right tool here:

• Excellent on heterogeneous numeric features. Returns, volatility ratios, RSI, funding cumulants, hour-of-day, day-of-week — all of these live on different scales and have different relationships to the target. Trees handle this natively: each split is feature-local, so wildly different ranges and units coexist without preprocessing or normalization.
• Captures non-linear interactions automatically. The model can discover that "high RSI matters more when funding is elevated" without anyone hand-engineering the interaction term. Depth-7 to depth-9 trees explore conjunctions of up to ~7-9 conditions per leaf.
• Robust to noisy and sparse signals. Markets are mostly noise. Trees naturally regularize via shallow depth + small leaf counts, and the boosting framework keeps adding only the trees that demonstrably reduce out-of-sample error. With early stopping on a validation split, the trainer halts before overfitting the residuals.
• Interpretable per-feature attribution. Permutation importance and split-usage statistics (visible in the per-model spec sheets) show exactly which features the ensemble actually leans on. For ZEC upside the dominant signals are ATR_ratio100 and close_to_ema5; for ZEC downside it's hour and funding_cum_24h. The model's behavior is auditable, not opaque.
• Deterministic at inference time. A trained tree is a fixed structure of integer comparisons against integer thresholds. With features quantized at scaleQ = 10⁶ and stored in the same Q-format, the entire ensemble evaluates to a bit-exact output on every EVM client — which is what makes trustless on-chain verification possible at all.
• Compact and cheap to evaluate. The six models in this dApp range from 1,008 to 2,500 trees with serialized sizes between 2.7 MB and 9.5 MB on-chain. Inference is a tight loop of comparisons; a single predictView call returns in seconds on the GenesisL1 RPC.

Empirically, this combination delivers 60-65% logloss reductions against the naive class-prior baseline on held-out windows, with test accuracies of 93-96% across the six models (see the On-chain AI models tab for per-model numbers).

What this dApp does NOT do

• Training is off-chain. Models are trained on historical data using a custom C++/Python trainer (open source under CC BY-SA 4.0). What is on-chain is the resulting frozen ensemble — its weights and topology — not the training procedure. Once minted, a model is immutable.
• Market data is off-chain. Candles and funding history come from Binance Futures via the dApp's fetch calls. The chain has no oracle for them. This is a deliberate architecture choice — the on-chain part is the verifiable computation; getting fresh inputs into the EVM is a separate (and well-understood) oracle problem.
• No order execution. This is a prediction surface, not an automated trading system. Probabilities are emitted; humans (or downstream contracts) act on them. The dApp explicitly does not place trades.

Reading the rest of this page

• Web3 AI Desk — live snapshot of all six models, latest predictions for each asset pair. Click Run all 6 on-chain inferences to fire six parallel predictView calls against the chain.
• Backtest — historical chart of each prediction overlaid on actual price action, with strict-signal grading (full target hit, half-target only, delayed hit, missed, pending).
• Predictions history — table of every model output produced so far, inner-joined across the long/short pair for each asset.
• Blockchain inference — pick any past 15-minute candle, run both models against it strictly causally, see what they would have said in real time. Outcome scoring against the actual ±target move follows automatically when ≥5h of forward data exists.
• On-chain AI models — per-model spec sheet: token id, model hash, test metrics, hyperparameters, barrier configuration.

Links