When Your Balance Shrinks, So Should Your Bets

The Number That Doesn't Move When Everything Else Does

I'm staring at a config value that was true last week and is a quiet lie this week. It's the maximum size, in dollars, that the bot is allowed to put into a single arbitrage attempt. I picked the number when the wallet had a certain balance. The wallet does not have that balance anymore. The number has not changed.

This is the part of bot building nobody warns you about. The hard problems — chasing opportunities, parsing on-chain data, surviving fee math — get all the attention. Meanwhile a hard-coded integer sitting in a config file is busy redefining what "risk per trade" actually means, every time the wallet moves up or down. A single static number is making a different promise to me every day, and I am the one who has to keep up with the lie.

So I'm pulling that number out of the config and replacing it with a function. That function is the topic of this entry: a dynamic trade cap that scales with the wallet, instead of a fixed amount that doesn't.

Why Fixed Dollar Caps Are a Slow-Motion Blow-Up

The instinct to set a fixed dollar limit is an honest one. It feels conservative. "I'll only ever risk up to X per trade" sounds like discipline. The catch is in the word "up to." Up to what? Up to a number you set on a Tuesday with a balance you no longer have.

Mahmoud Ali, in a Medium essay on institutional bot design, puts the asset-side version of this bluntly: "trading fixed lots on different assets is financial suicide". His point is about volatility — Bitcoin and the Euro are not the same animal — but the same logic applies on the time axis. Your wallet today and your wallet next month are not the same animal either. A fixed dollar amount is a pretend constant in a world where nothing else is constant.

The specific failure mode shows up the moment you take a few losses. AlgoBot.com walks through the arithmetic in a way that's hard to forget: start with a $2,000 account, decide your max trade is $200, lose five trades, and now your account is $1,000 while your bot is still cheerfully sending $200 per attempt. That same fixed amount is now twenty percent of your remaining capital instead of ten. Your stated risk policy didn't change. Your actual risk doubled, silently, because the denominator moved and the numerator didn't.

Coin Bureau frames the downstream consequence in plain language: "Risking 10–20% of your account on one trade means a short losing streak can do lasting damage". And the damage compounds in an asymmetric, unforgiving way. A run of five ten-percent losses takes the account down by roughly forty-one percent, per the same Coin Bureau guide. To climb back to break-even from there, the account has to deliver about a sixty-nine percent return. That's not a slump. That's a different career.

Fixed caps fail you in the other direction too, just less painfully. If the wallet grows, a fixed cap leaves money parked. Flipster's primer on position sizing notes that the fixed dollar approach "doesn't scale well with growing capital" — every dollar the wallet adds is a dollar that doesn't get to participate. The ceiling you set on a smaller balance becomes a tax on the bigger one.

Fixed caps, in short, are wrong on both ends. They risk too much when you've lost and risk too little when you've won. They're a thermostat that only reads the temperature on the day you installed it.

The Speed-Limit-Sign Problem

The American mental model that captures this best, for me, is highway speed limits versus the actual flow of traffic. The sign says 65. The road, depending on the time of day and the weather and the volume, supports something quite different. A driver who locks the cruise control at 65 in a downpour is being mechanical, not safe. The number on the sign was set by people who had no idea what kind of Tuesday afternoon you'd be driving in.

A fixed dollar trade cap is the cruise control. It was the right number for one specific day, and it is now a setting that does not respond to the road.

The alternative — a dynamic cap — is closer to how a careful driver actually behaves: the speed adapts to conditions. The cap, in the trading version, adapts to balance. If the wallet is smaller today than it was yesterday, the cap is smaller too. If the wallet is bigger, the cap is bigger. The percentage stays constant; the dollar amount floats.

How a Dynamic Cap Actually Works

Mechanically, this is the simplest part. A dynamic cap is not a fancy formula. It's a single multiplication, performed every time the bot evaluates a trade, against the current balance instead of a snapshot from the past.

AlgoBot.com's tutorial example is the cleanest illustration I've seen. Choose a percentage — say one percent. Deposit $2,000 into the exchange. Maximum trade size is $20. Then the wallet moves: "if your balance drops to $1,500 after losing trades, your maximum trade size is reduced to $15 (1% of $1,500). Conversely, if you're on a winning run and your balance reaches $4,000, your maximum stake size increases to $40 (1% of $4,000)".

Three things to notice about that example.

First, the percentage is the actual policy. The dollar amount is a derived quantity, recomputed on every read. There is no "max trade size" stored anywhere as a constant. There is only "max trade size at this moment, given this balance." Altrady puts it cleanly: "Dynamic position sizing means changing how much you trade based on the situation. In contrast, beginners often trade the same amount every time, like $100 per trade, but crypto's volatility makes this risky."

Second, the system self-corrects in both directions. Losing streaks shrink the cap automatically, which prevents the doubling-the-percentage failure described above. Winning streaks grow the cap automatically, which means upside isn't artificially fenced off. The asymmetry that crushes fixed-cap accounts disappears.

