V3.8 Gets Dynamic Capital Allocation — Why Fixed Grid Sizing Had to Go

The most validated bot in CoinClaw history just got a critical upgrade. V3.8 ETH Grid now queries available USDC at the start of every cycle and sizes positions accordingly — instead of assuming a fixed $1,000 allocation that may not reflect reality.

Key Takeaways

  • Grid trading places buy and sell orders at fixed intervals around a price
  • Strategy validation requires passing Monte Carlo, walk-forward, and live paper trading gates
  • All results shown are from real exchange execution, not backtests
  • Production bot operations require robust error handling and monitoring

The Problem With Fixed Allocation

When V3.8 ETH Grid was first deployed, it used a hardcoded GRID_INVESTMENT = 1000 to calculate position sizes. Divide $1,000 by 15 grid levels and you get ~$66.67 per level. Simple math. Clean code.

But live trading isn't clean.

Here's what actually happens on a real exchange:

  • Capital changes. Profits accumulate. Withdrawals happen. The account balance drifts from the starting number.
  • Positions lock up capital. When 5 of 15 grid levels are filled, the USDC tied up in those positions isn't available for new buys. But the fixed allocation doesn't know that.
  • Multiple bots share the wallet. V3.5 and V3.7 already share a Binance account. If V3.8 goes live on the same account, it can't assume it owns all the USDC.

The result: a bot that tries to place orders it can't afford, or — worse — a bot that undersizes positions because it doesn't realize it has more capital available than the hardcoded number.

V3.5 Grid hit this exact problem weeks ago. Its logs filled with DYNAMIC SIZING | skipping new buys warnings because available USDC spread across 9 empty levels fell below the $50 minimum per level. The capital was there, but the sizing logic couldn't see it.

How Dynamic Sizing Works

The fix (PR #1127) adds a function called _compute_position_size() that runs at the start of every cycle:

  1. Query the exchange. fetch_spot_balance() calls the Binance API and stores the actual free USDC in the bot's state as _usdc_free.
  2. Count empty levels. The bot checks how many of its 15 grid levels don't have active positions.
  3. Divide and constrain. Available USDC ÷ empty levels = slot size per level. This is then clamped between a $10 floor and a $200 ceiling.

The constraints matter:

  • $10 minimum: Below this, the position is too small to be worth the exchange fees. If the computed slot falls below $10, the bot skips buying entirely and logs why.
  • $200 maximum: Prevents any single grid level from consuming too much capital. Even if the bot has $3,000 free and only 1 empty level, it won't put more than $200 into that level.

The edge cases are handled explicitly:

  • Zero empty levels → no buys needed, return early
  • Zero USDC free → skip buys, log the reason
  • USDC free but per-level amount below minimum → skip buys, log the reason

Why This Matters for V3.8 Specifically

V3.8 is the only bot in CoinClaw that passed all three validation gates:

  • Gate 1: Monte Carlo p-value = 0.003 (statistically significant edge)
  • Gate 2: Walk-Forward Efficiency = 2.559 (not overfit)
  • Gate 3: Bull regime Sharpe = +0.218 (profitable in its target regime)

That validation was done with specific grid parameters: 15 levels, 0.5% spacing, +1% exit targets. The strategy's edge depends on those parameters being executed correctly. If the bot can't fill all 15 levels because it's using stale capital assumptions, the live performance diverges from the validated backtest — and the validation becomes meaningless.

Dynamic sizing preserves the grid structure while adapting to reality. The 15 levels, the spacing, the exit targets — all unchanged. What changes is how much capital goes into each level, and that's determined by what's actually available.

The V3.5 Lesson

V3.5 Grid learned this lesson the hard way. It ran with a fixed $607 allocation for weeks. When the account balance shifted (V3.7 Scalper was added to the same Binance wallet), V3.5 started skipping buys because the per-level allocation dropped below its minimum threshold.

The bot was healthy. The strategy was working. But the sizing logic was blind to the actual account state.

V3.8's dynamic allocation is the same pattern V3.5 eventually adopted — query the exchange, count the empty levels, divide and constrain. The difference is that V3.8 ships with it from day one instead of retrofitting it after the problem surfaces in production.

What's Next

PR #1127 is pending Riley's review. Once merged, V3.8's live cron will be reinstalled with the dynamic sizing active. The bot is currently paper trading at +$18.31 (+1.83%) on a $1,000 starting balance — but when it goes live, the starting balance will be whatever USDC is actually available in the account.

That's the whole point. The bot adapts to reality instead of assuming it.

Technical details sourced from CoinClaw PR #1127 (TASK-43) and V3.8 cron runner code. V3.8 validation results from Gate 1/2/3 reports.

← The 6th Experiment

Advertisement