Trading infrastructure (on your VPS):

• 10 grid algorithms: BTC · ETH · HYPE · SOL · DOGE · LINK ·

SUI · XRP · ADA · BNB

• Volatility stagger ladder (2+1 → 10 active)
• Shared capital pool with compound interest (equal floor)
• Trailing take-profit (no premature sell orders)
• Deep-grid: 5th level on 4/4 fills
• Shared HL cache — reduced load on exchange API
• Self-healing: auto-repair of services every 3 minutes
• Autostart via systemd (24/7, restart on failure)

Telegram bot:

• Notifications for every trade (OPEN / CLOSE)
• Menu: Balance · Report · Info
• Daily PnL report (21:00 Krasnoyarsk)
• Document package: guide, presentation, Grid, pricing

Security:

• Trading on Hyperliquid (decentralized exchange)
• API key for trading only — no withdrawals
• Private key and wallet remain with you
• VPS — your server or a server of your choice

Cost is divided into three parts:

1. ONE-TIME LAUNCH — developer work (turnkey setup)
2. MONTHLY INFRASTRUCTURE — VPS (paid to the provider)
3. MONTHLY SUPPORT — optional (monitoring, updates)

Trading deposit on Hyperliquid — separate; this is your capital for the algorithms (not included in developer pricing).

StormNova runs on a dedicated VPS 24/7. You pay the hosting provider directly — not the developer.

Minimum requirements:

• 1 vCPU, 2 GB RAM, 20 GB SSD
• Linux (Ubuntu 22.04+ / Debian 12+)
• Stable connection, European location (closer to HL API)

Estimated VPS cost:

Provider Plan Price/month

Recommendation: budget $10/month (≈ 900–1,000 ₽) for the server. The developer assists with VPS selection and initial setup as part of the launch plan.

Optional add-ons:

• Reserved IP / backup snapshots +$2–5/month
• Dedicated VPS for client only full plan cost

Hyperliquid (paid from trading turnover):

• Maker fee (limit orders): ~0.01–0.02%
• Taker fee (on slippage): higher
• Funding rate: market-dependent (usually minor)
• Minimum order: from ~$10 USDC per level

Account funding:

• USDC on Hyperliquid — via bridge / exchange (network fee)
• Withdrawal — only from your wallet, at any time

Minimum deposits for comfortable operation:

The larger the deposit — the greater the notional per grid level and the stronger the compound interest effect. Exact figures — in the briefing.

• Bot creation via @BotFather — free
• Notifications and menu — no Telegram subscription fee
• Only your chat_id is needed for binding

All work is done remotely (VPS, Telegram, remote access). No on-site visits.

Optional — StormNova Viewer mobile app: balance and report on iOS and Android, private read-only access to your VPS, no trading control.

Service Price (USD)

Example 1 —"Launch and forget"(STANDARD):

Example 2 —"Try one pair"(START):

First year: ~$419 + deposit

1. Contact @BagateyDI → briefing (pairs, deposit, VPS)
2. Plan agreement (START / STANDARD / PRO)
3. 50% prepayment — reservation of setup slot
4. VPS + HL + Telegram setup (1–3 business days)
5. Test run and demo in the bot
6. Remaining 50% payment — system handover
7. Start of monitoring period (7 or 14 days)

Payment methods: USDT / USDC / bank transfer — confirm with the developer.

• Hyperliquid account funded with USDC
• API wallet (trading agent private key)
• Main wallet address (account address)
• VPS (new or root/SSH access) — or help with ordering
• Telegram chat_id for notifications
• Telegram bot token (created via @BotFather)

The developer will provide a checklist and assist at every step.

The developer guarantees:

• correct installation and launch of the system per plan;
• all services operational at handover;
• delivery of documentation and instructions.

The developer does NOT guarantee:

• trading profit (markets are unpredictable);
• absence of drawdowns and liquidations in extreme markets;
• uninterrupted Hyperliquid API (depends on the exchange).

Trading risks remain with the client. StormNova is a strategy automation tool, not a fixed-income deposit.

Pricing effective from June 2026. The developer may change prices for new clients; for existing clients — terms are locked in at launch.

Questions and launch orders: Telegram @BagateyDI Website: https://StormNova.space

StormNova · StormNova.space

