The real technology edge in web3 is not a smarter model, it is seeing orders, signals and transactions before they execute. Once you see them first, the question is no longer “where is price going” but “should this pending action be allowed through” — a judgement problem, not a forecasting problem.
Evidence: this kind of model cannot do arithmetic
A test on 200 BTC 5-minute samples from Hyperliquid (public candleSnapshot API), asking for the next candle direction at a 5 basis point threshold. Feeding 20 raw candles: 0.315 accuracy. Switching to pre-computed signals discretised into semantics (RSI 27.4 becomes “oversold”, volume 2.4x becomes “spike”): 0.360. The always-“flat” baseline: 0.48. No directional skill at all, even though mean confidence rose from 0.264 to 0.485 — it knows that it does not know.
Principles
- Code computes and code enforces; the model only labels.
- Every threshold and comparison lives in code; only semantics go into the prompt.
- Low confidence falls back to a deterministic rule instead of letting the model decide.
- Never use the model for position sizing or as a hard gate on real-money orders.
Latency decides the architecture
The Jev API measured 521 ms per call from Vietnam to US-West, before real-world network jitter. With a window of one second or more (pre-signature checks, per-block, batch processing) the API is usable. In a sub-second race you have to self-host: laya runs at 236 ms per sample on a local CPU and costs no tokens.
Do this first
Build the decision log before building the model: before every execution, record the state and discretised features, the model's label, its confidence, and the outcome afterwards. One table, one writer. That is the only asset money cannot buy, and the precondition for choosing or fine-tuning a model later. The three-model comparison is in Measured: Jev, laya and an LLM.