Parameters Overview — Every Configurable Setting

Complete reference for every parameter you can configure on the TradingBot. Trading pair, activation, investment, buy logic, sell logic, risk management — every knob explained.

Every parameter below can be edited from the Dashboard or via the SignalsBot’s webhook API. Each parameter has a default value, a clear effect, and operator-relevant guidance. Use this page as your reference when configuring a mode, debugging unexpected behavior, or tuning an existing setup.

How parameters fit together

Parameters live at three levels in unCoded:

1. Trading pair level — base asset, quote asset, which mode is assigned.
2. Mode level — the strategy preset (BasicMode, FullBullMarket, etc.) that defines investment, buy, sell, and risk parameters.
3. Operator-tunable level — every parameter on a mode can be edited per pair, allowing you to deviate from default mode behavior for specific symbols.

The Dashboard’s Modes panel exposes all of these. Pre-built modes have validated defaults; you tune deliberately when you have a specific reason.

Never edit parameters mid-trade unless you understand in-flight position behavior. Open positions continue under the rules they were opened with — sell ladders are already on the exchange. Parameter edits affect new positions opened after the change.

---

1. Trading pair and mode

Base asset

The base asset of the trading pair — the currency being bought and sold. Example: PEPE, ETH, BTC.

Order quantities are denominated in base asset units. When the bot reports “bought 0.0149 BTC,” that’s the base-asset quantity.

Quote asset

The quote asset of the trading pair — the currency used to pay for buys and receive from sells. Example: USDC, USDT, FDUSD.

Using USDC at sufficient volume can unlock Binance VIP1 status. FDUSD is required for the MarketMaker modes (1001/1002). Most operators use USDT as the standard quote.

Mode

The trading strategy preset. Each mode applies a different pre-configured combination of trading parameters suited for different market conditions.

Default: 4 (BasicMode).

Mode 4 is a reliable balanced starting point for most users. See Modes Overview for all 9 pre-built modes and when to choose each.

---

2. Activation

`active`

Must be set to true for the bot to start trading. This confirms you have accepted the Terms of Service.

If set to false, the bot will not place any orders.

You can set this via:

• Telegram → /start → Configurations
• Setup Wizard at first launch
• Dashboard’s Modes panel

Default: false (must be explicitly activated).

`canBuy` (mode-level)

Top-level enable/disable for buying on this mode. Set to false to pause all buy activity without changing other settings.

Useful for winding down a pair: set canBuy: false and the bot will not open new positions, but existing positions continue to be managed by the sell ladder.

Default: true.

`canSell` (mode-level)

Top-level enable/disable for selling on this mode. Set to false to pause all sell activity.

Rare to use — you typically want sells active even if buys are paused, so existing positions can close. Use canSell: false only if you specifically want to take delivery of an asset rather than rotate it.

Default: true.

---

3. Basic info

`name`

Name of the mode. Use a descriptive label to identify this configuration at a glance.

Examples: BasicMode, FullBullMarket, LowMoney. For custom modes derived from a default: BasicMode-BTCUSDT-tighter-stops.

Visible in the Dashboard’s mode selector and in trade-close notifications.

`description`

Short description of the mode. Helps you remember the intent and strategy of this configuration.

Examples: 7-split mean-reversion grid, trend-follower with armed trailing stop, experimental tighter stops for volatile altcoins.

Visible in the Dashboard’s Modes panel when expanded.

---

4. Investment settings

`investmentPerBuy`

Amount (in quote currency) invested on each buy.

Default: 20.

Worked example: with investmentPerBuy: 20 and buySplits: 7, each buy split places a $20 order. Full ladder filled = $140 deployed. With buyVolumes: [25,20,15,15,10,10,5], the splits are weighted (a $20 base × weight%) per split.

Operator guidance: pre-built modes set this to match their recommended capital. Edit only with deliberate reason.

`dontBuyBelowQuoteAssetBalance`

Prevents buys if your quote balance falls below this value. Use this to maintain a minimum reserve in your account.

