Question 1

If the code already computes the probability, what is Jev actually contributing?

Accepted Answer

Two separable jobs behind flags. The regime Score adjusts sigma, and two Nouls can veto: one for an anomalous window and one for direction, where the model's answer must not disagree with the resolution rule. With JEV_GATE and JEV_REGIME_ADJUST both off, the engine never calls it. The author's own measurement is that the direction question added nothing, so treat the veto as unproven value rather than a core component.

Question 2

Is running this against Polymarket's terms of service?

Accepted Answer

The README puts a warning at the top and tells you to start in paper with shadow profiles. Live mode places real orders, an egress watcher checks the exit country against Polymarket's geoblock list with a SOCKS proxy primary and comma-separated fallbacks, a route that is down or returns a region 403 goes to quarantine, and if no acceptable route remains the engine stops posting. Clearing the terms and the law where you run is still on you.

Question 3

How do I tell whether a config change actually helped?

Accepted Answer

SHADOW_PROFILES starts extra paper engines in the same process, sharing the feed and the Jev verdicts but with their own ledgers and their own parameter prefixes, and shadow engines never receive the wallet key. report_5m.py then compares each profile against control only over windows both resolved, because engines born at different hours see different windows and summing everything compares luck rather than parameters. It also reports Brier by probability bucket, window phase and regime, the veto effect, fill and latency stats, and the early-exit counterfactual.

Question 4

What are the sharpest operational edges in the order handling?

Accepted Answer

A post with no response from the CLOB may have been accepted without returning an id, so the engine cancels everything and ends the window; a 4xx is a rejection and counts as a requote. get_order returns None for any order no longer on the book, so fills are read from trades by summing matched amounts, and there is a second trades query before requoting because indexing lags and a premature no-fill becomes a duplicate position. The engine records the outcome of every window it saw, not only the ones it bet.

Question 5

How do I run it, and is there an offline test path?

Accepted Answer

Python venv, pip install -r requirements.txt, then cp .env.example .env with TYPESAFE_API_KEY filled in and everything else defaulted, and PYTHONPATH=. pytest -q, which the README says is 100% offline. service_runner.py is the daemon and report_5m.py is the deterministic ledger report. Nothing needs a wallet key in paper mode, which is the shipped default.

Question 6

What is behind the flags that ship switched off?

Accepted Answer

Each hypothesis has its own key and runs in shadow and paper before anything reaches live. ALLOW_TAKER with TAKER_MIN_EDGE at 0,10 only takes the ask when edge_taker beats MAKER_FILL_RATE times edge_maker, and MAKER_FILL_RATE_AUTO measured 91% per window on 18/09/2026 against the 50% an order-level count suggests, which keeps maker ahead at 0,105 to 0,091. EARLY_EXIT_P and SIZING_MODE=conviction sit in the same group.

Question 7

Can it trade anything other than Bitcoin?

Accepted Answer

Yes, one asset per engine. ASSET=btc, eth or sol picks the market, and each asset carries its own slug, symbol, Chainlink feed, sigma prior and typical move in src/assets.py. Several assets means several engines in one process, each with its own feed and ledger. Liquidity measured the same day was BTC about 17,8k, ETH 4,2k and SOL 4,8k, on the same one-cent tick and five-share minimum.

Polymarket Btc 5M Agent

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev guides

From the Jev community