Pine Script Pyramiding: Entry Count vs Position Size

Three entries of two contracts make a six-contract position. That sounds too plain to need a manual, until the strategy has a pyramiding setting of three and somebody expects the total size to stop at three contracts.

Pyramiding controls how many entry trades a Pine strategy can accumulate in one direction through strategy.entry(). Order sizing controls how much each entry adds. Treating either setting as the other can produce a backtest with very different exposure from the one you intended.

This distinction matters in TradingView automation because an additional entry can become another execution instruction. AlgoWay's discussion of planned repeated entries versus duplicate deliveries explains why these events need to be distinguished. Before connecting a strategy, define whether a message means “add two” or “the desired total is six,” and verify that the receiving workflow uses the meaning you intended.

Count entries separately from contracts

The current Pine strategy documentation describes a default pyramiding value of 1: a strategy can open a position but cannot add to it through further same-direction strategy.entry() orders. The setting is also available in the strategy's Properties tab.

With a limit of 3, imagine three sequential market entries, each for two units. Assume each order fills before the next signal, no exit intervenes, and sufficient simulated capital is available. These are arithmetic examples, not recorded test results.

The fourth attempt cannot add another entry under those assumptions. Closing an entire entry trade can free a slot. Merely reducing an entry's quantity does not necessarily reduce the number of open entry trades. A count limit is therefore not a daily trade limit, a maximum contract count or a monetary risk budget.

Find the quantity that each call actually uses

TradingView's strategy properties reference distinguishes fixed quantity, cash amount and percentage-of-equity sizing. Fixed quantity asks for units; cash and equity settings calculate quantity from a monetary allocation. An allocation of 10% of equity is not the same as risking 10% of equity at the stop.

There is an important override: when strategy.entry() supplies a non-na qty argument, that value specifies contracts, shares, lots or units instead of using the strategy's default sizing settings. Changing the Properties order-size box may therefore leave those entries unchanged. Inspect the call that creates the order before blaming pyramiding.

If successive entries use different quantities, add their actual filled quantities. Do not multiply the first size by the pyramiding setting and assume that is the final position. Cash or equity sizing can produce different quantities as prices and equity change; explicit sizing logic can do the same.

The average entry moves, and so does the risk

For a simple position with two units filled at 100 and two more at 104, the weighted average entry is:

(2 × 100 + 2 × 104) / 4 = 102.

A third two-unit fill at 106 increases total size to six and moves the average to about 103.33. The average is a summary of fills, not evidence that all six units were bought there.

Suppose all six units share a stop at 98, and each one-unit price movement is worth $1 per unit. The gross loss at an exact stop fill would be 2 × (100 - 98) + 2 × (104 - 98) + 2 × (106 - 98) = $32, before fees or slippage. The first entry alone exposed $4 under the same assumptions. Adding entries multiplied exposure without changing the stop line.

Define the maximum total quantity and acceptable loss after each addition, including any existing positions the live account already holds. If the new entry exceeds those limits, an entry-count setting alone will not repair the sizing rule.

Two exceptions to the simple entry-count picture

strategy.order() does not obey the pyramiding property. It creates orders whose filled quantity changes the net position. A script that mixes it with strategy.entry() needs a separate review of those orders; setting pyramiding to 1 does not make every possible order path single-entry.

TradingView also documents an exception for multiple price-based entry orders created on the same tick. If their limit, stop or stop-limit conditions trigger, the emulator can fill them even when the resulting entry count exceeds the pyramiding limit. The sequential market-entry table above deliberately excludes that case. Inspect pending orders as well as currently open trades.

A reversal has a larger transaction than its final position

By default, an opposite-direction strategy.entry() reverses the existing position. If the strategy is long six units and requests a new short entry of two, the reversing sell transaction is eight units: six to close the long and two to establish the short. The final position is short two, not short eight. Direction restrictions can change this behavior.

That difference deserves particular care in alert messages. A transaction quantity, a new-entry quantity and a final position quantity are different numbers. Do not substitute one for another simply because all three are called “size” somewhere on a screen.

For a controlled automation check, follow one initial entry, one addition and one exit or reversal. Record the signal, order quantity, simulated fill, open-entry count and resulting position size, then compare them with the actual account's executions. The strategy alert timing guide helps keep simulated fills separate from broker fills. If you change settings after creating an alert, also review how to replace alerts that retain old settings. A correct calculation in the chart is useful only when the running alert and receiving account tell the same story.