The Grid algorithm is a «buy on pullback + take profit on rally» strategy:

• limit buy orders are placed below the current price;
• on fill, a long position is opened;
• when price rises sufficiently, trailing take-profit is activated;
• exit is via stop-limit (not market), with protection against

closing at a loss;

• after closing, the cycle repeats: the grid anchor is updated.

Architecture has two layers (do not mix them):

1. TRADE SLOTS — 10, as before. Unchanged for the standard setup:

at most 10 concurrent longs; budget pool is split by 10 (equal floor + leader bonuses).

1. ENTRY SEARCH POOL — expandable candidate list. Currently 12 pairs;

resting buys go to the best ATR% among that list (see §2.1). Technically the search pool may be any size (14, 20, …) — limited only by VPS capacity and exchange API rate limits, not by a hard-coded “must be 12” rule.

New search pairs start at 0 closed trades in the GRID report — expected. Leaders get 5%·3%·1% bonuses; weak candidates can be rotated out later.

• Trade pairs (long slots / budget): 10 — unchanged
• Search pool (entry candidates): currently 12

(BTC, ETH, HYPE, SOL, DOGE, LINK, SUI, XRP, ADA, BNB, AAVE, ZEC); search list is expandable; upper bound = server resources

• Concurrent longs (positions): max 10
• Budget pool: equal floor ÷ 10 (not ÷ number of search candidates)
• Direction: LONG only (buy)
• Margin: cross (shared account)
• Leverage: 10× → 5× (scales down as account grows — see §9)
• Order types: limit GTC on entry, trigger stop-limit on exit
• Bot cycle: adaptive poll (see §7.1) — base 10 s
• Budget: equal floor from tradable equity ÷ 10 + leader bonuses
• Telegram: «Positions» = opens + 10 budget slots;

«GRID (N pairs)» = all current search candidates (new → closed = 0)

Goal: on market drops, pairs enter sequentially, not all at once; priority goes to higher-volatility pairs (better fill odds).

How many pairs may have an active grid (position and/or buy orders). Candidates = full search pool (N; currently 12); concurrent trade cap = 10 slots (same as budget):

Ladder 2+1 → 3+1 → … → 10 active (up to 10 long/active):

A pair with an open long is always active (trailing, add-on levels).

Start: 2 flat pairs with grids (top ATR%) — no delay.

Ladder expansion delay (3rd, 4th, 5th, 6th pair):

• when the ladder condition is met (see table: 2+1 → 3+1, etc.) — pause 5 minutes;
• after the pause — volatility recheck and +1 new flat pair (best among remaining).
• the first 2 pairs at startup — no delay.

Flat pairs (no position): at most resting-buy slots from the table. Selection: top ATR% (1h candles, 24h lookback, ATR period 14).

Volatility refresh:

• immediately after any long entry or position close;
• if an armed flat pair waits > 60 min with no fill — recheck:

replace with a higher-vol pair, or if still the leader, wait 60 min more;

• background ATR cache — at most once per 30 min when idle.

Dormant flat pairs: buy orders cancelled, no new buys placed. After a close, a high-vol pair can be re-armed immediately.

All 10 pairs use the full n_trade table (0…9+).

Rules:

• Pair selection is still by volatility (stagger), not by slot number.
• While a position is open, L1 offset is FROZEN (like the anchor).
• After close, offset is recalculated from current n_trade.
• On pull-up / 6h stale — new L1 uses current n_trade.

From n_trade ≥ 2, levels 2–5 get extra depth below the anchor. L1 is unchanged (§2.2).

Extra depth = (n_trade − 1) × 0.1% × level multiplier

While a position is open, extras are FROZEN. After close — recalc.

The grid is «slightly deeper» on levels 2–5: upper levels closer to price, lower levels significantly deeper than a uniform step.

When flat, only levels 1–3 rest immediately; L4 and L5 follow §4.

When flat, only 3 full-size limit buys (levels 1–3) rest in the book.

Levels 4 and 5 are two-phase (all 10 pairs):

L1–L3 — full level notional, placed immediately.

L4 (after L1–L3 filled):

1. ~10 USDC probe at level 4 price (HL minimum);
2. after probe fill — HL 1h poll once per hour;
3. BUY signal: %B<0 + Williams<-80 + bounce (SELL ignored);
4. on confirmation — buy full L4 notional;
5. no timeout — wait indefinitely.