Third — and this is the part that sounds boring but is actually the whole point — the bot stops needing me to babysit it. There's no Sunday-evening ritual where I look at the wallet and adjust the config. The config no longer contains the dollar number. It contains the percentage. The percentage rarely needs to change. The dollar amount needs to change every time anything happens, and now it does.

What Percentage Is Reasonable

This is where I'm being deliberately careful, because the right percentage depends on the strategy, the win rate, the cost structure, and a dozen other things specific to a bot's situation. I'm not going to publish the number I use. But several sources converge on a sensible band, and that band is what I want to anchor the discussion in.

Blocsys's guide on building a crypto arbitrage bot states the range directly: "Your bot should never be allowed to allocate more than a fixed percentage of your capital to a single trade. A common limit is 2-5% of total capital per trade." That's the upper end of what gets called "common" in the algorithmic trading literature.

Cripton AI's bot risk management guide leans more conservative, recommending "never risk more than 1-2% of your total trading capital on any single trade" — a ten-thousand-dollar account translating to maybe one or two hundred dollars at risk. LuxAlgo's algo-trading material lands in the same neighborhood with a 2% risk rule. Altrady goes lower still for beginners, suggesting half a percent per trade until a strategy has earned the right to step up.

A pattern worth naming, even at the qualitative level: most serious sources put per-trade risk in single digits, and the cautious end of the band is well under that. A small percentage of the account, recomputed live, is the consensus posture. The reason that posture is the consensus is a piece of math worth its own section.

The Math That Made Me Take This Seriously

Here's where the dynamic-cap idea stopped being a style preference and started being a survival argument. BackTestBase's risk-of-ruin material lays it out: "Doubling your position size doesn't double your risk of ruin—it increases it exponentially."

The specific numbers from that source are sobering. At 2% risk per trade, the modeled risk of ruin sits at roughly 7%. Push that to 4% per trade — only doubling — and the ruin risk leaps to roughly 30%. The size went up by 2x. The danger went up more than 4x.

Applied to a fixed-cap bot, the implication is direct. A bot that started at, say, 2% effective risk and slowly drifts to 4% effective risk because the wallet shrank while the cap didn't is not slightly riskier. It's in a fundamentally different regime. The user thinks they're operating in the "7% chance of ruin" zone. They are actually operating in the "30%" zone. The slider moved without anyone touching it.

A dynamic cap is what keeps the slider where you put it. It doesn't make trading safe. It makes the safety setting honest. The percentage you chose is the percentage you're actually running at, every trade, regardless of what the wallet has done since.

Ira Cohen, Chief Data Scientist at Anodot, makes the broader version of this point in commentary cited by LuxAlgo: "Effective position sizing not only controls potential losses but also optimizes risk-adjusted returns, playing a pivotal role in the long-term success of any trading strategy." Position sizing isn't a side dish. It's the ingredient that decides whether a strategy compounds or evaporates.

The Kelly Tangent — Why Even "Optimal" Comes With a Cap

It's hard to write about position sizing without bumping into the Kelly Criterion. Kelly is the mathematically optimal fraction of bankroll to bet given a known edge — the highest long-run growth rate available to a strategy with positive expectancy. There's a formula. It works. And almost nobody uses it at full strength.

The LBank explainer on Kelly is clear about why: "Professional traders typically use between 10% and 25% of full Kelly". Half-Kelly, by their numbers, cuts volatility by about 25% while sacrificing only about 25% of the long-run growth rate. Quarter-Kelly cuts volatility roughly in half. The trade is excellent: give up a slice of theoretical growth to make the equity curve survivable.

LBank's hard ceiling: "Never risk more than 20% on a single position, regardless of what Kelly suggests." CoinMarketCap Academy independently lands on the same ceiling, calling it "unwise to risk more than 20% on a single position, bet or trade".

The takeaway for me isn't "implement Kelly." It's that even the framework that's literally designed to maximize growth tells you to throttle yourself well below what the math would naively suggest, especially in a market with fat tails like crypto. The dynamic cap concept is the operational version of that throttle. You can't do Kelly properly without a cap that scales with current bankroll, because Kelly's whole derivation assumes the bet size is a fraction of current capital, not a number you wrote down last month.

When the Cap Should Tighten Beyond the Percentage

The basic dynamic cap — fixed percentage of current balance — is the foundation. It is not the whole building. There are situations where the percentage itself should adapt.

Blockchain Council's 2026 guide to AI risk management lists several adjustments that production systems make on top of equity-based scaling. Volatility targeting reduces position size when the asset is moving more than usual. Correlation-aware limits reduce combined exposure when multiple positions start moving together. Liquidity-aware sizing caps trades according to actual order book depth, not theoretical capital. Their flash crash case study from March 2026 captures what this looks like in motion: "During a flash crash in March 2026, one arbitrage AI detected unusually high volatility and automatically reduced position sizes while increasing the profit threshold required for execution."

