Barriers, strikes and the payout optimizer

How barrier distance and payout are coupled, the break-even arithmetic the product uses, the shipped ladders, and exactly which fields the Payout Optimizer rewrites when you apply it.

10 min readUpdated 6 August 2026binary, barriers, payouts, optimizer, house-edge

A barrier is a distance from the entry price, and a payout is what you pay when the customer's contract lands the right side of it. They are one setting, not two. A wider barrier is easier for the trader to reach, so a payout that earns money at 0.1% is a guaranteed loss at 1%. Nothing on the Barrier Levels tab enforces that relationship — you can save a 90% payout at 2% distance and the platform will honour it on every ticket.

The product ships a calculator for this. This page is the arithmetic behind it, the ladders it ships with, and what the Apply optimized settings button actually writes.

Everything here is on Admin → Finance → Binary Options → Binary Settings (/admin/finance/binary/settings), on the Barrier Levels and Payout Optimizer tabs. How a chosen level's payout reaches a customer's ticket, and the duration ladder that then moves it, are on Order types, durations and payouts.

What a level is

Barrier levels and strike levels are the same five fields. They are stored per order type inside the single binarySettings JSON row, never as their own settings keys.

Field	Meaning
`id`	The identifier the trading page sends back when the customer picks this level. Shipped levels use readable ids (`hl_close`, `tn_near`, `cp_atm`, `turbo_tight`); one you add gets a generated one.
`label`	What the customer sees. The shipped labels carry the distance — `"Close (0.1%)"` — which is why editing a distance without editing the label produces a level that lies to the trader.
`distancePercent`	How far the barrier or strike sits from the entry price, as a percentage. Must be positive; a zero or negative value is a validation error and blocks the save.
`profitPercent`	The payout for this level. This is the number that reaches the ticket, replacing the order type's own `profitPercentage`. Must be 0–1000.
`enabled`	Whether the level is offered. A disabled level keeps its history readable without being sellable.

Which list a type carries:

Order type	List	Also carries
`RISE_FALL`	none — it has no barrier
`HIGHER_LOWER`	`barrierLevels`
`TOUCH_NO_TOUCH`	`barrierLevels`	`touchProfitMultiplier`, `noTouchProfitMultiplier`
`CALL_PUT`	`strikeLevels`	requires `payoutPerPoint` on the order (0.01–1000)
`TURBO`	`barrierLevels`	`payoutPerPointRange {min, max}`, `maxDuration`, `allowTicksBased`

Enabling a type with an empty list is a validation error: <TYPE>: At least one barrier level is required when enabled. Disabled types may have empty lists, which is how a half-configured type sits harmlessly until you finish it.

Touch and No Touch are priced twice

TOUCH_NO_TOUCH applies a side multiplier on top of the level's payout — touchProfitMultiplier (shipped 1.2) for a TOUCH ticket and noTouchProfitMultiplier (shipped 0.7) for a NO_TOUCH one. A level carrying 150% therefore pays 180% on Touch and 105% on No Touch before the duration ladder touches it.

That is deliberate and it is the only place the two sides of a contract are priced differently. Touch requires the price to travel a set distance and hit an exact level; No Touch only requires it to stay in a range, which ordinary market noise does for you.

Turbo's payout per point

TURBO is the one type where the customer also chooses a rate, and payoutPerPointRange bounds it: an order outside it is refused with Payout per point must be between <min> and <max>. Shipped range is 0.1 to 10; the conservative preset narrows it to 0.1–5 and the aggressive preset widens it to 0.1–20.

CALL_PUT also requires payoutPerPoint on the order, but has no configurable range — it is validated only against a fixed 0.01 to 1000. If you enable Call/Put, that is a number you cannot bound from this screen.

The shipped ladders

An install that has never saved binary settings serves these. Each profitPercent is the payout before the duration adjustment.

Higher/Lower — orderTypes.HIGHER_LOWER.barrierLevels