Example: dontBuyBelowQuoteAssetBalance: 100 means the bot will not place a buy if your USDT balance would drop below $100 after the buy.

Operator guidance: useful for maintaining operational headroom (fees, exchange-side reserves) and as a soft floor against fully-deploying capital during sustained drawdowns.

`investmentPercentMode`

Toggle that enables percentage-based investing instead of fixed amounts.

When enabled (true), the bot uses investmentPercentOfFreeQuote rather than investmentPerBuy to size each order.

Default: false (fixed-amount mode).

Use case: if your capital varies (e.g., reinvesting profits), percentage mode auto-scales orders with your account size. Fixed mode is more predictable for steady-state operation.

`investmentPercentOfFreeQuote`

Percentage of your available quote balance used per buy. Only active when investmentPercentMode is enabled.

Example: with investmentPercentOfFreeQuote: 5 and a $10,000 USDT balance, each buy is $500 (5% of free quote).

Operator guidance: typical values 2–10% per split. Higher values deploy capital faster; lower values stretch capital across more cycles.

`minInvestmentPerQuote`

Minimum required quote balance for an investment to be placed. The bot skips a buy if available balance is below this threshold.

Distinct from dontBuyBelowQuoteAssetBalance — this is a per-order minimum, not a balance floor.

Operator guidance: typically set above the exchange’s MIN_NOTIONAL (Binance: $10) so the bot pre-filters orders that would be rejected.

---

5. Buy configurations

`canBuy`

Enables or disables buying entirely. Set to false to pause all buy activity without changing other settings.

Existing sell ladders on open positions continue to honor.

Default: true.

Often used by SignalEditor strategies that gate buying based on conditions: the strategy flips canBuy to true when conditions hold, false when they don’t.

`canBuyUp`

Allows buys when the price moves up. Enable this to let the bot enter positions during upward price movements.

Default: depends on mode. Trend-following modes (FullBullMarket) typically have canBuyUp: true. Pure mean-reversion modes (BasicMode) typically don’t focus on up-moves.

Use case: enable for trend-following strategies that want to ride momentum; disable for pure mean-reversion that buys only on dips.

`canBuyDown`

Allows buys when the price moves down. Enable this to let the bot buy into dips.

Default: typically true for mean-reversion modes (BasicMode, LowMoney, MinimalMoney).

Use case: foundation of grid-trading and DCA-style strategies. Buys progressively scale into positions as price falls.

`onlyMakerBuy`

Places buy orders as maker orders only. Maker orders are added to the order book instead of executing immediately, which means they add liquidity to the market and may qualify for lower fees on Binance.

Default: true for most pre-built modes.

Trade-off: maker-only buys can sit unfilled if price moves before the order is matched. Taker buys (onlyMakerBuy: false) execute immediately but pay higher fees.

Operator guidance: keep maker-only enabled unless you specifically need fast execution.

`buyPercentage`

Percentage price move required to trigger a buy.

Default: 0.1.

Lower values increase buy frequency; higher values reduce it.

Worked example: with buyPercentage: 0.1, the bot triggers a buy when price has moved by 0.1% from the reference. With buyPercentage: 0.5, the bot triggers only on 0.5% moves — fewer but larger triggers.

`buySplits`

Number of split buy orders placed per trigger. Splitting buys distributes your entry across multiple price levels.

Default: 7 for BasicMode (the canonical 7-split grid).

Trade-off: more splits = more granular entry, but also smaller per-split sizing (must clear MIN_NOTIONAL). Fewer splits = larger per-split orders.

Operator guidance:

• High capital (>$15,000): 7 splits work well (BasicMode default).
• Medium capital ($5,000–$15,000): 5 splits often more efficient.
• Low capital (<$5,000): 3–4 splits keep per-order sizing above MIN_NOTIONAL.

`buyVolumes`

Comma-separated volume weights for each split buy order.

Example: 25,20,15,15,10,10,5.

Values represent relative weight, not absolute amounts. The bot normalizes to total 100 and applies each weight to investmentPerBuy (or percentage-based equivalent).

Worked example: with investmentPerBuy: 100 and buyVolumes: [25,20,15,15,10,10,5]:

