Which inputs does Scalping Timeframes use?

Direct answer

“Scalping timeframes” refers to using short chart time windows to manage entries, exits, and trade management. In practice, the approach uses a small set of inputs: (1) the chart timeframe(s), (2) rules that map timeframe information into decisions, (3) execution timing assumptions, (4) trading costs and friction assumptions, and (5) market-condition assumptions such as volatility and liquidity.

Because outcomes vary, these inputs should be separated into stable mechanics (what you do) versus variable conditions (what the market and your platform do). This separation is what you can independently verify.

Mechanism and definition: what inputs are actually used

1) Chart timeframe selection (the core input)

A “scalping timeframe” is an input that describes how much price history each decision looks at. Commonly, scalping uses short intervals (for example, minute-based charts) to react quickly to price changes. The specific timeframe is not the strategy by itself; it only defines the resolution of the information you observe.

Stable mechanic: you pick a timeframe (or set of timeframes) and then state how decisions are aligned to candle boundaries (for example, decisions are evaluated at bar close or at bar open).

2) Time rules: entry/exit scheduling

Short horizons require time-based rules, such as:

• When you are allowed to enter (e.g., only after a certain event on the chosen timeframe).
• When an exit is allowed (e.g., after a fixed number of bars, or when a condition is met).
• Whether trade management updates happen on each new bar, on every tick, or at a fixed cadence.

These are inputs because they control how frequently decisions are made and when information becomes available.

3) Execution timing and slippage assumptions

Even if your “signal logic” is defined, scalping timeframes implicitly assume that fills happen close to the intended price. Inputs here include:

• Whether you model execution at market, limit, or stop orders.
• Whether you assume minimal slippage or you explicitly budget for slippage.
• Whether your platform delivers pricing with enough speed for your intended timing.

Variable condition: real execution can differ from the backtest model, especially at short time horizons.

4) Trading costs and friction

Scalping timeframes depend on costs because profits (if any) are typically sensitive to:

• Spread (the difference between buy and sell).
• Commissions or fees.
• Financing or overnight treatment if positions extend beyond the intended holding window.

Stable mechanic: convert your approach into a measurable definition that includes cost assumptions.

Variable condition: costs and effective spread can change with liquidity.

5) Market-condition assumptions (liquidity and volatility)

To be checkable, you must state assumptions about the environment your timeframe logic expects:

• Volatility regimes (how much prices typically move during the holding period).
• Liquidity and depth (whether there are enough active buyers/sellers to support fills).
• Session behavior (whether trading occurs during typically more active hours versus quieter periods).

Material limitation: a timeframe choice that works under one volatility regime may degrade under another, because the “same” timeframe can produce very different price movement and fill quality.

Evidence or example: an independent way to list the inputs

Here is a checkable template for “inputs used” that does not require live prices:

1. Timeframe input: “I observe the primary chart on interval X, and I evaluate conditions at bar close.”
2. Decision cadence: “I update only when a new bar prints on interval X.”
3. Exit scheduling: “I exit if condition A is met, otherwise after N bars.”
4. Execution assumption: “I assume fills occur at the next-bar open (or I define a limit/stop fill model).”
5. Costs: “I include spread and fees in the calculation; I state the assumed cost level.”
6. Environment assumption: “I expect liquidity/volatility to be within a range; I test across different regimes.”

This example shows the dependencies: the “timeframe” input is only one part. The rest are the mechanical constraints and assumptions that determine whether the approach can be meaningfully evaluated.

Limitations and risks (material failure modes)

1) Backtest-to-live mismatch

Short horizons amplify modeling gaps. A common failure mode is that a backtest uses idealized fills (or fixed cost assumptions) while live execution experiences variable slippage and changing effective spreads.