`id`	Distance	Payout	Enabled
`hl_close`	0.1%	68%	yes
`hl_near`	0.2%	54%	yes
`hl_medium`	0.3%	45%	yes
`hl_far`	0.5%	35%	no

Touch/No Touch — orderTypes.TOUCH_NO_TOUCH.barrierLevels, before the ×1.2 / ×0.7 side multipliers

`id`	Distance	Payout	Enabled
`tn_close`	0.1%	95%	yes
`tn_near`	0.2%	120%	yes
`tn_medium`	0.3%	150%	yes

Call/Put — orderTypes.CALL_PUT.strikeLevels

`id`	Distance	Payout	Enabled
`cp_atm`	0.1%	72%	yes
`cp_near`	0.2%	62%	yes
`cp_otm`	0.5%	48%	yes

Turbo — orderTypes.TURBO.barrierLevels

`id`	Distance	Payout	Enabled
`turbo_tight`	0.03%	75%	yes
`turbo_normal`	0.05%	65%	yes
`turbo_wide`	0.1%	52%	yes

Every ladder pays less as the distance grows, except Touch/No Touch, which pays more — because on Touch a farther barrier is harder to reach, not easier. That inversion is the single thing to hold in your head before editing anything here.

Only RISE_FALL ships enabled, so none of these ladders is live on a default install. They become live the moment you switch their type on.

The break-even identity

One line of arithmetic governs the whole screen:

required win rate = 100 ÷ (100 + payout %)

That is the fraction of contracts the customer must win to break even against you. Above it they profit; below it you do.

Payout	Customer must win	Margin over a coin flip
50%	66.7%	16.7 points
65%	60.6%	10.6 points
72%	58.1%	8.1 points
80%	55.6%	5.6 points
85%	54.1%	4.1 points
95%	51.3%	1.3 points
100%	50.0%	none
120%	45.5%	negative

Comparing the break-even rate to 50% assumes a random guess wins half the time. That is true of RISE_FALL and of nothing else on this screen. A Touch contract at 0.3% distance is won maybe 15% of the time, which is why paying 150% on it is sound and paying 150% on a Rise/Fall contract would be ruinous.

For every barrier and strike type, compare the break-even rate to the barrier's own win probability, in the next section — not to 50%. The optimizer's own "platform edge" cards use the 50% baseline for all five types, and that is their main blind spot.

Barrier distance and how often the trader wins

BARRIER_WIN_PROBABILITY is the product's estimate of how often price travels a given distance inside a contract's life. It is the table the shipped ladders were priced from, and the one to price a new level with.

Distance	Estimated trader win rate	Payout at which you break even	Source's own description
0.03%	30%	233%	very hard
0.05%	35%	186%	hard
0.1%	42%	138%	challenging
0.15%	47%	113%	moderate
0.2%	52%	92%	slightly easy
0.3%	58%	72%	easy
0.5%	65%	54%	very easy
1%	75%	33%	near guaranteed
2%	85%	18%	abuse level
5%	95%	5%	effectively guaranteed

The third column is the identity run backwards — 100 ÷ p − 100, the payout at which a trader with that win rate makes exactly nothing. Anything above it loses money on every ticket, forever. Distances between two rows are interpolated linearly; anything below 0.03% or above 5% is clamped to the end value.

Read the last two rows again. At 1% distance any payout above 33% is a loss, and at 2% anything above 18% is. That is why the settings validator raises a warning when Higher/Lower's widest enabled barrier exceeds 1% and a danger when it exceeds 2%, and why hl_far at 0.5% ships disabled.

Pricing a level by hand

Pick the distance and read the trader win rate p from the table.
Choose the margin you want, in percentage points over p. The product's own targets are 7 to 10 points — see the duration table below.
Compute the break-even rate: BE = p + margin, as a decimal, and never below 0.51.
Compute the payout: payout = 100 ÷ BE − 100.
Adjust for the order type by multiplying by its risk multiplier, below.
Sanity-check against the third column of the table. If your answer is anywhere near the break-even payout for that distance, the level is not earning enough to be worth offering.

