# The plan: $1 → size, and everything that can stop you Companion to `STRATEGY.md` (the rules and the code). This file is about money, venues, risk and operations. All numbers verified 11 Nov 2026. --- ## 0. Corrections to my last answer **Liquidation was my bug, not your strategy — you were right.** The replay log showed a held LONG at 1267.08 with the line at 1267.07. Price fell to 1256.52 over 23 minutes and the position never closed. Reason: `on_chart3()` returned early whenever the gate was off, and a held trade is *always* gate-off — so **the rule "the held trade closes when price touches the newest line" could never fire.** The position rode to 75x liquidation for no reason other than that. Fixed: chart 3 now watches the line even when the gate is off, and a carried position closes (and books its cycle) on the first brick that touches the line. Re-run on the same real data, no liquidation: | | before the fix | after the fix | |---|---|---| | cycles | 9 | **50** | | chart-3 trades | 53 | 403 | | $1 → at 0% fees | liquidated | **$26.20** (+2520%), max drawdown 1.9% | | $1 → at 0.05% fees | liquidated | $0.07 (fees $0.87) | So the concept is removed from the model: **the line always exits before liquidation, because the line is closer than 1/leverage.** I will not use liquidation as an argument against 75x again. What remains true is narrower and still important: - The **held** trade can only exit on a *touch* of the newest line. If the line is far (the trade was opened on an old line and price ran without printing a new 1h brick), the exit is far. Very rare, and 0.33% wide at most, but not zero. - A **flash crash that jumps the line without trading at it** has no touch and therefore no exit. That is a real event, not a modelling artefact — see §4. - Fees are unchanged and still the dominant cost at 0.05%. **"All the 1h bricks are our profit."** Correct in principle, and now measured: the backtester counts every 1h brick printed while a trade is held. On this sample it was 12 bricks total across 50 cycles, because the *newest line* is usually still the old line, so the held trade exits after 0–2 bricks. Mean cycle = **+2.12 bricks** net, median 0, best +34. The account's growth came from **many cycles plus compounding**, not from one long run. To capture the long runs you are thinking of (median run 11 bricks, 6.5% are 50+), the exit rule would have to be a trailing line rather than "the newest printed line" — that is a strategy change, so I have not made it; it is task 1 in §9. --- ## 1. What I understood about removing chart 1 Your argument: chart 3 (0.001%) already knows when price is at the line, so chart 1's job is redundant. What I understood, and what the code now does: - Chart 3 can detect **the touch**. What chart 1 supplies is not detection, it is the **tolerance band** around the line — 0.1% of price. Without that band you have two bad options: gate off on the first tick that leaves the line (far too tight, trading almost never on), or invent a distance threshold anyway. - So: the *chart* can go, the *band* cannot. Removing chart 1 and setting a 0.1% distance gate is the same rule expressed without a chart — and that is now a switch (`GATE_MODE = "band"`, `GATE_BAND = 0.1%`), not an argument. - Chart 2 keeps its job unchanged: it is the only thing that defines where the line *is*. Charts 1 and 3 are both "alignment" to that line; only chart 3 trades. Measured on the same real data (§ below), the band version and the chart-1 version are within noise of each other on trades and net, which supports your point: the 0.1% chart is not adding information, only a tolerance width. Keep the switch, drop the chart if you prefer — the strategy is identical. --- ## 2. The plan, stage by stage Each stage has a gate. Do not advance until the gate passes. Every stage trades the same rules; only size, venue and custody change. **Stage 0 — prove the number (now, $0).** Run `backtest.py` on ≥4 weeks of ticks at 20x, zero fees, `--both` to see the fee version side by side. Gate: **positive net per cycle over 200+ cycles**, and positive in ≥3 separate weeks. A few hours of data is not evidence. **Stage 1 — paper live ($0, 2–4 weeks).** `python zec_renko_bot.py` on a machine that stays on. Gate: logged cycles match the backtest's distribution (median ≈ 0, mean ≈ +2 bricks). If live differs from replay, the replay is wrong — stop and fix it. **Stage 2 — real money, tiny ($50–$200 on Lighter at 10–20x).** Purpose is execution truth, not profit. Measure: real fill distance from the line, real slippage, real fee (should be $0.00), missed touches, uptime. Gate: 100+ real trades with fills within your modelled slippage and **zero manual interventions**. **Stage 3 — scale to the venue's impact limit ($1k → $250k notional).** ZEC on Lighter: OI $27.8M, so 1% of OI ≈ **$278k notional** is the ceiling before you are the market. At 20x that is ~$14k of margin. Gate: measured slippage still under 0.01% per order; if it is worse, you are already too big for this asset. **Stage 4 — multi-asset, one venue ($250k → $10M notional).** Same strategy on BTC/ETH/SOL/HYPE/ZEC where each position ≤1% of that asset's OI and ≤1% of its 24h volume. Diversification here is not for returns, it is so no single asset's liquidity is your limit. **Stage 5 — multi-venue (the only way past ~$50M).** Split across Lighter + Hyperliquid + a CEX, deliberately keeping <30% of capital on any one venue (§5). This is a custody decision as much as a trading one. **Stage 6 — $800M.** See §3. Short version: it does not work as perps on one DEX. **The honest arithmetic.** $1 → $800M is 800,000,000×. At +2% per day compounded that is ~1,030 days (2.8 years); at +10%/day it is 210 days; at +100%/month it is ~30 months. Every one of those rates is impossible to hold while scaling, because return-per-cycle is fixed in *price* terms (0.1% = 1 brick) while your size is capped by liquidity at every step. The plan above is the *only* shape that survives: the strategy's edge stays constant, your size grows until impact eats it, then you add assets, then venues. Anyone who tells you the compounding is the hard part has not tried to fill an order. --- ## 3. $800M — what the numbers actually allow Hyperliquid, 11 Nov 2026: total OI **$8.69B**, 24h volume **$6.79B**. Per asset OI: BTC $3.01B, ETH $1.59B, HYPE $1.54B, ZEC $542M, SOL $454M, XRP $161M, XMR $152M. HIP-3 sectors add stocks ($3.4B/day), indices ($1.0B), energy ($472M), metals ($245M) — NVDA $523M/day, SP500 $455M, XYZ100 $584M, SOXL $322M, Brent $244M, CL $194M, AMD $163M. **Sizing rule (use these, not gut feel):** - position ≤ **1% of that asset's 24h volume** - position ≤ **1% of that asset's open interest** - a single market order ≤ **0.1% of the book within ±0.1% of mid** At 1% of OI, the *entire* Hyperliquid book absorbs: BTC $30M + ETH $16M + HYPE $15M + ZEC $5.4M + SOL $4.5M ≈ **$71M of notional** across the liquid five. To hold $800M of notional you would be ~11% of Hyperliquid's total open interest — you would *be* the market, and your own entry would move the price through your line. So the $800M answer, plainly: **not as leveraged perps on one DEX.** The shapes that do work: - $800M as **spot / custody** (no impact at all), with the strategy trading a small perp overlay for yield. - $800M **notional spread over ~12+ days of execution** at ≤1% ADV per day, across venues. - $800M **at 1–2x**, i.e. $400–800M notional, split across BTC/ETH/HYPE and the HIP-3 sectors, each entry clipped into 50–200 orders. At 1x the strategy's 0.1% brick is 0.1%, not 2% — returns fall by 20×, and so does the risk. Max leverage at $800M is not a thing anywhere: at 20x that is $16B notional, twice Hyperliquid's entire open interest. **Max cash that does not move price, by asset (1% of OI):** ZEC on Lighter ≈ $278k; ZEC on Hyperliquid ≈ $5.4M; SOL ≈ $4.5M; HYPE ≈ $15M; ETH ≈ $16M; BTC ≈ $30M. Those are ceilings per position, not per day. --- ## 4. Everything that can stop you (risk register) | # | Risk | What it looks like | Mitigation | |---|---|---|---| | 1 | **Fee drag** | 0.05% × position per order ≈ 95% of one brick | Zero-fee venue (Lighter). This is the #1 killer, proven on real data. | | 2 | **Flash crash / gap through the line** | Price jumps past the line with no trade *at* it → no touch → no exit until the next brick | Resting stop 1 chart-1 brick beyond the line; reconcile state on boot; never rely on the bot being awake | | 3 | **Venue outage** | Lighter had a 4.5h outage on 2025-10-10 during a crash | Keep ≤30% per venue; exchange-side stop so a dead bot is still flat-protected | | 4 | **DEX smart-contract / circuit risk** | 9 audit files, 2 by Nethermind, circuits by zkSecurity; a bug is still possible | Escape hatch (Lighter: verifiable, proven end-to-end by L2BEAT) vs Hyperliquid (8 validators, **no** permissionless exit). Size accordingly | | 5 | **Stage 0 governance** | Lighter's team controls the upgrade path | Treat as a young venue: withdraw profits weekly, keep bulk elsewhere | | 6 | **Sequencer censorship / halt** | Orders stop filling; you are stuck in a position | Stop order on venue; second venue with the opposite hedge ready | | 7 | **Oracle / mark-price divergence** | Liquidation or PnL on a price that never traded | Use venues with robust oracle guards; avoid thin assets | | 8 | **Funding** | Charged on notional, hourly on Lighter (ZEC ≈ 0.0012%/h ≈ 10.5%/yr) | 100 occurrences = 0.12% of notional ≈ **1.2 bricks** of your profit. Real, small, but count it | | 9 | **Slippage / impact** | You are the move once size >1% ADV | Size caps §3, clip entries, measure every fill | | 10 | **Latency** | Lighter Standard has 300ms taker delay; a fast move fills off the line | Accept it: your edge is the brick, not the tick. Do not chase fills | | 11 | **Bot/ops failure** | PC sleeps, power cut, process dies, exception | VPS + systemd restart + heartbeat alert (ntfy) + venue-side stop | | 12 | **API key / wallet compromise** | Withdrawal-enabled key, leaked env file | Self-custody wallet, no seed on the box, API key with trade-only scope, IP allowlist where supported, separate trading wallet | | 13 | **Stablecoin risk** | USDC depeg freezes your margin value | Split collateral; keep some in the settlement asset of each venue | | 14 | **Regulatory / KYC / tax** | Lighter excludes many jurisdictions; perp profits are taxable events | Check your jurisdiction before depositing; log every trade (the bot already writes `events.csv`) | | 15 | **Model/data risk** | Backtest on 7 hours; regime change; edge decay | Weeks of data, walk-forward, no parameter tuning to one week | | 16 | **Correlation** | All sectors fall together; perp longs all stop at once | The strategy is direction-agnostic (it shorts too), but venue-wide gaps hit everything | | 17 | **Wash-trading / listing risk** | Lighter was once delisted by DefiLlama over wash-trading allegations | Do not treat venue volume as gospel; cross-check OI and depth | | 18 | **Tax/record gaps** | Missing fills break your accounting | CSV log per trade, dated, never deleted | **Flash crash, specifically.** Your exit is a *touch*. A crash that gaps through the line prints a chart-3 brick whose range contains the line — which the bot treats as a touch — but the fill is at the far side of the gap. In the artifact's scenario 5 that was 6 bricks, i.e. 0.006 of price. At 75x that is 45% of capital in one event; at 20x, 12%. So: resting stop order, and never more than 20x on an asset you would not hold through a 5% gap. --- ## 5. Venue: Lighter vs Hyperliquid | | **Lighter** | **Hyperliquid** | |---|---|---| | Fee | **0% / 0%** (Standard, 300ms taker) | 0.045% taker / 0.015% maker | | ZEC | yes, 20x, OI $27.8M | yes, 10x, OI $542M, $431M/day | | Custody | Self-custody in Ethereum contracts; **verifiable escape hatch** (ZK proof, no operator cooperation) | Bridge secured by 8 permissioned validators; **no permissionless exit** | | Safety record | 9 audit files (Nethermind core+bridge, zkSecurity circuits), Stage 0 governance, one 4.5h outage (Oct 2025 crash) | Own L1, Zellic bridge audit, $1M bug bounty, never halted | | Depth | Thin outside majors (ZEC OI $27.8M) | Deepest onchain book (BTC OI $3.0B) | | Verdict | **Trade here first.** Zero fees are the strategy's oxygen; keep size under ~$250k per asset | **Scale here later** (10x only on ZEC), and for $800M it is the only venue with the depth | **Is Lighter trusted?** It is the only perp venue where an independent party (L2BEAT, May 2026) reconstructed the emergency-withdrawal proof end to end — meaning if the operator vanishes you can still take your money out without their permission. That is a stronger property than Hyperliquid's (which relies on 8 validators agreeing). But it is Stage 0, the team controls upgrades, it is young, and it had a 4.5-hour outage during a crash. Trust the exit, not the uptime: keep working capital there, profits out weekly. **Recommended split once you are past $1M:** 40% Lighter (fee-free trading), 40% Hyperliquid (depth + reliability), 20% CEX (last-resort liquidity + fiat rails), and never more than 30% of *capital* on one venue. --- ## 6. Alerts without creating a Telegram bot You said you can't make a bot. Then don't: **use ntfy.sh.** No account, no bot, no token — install the app, pick a private topic name, and anything POSTed to `ntfy.sh/` arrives as a phone push. Already wired into the bot: ``` setx NTFY_TOPIC "zec-line-7k9x2-private" # Windows, then reopen the terminal python zec_renko_bot.py ``` Every LONG, SHORT, close (USD + %), cycle profit/loss, hold, gate-on and liquidation is pushed. Telegram still works if you ever do make a bot (`TELEGRAM_BOT_TOKEN` + `TELEGRAM_CHAT_ID`); ntfy is the zero-setup path. Requirements: phone with the app, an unguessable topic name (the topic *is* the password), internet. That's it. --- ## 7. 24/7 hosting No exchange hosts your Python — not Binance, not Lighter, not Hyperliquid. There is no "safe Binance python app". The bot must run on a machine that stays awake: - **Cheapest real option:** a €4–5/month VPS (Hetzner/DigitalOcean), Debian, `systemd` unit with `Restart=always`, `ufw` closed except SSH, key-only SSH. - **Free:** a laptop/desktop that never sleeps, on a UPS, with the OS set to never suspend — but a residential internet drop is the same as an outage. - **Non-negotiable with either:** an exchange-side stop order at the line, so a dead bot is never an unmanaged 20x position; a heartbeat alert if the process dies; and state reconciliation from the exchange on startup (never assume flat). - **Built for life:** log rotation, one CSV of every trade forever, and a monthly restore test. The strategy outlives the bot only if the records do. --- ## 8. Is this HFT? No. High-frequency trading means co-located servers, microsecond latency, and thousands of orders per second competing on queue position. This is **event-driven tick scalping**: your decision points are a handful per hour, and 300ms of venue latency does not change whether a 0.1% brick printed. What it *does* share with HFT is the economics — many small trades where per-trade cost decides the outcome — which is exactly why the fee venue matters more than the latency. --- ## 9. What I did not do, and what is next 1. **Trailing-line exit** so the long runs (median 11 bricks, 6.5% are 50+) are actually captured instead of exiting at the first return. This is the single biggest upside left, and it is a rule change — yours to approve. 2. **Four+ weeks of ticks** in the backtest (`--download` a month; it is several GB). 3. **Live chart in the preview** — done: `live_chart.html` builds all three Renko charts from Binance's public feed in your browser and refreshes every few seconds. 4. **Exchange-side stop + restart reconciliation** before any real size. 5. **Lighter execution layer** (order placement, 0% fee, 20x). The bot keeps every chart in its own memory — it builds the three Renko series from raw trades, so the venue only has to supply a trade stream. It does not need, and does not use, any exchange-provided chart. That is why the identical code can run on Lighter, Paradex, Hyperliquid or Binance.