Pricing and settlement

This is the page that explains what the addon actually does to a trade. Read it before you activate an engine on live money — not because the mechanism is complicated, but because every safety rule in it exists for a reason you will otherwise discover the hard way.

Payouts are not set here

Start with what the engine does not control.

What a winning binary trade pays comes from the per-type Profit % under Finance → Binary → Settings, adjusted by the per-duration profitAdjustment, and it is stamped onto the order row at the moment the order is placed. The engine has no input into it. There is deliberately no payout column on the engine.

Break-even is 1 / (1 + payout). Duration overrides move the effective payout — ultra-short expiries get a bonus, hour-plus expiries a penalty, on the reasoning that skilled traders have more edge over a longer horizon.

Two knobs, two owners: Finance → Binary → Settings decides what a win pays, the engine decides how often a win happens. Change either and you change your margin.

The decision: which side should win

Once a second, each ACTIVE engine looks at the open Rise/Fall orders on its symbol and groups them into expiry buckets — all orders sharing an expiry time.

A bucket is skipped when:

• it has no orders;
• expiry is further out than adjustmentLeadTimeSeconds (default 30);
• expiry has already passed;
• the total staked (totalRise + totalFall) is below minPositionForOptimization.

For every surviving bucket the engine computes an effective target win rate, starting from the engine's targetUserWinRate and adjusting it:

The engine then compares that target to the realised win rate for the current period — wins / (wins + losses) from the engine's own counters:

With zero settled orders in a period the realised rate is reported as the configured target, so a fresh period resolves to WITHIN_RANGE and does not open with a spurious forced outcome.

A forced win lands on the side holding the most orders. That is what makes the daily-loss guard below necessary.

The daily-loss override

Honouring the win-rate target must never cost more than you signed up for. Before committing, the engine checks: if the chosen side would push the period's platform profit below −maxDailyLoss, and the other side would not, it takes the other side and records the reason with an _OVERRIDDEN_BY_DAILY_LOSS_LIMIT suffix.

The win rate drifts; the balance sheet does not. If the period profit cannot be read at all, the guard treats the budget as exhausted rather than assuming headroom.

Recording the decision

The chosen side is written to manipulationDetails.targetSide on every position row in the bucket, together with the target price, direction, expected profit, confidence and a timestamp. Positions are created on first sight and refreshed on every subsequent tick, because bucket composition changes as new orders arrive.

wasManipulated stays false here. It only becomes true at reconciliation, once the settlement price was genuinely adjusted.

The decision is recorded for live and demo alike; whether it is applied is decided at settlement.

The settlement seam

When an order expires, core Bicrypto asks the engine for an effective close price. The engine either returns the real close unchanged, or returns a nudged one.

The nudge is simple: push the close to the far edge of the allowed band in the house-favourable direction.

maxAdj    = realClosePrice × maxPriceAdjustmentPercent
effective = targetSide === "RISE"
              ? realClosePrice + maxAdj
              : realClosePrice - maxAdj

At the default maxPriceAdjustmentPercent of 0.003 that is 0.3% of the close. The column is hard-capped at 0.01 (1%) in code, and the cap is re-applied when the configuration is loaded, so a row written by a direct database edit cannot widen it either.

Only outcomes inside the band flip. A user who won by more than 0.3% still wins.

Seven ways it refuses to steer

Every refusal is deliberate, and every one is recorded on the position row as manipulationDetails.settlementDecision. The dashboard aggregates them over the last 24 hours. This is the list to check when an ACTIVE engine appears to be doing nothing.

The two publication rules

These are the rules that keep the settled price and the visible chart in agreement. Both fail safe.

The market must be one you actually publish

The engine checks that the binary market's source is ECOSYSTEM, that a matching ecosystem market exists, and that its AI Market Maker is ACTIVE.

The last condition matters more than it looks. An engine can be ACTIVE while its market maker is stopped — restart recovery revives engines without re-checking. In that state nothing else writes the tape: entries read the last candle close and settlements publish into it, both numbers the engine itself last wrote. It would be settling against its own prints. So it does not.

The expiry candle must still be open

The steered value becomes the close of the 1-minute candle covering expiry. If the minute has already rolled over, that candle is history and a client may already have seen it. The engine compares the expiry minute to the current minute and refuses when they differ, recording how late it was.

One bucket, one close

Every order sharing an expiry minute settles on the same number. Without that, each settlement would re-apply the band to the price the previous settlement had just published — six orders would ratchet the series by roughly 1.8% and hand later entrants an outcome the band was never meant to reach.

Two layers enforce it:

• an in-process map keyed by symbol and expiry minute;
• a durable pin recorded by the settlement-close authority, so two processes or a restart mid-bucket cannot each publish a different close for the same minute.

The pin is the same record the market maker and the matching engine defer to, so all three agree by construction.

Publishing the steered price

When the engine steers, it writes the value into the ecosystem candle series and updates the market maker's lastKnownPrice. The candle write pins the value as that minute's close for the rest of the minute — without the pin the market maker's next write (within a second on a trade tick, ten seconds on its heartbeat) would overwrite it and leave the settled order permanently disagreeing with the chart.

Publishing happens before the price is returned. If it fails, the engine settles fairly instead — a price nobody could see is not a price it will settle on.

Reconciliation

After the settlement transaction commits, the engine reconciles the order into its position row. This is idempotent and never throws.

• Outcome and status are written; the position moves to SETTLED.
• Platform profit is computed: a user WIN is −profit to the house; a total LOSS is +stake; a partial loss (Turbo) is −profit, which is positive; a DRAW is zero.
• wasManipulated is set true only if the engine was genuinely active, non-simulation, not globally shadowed, not a blocked demo order, and a decision had been recorded.
• settlementDecision records exactly which of the reasons above applied.
• Period counters are updated for live orders; demo orders only count when practice mode is engaged.
• Cooldowns are evaluated against the user's realised profit.

Volatility masking

volatilityMaskingEnabled (on by default) adds a small random noise component, bounded by volatilityNoisePercent (default 0.001, maximum 0.05), to the market-side price nudges. Its purpose is to stop the engine's interventions from forming an obvious repeating pattern on the chart. It does not widen the settlement band, which stays governed by maxPriceAdjustmentPercent alone.

What to check when nothing is being steered

In order — the first two account for most cases:

1. processBinaryAiEngine in Admin → System → Cron. No cron, no engines.
2. The dashboard's settlement verdict breakdown. It names the reason.
3. The attached market maker's status.
4. The binary market's source.
5. minPositionForOptimization against the stakes people are actually placing.
6. adjustmentLeadTimeSeconds against the durations you offer.

Troubleshooting walks through each of these.