L5 (after full L4):

• allowed only for the first 4 pairs that completed full L4;

1. ~10 USDC probe at level 5;
2. after probe — HL 1D poll once per day;
3. BUY signal: %B<0 + Williams<-90;
4. on confirmation — buy full L5 notional;
5. no timeout.

Immediate probe fill is OK — full top-up still waits for the TF signal.

On position close, that pair's L5 slot is released.

Purpose: avoid blind deep entries on prolonged dumps; probe keeps API load low until the level is actually touched.

IMPORTANT: pull-up and grid rebuild work ONLY when there is NO position (account is «flat» for the pair).

If a long position is open (waiting for trailing stop):

• anchor is FROZEN;
• limit order prices are NOT moved;
• position and stop-limit are NOT touched;
• when trading volume grows (compound), only the SIZE of

existing limit orders at the same prices is increased.

When there is no position:

The grid always has 4 limit buys (levels 1–4) — placed and removed as a whole. There is no «3-order mode».

A) Pull-up (single unified rule) Trigger: mid > anchor × (1 + 2.5% + L1%), where L1% is the current first-level offset per §2.2 (n_trade). Examples: L1 = 0.5% → threshold +3.0% above anchor; L1 = 1.0% → threshold +3.5%.

Confirmation: price stays above the threshold for 5 minutes. If price drops below during the wait — timer resets, no action.

After 5 minutes still above:

1. cancel ALL resting buys;
2. re-place the full grid from current mid

(anchor = mid, L1 per §2.2, L2–L5 as usual, 4 buys).

Repeats on continued rallies. Anchor is NOT moved down on dips (re-center disabled).

B) Stale rearm (6 hours, zero fills) Only if there were ZERO buy fills for 6 hours (position never opened) while price moved in the corridor:

• entire grid is cancelled;
• pair is disarmed from stagger;
• system re-picks the armed flat pair by volatility

(may be a different pair).

After pull-up or stale rearm, limit orders that do not match the new target levels are cancelled and re-placed.

• A limit buy is filled when price touches the level.
• Each level is a separate fill; the position is scaled up.
• Average entry price is recalculated across all fills.
• Minimum order notional on Hyperliquid: ~10 USDC.

Trailing activation (when we start «pulling» the stop up):

• Same rule for all pairs: trailing activates at +0.9% from entry.
• First take-profit is set at +0.75% from entry.
• Then the stop trails behind the price (trail gap 0.25%).

Trailing parameters:

• Trail gap: 0.25%

Stop trails the best price by 0.25% profit.

• Stop moves UP ONLY, never down.
• Exit type: stop-limit (reduce-only), not market.
• Minimum profit on close: +0.1% from entry price

(bot does not close the position below this threshold).

Hysteresis:

• Fast: enter at ≥ +0.5%; exit only when profit < 0

(between 0 and +0.5% after fast → stay at 2 s).

• Slow: enter at ≤ −5%; exit when profit ≥ −1%

(between −5% and −1% after slow → stay at 60 s).

• Flat (no position) — always Normal 10 s.

Link to trailing: from +0.5% we already poll every 2 s; stop activation remains ~+0.9% (§7). Once the stop-limit rests on the book, HL triggers it immediately.

On stop trigger:

• position is closed;
• PnL is calculated from actual exchange fills (closedPnl

minus fees);

• anchor is reset to the current price;
• deep grid (4+1) is cleared;
• grid is re-placed (4 orders).

• Base floor is equal for all pairs.
• Source: tradable equity (§9) ÷ number of active pairs.
• Leader bonuses by closed trades (from account equity):

1st +5% · 2nd +3% · 3rd +1%

• Floor recalculated on sync deposit (equity / PnL growth).
• Growth capped by tradable equity and available cross margin.

When floor increases, if a pair is ALREADY in a position:

• only pending limit orders are resized (same prices,

larger size);

• open position and trailing stop are unchanged.

If two pairs closed simultaneously within 120 seconds:

• floor is temporarily «frozen» at previous values,
• to avoid a margin spike on parallel re-entry.

Pool size = total trading account equity (all pairs).

