Skip to main content

Documentation Index

Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt

Use this file to discover all available pages before exploring further.

The single most-asked support question in the first month of running unCoded. An operator sets investment_per_buy = $50, watches the first buy go in at exactly $50, and then sees a later buy on the same pair come in at $15 or $7. Their reaction is almost always “is something broken?” The answer is no — the bot is working exactly as designed. This page explains why, with the actual support-ticket example that prompted this doc to exist.

The question, as operators ask it

Real conversation patterns we see repeatedly in support:
“My slot size is $500. The first buy came in at $500, but the next one was only $120. Why?”
“I set investment_per_buy to $50. Why is the bot buying $30 and $20 chunks instead?”
“I see 60 ADA traded. At $0.25 per ADA, that’s only $15 — but my slot is $50. The bot under-bought. Is this a bug?”
Same question, different framings. The answer is the same in every case: the first buy is the only “full slot” buy. Every later buy on the same position refills tiers that previously sold — and the refill size matches the freed-up portion of the slot, not the slot itself.

The 30-second answer

A position is a tier stack, not a single block. In Mode 4 (BasicMode), investment_per_buy = $50 is split internally into 7 tiers of ~$7.14 each, each with its own sell target.
  1. First buy: loads all 7 tiers at once → $50 total.
  2. Tiers sell as price rises (one at a time, at their respective targets).
  3. Re-buys happen when price drops back: each re-buy refills only the tiers that previously sold, not the entire slot.
  4. A re-buy of $7.14 = 1 tier was empty. A re-buy of $15 = 2 tiers were empty. A re-buy of $50 would only happen if the entire position had closed first.
The bot is not “under-buying.” It’s filling the exact space that opened up. That’s the whole answer. The rest of this page walks through the math, the ADA case, and the misconceptions.

The canonical support-ticket example

The conversation that prompted this doc:
Operator: “60 ADA traded — but that’s not 60$ worth?” Senior operator: “Buy and sell here would be $15 buy and $15.xx sell. You still have the other tiers — e.g., if you have a 1% TP and another 2% TP and the bot only manages to sell at 1% and price drops, it only refills the 1% tier. That’s how the bot ‘buys less.’”
Decoded:
The operator’s bot traded 60 ADA. ADA’s price was around $0.25, so 60 × $0.25 = $15.Operator’s expectation: “My slot is configured for larger amounts. Each buy should be in that range.”Operator’s confusion: “The bot bought less than I configured. Something is off.”
The position on this ADA pair was already established. Some tiers had previously sold and been credited as cash. When the price dropped back, the bot refilled only those previously-sold tiers — not the entire slot.With investment_per_buy = $50 and Mode 4’s 7-tier stack:
  • Each tier ≈ $7.14
  • $15 corresponds to roughly 2 tiers worth
  • The bot refilled 2 tiers because 2 tiers had been empty
The other 5 tiers were still in the position, holding asset, waiting for their respective sell targets to be hit.
The senior operator pointed out: $15 buy and $15.xx sell.”The matching sell was ~$15.10–$15.30 — same 2 tiers’ worth, plus the small take-profit margin those tiers captured. This is the “tier rotation” cycle in action:
  1. 2 tiers sold at their targets → ~$15.30 cash returned.
  2. Price reverted → 2 tiers refilled at ~$15.00.
  3. Net captured profit: ~$0.20-$0.30 minus fees. Tiny, but it adds up over many cycles per day per pair.
The bot is profitable on this position. The operator’s instinct that “something is wrong because the buy is small” had the right concern but the wrong target — the small buy is the success signal, not the failure signal.
The senior operator’s analogy:
“If you have a 1% TP and another 2% TP, and the bot only manages to sell at 1% and price drops, it only refills the 1% tier.”
Translated to the tier-stack model:
  • “The 1%” = the tier with +1% take-profit target.
  • “The 2%” = the tier with +2% take-profit target.
  • Price moved enough for the +1% tier to fire but not the +2% tier.
  • Then price dropped → the +1% tier (and only it) refills.
  • The +2% tier is still loaded, still in the position, still waiting for +2% from the (new) average entry.
This is why the bot “buys less” on the refill. The remaining tiers were never empty.

The math, one more time

For Mode 4 with investment_per_buy = $50:
Tiers empty when refill triggersApprox. refill buy sizeOperator’s expected reaction
0 (all loaded)No buy fires(correct — nothing to refill)
1~$7.14”Why so small?” — because 1 tier opened up
2~$14.28”Why ~$15?” — because 2 tiers opened up
3~$21.42”Why ~$21?” — because 3 tiers opened up
4~$28.57”Why ~$29?” — because 4 tiers opened up
7 (all empty / position closed)New initial buy at $50”OK that matches”
Key insight: if you ever see a refill buy that doesn’t match tier_size × N for some N between 1 and 6, that is worth investigating. Buys at clean tier-multiples are the bot working correctly.

What else might explain a small buy