Worked: a Higher/Lower level at 0.2%. p is 52%, take 9 points of margin, so BE = 0.61 and payout = 100 ÷ 0.61 − 100 = 63.9, times 0.95 for Higher/Lower gives 61%. The shipped hl_near is 54%, which is more conservative — the shipped ladders are hand-chosen and sit below what the formula allows.

Platform edge by duration

PLATFORM_EDGE_BY_DURATION is the margin, in percentage points over 50%, the optimizer aims for at each contract length. The category is chosen by minutes alone.

Category	Applies to	Target edge	Break-even	Optimal payout
`ULTRA_SHORT`	1 minute and under	8	58%	72.4%
`SHORT`	over 1, up to 5 minutes	7	57%	75.4%
`MEDIUM`	over 5, up to 30 minutes	9	59%	69.5%
`LONG`	over 30 minutes	10	60%	66.7%

Longer durations get a bigger edge because a skilled trader beats randomness over an hour and cannot over a minute: full technical analysis works at 60 minutes, and price movement inside 60 seconds is mostly noise. Lower payouts on the long rungs are how the platform is compensated for that.

SHORT carries the smallest edge of the four (7), so 2 to 5 minutes is the best-paying band in the shipped model — better than 1 minute. The reasoning in the source is behavioural: ultra-short contracts feel like gambling, so traders accept slightly worse odds, while the 2–5 minute band is where the platform competes for the trader who thinks they have an edge.

Order type risk multipliers

ORDER_TYPE_RISK_MULTIPLIER scales a computed payout by how hard the type is for the trader.

Type	Multiplier	Why
`RISE_FALL`	1.00	the baseline: a pure direction bet
`HIGHER_LOWER`	0.95	the barrier gives the trader a second way to be right
`TOUCH`	1.15	must hit an exact level, not just finish on a side
`NO_TOUCH`	0.85	only has to stay in a range; market noise helps
`CALL_PUT`	0.92	like Higher/Lower, against a strike
`TURBO`	0.90	ultra-short and volatile, so closer to random

Note that Touch and No Touch have separate multipliers here, while the settings document has separate touchProfitMultiplier / noTouchProfitMultiplier fields with different shipped values (1.2 and 0.7). The constants above are the optimizer's model; the fields on the Order Types tab are what actually price a ticket.

The Payout Optimizer tab

The tab has three read-only cards and one button. Everything on it is computed in your browser from the settings currently on screen — there is no optimizer endpoint, and nothing it shows has been saved.

What each card computes

Card	Reads	Watch out for
Platform edge (the ring)	the mean of `100 ÷ (100 + profitPercentage) − 50` across enabled types only	uses the type-level base payout, which four of the five types never charge
Active order types / durations	counts of `enabled`	nothing
Health score	the number of warnings — 0 is "Excellent", 1–2 "Good", 3+ "Needs attention"	it is a count, not a severity
Platform edge by order type	per enabled type, from `profitPercentage`	same base-payout problem
Platform edge by duration	`RISE_FALL` base, plus that one rung's `profitAdjustment`	the engine sums the whole ladder — see below
Warnings and recommendations	barriers over 1% distance paying over 60%; edge under 5% or over 15%	the barrier check only looks at enabled types

The type-level payout is not what four of five types pay. Choosing a barrier or strike level is mandatory on HIGHER_LOWER, TOUCH_NO_TOUCH, CALL_PUT and TURBO, and the level's profitPercent replaces the type's base outright. The edge cards read the base. On a default-shaped install with Touch enabled at a 95% base, the tab reports a 1.3% edge for it and drags the overall ring down — while the ladder it is actually selling (95/120/150, ×1.2 on Touch) is comfortably profitable.

