DEXBOT EN

🖥️ Added a first-time setup wizard with clear step-by-step instructions explaining the features. 🛠 Token setup has been moved to the main menu for convenience, and access to token setup is still available in each Bot. 💎 Added a support menu. If anyone would like to leave a thank you, we welcome any donation. 🆘 Changed the technical support menu. You can now create a separate ticket, go to the Telegram group, and also enable the first-time setup wizard.

Previously, the bot's master password, randomly generated for each user, was used to encrypt the secret key or seed phrase. Now, we've implemented YOUR personal password on top of it, which only YOU set. How it works: The seed phrase or secret key is encrypted with the master key and, additionally, YOUR personal password. The password itself is never stored on disk. Only an irreversible hash fingerprint of the password with a random salt is stored in the database—it's impossible to restore the original. If an attacker steals both the master password and the database, it's fundamentally impossible to decrypt the keys without your personal password. Convenience: You enter your personal password once per session. When adding other wallets, the bot doesn't ask for it again until the vault is empty. Remains unlocked. 📧 Confirmation codes — no chance of guessing After 5 incorrect attempts to enter the code, access is blocked for 15 minutes. Guessing the code in 5 tries? Impossible. The code itself is not written to the logs — even if the logs are stolen, no one will see the numbers. When resending, the code is not duplicated, eliminating confusion. 🕵️ Logs and email — completely masked All administrator email addresses in the logs now look like this: v*****@gmail.com. Your real email address won't even appear in service records. 🧅 TOR — neat, without side effects Previously, when restarting TOR, the bot could accidentally terminate other processes. Now, the pkill -x tor command is used — only TOR itself, and nothing else. ⚙️ Assembly and internals — flawless Added the bip-utils library — wallet cryptography is now correct It's packaged into a bundle, so nothing gets lost. As a reminder, the .env file must have 600 permissions, and the bot itself must be run under a separate user. Administrators in Telegram must be whitelisted. 🚀 Stability, Performance, and Solana Experience We've not only strengthened security but also optimized the code. The bot has become more stable—it crashes less frequently in unexpected places. CPU and RAM consumption have been reduced, making it faster and easier to use even on low-end servers. Solana network integration has been updated: migration to the latest Jupiter APIs ensures accurate retrieval of prices, routes, and swap execution in accordance with the latest protocol changes. 🔒 Result: Complete protection of your keys Even if an attacker: learns your server's IP address, gains administrative access to it, steals all bot files, and selects Master Password — They won't be able to decrypt your seed phrases and secret keys without your personal password, which never leaves the process's memory. And attempts to guess the confirmation code from the email are blocked after five errors. Your funds are protected to the fullest extent.

We've completely redesigned and significantly strengthened the security system for connecting wallets to the bot. When connecting a seed phrase or secret key, the data is instantly encrypted and never stored in plaintext. A special master key is used to decrypt it, which: is also stored encrypted is unique to each bot instance is not transmitted or stored centrally We intentionally don't disclose the technical details and security algorithms, but we will explain in principle how difficult a hacking attempt is. What does this look like in practice? Suppose an attacker is trying to access your wallet. To do this, they need to: Find out which server your bot is running on Get administrator access to this server Find the encrypted data for the seed phrase or secret key Understand the algorithm Encryption used in the system Find and decrypt the unique master key for your bot. Only then attempt to decrypt the seed phrase and gain access to the wallet. In practice, this is virtually impossible. Important to know Each bot uses its own unique key system. As developers, we do not have access to users' master keys. Without direct administrative access to the server, decrypting data is impossible. No one knows which servers the bots are running on—there are millions of active servers worldwide. Results Even in a hypothetical infrastructure hack, an attacker would have to go through a series of extremely complex and unrealistic steps. This makes unauthorized access to wallets virtually impossible. 🔒 The security of your funds is our absolute priority.

Fixed minor bugs with connecting and creating wallets directly from the bot

Fixed minor errors in GRID bot levels, also improved synchronization between GRID and the Trading Bot to avoid balance conflicts when running simultaneously.

We've added a new bot. Now there's a bot that works directly on your wallet without any crypto exchange, using a grid within a specified range or following the price, dynamically changing the grid. The GRID bot can work both separately and in parallel with the main trading bot.

Completely replaced OKX with other aggregators that do not require registration and API keys.

Added checks for zero values when rounding Decimal

