MBOT Support Center

MBOT is a Binance spot grid trading bot SaaS platform. Users choose a plan, connect exchange API keys, configure bot settings, and monitor runtime state from a dashboard.

The goal is to automate buy-sell cycles during price oscillations, make open position risk visible, and manage the bot from one interface.

MBOT focuses on Binance spot markets. Futures, shorts, and leverage are not part of the core product flow.

The spot-only model allows users to connect API keys without withdrawal permission.

No. No trading bot can guarantee profit. Grid bots assume that price will continue oscillating inside a useful range. If the market trends sharply in one direction, open positions, waiting time, and losses can occur.

That is why MBOT includes testnet onboarding, backtesting, inventory risk tracking, max coin limits, reserve controls, and new BUY locks.

The bot creates buy and sell levels inside a selected price range. When price drops, buy levels can fill. When price rises, sell levels can close those positions for a spread.

This works best in sideways or oscillating markets. In strong trends, new buys should be restricted.

MBOT is for Binance spot users who want to automate grid trading and are willing to configure API security and risk settings correctly.

Beginners should start with testnet and small budgets. Advanced users can tune grid, inventory, and backtesting settings in more detail.

Use the register button on the landing page to create a user account. After registration, the dashboard guides you through plan, payment, API, and bot runtime setup.

The SaaS flow is designed to verify subscription and API readiness before enabling live bot usage.

The recovery code is used to regain access if you forget your password. It is shown only once and must be stored securely.

MBOT cannot show the same recovery code again. Losing it can make account recovery harder.

You can sign in, but live bot functions depend on an active plan and payment state. Without an active plan, the dashboard may stay limited or setup-pending.

After registration and activation, MBOT requires 2FA before live bot usage and critical account actions. Live API addition, live bot settings, and starting the bot in live mode should not be available without 2FA.

This protects the account if a password is compromised and makes unauthorized bot starts, API changes, or subscription misuse harder.

• Open Profile or Account Security in the dashboard.
• Enable the 2FA / Authenticator option.
• Scan the QR code with Google Authenticator, Microsoft Authenticator, or another TOTP app.
• Enter the 6-digit code generated by the app and confirm.
• Store recovery codes securely and never share them.

First add and validate your API settings. Then review testnet or demo values, confirm bot settings, and check plan limits.

Before live mode, 2FA must be enabled, a Live Binance API key must be added and validated, and MBOT should show validation_status=valid with can_trade=true. Also verify max coins, per-token order cap, reserve, inventory lock, and risk shield settings.

MBOT supports Turkish and English interfaces. Language should follow the URL and saved preference. Light and dark themes are available across the public site and dashboard.

Landing and dashboard copy should match the selected language.

The plan controls available bot features, runtime access, limits, and subscription state. Plan selection is part of the registration and payment flow.

Live bot access should not open until the active plan and payment status are verified.

The subscription becomes active and dashboard features unlock according to the plan limits. The user can then validate API keys and proceed with setup.

If payment or license validation is not complete, live bot access remains restricted.

MBOT payments are collected in crypto through the XPayr checkout flow. After selecting a plan, the user is redirected to the XPayr payment page or sees an XPayr payment popup.

In the payment screen, connect a wallet, choose a supported network and token, and approve the transaction from the wallet. XPayr verifies the chain payment and MBOT updates subscription access after confirmation.

• Click the plan button and complete login or registration.
• Choose and connect your wallet in the XPayr checkout.
• Select the correct network and token. Pay attention to mainnet/testnet labels.
• Approve the wallet transaction and wait for on-chain confirmation.
• If access does not update immediately, check the payment status and the Subscription page.

At this stage, crypto renewals are manual. MBOT can show reminders or send notifications before the subscription expires.

To renew, return to the plan/payment flow and complete a new crypto payment through XPayr. There is no automatic card or bank charge.

Check the payment provider status first. If the dashboard still does not unlock, review the package and payment status messages.

Pending, failed, or expired payments do not grant live bot access.

Plan changes are handled from the subscription area. Limits and available features update according to the selected plan.

After an upgrade or renewal, you may need to refresh the dashboard or re-check the session.

The landing page plan buttons move users into registration or login. Payment and technical details are handled inside the dashboard for better account validation.

This reduces incorrect package activation and keeps payment flow tied to an authenticated user.

Starter is the testnet onboarding plan for learning MBOT without live-fund risk. It includes testnet mode, Standard Grid Engine testing, basic reports, emergency stop, and standard support.