• Split 1: $25
• Split 2: $20
• Split 3: $15
• Split 4: $15
• Split 5: $10
• Split 6: $10
• Split 7: $5

Front-loaded weights (more on early splits) commit more capital at first dip levels. Back-loaded weights wait for deeper dips before committing big size.

`buyVolumesType`

Defines how buy volume is distributed across splits. Controls the weighting strategy applied to buyVolumes.

Common values:

• static: use buyVolumes literally as weights.
• linear: distribute evenly.
• exponential: increasing/decreasing exponential distribution.

Operator guidance: pre-built modes set this; only edit if you have a specific weighting strategy in mind.

---

6. Sell configurations

`canSell`

Enables or disables selling entirely. Set to false to pause all sell activity.

Default: true.

Rarely set to false — most operators want sells active even when buys are paused so existing positions can close.

`onlyMakerSell`

Places sell orders as maker orders only. Like maker buys, these orders are added to the order book rather than executing immediately.

Default: true for most pre-built modes.

Trade-off: maker-only sells benefit from lower fees but may sit unfilled. Aggressive sells (onlyMakerSell: false) cross the spread and execute immediately at higher fees.

Operator guidance: keep maker-only enabled. The pre-built modes’ sell-ladder design assumes maker fills.

`sellPercentages`

Comma-separated percentage levels at which the bot places sell orders.

Example: 0.25,0.5,0.75,1,1.5.

Each value corresponds to a split from buySplits — the bot places one sell rung per buy split.

Default for BasicMode: [0.25, 0.35, 0.5, 0.75, 1, 2.5, 5] (7 rungs, narrow-to-wide).

Worked example: with entry at $70,000 and sellPercentages: [0.25, 0.5, 1, 2, 3, 4, 5]:

• Rung 1: sell at $70,175 (+0.25%)
• Rung 2: sell at $70,350 (+0.5%)
• Rung 3: sell at $70,700 (+1%)
• Rung 4: sell at $71,400 (+2%)
• Rung 5: sell at $72,100 (+3%)
• Rung 6: sell at $72,800 (+4%)
• Rung 7: sell at $73,500 (+5%)

Operator guidance: tighter rungs (more frequent small profits) work in chop. Wider rungs (fewer larger profits) work in trends. Don’t change without backtesting.

`showSellLevels`

Displays the configured take profit levels in the dashboard. Useful for reviewing your sell targets at a glance.

Default: true.

Has no effect on trading behavior — purely a UI display flag.

`trailingStopLossPercentages`

Adjusts the stop loss upward as price moves in your favor. Locks in gains while limiting downside as the position profits.

Comma-separated percentages, one per split.

Default for BasicMode: [0,0,0,0,0,0,0] (all zeros — no trailing stop, sell-ladder-only exits).

Default for Tsl2Sell: non-zero values that arm trailing stops on profit.

Operator guidance:

• All zeros = no trailing stop (predictable mechanical exits).
• Non-zero values = trailing stop arms when position reaches that profit level. Trailing stop tracks new highs and exits on retracement.

Caveat: trailing stops are locally re-priced. During bot downtime, the trailing reference doesn’t advance with new highs.

`sellTimeCurves` (EXPERT MODE)

Controls selling behavior over time. Allows you to define time-based sell conditions per split rather than relying on a single fixed condition.

For example, you can configure the bot to sell more aggressively if a position has been open for an extended period.

This is an expert-level feature — start with standard sellPercentages before experimenting with time curves.

Use case: prevents positions from being held indefinitely waiting for the full sell ladder. Useful for instruments where stale positions are a liability.

Operator guidance: most operators don’t use this. The pre-built modes’ fixed sell ladders are sufficient.

`sellTimeCurveCheckIntervalMs`

Sets how often (in seconds) the time curve conditions are evaluated. Only relevant when sellTimeCurves is configured.

Typical values: 60000 (every minute) for slower instruments; lower for faster ones.

Lower interval = more frequent evaluation = more CPU. Higher interval = less precise time-curve enforcement.