Added support for the COSMOS network and the following blockchains: OSMOSIS, KAVA, JUNO, SEI, INJECTIVE Bot installation has been improved and simplified API and wallet management has been added directly from the bot — now you can: • Add keys and wallets; they are automatically encrypted and stored on your server in encrypted form • Deletion requires confirmation via email from the license owner • Create new wallets directly from the bot Sorting has been implemented — activated blockchains, pairs, and indicators are now displayed first Many non-critical bugs have been fixed and overall stability has been improved

Now, during installation, all private keys are automatically encrypted and stored in the .env file in encrypted form. Even if someone gains access to your server, it will be impossible to decrypt the original keys—your data is securely protected at all stages. Furthermore, we've improved the installation script—now installing the bot is even simpler and more intuitive. Even users without technical experience can easily follow all the steps and launch the bot. The algorithm for notifications about unsuccessful transactions has also been updated. Now you'll only receive a message after all retries, and only if the transaction has truly failed—without unnecessary notifications.

Manual selling of positions via the Telegram bot has been reduced from 5% profit to 0.7% to still protect against losses and prevent accidental selling at a loss. This feature remains the same; if the transaction is ≥ 0.7%, a button will be available to sell the position even if the sell indicators are not triggered.

As of September 30, 2025, Jupiter is removing old endpoints - this update migrates to new API endpoints

Translation errors fixed All menu and settings texts are now displayed correctly in all languages. More accurate indicator calculations The system receives sufficient data for analysis and generates more reliable signals. Automatic currency selection for calculations If there is not enough data for USDC, the system automatically uses USDT to ensure that indicators always work reliably. MACD calculation fixed The indicator now calculates values using the classic formula and produces more accurate results. All indicators updated All 20 indicators have been tested, fixed, and are working correctly. Improved reliability and speed The system processes requests faster and continues to operate even if data sources fail.

Added duplicate protection; the bot will no longer initiate a second simultaneous purchase/sale of the same token. Configured smart retry of unsuccessful trades with pauses, limited attempts, and a gradual delay increase. Introduced automatic resaving of missed trades; if the purchase took place online, the entry will appear in the database. Strengthened pre-trade balance checks for the base token/gas and the token being sold. Added buttons to the Telegram menu. Retry Queue - shows pending retry transactions. Retry Statistics - a brief status summary. Improved the stability of database entries; purchases and sales are now correctly reflected in the tables for their respective networks.

Critical errors in price calculations with the position averaging function enabled have been fixed. Now the system correctly calculates the purchase price and works correctly with rounding of numbers. Improved process logging for better diagnostics. Optimized the database from unnecessary requests.

- Fixed a bug with re-selling tokens - Restored correct display of sell signals - Added protection against division by zero in all calculations - Replaced broad exception handling with more specific - Removed unused imports and cleaned up the code - Improved type checks to increase reliability - All tests passed successfully, no syntax errors - The API is fully compatible with previous versions - Improved security due to strict error handling - Improved performance due to the elimination of duplication of operations - Added additional protective checks

Critical Memory Usage: Resolved RAM consumption issue database_manager caches: Size reduced from 1000 → 500 entries, cleanup interval 10 → 5 minutes Indicator caches: Limited to 100 entries with autocleanup when added Autocleanup memory: At critical usage >90% with forced garbage collection Memory: Reduced consumption by ~50%

Logic of disabled indicators: return False → return None (29 files) MACD indicator: Fixed critical errors and duplicated code Documentation: Removed duplicated parameters in 5 indicators Return values: Standardized in SMA/EMA

A bug in the Automatic Sale function has been fixed: previously, when activated, native tokens (WETH, WBNB, etc.) were not sold without an indicator signal. Now the behavior is correct — if Auto Sell is enabled, the token is sold when the take profit or trailing stop conditions are met, even without indicator signals.