Starter is not a live trading plan. Live API, live orders, and live bot mode require a live-enabled plan such as Flow, Pro, or Prime.

Flow is for users who want a focused live Standard Grid setup for Binance spot. It includes Live Standard Grid, Bull Basket, basic Telegram alerts, basic reports, emergency stop, and standard support.

MBOT Grid, advanced inventory reports, and advanced control layers are not the main scope of Flow. It is better for simpler, more controlled live grid usage.

Pro adds MBOT Grid Engine, Inventory Risk Engine, Portfolio Roles, staged exit plans, Backtesting, and Bull Signals on top of Standard Grid access.

A Pro user can select either Standard Grid or MBOT Grid, but only one engine can be active at a time. The inactive engine's controls are disabled to prevent conflict.

Prime is for users who want the broadest MBOT Grid control stack. It includes MBOT Grid Engine, advanced inventory reports, rebalance risk report, custom Telegram bot, Prime analytics, and priority support.

Prime is not only about more features; it is intended to provide deeper reporting, higher operational priority, and more professional risk visibility.

Package features are managed through admin package and feature-gate settings. The live system decides available features from the active subscription and current admin configuration.

If a dashboard feature appears locked, the usual reasons are plan scope, payment state, live access controls, or a feature gate disabled by admin.

Referral Engine is MBOT's referral growth system. It lets users invite new subscribers with a personal referral link and earn XP when those users activate a qualifying subscription.

The goal is not a one-sided commission loop. It creates value for both sides: the invited user gets a better starting offer, and the referrer earns XP inside MBOT.

A signup alone is not enough. The invited user must activate a subscription and the payment must be verified.

After payment, XP can appear as pending or available depending on the current rules. Abuse checks, early-cancel windows, and payment status determine when XP becomes usable.

The invited user can receive a discount, starter XP, or another campaign offer depending on the active referral configuration.

These values can change by campaign, plan, and duration. The purpose is to reduce the first-step friction for a legitimate new MBOT user.

XP can be used for MBOT subscription benefits such as unlocking a free month when the required threshold is reached. The Referral Engine progress bar shows how close you are to that target.

XP is not cash, investment return, or guaranteed profit. It is a product credit mechanism inside MBOT.

The system is designed to support scalable sharing under normal use. However, self-referrals, repeated payment methods, fraud signals, chargebacks, and early-cancel abuse are blocked or reviewed.

If abuse is detected, the related XP can be cancelled or clawed back from the balance.

If an early cancellation, refund, chargeback, or fraud signal appears, XP earned from that referral can be reversed.

This is why Referral Engine separates available XP from pending XP. Available XP reflects rewards that passed the required checks.

Viral Engine is MBOT's XP-powered community growth system. A user starts an XP Boost for X or TikTok content; other users complete the selected actions, submit proof, and earn XP from the boost budget.

It is not a fake-follower tool or a guarantee of virality. Its purpose is to help real MBOT-related content get more visibility inside the community while keeping XP useful inside the product.

Available XP earned through Referral Engine can be used as Viral Engine boost budget. This lets users spend referral XP not only on subscription benefits, but also on growing their own MBOT content.

When a boost starts, XP is locked into the boost budget. Accepted task submissions pay participants from that budget; unused XP is returned when the boost closes.

The first scope focuses on X and TikTok. X tasks can include replies, quotes, or original posts about MBOT. TikTok tasks can include short clips or video posts.

MBOT profit-card sharing is not part of the paid task marketplace. It is a separate product action; if XP is awarded for it, the reward should stay small and automatic instead of requiring users to create tasks for it.

In Viral Engine, choose the platform, paste the target X/TikTok link, add a title and optional description, set the duration, and select which actions should earn XP. The system calculates the total XP budget from reward values and participant limits.

After the boost starts, that XP is reserved from the available balance. As participants submit accepted proof, XP is distributed from the reserved budget.

Each task has a reward XP value and a maximum participant limit. For example, a task that pays 50 XP to 5 participants requires a 250 XP budget.

If a boost expires or is closed, undistributed XP is refunded. Distributed XP is not normally returned, but fraudulent, invalid, or abusive submissions can be rejected or reversed.

Viral Engine reviews several signals together: whether the target link belongs to the selected platform, the user's social account information, the boost proof code, the submitted proof URL, and duplicate or abuse patterns.