As the account grows, the system lowers leverage and sets aside part of equity in reserve (excluded from floor sizing). Below $1,000: no change — 10× leverage, 100% tradable, no separate reserve.

From $1,000 upward, a tier ladder applies (highest matching threshold):

Pool equity (USDC) Leverage Tradable Reserve

Example with 10 pairs and $10,000 pool:

• 8× leverage, tradable: $9,500 → $950 floor per pair (before bonuses);
• reserve: $500 (cushion on drawdowns).

All pair floors remain equal and are computed from tradable pool equity divided by the number of active pairs (plus leader bonuses §8).

• Margin per level = floor ÷ 5 (five grid levels).
• Notional per level = floor × leverage ÷ 5.
• A new limit order is not placed if margin is insufficient

on the pair or on the shared cross account.

• A limit buy is not placed if its price ≥ 99.9% of the current

mid price (level must be strictly below market).

• Every position open and close per pair.
• PnL in % and net USDC (fees included).
• Daily report (time: 21:00 Krasnoyarsk).
• Portfolio drawdown alerts: 50% / 40% / 30% / 20%

of peak equity (no more than once per 24 h per threshold; re-trigger after recovery above 50%).

StormNova · Grid · Hyperliquid Mainnet Document for system users

• Trade ONLY with the trend — counter-trend trading is excluded.
• In parallel: BTC and ETH on a single account (50% / 50% capital).
• Analysis timeframe: 1 hour (1H).
• Entry on pullback within the dominant trend.
• Parameters derived via evolutionary selection on 2024–2026 history.
• Hyperliquid commissions accounted for in backtests and live logic.

Entry is permitted only when the regime matches the trade direction.

Regimes by direction:

• Long only in trend_up
• Short only in trend_down

Stop and target:

• Stop: ATR × 0,615 from entry price
• Base target: 0,19 R (19% of distance to stop)
• Trailing activate: 0,123 R
• Trailing distance: 0,020 R

Period: 26.12.2025 — 24.06.2026 (≈ 6 months) Start: $5 USDC per stream (BTC and ETH separately) Methodology: compound, HL commissions, leverage 10×, risk 10%

ETH stream: (same structure, parallel stream)

Combined test demonstrates robustness across different market phases in 2024–2026 with costs included.

A closely related genetic variant with combo_crash_leader mode (allows entries on sharp RSI moves). Used in R&D; the client presentation shows the more conservative pullback_only variant.

Additional champion gene parameters:

• entry_mode: combo_crash_leader
• rsi_crash_delta: 6
• rsi_crash_lookback: 3 bars
• leverage (in gene): 15× — in lab; presentation uses 10×
• risk_pct (in gene): ~0,91%

Champion metrics (BTC, full sample 2025–2026):

• Win Rate ~87,9%
• Max DD ~7,5%
• Profit Factor ~6,57
• Trades/day ~13,7

• Exchange: Hyperliquid Mainnet
• Execution: limit / market per strategy signal
• Candle analysis: 1H, lookback ≥ 100 bars for regime
• Live vs historical regime reconciliation (mismatch → position

size reduction)

• 24/7 operation on VPS, reports and trades via Telegram

• Grid: BTC · ETH · HYPE · SOL · DOGE · LINK · SUI · XRP · ADA · BNB

(Grid: 10 trade slots · expandable search, 100% capital).

• AI streams disabled; XRP · ADA · BNB moved to Grid.
• Grid and AI do not trade the same coin simultaneously (archive rule).

StormNova · AI Trend · Hyperliquid Document for system users

1.1."Operator"/"Project"— an individual or other entity administering the StormNova ecosystem, the Telegram bot, and related infrastructure, including infrastructure hosted on a VPS.

1.2."User"/"Participant"— a legally capable natural person who has reached the age of 18 (eighteen) years, voluntarily using the StormNova Telegram bot and the"Check"feature on their own behalf and at their own expense.

1.3."Check"— an electronic record (invoice) generated in the Telegram bot at the User's initiative, containing the amount of a voluntary contribution in USDC, transfer details (Arbitrum network, wallet address), and an expiration period. A Check is not a payment document within the meaning of accounting legislation, is not a fiscal receipt, invoice, promissory note, acknowledgment of debt, or other security.