That's the difference between a static "don't trade more than X percent" and a system that knows when conditions have shifted underneath it. A cap can be smart about more than balance. But before any of that sophistication is worth building, the boring foundation has to be in place: the cap needs to track the wallet, period.

There's also the kill-switch layer above per-trade caps. Blocsys describes it as a hard rule: "If the bot's net losses for the day hit a predefined amount (e.g., 2% of total capital), it must automatically shut down all new trading." A per-trade cap protects the next trade. A daily-loss cap protects the next day. They're different defenses for different failure modes, and a serious bot eventually wants both. For now, I'm focused on the per-trade layer, because nothing else matters if a single trade can sink the account.

The Failure That Crypto.com's Doc Quietly Confirms

One small detail from the Crypto.com arbitrage bot help page stuck with me. If the bot tries to place an order and the order is rejected for insufficient balance or for breaching a position limit, the bot doesn't retry, doesn't shrink the order, doesn't gracefully degrade. It terminates.

That's the production-grade venue saying: if your sizing is wrong, we don't fix it for you, we shut you down. Which is the exchange's polite way of telling bot operators that the responsibility for keeping trade sizes in line with current balance lives entirely on the client side. The exchange enforces a hard rejection. The bot author is supposed to make sure that rejection never happens.

A fixed dollar cap, applied to a wallet that's been bleeding, is exactly the configuration that triggers those rejections. A dynamic cap, applied to the same wallet, doesn't, because the cap moved with the balance and never tried to send an order the wallet couldn't cover.

What I'm Actually Putting Into the Code

I'm going to keep the specifics private — the exact percentage I'm using, the exact way the cap interacts with the rest of the risk stack, the precise thresholds where extra brakes kick in. Those numbers are tuned to my situation, and a different operator with a different strategy would land somewhere different.

What I will say about the design is the part that generalizes:

The dollar amount is no longer stored. It is computed. Every time the bot considers a trade, it reads the current wallet balance and multiplies by the percentage policy. That product is the cap for that single decision. The next decision, milliseconds later, may use a slightly different cap because the balance moved. That's the feature, not a bug.

The percentage I chose sits in the conservative band described above — closer to the floor than the ceiling. The reasoning is that arbitrage opportunities, in the current environment, are small. The research notes I gathered for this entry put typical opportunities somewhere between a tenth of a percent and two percent, with round-trip fees eating roughly four-tenths of a percent. The math doesn't reward swinging hard. It rewards swinging often, with size that survives the misses.

There is a floor. Below a certain wallet balance, the percentage-derived cap would shrink to a number too small to clear fees. At that point, the right behavior isn't to send tiny doomed trades — it's to stop. A dynamic cap that includes a hard floor effectively converts a wallet drawdown into an automatic pause, which is exactly the kind of intervention I want when things are going badly.

What This Changes in the Day-to-Day

Before this change, every meaningful move in the wallet created a tiny obligation to update the config. I rarely actually did it. The number drifted out of meaning, and I drifted along with it.

After this change, the config contains a percentage and a few guardrails. The dollar amount the bot uses today is whatever the math says today. There is nothing to remember to update, because there is nothing static left to update. The cap is no longer a thing I set; it is a thing the bot derives, on demand, from the only piece of state that actually matters — what the wallet currently holds.

It feels like a small change. It is, in lines of code. The reason I'm spending an entire entry on it is that the category of change is large. Replacing a static parameter with a live computation is a pattern that shows up everywhere in bot work, and most of the patches-on-patches problems in this project trace back to versions of me deciding that some quantity was "basically constant" when it wasn't.

The wallet balance is the most obvious moving target in the system. It deserves a sizing rule that moves with it.

Key Takeaways

• A fixed dollar trade cap silently lies about your risk: when the wallet shrinks, the same cap becomes a larger percentage of capital, pushing you into a riskier regime without any policy change.
• The compounding asymmetry of losses is brutal — a five-loss streak at 10% per trade leaves the account down roughly 41%, requiring about a 69% return to recover (Coin Bureau).
• Risk of ruin grows non-linearly with position size: doubling per-trade size from 2% to 4% multiplies modeled ruin risk from roughly 7% to roughly 30% (BackTestBase).
• A dynamic cap stores a percentage, not a dollar amount, and recomputes the dollar limit live against current balance — exactly the mechanism AlgoBot.com illustrates with the $2,000 → $20, $1,500 → $15 example.
• Even Kelly, the formal optimum, gets throttled in practice: professional traders typically use 10–25% of full Kelly, and a 20% per-position ceiling is repeatedly cited as the hard cap regardless of what the formula suggests.
• The dynamic cap is the operational baseline. Volatility, correlation, and liquidity adjustments — and a daily-loss kill switch — are layers built on top of that foundation, not substitutes for it.