Participants are expected to submit clear, reviewable proof. If the proof URL, post text, or proof code does not match the boost requirements, the submission can be reviewed, rejected, or reversed in abuse cases.

Adding a social account helps MBOT understand that tasks are being performed from the user's own X or TikTok identity. The system generates a proof code that can be placed in a profile, post text, or verification proof.

Verified accounts reduce fraud risk. Repeated proof links, duplicated accounts, self-participation, or suspicious behavior can be blocked.

No. Viral Engine is designed to block self-participation. The goal is not to move XP from a user back to the same user, but to create real community engagement around MBOT content.

Same tenant, same user, repeated proof links, duplicate social accounts, or suspicious submission patterns can cause a task to be rejected.

No. Viral Engine does not guarantee views, followers, sales, subscriptions, or virality. It only provides a proof-based XP task system for MBOT users.

Content quality, market timing, platform algorithms, account trust, and posting context all affect the final result.

MBOT needs spot trading permission. Withdrawal permission must not be enabled. API keys with withdrawal permission are not acceptable from a security perspective.

Enable only the permissions required for trading, and add the MBOT outbound IP 145.223.99.186 in the Binance API IP restriction field.

On Binance web, open the profile menu in the top-right corner and go to API Management. On mobile, open the profile area and look for API Management or More > API Management. Menu names can vary slightly by region and app version.

After creating the key, open API Settings in the MBOT dashboard, choose testnet or live, enter the API key and secret, and run Validate.

• Enable spot trading permission on Binance.
• Keep withdrawal permission disabled.
• Add the MBOT outbound IP 145.223.99.186 to the Binance API IP restriction field.
• Store the API secret safely; Binance shows it only once.
• Do not start live mode until MBOT shows validation_status=valid and can_trade=true.

No, not when your API key is configured correctly. MBOT's security model is designed around trade-only API access.

Users must keep withdrawal permission disabled in Binance.

The API secret is sensitive and must be stored encrypted. Do not share it, expose it in screenshots, or reuse old keys unnecessarily.

Deleting invalid or disabled API records from the dashboard reduces operational confusion.

validation_status shows whether the API key was validated. can_trade shows whether the bot is allowed to send trade orders with that key.

For live trading, validation_status should be valid and can_trade should be true. Otherwise the bot may appear live but still be unable to trade.

MBOT opens live access through admin-controlled gates. Platform settings can require 2FA before adding a Live API key or selecting Live bot mode.

They can also require that a Live Binance API key already exists and has been validated before Live mode can be selected. In that setup, the Live option becomes available only when 2FA is enabled, a Live API exists, and validation_status=valid / can_trade=true.

• Testnet remains separate; when the platform is in Live mode, users can still use testnet API and testnet bot flows.
• Withdrawal permission is never accepted and should not be relaxed by plan or admin configuration.
• If Live mode is blocked because the API is not validated, open API Settings, choose the Live environment, and run Validate first.

The bot may not place orders, read balances, or run normally. Use validate, disable, or delete actions in API Settings to manage records.

Invalid records should be removed and replaced with correctly configured keys for the selected environment.

The main dashboard summarizes bot balance, total balance, active trade count, USDT state, market indicators, open positions, profit chart, and inventory risk.

It is the decision screen. Detailed edits belong in the related sub-pages.

The Cryptocurrency table shows watched coins, prices, signal state, and available actions. The view icon opens coin-specific details.

It is the first place to check which coins are candidates and which are blocked.

This section shows open spot positions, entry price, current price, target sell, unrealized PnL, and exit tracking state.

Positions closest to exit are usually those with the lowest current loss percentage or closest target sell distance.

The profit chart visualizes closed trade results and daily performance. Unrealized PnL on open positions must be evaluated separately from realized P/L.

Realized P/L includes only closed trades. Open bag positions are not realized profit until sold.

Bull Signals tracks candidate markets, scores, and possible opportunities. A signal is not a direct order guarantee.

The bot can trade only when signal, risk, inventory, budget, and API conditions are all valid.

System Logs show why the bot did not trade, which protection blocked an action, API failures, and runtime events.

When the bot is live but not opening trades, this is one of the first pages to inspect.

A portfolio role tells the bot how to treat a coin. Managed means bot-managed, Exit Only means no new buys and exit tracking only, and Hold means manually monitored.

Wrong role selection can make the bot trade unexpectedly or ignore a position.

Use Exit Only when you want to keep an existing position but prevent new buys. The bot should track exit logic without adding risk.