1.4."Check contribution"/"Sponsorship contribution"— a voluntary transfer of digital assets (USDC) to the wallet specified in the Check, made by the User without coercion, at their own discretion, for the purpose of supporting the development of the StormNova ecosystem.

1.5."Check Balance"— an accounting (informational) indicator in the bot reflecting the aggregate amount of Check contributions confirmed on-chain after transaction verification. It does not constitute a monetary obligation of the Operator to the User.

1.6."Credits"— an accounting (informational) indicator in the bot reflecting the aggregate amount of voluntary gratuities from the Project to the User, which the Operator may, but is not obliged to, provide at its discretion. Credits are not interest, dividends, royalties, remuneration under a loan agreement, investment income, insurance payments, or other guaranteed payments.

1.7."StormNova Ecosystem"— the aggregate of software, algorithms, server infrastructure, documentation, the Telegram bot, the official website https://StormNova.space, and other components aimed at automating trading processes and related tasks.

2.1. This Agreement governs the procedure for the User's voluntary sponsorship participation in the development of the StormNova ecosystem through the"Check"feature and the display of related indicators in the bot.

2.2. A Check contribution is legally characterized as a voluntary donation / voluntary sponsorship contribution in favor of project development and is not:

• payment for goods, work, or services within the meaning of the

Civil Code of the Russian Federation (Chapters 30, 37);

• prepayment, earnest money, or advance payment under a sale

contract;

• a contribution to authorized capital, a share in a homeowners'

association, or a share in a cooperative;

• a pooled contribution with mandatory distribution of benefits;
• investment in securities, digital financial assets, utility

digital rights, or other investment products;

• a loan agreement, microloan agreement, or credit agreement;
• an agency, commission, brokerage, or trust management agreement;
• a public offer to receive income or guaranteed profit.

2.3. Credits are legally characterized as voluntary gratuities from the Project for sponsorship support and do not create an obligation for the Operator to pay them in any particular amount, frequency, or timeframe.

2.4. Funds used in the StormNova trading infrastructure (capital on the Hyperliquid account used by Grid and AI algorithms, as well as related"Balance","Report", equity, and trading metrics in the bot) are legally treated solely as the targeted use of sponsorship contributions / voluntary donations (Art. 582 of the Civil Code of the Russian Federation) for in-depth testing, debugging, and demonstration of the platform's technical capabilities, and not as:

• property transferred into trust management (Chapter 53.1 of the

Civil Code of the Russian Federation);

• client funds of a professional securities market participant or

other licensed financial intermediary;

• a contribution to an investment project with an expectation of

guaranteed or systematic income;

• funds subject to mandatory return upon the contributor's or

investor's demand.

2.5. The User confirms that transferring USDC via a Check and (where applicable) placing funds on a trading account for algorithm operation are carried out for research and experimental project support purposes (live software testing on a real market), without creating an obligation for the Operator to preserve, increase, or return such funds. Trading operations constitute software testing, not the provision of investment, brokerage, dealer, or advisory services within the meaning of the legislation of the Russian Federation (including Federal Law No. 39-FZ"On the Securities Market", Federal Law No. 460-FZ, Federal Law No. 259-FZ — to the extent applicable to digital asset operations).

3.1. The User confirms that creating a Check, paying a Check, and confirming a transaction are performed solely at their own will, without coercion, threats, misrepresentation, or material pressure from the Operator or third parties.

3.2. The User independently determines the contribution amount within the limits established by the bot interface (as of the publication of this Agreement: from 25 to 1,000 USDC) and bears full responsibility for their decision to transfer funds.

3.3. The Operator does not promise, guarantee, or mandatorily communicate to the User any financial results, benefits, profit, return on investment, capital growth, or other economic effects in connection with a Check contribution.

3.4. Information in the"Balance,""Report,"and other sections of the bot related to exchange trading is not a promise of yield from a sponsorship contribution and does not link the amount of Credits to trading results.

4.1. Check contributions are gratuitous and non-refundable. After on-chain confirmation of a transfer, the User is not entitled to demand a full or partial refund of a contribution, including in cases of:

• change in the User's financial circumstances;
• dissatisfaction with the operation of the bot, algorithms, or

infrastructure;

