Automate the ATF Telegram Mini App with Node.js and Telethon Sessions

What ATF Bot Automation v2 Does

ATF Bot Automation v2 is a Node.js bot that interacts with the ATF Telegram Mini App through active Telethon SQLite session files. Instead of saving Telegram.WebApp.initData in a static query file, it requests a new Telegram WebView during every cycle and uses the fresh initialization data returned by Telegram.

The bot supports multiple accounts and can manage ATF login, TON wallet creation and verification, mining claims, dynamic tasks, referral registration, account statistics, wallet replacement, and ATF withdrawal. It scans the session directory again on every cycle, so newly added accounts can be discovered without changing the source code.

Key Features

• Fresh Telegram WebView and Mini App initialization data for every cycle.
• Read-only access to Telethon SQLite session databases, with the authentication key copied temporarily into memory.
• Automatic creation of real TON v4r2 mainnet wallet addresses.
• TON Proof signing and wallet verification through the ATF sync_wallet endpoint.
• Queued wallet workers for accounts receiving temporary busy or cached/deduplicated responses.
• Dynamic task discovery by parsing the ATF frontend configuration with Acorn without using eval.
• Independent task workers and onboarding state for each session.
• Referral registration through Telegram messages.StartBot, including Turnstile handling.
• Per-account HTTP or HTTPS proxy configuration for ATF requests.
• A Textual dashboard for live automation and a separate read-only statistics dashboard.
• Sequential withdrawals with balance checks, image CAPTCHA solving, proxy rotation, and withdrawal history reporting.
• Stable request IDs, controlled retries, graceful shutdown, and sensitive-value filtering in logs.

Requirements

Prepare the following before installing the project:

• Node.js 22.5 or newer.
• Your own Telegram API ID and API hash from https://my.telegram.org/apps.
• At least one active Telethon SQLite session file ending in .session.
• Python 3 if you want to use the Textual dashboard or the local Turnstile solver.

Security warning: Never share your Telegram API hash, Telethon session files, proxy credentials, .env, or wallets-accounts.json. The wallet file contains plaintext mnemonics and private keys that provide complete control over every wallet stored in it.

Install and Configure the Bot

1. Install Node.js dependencies

Open PowerShell in the project root and install the packages:

npm install
Copy-Item .env.example .env

2. Add Telegram API credentials

Edit .env and enter the credentials issued for your Telegram application:

TELEGRAM_API_ID=12345678
TELEGRAM_API_HASH=your_api_hash

These credentials must belong to you. Do not commit the completed environment file to version control.

3. Add Telethon sessions

Place all active SQLite session files in the session directory. The filename becomes the account label shown by the bot.

session/
├── account1.session
├── account2.session
└── account3.session

The directory is scanned on each cycle. Session databases are opened read-only, and access to the same account session is queued to prevent concurrent operations from colliding.

4. Optionally install the Textual dashboard

The main automation option can display a navy, violet, and coral Textual dashboard. Install its Python dependencies once:

python -m pip install -r requirements-textual.txt

If Python is installed in a nonstandard location, set ATF_PYTHON to the complete path of python.exe.

Run the Bot

Start the interactive menu with:

npm start

The menu provides these workflows:

[1] Run BOT
[2] Register accounts with referral code
[3] Replace TON wallet
[4] Check account statistics
[5] Withdraw ATF
[0] Exit

Run the main automation

Select option 1 to start the Node.js workers with the Textual dashboard. The dashboard reports Telegram usernames, levels, mined ATF, ATF holdings, pending rewards, wallet state, mining status, task claims, task countdowns, referral results, Team Wallet details, connections, and cycle summaries.

Useful dashboard controls include:

• q: stop gracefully and exit.
• p: pause or resume workers.
• r: refresh statistics for all accounts in parallel.
• c: clear the log panel.
• PgUp and PgDn: scroll through logs.
• g and Shift+G: move to the start or end of the log.

The dashboard automatically refreshes account state according to dashboard_refresh_interval_minutes, whose default value is 10 minutes. To launch it directly, use:

npm run dashboard

For standard terminal logs without Textual, run:

npm run start:run

This command is also the appropriate entry point for schedulers and non-interactive processes.

How TON Wallet Setup Works

After an account logs in, the bot checks the ATF server fields wallet_address and wallet_verified. If no verified wallet exists, it follows this sequence:

1. Creates a TON v4r2 wallet for mainnet.
2. Immediately stores its address, 24-word mnemonic, and private key in wallets-accounts.json.
3. Requests the official TON Proof payload from ATF.
4. Signs the proof for the ATF WebApp domain.
5. Submits the proof to sync_wallet.
6. Continues to the security question and mining only after verification succeeds.

