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 setinvestment_per_buyto$50. Why is the bot buying$30and$20chunks instead?”
“I seeSame 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.60 ADAtraded. At$0.25per ADA, that’s only$15— but my slot is$50. The bot under-bought. Is this a bug?”
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.
- First buy: loads all 7 tiers at once →
$50total. - Tiers sell as price rises (one at a time, at their respective targets).
- Re-buys happen when price drops back: each re-buy refills only the tiers that previously sold, not the entire slot.
- A re-buy of
$7.14= 1 tier was empty. A re-buy of$15= 2 tiers were empty. A re-buy of$50would only happen if the entire position had closed first.
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 beDecoded:$15buy and$15.xxsell. You still have the other tiers — e.g., if you have a1%TP and another2%TP and the bot only manages to sell at1%and price drops, it only refills the1%tier. That’s how the bot ‘buys less.’”
Step 1 — what the operator saw
Step 1 — what the operator saw
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.”Step 2 — what was actually happening
Step 2 — what was actually happening
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 $15corresponds to roughly 2 tiers worth- The bot refilled 2 tiers because 2 tiers had been empty
Step 3 — the matching sell
Step 3 — the matching sell
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:- 2 tiers sold at their targets →
~$15.30cash returned. - Price reverted → 2 tiers refilled at
~$15.00. - Net captured profit:
~$0.20-$0.30minus fees. Tiny, but it adds up over many cycles per day per pair.
Step 4 — Felix's '1% sells, 2% doesn't' explanation
Step 4 — Felix's '1% sells, 2% doesn't' explanation
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.
The math, one more time
For Mode 4 withinvestment_per_buy = $50:
| Tiers empty when refill triggers | Approx. refill buy size | Operator’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” |
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”:DCA / averaging-down step
DCA / averaging-down step
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.Partial fill on the exchange
Partial fill on the exchange
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.
Mode-specific weighted tiers (not 1/N)
Mode-specific weighted tiers (not 1/N)
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.Quote-asset rounding
Quote-asset rounding
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.MarketMaker mode active
MarketMaker mode active
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: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.
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.
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
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 buy | investment_per_buy is the slot size — the maximum capital one pair occupies when fully loaded |
| Each buy is independent | Each buy refills a specific tier within an existing position structure |
| Small buys = bot under-performing | Small buys = healthy tier rotation; this is what profitable operation looks like |
| The bot decides buy sizes ad-hoc | The bot decides buy sizes deterministically based on tier state |
If buy ≠ investment_per_buy, something is off | If buy ≠ tier_size × N for any N, something might be off — otherwise it’s normal |
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 = $15corresponds 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.