If the math above doesn’t fit, here are other (less common) causes for buy sizes that look “off”:
Some modes execute DCA buys when the price drops below the entry without any tiers having sold yet. These buys add capital to the position before the tier rotation game even begins.How to identify: No prior sells on this position; price is below the original entry; mode supports DCA.Buy size: Mode-specific — could be a fraction of investment_per_buy or a configured DCA step amount.
If the bot tried to buy a specific size but the exchange only filled part of the order (low liquidity at that price), the remaining quantity may post as a separate fill in the log.How to identify: Two fills with the same timestamp / order ID, totaling the expected size.Operator implication: Not a bot issue — exchange-side liquidity. Common on long-tail / illiquid pairs.
Some modes use uneven tier weighting, e.g., 30 / 30 / 28 / 12 for a $100 slot. Refilling the 12% tier alone produces a $12 buy; refilling the two 30% tiers gives $60.How to identify: Buy size doesn’t match slot / N cleanly but does match the mode’s weighting scheme.Operator implication: Read the mode’s documentation for tier weighting. Mode 4 uses uniform 1/7; not all modes do.
Exchanges round to specific tick sizes for both price and quantity. A $7.14 intended buy might fill as $7.13 or $7.15 depending on the exchange’s lot/tick size for that asset.How to identify: Buy size is within ~1% of the expected tier size.Operator implication: Rounding noise, not a bot problem.
If you’re running Mode 1001 or 1002 (MarketMaker / MarketMakerMinimal), the tier-stack model does not apply. Those modes use spread-based buys and produce many small, rapid trades by design.How to identify: Mode is 1001 or 1002. Pair is FDUSD-quoted. High-frequency small trades.Operator implication: Different mental model. See MarketMaker mode docs.

How to verify your bot is doing tier rotation correctly

Three checks, each takes 30 seconds:
1

Check the buy-sell size match

Find the suspicious small buy in your trade log. Look at the most recent sells on the same pair before this buy.
  • If the small buy size ≈ sum of recent sell sizes (within fees + a small TP margin) → tier rotation, working correctly.
  • If buy size has no matching prior sells → continue to step 2.
2

Check the position state in the dashboard

Open the dashboard’s positions view. Look at the pair in question.
  • Position state shows N/M tiers loaded (e.g., “5/7”). Multiply: (7 - 5) × tier_size = 2 × $7.14 = $14.28 — should match the recent buy size.
  • If position state shows fully loaded but you still see small buys → investigate further (state sync issue, possible bug — escalate).
  • If position state is consistent with the buy size → tier rotation, working correctly.
3

Check the bot's logs for the buy decision

The bot logs every buy decision with the reasoning — which tier(s) being refilled, what trigger fired, current price vs trigger price.
  • Logs explicitly mention tier(s) being refilled → working correctly.
  • Logs show DCA reasoning → averaging-down buy, expected if mode supports it.
  • Logs show neither tier nor DCA reasoning → escalate to support with the log line.

What to NOT do

  • Don’t stop the bot in panic over small buys. They are the most common buy type during normal operation.
  • Don’t manually close positions to “reset” the tier state. Tier state is internally tracked and recovers correctly across restarts.
  • Don’t change investment_per_buy in response to confusion about buy sizes. That changes your slot size, which has cascading capital-allocation implications. Fix the mental model instead.
  • Don’t compare buy sizes to indicator-driven bots’ behavior. Other platforms may treat each buy as an independent decision. unCoded treats the position as a structured ladder. Different model entirely.
  • Don’t assume “small buy = bot error.” The reverse is true: small buys are the bot’s main mode of operation in tight-grid strategies.

The mental shift, summarized

The whole confusion comes from one assumption that needs replacing:
Old assumption (wrong)Correct mental model
investment_per_buy is the size of every buyinvestment_per_buy is the slot size — the maximum capital one pair occupies when fully loaded
Each buy is independentEach buy refills a specific tier within an existing position structure
Small buys = bot under-performingSmall buys = healthy tier rotation; this is what profitable operation looks like
The bot decides buy sizes ad-hocThe bot decides buy sizes deterministically based on tier state
If buy ≠ investment_per_buy, something is offIf buy ≠ tier_size × N for any N, something might be off — otherwise it’s normal
Once you’ve replaced the old mental model, every trade in your log becomes interpretable. Until you do, the bot looks like it’s making arbitrary choices — and operator instinct will scream “broken” at every small buy. This is by far the highest-ROI mental adjustment new operators make. Most of the rest of operating unCoded follows from getting this one right.

TL;DR

  • First buy on a fresh pair = full investment_per_buy. This is the only buy of that size for the whole position lifecycle.
  • Subsequent buys refill tiers that previously sold. Buy size = tier_size × empty_tier_count.
  • 60 ADA at $0.25 = $15 corresponds to 2 tiers (out of 7) being refilled in Mode 4 — exactly the support-ticket example.
  • The matching sell that “freed up” those tiers was for ~$15.10–$15.30 — small profit captured per cycle.
  • Tiny buys are the success signal, not the failure signal. They mean the position is rotating profitably.
  • Verify with three checks: match buy size to recent sell size, check position state in dashboard, read bot logs for the buy reason.
  • Replace the assumption “every buy = investment_per_buy” with “every buy = empty tiers being refilled.” This single mental shift resolves 90% of “is this normal?” support questions.

What’s next

Buy Splits — full reference

Comprehensive deep-dive into the tier-stack mental model, all four buy types, capital math, and edge cases.

BasicMode (Mode 4)

The canonical 7-tier example mode used throughout this page.

Parameters Reference

Every parameter that affects tier behavior, with worked examples.

Common Issues

Other frequent operator questions and their answers.

Reading Backtest Results

Backtests show the same buy/sell pattern as live trading — useful for validating tier behavior before deploying.

Capital Allocation

Sizing investment_per_buy correctly in the first place.
Last modified on May 6, 2026