This is important for bag management because the goal is to exit without increasing exposure.

Cost can come from trades, exchange_trades, or manual values. If the same coin was bought and sold before, the system must isolate the current open position cost correctly.

If Binance and MBOT cost differ, review open position history and exchange trade matching.

A staged sell plan uses TP1, TP2, TP3, and similar levels with target prices and percentages. When price reaches a level, the bot attempts to sell the configured amount.

A final TP marked as last means the remaining free balance should be sold at that level. When a staged plan is active, the single target price and percentage target are disabled.

Profit is realized only when a sell order fills and the closing trade is recorded.

A limit order that is placed but not filled still leaves the position open.

A bag is an open position left after a grid buy when price does not return to the sell level. Temporary bags are normal in grid systems; uncontrolled bag value and age are the real risk.

MBOT makes this risk visible through open bag/exit value, ratio, oldest bag age, and global inventory mode.

Global Inventory Mode shows overall risk based on open bag and exit value. GREEN is normal, YELLOW is caution, and RED means stricter protection on new buys.

This makes the bot consider both opportunity and carried risk.

When open bag/exit value reaches the configured percentage of bot balance, new grid buys are blocked. Existing positions and existing sell orders are not touched.

The goal is to prevent new risk while bags are already high. This is the first risk-control layer without selling at a loss.

This engine monitors bag positions by age, cost, target price, and current price. If a position is above the profit buffer or reaches fee-inclusive breakeven, it can be marked as an exit candidate.

It does not execute loss-making market sells. The priority is to clear profitable or no-loss positions with limit sell orders.

Profit candidate auto limit sell targets older bag positions that are above the configured profit buffer and places post-only limit sells.

Breakeven candidate auto limit sell targets positions that can close at no-loss after fees. Both avoid market sells and loss-making sells.

Rebalance should not be treated as a simple grid refresh. Carried inventory value, bag_rebalance_count, and whether risk increased or decreased after rebalance must be tracked.

These metrics show whether the bot reduced risk or only rebuilt levels while carrying bags.

Standard Grid is the more controlled classic grid engine. It is shaped by signal gates, regime gates, Standard Grid settings, Smart Grid layers, and the general Inventory Risk Engine controls.

MBOT Grid is a separate engine with its own budget, levels, symbols, volatility rules, and settings page. It runs independently from Standard Grid behavior and is managed from MBOT Grid-specific settings.

MBOT Grid can be preferred when the user wants a more active grid structure, its own investment amount, its own level logic, and a separate engine path that is not directly overridden by Standard Grid bag locks.

It is better for users who want more control, faster grid cycling, and MBOT Grid-specific inventory/risk visibility. It also requires closer monitoring and correct budget configuration.

Binance Grid Bot can be enough when you only need a simple grid to run on the exchange. MBOT is different because it is not just a grid launcher; it brings bot capital, manual reserve, per-token caps, active coin limits, signal gates, regime gates, inventory risk, bag age, open bag value, breakeven/profit candidate tracking, and runtime visibility into one dashboard.

MBOT treats grid trading as an operated system, not a one-off order tool. The user can see which capital is allowed, when new BUYs are locked, which positions are approaching profit or breakeven, and why the bot is waiting instead of guessing from exchange orders alone.

So MBOT is not positioned as a promise of higher profit than Binance Grid. It is built for users who want more control, clearer risk visibility, testnet-first onboarding, package-gated advanced modules, and a monitored bot workflow.

• Binance Grid: fast setup and simple grid execution.
• MBOT: grid + capital limits + inventory risk + bag tracking + signal gates + runtime monitoring.
• MBOT does not guarantee profit; it makes grid operation easier to understand, control, and monitor.

Standard Grid is better for simpler, more conservative usage with stricter general risk gates. require_signal, regime gate, reserve, and bag lock behavior are designed to make new BUY behavior more controlled.

It is a better first choice when the user wants lower complexity, clearer controls, or a more cautious grid setup.

No. In the first version, the user can select only one grid engine at a time: Standard Grid or MBOT Grid. The selection is made from the STANDART / MBOT switch inside Capital & Asset Management.

When one engine is selected, the other engine's controls and runtime path are disabled. This prevents two engines from opening orders on the same symbol and mixing position management.

No. Total Balance is the overall exchange account value. Bot Balance is the capital the bot is allowed to use.

This distinction matters because the bot should not automatically use the full account value.