`sellActivateDistancePercentage`

The percentage recovery from a dip required before sell orders become active.

Default: 0.1.

Lower values activate sells sooner after a dip; higher values require a stronger recovery signal before orders are placed.

Worked example: with sellActivateDistancePercentage: 0.5, the bot waits for price to recover 0.5% from the most recent low before placing sell-ladder rungs. This prevents fragile sell-ladders that get cancelled during continued dipping.

`sellCancelDistancePercentage`

The percentage drop at which active sell orders are visually removed from the interface but remain active in the background.

Default: 1.

Higher values give deeper dips more room before orders are cancelled.

Note: this is a UI display threshold, not an order-cancellation threshold. Sell orders themselves remain on the exchange book until filled or operator-cancelled.

On sell time curves: time curves let the bot adjust sell behavior over time for each split instead of relying on one fixed sell condition. For example, you can configure the bot to sell more aggressively if a position has been open for an extended period. This is an expert-level feature — start with standard sellPercentages before experimenting with time curves.

---

7. Risk management

`stopLoss`

Toggle that enables a stop loss to limit downside risk. When enabled, the bot will close a position if the price drops by stopLossPercentage.

Default: true for most pre-built modes.

Operator guidance: keep enabled. Disabling stop-loss removes the worst-case bound on per-trade outcome — a position with deep drawdown has no automatic exit.

`stopLossPercentage`

Defines how far the price may drop (as a percentage) before the stop loss triggers. Only active when stopLoss is enabled.

Typical defaults: -15% to -25% from average entry, mode-specific.

Operator guidance:

• Tighter stop-loss (-10% to -15%) = more frequent stop-outs (small losses) but smaller worst-case per-trade loss.
• Looser stop-loss (-25% to -30%) = fewer stop-outs but larger worst-case per-trade loss.
• Defaults are calibrated for typical regime behavior. Tighten only with backtest evidence.

Caveat: stop-loss bounds the trigger level, not the actual fill price. Slippage during fast moves means realized loss can exceed stopLossPercentage.

---

Parameter interaction patterns

Capital-aware sizing — relating splits, volumes, and balance

The trio that determines per-order sizing:

• investmentPerBuy (or percentage-based equivalent): base size.
• buySplits: how many orders.
• buyVolumes: how the base size is weighted across splits.

Worked example: $20,000 capital, investmentPerBuy: 20, buySplits: 7, buyVolumes: [25,20,15,15,10,10,5]:

• Each “split” is $20 × weight%.
• Total for full ladder: $140 ($20 × 7).
• Per-cycle deployment: ~0.7% of capital — leaves room for many cycles before exhausting balance.

Sell ladder — relating splits and percentages

buySplits and sellPercentages must have matching lengths. Each buy split has a corresponding sell rung.

With buySplits: 7 and sellPercentages: [0.25, 0.5, 1, 2, 3, 4, 5], each filled buy maps to one sell rung at the corresponding percentage above entry.

If lengths don’t match, the SignalsBot rejects the configuration with a validation error.

Trailing stop — relating to sell ladder

trailingStopLossPercentages is per-split, like sellPercentages.

All-zeros trailing-stop values mean “no trailing stop, use sell ladder only” (BasicMode pattern).

Non-zero values mean “trailing stop activates when this split’s profit threshold is reached, then tracks new highs and exits on retracement” (FullBullMarket / Tsl2Sell pattern).

Activation chain — `active` + `canBuy` + `canSell`

For the bot to actually trade:

1. active: true (bot is ToS-accepted and operating)
2. canBuy: true (mode is allowed to buy)
3. canBuyUp: true and/or canBuyDown: true (direction-specific)
4. Mode’s buy conditions trigger (price move, indicators, etc.)

For sell:

1. active: true
2. canSell: true
3. Sell ladder placed (after a buy fill)
4. Price reaches a sell rung

Any one of these flipped to false halts the corresponding action.

---

Editing parameters in production

1. Backtest the change first

   Especially for sell percentages, buy splits, or stop-loss values. Even small parameter changes can substantially alter equity-curve character.

