How TheHyperBot Works
A practical guide to launching, monitoring, and managing the DCA grid system on Hyperliquid, including the BTC grid, optional ETH hedge leg, Live Grid status, editing controls, and risk boundaries.
Overview
TheHyperBot is a browser-launched DCA grid system for Hyperliquid. The main configuration launches a BTC long grid below market and can aggregate already-crossed levels into a near-market allocation-curve catch-up order. The optional hedge configuration launches an ETH short grid above market using the same curve-aware logic. New grid entries are launched with native Hyperliquid TP/SL brackets so each parent order can show its intended take profit and stop loss on the exchange.
The core cycle is simple: enter on grid fill → exit on take profit → re-place the level. In sideways or volatile markets, the system is designed to monetize repeated movement through the same price zones. In strong trends, open inventory and stop/close decisions matter more than completed-cycle income.
At 5x leverage, a 1% price move = 5% return on the margin used for that order. The bot does this on every individual order, not the whole position. Each order is its own profit center.
The optional ETH short grid and allocation-curve catch-up can reduce directional BTC risk, but they are not a guaranteed hedge. Protection depends on actual fills, sizing, correlation, slippage, funding, and whether risk controls remain active. A completed TP cycle can be profitable while the total portfolio still loses money in a strong trend or forced unwind.
Resting limit orders and stop triggers live on Hyperliquid after launch. The browser launches and edits the grid, but always-on cycling, TP repair, dynamic hedge rebalancing, pair kill, and trailing exits are backend-worker responsibilities. Live Grid and Panic Close are useful active-session controls, not replacements for a running worker.
TheHyperBot is trading software, not financial advice or a managed account service. You choose the parameters and you are responsible for verifying every live order directly on Hyperliquid, including entries, TP/SL children, reduce-only flags, leverage, margin mode, collateral, and open positions. If the orders shown on Hyperliquid do not match what you expect, do not leave the grid running.
How the Grid Works
The bot calculates grid levels based on your configuration:
- Grid range: Defined as a percentage of BTC's all-time high (ATH), for example 85% to 60% of ATH.
- Allocation curve: The ATH range is also a target exposure curve. If price is already inside the range, the bot targets the cumulative exposure that would have filled from the grid top down to the current zone.
- Number of orders: Evenly spaced within the range (default: 50 orders).
- Graduated sizing: Orders near the top get less margin ($10), orders near the bottom get more ($15). This means you buy more BTC at deeper discounts.
Normal future grid entries are placed as resting limit orders, which are intended to earn maker fees when they fill. If current price is already below some BTC long levels, those historical levels are aggregated into a near-market maker-style catch-up order instead of being placed above market as immediate taker buys. Emergency actions, stop exits, and panic closes may still cross the spread and pay taker fees.
The bot does not silently move your ATH risk range after a rebound. Your configured range defines the risk budget. The backend worker compares live BTC exposure against the target implied by that range and can add or reduce exposure around the target as price oscillates.
Why graduated sizing?
Flat grids allocate equal margin to every level. This means you buy the same amount at $77K as at $64K. Graduated sizing flips this — you allocate more capital to lower prices where BTC is cheaper and has more recovery potential. This improves your average entry price and pushes the liquidation price further away.
Wallet Connection
TheHyperBot uses WalletConnect (via Reown AppKit) so you can sign orders directly with your Trezor, Ledger, or MetaMask — no private key needed.
How it works
- Connect Wallet — click the Connect button in the nav bar, select MetaMask or scan a WalletConnect QR code.
- Named Agent Approval — your wallet approves a named HyperBot agent generated in your browser.
- Session-limited reuse — the named agent is cached in browser
sessionStoragefor the current tab for up to 12 hours, then cleared or refreshed. - Propagation retry — after approval, the calculator waits and retries while Hyperliquid propagates the agent approval.
- Stale-agent recovery — if Hyperliquid rejects a cached agent, the cache is cleared and the UI asks for one fresh named approval instead of repeatedly requesting signatures.
Your main wallet signs an approveAgent action authorizing a named browser key to trade. The agent key can place and cancel orders, but it cannot withdraw funds. Closing the browser tab clears the session cache. If you revoke the agent on Hyperliquid, the next signed action may require a new approval.
You can also use a raw private key (API wallet) by clicking "Use private key instead" in the modal. This is the legacy flow for users who prefer to paste their Hyperliquid API wallet key directly.
How Orders Are Placed
When you click Launch Grid Orders, the calculator signs and sends a sequence of Hyperliquid actions from your browser:
New launches are tagged with internal HyperBot client order IDs. These tags let the Live Grid tab identify which entry, TP, and stop orders belong together without relying only on price and size matching.
Native Brackets & Order Counts
New grid launches use Hyperliquid native TP/SL brackets. A single grid level is not one open order on Hyperliquid. It is usually three linked orders:
| Order | Purpose | Expected behavior |
|---|---|---|
| Parent entry | Opens the grid level if price reaches the entry. | Normal limit order, not reduce-only. |
| Take-profit child | Closes that level at the configured net TP target. | Reduce-only TP market trigger. |
| Stop-loss child | Closes that level if the stop trigger is reached. | Reduce-only stop market trigger. |
This means a 50-level grid can show close to 150 open orders on Hyperliquid: 50 parent entries, 50 TP children, and 50 SL children. That is expected for bracketed protection and is not, by itself, a bug.
Why a 50-level grid may show 135 orders
Allocation-curve catch-up can consolidate already-crossed levels into one near-market bracket. For example, if 6 BTC long levels are already above current market and catch-up is enabled, those 6 historical levels are replaced by one aggregated level 0 catch-up bracket. The result is:
In that case, the missing 5 brackets were not rejected. The already-crossed exposure was intentionally consolidated. The catch-up level should appear as level 0 in Live Grid.
Catch-up is maker-style, not guaranteed immediate fill
The current catch-up order is placed near market but on the passive side: for BTC longs, slightly below current price; for ETH shorts, slightly above current price. This is designed to avoid unnecessary taker fees. It also means the catch-up order may rest without filling if price moves away. If you require immediate exposure, you must understand that this would require a more aggressive IOC/taker-style mode and higher fee/slippage risk.
Launch batching
The calculator currently sends bracket levels sequentially so each bracket can be accepted or reported independently. Bulk bracket batching could reduce API calls and launch time, but it does not reduce the number of open orders on Hyperliquid. It also changes failure behavior: one malformed bulk request can reject a larger group of brackets. Sequential bracket placement is slower, but easier to audit level by level.
What is reduce-only?
Reduce-only (r: true) is the key mechanism that makes this safe. A reduce-only sell order can only close an existing long position — it will never open a new short position. This means:
- A reduce-only TP can only close existing exposure; it cannot accidentally reverse the account into the opposite direction.
- Native bracket TP/SL children are reduce-only, so they are intended to close the parent exposure rather than open a new opposite position.
- If any TP/SL child is missing or rejected, Live Grid should flag the missing protection and the backend worker can repair cloid-tracked levels when it sees the fill.
- When a buy fills, you now have a long position. The intended TP sell should then be available as the attached or repaired reduce-only exit.
New grid launches are tagged for cycling by default. There is no static-mode launch option. The backend worker reads those tags, repairs missing TPs after entries fill, and re-places completed levels so the browser does not need to stay open for cycle replacement.
Backend cycling is deterministic only for new HyperBot launches with internal client order IDs. Older grids without these tags can still appear in Live Grid as inferred legacy orders, but the worker will not safely re-cycle them because it cannot prove which entry and TP belong to the same level.
If the backend worker is not running, exchange-resident orders remain, but completed levels will not be re-placed and missing TPs will not be repaired. Treat pair_worker.py as part of the live trading system.
Grid cycling, TP repair, dynamic ETH rebalancing, automatic pair kill, and trailing exits require the Python backend worker (python3 pair_worker.py). The browser calculator can launch and edit orders, but it is not reliable enough for crash-speed automation when the tab is backgrounded or closed.
ETH Hedge & Allocation-Curve Catch-Up
The BTC grid is mostly below current market price. That is useful for catching dips, but it also means any levels already crossed by the current price should be treated as target exposure rather than as future passive orders. The optional allocation-curve catch-up moves those already-crossed levels into a near-market maker-style order sized by the curve itself.
When the ETH hedge is enabled, the calculator prepares an opposite ETH short grid. The ETH leg is designed to mirror the broad BTC scenario while respecting ETH's different volatility profile and a conservative hedge size. The important point for users is behavioral, not mathematical: BTC long entries are placed below market, while ETH short entries are placed above market.
- BTC long catch-up: already-crossed BTC long levels are consolidated near market instead of becoming marketable buy limits above price.
- ETH short catch-up: already-crossed ETH short levels follow the same rule on the short side.
- Budget-neutral grid: catch-up exposure replaces the equivalent passive levels, so planned exposure remains within the allocation slider.
- Curve-sized only: the catch-up amount comes from levels already crossed by market price, not from an arbitrary fixed percentage.
Catch-up is not a promise that the account already has the target exposure. It is an order-placement method. If the near-market catch-up order does not fill, the target exposure is still not active. Always verify filled position size and remaining open orders on Hyperliquid.
A passive ETH short grid is not the same thing as a guaranteed real-time hedge. If ETH does not fill, it cannot protect the account. Curve catch-up and the backend worker improve this, but correlation, slippage, funding, and execution speed still matter.
Live Grid Status
The Live Grid tab reconstructs the current state of a running grid from Hyperliquid read-only data. It can be used with a connected wallet or by pasting the main public account address. Do not paste an agent key address for inspection; agent addresses do not own the positions.
The Live Grid shows:
- Position summary: side, size, entry, mark price, unrealized P&L, liquidation price, and margin used.
- Recent realized P&L: calculated only from recent fills returned by Hyperliquid, not lifetime history.
- Grid levels: pending entries, active filled levels, partial levels, legacy seed TP entries, completed recent cycles, and manual orders.
- Stop trigger: the current reduce-only stop trigger if one is found.
- Recent fills: recent buys/sells, size, price, fee, and closed P&L as reported by Hyperliquid.
Live Grid reconstructs state from Hyperliquid read-only endpoints and recent fills. It can be stale, inferred, or incomplete if an API call fails or the grid was launched before HyperBot cloid tagging. Hyperliquid Open Orders, Positions, and Order History are the source of truth for live trading decisions.
Cloid-tracked vs inferred grids
New HyperBot launches include client order IDs that identify each order's purpose and grid level. These grids can be tracked and edited much more reliably.
Older grids launched before this tagging existed are shown as inferred. The Live Grid can still show positions and recent fills, but level matching may be imperfect. For safety, inferred legacy grids are read-only and editing controls are disabled.
If you need full Live Grid editing, launch a fresh cloid-tracked grid. Legacy positions can still be inspected, but the calculator will avoid mutating orders it cannot identify with high confidence.
Editing Running Grids
For cloid-tracked grids, the Live Grid tab exposes controlled editing actions. These actions require signing authority through WalletConnect or a stored API wallet key. Pasting a public account address is enough for inspection, but not for editing.
| Action | What it does | Safety behavior |
|---|---|---|
| Edit TP | Moves a resting take-profit order to a new price. | Warns if the new TP is immediately marketable. Coordinates with the cycle monitor. |
| Edit Stop | Replaces the current stop trigger at a new trigger price. | Preserves the original SL size instead of shrinking it to current position size. |
| Cancel pending level | Cancels a fully pending level before it has created exposure. | Removes the level from browser cycling so it is not re-placed. |
| Close active level | Cancels the TP and sends a reduce-only IOC close for that level size. | Verifies an open position in the expected direction before sending the close. |
During any edit, browser cycling is paused, the edit is signed and sent, Live Grid refreshes, and then cycling resumes if it was active. This prevents the monitor from re-creating an old TP or canceled level while the edit is in flight.
Manual orders and legacy inferred orders can be displayed, but they are not edited by HyperBot. This is intentional: an incorrect match could cancel or modify the wrong order.
Panic Close
The compact Panic Close control appears when the account has BTC/ETH exposure or open orders. It is intentionally small and right-aligned so it remains available without becoming an easy accidental click target.
After confirmation, Panic Close attempts to:
- Stop browser cycle monitors for both BTC and ETH.
- Cancel open orders on the account.
- Fetch current BTC/ETH positions.
- Send reduce-only IOC close orders for non-zero BTC and ETH positions.
- Re-check positions and open orders before reporting success.
If any BTC/ETH position or order remains after the close attempt, the button stays visible and the status message reports what is still open. Use this as an emergency unwind tool, not as a normal rebalancing method.
Take-Profit Cycling
Each grid level goes through a cycle:
If BTC oscillates in a tight range, the orders near that range can cycle multiple times per day. Each completed cycle captures the configured TP minus fees. This is where the bot is strongest: monetizing volatility without needing a large directional move.
Graduated take profit
The calculator can use graduated TP targets. Orders close to current price use the base TP, while deeper long entries or farther short entries require wider profit targets. This can improve revenue per completed cycle at grid extremes, but it also means some positions need a larger recovery before closing.
Net-of-fees take profit
TP percentages are treated as the intended net return on entry notional, not just the raw price distance. The calculator and backend worker estimate entry and exit trading fees, then place TP prices far enough away that a completed cycle should realize the configured TP after trading fees, before funding and slippage.
The backend worker refreshes Hyperliquid userFees daily when available and can safely adjust cloid-tracked resting TPs if the account's fee tier changes. It will not move a TP to a marketable price just to satisfy the formula; it logs or alerts instead.
"Loss" Orders Are Just Accounting
This is the most important concept to understand. When you look at your P&L on Hyperliquid after the bot closes a position, you might see some orders showing a negative P&L. This can be alarming, but it is purely an accounting artifact — not a real loss.
Why this happens
Hyperliquid merges all your fills into a single position with a weighted average entry price. When the bot closes individual orders at their TP price, Hyperliquid calculates the P&L against the average entry — not the entry price of that specific order.
Hyperliquid does not track per-order P&L. It only tracks one position per asset with one weighted-average entry price. TheHyperBot tracks each order individually in software and places each TP at that order's configured profitable exit level, but the TP still has to fill.
Worked Example
Let's walk through a concrete scenario with 3 orders:
| Order | Buy Price | Size | TP Sell Price (+1%) |
|---|---|---|---|
| #1 | $77,000 | 0.001 BTC | $77,770 |
| #2 | $76,000 | 0.001 BTC | $76,760 |
| #3 | $75,000 | 0.001 BTC | $75,750 |
Step 1: All three buys fill as price drops
BTC drops from $78K to $74K. All three orders fill. On Hyperliquid, your position is:
Step 2: Price bounces to $76,000 — Order #3 TP fills
Order #3's TP sell is at $75,750. It fills. The bot sells 0.001 BTC at $75,750.
Hyperliquid shows a $0.25 loss because it compares the sell price ($75,750) against the average entry ($76,000). But the bot bought that specific order at $75,000, so the real profit is $0.75.
Step 3: Price bounces to $77,000 — Order #2 TP fills
Step 4: Price hits $77,770 — Order #1 TP fills
Final Tally
| Hyperliquid Shows | Real Per-Order P&L | |
|---|---|---|
| Order #3 | -$0.25 | +$0.75 |
| Order #2 | +$0.26 | +$0.76 |
| Order #1 | +$0.77 | +$0.77 |
| Total | +$0.78 | +$2.28 |
They do, once you account for the unrealized P&L that existed while the position was open. As orders closed, the remaining position's average entry shifted, and those unrealized gains/losses transferred into the subsequent closes. The total realized + unrealized P&L across all steps always equals the sum of real per-order profits. No money is lost or created — it's just allocated differently in the display.
What Per-Order TP Guarantees
The bot places each long TP above its specific buy price, and each short TP below its specific sell price. This means:
- Every completed TP cycle is intended to close that specific order at a positive net spread after estimated trading fees.
- Reduce-only TP orders are designed to close exposure, not open the opposite position.
- In lateral markets, the same price level can cycle repeatedly and capture the configured TP.
This does not guarantee total strategy profit. Open inventory can move against the account, TP orders may not fill, funding and fees can reduce returns, IOC/stop orders can slip, and safety exits can close positions at a loss. Per-order TP controls the exit target for completed cycles; it does not remove market risk.
Checking TP Coverage
A running grid should normally have reduce-only TP orders resting for the grid levels that are intended to close exposure. In the Live Grid tab, this appears as active levels with a TP price, pending levels with paired entry/TP orders, and a Stop Trigger card if a stop-loss trigger exists.
Useful checks after launch:
- Pending levels: each pending grid level should show an entry price, TP price, size, and tracking status.
- Active levels: each filled level should show a resting TP. If an active level has no TP, it needs attention.
- Legacy seed TP: older seed fills are tracked separately from normal grid levels so they do not hide a missing grid TP.
- Stop Trigger: the summary should show a stop trigger if the launch placed one and it has not been canceled.
- Legacy warning: if the grid is inferred, Live Grid may not be able to prove exact level pairing. Use Hyperliquid open orders as the source of truth if anything looks mismatched.
Hyperliquid verification checklist
After every launch, edit, repair, or panic action, verify directly inside Hyperliquid:
- Open Orders: parent grid entries should have the expected size, price, direction, and TP/SL children.
- TP/SL: take-profit and stop-loss orders should be reduce-only and point in the closing direction.
- Positions: position size, average entry, unrealized P&L, and liquidation information should match your risk expectation.
- Order History: rejected, canceled, or partially accepted brackets should be reviewed before assuming the grid is fully protected.
- Account mode: the bot is designed for cross margin in Standard or Unified Account mode, not isolated margin or Portfolio Margin.
If Hyperliquid does not show the TP/SL orders you expect, act as if the position is unprotected until you confirm otherwise. The user is responsible for checking exchange state before leaving capital exposed.
Anyone can verify open order coverage with the main public Hyperliquid account address. Hyperliquid info-query data is public by address; no private key is needed. The address must be the main account, not an agent wallet address.
Cross-Margin Explained
TheHyperBot uses cross-margin mode on Hyperliquid. This means your entire account balance acts as collateral for your position — not just the margin allocated to each order. Isolated margin is not supported by the worker because it breaks the shared-collateral liquidation and pair-risk assumptions.
Cross vs Isolated Margin
| Cross Margin | Isolated Margin | |
|---|---|---|
| Collateral | Entire account balance | Only the margin for that position |
| Liquidation price | Much further from entry | Close to entry |
| Risk | All funds at risk if liquidated | Only allocated margin at risk |
| Best for | Grid bots with many small orders | Single high-conviction trades |
Why cross margin for grid trading?
With 50 orders using only 40% of your portfolio, the remaining 60% acts as a collateral buffer. In cross mode, that buffer is not isolated cash; it supports the whole account and is at risk if liquidation occurs. Example:
Cross margin makes grid strategies safer by letting unused collateral absorb drawdowns across the account. The tradeoff is that liquidation risk applies to the shared collateral pool.
If your Hyperliquid account uses Unified Account mode (the current default), spot and perp balances share a single USDC collateral pool. Your "reserve" is not separate protected cash — it is actively collateralizing your cross-margin perp positions, which makes your liquidation price safer but means all USDC is at risk if liquidation occurs.
The backend worker reads equity from spotClearinghouseState (USDC total) rather than clearinghouseState.marginSummary.accountValue, which only reports the perp-side margin for Unified accounts. It also monitors unified margin ratio as maintenance margin divided by usable USDC collateral. Do not opt into Portfolio Margin or isolated margin while running this bot — live worker mode refuses both by default because they introduce risk models the bot is not designed to manage.
How Liquidation Works
Liquidation occurs when your account equity falls below the maintenance margin requirement. On Hyperliquid, this is approximately 1.25% of your total position notional for BTC (calculated as 1 / (2 * maxLeverage) where maxLeverage = 40).
The 1.25% maintenance margin is not a periodic charge. It is the minimum equity-to-notional ratio. If your account equity drops below this threshold, Hyperliquid's liquidation engine will close your position. Think of it as a minimum balance requirement, not a recurring cost.
Concrete example
You have a $15,000 portfolio and all 50 grid orders fill, creating $30,000 in notional exposure:
- Maintenance margin required: $30,000 * 1.25% = $375
- Your account equity: $15,000 minus unrealized losses
- Liquidation triggers when: Equity drops to $375
- That means BTC must drop to: ~$31,000 (roughly 55% below your average entry)
With the circuit breaker set at 55% below ATH, the bot will close your position well before liquidation could occur.
Safety Mechanisms
The system uses several layers of safety. Some are exchange-resident, some are browser-assisted, and some require the backend worker.
Exchange-resident protection
- Reduce-only TPs: take-profit orders are designed to close exposure, not reverse the account.
- Stop trigger: launch places reduce-only stop triggers for the planned bracketed grid entries.
- Cross margin: unused account equity acts as a buffer, but the full account is still at risk if liquidation occurs.
Browser-assisted protection
- Live Grid: shows whether open orders, positions, TPs, recent fills, and stop triggers are visible.
- Inline edits: lets you move cloid-tracked TPs and stop triggers without manually rebuilding the whole grid.
- Panic Close: attempts to cancel orders and close BTC/ETH positions, then verifies whether anything remains.
Backend-worker protection
Always-on grid cycling, TP repair, allocation-curve rebalancing, fee-aware TP review, dynamic ETH hedge rebalancing, automatic pair kill, and trailing exits require the backend worker. This is also where Unified Account risk is monitored: account value comes from the shared USDC collateral pool, and the worker can stop the pair if unified margin ratio crosses the configured limit.
The unified margin-ratio guard is controlled by PAIR_KILL_MAX_UNIFIED_MARGIN_RATIO. It accepts either ratio or percentage notation: 0.80, 80, and 80% all mean 80%, while 1 means 100%.
The worker also refuses isolated BTC/ETH positions by default. Keep PAIR_ALLOW_ISOLATED_MARGIN=false unless you are intentionally bypassing the bot's cross-margin risk model.
The worker exposes a localhost health endpoint at 127.0.0.1:8081/health by default and can send Telegram alerts for pair kills, incomplete unwinds, trailing exits, account-mode pauses, and worker start/stop events when Telegram env vars are configured.
The browser is not the always-on engine. If the worker is stopped, existing exchange orders can still fill, but completed levels will not be re-created and missing TPs will not be repaired until automation is running again.
Operating Checklist
Use this checklist whenever you launch or modify a live grid:
- Before launch: confirm BTC/ETH prices, ATH data, grid range, leverage, allocation, TP style, and stop level.
- Before live cycling: start
pair_worker.pywith live trading explicitly enabled and verify it is logging grid sync activity. - Before curve rebalancing: verify the worker logs the expected allocation-curve target and that
PAIR_ALLOCATION_CURVE_ENABLEDis intentional. - Do not mix engines: do not run the legacy core bot on BTC or ETH while the pair worker is active unless you intentionally set
CORE_ALLOW_WITH_PAIR_WORKER=true. - After launch: open Live Grid and verify that orders, position, TP levels, and stop trigger appear as expected.
- On Hyperliquid itself: confirm the parent entries, TP children, SL children, reduce-only flags, and account position directly in Open Orders and Positions.
- If using hedge: check both BTC and ETH tabs. A hedge is only real when the intended ETH exposure has actually filled.
- After editing: refresh Live Grid and confirm the edited TP or stop trigger is visible on the exchange state.
- Before sleeping or stepping away: confirm the backend worker is still running and that the account has the TP coverage you expect.
- If something looks wrong: verify open orders directly in Hyperliquid before assuming the UI reconstruction is correct.
If you do not understand why the exchange shows a certain number of open orders, why a TP/SL is missing, or why a catch-up order has not filled, pause and inspect before adding exposure. Automation is not a substitute for understanding the orders on your own account.
Trading Fees
Normal resting grid entries and resting TP orders are designed to fill as maker orders, which get the lowest fee tier on Hyperliquid. Stop-triggered exits, panic closes, and active-level market closes can behave like taker executions because they prioritize immediate execution over fee minimization.
The bot reads Hyperliquid's user-specific fee rates through userFees when possible. If that lookup fails, it uses conservative fallback rates from configuration. Funding payments and execution slippage are not included in the TP formula.
| Order Type | Fee | Per $1,000 notional |
|---|---|---|
| Maker (limit) | 0.010%* | $0.10 |
| Taker (market) | 0.035%* | $0.35 |
*Base fees, subject to change. Fees are floating and may vary by tier. With the BOTARMY referral, you get an additional 4% discount on all fees. See Hyperliquid fee schedule.
Round-trip cost per cycle
Each TP cycle involves one buy (maker) and one sell (maker):
Performance Fee
TheHyperBot charges a 10% performance fee on realized profits only. No monthly subscriptions, no upfront costs.
- Fee is calculated per completed TP cycle:
profit * 10% - If a cycle results in a loss (e.g., circuit breaker close), no fee is charged
- Fees are tracked in real-time on your dashboard
- Settled monthly via USDC transfer
Example
| Scenario | Bot Profit | Fee (10%) | You Keep |
|---|---|---|---|
| 50 cycles, $0.37 each | $18.50 | $1.85 | $16.65 |
| 200 cycles in a month | $74.00 | $7.40 | $66.60 |
| Circuit breaker close | -$120.00 | $0 | -$120.00 |
The performance-fee model is intended to align incentives on realized profitable cycles. It is not a guarantee of profitability and does not transfer trading risk away from the user.
User Responsibility and Liability
TheHyperBot is provided as software tooling and educational material for users who choose to trade on Hyperliquid. It is not investment advice, financial advice, legal advice, tax advice, portfolio management, a managed account, or a promise of profit.
You are solely responsible for every trading decision and every parameter used by your account, including allocation, leverage, account mode, grid range, TP settings, stop-loss settings, hedge settings, worker configuration, wallet connection method, and whether to launch, edit, cancel, close, or leave a grid running.
Before leaving a grid active, you must verify the actual orders on Hyperliquid. Check entries, take profits, stop losses, reduce-only flags, order sizes, prices, open positions, margin mode, liquidation risk, and order history. If Hyperliquid does not show what you expect, do not rely on the bot UI alone.
Trading perpetual futures, leverage, cross margin, Unified Account collateral, hedging, and automated order placement can result in partial or total loss of funds. Losses can come from market movement, liquidation, funding, fees, slippage, missing fills, partial fills, rejected orders, API outages, exchange behavior, wallet issues, browser issues, backend-worker downtime, stale data, software bugs, user configuration mistakes, manual actions, security incidents, or any other cause.
To the maximum extent permitted by applicable law, TheHyperBot, thehyperbot.com, its operators, developers, contributors, affiliates, and related parties are not responsible or liable for user losses, damages, missed profits, liquidations, fees, funding payments, slippage, failed hedges, failed automation, order errors, exchange outages, or any other trading outcome. Use the software at your own risk. If you do not understand the orders and risks shown on Hyperliquid, do not trade.
This documentation is written for practical risk disclosure. It should not be treated as a substitute for formal legal terms. Users and operators should have counsel review the final terms of service and liability language for their jurisdiction.
Referral Discount
All TheHyperBot users join Hyperliquid via our referral code BOTARMY. This is free and gives you a permanent 4% discount on all trading fees.
TheHyperBot (referee) receives 10% of referred users' trading fees from Hyperliquid. Referred users receive a 4% discount on all fees. This referral fee is paid by Hyperliquid, not by you — it does not increase your costs. See Hyperliquid Docs for details.
The referral discount applies to all your trades on Hyperliquid, not just those made by the bot. It's a permanent benefit with no expiration.
Trading perpetual futures involves substantial risk of loss. Leverage amplifies both gains and losses. Past performance does not guarantee future results. Only trade with capital you can afford to lose entirely. TheHyperBot is a tool and does not eliminate market, execution, liquidation, or operational risk. Safety mechanisms reduce some risks but cannot guarantee protection. You are responsible for verifying all orders and positions on Hyperliquid.