Binary Trading AI Engine
A dealing-desk layer for binary options — target win rates, bounded settlement steering, per-user tiers and cooldowns, whale handling and house risk limits, on top of Bicrypto's core binary markets.
On a binary market the platform is the counterparty to every trade. When a user wins, the house pays; when a user loses, the house keeps the stake. Left alone that is a coin flip with a payout haircut, and the house profit-and-loss swings hard from day to day even when the long-run maths is sound.
The Binary Trading AI Engine makes that P&L predictable. You give an engine a target user win rate, and it steers realised outcomes toward that target inside tight, configurable bounds — so instead of getting lucky or unlucky, you hold a margin you chose.
This addon deliberately influences the settlement price of real money contracts. Whether you may operate it at all depends on your jurisdiction, your licence and what your terms of service say. It is your responsibility to establish that before you switch an engine to ACTIVE. Nothing in the product makes that judgement for you.
What it requires
This is not a standalone product. It sits at the top of a four-layer stack and every layer below it must already be installed, licensed and working.
| Layer | Why it is required |
|---|---|
| Bicrypto (core) | Owns binary markets, binary settings, binary orders and the settlement path the engine hooks into. |
| Ecosystem | The engine may only steer a binary market whose source is ECOSYSTEM — a market whose price series your own platform publishes. |
| AI Market Maker | An engine is attached to one AI Market Maker, one-to-one. The market maker owns the price series; without an ACTIVE one the engine refuses to steer. |
| Binary Trading AI Engine | This addon. |
There is no way around that chain. The create-engine screen lists AI Market Makers, not markets, so an install without the market maker addon has nothing to attach an engine to. See Install for the order to do it in.
The optional Chart Engine addon is unrelated to the engine but is the default
chart on the binary trading screen; see the display.chartType setting under
Finance → Binary → Settings.
What it does not do
Four things people expect it to control, and it controls none of them.
- It does not set payouts. What a winning trade pays comes from the per-type Profit % under Finance → Binary → Settings, and is stamped onto each order at the moment it is placed. The engine has no say in it and never did.
- It does not create binary markets or order types. Those are core Bicrypto screens under Finance → Binary.
- It does not touch anything but Rise/Fall. Higher/Lower, Touch/No-Touch, Call/Put and Turbo settle fairly and untouched, as does every non-binary product on the platform — spot, futures, forex, staking.
- It does not decide individual trades. Steering happens per expiry bucket: one published close price resolves every order sharing that expiry minute. Two users who expire in the same minute always get the same close.
The core idea
A target win rate of 35% means that, across many settled orders, roughly 35% end in a user win. Whether that leaves you ahead depends entirely on the payout you advertise.
The break-even user win rate is 1 / (1 + payout). At the default 72% Rise/Fall
payout that is 58.1% — below it the house is ahead, above it the house pays
out more than it takes. The expected house margin per unit staked is
(1 − w) − w × payout, where w is the realised user win rate.
That gives you the two dials that matter:
- Raise the target and the platform feels more generous. Retention improves, margin thins.
- Lower the target and margin widens, but users notice. Nothing stops a cohort from concluding the market is unwinnable.
Every engine is clamped to a global floor and ceiling — 25% to 45% by default, set on the Settings page. The per-engine target column itself rejects anything outside 0.25–0.45 at the model level, so a direct database edit cannot widen the band either.
How a trade actually flows
-
A user places a Rise/Fall order on a binary market. Core Bicrypto validates it, takes the stake, stamps the payout percentage on the order row, and stores it with an expiry time.
-
The tick loop notices it. Once a second, each ACTIVE engine groups the open orders on its symbol into expiry buckets. Buckets further out than the engine's
adjustmentLeadTimeSeconds(default 30) are ignored, as are buckets whose total staked amount is belowminPositionForOptimization. -
A decision is recorded. For each bucket in range the engine works out which side — RISE or FALL — should win, given the current period win rate, the target, tier bonuses, active cooldowns, whale caps and the remaining daily-loss budget. That decision is written onto every position row in the bucket.
-
Settlement reads the decision. When the orders expire, the settlement path asks the engine for an effective close price. If every safety condition holds, the honest close is nudged to the far edge of a tiny band (
maxPriceAdjustmentPercent, default 0.3%, hard-capped at 1%) in the house-favourable direction, and that steered price is published into the candle series clients can see. -
The result is reconciled. Realised outcome, platform profit and the exact reason the settlement was or was not steered are written back to the position row, and the period counters and cooldowns are updated.
Every step from 3 onward fails safe: any error, any missing precondition, any disagreement with the published chart, and the order settles on the honest close with nothing touched.
Where to start
The prerequisite chain, the extension row that gates the cron, and how to prove the engine is actually running before you point it at real money.
Creating an engine against a market maker, the three states, period resets and what each field on the detail screen changes.
Exactly how a close price is steered, the seven conditions that refuse to steer, and where payouts really come from.
Daily loss budget, per-order exposure cap, whale handling, simulation and practice modes, and the emergency stop.
Volume and deposit tiers with win-rate bonuses, big-win and streak cooldowns, and how to lift one for a specific user.
Machine-learning win-rate recommendations, cohorts, A/B tests, time-of-day breakdowns and external price correlation monitoring.
Behind those: Global settings documents every
binaryAiEngine* key on the Settings page,
Snapshots and audit covers configuration
rollback and the append-only action log, API reference
lists every endpoint with its permission, and
Troubleshooting is the page to open when an ACTIVE engine
appears to be doing nothing.
Design principles worth knowing up front
The settlement hook can never throw into the trade path. It is wrapped so that a database hiccup, a missing market maker, an unreachable Redis or an unparseable JSON column all resolve to one outcome: settle on the real close price. A broken engine is an engine that stopped steering, not an engine that mis-priced anything.
The engine only steers markets whose price series the platform itself publishes, and only while it can still write the steered value into the candle a client is watching. If the expiry minute has already closed, or the market is exchange-backed, or the market maker is not ACTIVE, it refuses. Otherwise the settled close would disagree with the chart — and that gap is the single provable artifact.
Every order sharing an expiry minute settles on the same published number, pinned in Redis so two processes cannot each publish a different steered close for the same minute.
The win rate is clamped to the global min/max band on every decision. The price
nudge is clamped to maxPriceAdjustmentPercent, which is itself hard-capped at
1% in code regardless of what is stored in the column. A user who wins by more
than the band still wins.
Every steering decision, every refusal and its reason, every cooldown, every status change and every configuration edit is written to the engine action log and to the position row. If you ever have to explain an outcome, the record is there.