The per-duration edge ignores the cascade. The engine sums every rung's adjustment from the shortest up to and including the one chosen; this card reads one rung in isolation. On the shipped ladder the card reports the 1-hour edge as if the payout were 63.4%, when the payout actually charged is 57.6%.

What Apply optimized settings writes

The button stages changes — the floating "You have unsaved changes" bar appears with Discard and Save changes. Nothing is written until you press Save, and Discard restores what was loaded.

It rewrites exactly two things.

One: the base payout on all five order types. Computed from the SHORT category (7 points of edge, 75.4% optimal payout) times each type's multiplier:

Type	New `profitPercentage`
`RISE_FALL`	75
`HIGHER_LOWER`	72
`TOUCH_NO_TOUCH`	83
`CALL_PUT`	69
`TURBO`	68

Two: the entire durations array, replaced with eight rungs — 1, 2, 3, 5, 10, 15, 30 and 60 minutes — each with a new id of the form duration_<n>m, all five orderTypeOverrides filled in, and TURBO enabled only at 5 minutes and under. Each rung's enabled is carried over from an existing rung with the same minutes, or set to true if there was none.

The per-type adjustments it writes:

Rung	RISE_FALL	HIGHER_LOWER	TOUCH_NO_TOUCH	CALL_PUT	TURBO
1 min	−4	−9	−4	−12	−14
2 min	0	−5	0	−8	−10
3 min	0	−5	0	−8	−10
5 min	0	−5	0	−8	−10
10 min	−8	−13	−8	−16	off
15 min	−8	−13	−8	−16	off
30 min	−8	−13	−8	−16	off
60 min	−12	−17	−12	−20	off

What it does not touch: barrier levels, strike levels, the Touch multipliers, Turbo's payoutPerPointRange, the global limits, cancellation rules and risk management are all left exactly as they were. The card's own bullet list claims it will "optimize barrier level payouts" — it does not. The bullet claiming a 72% Rise/Fall payout is also stale; the figure it writes is 75.

It deletes any rung that is not 1, 2, 3, 5, 10, 15, 30 or 60 minutes. The aggressive preset ships a 4-hour rung and it is silently dropped, as is any custom duration you added.

It changes every duration id from d_5m to duration_5m. A customer whose trading page is already open is holding the old catalogue and will get Invalid or inactive duration selected on their next order until they reload.

The cascade makes the long rungs pay far less than the tab suggests. Because adjustments are summed, the payouts the optimizer's own ladder actually charges on Rise/Fall are:

Duration	Running total	Effective payout
1 min	−4	72.0%
2–5 min	−4	72.0%
10 min	−12	66.0%
15 min	−20	60.0%
30 min	−28	54.0%
1 hour	−40	45.0%

The tab's own table will report the 1-hour edge as about 10%. The real payout of 45% is a break-even rate of 69%, which is 19 points over a coin flip — more than double the target. That may be exactly what you want; it is not what the screen says you are getting.

A review order that works

Decide the distances before the payouts. The distance sets the trader's win rate; the payout is then arithmetic, not taste.
Price each level from the win-probability table, then compare it to the break-even payout in the third column. If the two are close, either tighten the barrier or drop the level.
Use the optimizer as a second opinion, not a first draft. Read its warnings, ignore its per-type edge figures for anything with a ladder, and remember it will replace your duration rungs wholesale if you press Apply.
If you do apply it, walk the duration ladder afterwards and total the adjustments for each type. The number in the box is not the number applied.
Save, then place one real order at each enabled level on a test account and read profitPercentage off the row in Order Management → Binary Orders. That frozen column is the only proof the arithmetic came out where you intended — see The binary order desk.

Related: Order types, durations and payouts for how the ladder moves a payout, Early cancellation and risk limits for the refund path and the three presets, and Binary options: switching it on for the switches and the global per-user limits.