Manual Reserve Mode lets you dynamically set how much USDT should stay outside bot usage. Higher reserve means less capital available for new trades.

This must stay configurable from Bot Settings, not hardcoded.

A per-token cap limits how much risk can be allocated to a single coin. Lower caps allow more coins but smaller trade profit. Higher caps create fewer but larger trades.

Evaluate it together with max active coins and bot capital.

More grid levels create smaller and more frequent orders. Fewer levels create wider, less frequent orders with potentially more meaningful profit per cycle.

Very small orders can be consumed by fee and spread, so level count must be balanced with minimum order size and per-token cap.

Equal spacing distributes levels evenly by price or percentage. Logarithmic spacing can fit percentage-based price movement better.

For volatile and wider ranges, logarithmic spacing may be more balanced. Final choice should come from testing, backtesting, and market regime.

require_signal allows new grids only when entry conditions exist. regime gate restricts new BUYs when market conditions are not range-friendly.

Together, they reduce the chance of opening grids near local tops or inside strong trend markets.

Crash Circuit Breaker is a separate safety module that stops the bot from adding new risk when the market deteriorates sharply within seconds or minutes. It evaluates BTC 1m/5m drops, broad market red ratio, hard-dump breadth, liquidity/spread deterioration, and cooldown rules together.

The default behavior is not a loss-making sell. The module first locks new BUY entries and cancels open BUY orders so the bot does not keep accumulating assets during a fast drop. Existing positions and sell orders are preserved.

Crash mode can trigger when BTC drops beyond configured short-term thresholds, a large share of liquid USDT pairs turns red at the same time, hard-dump breadth rises, or spread/liquidity deteriorates.

These thresholds are managed under Market Risk Shield settings. Even after the signal clears, the system can keep new BUYs locked until the configured cooldown expires.

• BTC Panic 1m / 5m thresholds track sudden BTC drops.
• Market Red Ratio and Hard Dump Ratio track correlated market crashes.
• Average Max Spread tracks liquidity deterioration.
• Risk Cooldown defines how long new entries stay locked.

No. The default and recommended mode pauses new entries and cancels open BUY orders without executing loss-making market sells.

Emergency loss-cut behavior is a separate explicit setting. Only if the user or admin enables force market exit can the system move into an emergency close-all scenario. That option is high risk and should stay disabled for normal use.

This module is a global market safety layer. It can block new BUY entries whether Standard Grid or MBOT Grid is selected. The goal is to prevent new exposure during a market crash, independent of the active engine.

Existing SELL orders and exit tracking normally continue. If the market recovers, positions can still close through target sell or breakeven logic.

If enabled, the lock placed by Crash Circuit Breaker can be removed after the risk signal clears and cooldown expires.

This automatic resume behavior should not override a manual 'Pause Buys' decision. A manually paused bot should not restart aggressive buying only because market risk returned to normal.

Backtesting shows how selected settings might have behaved on historical data. Monte Carlo tests whether the results remain stable under different orderings and variations.

Use it to compare parameters before going live.

No. Backtesting uses historical data. Live markets include spread, slippage, fill quality, API latency, and regime changes.

Even good backtests should move through testnet or low-budget micro live before full live usage.

Shadow tests measure strategy signals and exits without sending real orders. Clean Cycle, Cross-Pair Lag, and Volatility Harvest can be evaluated this way.

Strategies should not move live before enough shadow data exists.

Readiness is the minimum data and quality threshold before a strategy can be considered for live use. It includes completed count, avg/median net PnL, win rate, clean close, and stuck position count.

Low readiness means the strategy should not be tested with real capital.

Some reports are written after background tests or calculations finish. A page can look empty immediately after refresh and then populate later.

For long tests, compare report timestamps with System Logs.

MBOT can send runtime start/stop events, errors, critical risk alerts, trade events, exit tracking updates, and system warnings.

Exact coverage depends on plan, settings, and connected Telegram destination.

When bot token, chat ID, and topic ID are configured correctly, MBOT sends events to the selected Telegram chat.

Critical notifications from the main bot can also be routed to the MBOT topic inside the community group.

Open the official BotFather bot in Telegram and use /newbot. BotFather asks for a display name and username, then returns an HTTP API token. Add that token to MBOT Telegram settings.

To send alerts to a group or channel, add the bot to that destination and give it permission to post messages. If the group uses forum topics, create an MBOT topic and save the topic ID as well.

