Question 1

How are miner predictions kept secret before the deadline?

Accepted Answer

Miners submit V2 JSON payloads encrypted via dual-path AEAD: an owner path (X25519 + ChaCha20-Poly1305) allows immediate decryption for trading, and a timelock path uses Drand BLS12-381 IBE. After PAYLOAD_MATURITY_BLOCKS (~1 week), validators decrypt via the public Drand beacon signature. A SHA-256 binding hash over the hotkey, round, owner key, and ephemeral key prevents replay and substitution. Ciphertexts are stored in SQLite until maturation; no party can observe plaintexts before the beacon signature is published.

Question 2

What types of predictions do miners submit?

Accepted Answer

Miners submit embedded prediction vectors tailored to each challenge: 2-dimensional binary direction predictions (ETH, forex), 17-dimensional regime/quantile predictions (volatility challenges), 3-dimensional barrier-hit probabilities, 2-dimensional per-asset range breakout continuations/reversals, 1-dimensional per-asset cross-sectional return ranks, 1-dimensional funding-rate ranks, and 28-dimensional bracket trades (4 regimes × 7 fields: direction, Kelly, stop, target1, target2, horizon, ID). Predictions are encrypted at submission and stored with live prices; embeddings backfill onto price rows after decryption.

Question 3

How does the validator score predictions from different miners?

Accepted Answer

Validators use walk-forward machine learning: for each challenge, they split historical decrypted embeddings and prices into training/test segments, fit per-miner L2 logistic regression models, and measure feature importance via coefficients or AUC. Challenge-specific scorers apply regularization (L1 and L2), uniqueness penalties (to suppress clones), and recency weighting. Per-challenge salience vectors are normalized, multiplied by challenge weight, and aggregated into a final per-miner score. EMA smoothing (α=0.15) is applied across weight-setting intervals to reduce block-to-block variance before on-chain weight submission.

Question 4

What prevents miners from copying each other?

Accepted Answer

L2 regularization splits coefficient mass among correlated miners: if n clones submit identical predictions, each receives approximately w/n weight. In binary and LBFGS challenges, L1 and uniqueness penalties drive redundant or zero-information miners toward zero. Validators compare miner overlap during LBFGS scoring and penalize miners >85% identical to higher-ranked peers. This sybil resistance is enforced at the scoring layer without explicit on-chain penalties.

Question 5

How does capital-at-risk (FLOW) scoring work differently?

Accepted Answer

FLOW miners post bracket trades (direction, Kelly fraction, stop, two targets, horizon) directly onto the FlowCollateralPool smart contract, locking collateral. Trades are resolved against multi-venue klines post-maturity; returns are path-penalized, tail-amplified, and Kelly-weighted into per-regime EWMA scores. A significance gate (rolling/historical t-statistic on 168-hour block sums) gates payment eligibility. Once cleared, winners split the pool pro rata; uncleared keys split a 2% dust tier; remainder burns. Settlement is weekly and zero-sum, enforced on-chain with a permissionless expiry sweep if the owner fails.

Question 6

What hardware is required to run a validator?

Accepted Answer

MANTIS validators require an NVIDIA GeForce RTX 4090 GPU (listed in min_compute.yml). Scoring is CPU-based (pure numpy/sklearn with CUDA disabled by default for reproducibility), but torch is installed as a dependency. Single-threaded BLAS thread-pinning (enforced via environment variables in config.py) ensures deterministic numerical output across different hardware, driving validator agreement on weight vectors.

Question 7

How often are validator weights updated on-chain?

Accepted Answer

Validators set on-chain weights every WEIGHT_SET_INTERVAL (360 blocks, ~1.2 hours). Weight calculation runs every WEIGHT_CALC_INTERVAL (1000 blocks, ~3.3 hours) but only contributes to on-chain submission during set intervals. This decoupling allows computation and smoothing to happen independently of network confirmation latency. Miner payloads are sampled every SAMPLE_EVERY (5 blocks, 60 seconds).

Question 8

Can validators replay or substitute encrypted payloads?

Accepted Answer

No. Each encrypted payload includes a SHA-256 binding hash over the miner's hotkey, Drand round number, owner public key, and ephemeral public key, used as additional authenticated data (AAD) in the AEAD scheme. This prevents replay across different rounds, relay to different validators, and substitution of the encrypted ciphertext. Decryption fails if the hash does not match.

Question 9

What data does the validator publish?

Accepted Answer

Validators maintain SQLite datalogs with (challenge_ticker, sample_index) rows storing prices, hotkey lists, and binary float16 embeddings. FLOW data lives in a separate file (flow_datalog.db) attached as schema `inv`. Datalogs are published to Cloudflare R2 as consistent snapshots (using VACUUM INTO to prevent torn reads). Miners and researchers can download these datalogs to audit scoring and train models using historical walk-forward training data streamed via generator iteration.

Question 10

What happens if a miner submits predictions for only some challenges?

Accepted Answer

Miners can submit predictions for any subset of the 12 challenges. Per-challenge scoring only includes miners with valid embeddings for that challenge. The final aggregated score uses weighted average of per-challenge salience vectors; missing challenges contribute zero to that average. Challenge weights are fixed in config.py (binary=1.0, forex=0.5, hitfirst=1.25, lbfgs variants=3.5–2.875, breakout=5.0, xsec_rank=3.0, funding_xsec=4.0, flow=0.0 at launch, 7.875 at turn-on).

MANTIS

MANTIS

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup

Participate

Participate

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup