A cheap trend‑following ETH/USDC bot with two models in the loop: what paper trading showed

Description and use

The trend‑following ETH/USDC bot on Base via Uniswap v3 failed to outperform a simple hold strategy in paper trading. It switched twice per session but always lost to holding, and the judge model rarely signaled trades. Inference costs were high relative to small capital sizes.

Problem

The bot was designed to trend‑follow ETH/USDC on Base via Uniswap v3, but paper trading over several days showed it did not outperform simply holding the asset.

Outcome

The bot failed to beat a simple hold strategy in all paper sessions. Forecast rule prevented any trades; trend rule caused whipsaw losses. Inference costs were 5 % of $100 capital, 0.5 % of $1,000, and 0.05 % of $10,000, making the system expensive for small accounts.

Workflow

• 1. Compute features every 60 s (EMA20 vs EMA50, recent returns, volatility, switching cost).
• 2. Send state to a judge model via HTTP API to answer four fixed questions (regime, 15‑min direction, moment quality, risk‑off).
• 3. Aggregate votes: require 5/6 or 3/4 agreements depending on preset.
• 4. Apply filters: EMA trend agreement, optional veto from a second model (DeepSeek).
• 5. Enforce hard limits (switches per day, minimum hold, loss halts, inference budget, data freshness).
• 6. Execute switch if all conditions met, using on‑chain quotes and simulated fills in paper mode.

Evidence

The bot holds one position, all of it either in ETH or in USDC, and switches sides when several independent checks agree.

Source

Every 60 seconds: 1. Code computes features… 2. A judge answers four fixed questions… 3. Votes… 4. Filters and a veto… 5. Hard limits…

Source

Under the forecast rule the bot never traded… Under the trend rule every arm switched exactly twice and every arm lost to holding.

Source

Inference is the only running cost, and it is a fixed number of dollars per month… On $100 the models eat the capital faster than any plausible edge.

Source