1. Added 20 main trading indicators. 2. Implemented logic for working with indicators: Any, All, Selected quantity, Consensus. 3. Indicator settings are distributed by priority: • Highest priority - individually for a pair. • Next - for the entire blockchain. • Lowest priority - basic settings. 3. In additional purchases, 2 strategies have been added: averaging and new purchase. 4. All trading pairs are now configured individually. 5. Added presets for quickly copying settings from one pair to another. 6. Added the INFORMATION button with a detailed description of the functions. 7. Implemented a monitoring panel for monitoring the ``health`` of the system. 8. Added viewing the balance for all blockchains and tokens. 9. Created the Performance section for individual caching and query settings. 10. Added the ability to select native token on the blockchain. 11. Added the ability to set the router address and chains from the Telegram bot settings. 12. Added additional notifications to Telegram. 13. Implemented the ability to disable and customize individual notifications. 14. Implemented a logging system through Telegram settings with the ability to write logs to a file and download them via Telegram. 15. Completely redesigned logging of the main bot. 16. All requests are now executed asynchronously, not sequentially. 17. Added support for batching requests to all APIs. 18. Implemented several alternative data sources for system stability and reducing the load on the API. 19. In the transaction information, the ``Buy`` and ``Sell`` buttons have been added, which redirect to data by transaction hash.

You can now enable a maximum price check and set it for each token. The purchase is made only if the price ≤ the specified value and all other filters are met.

– BUY sent only after confirmation – Added BUY_FAILED and SELL_FAILED notifications – Stop-loss prioritized in selling logic – Fixed Trailing stop and Take Profit – Solana confirmation check before DB insert

– Fixed critical Solana logic issue: trades are now stored only after transaction confirmation. If failed, no DB record is created and BUY_FAILED notification is sent. – Notification improvements: • BUY only after confirmation. • BUY_FAILED on network error or cancellation. – Fixed issue with trades in DB without actual token purchase. – Improved Jupiter API stability. – Added ability to reset device from your account (My Account → My Licenses). – Optimized license sync error protection. – Updated Solana confirmation mechanism for better reliability.

– Improved license verification system: automatic fallback to the backup server has been added if the main server is unavailable. – Improved stability of the Telegram bot during startup and license verification. – Fixed a critical TypeError: 'str' object is not callable error that occurred when starting the Telegram bot. – Removed the localization function overwriting _() when protection is enabled. – The Telegram bot now works correctly with the same license as the main DEXBOT. – Added logic for displaying the activation status: device ID, number of activations, and expiration date. – Added the TRADE_LOOP_DELAY parameter in config.json → TIMEOUTS, which allows you to control the delay between trade processing. – Implemented loop_delay in the _process_single_trade method for flexible speed control. – Removed the unnecessary await asyncio.sleep(0.2) delay between chunks to avoid duplicate braking. – Now all the logic of pauses is centralized and configured via the config without the need to edit the code. – Increased overall productivity

– Improved notification when license expires — now with event_type=``LICENSE``. – Wrapped in try/except watchdog() loop to prevent hangs. – All critical background tasks are now protected from crashes. – Additional check for protection and words like API_KEY, TOKEN, WALLET. – Added initialization of self.failed_tokens to avoid AttributeError.

The FAILED_SELL_RETRY mechanism has been updated. Notifications are sent only under the required conditions. Protection against repeated sending when fail_count >= max

Fixed Telegram notification errors. The sale notification is recorded only upon successful transaction.

Automatic installation script: NGINX, MySQL, Adminer, Restart, security.

Creating a website and setting up an affiliate program.

The Telegram bot now shows active/completed transactions on all blockchains at once.

Displaying the transaction ID, time, quantity, and current price in Telegram.

Pagination, filtering of transactions, statistics. Displaying the RSI, TP, SL and control buttons in the Telegram bot.

Transfer of the Telegram bot to aiomysql and FSM. Modular separation of logic, addition of multilingual localization (40 languages).

A full-time arbitration bot. Support for trailing, TP, SL, profit taking, notifications, and databases.

Protection against simultaneous startup. FastAPI server, MySQL sessions.

Online verification integration. License verification at startup, shutdown if the license is not valid.

Implemented the rotation of the RPC node. Auto-switching and fallback, gas check, caching.

Transferring all configurations (API_KEY, ADMIN_IDS, wallets) to .env. Centralized Telegram notification system.

MySQL connection. Saving transactions, profits, network and platform commissions. Calculation of liquidity and selection of the best pools.

The division of logic into farm.py , farmsol.py , farmokx.py . Putting the general logic in a separate module.

Creating a Telegram bot for management and monitoring.

Integration of the OKX Web3 API for obtaining balance and signing transactions. Using Solana as the main blockchain network.

The launch of the DEXBOT project. Integration with Jupiter and Raydium for price analysis. Configuring the profit filter via the MIN_PROFIT = 0.6 parameter