• BotFather > /newbot > bot name > bot username.
• Keep the BotFather token private.
• Add the bot to your Telegram group or channel with posting permission.
• Send a test message and use Telegram getUpdates or a trusted chat ID helper bot to read chat.id.
• For topic-based groups, post inside the MBOT topic and capture message_thread_id.
• Enter bot token, chat ID, and optional topic ID in MBOT Notifications, then send a test notification.

Check bot token, chat ID, topic ID, and the Telegram bot permissions in the group. Then inspect System Logs for send failures.

For topic-based groups, an incorrect message_thread_id can make messages land in the wrong place or not appear as expected.

In active grid systems, every small trade can create too much noise. Critical events, risk mode changes, API failures, and large position alerts are usually more useful.

The demo site lets users inspect the MBOT interface and core flow without real money risk. It should be readonly, with no real orders or permanent user-side changes.

Testnet lets users try bot behavior and dashboard flow without real funds. Testnet balance should be dynamically configurable and separate from live Binance balance.

Testnet results do not perfectly represent live spread and liquidity behavior.

Testnet testing does not use real crypto funds. Required testnet USDT or supported test tokens should be claimed from the Faucet inside your XPayr account.

On the XPayr Faucet page, select the test network, connect your wallet, optionally add the token to the wallet, and request tokens. Faucet link: https://xpayr.com/merchant/faucet

The sidebar or dashboard shows live/stopped state. Runtime status, API validation, bot mode, and is_running should be checked together.

Live status alone does not guarantee new trades. Risk shield, inventory lock, signal gate, or budget conditions can still block entries.

Testnet is a testing environment. Some protections can be relaxed to make testing possible. Live mode should keep risk shield and inventory settings strict.

2FA should be enabled, a Live Binance API key should be added, the Live API should be valid, can_trade should be true, withdrawal permission should be disabled, bot balance and reserve should be correct, max coins and per-token cap should be reviewed, Inventory Risk Engine should be active, and System Logs should be clean.

If admin live access controls are enabled, Live bot mode will remain unavailable until these requirements are complete. That is intentional and protects live funds.

There is currently no separate App Store or Google Play mobile app. MBOT is designed to be fully responsive and mobile-friendly.

You can use MBOT like an app by adding the site to your phone home screen.

• iPhone/Safari: open MBOT, tap Share, then Add to Home Screen.
• Android/Chrome: open MBOT, tap the top-right menu, then Add to Home screen or Install app.
• The icon opens MBOT like an app, while still using the browser/PWA behavior underneath.

There can be many correct reasons: invalid API, can_trade false, insufficient USDT after reserve, max coin limit reached, require_signal not satisfied, or inventory BUY lock active.

Check System Logs, API Settings, Bot Settings, Inventory Risk Engine, and Bull Signals together.

Total balance, bot balance, available USDT, open position value, and invested value are different concepts. Open positions and locked orders can reduce available USDT.

In testnet, displayed balance can be simulated or user-configured. In live mode, exchange data should be the source of truth.

Daily bot profit usually reflects realized profit from closed trades. Balance includes more than closed trades; it also includes the current market value of tokens still held in open positions. The bot may close several small profitable cycles during the day, while tokens that remain open lose more market value.

That does not mean the bot lost money on those closed trades. The usual reason is that tokens bought by the bot dropped before returning to their sell targets. Realized daily profit can be positive, while total account value still falls because open token inventory is marked at a lower market price.

The distinction matters: realized profit is the result of completed buy-sell cycles; total balance change also includes unrealized movement on open token inventory. That is why MBOT separates bags, open positions, inventory risk, and breakeven/profit candidates from the daily realized profit number.

• Bot profit: realized P/L from closed trades.
• Total balance: USDT plus the current market value of open token holdings.
• A falling balance is often caused by token price decline, not by a losing closed bot trade.
• Until the token is sold, this is unrealized value movement; it still needs risk monitoring.

Language should follow both URL and saved preference. `/tr` should show Turkish and `/en` should show English.

When switching language, the URL should change too. Updating only the dropdown text is not enough.

MBOT dashboard tables should become card-like or stack columns on mobile. Horizontal scrolling should be used only when dense data makes it unavoidable.

Portfolio Roles, Spot Plans, Profits, Bull Signals, Backtesting, and System Logs should be responsive.

Pause new BUYs or pause the bot first. Analyze the situation without touching current positions and sell orders unnecessarily.

Closing positions or canceling orders can be risky. Loss-making sells should not be automated unless explicitly enabled by the user.