2. Engage kill switch (optional but recommended)

   For non-trivial parameter changes, flip the kill switch first. New buys pause; existing positions continue managing under previous rules. Reduces variability while you make changes.

3. Edit via the Dashboard's Modes panel

   Verify the configuration looks correct after editing. Mistakes here propagate to live trading on the next configuration poll.

4. Wait for in-flight positions to close (or close manually)

   Already-open positions continue under the rules they were opened with. New positions opened after the change use the new parameters. For a clean cutover, wait for existing positions to close.

5. Disable kill switch and observe

   Watch the Dashboard’s Logs panel and Live Trades panel for the first hour after a parameter change. Most issues surface within that window.

6. Document the change in your operator runbook

   What you changed, why, what you observed. Future-you needs the context.

---

Common parameter mistakes

❌ Mismatched `buySplits` and `sellPercentages` lengths

The two arrays must have the same length. If buySplits: 7 then sellPercentages must have 7 values.

Symptom: SignalsBot rejects the config with a validation error referencing array length mismatch.

Fix: align the lengths. Both should match buyVolumes length too.

❌ Per-split sizing below `MIN_NOTIONAL`

With low capital and high split count, per-split orders can fall below the exchange’s minimum (Binance: typically $10).

Symptom: bot logs MIN_NOTIONAL rejections; orders are skipped.

Fix: increase investmentPerBuy, decrease buySplits, or switch to a low-capital-tuned mode (LowMoney, MinimalMoney).

❌ Disabling `stopLoss`

“I want to ride through any drawdown” → disabled stop-loss → position goes deeply underwater with no automatic exit.

Reality: not all drawdowns recover. Tail-risk events do happen.

Fix: keep stopLoss: true. If you want a different threshold, edit stopLossPercentage, don’t disable.

❌ Editing parameters mid-trade without understanding in-flight behavior

Open positions continue under previous rules; sell ladders are already on the exchange.

Symptom: confusion when expected new behavior doesn’t apply to existing positions.

Fix: wait for in-flight positions to close (or close manually), then make the change.

❌ Setting `buyPercentage` too low

buyPercentage: 0.01 triggers buys on tiny moves — leads to over-trading, fees dominate.

Fix: stay near defaults (0.1 for BasicMode-style modes). Adjust based on backtest evidence, not gut.

❌ Switching `investmentPercentMode` without updating values

Toggling from fixed to percentage mode without setting investmentPercentOfFreeQuote to a sensible value can produce unexpected order sizes.

Fix: set both investmentPercentMode AND investmentPercentOfFreeQuote together.

❌ Configuring `sellTimeCurves` as a beginner

Time curves are an expert feature. Configuring them without understanding sell-curve dynamics can produce strange sell behavior.

Fix: master standard sellPercentages first. Only experiment with time curves after multi-month operation.

---

Worked configuration examples

BasicMode default — for `BTCUSDT` at `$20,000` capital

{
  "name": "BasicMode",
  "description": "7-split mean-reversion grid",
  "active": true,
  "canBuy": true,
  "canBuyDown": true,
  "canBuyUp": false,
  "onlyMakerBuy": true,
  "buyPercentage": 0.1,
  "buySplits": 7,
  "buyVolumes": [25, 20, 15, 15, 10, 10, 5],
  "investmentPerBuy": 20,
  "minInvestmentPerQuote": 15,
  "canSell": true,
  "onlyMakerSell": true,
  "sellPercentages": [0.25, 0.35, 0.5, 0.75, 1, 2.5, 5],
  "trailingStopLossPercentages": [0, 0, 0, 0, 0, 0, 0],
  "sellActivateDistancePercentage": 0.1,
  "sellCancelDistancePercentage": 1,
  "stopLoss": true,
  "stopLossPercentage": 25
}

Front-loaded buy weights (more on early splits) commit capital at first dip levels. Sell ladder narrow-to-wide for chop-friendly behavior. No trailing stop. Hard -25% stop-loss as worst-case bound.

LowMoney variant — for `$3,000` capital on smaller pair