The wallet record is written before verification begins. Therefore, a temporary busy response or a deferred account does not cause a newly generated wallet to be lost.

If ATF returns busy or a cached/deduplicated response while the wallet remains unverified, the main process retries once after wallet_busy_retry_seconds, which defaults to 15 seconds. If the account is still busy, it is moved to a wallet worker so the main process can continue.

Up to wallet_worker_concurrency wallet jobs run in parallel, with a default of 10. Additional accounts enter a FIFO queue. Only one active or queued wallet worker is allowed for each session.

The generated wallet is a real wallet address, but it is not deployed on-chain until it is used for an on-chain transaction. Store wallets-accounts.json securely and back it up carefully. Anyone with this file can control the wallets.

Older records containing encrypted_secrets are migrated to the plaintext format when the bot first opens them. The former WALLET_KEYSTORE_PASSWORD is needed only for that migration.

Configure Referral Registration

Add a referral code to config.json when you want option 2 to register new accounts:

{
  "referral_code": "610911604"
}

For each session not previously processed with that code, the bot calls Telegram messages.StartBot, opens the WebView using the same start parameter, and sends ref_code during ATF login. A successful result is recorded as a hash in .state/referrals.json, preventing the same StartBot action from being repeated every cycle.

Referral mode only handles referral registration. Wallet creation and storage remain part of the main automation under option 1. Existing accounts generally cannot replace an inviter already recorded by the server.

Run referral registration directly without the interactive menu with:

npm run register-referral

Use MultiBot for Turnstile

If a new account receives a Cloudflare Turnstile challenge, the bot can obtain the official site_key from ATF and request a token from MultiBot. Add its API key to .env:

MULTIBOT_API_KEY=your_api_key

Account proxies are not sent to MultiBot by default. If solving must use the same proxy IP, enable:

MULTIBOT_USE_ACCOUNT_PROXY=1

Enabling this setting sends the account proxy address and credentials to MultiBot. Consider that exposure before using the option.

Run the local Turnstile solver

The included local solver binds only to 127.0.0.1:8000. On Windows, install Python 3 and prepare the solver from the project root:

py -3 -m venv local-solver\.venv
local-solver\.venv\Scripts\python.exe -m pip install -r local-solver\requirements.txt
local-solver\.venv\Scripts\python.exe -m camoufox fetch
cd local-solver
.venv\Scripts\python.exe api_server.py --yes

Keep that terminal open. In another terminal, run the bot, select option 2, and choose the local solver. For non-interactive execution, configure:

TURNSTILE_SOLVER=local
LOCAL_TURNSTILE_SOLVER_URL=http://127.0.0.1:8000

Apply Per-Account Overrides

Copy account-overrides.example.json to account-overrides.json when individual sessions need different settings. For example:

{
  "account1.session": {
    "enabled": true,
    "proxy": "http://username:password@127.0.0.1:8080",
    "ready_task_ids": ["telegram_join"]
  }
}

• enabled activates or disables the session.
• proxy sets an HTTP or HTTPS proxy for ATF requests. Telegram MTProto remains a direct connection.
• ready_task_ids identifies one-time tasks that were genuinely completed manually and may now be claimed by the bot.

The override file, proxies, environment file, cache, state, and session files are ignored by Git.

Configure Dynamic Tasks

ATF does not expose a task-list endpoint. Instead, its frontend includes tasksConfig as inline JavaScript in index.html. The bot downloads that page and parses its abstract syntax tree with Acorn, without executing the code. It extracts only task IDs, titles, rewards, links, cooldowns, minimum durations, and manual-review status.

If the page cannot be loaded, the bot uses the latest cache. If neither the frontend nor a cache is available, task claims are disabled for that cycle rather than using a hard-coded fallback.

Set the task mode in config.json to one of these values:

• off: do not read or process tasks.
• report: display available tasks without starting or claiming them.
• claim_ready: register link clicks with start_task, start eligible tasks, wait for each minSeconds period in parallel, and claim tasks when ready.

Tasks listed in ready_task_ids enter the claim queue without being started again. After sequential initial login, every account receives an independent task worker. The worker sleeps until that account's cooldown expires, reloads server state, processes ready tasks, and schedules its next run from the latest response.

If a ready task cannot be started or claimed, retries are limited by task_ready_retry_seconds, which defaults to 60 seconds. This prevents a tight retry loop. The loop_interval_hours setting applies only to mining-claim cycles, not task scheduling.

Replace a TON Wallet Safely

Select option 3, or run npm run replace-wallets from an interactive terminal, to scan sessions for wallets that may need replacement. Accounts already containing a valid mnemonic and private key in wallets-accounts.json are skipped.

For verified wallets without local secrets, the bot cannot determine whether the wallet came from an older bot installation whose backup was lost or from an external wallet. It therefore shows the username and masked address and asks for confirmation per account:

• Enter y to replace the wallet.
• Press Enter or n to skip it.
• Enter q to cancel the remaining scan.

After approval, the new wallet and mnemonic are saved before ATF is updated atomically through sync_wallet and TON Proof. On-chain assets in the previous wallet are not transferred. Busy replacements are stored as replacement_pending and retried by up to five workers after the scan. Interrupted replacements can be resumed by running option 3 again.

Audit Account Statistics

Option 4, or npm run stats, opens a read-only audit dashboard. It performs a fresh login, calls sync_wallet, and reads get_withdraw_history. Concurrency is controlled by stats_worker_concurrency and capped at five workers.

The dashboard displays usernames, wallet addresses, ATF holdings, mined balances, ban state, risk score, qualified DEX purchase status, pending withdrawals, the latest withdrawal status, and FRAUD MASK from masked_auto_fraud. Withdrawal states include NONE, PENDING, APPROVED, KYC/VERIFY, FAILED, and UNAVAILABLE. KYC status and the fraud mask are separate signals.

Press r to run the audit again or q to exit.

Withdraw ATF

Option 5 processes accounts sequentially and asks for one confirmation before starting because the server charges 70 ATF for each withdrawal request.

For each account, the bot:

1. Logs in with a new session and reads mined_balance and pending_reward.
2. Claims any pending reward.
3. Logs in again to refresh the mined balance.
4. Skips the account if its balance is below 500 ATF or its wallet is not verified.
5. Rounds the full eligible mined balance down to four decimal places.
6. Solves the image CAPTCHA and submits the withdrawal.
7. Reads withdrawal history and reports the final available status.

Add a 2Captcha key to .env for the ImageToTextTask solver:

TWOCAPTCHA_API_KEY=your_api_key

The bot applies the frontend's official 1.2-to-2-second jitter before submission. Failed or rejected CAPTCHA answers cause a new challenge to be requested, up to the lower of withdraw_captcha_max_attempts, whose maximum is three, and the server's attempts_left.

A retry_after_seconds response, withdrawal lock, or exhaustion of server attempts stops retries for that account. Run withdrawal directly with:

npm run withdraw

Use proxies for withdrawals

If proxy.txt or proxies.txt contains proxies, withdrawal mode creates a unique pool for the entire batch. Each proxy can be selected only once, even if it fails, and is never reassigned to another account during that batch.

A network error during login, reward claim, balance refresh, CAPTCHA retrieval, submission, or history retrieval rotates the account to the next unused healthy proxy. When a proxy pool exists, withdrawal does not silently fall back to the direct IP. Claim and withdrawal request IDs remain unchanged during rotation to reduce the risk of duplicate actions.

Provide at least one unique proxy per account plus additional proxies for retries. If the pool is exhausted, the current account fails and processing continues with the next account.

Advanced Reliability and Security Tips

• Keep wallets-accounts.json outside shared or synchronized locations unless the storage is appropriately protected.
• Back up wallet secrets securely before replacing wallets or moving the installation.
• Use ready_task_ids only for tasks that were actually completed manually.
• Remember that an account proxy affects ATF HTTP requests, not the direct Telegram MTProto connection.
• Configure enough distinct withdrawal proxies because used and failed proxies are not recycled within a batch.
• Use Ctrl+C for graceful shutdown. The bot cleans up connections and does not start another account after receiving the shutdown signal.
• Review the per-account summary, which distinguishes success, partial, and failed results.

The project restricts API and WebApp destinations through allowed_hosts and requires HTTPS. It does not automatically follow HTTP redirects. HTTP 401 and 403 responses are not retried, while HTTP 429 and 5xx responses use exponential backoff with jitter.

Request IDs remain stable across retries so the server can treat repeated actions idempotently. Business responses such as cooldowns and already claimed are not treated as network failures. Proxies that repeatedly fail during ATF login are temporarily quarantined, and the bot does not silently switch to the direct IP.

Session tokens, initialization data, hashes, and proxy passwords are redacted from logs. Stable device IDs are stored per Telegram ID in .state/device-ids.json. The bot also reloads config.json, sessions, proxies, and account overrides each cycle.

When mining requires a security question, recognized basic arithmetic is solved automatically. Unknown formats fall back to manual terminal input.

Validate the Installation

Run the project's checks and tests after setup or configuration changes:

npm run check
npm test

Conclusion

ATF Bot Automation v2 combines fresh Telegram WebView authentication with multi-account ATF automation, TON wallet verification, dynamic tasks, referrals, account auditing, and controlled withdrawals. Start with valid Telethon sessions and protected Telegram credentials, verify the main workflow with a small number of accounts, and treat wallets-accounts.json as a high-value secret because it contains direct access to every generated wallet.