jev-trader

This review covers software, not a trading strategy. Nothing here is financial advice. We only ran the bot in dry-run mode and did not trade real funds.

What it does

jev-trader is a market-making bot for the MON-USDC order book on Kuru, an exchange on the Monad blockchain. On every block, roughly every 300 milliseconds, it reads the order book and asks Jev a single question: will the price be higher or lower over the next 100 blocks (about 30 seconds)? It then posts a post-only limit order one tick inside the best price on that side, cancelling its previous order in the same transaction. It earns the spread when someone else’s order fills it, rather than paying the spread.

A small server streams every block’s book, decision, order, fills, position, and running totals over server-sent events. A dashboard app is included, and the author hosts a public dashboard running in dry-run mode with the built-in mock model.

Setup

cp .env.example .env
bun install
bun run start

With no PRIVATE_KEY, or with DRY_RUN=true, it dry-runs: it reads the real order book and makes real decisions, but orders are simulated and filled against real trades. To use Jev, set MODEL=jev and TYPESAFE_AI_API_KEY. The default mock model is a simple momentum heuristic. Jev is called through the Vercel AI SDK’s TypeSafe provider (@ai-sdk/typesafe-ai) with experimental_evaluate, which makes this a handy reference if you already use the AI SDK.

The repository has no automated test suite. Its scripts/ folder holds probes and checks, including one that signs orders offline and asserts the encoded transaction matches the exchange SDK’s.

Using it (dry run)

We built the image with the repository’s own Dockerfile, left out any private key, and ran it against Monad’s public RPC, first with the mock model and then with Jev.

• It’s safe by default. The status endpoint reported dry-run mode with no wallet. Every order was marked simulated, and nothing tried to deposit funds or send transactions.
• The event stream works as documented. We received a snapshot on connect, one event per block, and separate fill events for simulated fills.
• The Jev path ran cleanly. Decisions came back through the AI SDK provider with no errors logged. By design only one decision is in flight at a time, and a block that arrives before the previous decision finishes is marked late and skipped. How many that is depends on your network and API latency.
• The README is a small engineering essay. It explains how the loop fits in one block with only two network round trips, why gas limits are fixed rather than estimated (Monad charges gas on the limit, not on usage), and how fee settings interact. It’s worth reading even if you never run the bot.

Money and permissions

Read this before setting a private key.

• Your private key sits in .env. Use a dedicated wallet holding only what you’re willing to lose.
• It moves funds at startup. In live mode it tops up the exchange’s margin account to the configured balances (600 MON and 20 USDC by default), and grants that margin contract an unlimited USDC allowance. Unlimited approvals are common in DeFi, but they mean a problem with that contract could reach all the USDC in the wallet.
• Gas is a constant cost. It sends one transaction per block. The example config estimates about 0.03 MON of gas per block live. At roughly three blocks per second, that works out to about 360 MON per hour whether or not any order fills. Check the current price of MON and your expected fills before running live.
• Risk controls are minimal. There’s a position cap (MAX_POSITION_MON, 1,000 MON by default). There’s no stop-loss, no daily loss limit, and no gas budget. BANKROLL_USD is only used to report percentage P&L.
• Failures can leave a stale order. In the code, cancelling the previous order is bundled into placing the next one. If a block’s decision fails or arrives late, no new order is sent, so the previous order stays on the book at its old price. During a long Jev or RPC outage, that order could fill after the market has moved. We found this by reading the code, not in a live run.
• Only market data goes to TypeSafe. Jev receives public order-book, price, and recent-trade features, plus whether each side is currently allowed under your position cap. It doesn’t receive your keys, balances, or position size.

Maintenance

jev-trader was written in one evening (September 16) across a dozen commits and hasn’t been updated since. It’s MIT licensed and has been forked widely. Treat it as a published experiment, not a maintained trading system.

Verdict

As a piece of engineering writing and a reference for latency-critical Jev loops, jev-trader is excellent: small, readable, and honest about how it works. Dry-run mode makes it safe to explore. As a live trading bot, it’s a demo. Before putting real funds behind it, you’d want at least a loss limit, a gas budget, and cancel-on-error handling, plus your own judgment about whether the strategy makes sense. None of this is financial advice.

For a trading agent that keeps Jev in a shadow, advisory role instead of placing orders, see Prism. For other latency-sensitive Jev loops, see the games and real-time demos.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 19, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.