jev-trader: A 2,000-Star Market Maker Built on Jev

jev-trader is, by star count, the second-biggest project in the Jev ecosystem outside the browser-automation space: 2,128 stars as of September 2026, per the awesome-jev-projects radar. The name suggests something more exotic than what's actually in the repo. It's a market-making bot for a single spot pair — MON-USDC — on Kuru's order book on the Monad chain, not a perpetuals or leveraged-futures trader. That distinction matters, because market-making and perp trading carry very different risk profiles, and the README doesn't claim the latter.

The interesting engineering decision here isn't the trading strategy — it's the default posture. Out of the box, jev-trader reads real order-book data, makes real Jev-driven decisions, and simulates the fills. Nothing touches the chain until you explicitly add a private key. This article covers what the bot does, what its README actually measures, and what it doesn't.

Key Takeaways

• It's a spot market maker, not a perp bot. jev-trader posts post-only limit orders one tick inside the spread on Kuru's MON-USDC book, aiming to earn the bid-ask spread rather than pay it.
• No capital is at risk by default. Without a PRIVATE_KEY set in .env, the bot runs entirely in dry-run mode: real market data, simulated fills.
• Jev predicts direction over a fixed horizon. The README states Jev forecasts price movement over roughly 100 blocks (~30 seconds) and returns buy/sell/hold probabilities; the bot acts on whichever is highest.
• The README reports specific latency numbers: roughly 81ms for the Jev call itself, and separately, dry-run benchmarks of an 18ms median order-book read and a 100ms median full decision loop.
• No profitability figures are published. The repo documents latency and architecture, not returns — treat any claim of live P&L as unverified until someone publishes one.

What the bot actually does

The loop is straightforward: read the current order book via an eth_call, feed the resulting state to Jev, get back buy/sell/hold probabilities for the next roughly 100 blocks (about 30 seconds on Monad), and act on the highest-probability outcome by posting a post-only limit order one tick inside the current spread. Posting inside the spread rather than crossing it is the market-maker's core move — you're trying to be the one who earns the spread, not the one who pays it, which only works if your orders actually get filled by someone crossing to meet you.

Orders are refreshed roughly every 300ms, and the project frames that as a hard execution budget: Monad charges gas on a posted limit order whether or not it ultimately fills, so the cost of running the loop is deterministic in a way that pure off-chain strategies aren't. That's a real constraint that shapes the whole design — every decision cycle has a gas cost attached, which is not true of most software trading bots.

Reading the latency numbers correctly

The README states two different latency figures, and it's worth keeping them separate. The Jev model call itself is reported at roughly 81ms. Separately, dry-run benchmarks report a median order-book read of 18ms and a median full decision loop of 100ms. Neither figure has been independently retested by this site, and both are self-reported from the author's own environment — treat them as a starting point for your own measurement, not a guarantee for yours. Given the stated 300ms execution budget, an 81-100ms model-and-decision cost leaves real headroom, but that headroom will shrink or vanish depending on your own network path to both the model and the chain.

What "mock model" and "dry run" mean here

By default, jev-trader runs what the README calls a "mock" model — described as a momentum-based heuristic standing in for Jev — and simulates fills rather than submitting transactions. This is deliberate: you can watch the bot make real decisions against live order-book data without risking capital or needing a wallet at all. Going live requires explicitly setting a private key in the environment file; there's no accidental path from dry-run to real trading. That's a sound default for a strategy this new, and it's worth checking that any fork or derivative of the project preserves it before you run one.

What the README does not provide is any measurement of actual trading performance — no realized spread capture, no win rate, no comparison against a passive holding baseline. That's a meaningful gap for anything billed as a trading strategy, and it's the reason to treat this as an architecture and latency case study rather than evidence the strategy is profitable. jev-trader is MIT-licensed and listed on aiskill.market as jev-trader.

What to do next

1. Read the repo directly before running anything beyond dry-run mode, and confirm your fork still defaults to it.
2. If you adapt this pattern, measure your own end-to-end latency on your network path rather than trusting the published 81ms figure.
3. For the broader case of Jev making fast decisions under a hard time budget, see real-time Jev: loops, games and trading.
4. For how to judge a claim like this one on its own evidence, see how to evaluate Jev projects honestly.