User tiers and cooldowns
Per-user controls in the Binary AI Engine — volume and deposit tiers that add a win-rate bonus, big-win and streak cooldowns that subtract one, and how to inspect, edit or lift either for a specific user.
The engine's win-rate target is a property of a market, not a person. Tiers and cooldowns are the two mechanisms that make a bucket's effective target reflect who is in it.
Both are adjustments to the same number, in opposite directions:
effective target = engine target
+ average tier bonus of tiered orders in the bucket
- cooldown reduction × (cooldown orders ÷ all orders)The result is then clamped to the platform min/max band, and capped again if the bucket contains a whale. Neither mechanism can push an engine outside the band you configured.
One published close resolves every order sharing an expiry minute, so two users in the same minute always get the same outcome. A tier bonus does not give one user a better result in that minute — it raises the target for the bucket they are in. Across many buckets, users who are usually in tiered company do measurably better.
User tiers
Tiers live under Users → User Tiers and are per engine. Two engines can run completely different ladders.
enableUserTiers on the engine is the master switch; tierCalculationMethod
decides what a user is measured on.
| Method | Measured on |
|---|---|
VOLUME |
Settled binary order volume (statuses WIN, LOSS, DRAW) |
DEPOSIT |
Total deposits |
MANUAL |
Assigned by an administrator |
Tier fields
| Field | Meaning |
|---|---|
tierName |
Display name, e.g. GOLD |
tierOrder |
Hierarchy position; higher is better |
minVolume |
Inclusive lower bound |
maxVolume |
Exclusive upper bound; null means unbounded (top tier) |
minDeposit |
Lower bound when the method is DEPOSIT |
winRateBonus |
Added to the target, as a fraction. Capped at 0.2 (20 points) |
isActive |
Inactive tiers are ignored entirely |
description |
Free text for your own reference |
Bucket selection
A user falls into exactly one tier: the qualifying tier with the highest
minVolume. Bands are half-open — a value equal to a tier's maxVolume belongs
to the next tier up. A user whose value exceeds every bounded tier's maxVolume
lands in the highest-minVolume tier, which is the intended behaviour for an
unbounded top tier.
Both the tier manager and the position analyser use the same selection function, so the tier shown on a screen and the tier used in the arithmetic always agree.
The create and update endpoints reject maxVolume at or below minVolume with a
400, and reject a winRateBonus above 0.2. Before that validation existed, an
inverted band saved cleanly and then silently matched no user at all.
The seeded ladder
Enabling the extension seeds five tiers per existing engine:
| Tier | Order | Min volume | Min deposit | Bonus |
|---|---|---|---|---|
| BRONZE | 1 | 0 | 0 | 0% |
| SILVER | 2 | 5,000 | 500 | +1% |
| GOLD | 3 | 25,000 | 2,500 | +2% |
| PLATINUM | 4 | 100,000 | 10,000 | +3% |
| DIAMOND | 5 | 500,000 | 50,000 | +5% |
The seeder skips engines that already have a tier of the same name, so it is safe to re-run. Engines created later do not get seeded tiers — add them yourself.
Note that the seeded bonuses and the Settings page's five tier-bonus fields are separate things. The Settings fields are the platform-wide defaults referenced when reasoning about the ladder; the numbers actually applied come from these per-engine rows.
Designing a ladder
- Keep the top bonus modest. A +5% bonus on a 35% target is a 40% target, which is inside the default 25–45% band but close to its ceiling. Anything the band would clamp is a bonus you are not really giving.
- Mind the whale interaction. A DIAMOND user placing whale-sized tickets gets the tier bonus applied and then the whale cap applied over the top. Cap wins.
- Leave a zero-bonus entry tier. BRONZE at 0/0/0% exists so every user has a tier and the average is well defined.
Cooldowns
A cooldown is a temporary win-rate reduction attached to one user on one engine. Cooldowns live under Users → Cooldowns.
The engine-level master switch is enableBigWinCooldown; streaks have their own
enableStreakCooldown.
The two triggers
After a settlement, if the user's realised profit reaches bigWinThreshold,
a BIG_WIN cooldown is applied for cooldownDurationMinutes at a reduction of
cooldownWinRateReduction.
bigWinThreshold is an absolute profit amount in the market's quote currency
— what the user actually took off the table, not the stake and not a multiple of
anything. Defaults: 1,000 profit, 60 minutes, −10%.
That distinction matters. Measured on the stake, a 1,000 threshold fires on a 1,000 stake that returned 750, and never fires on a 999 stake that returned 999 at a 100% payout.
If enableStreakCooldown is on and the user's consecutive wins on this
symbol reach streakThreshold (default 3), a STREAK cooldown is applied for
streakCooldownDuration minutes (default 30) at the same reduction.
The streak is scoped to the engine's own market, so wins elsewhere on the platform do not accumulate toward it.
Both triggers are evaluated during reconciliation, after the settlement transaction has committed, and both are best-effort: a cooldown failure never affects a settlement.
One row per reason
At most one active cooldown exists per (engine, user, reason). A user on a long
streak has an existing active row refreshed — trigger amount, reduction and
expiry updated — rather than accumulating a new row on every win. Without that, a
table full of rows would exist where only the latest-expiring one was ever read.
A user can hold a BIG_WIN and a STREAK cooldown at the same time. Cooldown
lookups take the one expiring latest.
Manual cooldowns
MANUAL is a valid reason. Support and risk teams can create or edit a cooldown
directly from the cooldowns screen — useful when you want to slow an account down
without touching engine configuration. Edits accept a winRateReduction between 0
and 1, an expiresAt date, and isActive.
Lifting a cooldown
Three routes, in increasing blast radius:
- Deactivate one cooldown on the cooldowns screen. Wrong-call fix for one user.
- Delete the cooldown row. Removes it from history too. Prefer deactivation.
- Clear All Cooldowns on the Settings page. Every active cooldown, on every engine, deactivated at once. Optionally scoped to a single engine.
The bulk clear deactivates rather than deletes, so who was penalised, why and for how long survives. That record is the only evidence a win-rate reduction was ever applied to a specific account, and you will want it if anyone asks.
Expired cooldowns are also cleaned up automatically as part of each period reset.
Caching
Active-cooldown lookups are cached for 30 seconds and tier lookups for 60 seconds per user. A cooldown you deactivate can therefore take up to half a minute to stop influencing a bucket. The caches are cleared when a cooldown is written through the manager.
What appears on the position row
Every position the engine tracks records the per-user context it used:
| Field | Meaning |
|---|---|
userTier |
The tier name in force when the order was analysed |
isWhale |
Whether the order crossed the whale threshold |
hasCooldown |
Whether the user was under cooldown |
abTestId / abVariant |
The experiment arm governing this position, if any |
These are refreshed on every tick while the position is open, because a user's tier or cooldown state can change before expiry. Once settled they are frozen.
That makes the positions screen — Engine → Positions, filterable by status and whale flag — the place to answer "why did this specific trade go the way it did".
Practice and demo accounts
Neither tiers nor cooldowns apply to demo orders. Tier bonuses are computed for
live buckets only, cooldown reductions likewise, and cooldowns are only evaluated
on live settlements. A demo account trading under CUSTOM practice mode gets the
practice target and nothing else.