[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_234":235,"_236":237},"routes/_app.x.$handle.$name",{"_99":98,"_32":44,"_107":89,"_27":108,"_13":14,"_109":-5,"_11":110,"_111":112,"_113":114,"_115":116,"_117":118,"_20":-5,"_119":-5,"_120":-5,"_121":25,"_122":123,"_124":58,"_125":-5,"_126":-5,"_127":128},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_42":43,"_32":44,"_37":45,"_46":-5,"_47":25,"_48":49,"_50":49,"_51":52,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70,"_71":-5,"_72":73,"_74":73,"_75":76,"_77":76,"_78":76,"_79":73,"_80":73,"_81":82,"_83":84,"_85":86,"_87":25},"version",99,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":25,"_27":28,"_29":28},"file",{"_30":31,"_32":28,"_33":20,"_34":36,"_37":38,"_39":14,"_40":41,"_24":25},"previous",{"_30":31,"_32":28,"_33":20,"_34":35},"deleted",false,"deletedHere","path","PROJECT_RULES.md","latestPath","fileId","8c82135a-a905-11f1-bc44-1607ee4eb77e","name","fileType","content","# Hyperliquid / XYZ Project Rules — Persistent Canonical Rules\n\nUpdated: 2026-09-07 JST\n\nThis file contains only reusable trading/workflow rules. It intentionally contains no wallet address, account balances, positions, or private account state.\n\n## Startup procedure for every new chat\n1. Fix current JST time.\n2. If the user reports a position/order change or this is a handoff boundary, run the Val Town script `account_checker.ts` in `kamibaba/hyperliquid-market-bridge` to retrieve live positions/orders and Strategy tracking. Do not use that route for market screening. MicroFn account functions are non-authoritative fallbacks only; do not depend on them for ledger registration or PnL authority.\n3. Retrieve the full current Hyperliquid/HIP-3 universe through `kamibaba/hyperliquid-market-bridge`.\n4. Validate `coverageComplete=true`, `registryVerified=true`, no venue failures, fresh `fetchedAt`, and active/valid counts.\n5. Read all active rows using stored-snapshot pagination; do not claim full-universe screening without reading the full active set.\n6. Screen Long and Short candidates independently, then decide whether the best portfolio should be one-sided or multi-leg. Long+Short is not mandatory.\n7. For finalists, fetch exact-symbol 5m/15m/1h/4h closed candles and L2 book (max two symbols per detailed request).\n8. Check current macro/news/fundamentals where material. Execution levels must use Hyperliquid/XYZ prices, not external cash prices.\n9. Define structural SL and structural TP first, then risk, notional, leverage and margin mode.\n10. Present exact prices, sizes, leverage, margin mode, SL/TP, expiry, cancellation conditions and chase cutoff.\n\n## Market data transport\nVal: `kamibaba/hyperliquid-market-bridge`\nHTTP file: `index.tsx`\nBridge version baseline: `1.2.1` (verify current version if behavior changes)\nUpstream: deployed read-only Netlify Hyperliquid market service.\nNo paid third-party liquidation API is required or configured. Use liquidation data only when it is genuinely available at no added cost or is supplied directly by the user; otherwise proceed without it rather than weakening the setup with an uncertain or paid dependency.\nNo schedules / no automated trading / no wallet data in the market bridge.\n\nTypical calls:\n- `mode=market&limit=0` — refresh all venues.\n- `mode=read&data=market&offset=0&limit=100`, then 100/200/300... until `hasMore=false` — read the same saved snapshot without another upstream collection.\n- `mode=read&data=market&symbols=...` — shortlisted exact rows/deltas.\n- `mode=technical&coins=AAA,BBB` — exact symbols; closed 5m/15m/1h/4h bars + L2 book, max 2 symbols.\n\nNever assume the universe is a fixed count. Discover venues and active markets dynamically each time.\n\n## Account-data route\nThe authoritative account checker is the Val Town script `account_checker.ts` in `kamibaba/hyperliquid-market-bridge`. It is for live position/order verification after reported account changes and handoff boundaries, JST account-wide realized-PnL auditing, and the project-scoped Strategy ledger. Do not use it for broad market screening. The account address is stored in the val environment as `HL_ACCOUNT_ADDRESS`, not in the public market HTTP file.\n\nThe authoritative Strategy ledger is the val-scoped SQLite database in `kamibaba/hyperliquid-market-bridge`, using tables `strategy_oids`, `strategy_tids`, `strategy_seeds`, and `strategy_meta`. `account_checker.ts` returns live `positions`, `openOrders`, account-wide `targetTracking`, Strategy-scoped `strategyTracking`, and recent perp fills with a `tagged` flag. `targetTracking` can include independent discretionary trades. `strategyTracking` is the project authority and includes only fills whose OID/TID is registered in SQLite plus reconstructed funding while a project position is open.\n\nMicroFn account functions are retained only as non-authoritative recovery/audit fallbacks. On 2026-09-07, all three MicroFn execution routes returned generic `Function execution failed` even with a one-line diagnostic function, so ledger/PnL operation MUST NOT depend on MicroFn availability.\n\nWhen the user says an instructed order was placed/modified, immediately run `account_checker.ts`, identify the actual parent/child OIDs and any newly executed TIDs, and write them with parameterized `INSERT OR REPLACE` statements through Val Town `sqlite_batch`. Future fills on registered OIDs are then attributed automatically. For positions carried across a ledger boundary, add one signed row in `strategy_seeds` at the boundary so subsequent funding can be reconstructed. Independent discretionary orders must never be tagged as project orders.\n\nVal Town Strategy authority starts at 2026-09-07 JST. The 2026-09-06 final strict Strategy Net baseline is fixed at `-$2.965045`, producing a 2026-09-07 prior carry-in of `$202.965045`. The carried PUMP short was seeded at the 2026-09-07 00:00 JST boundary. The legacy MicroFn ledger remains untouched for later audit/reconciliation if its execution service recovers.\n\nFor usable new-position headroom, the authoritative value is the Hyperliquid UI `Balances → USDC → Available Balance` / actual order buying power reported by the user. API `withdrawable`, `accountValue`, `marginSummary.accountValue`, and `crossMarginSummary.accountValue` MUST NOT be used to cap or infer new-order headroom. They may be used only for account-state diagnostics. A user-supplied Available Balance is valid only until any margin-changing event occurs: entry/add fill, position-size change, newly accepted margin-reserving order, leverage/margin adjustment, or other event that can change order headroom. After such an event, treat the old UI figure as stale and require a fresh user-visible Available Balance before designing further margin-consuming orders; do not infer fresh headroom merely by subtracting theoretical `notional/leverage`. Position sizing must still be limited by structural stop risk rather than by maximum buying power.\n\n## Portfolio selection\nThe goal is the highest-expectancy portfolio, not preservation of the last favorite symbol.\nConsider:\n- long only\n- short only\n- multiple longs\n- multiple shorts\n- long + short\n- relative-value pairs\n- current-position maintenance/reduction/exit\n\nAlways inspect both Long and Short opportunity sets, but do NOT force a hedge. First assess broad market regime, majors, sector/category/chain rotation and correlation. Independently of any user hint, perform an automatic narrative/theme-discovery pass on every meaningful crypto decision: start from cross-sectional leaders/laggards and short-interval relative performance, cluster symbols by shared tokenomics/chain/sector/catalyst characteristics, then actively verify likely common causes with fresh fundamental/news/flow evidence. Explicitly test themes such as buybacks/burns/value-accrual, unlock/supply overhang, launchpad/memecoin rotation, chain migration/ecosystem rotation, AI/agent, DeFi/RWA, privacy, staking/emissions, and any newly emerging theme suggested by the live leaders; this list is illustrative, not exhaustive. A theme should be promoted when enough leaders/benchmarks show current relative strength plus fresh causal evidence; the trade candidate itself does NOT need to have already accelerated. After a theme is promoted, split the basket into (a) leaders/continuation names and (b) catch-up/laggard candidates. Explicitly compare buying the leader continuation versus buying an unextended laggard that is genuinely exposed to the same catalyst/flow, has no idiosyncratic negative catalyst, retains acceptable 1h/4h structure, has adequate liquidity, and is less crowded on funding/OI. Do not reject a laggard merely because it is flat while leaders are moving; that flatness can be the opportunity. Conversely, never buy a laggard solely because it has not moved—distinguish true catch-up candidates from fundamentally weak non-participants. If the user separately identifies a live theme, treat that as an additional high-priority hypothesis to test, not as the only source of theme discovery. A theme leader that is already extended must not be dismissed solely for being up a lot; evaluate breakout/retest, small-core + pullback-add, and continuation structures so non-fill opportunity cost is modeled. The max-two-symbol technical endpoint is a per-call constraint, not a reason to skip serial detailed checks on additional high-priority theme finalists.\n\nFor crypto, explicitly classify the broad regime BEFORE selecting directional trades using at minimum BTC/ETH/SOL/BNB relative strength, 5m/15m/1h/4h trend context, breadth across major Layer-1/DeFi/meme clusters, funding/OI where available, and current macro/flow/fundamental context. A sharp short-term decline in one or two majors must not by itself flip the broad regime to bearish when market breadth and higher-timeframe structure remain risk-on. If most majors/major-alt clusters are positive and higher-timeframe structure is still up, do not build a multi-leg net-short portfolio unless it is explicitly a relative-value/hedged construction with controlled net beta.\n\nIf Long+Short is used, size by structural-stop risk contribution and correlation/beta, not equal dollar notional. Highly correlated instruments that express the same underlying thesis (for example WTI + Brent, BTC + ETH beta longs, or multiple names driven by the same single catalyst) must be treated as one risk bucket for portfolio risk and daily-capacity stress tests. Do not count their profit capacities as fully independent when applying the single-largest-independent-setup-failure test, and cap aggregate stop/gap risk at the bucket level rather than per symbol.\n\nDirectional concentration is not a defect by itself. If the broad market regime and the best independent setups all point the same way, a one-sided portfolio (all LONG or all SHORT) may be optimal. Never add an opposite-direction position merely to create visual balance, reduce net exposure mechanically, or satisfy a hedge quota; in a persistent trend this creates predictable drag and can guarantee that one side loses. Regime-aligned trades use the normal entry standard: in a clearly bullish regime, LONGs do not require a special idiosyncratic catalyst beyond a valid setup; in a clearly bearish regime, SHORTs do not require one. Counter-regime trades require materially stronger independent evidence: e.g. clear relative weakness/strength plus a specific fundamental, flow, supply-demand, catalyst, or structural reason that explains why that asset should diverge from the broad market. Apply this symmetrically: bullish regime -> SHORT needs extra justification; bearish regime -> LONG needs extra justification. Same-direction additions are restricted only when they are duplicative/highly correlated without incremental expectancy or push aggregate structural-stop risk above the chosen risk budget. Portfolio direction must follow regime + expectancy, not forced symmetry.\n\nIf one leg's thesis breaks, close/reduce that leg; do not keep a broken long merely because a short hedge exists.\n\n## Crypto-specific behavior\nDo not apply stock logic mechanically to crypto. Include:\n- weekend alt rotations / “alt hour” behavior\n- chain/category/theme capital rotation\n- short/long squeeze risk\n- funding crowding\n- OI changes\n- Mark/Oracle premium\n- liquidity / spread / order book\n- liquidation data only when actually available. When a verified liquidation heatmap / liquidation-level source is available (including a user-supplied CoinGlass screenshot or a fetched API/source), use it as a secondary liquidity-map input: distinguish overhead short-liquidation clusters from downside long-liquidation clusters where possible, compare distance/size with current trend, funding/OI, book and ATR, and use nearby clusters to refine continuation probability, TP/scale-out and squeeze risk. Do not describe estimated heatmap bands as guaranteed actual liquidations or proof of deliberate \"liquidation hunting\"; they are modeled potential concentration zones, not deterministic targets. In a trend-aligned setup, nearby liquidation clusters in the direction of travel can increase continuation expectancy, but never use them as the sole entry thesis.\n- BTC/ETH relative strength and alt divergence\n\nFunding sign alone is never an entry signal. OI changes alone do not identify directional initiators.\n\n## Entry execution\nExecution choice is part of expectancy. Compare:\n- marketable core\n- single limit\n- manual limit ladder\n- core + ladder\n- breakout core + retest add\n- scale-out on exits\n\nDo not default to one “perfect” limit. Model non-fill opportunity cost.\n\nUse a small Core when momentum/hedge urgency makes waiting costly. Do not chase if already directionally exposed and pullback RR is better.\n\nThe default actionable entry must be placeable immediately without requiring the user to watch for a later candle close, reclaim, or other manual confirmation trigger. Prefer resting Limit / ladder / core+ladder orders with hard attached protection. If a setup is only valid after later confirmation, either choose another immediately placeable symbol from the full universe or label it watch-only rather than making it the primary instruction. Do not require continuous screen-watching.\n\nFor catalyst-driven crypto that has already made a sharp extension, do not treat the catalyst alone as permission to passively buy a pullback. If lower-timeframe rollover makes a passive Limit a falling-knife entry, choose a different symbol/setup that supports a structurally protected resting order rather than requiring the user to wait for a manual confirmation trigger. A scheduled buyback/reserve purchase with undisclosed size is qualitative support, not a quantitatively guaranteed bid. For scheduled tokenomics events such as unlocks, claims, emissions changes or burns, re-verify the event's current status and timestamp before demoting or replacing an otherwise stronger setup; do not treat a stale \"today/upcoming\" page state as proof that the event is still ahead. If the event status is genuinely uncertain but the asset remains a regime-aligned leader with strong multi-timeframe structure and positive value-accrual/flow support, manage the uncertainty through smaller Core size, wider structural risk allowance or delayed adds rather than automatically replacing it with a weaker asset. When momentum is strong and passive pullback entries risk non-fill, explicitly compare a small marketable Core + deeper adds against an all-limit ladder.\n\nBefore placing a structural stop around a support/resistance level, compare the buffer beyond that level with current 5m/15m ATR, spread, and plausible stop-market slippage. If the invalidation requires a wider stop, reduce size rather than moving the stop inside normal noise. When a first tranche is losing momentum into support, do not automatically add solely because price reaches the planned level. If fast downside momentum makes passive averaging materially worse, cancel/omit the add and choose a different immediately placeable setup rather than requiring the user to wait for a manual confirmation trigger.\n\n## Native Scale orders\nUser's Hyperliquid UI cannot attach SL/TP while creating a native Scale entry.\nTherefore:\n- do not use native Scale as the default way to open a fresh unprotected position;\n- prefer normal Limit ladder entries with protection;\n- native Scale is primarily for Reduce-Only scale-out / partial profit taking;\n- native Scale add is acceptable only if an already-active Position SL demonstrably covers the additional filled size.\n\nFixed-size reduce-only TPs do not auto-resize after position additions. Recalculate after fills. Position TP/SL can manage the remaining position dynamically.\n\nFor an unattended multi-entry ladder that belongs to one thesis, do not place any pending re-entry beyond another tranche's hard SL. LONG: every planned buy Entry must remain above the shared structural SL. SHORT: every planned sell Entry must remain below the shared structural SL. Otherwise the sequence can become stop-out followed by automatic re-entry, which is contradictory for a single thesis. If different tranches genuinely use different invalidations, treat and label them as separate independent setups; do not present them as one ladder. Prefer a common structural SL for a single unattended ladder, with size adjusted so the shared stop remains acceptable.\n\nWhen the user says they are going to sleep, going offline, or otherwise cannot monitor the position, switch to **sleep/unattended mode**. Default behavior is: cancel all pending entry/add orders and leave only already-open positions with verified hard SL/TP protection. Do not allow a position to increase automatically while the user is asleep merely because a preplanned adverse-price add is reached. An overnight pending entry/add is exceptional and requires explicit justification that (a) the setup remains valid without future discretionary confirmation, (b) worst-case all-fill structural/gap risk is acceptable as one unattended portfolio, (c) correlated risk buckets are already aggregated, and (d) no stale Available Balance is being reused. If those conditions are not proven, no overnight adds.\n\nHyperliquid TP/SL trigger orders are triggered by **Mark Price**, not by the last trade / TradingView candle price. Therefore a candle wick can pass through a TP trigger level without the TP firing if Mark Price never crosses the trigger. When the goal is to capture a trade-price touch/wick at a profit target, prefer a resting Reduce-Only Limit (or Reduce-Only Scale exit) rather than a TP trigger order. Keep trigger-market orders for protection when Mark-based activation is desired.\n\nWhen an intermediate TP executes, cancel stale unfilled add orders if they could rebuild the position after profit taking.\n\n## Margin and leverage\nDecision order:\n1. thesis\n2. entry\n3. structural SL\n4. structural TP\n5. max acceptable loss\n6. notional\n7. leverage + Cross/Isolated\n\nFor fixed notional and SL, increasing leverage does not itself increase stop-loss dollars; it changes margin efficiency and liquidation distance.\n\nFor existing Isolated positions, increasing the leverage setting may NOT automatically release previously allocated isolated margin. Check/remove isolated margin separately when appropriate.\n\nChoose leverage so liquidation remains safely beyond structural SL after allowing for slippage, gaps, Mark moves and volatility. Do not use unnecessarily low leverage if it only locks capital without lowering the defined risk.\n\nCross can be efficient for portfolio-level offsets but shares equity risk. Isolated contains idiosyncratic failures. Neither mode changes the requirement for a structural hard stop.\n\n## SL / TP / sizing\nStructural invalidation first. Do not place stops merely “close” to make risk small.\nUse 4h/1h/15m/5m structure and ATR context; 1m is execution detail, not thesis invalidation.\n\nTPs come from market structure, not the daily dollar goal. Consider resistance/support, prior highs/lows, breakouts, volume/liquidation levels when actually available, and scale-out to reduce near-miss risk.\n\nSize from max loss divided by stop distance. Daily target does not determine notional.\n\n## Fees\nPrefer the user's actual observed fee tier. Known historical observed rates were roughly taker 0.0081% and maker 0.0027%; re-check if needed.\nEvaluate Net PnL after fees, funding and slippage.\n\n## Daily target\nUser target: at least Net +$200 per JST day effective 2026-09-06 JST. The prior base target remains $100 for 2026-09-04 and 2026-09-05, but the user explicitly reset carry at the start of 2026-09-06: the 2026-09-06 required target is a clean $200 with no prior carry-in. From 2026-09-06 onward, new shortfalls roll fully into the next day; profit above the required amount clears carry but does not reduce the next day's applicable base target.\n\n$200 is a minimum realized Strategy Net threshold, not the profit-capacity planning ceiling. A set presented as capable of completing the day must include headroom for non-fills, partial fills, fees, funding, slippage and targets that narrowly miss. As a default completion-capacity gate, require prospective net profit capacity of at least `max(remaining strategy target × 1.50, remaining strategy target + $50)` from the still-open/planned opportunities. In addition, stress-test whether the day can still plausibly reach $200 if the single largest independent setup fails while the others behave as planned. If either the 50% headroom gate or the single-largest-setup-failure test cannot be supported by high-EV setups, label the set as an intermediate cycle and re-screen/redeploy sequentially; never mechanically enlarge risk solely to satisfy the buffer arithmetic.\n\nFor audit, Val Town `account_checker.ts` computes ACCOUNT-WIDE JST 00:00→now strict realized perp Net PnL as `sum(closedPnl) - sum(USDC trading fee) + sum(userFunding delta.usdc)`. It excludes spot fills and does not count unrealized PnL. This is useful for reconciliation but may include the user's independent discretionary trades.\n\nThe project's minimum daily goal must use Val Town SQLite-backed `strategyTracking`, a separate STRATEGY-SCOPED net PnL that includes only fills/funding/fees attributable to registered project OIDs/TIDs plus seeded carried positions. Discretionary trades such as the user's 2026-09-04 SOFTBANK trade must not count toward project performance. Maintain account-wide `targetTracking` and project-wide `strategyTracking` separately; never silently substitute one for the other.\n\nFrom 2026-09-07 JST onward, `account_checker.ts` + val-scoped SQLite is the authoritative remaining-target transport. Its 2026-09-07 starting carry is `$202.965045`, derived from the fixed 2026-09-06 final strict Strategy Net baseline `-$2.965045`. Never distort SL, TP, leverage or position size merely to hit the target, but do check whether planned trades have realistic profit capacity relative to the remaining target. If a proposed order set cannot realistically cover the remaining target, explicitly label it as an intermediate cycle rather than presenting it as a complete daily-target plan.\n\n## Time budget\nBefore committing to a trade, estimate whether its target is a scalp, 1–6 hour trade, or potentially beyond the current day. Do not rely on a single slow trade if its realistic maximum profit is far below the remaining daily target; continue screening independent high-quality opportunities in parallel, without forcing trades.\n\n## Final answer format\nFor each actionable leg include exact:\n- Symbol / direction\n- Core entry and notional/quantity\n- Add entries\n- Max total notional\n- Leverage\n- Cross/Isolated\n- Hard SL and order type\n- TP1/TP2/final TP + allocations\n- Reduce Only\n- order expiry\n- cancellation condition\n- chase cutoff\n- partial-fill handling\n- max stop risk / net RR estimate\n\nDo not leave percentages for the user to convert into actual prices.\n\n## Change management\nUpdate this canonical file only for persistent rule/process changes, tool/transport changes, or newly learned platform mechanics. Do not persist live positions here; live account state is always re-fetched because stored positions become stale.\n\n\n## Persistent private handoff state\nThe latest account-specific handoff is stored in this val's **project-scoped blob storage**, not in a public file.\n\n- Blob key: `project:hyperliquid:authoritative-handoff:current`\n- Read it with the connected Val Town `readBlob` tool using storage `{type:\"val\", val:\"kamibaba/hyperliquid-market-bridge\"}`.\n- It contains the latest handoff snapshot, resolved/closed trade context, the public account address needed by the read-only checker, and the startup checklist.\n- It is **not** exposed by the public market HTTP endpoint.\n- Stored positions/prices are a handoff snapshot only. At the start of a new chat, immediately re-fetch live positions/orders and live markets; live values override the blob.\n- Update the blob at major handoff boundaries or when important project state/rules change. Ordinary fills can be recovered from the live account checker and do not require rewriting the public rules file every time.\n","# Hyperliquid / XYZ Project Rules — Persistent Canonical Rules\n\nUpdated: 2026-09-07 JST\n\nThis file contains only reusable trading/workflow rules. It intentionally contains no wallet address, account balances, positions, or private account state.\n\n## Startup procedure for every new chat\n1. Fix current JST time.\n2. If the user reports a position/order change or this is a handoff boundary, run the Val Town script `account_checker.ts` in `kamibaba/hyperliquid-market-bridge` to retrieve live positions/orders and Strategy tracking. Do not use that route for market screening. MicroFn account functions are non-authoritative fallbacks only; do not depend on them for ledger registration or PnL authority.\n3. Retrieve the full current Hyperliquid/HIP-3 universe through `kamibaba/hyperliquid-market-bridge`.\n4. Validate `coverageComplete=true`, `registryVerified=true`, no venue failures, fresh `fetchedAt`, and active/valid counts.\n5. Read all active rows using stored-snapshot pagination; do not claim full-universe screening without reading the full active set.\n6. Screen Long and Short candidates independently, then decide whether the best portfolio should be one-sided or multi-leg. Long+Short is not mandatory.\n7. For finalists, fetch exact-symbol 5m/15m/1h/4h closed candles and L2 book (max two symbols per detailed request).\n8. Check current macro/news/fundamentals where material. Execution levels must use Hyperliquid/XYZ prices, not external cash prices.\n9. Define structural SL and structural TP first, then risk, notional, leverage and margin mode.\n10. Present exact prices, sizes, leverage, margin mode, SL/TP, expiry, cancellation conditions and chase cutoff.\n\n## Market data transport\nVal: `kamibaba/hyperliquid-market-bridge`\nHTTP file: `index.tsx`\nBridge version baseline: `1.2.1` (verify current version if behavior changes)\nUpstream: deployed read-only Netlify Hyperliquid market service.\nNo paid third-party liquidation API is required or configured. Use liquidation data only when it is genuinely available at no added cost or is supplied directly by the user; otherwise proceed without it rather than weakening the setup with an uncertain or paid dependency.\nNo schedules / no automated trading / no wallet data in the market bridge.\n\nTypical calls:\n- `mode=market&limit=0` — refresh all venues.\n- `mode=read&data=market&offset=0&limit=100`, then 100/200/300... until `hasMore=false` — read the same saved snapshot without another upstream collection.\n- `mode=read&data=market&symbols=...` — shortlisted exact rows/deltas.\n- `mode=technical&coins=AAA,BBB` — exact symbols; closed 5m/15m/1h/4h bars + L2 book, max 2 symbols.\n\nNever assume the universe is a fixed count. Discover venues and active markets dynamically each time.\n\n## Account-data route\nThe authoritative account checker is the Val Town script `account_checker.ts` in `kamibaba/hyperliquid-market-bridge`. It is for live position/order verification after reported account changes and handoff boundaries, JST account-wide realized-PnL auditing, and the project-scoped Strategy ledger. Do not use it for broad market screening. The account address is stored in the val environment as `HL_ACCOUNT_ADDRESS`, not in the public market HTTP file.\n\nThe authoritative Strategy ledger is the val-scoped SQLite database in `kamibaba/hyperliquid-market-bridge`, using tables `strategy_oids`, `strategy_tids`, `strategy_seeds`, and `strategy_meta`. `account_checker.ts` returns live `positions`, `openOrders`, account-wide `targetTracking`, Strategy-scoped `strategyTracking`, and recent perp fills with a `tagged` flag. `targetTracking` can include independent discretionary trades. `strategyTracking` is the project authority and includes only fills whose OID/TID is registered in SQLite plus reconstructed funding while a project position is open.\n\nMicroFn account functions are retained only as non-authoritative recovery/audit fallbacks. On 2026-09-07, all three MicroFn execution routes returned generic `Function execution failed` even with a one-line diagnostic function, so ledger/PnL operation MUST NOT depend on MicroFn availability.\n\nWhen the user says an instructed order was placed/modified, immediately run `account_checker.ts`, identify the actual parent/child OIDs and any newly executed TIDs, and write them with parameterized `INSERT OR REPLACE` statements through Val Town `sqlite_batch`. Future fills on registered OIDs are then attributed automatically. For positions carried across a ledger boundary, add one signed row in `strategy_seeds` at the boundary so subsequent funding can be reconstructed. Independent discretionary orders must never be tagged as project orders.\n\nVal Town Strategy authority starts at 2026-09-07 JST. The 2026-09-06 final strict Strategy Net baseline is fixed at `-$2.965045`, producing a 2026-09-07 prior carry-in of `$202.965045`. The carried PUMP short was seeded at the 2026-09-07 00:00 JST boundary. The legacy MicroFn ledger remains untouched for later audit/reconciliation if its execution service recovers.\n\nFor usable new-position headroom, the authoritative value is the Hyperliquid UI `Balances → USDC → Available Balance` / actual order buying power reported by the user. API `withdrawable`, `accountValue`, `marginSummary.accountValue`, and `crossMarginSummary.accountValue` MUST NOT be used to cap or infer new-order headroom. They may be used only for account-state diagnostics. A user-supplied Available Balance is valid only until any margin-changing event occurs: entry/add fill, position-size change, newly accepted margin-reserving order, leverage/margin adjustment, or other event that can change order headroom. After such an event, treat the old UI figure as stale and require a fresh user-visible Available Balance before designing further margin-consuming orders; do not infer fresh headroom merely by subtracting theoretical `notional/leverage`. Position sizing must still be limited by structural stop risk rather than by maximum buying power.\n\n## Portfolio selection\nThe goal is the highest-expectancy portfolio, not preservation of the last favorite symbol.\nConsider:\n- long only\n- short only\n- multiple longs\n- multiple shorts\n- long + short\n- relative-value pairs\n- current-position maintenance/reduction/exit\n\nAlways inspect both Long and Short opportunity sets, but do NOT force a hedge. First assess broad market regime, majors, sector/category/chain rotation and correlation. Independently of any user hint, perform an automatic narrative/theme-discovery pass on every meaningful crypto decision: start from cross-sectional leaders/laggards and short-interval relative performance, cluster symbols by shared tokenomics/chain/sector/catalyst characteristics, then actively verify likely common causes with fresh fundamental/news/flow evidence. Explicitly test themes such as buybacks/burns/value-accrual, unlock/supply overhang, launchpad/memecoin rotation, chain migration/ecosystem rotation, AI/agent, DeFi/RWA, privacy, staking/emissions, and any newly emerging theme suggested by the live leaders; this list is illustrative, not exhaustive. A theme should be promoted when enough leaders/benchmarks show current relative strength plus fresh causal evidence; the trade candidate itself does NOT need to have already accelerated. After a theme is promoted, split the basket into (a) leaders/continuation names and (b) catch-up/laggard candidates. Explicitly compare buying the leader continuation versus buying an unextended laggard that is genuinely exposed to the same catalyst/flow, has no idiosyncratic negative catalyst, retains acceptable 1h/4h structure, has adequate liquidity, and is less crowded on funding/OI. Do not reject a laggard merely because it is flat while leaders are moving; that flatness can be the opportunity. Conversely, never buy a laggard solely because it has not moved—distinguish true catch-up candidates from fundamentally weak non-participants. If the user separately identifies a live theme, treat that as an additional high-priority hypothesis to test, not as the only source of theme discovery. A theme leader that is already extended must not be dismissed solely for being up a lot; evaluate breakout/retest, small-core + pullback-add, and continuation structures so non-fill opportunity cost is modeled. The max-two-symbol technical endpoint is a per-call constraint, not a reason to skip serial detailed checks on additional high-priority theme finalists.\n\nFor crypto, explicitly classify the broad regime BEFORE selecting directional trades using at minimum BTC/ETH/SOL/BNB relative strength, 5m/15m/1h/4h trend context, breadth across major Layer-1/DeFi/meme clusters, funding/OI where available, and current macro/flow/fundamental context. A sharp short-term decline in one or two majors must not by itself flip the broad regime to bearish when market breadth and higher-timeframe structure remain risk-on. If most majors/major-alt clusters are positive and higher-timeframe structure is still up, do not build a multi-leg net-short portfolio unless it is explicitly a relative-value/hedged construction with controlled net beta.\n\nFor any trade whose thesis is causally derived from another symbol, theme leader, catalyst or flow source, explicitly record that dependency and keep re-checking it while the trade is open or while adds remain pending. The dependent trade's own technical trend is not sufficient to preserve the thesis if the causal driver has materially changed. Example: if PUMP weakness is attributed to selling in PONS or another related leader, then PONS stabilization/sideways action, reversal, or broad-market risk-on strengthening is a mandatory thesis re-check. When the causal driver stops confirming, first cancel pending adds; then reassess whether to reduce/exit the dependent position even if its own 15m/1h/4h trend still points the original way. Never keep adding merely because the dependent symbol remains technically down/up after the original causal impulse has faded.\n\nIf Long+Short is used, size by structural-stop risk contribution and correlation/beta, not equal dollar notional. Highly correlated instruments that express the same underlying thesis (for example WTI + Brent, BTC + ETH beta longs, or multiple names driven by the same single catalyst) must be treated as one risk bucket for portfolio risk and daily-capacity stress tests. Do not count their profit capacities as fully independent when applying the single-largest-independent-setup-failure test, and cap aggregate stop/gap risk at the bucket level rather than per symbol.\n\nDirectional concentration is not a defect by itself. If the broad market regime and the best independent setups all point the same way, a one-sided portfolio (all LONG or all SHORT) may be optimal. Never add an opposite-direction position merely to create visual balance, reduce net exposure mechanically, or satisfy a hedge quota; in a persistent trend this creates predictable drag and can guarantee that one side loses. Regime-aligned trades use the normal entry standard: in a clearly bullish regime, LONGs do not require a special idiosyncratic catalyst beyond a valid setup; in a clearly bearish regime, SHORTs do not require one. Counter-regime trades require materially stronger independent evidence: e.g. clear relative weakness/strength plus a specific fundamental, flow, supply-demand, catalyst, or structural reason that explains why that asset should diverge from the broad market. Apply this symmetrically: bullish regime -> SHORT needs extra justification; bearish regime -> LONG needs extra justification. Same-direction additions are restricted only when they are duplicative/highly correlated without incremental expectancy or push aggregate structural-stop risk above the chosen risk budget. Portfolio direction must follow regime + expectancy, not forced symmetry.\n\nIf one leg's thesis breaks, close/reduce that leg; do not keep a broken long merely because a short hedge exists.\n\n## Crypto-specific behavior\nDo not apply stock logic mechanically to crypto. Include:\n- weekend alt rotations / “alt hour” behavior\n- chain/category/theme capital rotation\n- short/long squeeze risk\n- funding crowding\n- OI changes\n- Mark/Oracle premium\n- liquidity / spread / order book\n- liquidation data only when actually available. When a verified liquidation heatmap / liquidation-level source is available (including a user-supplied CoinGlass screenshot or a fetched API/source), use it as a secondary liquidity-map input: distinguish overhead short-liquidation clusters from downside long-liquidation clusters where possible, compare distance/size with current trend, funding/OI, book and ATR, and use nearby clusters to refine continuation probability, TP/scale-out and squeeze risk. Do not describe estimated heatmap bands as guaranteed actual liquidations or proof of deliberate \"liquidation hunting\"; they are modeled potential concentration zones, not deterministic targets. In a trend-aligned setup, nearby liquidation clusters in the direction of travel can increase continuation expectancy, but never use them as the sole entry thesis.\n- BTC/ETH relative strength and alt divergence\n\nFunding sign alone is never an entry signal. OI changes alone do not identify directional initiators.\n\n## Entry execution\nExecution choice is part of expectancy. Compare:\n- marketable core\n- single limit\n- manual limit ladder\n- core + ladder\n- breakout core + retest add\n- scale-out on exits\n\nDo not default to one “perfect” limit. Model non-fill opportunity cost.\n\nUse a small Core when momentum/hedge urgency makes waiting costly. Do not chase if already directionally exposed and pullback RR is better.\n\nThe default actionable entry must be placeable immediately without requiring the user to watch for a later candle close, reclaim, or other manual confirmation trigger. Prefer resting Limit / ladder / core+ladder orders with hard attached protection. If a setup is only valid after later confirmation, either choose another immediately placeable symbol from the full universe or label it watch-only rather than making it the primary instruction. Do not require continuous screen-watching.\n\nFor catalyst-driven crypto that has already made a sharp extension, do not treat the catalyst alone as permission to passively buy a pullback. If lower-timeframe rollover makes a passive Limit a falling-knife entry, choose a different symbol/setup that supports a structurally protected resting order rather than requiring the user to wait for a manual confirmation trigger. A scheduled buyback/reserve purchase with undisclosed size is qualitative support, not a quantitatively guaranteed bid. For scheduled tokenomics events such as unlocks, claims, emissions changes or burns, re-verify the event's current status and timestamp before demoting or replacing an otherwise stronger setup; do not treat a stale \"today/upcoming\" page state as proof that the event is still ahead. If the event status is genuinely uncertain but the asset remains a regime-aligned leader with strong multi-timeframe structure and positive value-accrual/flow support, manage the uncertainty through smaller Core size, wider structural risk allowance or delayed adds rather than automatically replacing it with a weaker asset. When momentum is strong and passive pullback entries risk non-fill, explicitly compare a small marketable Core + deeper adds against an all-limit ladder.\n\nBefore placing a structural stop around a support/resistance level, compare the buffer beyond that level with current 5m/15m ATR, spread, and plausible stop-market slippage. If the invalidation requires a wider stop, reduce size rather than moving the stop inside normal noise. When a first tranche is losing momentum into support, do not automatically add solely because price reaches the planned level. If fast downside momentum makes passive averaging materially worse, cancel/omit the add and choose a different immediately placeable setup rather than requiring the user to wait for a manual confirmation trigger.\n\n## Native Scale orders\nUser's Hyperliquid UI cannot attach SL/TP while creating a native Scale entry.\nTherefore:\n- do not use native Scale as the default way to open a fresh unprotected position;\n- prefer normal Limit ladder entries with protection;\n- native Scale is primarily for Reduce-Only scale-out / partial profit taking;\n- native Scale add is acceptable only if an already-active Position SL demonstrably covers the additional filled size.\n\nFixed-size reduce-only TPs do not auto-resize after position additions. Recalculate after fills. Position TP/SL can manage the remaining position dynamically.\n\nFor an unattended multi-entry ladder that belongs to one thesis, do not place any pending re-entry beyond another tranche's hard SL. LONG: every planned buy Entry must remain above the shared structural SL. SHORT: every planned sell Entry must remain below the shared structural SL. Otherwise the sequence can become stop-out followed by automatic re-entry, which is contradictory for a single thesis. If different tranches genuinely use different invalidations, treat and label them as separate independent setups; do not present them as one ladder. Prefer a common structural SL for a single unattended ladder, with size adjusted so the shared stop remains acceptable.\n\nWhen the user says they are going to sleep, going offline, or otherwise cannot monitor the position, switch to **sleep/unattended mode**. Default behavior is: cancel all pending entry/add orders and leave only already-open positions with verified hard SL/TP protection. Do not allow a position to increase automatically while the user is asleep merely because a preplanned adverse-price add is reached. An overnight pending entry/add is exceptional and requires explicit justification that (a) the setup remains valid without future discretionary confirmation, (b) worst-case all-fill structural/gap risk is acceptable as one unattended portfolio, (c) correlated risk buckets are already aggregated, and (d) no stale Available Balance is being reused. If those conditions are not proven, no overnight adds.\n\nHyperliquid TP/SL trigger orders are triggered by **Mark Price**, not by the last trade / TradingView candle price. Therefore a candle wick can pass through a TP trigger level without the TP firing if Mark Price never crosses the trigger. When the goal is to capture a trade-price touch/wick at a profit target, prefer a resting Reduce-Only Limit (or Reduce-Only Scale exit) rather than a TP trigger order. Keep trigger-market orders for protection when Mark-based activation is desired.\n\nWhen an intermediate TP executes, cancel stale unfilled add orders if they could rebuild the position after profit taking.\n\n## Margin and leverage\nDecision order:\n1. thesis\n2. entry\n3. structural SL\n4. structural TP\n5. max acceptable loss\n6. notional\n7. leverage + Cross/Isolated\n\nFor fixed notional and SL, increasing leverage does not itself increase stop-loss dollars; it changes margin efficiency and liquidation distance.\n\nFor existing Isolated positions, increasing the leverage setting may NOT automatically release previously allocated isolated margin. Check/remove isolated margin separately when appropriate.\n\nChoose leverage so liquidation remains safely beyond structural SL after allowing for slippage, gaps, Mark moves and volatility. Do not use unnecessarily low leverage if it only locks capital without lowering the defined risk.\n\nCross can be efficient for portfolio-level offsets but shares equity risk. Isolated contains idiosyncratic failures. Neither mode changes the requirement for a structural hard stop.\n\n## SL / TP / sizing\nStructural invalidation first. Do not place stops merely “close” to make risk small.\nUse 4h/1h/15m/5m structure and ATR context; 1m is execution detail, not thesis invalidation.\n\nTPs come from market structure, not the daily dollar goal. Consider resistance/support, prior highs/lows, breakouts, volume/liquidation levels when actually available, and scale-out to reduce near-miss risk.\n\nSize from max loss divided by stop distance. Daily target does not determine notional.\n\n## Fees\nPrefer the user's actual observed fee tier. Known historical observed rates were roughly taker 0.0081% and maker 0.0027%; re-check if needed.\nEvaluate Net PnL after fees, funding and slippage.\n\n## Daily target\nUser target: at least Net +$200 per JST day effective 2026-09-06 JST. The prior base target remains $100 for 2026-09-04 and 2026-09-05, but the user explicitly reset carry at the start of 2026-09-06: the 2026-09-06 required target is a clean $200 with no prior carry-in. From 2026-09-06 onward, new shortfalls roll fully into the next day; profit above the required amount clears carry but does not reduce the next day's applicable base target.\n\n$200 is a minimum realized Strategy Net threshold, not the profit-capacity planning ceiling. A set presented as capable of completing the day must include headroom for non-fills, partial fills, fees, funding, slippage and targets that narrowly miss. As a default completion-capacity gate, require prospective net profit capacity of at least `max(remaining strategy target × 1.50, remaining strategy target + $50)` from the still-open/planned opportunities. In addition, stress-test whether the day can still plausibly reach $200 if the single largest independent setup fails while the others behave as planned. If either the 50% headroom gate or the single-largest-setup-failure test cannot be supported by high-EV setups, label the set as an intermediate cycle and re-screen/redeploy sequentially; never mechanically enlarge risk solely to satisfy the buffer arithmetic.\n\nFor audit, Val Town `account_checker.ts` computes ACCOUNT-WIDE JST 00:00→now strict realized perp Net PnL as `sum(closedPnl) - sum(USDC trading fee) + sum(userFunding delta.usdc)`. It excludes spot fills and does not count unrealized PnL. This is useful for reconciliation but may include the user's independent discretionary trades.\n\nThe project's minimum daily goal must use Val Town SQLite-backed `strategyTracking`, a separate STRATEGY-SCOPED net PnL that includes only fills/funding/fees attributable to registered project OIDs/TIDs plus seeded carried positions. Discretionary trades such as the user's 2026-09-04 SOFTBANK trade must not count toward project performance. Maintain account-wide `targetTracking` and project-wide `strategyTracking` separately; never silently substitute one for the other.\n\nFrom 2026-09-07 JST onward, `account_checker.ts` + val-scoped SQLite is the authoritative remaining-target transport. Its 2026-09-07 starting carry is `$202.965045`, derived from the fixed 2026-09-06 final strict Strategy Net baseline `-$2.965045`. Never distort SL, TP, leverage or position size merely to hit the target, but do check whether planned trades have realistic profit capacity relative to the remaining target. If a proposed order set cannot realistically cover the remaining target, explicitly label it as an intermediate cycle rather than presenting it as a complete daily-target plan.\n\n## Time budget\nBefore committing to a trade, estimate whether its target is a scalp, 1–6 hour trade, or potentially beyond the current day. Do not rely on a single slow trade if its realistic maximum profit is far below the remaining daily target; continue screening independent high-quality opportunities in parallel, without forcing trades.\n\n## Final answer format\nFor each actionable leg include exact:\n- Symbol / direction\n- Core entry and notional/quantity\n- Add entries\n- Max total notional\n- Leverage\n- Cross/Isolated\n- Hard SL and order type\n- TP1/TP2/final TP + allocations\n- Reduce Only\n- order expiry\n- cancellation condition\n- chase cutoff\n- partial-fill handling\n- max stop risk / net RR estimate\n\nDo not leave percentages for the user to convert into actual prices.\n\n## Change management\nUpdate this canonical file only for persistent rule/process changes, tool/transport changes, or newly learned platform mechanics. Do not persist live positions here; live account state is always re-fetched because stored positions become stale.\n\n\n## Persistent private handoff state\nThe latest account-specific handoff is stored in this val's **project-scoped blob storage**, not in a public file.\n\n- Blob key: `project:hyperliquid:authoritative-handoff:current`\n- Read it with the connected Val Town `readBlob` tool using storage `{type:\"val\", val:\"kamibaba/hyperliquid-market-bridge\"}`.\n- It contains the latest handoff snapshot, resolved/closed trade context, the public account address needed by the read-only checker, and the startup checklist.\n- It is **not** exposed by the public market HTTP endpoint.\n- Stored positions/prices are a handoff snapshot only. At the start of a new chat, immediately re-fetch live positions/orders and live markets; live values override the blob.\n- Update the blob at major handoff boundaries or when important project state/rules change. Ordinary fills can be recovered from the live account checker and do not require rewriting the public rules file every time.\n","createdAt",["D",1788742001148],"branchVersion","branchId","9b5029ed-e69a-483d-8cb3-234853c9a254","id","87f5b472-21e5-4767-9ac3-e191e3944e56","hyperliquid-market-bridge",["D",1788584474524],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","Public market data only; on demand; no trading.","imageUrl","0e061ab1-2aec-4517-be54-467ef7fcb625","pinnedFileId","01a06ff1-37fe-726c-835e-8d7a62a2a226","pinPreview",true,"pinMigrated","screenshotVersion","likeCount",0,"orgId","01a06fee-2d51-773c-94a7-f1125fac90b4","tursoName","87f5b47221e547679ac3e191e3944e56","tursoHostname","87f5b47221e547679ac3e191e3944e56-val-town.aws-us-east-2.turso.io","tursoMeasuredAt",["D",1789491713377],"pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_99":98,"_106":102},"org",{"_99":98,"_100":98,"_101":102,"_18":54,"_103":104,"_105":25},"branch",{"_13":88,"_32":89,"_42":41,"_90":43,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":44,"_97":98},"isOwned",187,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","kamibaba","handle","displayName","avatar","https://avatars.githubusercontent.com/u/51115889?v=4","tier","free","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_42":43,"_32":44,"_37":229,"_46":-5,"_47":25,"_48":49,"_50":49,"_51":52,"_53":-5,"_18":54,"_55":56,"_57":58,"_59":-5,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68,"_69":230,"_71":-5,"_72":73,"_74":73,"_75":76,"_77":76,"_78":76,"_79":73,"_80":73,"_81":231,"_83":232,"_85":233,"_87":25},"tree",[188,191,192,193,194,195],"files",[188,189,190,191,192,193,194,195],"counts",{"_178":62,"_179":166,"_180":62,"_181":182,"_183":184},"contents",[129,130,131,132,133,134],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_42":173,"_32":49,"_30":174,"_138":-5,"_40":41,"_39":166,"_140":58,"_37":175,"_13":62,"_33":176,"_34":-5,"_24":25,"_144":-5,"_27":177},{"_42":169,"_32":28,"_30":31,"_138":-5,"_40":41,"_39":14,"_140":25,"_37":170,"_13":171,"_33":20,"_34":36,"_24":25,"_144":-5,"_27":172},{"_42":161,"_32":162,"_30":163,"_138":-5,"_40":41,"_39":164,"_140":58,"_37":165,"_13":166,"_33":20,"_34":167,"_24":25,"_144":-5,"_27":168},{"_42":154,"_32":155,"_30":156,"_138":-5,"_40":41,"_39":157,"_140":25,"_37":158,"_13":62,"_33":142,"_34":159,"_24":25,"_144":-5,"_27":160},{"_42":146,"_32":147,"_30":56,"_138":-5,"_40":41,"_39":148,"_140":58,"_37":149,"_13":150,"_33":151,"_34":152,"_24":25,"_144":-5,"_27":153},{"_42":135,"_32":136,"_30":137,"_138":-5,"_40":41,"_39":139,"_140":58,"_37":141,"_13":62,"_33":142,"_34":143,"_24":25,"_144":-5,"_27":145},"f911537f-535a-4954-b4a3-8912461ebcf9","tmp_reconcile_after_exits.ts","a6902602-aa03-11f1-9940-1607ee4eb77e","parentId",63,"latest",["D",1788706808115],"script","const user='0x75e6e34a78cD19054BD0f298eb47b6DdfA2c4127';\nconst INFO='https://api.hyperliquid.xyz/info';\nconst post=async(b:any)=>{const r=await fetch(INFO,{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify(b)});if(!r.ok) throw new Error(`${r.status}:${await r.text()}`);return await r.json();};\nconst startTime=Date.parse('2026-09-05T15:00:00Z');\nconst recentStart=Date.parse('2026-09-06T14:40:00Z');\nconst [state,orders,xyzState,xyzOrders,fills,funding]=await Promise.all([\n post({type:'clearinghouseState',user}),post({type:'openOrders',user}),post({type:'clearinghouseState',user,dex:'xyz'}),post({type:'openOrders',user,dex:'xyz'}),post({type:'userFillsByTime',user,startTime,aggregateByTime:false}),post({type:'userFunding',user,startTime})\n]);\nconst perp=fills.filter((f:any)=>f.feeToken==='USDC' && /(Long|Short)/i.test(String(f.dir||'')));\nconst gross=perp.reduce((s:number,f:any)=>s+Number(f.closedPnl||0),0),fees=perp.reduce((s:number,f:any)=>s+Number(f.fee||0),0),fund=funding.reduce((s:number,x:any)=>s+Number(x.delta?.usdc||0),0);\nconsole.log(JSON.stringify({positions:state.assetPositions.map((x:any)=>x.position),orders,xyzPositions:xyzState.assetPositions.map((x:any)=>x.position),xyzOrders,recentFills:perp.filter((f:any)=>f.time>=recentStart).map((f:any)=>({coin:f.coin,px:f.px,sz:f.sz,dir:f.dir,closedPnl:f.closedPnl,fee:f.fee,tid:f.tid,oid:f.oid,time:f.time})),strict:{gross,fees,funding:fund,net:gross-fees+fund}}));","label",[136],"f713473c-0fb6-4b17-a986-6d32c82ef6ae","index.tsx",54,["D",1788700751921],18,"http","import { blob } from \"https://esm.town/v/std/blob/main.ts\";\n// Public market information only. Fixed upstream; no wallets, keys or trading.\nconst ORIGIN = \"https://hyperliquid-readonly-proxy.netlify.app\";\nconst VERSION = \"1.2.1\";\nconst COLS = [\"symbol\",\"venue\",\"markPx\",\"oraclePx\",\"change24hPct\",\"volume24hQuote\",\"oiBase\",\"oiNotionalQuote\",\"fundingHourly\",\"markOracleBps\",\"impactSpreadBps\",\"discoveryGate\",\"collateralSymbol\",\"maxLeverage\",\"szDecimals\"];\nconst CURATED_THEMES:Record={\n solana_ecosystem:[\"SOL\",\"JUP\",\"JTO\",\"PENGU\",\"FARTCOIN\",\"kBONK\",\"WIF\",\"PYTH\"],\n};\nfunction reply(data:unknown,status=200){return Response.json(data,{status,headers:{\"Cache-Control\":\"no-store\",\"X-Robots-Tag\":\"noindex, nofollow\"}});}\nfunction err(e:unknown){return e instanceof Error?e.message:String(e);}\nfunction median(xs:number[]){const a=xs.filter(Number.isFinite).toSorted((x,y)=>x-y);if(!a.length)return null;const m=Math.floor(a.length/2);return a.length%2?a[m]:(a[m-1]+a[m])/2;}\nfunction themeDiscovery(active:any[]){\n const eligible=active.filter((r:any)=>r.discoveryGate&&!r.gateUnitWarning&&r.assetClass===\"crypto\");\n const base24=median(eligible.map((r:any)=>r.change24hPct));\n const base15=median(eligible.map((r:any)=>r.deltas?.[\"15m\"]?.pricePct).filter((x:any)=>Number.isFinite(x)));\n const base1h=median(eligible.map((r:any)=>r.deltas?.[\"1h\"]?.pricePct).filter((x:any)=>Number.isFinite(x)));\n const themeMembers:Record>={};\n for(const [theme,symbols] of Object.entries(CURATED_THEMES))themeMembers[theme]=new Set(symbols);\n for(const r of eligible)for(const tag of (r.tags??[])){if(tag===\"unclassified\")continue;(themeMembers[\"tag:\"+tag]??=new Set()).add(r.symbol);}\n const metric=(rows:any[],tf:string)=>rows.map((r:any)=>r.deltas?.[tf]?.pricePct).filter((x:any)=>Number.isFinite(x));\n const signals=Object.entries(themeMembers).map(([theme,set])=>{\n const rows=eligible.filter((r:any)=>set.has(r.symbol));if(rows.length<2)return null;\n const m24=median(rows.map((r:any)=>r.change24hPct)),m15=median(metric(rows,\"15m\")),m1h=median(metric(rows,\"1h\"));\n const r24=m24==null||base24==null?null:m24-base24,r15=m15==null||base15==null?null:m15-base15,r1h=m1h==null||base1h==null?null:m1h-base1h;\n const hasCurrentInterval=m15!=null||m1h!=null; const score=hasCurrentInterval?((r24??0)*0.2+(r15??0)*0.35+(r1h??0)*0.45):null;\n const leaders=rows.toSorted((a:any,b:any)=>((b.deltas?.[\"1h\"]?.pricePct??b.change24hPct/24)-(a.deltas?.[\"1h\"]?.pricePct??a.change24hPct/24))).slice(0,5).map((r:any)=>({symbol:r.symbol,change24hPct:r.change24hPct,change15mPct:r.deltas?.[\"15m\"]?.pricePct??null,change1hPct:r.deltas?.[\"1h\"]?.pricePct??null,oi1hPct:r.deltas?.[\"1h\"]?.oiBasePct??null,volume24h:r.volume24hQuote}));\n return {theme,memberCount:rows.length,positive24h:rows.filter((r:any)=>r.change24hPct>0).length,positive15m:rows.filter((r:any)=>(r.deltas?.[\"15m\"]?.pricePct??-Infinity)>0).length,positive1h:rows.filter((r:any)=>(r.deltas?.[\"1h\"]?.pricePct??-Infinity)>0).length,median24hPct:m24,median15mPct:m15,median1hPct:m1h,relative24hPctPoints:r24,relative15mPctPoints:r15,relative1hPctPoints:r1h,currentSignalValid:hasCurrentInterval,signalStatus:hasCurrentInterval?\"CURRENT_INTERVAL_EVIDENCE\":\"INSUFFICIENT_CURRENT_INTERVAL_DATA\",themeStrengthScore:score,leaders};\n }).filter(Boolean) as any[];\n const ranked=signals.filter((s:any)=>s.currentSignalValid).toSorted((a:any,b:any)=>b.themeStrengthScore-a.themeStrengthScore); const historical24hThemes=signals.toSorted((a:any,b:any)=>(b.relative24hPctPoints??-Infinity)-(a.relative24hPctPoints??-Infinity)).slice(0,8);\n const discoveryLeaders=eligible.toSorted((a:any,b:any)=>((b.deltas?.[\"1h\"]?.pricePct??0)*0.6+(b.deltas?.[\"15m\"]?.pricePct??0)*0.3+b.change24hPct*0.1)-((a.deltas?.[\"1h\"]?.pricePct??0)*0.6+(a.deltas?.[\"15m\"]?.pricePct??0)*0.3+a.change24hPct*0.1)).slice(0,20).map((r:any)=>({symbol:r.symbol,tags:r.tags??[],change24hPct:r.change24hPct,change15mPct:r.deltas?.[\"15m\"]?.pricePct??null,change1hPct:r.deltas?.[\"1h\"]?.pricePct??null,oi1hPct:r.deltas?.[\"1h\"]?.oiBasePct??null,fundingHourly:r.fundingHourly,volume24h:r.volume24hQuote}));\n return {baseline:{eligibleCrypto:eligible.length,median24hPct:base24,median15mPct:base15,median1hPct:base1h},hotThemes:ranked.slice(0,8),coldThemes:ranked.toReversed().slice(0,8),historical24hThemes,discoveryLeaders,note:\"hotThemes require current 15m and/or 1h interval evidence. historical24hThemes are context only and must not be described as currently accelerating. Curated ecosystem taxonomy + upstream tags are detection signals, not proof of capital flow or causal fundamentals; verify promoted themes with fresh news/flow/fundamental evidence.\"};\n}\nfunction marketView(d:any,offset:number,limit:number,summary:boolean){\n const active=d.markets.filter((r:any)=>!r.isDelisted);\n const p=(r:any)=>({symbol:r.symbol,mark:r.markPx,change24hPct:r.change24hPct,volume24h:r.volume24hQuote,oiBase:r.oiBase,oiNotional:r.oiNotionalQuote,fundingHourly:r.fundingHourly,impactSpreadBps:r.impactSpreadBps,markOracleBps:r.markOracleBps});\n const eligible=active.filter((r:any)=>r.discoveryGate&&!r.gateUnitWarning);\n return {fetchedAt:d.fetchedAt,fetchedAtJST:d.fetchedAtJST,scope:d.scope,venueStatus:d.venues??d.venueStatus,history:d.history,clusters:d.clusters,cache:d.cache,\n note:\"All active rows retained. Impact spread is NOT best bid/ask. Collection time is not an exchange timestamp. Missing deltas are unknown.\",\n ...(summary?{themeDiscovery:themeDiscovery(active),liquid:eligible.toSorted((a:any,b:any)=>b.volume24hQuote-a.volume24hQuote).slice(0,15).map(p),gainers:eligible.toSorted((a:any,b:any)=>b.change24hPct-a.change24hPct).slice(0,15).map(p),losers:eligible.toSorted((a:any,b:any)=>a.change24hPct-b.change24hPct).slice(0,12).map(p),negativeFunding:eligible.filter((r:any)=>r.fundingHourly<0).toSorted((a:any,b:any)=>a.fundingHourly-b.fundingHourly).slice(0,12).map(p)}:{}),\n columns:COLS,offset,count:Math.min(limit,Math.max(0,active.length-offset)),total:active.length,hasMore:offset+limitCOLS.map(k=>r[k]??null))};\n}\nexport default async function(req:Request){\n if(req.method!==\"GET\")return reply({error:\"GET_ONLY\"},405);\n try{\n const u=new URL(req.url),mode=u.searchParams.get(\"mode\")??\"health\";\n if(mode===\"health\")return reply({ok:true,version:VERSION,marketDataOnly:true,noMicrofn:true,noSchedules:true,noWallets:true,upstream:ORIGIN,modes:[\"market\",\"technical\",\"read\"],usage:\"market: live all venues; technical: coins=HYPE,BTC; read: data=market or technical, offset/limit, no upstream fetch\"});\n if(![\"market\",\"technical\",\"read\"].includes(mode))return reply({error:\"INVALID_MODE\"},400);\n const offset=Number(u.searchParams.get(\"offset\")??0),limit=Number(u.searchParams.get(\"limit\")??0);\n if(!Number.isInteger(offset)||offset<0||!Number.isInteger(limit)||limit<0||limit>100)return reply({error:\"INVALID_PAGE\"},400);\n let kind=mode===\"read\"?(u.searchParams.get(\"data\")??\"market\"):mode;\n if(![\"market\",\"technical\"].includes(kind))return reply({error:\"INVALID_DATA\"},400);\n const key=kind+\"-latest\";\n let d:any,network=false;\n if(mode===\"read\"){\n d=await blob.getJSON(key);if(!d)return reply({error:\"NO_STORED_SNAPSHOT\"},404);\n }else{\n let path=\"/market?venue=all&kind=all\";\n if(mode===\"technical\"){\n const coins=(u.searchParams.get(\"coins\")??\"HYPE,BTC\").split(\",\");\n if(coins.length<1||coins.length>2||new Set(coins).size!==coins.length||coins.some(c=>!/^(?:[a-z][a-z0-9_-]{0,24}:)?[A-Za-z0-9_.-]{1,32}$/.test(c)))return reply({error:\"INVALID_COINS\"},400);\n path=\"/technical?coins=\"+encodeURIComponent(coins.join(\",\"));\n }\n const now=Date.now(),last:any=await blob.getJSON(key);\n if(last&&last.bridgePath===path&&now-Date.parse(last.fetchedAt)<60000){d=last;}\n else{\n const day=new Date().toISOString().slice(0,10);let budget:any=await blob.getJSON(\"budget\");if(budget?.day!==day)budget={day,count:0,lastMarket:0,lastTechnical:0};\n if(budget.count>=200)return reply({error:\"LOCAL_DAILY_UPSTREAM_CAP_200\",budget},429);\n const k=mode===\"market\"?\"lastMarket\":\"lastTechnical\",gap=mode===\"market\"?65000:31000;\n if(now-(budget[k]??0)4000000)throw new Error(\"UPSTREAM_TOO_LARGE\");\n if(!r.ok)return reply({error:\"UPSTREAM_HTTP_\"+r.status,detail:text.slice(0,1000),retryAfter:r.headers.get(\"retry-after\")},r.status===429?429:502);\n d=JSON.parse(text);const age=Date.now()-Date.parse(d.fetchedAt??\"\");if(!Number.isFinite(age)||age>90000||age< -5000)throw new Error(\"STALE_OR_INVALID_COLLECTION_TIME\");\n if(mode===\"market\"){\n if(!d.scope?.coverageComplete||!d.scope?.registryVerified||!Array.isArray(d.markets))throw new Error(\"INCOMPLETE_MARKET_COVERAGE\");\n const a=d.markets.filter((r:any)=>!r.isDelisted);\n if(a.length!==d.scope.perpScreenedValid||a.some((r:any)=>!r.quality?.valid))throw new Error(\"INVALID_ACTIVE_ROWS\");\n }\n if(mode==='technical'&&(!d.complete||!Array.isArray(d.symbols)||!d.out||d.symbols.some((s:string)=>['5m','15m','1h','4h','book'].some(t=>!d.out[s]?.[t]?.ok))))throw new Error('INCOMPLETE_TECHNICAL_SNAPSHOT');\n d.bridgePath=path;d.bridgeReceivedAt=new Date().toISOString();await blob.setJSON(key,d);network=true;\n }\n }\n const ageMs=Date.now()-Date.parse(d.fetchedAt??\"\");\n const meta={bridgeVersion:VERSION,networkFetch:network,storedSnapshot:mode===\"read\",snapshotAgeMs:ageMs,liveForExecution:ageMs>=0&&ageMs<=90000,servedAt:new Date().toISOString(),source:ORIGIN+d.bridgePath};\n if(u.searchParams.get(\"view\")===\"raw\")return reply({...meta,data:d});\n if(kind===\"market\"){\n if(u.searchParams.has('symbols')){const wanted=u.searchParams.get('symbols')!.split(',');if(wanted.length>25||wanted.some(s=>!/^(?:[a-z][a-z0-9_-]{0,24}:)?[A-Za-z0-9_.-]{1,32}$/.test(s)))return reply({error:'INVALID_SYMBOL_SELECTION'},400);const selected=d.markets.filter((r:any)=>wanted.includes(r.symbol));return reply({...meta,data:{fetchedAt:d.fetchedAt,scope:d.scope,history:d.history,requestedSymbols:wanted,foundSymbols:selected.map((r:any)=>r.symbol),rows:selected}});}\n return reply({...meta,data:marketView(d,offset,limit,mode!==\"read\"||u.searchParams.get(\"summary\")===\"1\")});\n }\n const compactOut=Object.fromEntries(Object.entries(d.out??{}).map(([coin,sections]:[string,any])=>[coin,Object.fromEntries(Object.entries(sections).map(([name,value]:[string,any])=>{if(name==='book')return [name,value];const {lastClosedBars,pivotsHigh,pivotsLow,...rest}=value;return [name,{...rest,pivotsHigh:pivotsHigh?.slice(-4),pivotsLow:pivotsLow?.slice(-4),lastClosedBars:lastClosedBars?.slice(-3)}];}))]));\n return reply({...meta,data:{...d,out:compactOut}});\n }catch(e){return reply({ok:false,error:err(e),at:new Date().toISOString()},502);}\n}\n",[147],"6d46cd24-a6dc-422d-b8b9-0554584db8f6","account_checker.ts","960fd2b8-aa09-11f1-a49e-1607ee4eb77e",70,["D",1788709357408],"import { sqlite } from \"https://esm.town/v/std/sqlite/main.ts\";\n\nconst INFO = \"https://api.hyperliquid.xyz/info\";\nconst JST_MS = 9 * 60 * 60 * 1000;\nconst DAY_MS = 86_400_000;\nconst DEFAULT_EFFECTIVE_JST = \"2026-09-07\";\nconst DEFAULT_BASE_TARGET = 200;\n\nconst num = (v: unknown) => {\n const n = typeof v === \"number\" ? v : Number(String(v ?? \"0\").trim());\n return Number.isFinite(n) ? n : 0;\n};\nconst round = (v: number, dp = 6) => {\n const p = 10 ** dp;\n return Math.round((v + Number.EPSILON) * p) / p;\n};\nconst jstDateKey = (ms: number) => new Date(ms + JST_MS).toISOString().slice(0, 10);\nconst jstMidnightMs = (d: string) => Date.parse(`${d}T00:00:00+09:00`);\nconst fillKey = (f: any) => String(f?.tid ?? `${f?.time}|${f?.coin}|${f?.oid}|${f?.side}|${f?.px}|${f?.sz}`);\nconst fundingKey = (r: any) => `${String(r?.hash ?? \"\")}|${String(r?.time ?? \"\")}|${String(r?.delta?.coin ?? \"\")}|${String(r?.delta?.usdc ?? \"\")}`;\nconst projectDelta = (f: any) => {\n const d = String(f?.dir ?? \"\").toLowerCase();\n const s = Math.abs(num(f?.sz));\n if (d.includes(\"open long\")) return s;\n if (d.includes(\"close long\")) return -s;\n if (d.includes(\"open short\")) return -s;\n if (d.includes(\"close short\")) return s;\n return 0;\n};\nconst uniqueBy = (rows: any[], key: (r: any) => string) => {\n const m = new Map();\n for (const r of rows) m.set(key(r), r);\n return [...m.values()];\n};\n\nasync function post(body: Record) {\n const r = await fetch(INFO, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify(body),\n });\n if (!r.ok) throw new Error(`HL_HTTP_${r.status}:${(await r.text()).slice(0, 200)}`);\n return await r.json();\n}\n\nasync function fetchRange(type: \"userFillsByTime\" | \"userFunding\", user: string, startTime: number, endTime: number, depth = 0): Promise {\n const body: any = { type, user, startTime, endTime };\n if (type === \"userFillsByTime\") body.aggregateByTime = false;\n const rows = await post(body);\n if (!Array.isArray(rows)) throw new Error(`${type}_NOT_ARRAY`);\n if (rows.length < 2000) return rows;\n if (depth >= 24 || endTime - startTime <= 1) throw new Error(`${type}_WINDOW_TOO_DENSE`);\n const mid = Math.floor((startTime + endTime) / 2);\n return [...await fetchRange(type, user, startTime, mid, depth + 1), ...await fetchRange(type, user, mid + 1, endTime, depth + 1)];\n}\n\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS strategy_oids (\n oid TEXT PRIMARY KEY, coin TEXT, side TEXT, venue TEXT, order_type TEXT,\n limit_px REAL, trigger_px REAL, orig_sz REAL, parent_oid TEXT,\n plan_id TEXT, registered_at TEXT NOT NULL\n)`);\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS strategy_tids (\n tid TEXT PRIMARY KEY, plan_id TEXT, registered_at TEXT NOT NULL\n)`);\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS strategy_seeds (\n coin TEXT PRIMARY KEY, signed_size REAL NOT NULL, at_time INTEGER NOT NULL,\n note TEXT, registered_at TEXT NOT NULL\n)`);\nawait sqlite.execute(`CREATE TABLE IF NOT EXISTS strategy_meta (\n key TEXT PRIMARY KEY, value TEXT NOT NULL\n)`);\n\nconst user = Deno.env.get(\"HL_ACCOUNT_ADDRESS\");\nif (!user) throw new Error(\"MISSING_HL_ACCOUNT_ADDRESS\");\nconst now = Date.now();\nconst todayJST = jstDateKey(now);\nconst metaRows = (await sqlite.execute(\"SELECT key,value FROM strategy_meta\")).rows as any[];\nconst meta = Object.fromEntries(metaRows.map((r: any) => [String(r.key), String(r.value)]));\nconst effectiveJST = meta.effective_from_jst || DEFAULT_EFFECTIVE_JST;\nconst effectiveStart = jstMidnightMs(effectiveJST);\nconst todayStart = jstMidnightMs(todayJST);\nconst baseTarget = num(meta.base_daily_target_usd) || DEFAULT_BASE_TARGET;\nconst priorCarry = num(meta.prior_carry_in_usd);\n\nconst [mainState, mainOrders, xyzState, xyzOrders, fillsRaw, fundingRaw, oidRows, tidRows, seedRows] = await Promise.all([\n post({ type: \"clearinghouseState\", user }),\n post({ type: \"frontendOpenOrders\", user }),\n post({ type: \"clearinghouseState\", user, dex: \"xyz\" }),\n post({ type: \"frontendOpenOrders\", user, dex: \"xyz\" }),\n fetchRange(\"userFillsByTime\", user, effectiveStart, now),\n fetchRange(\"userFunding\", user, effectiveStart, now),\n sqlite.execute(\"SELECT * FROM strategy_oids\"),\n sqlite.execute(\"SELECT * FROM strategy_tids\"),\n sqlite.execute(\"SELECT * FROM strategy_seeds\"),\n]);\n\nconst fills = uniqueBy(fillsRaw, fillKey).filter((f: any) => {\n const c = String(f?.coin ?? \"\");\n return c && !c.startsWith(\"@\") && /(Long|Short)/i.test(String(f?.dir ?? \"\"));\n}).sort((a: any, b: any) => num(a.time) - num(b.time));\nconst funding = uniqueBy(fundingRaw, fundingKey).sort((a: any, b: any) => num(a.time) - num(b.time));\nconst oidSet = new Set((oidRows.rows as any[]).map((r: any) => String(r.oid)));\nconst tidSet = new Set((tidRows.rows as any[]).map((r: any) => String(r.tid)));\nconst seeds = Object.fromEntries((seedRows.rows as any[]).map((r: any) => [String(r.coin), { signedSize: num(r.signed_size), atTime: num(r.at_time) }]));\nconst tagged = fills.filter((f: any) => oidSet.has(String(f?.oid ?? \"\")) || tidSet.has(String(f?.tid ?? \"\")));\n\nconst byCoin = new Map();\nfor (const f of tagged) {\n const c = String(f.coin);\n if (!byCoin.has(c)) byCoin.set(c, []);\n byCoin.get(c)!.push(f);\n}\nconst activeAt = (coin: string, t: number) => {\n const seed = seeds[coin];\n let pos = seed && seed.atTime <= t ? seed.signedSize : 0;\n for (const f of byCoin.get(coin) || []) {\n const ft = num(f.time);\n if (ft > t) break;\n if (seed && ft < seed.atTime) continue;\n pos += projectDelta(f);\n }\n return Math.abs(pos) > 1e-12;\n};\n\nlet accountGross = 0, accountFees = 0, accountFunding = 0;\nlet strategyGross = 0, strategyFees = 0, strategyFunding = 0, strategyFundingCount = 0;\nfor (const f of fills) {\n const t = num(f.time);\n if (t < todayStart || t > now) continue;\n accountGross += num(f.closedPnl);\n if (String(f.feeToken ?? \"USDC\").toUpperCase() === \"USDC\") accountFees += num(f.fee);\n}\nfor (const f of tagged) {\n const t = num(f.time);\n if (t < todayStart || t > now) continue;\n strategyGross += num(f.closedPnl);\n if (String(f.feeToken ?? \"USDC\").toUpperCase() === \"USDC\") strategyFees += num(f.fee);\n}\nfor (const r of funding) {\n const t = num(r.time);\n if (t < todayStart || t > now || String(r?.delta?.type ?? \"\") !== \"funding\") continue;\n const v = num(r?.delta?.usdc);\n accountFunding += v;\n const coin = String(r?.delta?.coin ?? \"\");\n if (activeAt(coin, t)) {\n strategyFunding += v;\n strategyFundingCount++;\n }\n}\n\nconst accountNet = accountGross - accountFees + accountFunding;\nconst strategyNet = strategyGross - strategyFees + strategyFunding;\nconst requiredToday = baseTarget + priorCarry;\nconst remainingToday = Math.max(0, requiredToday - strategyNet);\nconst positionRows = [\n ...(Array.isArray(mainState?.assetPositions) ? mainState.assetPositions : []),\n ...(Array.isArray(xyzState?.assetPositions) ? xyzState.assetPositions : []),\n].map((x: any) => x.position).filter((p: any) => Math.abs(num(p?.szi)) > 1e-12);\nconst openOrders = [\n ...(Array.isArray(mainOrders) ? mainOrders : []),\n ...(Array.isArray(xyzOrders) ? xyzOrders : []),\n];\n\nconsole.log(JSON.stringify({\n checkerVersion: \"val-sqlite-v1.0.0\",\n authority: \"VAL_TOWN_SQLITE\",\n fetchedAt: new Date(now).toISOString(),\n jst: { date: todayJST, dayStartAt: new Date(todayStart).toISOString(), timezone: \"Asia/Tokyo\" },\n positions: positionRows,\n openOrders,\n targetTracking: {\n authoritativeMethod: \"ACCOUNT_WIDE_JST_STRICT_REALIZED_PERP_NET\",\n todayStrictNetUSD: round(accountNet),\n grossClosedPnlUSD: round(accountGross),\n tradingFeesUSD: round(accountFees),\n fundingUSD: round(accountFunding),\n },\n strategyTracking: {\n authoritativeMethod: \"VAL_TOWN_SQLITE_TAGGED_HYPERLIQUID_FILLS_AND_FUNDING\",\n effectiveFromJST: effectiveJST,\n priorCarryInUSD: round(priorCarry),\n baseDailyTargetUSD: round(baseTarget),\n requiredTodayUSD: round(requiredToday),\n todayStrategyStrictNetUSD: round(strategyNet),\n remainingTodayUSD: round(remainingToday),\n todayGoalMet: remainingToday <= 0,\n grossClosedPnlUSD: round(strategyGross),\n tradingFeesUSD: round(strategyFees),\n fundingUSD: round(strategyFunding),\n fundingAttributedCount: strategyFundingCount,\n registeredOidCount: oidSet.size,\n registeredTidCount: tidSet.size,\n seededPositionCount: Object.keys(seeds).length,\n },\n recentPerpFills: fills.slice(-25).map((f: any) => ({\n time: num(f.time), at: new Date(num(f.time)).toISOString(), tid: String(f.tid ?? \"\"), oid: String(f.oid ?? \"\"),\n coin: String(f.coin ?? \"\"), dir: String(f.dir ?? \"\"), px: num(f.px), sz: num(f.sz),\n closedPnl: num(f.closedPnl), fee: num(f.fee), feeToken: String(f.feeToken ?? \"USDC\"),\n tagged: oidSet.has(String(f.oid ?? \"\")) || tidSet.has(String(f.tid ?? \"\")),\n })),\n}));\n",[155],"028a7759-744a-4039-97a6-0d0677324b5d","README.md","01a06ff1-37fe-726c-835e-88db01f1a3f6",9,["D",1788585922073],1,"# Hyperliquid market bridge — verified on-demand retrieval\n\nThis service is public MARKET DATA ONLY. It contains no wallet address, positions, credentials, order signing or trading functions. It has no scheduled jobs. It was verified with actual Hyperliquid responses on 2026-09-05, not only mocked tests.\n\n## Stable identity\n- Val: `kamibaba/hyperliquid-market-bridge`\n- HTTP file: `index.tsx`; branch: `main`\n- Bridge version: `1.1.1`\n- Fixed upstream: `https://hyperliquid-readonly-proxy.netlify.app`\n- Netlify project: `hyperliquid-readonly-proxy`, site ID `378ad326-88f1-4aef-aac5-1a3734fe8627`\n- No custom domain is needed. The unrelated sound-notes.net project must not be edited.\n\n## ChatGPT workflow — no Mac operation or uploaded JSON required\nUse the connected `Val_Town.fetch_val_endpoint` tool. Always pass the actual val identity and HTTP file; do not construct or guess val endpoint URLs.\n\n1. Fetch all venues: `{ \"val\": \"kamibaba/hyperliquid-market-bridge\", \"path\": \"index.tsx\", \"search\": \"mode=market&limit=0\" }`.\n2. Validate HTTP status, `data.scope.coverageComplete`, `registryVerified`, active/valid counts, venue errors and `data.fetchedAt`. The universe is dynamic, not a fixed 315 or 370.\n3. Read every active row without refetching upstream: `mode=read&data=market&offset=0&limit=100`; then 100, 200, 300 until `hasMore=false`. If tool output truncates, reduce limit. Check fetchedAt is unchanged across pages.\n4. Inspect shortlisted symbols including interval deltas: `mode=read&data=market&symbols=HYPE,ZEC,NEAR,DASH,LIT`. Keep selection small to avoid output truncation. This is explicitly a subset of the already-fetched full market.\n5. Fetch closed candles and book for at most two symbols per call: `mode=technical&coins=HYPE,BTC` or `mode=technical&coins=xyz:MU,xyz:AVGO`. Default response is compact; raw is available using `view=raw`.\n6. If a response is truncated or interrupted, `mode=read&data=technical` reads the saved result without an upstream call. Verify `data.symbols` matches the intended pair before using it. A 429 may coexist with a recently completed request: inspect the stored snapshot rather than blindly retrying.\n7. Refresh market or selected technical data near the final trading decision. `mode=read` is historical snapshot access, never a promise of current market data.\n\nThe connector's built-in `Val_Town.web_fetch` also successfully fetched the Netlify /health endpoint, but health alone does not verify market coverage.\n\n## Quotas and cost\nThis val is on the Free tier. The upstream Netlify site remains on its existing Free plan; shared account usage still applies. No paid plan, auto recharge, inference model, cron or trading agent is configured. Additional tool calls may use ChatGPT limits separately.\n\n- Market upstream cooldown: 65 seconds; technical upstream cooldown: 31 seconds.\n- Reuse same-query snapshots younger than 60 seconds.\n- An application-level budget limits upstream attempts to 200/day (UTC). This is a best-effort application counter, NOT an atomic billing cap or a promise of unlimited free usage. Netlify also enforces its own request limits and Free plan cap.\n- Read pages use the stored snapshot, not more Hyperliquid/Netlify collection calls.\n- Stored snapshots are overwritten; there is no unbounded full-snapshot archive here.\n\n## Interpretation safeguards\n- All-perp scope includes Core, XYZ and every HIP-3 venue returned by the official registry. `kind=all` also fetches spot metadata/contexts, but this bridge's default rows are active perps; do not claim deep analysis of all spot pairs.\n- `fetchedAt` is collection time. Asset contexts have no independent exchange event timestamp. The order book has its own source timestamp.\n- 24-hour returns are rolling returns, NOT the return since midnight JST.\n- Impact spread is NOT best bid/ask spread; use the book for execution analysis.\n- OI base and OI notional are distinct. OI increase does not identify which directional side initiated trading.\n- Missing interval history remains unknown; no inferred liquidation maps or spot CVD.\n- Curated tags are incomplete and may overlap. ZEN is a Base token; grouping it with historical privacy names is a thematic comparison, not a same-chain assertion. NEAR also has privacy-related products despite its basic layer1 label.\n- All technical indicators use closed contiguous bars. ATR is neither a guaranteed range nor an automatic minimum stop distance.\n- Reject partial, stale or wrong-symbol detailed responses. `liveForExecution` only checks snapshot age, not profitability or fill guarantees.\n- Use market snapshots for setup screening, then check specific execution prices and expiry conditions. Do not enlarge risk merely to target a daily dollar profit.\n\n## Actual verification\n2026-09-05T05:15:51.880Z and 2026-09-05T05:21:23.682Z: all 11 discovered venues returned HTTP 200; 512 listed perp records, 315 active/valid, 326 spot pairs. All 315 active rows were read from the first snapshot in four pages. The second snapshot refreshed the full universe and ranking outputs.\n\nTechnical requests succeeded for HYPE, BTC, NEAR, ZEC, DASH, LIT, CASHCAT, ZRO, SKR and ZORA. HYPE/ZEC were refreshed at 2026-09-05T05:23:28.897Z. These are historical verification times, never current trading prices in a future chat.\n\nMarket collection does not use microfn. microfn remains a separate account-checking route only when the user reports position/order changes. Do not use this public val to store the user's account data.\n",[162],"8981344c-bdea-40be-b6ec-a162a446d903",["D",1788742001148],42,[28],"2e50ecae-483a-4d27-ac23-d7f563d4c130","01a06ff1-37fe-726c-835e-844c9ed57932",["D",1788584474524],"directory",[49],"pulls","branches","forks","envVars",{"_185":166,"_187":62},"connections",{"_185":62,"_186":62},"count","unfilledCount","emptyCount",{"_42":173,"_32":49,"_30":174,"_138":-5,"_40":41,"_39":166,"_140":58,"_37":226,"_13":62,"_33":176,"_34":-5,"_24":25,"_144":-5,"_197":227,"_27":228},{"_42":219,"_32":220,"_30":221,"_138":174,"_40":41,"_39":166,"_140":58,"_37":222,"_13":62,"_33":142,"_34":223,"_24":25,"_144":-5,"_197":224,"_27":225},{"_42":212,"_32":213,"_30":214,"_138":174,"_40":41,"_39":166,"_140":58,"_37":215,"_13":62,"_33":20,"_34":216,"_24":25,"_144":-5,"_197":217,"_27":218},{"_42":169,"_32":28,"_30":31,"_138":-5,"_40":41,"_39":14,"_140":25,"_37":209,"_13":171,"_33":20,"_34":36,"_24":25,"_144":-5,"_197":210,"_27":211},{"_42":161,"_32":162,"_30":163,"_138":-5,"_40":41,"_39":164,"_140":58,"_37":206,"_13":166,"_33":20,"_34":167,"_24":25,"_144":-5,"_197":207,"_27":208},{"_42":154,"_32":155,"_30":156,"_138":-5,"_40":41,"_39":157,"_140":25,"_37":203,"_13":62,"_33":142,"_34":159,"_24":25,"_144":-5,"_197":204,"_27":205},{"_42":146,"_32":147,"_30":56,"_138":-5,"_40":41,"_39":148,"_140":58,"_37":200,"_13":150,"_33":151,"_34":152,"_24":25,"_144":-5,"_197":201,"_27":202},{"_42":135,"_32":136,"_30":137,"_138":-5,"_40":41,"_39":139,"_140":58,"_37":196,"_13":62,"_33":142,"_34":143,"_24":25,"_144":-5,"_197":198,"_27":199},["D",1788706808115],"children",[],[136],["D",1788700751921],[],[147],["D",1788709357408],[],[155],["D",1788585922073],[],[162],["D",1788742001148],[],[28],"eecdc355-933e-4c99-99e5-481180e6832a","favicon.svg","01a06ff1-37fe-726c-835e-801b891f2122",["D",1788584474524],"\n",[],[49,213],"94aaa291-56be-425b-8726-a9d3e3c0f5eb","counter.ts","01a06ff1-37fe-726c-835e-7c219a514093",["D",1788584474524],"const count = document.getElementById(\"count\")!;\nconst button = document.getElementById(\"increment\")!;\n\nbutton.addEventListener(\"click\", async () => {\n const res = await fetch(\"/api/increment\", { method: \"POST\" });\n const data = await res.json();\n count.textContent = String(data.count);\n});\n",[],[49,220],["D",1788584474524],[189,190],[49],["D",1788584474524],["D",1789491713377],{"_99":98,"_106":102},{"_99":98,"_100":98,"_101":102,"_18":54,"_103":104,"_105":25},{"_13":88,"_32":89,"_42":41,"_90":43,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":44,"_97":98},"ctx",{"_81":-5,"_126":267,"_268":269,"_270":271,"_272":25,"_273":25,"_274":25,"_275":58,"_276":-5,"_277":-7,"_278":-7,"_279":62,"_280":25,"_281":25,"_282":-5,"_283":25,"_284":25,"_285":25,"_286":-5},"ENV",{"_238":239,"_240":241,"_242":89,"_243":244,"_245":246,"_247":248,"_249":250,"_251":252,"_253":254,"_255":256,"_257":258,"_259":260,"_261":262,"_263":264,"_265":266},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Diff · v99