{
  "name": "LowMoney",
  "description": "Adapted for $3,000–$5,000 capital",
  "active": true,
  "canBuy": true,
  "canBuyDown": true,
  "onlyMakerBuy": true,
  "buyPercentage": 0.1,
  "buySplits": 4,
  "buyVolumes": [40, 30, 20, 10],
  "investmentPerBuy": 12,
  "minInvestmentPerQuote": 10,
  "canSell": true,
  "onlyMakerSell": true,
  "sellPercentages": [0.5, 1, 2, 4],
  "trailingStopLossPercentages": [0, 0, 0, 0],
  "stopLoss": true,
  "stopLossPercentage": 20
}

Fewer splits (4 vs 7) keep per-split sizing above MIN_NOTIONAL at lower capital. Tighter sell ladder to capture meaningful per-trade P&L at smaller scale.

FullBullMarket variant — trend-follower with trailing stop

{
  "name": "FullBullMarket",
  "description": "Trend-follower with armed trailing stop",
  "active": true,
  "canBuy": true,
  "canBuyDown": true,
  "canBuyUp": true,
  "onlyMakerBuy": true,
  "buyPercentage": 0.2,
  "buySplits": 5,
  "buyVolumes": [30, 25, 20, 15, 10],
  "investmentPerBuy": 30,
  "canSell": true,
  "onlyMakerSell": true,
  "sellPercentages": [1, 2, 3, 5, 8],
  "trailingStopLossPercentages": [0.5, 0.75, 1, 1.5, 2],
  "stopLoss": true,
  "stopLossPercentage": 20
}

Wider sell rungs (+1% to +8%) capture larger trend moves. Trailing stops arm progressively (tighter on early splits, wider on later splits) to protect profit while letting the position ride.

MarketMaker variant — FDUSD-only on Binance

{
  "name": "MarketMaker",
  "description": "FDUSD-only maker-rebate strategy",
  "active": true,
  "canBuy": true,
  "canBuyDown": true,
  "canBuyUp": true,
  "onlyMakerBuy": true,
  "buyPercentage": 0.05,
  "buySplits": 3,
  "buyVolumes": [40, 35, 25],
  "investmentPerBuy": 50,
  "canSell": true,
  "onlyMakerSell": true,
  "sellPercentages": [0.1, 0.2, 0.3],
  "stopLoss": true,
  "stopLossPercentage": 15
}

Very tight sell rungs (+0.1% to +0.3%) — market-making profits from rebate plus minimal spread capture, not from directional moves. Maker-only on both sides is mandatory.

---

Best practices

• ✅ Start with pre-built mode defaults — don’t tune until you understand baseline behavior.
• ✅ Backtest every parameter change before applying live.
• ✅ Document changes in your operator runbook with reasoning.
• ✅ Match buySplits / sellPercentages / buyVolumes / trailingStopLossPercentages lengths — all must equal.
• ✅ Verify per-split sizing exceeds MIN_NOTIONAL — typical Binance floor is $10.
• ✅ Keep stopLoss: true — never disable, only tune stopLossPercentage.
• ✅ Edit during quiet hours — after open positions close, before market events.
• ✅ Engage kill switch during non-trivial edits — reduce variability.
• ✅ Watch logs for the first hour after any change — catches misconfigurations early.
• ✅ Don’t change sellTimeCurves until you’ve mastered standard sellPercentages — expert feature.
• ✅ Coordinate canBuy, canBuyUp, canBuyDown — flag interactions matter.
• ✅ Test on small capital before scaling — even validated changes can surprise you in live conditions.

---

What’s next

Modes Overview

The 9 pre-built mode profiles and when to use each.

BasicMode

The recommended starter — see how default parameters compose.

TradingBot

The execution engine that applies these parameters.

Dashboard

Where you edit parameters in the live system.

SignalsBot

The webhook gateway that accepts parameter updates from external sources.

Capital Allocation

How parameters interact with capital sizing decisions.

Backtesting

Validate parameter changes before live deployment.

Glossary

Definitions for every term used in parameter descriptions.