• absence, reduction, or cessation of Credits;
• erroneous or impulsive transfer (provided the transfer was made

to the details specified in the User's active Check);

• fluctuations in the exchange rate of USDC, ETH, or other assets;
• technical failures, except in cases expressly stated in Section

4.3 of this Agreement.

4.2. The User waives the application to Check-related relations of rules on unjust enrichment (Article 1102 of the Civil Code of the Russian Federation) with respect to claims for refund of a voluntary sponsorship contribution, since the basis for the Operator's receipt of funds is the User's expression of will, manifested in acceptance of this Agreement and completion of the transfer.

4.3. The sole exception: if it is proven that a transfer was made to different details (a different address or a different network) not specified in the User's active Check — such a transfer is not considered a Check contribution; the procedure for resolution is determined under the general rules of applicable law, taking into account the technical limitations of the blockchain.

5.1. Credits constitute an accounting indicator of voluntary gratuity from the Project and may:

• not be provided at all;
• be provided irregularly;
• change in amount without prior notice;
• be discontinued at any time at the Operator's decision.

5.2. The absence of Credits, their reduction, or cessation does not constitute a breach of this Agreement and does not give the User the right to a refund of contributions, penalties, interest, compensation for lost profits, or other sanctions.

5.3. Credits have no upper or lower limit, are not tied to a formula, interest rate, share, period, or other algorithm binding on the Operator. Any historical examples of Credits (if any occurred) do not constitute precedent and do not create legal expectations for the future.

5.4. Display of the"Credits"amount in the bot is purely informational and does not constitute recognition of a monetary debt, a promissory obligation, or a guarantee of payment.

6.1. The Operator does not engage in brokerage, dealer, depository, trust, or investment advisory activities, is not a professional participant in the securities market, does not provide services for attracting investments within the meaning of Federal Law No. 39-FZ"On the Securities Market,"and does not offer participation in collective investments.

6.2. The"Check"feature is not an offering of digital financial assets, utility digital rights, cryptocurrency as an investment object, or other offering subject to mandatory registration / licensing in the Russian Federation.

6.3. The User confirms that they do not perceive a Check contribution as an investment, do not expect systematic income, and use only funds the loss of which will not impair their vital interests.

7.1. The StormNova ecosystem, Telegram bot,"Check"feature, transaction verification, and display of indicators are provided"as is,"without any express or implied warranties, including warranties of fitness for a particular purpose, error-free operation, continuity, security, and conformity with the User's expectations.

7.2. The Operator does not guarantee:

• uninterrupted operation of the bot, Arbitrum RPC network, or

Telegram API;

• timely confirmation of transactions on the blockchain;
• safety of funds in wallets outside the Operator's control;
• absence of changes in legislation affecting the use of digital

assets.

8.1. The User acknowledges and accepts risks, including:

• volatility of digital assets;
• irreversibility of erroneous transfers on the blockchain;
• sending funds on the wrong network or to the wrong address;
• network fees (gas) paid by the User independently;
• delays in transaction confirmation;
• technical failures of equipment, communications, or software;
• actions of third parties (messenger hacking, phishing, address

substitution);

• changes in the regulation of cryptocurrencies and digital

assets in the Russian Federation and other jurisdictions;

• tax consequences of transactions with digital assets.

8.2. The User undertakes to independently verify the recipient address, network (Arbitrum), token (USDC), and amount before sending.

9.1. This Agreement constitutes a public offer within the meaning of Article 437 of the Civil Code of the Russian Federation with respect to the terms of use of the"Check"feature.

9.2. Acceptance (full and unconditional agreement) of the terms of this Agreement is deemed to occur when the User performs any of the following actions:

• pressing the"Check"or"Create new check"button;
• entering an amount and generating a Check;
• pressing"Paid"and/or submitting a transaction hash;
• actually transferring USDC to the Check details.

9.3. From the moment of acceptance, the User is deemed to have reviewed all provisions of the Agreement posted in the"Info"section of the bot and/or as part of the StormNova document package.

10.1. The User is entitled to:

• voluntarily create Checks within the bot limits;
• cancel an unpaid Check before its expiration;
• view Check history, payments, and accounting indicators;
• discontinue use of the"Check"feature at any time.

10.2. The User undertakes to:

• provide accurate transaction data (hash);
• not use the"Check"feature for unlawful purposes;
• not represent a sponsorship contribution to third parties as an

investment, deposit, loan, or payment for guaranteed services;

• comply with applicable law of the Russian Federation.

10.3. The Operator is entitled to:

• change technical parameters of Checks (term, amount limits);
• suspend or restrict the"Check"feature;
• reject payment confirmation if on-chain data does not match

Check conditions;

• grant or withhold gratuity at its discretion;
• update the text of this Agreement.

10.4. The Operator is not obliged to:

• refund contributions;
• pay Credits in any particular amount or timeframe;
• provide reporting in the form established for investment or

credit products.

11.1. The aggregate liability of the Operator to the User for any claims related to Checks and Credits is limited to the amount of 0 (zero) rubles / 0 (zero) USDC, except where applicable law does not permit such limitation by reason of mandatory rules.

11.2. The Operator is not liable for indirect losses, lost profits, moral damages, loss of reputation, loss of data, or other consequences arising in connection with use of the"Check"feature or absence of Credits.

11.3. The User undertakes to indemnify the Operator (hold harmless) for losses, expenses, and sanctions arising from claims by third parties (including government authorities) based on the User's unlawful representation of a sponsorship contribution to third parties as an investment or guaranteed income.

12.1. The User independently calculates, declares, and pays all taxes and levies arising in connection with transfers of digital assets, receipt of Credits (if applicable), and other transactions.

12.2. The Operator does not act as the User's tax agent unless otherwise expressly required by mandatory rules of law.

13.1. Within the"Check"feature, minimally necessary technical identifiers (Telegram user id, chat id, blockchain transaction data) are processed solely for Check accounting, payment verification, and display of history.

13.2. The User consents to such processing as necessary for the operation of the bot.

14.1. All rights to software code, algorithms, documentation, the StormNova brand, the StormNova.space domain and website, and bot materials belong to the Operator or lawful rights holders.

14.2. A sponsorship contribution does not transfer to the User any share in intellectual property, business, revenue, or assets of the Operator.

15.1. The law of the Russian Federation applies to this Agreement.

15.2. Disputes are subject to mandatory pre-trial resolution: a party sends a claim via Telegram @BagateyDI; response period — 30 (thirty) calendar days.

15.3. If no agreement is reached, the dispute shall be submitted to a court at the place of residence (place of stay) of the Operator, unless otherwise required by mandatory rules of procedural law.

15.4. The User confirms that the terms of this Agreement do not deprive them of rights unconditionally guaranteed by the legislation of the Russian Federation on consumer protection — to the extent directly applicable to gratuitous voluntary donations and informational services that do not constitute payment for goods/services.

16.1. The parties are released from liability for failure to perform obligations caused by force majeure circumstances: natural disasters, military actions, acts of government authorities, failures of global networks, large-scale internet outages, regulatory changes, hard forks, compromise of third-party infrastructure (Telegram, RPC providers, blockchain networks), and other events beyond the reasonable control of a party.

17.1. The Operator may amend this Agreement unilaterally. The current version is published in the"Info"section of the bot and/or on the website https://StormNova.space.

17.2. A new version applies to Checks created after publication of the update. Previously paid contributions are governed by the version in effect at the time of acceptance.

17.3. The Operator may discontinue the"Check"feature in whole or in part without compensation to Users.

18.1. Invalidity of any individual provision of this Agreement does not entail invalidity of the remaining provisions.

18.2. Inaction by the Operator in the event of a breach by the User does not constitute a waiver of rights.

18.3. This Agreement is drafted in Russian. In the event of any discrepancy between translations, the Russian-language version shall prevail.

18.4. By using the"Check"feature, the User confirms that:

• they have reached the age of 18 and possess full legal capacity;
• they have read and understood this Agreement;
• they understand the gratuitous and non-refundable nature of the

contribution;

• they understand the non-mandatory nature of Credits;
• they act on their own behalf, at their own expense, and at their

own risk.

BRIEF SUMMARY (does not replace the full text above)

• Check = voluntary sponsorship contribution to StormNova development
• Contribution is non-refundable
• Trading capital = targeted use of contributions for in-depth platform

testing (not investment or trust management)

• Credits = voluntary gratuity, without guarantees or deadlines
• This is not an investment, loan, or purchase of income
• Network fee is paid by the sender
• Full text of the Agreement — in the"Info"section of the bot

document for review before using"Check"