[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J0PD9HPXYEAPM5DSAJRK9M":3,"skill-same:01M6J0PD9HPXYEAPM5DSAJRK9M":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6J0PD9HPXYEAPM5DSAJRK9M","limit-offset-bps-calculation",null,"Use when placing any post-only limit order on HyperLiquid to calculate the optimal price offset from mid that maximizes fill probability while preserving maker status, accounting for spread, volatility, book depth, and asset tick size.","enuno\u002Fhyperliquid-trading-firm","enuno","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6727752?v=4","01M6J09HF6Y74150F7PEMC446X","Elvis Nuno","01M6J09HKK0YMKE39JXT8JT8VM",1,"GPL-3.0","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fmulticlaw\u002Fmetaclaw\u002Fskills\u002Fexecution\u002Flimit-offset-bps-calculation\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"limit offset bps calculation","limit","calculation","post","fill","book","for","limit order","size","asset","agentic","price","probability","maker","accounting","only","use","calculate","Volatility","status","2026-11-10 10:12:30",false,"---\nname: limit-offset-bps-calculation\ndescription: Use when placing any post-only limit order on HyperLiquid to calculate the optimal price offset from mid that maximizes fill probability while preserving maker status, accounting for spread, volatility, book depth, and asset tick size.\ncategory: agentic\n---\n\n# Limit Order Offset (BPS) Calculation\n\n## When This Skill Activates\n\nApply this skill **every time an `Alo` (post-only) limit order price must\nbe determined** before submission. The skill answers: *how many basis\npoints inside or outside the spread should the limit price be placed?*\n\nAlso apply when:\n- An `Alo` order was rejected (price crossed spread) and a new offset\n  must be computed before reposting\n- Fill rate on resting limit orders is unacceptably low and offset\n  calibration needs review\n- A new asset is being traded for the first time and no historical\n  offset data exists yet\n- Spread has widened significantly (low liquidity period, news event)\n  and the standard offset is stale\n\n---\n\n## Core Principle\n\nA post-only limit order placed **too far from mid** rests on the book\nfor a long time and may never fill — opportunity cost. Placed **too\nclose to mid** it risks crossing the spread on a momentary tick and\nbeing rejected as a taker (or, with `Gtc`, accidentally paying taker\nfee). The optimal offset is the minimum distance from mid that reliably\nlands inside the book as a resting maker order given current spread and\nvolatility, without being so far away that fill probability collapses.\n\n> **Rule**: Place limit orders at `mid ± offset_bps` where `offset_bps`\n> is computed fresh from live spread and recent volatility at the time\n> of each order. Never use a hardcoded static offset across all market\n> conditions.\n\n---\n\n## Inputs Required\n\nFetch all of the following from HyperLiquid before computing offset:\n\n```python\n# From WebSocket l2Book or REST \u002Finfo → l2Book(coin):\nbest_bid   = l2book[\"levels\"][0][0][\"px\"]   # highest bid price\nbest_ask   = l2book[\"levels\"][1][0][\"px\"]   # lowest ask price\nmid_price  = (best_bid + best_ask) \u002F 2\nraw_spread_bps = (best_ask - best_bid) \u002F mid_price * 10000\n\n# From REST \u002Finfo → meta + assetCtxs:\nmark_price = asset_ctx[\"markPrice\"]         # oracle mark; use for offset anchor\ntick_size  = asset_meta[\"szDecimals\"]       # price precision (decimal places)\n\n# From recent trade history (last 50–100 trades, 5m window):\nimport statistics\ntrade_prices  = [t[\"px\"] for t in recent_trades]\nvolatility_bps = statistics.stdev(trade_prices) \u002F mid_price * 10000\n# Short-window volatility: 1-sigma move in the last 5m in basis points\n```\n\n---\n\n## Offset Calculation\n\n### Base Offset Formula\n\n```python\ndef compute_limit_offset_bps(\n    raw_spread_bps: float,\n    volatility_bps: float,             # 5m 1-sigma in bps\n    side: str,                         # \"buy\" or \"sell\"\n    order_urgency: str = \"normal\",     # \"normal\", \"patient\", \"urgent\"\n    book_fragility: float = 0.0,       # 0–1; from liquidation-cascade-risk\n) -> float:\n    \"\"\"\n    Returns the offset in basis points from mid.\n    Positive offset = deeper into the book (better fill safety, worse fill rate).\n    \"\"\"\n    # Half-spread is the minimum safe distance to guarantee maker status\n    half_spread_bps = raw_spread_bps \u002F 2\n\n    # Safety buffer: 1 tick worth of extra clearance beyond half-spread\n    # Prevents rejection on micro-moves at the moment of submission\n    safety_buffer_bps = max(0.5, half_spread_bps * 0.10)\n\n    # Volatility buffer: scale with recent short-window vol to avoid\n    # being crossed during order transit latency (~50–200ms on HL)\n    vol_buffer_bps = volatility_bps * 0.20   # 20% of 1-sigma 5m vol\n\n    # Base offset: half-spread + safety + vol buffer\n    base_offset = half_spread_bps + safety_buffer_bps + vol_buffer_bps\n\n    # Urgency modifier:\n    urgency_multiplier = {\n        \"urgent\":  0.5,    # closer to mid; accept higher rejection risk for better fill\n        \"normal\":  1.0,    # standard\n        \"patient\": 1.5,    # deeper in book; lower rejection risk; slower fill\n    }[order_urgency]\n\n    # Book fragility modifier: widen offset when book is thin\n    # (thin books = higher vol transit risk = needs more clearance)\n    fragility_multiplier = 1.0 + (book_fragility * 0.5)\n\n    offset_bps = base_offset * urgency_multiplier * fragility_multiplier\n\n    # Clamp: never closer than 0.5 bps (tick noise floor)\n    #        never farther than 5.0 bps (fill probability collapses)\n    return max(0.5, min(5.0, offset_bps))\n```\n\n### Applying Offset to Order Price\n\n```python\ndef compute_limit_price(\n    mid_price: float,\n    offset_bps: float,\n    side: str,\n    tick_size_decimals: int,\n) -> float:\n    \"\"\"\n    Buy orders: place BELOW mid (offset into bid side)\n    Sell orders: place ABOVE mid (offset into ask side)\n    Round to asset tick size to avoid rejection for invalid price precision.\n    \"\"\"\n    offset_price = mid_price * (offset_bps \u002F 10000)\n\n    if side == \"buy\":\n        raw_price = mid_price - offset_price\n    else:  # sell\n        raw_price = mid_price + offset_price\n\n    # Round to valid tick size (round down for buys, up for sells\n    # to stay on the correct side of mid after rounding)\n    factor = 10 ** tick_size_decimals\n    if side == \"buy\":\n        return math.floor(raw_price * factor) \u002F factor\n    else:\n        return math.ceil(raw_price * factor) \u002F factor\n```\n\n---\n\n## Offset Calibration by Market Condition\n\n### Spread Regime Classification\n\nClassify current spread before applying offset to set urgency defaults:\n\n| Spread (bps) | Regime | Suggested Urgency | Notes |\n|---|---|---|---|\n| \u003C 1.0 | Tight | `normal` | Liquid; standard offset works well |\n| 1.0–2.5 | Normal | `normal` | Typical for mid-cap perps |\n| 2.5–5.0 | Wide | `patient` | Low liquidity; widen offset or wait |\n| 5.0–10.0 | Very wide | `patient` + size reduction | Consider deferring non-urgent entries |\n| > 10.0 | Illiquid | Defer or use `Ioc` taker if urgent | Maker fill unlikely at reasonable offset |\n\n> When spread > 10 bps and the entry is time-critical, the cost of\n> waiting for a maker fill (missing the move) may exceed taker fee.\n> Defer to `maker-order-preference-fee-reduction` for the explicit\n> taker-vs-maker decision; this skill only handles the offset calculation\n> for the maker path.\n\n### Volatility Regime Adjustment\n\n| 5m Volatility (bps) | Vol Regime | vol_buffer_bps | Effect on Offset |\n|---|---|---|---|\n| \u003C 2 | Low vol | 0.4 | Offset stays near minimum |\n| 2–5 | Normal vol | 0.4–1.0 | Standard offset range |\n| 5–10 | Elevated vol | 1.0–2.0 | Offset widens meaningfully |\n| 10–20 | High vol | 2.0–4.0 | Approach upper clamp; consider `patient` |\n| > 20 | Extreme vol | Clamp at 5.0 | Near-cascade conditions; see `liquidation-cascade-risk` |\n\n---\n\n## Asset-Specific Tick Size Reference\n\nHyperLiquid enforces strict price precision per asset. Submitting an\norder with more decimal places than allowed causes immediate rejection.\n\n```python\n# Always fetch live from \u002Finfo → meta:\nasset_tick_map = {\n    asset[\"name\"]: asset[\"szDecimals\"]\n    for asset in meta[\"universe\"]\n}\n\n# Common values at time of writing (verify live — do not hardcode):\n# BTC:  1 decimal place  (e.g. 91450.0)\n# ETH:  2 decimal places (e.g. 1791.40)\n# SOL:  3 decimal places (e.g. 138.250)\n# ARB:  5 decimal places (e.g. 0.47820)\n# DOGE: 6 decimal places (e.g. 0.072340)\n```\n\nThe `compute_limit_price()` function above handles rounding automatically\nwhen `tick_size_decimals` is passed correctly. **Always fetch tick size\nfrom live `meta`, never hardcode it.**\n\n---\n\n## Worked Examples\n\n### Example 1 — BTC, Normal Conditions\n\n```\nInputs:\n  mid_price       = 91,500.00\n  best_bid        = 91,494.00\n  best_ask        = 91,506.00\n  raw_spread_bps  = 12 \u002F 91,500 * 10,000 = 1.31 bps\n  volatility_bps  = 3.2 bps  (last 5m trades)\n  side            = \"buy\"\n  urgency         = \"normal\"\n  book_fragility  = 0.10\n\nCalculation:\n  half_spread     = 0.655 bps\n  safety_buffer   = max(0.5, 0.655 * 0.10) = 0.50 bps\n  vol_buffer      = 3.2 * 0.20 = 0.64 bps\n  base_offset     = 0.655 + 0.50 + 0.64 = 1.795 bps\n  urgency_mult    = 1.0\n  fragility_mult  = 1.0 + (0.10 * 0.5) = 1.05\n  offset_bps      = 1.795 * 1.0 * 1.05 = 1.885 bps  → clamped to range: 1.885\n\nLimit price:\n  offset_price    = 91,500 * (1.885 \u002F 10,000) = 1.725\n  raw_price       = 91,500 - 1.725 = 91,498.275\n  tick_size       = 1 decimal → floor to 91,498.2\n\nOrder submitted: BUY limit 91,498.2  (Alo, tif=\"Alo\")\n```\n\n### Example 2 — ETH, Elevated Volatility\n\n```\nInputs:\n  mid_price       = 1,792.00\n  raw_spread_bps  = 2.80 bps\n  volatility_bps  = 8.5 bps  (elevated; approaching news event)\n  side            = \"sell\" (TP exit)\n  urgency         = \"patient\"\n  book_fragility  = 0.25\n\nCalculation:\n  half_spread     = 1.40 bps\n  safety_buffer   = max(0.5, 1.40 * 0.10) = 0.50 bps\n  vol_buffer      = 8.5 * 0.20 = 1.70 bps\n  base_offset     = 1.40 + 0.50 + 1.70 = 3.60 bps\n  urgency_mult    = 1.5  (patient)\n  fragility_mult  = 1.0 + (0.25 * 0.5) = 1.125\n  offset_bps      = 3.60 * 1.5 * 1.125 = 6.075 bps  → clamped to 5.0 bps\n\nLimit price:\n  offset_price    = 1,792 * (5.0 \u002F 10,000) = 0.896\n  raw_price       = 1,792 + 0.896 = 1,792.896\n  tick_size       = 2 decimals → ceil to 1,792.90\n\nOrder submitted: SELL limit 1,792.90  (Alo, tif=\"Alo\")\n```\n\n---\n\n## Fill Rate Monitoring and Self-Calibration\n\nMetaClaw’s skills auto-evolve from deployment experience. To enable\nthis skill to improve its offset calibration over time, log sufficient\ndata for the RL replay buffer:\n\n```json\n{\n  \"event\": \"limit_order_offset_calc\",\n  \"asset\": \"BTC\",\n  \"timestamp_utc\": \"2026-04-07T22:00:00Z\",\n  \"side\": \"buy\",\n  \"mid_price\": 91500.00,\n  \"raw_spread_bps\": 1.31,\n  \"volatility_bps_5m\": 3.2,\n  \"book_fragility\": 0.10,\n  \"urgency\": \"normal\",\n  \"offset_bps_computed\": 1.885,\n  \"limit_price\": 91498.2,\n  \"order_result\": \"filled\",        \u002F\u002F \"filled\", \"partial\", \"expired\", \"rejected\"\n  \"fill_latency_seconds\": 14.3,    \u002F\u002F time from placement to fill\n  \"fill_price\": 91498.2,\n  \"slippage_bps\": 0\n}\n```\n\n### Fill Rate Thresholds for Recalibration\n\nIf the rolling 50-order fill rate for a given asset falls outside the\nacceptable range, recalibrate the offset multipliers:\n\n| Fill Rate | Diagnosis | Recalibration Action |\n|---|---|---|\n| > 95% | Offset too deep | Reduce `urgency_multiplier` by 0.1; or reduce `safety_buffer` |\n| 80–95% | Optimal range | No change |\n| 60–80% | Offset borderline | Review spread regime; check for persistent wide spread |\n| \u003C 60% | Offset too tight | Increase `vol_buffer` coefficient (0.20 → 0.25); or switch urgency to `patient` |\n| High rejection rate | Alo crossing spread | Increase `safety_buffer` to 1.0 bps; review mid-price staleness |\n\n---\n\n## Failure Modes to Avoid\n\n- **Using a static offset across all assets and conditions**: BTC at\n  1 bps spread needs a different offset than DOGE at 8 bps spread.\n  Offset must be computed per-asset per-order from live data.\n- **Anchoring to `mid_price` from a stale snapshot**: Mid-price from\n  the last REST poll may be 200–500ms old on a fast market. Use the\n  WebSocket `l2Book` subscription for real-time mid when placing orders\n  in volatile conditions (`volatility_bps > 5`).\n- **Ignoring tick size rounding direction**: Rounding a buy limit price\n  *up* instead of *down* can push it above best ask, crossing the spread\n  and triggering `Alo` rejection. Always floor buy prices and ceil sell\n  prices after offset application.\n- **Applying the upper clamp (5.0 bps) as a routine offset**: The 5.0 bps\n  clamp is a safety ceiling, not a target. Consistently hitting the clamp\n  means market conditions are too volatile or illiquid for maker execution;\n  the correct response is to defer the order, not to accept a 5 bps\n  penalty as standard.\n- **Not refreshing offset on order re-queue**: If an `Alo` order expires\n  or is cancelled and must be reposted, **recompute the offset from fresh\n  data**. Market conditions at repost time may be materially different\n  from the original placement.\n- **Conflating offset with slippage**: Offset is the deliberate distance\n  placed *into the book* on the maker side. Slippage is unintended price\n  deviation on taker fills. They are separate quantities; do not use\n  slippage tolerance parameters to govern maker order offsets.\n\n---\n\n## Integration with Other Skills\n\n- **`maker-order-preference-fee-reduction`** (execution\u002F): Run first to\n  decide *whether* to use `Alo`. This skill runs second to decide *where*\n  to place the `Alo` order. They are always used together.\n- **`slippage-budget-enforcement`** (execution\u002F): For taker orders, that\n  skill governs the price tolerance. This skill is maker-path only.\n- **`liquidation-cascade-risk`** (regime-detection\u002F): Passes\n  `book_fragility` score as an input to this skill’s offset formula.\n  Higher fragility → wider offset → less chance of `Alo` rejection\n  from a volatile book.\n- **`trending-bull-entry-timing`** (regime-detection\u002F): Provides\n  the Fibonacci target price as the *anchor* for the offset calculation.\n  This skill computes the final submitted price around that anchor.\n\n---\n\n## Quick Decision Tree\n\n```\nNeed to place an Alo limit order — what price?\n│\n├── 1. Fetch live l2Book → best_bid, best_ask, mid_price\n├── 2. Compute raw_spread_bps and volatility_bps (last 5m trades)\n├── 3. Get book_fragility from liquidation-cascade-risk if available\n├── 4. Classify spread regime (tight \u002F normal \u002F wide \u002F illiquid)\n│     └── Illiquid (> 10 bps)? → Defer or escalate to taker decision\n├── 5. Set urgency: normal (default) \u002F patient (wide spread or low urgency)\n├── 6. Run compute_limit_offset_bps() → offset_bps\n├── 7. Run compute_limit_price() with tick_size from live meta → limit_price\n├── 8. Submit order with tif=\"Alo\" at computed limit_price\n│\n├── Alo FILLS → log event with fill_latency. Done.\n├── Alo REJECTS → price moved. Recompute offset from fresh data. Reassess entry.\n└── Alo EXPIRES (GTC timeout) → Recompute. Re-evaluate setup validity.\n```\n","# Limit Order Offset (BPS) Calculation\n\n## When This Skill Activates\n\nApply this skill **every time an `Alo` (post-only) limit order price must\nbe determined** before submission. The skill answers: *how many basis\npoints inside or outside the spread should the limit price be placed?*\n\nAlso apply when:\n- An `Alo` order was rejected (price crossed spread) and a new offset\n  must be computed before reposting\n- Fill rate on resting limit orders is unacceptably low and offset\n  calibration needs review\n- A new asset is being traded for the first time and no historical\n  offset data exists yet\n- Spread has widened significantly (low liquidity period, news event)\n  and the standard offset is stale\n\n---\n\n## Core Principle\n\nA post-only limit order placed **too far from mid** rests on the book\nfor a long time and may never fill — opportunity cost. Placed **too\nclose to mid** it risks crossing the spread on a momentary tick and\nbeing rejected as a taker (or, with `Gtc`, accidentally paying taker\nfee). The optimal offset is the minimum distance from mid that reliably\nlands inside the book as a resting maker order given current spread and\nvolatility, without being so far away that fill probability collapses.\n\n> **Rule**: Place limit orders at `mid ± offset_bps` where `offset_bps`\n> is computed fresh from live spread and recent volatility at the time\n> of each order. Never use a hardcoded static offset across all market\n> conditions.\n\n---\n\n## Inputs Required\n\nFetch all of the following from HyperLiquid before computing offset:\n\n```python\n# From WebSocket l2Book or REST \u002Finfo → l2Book(coin):\nbest_bid   = l2book[\"levels\"][0][0][\"px\"]   # highest bid price\nbest_ask   = l2book[\"levels\"][1][0][\"px\"]   # lowest ask price\nmid_price  = (best_bid + best_ask) \u002F 2\nraw_spread_bps = (best_ask - best_bid) \u002F mid_price * 10000\n\n# From REST \u002Finfo → meta + assetCtxs:\nmark_price = asset_ctx[\"markPrice\"]         # oracle mark; use for offset anchor\ntick_size  = asset_meta[\"szDecimals\"]       # price precision (decimal places)\n\n# From recent trade history (last 50–100 trades, 5m window):\nimport statistics\ntrade_prices  = [t[\"px\"] for t in recent_trades]\nvolatility_bps = statistics.stdev(trade_prices) \u002F mid_price * 10000\n# Short-window volatility: 1-sigma move in the last 5m in basis points\n```\n\n---\n\n## Offset Calculation\n\n### Base Offset Formula\n\n```python\ndef compute_limit_offset_bps(\n    raw_spread_bps: float,\n    volatility_bps: float,             # 5m 1-sigma in bps\n    side: str,                         # \"buy\" or \"sell\"\n    order_urgency: str = \"normal\",     # \"normal\", \"patient\", \"urgent\"\n    book_fragility: float = 0.0,       # 0–1; from liquidation-cascade-risk\n) -> float:\n    \"\"\"\n    Returns the offset in basis points from mid.\n    Positive offset = deeper into the book (better fill safety, worse fill rate).\n    \"\"\"\n    # Half-spread is the minimum safe distance to guarantee maker status\n    half_spread_bps = raw_spread_bps \u002F 2\n\n    # Safety buffer: 1 tick worth of extra clearance beyond half-spread\n    # Prevents rejection on micro-moves at the moment of submission\n    safety_buffer_bps = max(0.5, half_spread_bps * 0.10)\n\n    # Volatility buffer: scale with recent short-window vol to avoid\n    # being crossed during order transit latency (~50–200ms on HL)\n    vol_buffer_bps = volatility_bps * 0.20   # 20% of 1-sigma 5m vol\n\n    # Base offset: half-spread + safety + vol buffer\n    base_offset = half_spread_bps + safety_buffer_bps + vol_buffer_bps\n\n    # Urgency modifier:\n    urgency_multiplier = {\n        \"urgent\":  0.5,    # closer to mid; accept higher rejection risk for better fill\n        \"normal\":  1.0,    # standard\n        \"patient\": 1.5,    # deeper in book; lower rejection risk; slower fill\n    }[order_urgency]\n\n    # Book fragility modifier: widen offset when book is thin\n    # (thin books = higher vol transit risk = needs more clearance)\n    fragility_multiplier = 1.0 + (book_fragility * 0.5)\n\n    offset_bps = base_offset * urgency_multiplier * fragility_multiplier\n\n    # Clamp: never closer than 0.5 bps (tick noise floor)\n    #        never farther than 5.0 bps (fill probability collapses)\n    return max(0.5, min(5.0, offset_bps))\n```\n\n### Applying Offset to Order Price\n\n```python\ndef compute_limit_price(\n    mid_price: float,\n    offset_bps: float,\n    side: str,\n    tick_size_decimals: int,\n) -> float:\n    \"\"\"\n    Buy orders: place BELOW mid (offset into bid side)\n    Sell orders: place ABOVE mid (offset into ask side)\n    Round to asset tick size to avoid rejection for invalid price precision.\n    \"\"\"\n    offset_price = mid_price * (offset_bps \u002F 10000)\n\n    if side == \"buy\":\n        raw_price = mid_price - offset_price\n    else:  # sell\n        raw_price = mid_price + offset_price\n\n    # Round to valid tick size (round down for buys, up for sells\n    # to stay on the correct side of mid after rounding)\n    factor = 10 ** tick_size_decimals\n    if side == \"buy\":\n        return math.floor(raw_price * factor) \u002F factor\n    else:\n        return math.ceil(raw_price * factor) \u002F factor\n```\n\n---\n\n## Offset Calibration by Market Condition\n\n### Spread Regime Classification\n\nClassify current spread before applying offset to set urgency defaults:\n\n| Spread (bps) | Regime | Suggested Urgency | Notes |\n|---|---|---|---|\n| \u003C 1.0 | Tight | `normal` | Liquid; standard offset works well |\n| 1.0–2.5 | Normal | `normal` | Typical for mid-cap perps |\n| 2.5–5.0 | Wide | `patient` | Low liquidity; widen offset or wait |\n| 5.0–10.0 | Very wide | `patient` + size reduction | Consider deferring non-urgent entries |\n| > 10.0 | Illiquid | Defer or use `Ioc` taker if urgent | Maker fill unlikely at reasonable offset |\n\n> When spread > 10 bps and the entry is time-critical, the cost of\n> waiting for a maker fill (missing the move) may exceed taker fee.\n> Defer to `maker-order-preference-fee-reduction` for the explicit\n> taker-vs-maker decision; this skill only handles the offset calculation\n> for the maker path.\n\n### Volatility Regime Adjustment\n\n| 5m Volatility (bps) | Vol Regime | vol_buffer_bps | Effect on Offset |\n|---|---|---|---|\n| \u003C 2 | Low vol | 0.4 | Offset stays near minimum |\n| 2–5 | Normal vol | 0.4–1.0 | Standard offset range |\n| 5–10 | Elevated vol | 1.0–2.0 | Offset widens meaningfully |\n| 10–20 | High vol | 2.0–4.0 | Approach upper clamp; consider `patient` |\n| > 20 | Extreme vol | Clamp at 5.0 | Near-cascade conditions; see `liquidation-cascade-risk` |\n\n---\n\n## Asset-Specific Tick Size Reference\n\nHyperLiquid enforces strict price precision per asset. Submitting an\norder with more decimal places than allowed causes immediate rejection.\n\n```python\n# Always fetch live from \u002Finfo → meta:\nasset_tick_map = {\n    asset[\"name\"]: asset[\"szDecimals\"]\n    for asset in meta[\"universe\"]\n}\n\n# Common values at time of writing (verify live — do not hardcode):\n# BTC:  1 decimal place  (e.g. 91450.0)\n# ETH:  2 decimal places (e.g. 1791.40)\n# SOL:  3 decimal places (e.g. 138.250)\n# ARB:  5 decimal places (e.g. 0.47820)\n# DOGE: 6 decimal places (e.g. 0.072340)\n```\n\nThe `compute_limit_price()` function above handles rounding automatically\nwhen `tick_size_decimals` is passed correctly. **Always fetch tick size\nfrom live `meta`, never hardcode it.**\n\n---\n\n## Worked Examples\n\n### Example 1 — BTC, Normal Conditions\n\n```\nInputs:\n  mid_price       = 91,500.00\n  best_bid        = 91,494.00\n  best_ask        = 91,506.00\n  raw_spread_bps  = 12 \u002F 91,500 * 10,000 = 1.31 bps\n  volatility_bps  = 3.2 bps  (last 5m trades)\n  side            = \"buy\"\n  urgency         = \"normal\"\n  book_fragility  = 0.10\n\nCalculation:\n  half_spread     = 0.655 bps\n  safety_buffer   = max(0.5, 0.655 * 0.10) = 0.50 bps\n  vol_buffer      = 3.2 * 0.20 = 0.64 bps\n  base_offset     = 0.655 + 0.50 + 0.64 = 1.795 bps\n  urgency_mult    = 1.0\n  fragility_mult  = 1.0 + (0.10 * 0.5) = 1.05\n  offset_bps      = 1.795 * 1.0 * 1.05 = 1.885 bps  → clamped to range: 1.885\n\nLimit price:\n  offset_price    = 91,500 * (1.885 \u002F 10,000) = 1.725\n  raw_price       = 91,500 - 1.725 = 91,498.275\n  tick_size       = 1 decimal → floor to 91,498.2\n\nOrder submitted: BUY limit 91,498.2  (Alo, tif=\"Alo\")\n```\n\n### Example 2 — ETH, Elevated Volatility\n\n```\nInputs:\n  mid_price       = 1,792.00\n  raw_spread_bps  = 2.80 bps\n  volatility_bps  = 8.5 bps  (elevated; approaching news event)\n  side            = \"sell\" (TP exit)\n  urgency         = \"patient\"\n  book_fragility  = 0.25\n\nCalculation:\n  half_spread     = 1.40 bps\n  safety_buffer   = max(0.5, 1.40 * 0.10) = 0.50 bps\n  vol_buffer      = 8.5 * 0.20 = 1.70 bps\n  base_offset     = 1.40 + 0.50 + 1.70 = 3.60 bps\n  urgency_mult    = 1.5  (patient)\n  fragility_mult  = 1.0 + (0.25 * 0.5) = 1.125\n  offset_bps      = 3.60 * 1.5 * 1.125 = 6.075 bps  → clamped to 5.0 bps\n\nLimit price:\n  offset_price    = 1,792 * (5.0 \u002F 10,000) = 0.896\n  raw_price       = 1,792 + 0.896 = 1,792.896\n  tick_size       = 2 decimals → ceil to 1,792.90\n\nOrder submitted: SELL limit 1,792.90  (Alo, tif=\"Alo\")\n```\n\n---\n\n## Fill Rate Monitoring and Self-Calibration\n\nMetaClaw’s skills auto-evolve from deployment experience. To enable\nthis skill to improve its offset calibration over time, log sufficient\ndata for the RL replay buffer:\n\n```json\n{\n  \"event\": \"limit_order_offset_calc\",\n  \"asset\": \"BTC\",\n  \"timestamp_utc\": \"2026-04-07T22:00:00Z\",\n  \"side\": \"buy\",\n  \"mid_price\": 91500.00,\n  \"raw_spread_bps\": 1.31,\n  \"volatility_bps_5m\": 3.2,\n  \"book_fragility\": 0.10,\n  \"urgency\": \"normal\",\n  \"offset_bps_computed\": 1.885,\n  \"limit_price\": 91498.2,\n  \"order_result\": \"filled\",        \u002F\u002F \"filled\", \"partial\", \"expired\", \"rejected\"\n  \"fill_latency_seconds\": 14.3,    \u002F\u002F time from placement to fill\n  \"fill_price\": 91498.2,\n  \"slippage_bps\": 0\n}\n```\n\n### Fill Rate Thresholds for Recalibration\n\nIf the rolling 50-order fill rate for a given asset falls outside the\nacceptable range, recalibrate the offset multipliers:\n\n| Fill Rate | Diagnosis | Recalibration Action |\n|---|---|---|\n| > 95% | Offset too deep | Reduce `urgency_multiplier` by 0.1; or reduce `safety_buffer` |\n| 80–95% | Optimal range | No change |\n| 60–80% | Offset borderline | Review spread regime; check for persistent wide spread |\n| \u003C 60% | Offset too tight | Increase `vol_buffer` coefficient (0.20 → 0.25); or switch urgency to `patient` |\n| High rejection rate | Alo crossing spread | Increase `safety_buffer` to 1.0 bps; review mid-price staleness |\n\n---\n\n## Failure Modes to Avoid\n\n- **Using a static offset across all assets and conditions**: BTC at\n  1 bps spread needs a different offset than DOGE at 8 bps spread.\n  Offset must be computed per-asset per-order from live data.\n- **Anchoring to `mid_price` from a stale snapshot**: Mid-price from\n  the last REST poll may be 200–500ms old on a fast market. Use the\n  WebSocket `l2Book` subscription for real-time mid when placing orders\n  in volatile conditions (`volatility_bps > 5`).\n- **Ignoring tick size rounding direction**: Rounding a buy limit price\n  *up* instead of *down* can push it above best ask, crossing the spread\n  and triggering `Alo` rejection. Always floor buy prices and ceil sell\n  prices after offset application.\n- **Applying the upper clamp (5.0 bps) as a routine offset**: The 5.0 bps\n  clamp is a safety ceiling, not a target. Consistently hitting the clamp\n  means market conditions are too volatile or illiquid for maker execution;\n  the correct response is to defer the order, not to accept a 5 bps\n  penalty as standard.\n- **Not refreshing offset on order re-queue**: If an `Alo` order expires\n  or is cancelled and must be reposted, **recompute the offset from fresh\n  data**. Market conditions at repost time may be materially different\n  from the original placement.\n- **Conflating offset with slippage**: Offset is the deliberate distance\n  placed *into the book* on the maker side. Slippage is unintended price\n  deviation on taker fills. They are separate quantities; do not use\n  slippage tolerance parameters to govern maker order offsets.\n\n---\n\n## Integration with Other Skills\n\n- **`maker-order-preference-fee-reduction`** (execution\u002F): Run first to\n  decide *whether* to use `Alo`. This skill runs second to decide *where*\n  to place the `Alo` order. They are always used together.\n- **`slippage-budget-enforcement`** (execution\u002F): For taker orders, that\n  skill governs the price tolerance. This skill is maker-path only.\n- **`liquidation-cascade-risk`** (regime-detection\u002F): Passes\n  `book_fragility` score as an input to this skill’s offset formula.\n  Higher fragility → wider offset → less chance of `Alo` rejection\n  from a volatile book.\n- **`trending-bull-entry-timing`** (regime-detection\u002F): Provides\n  the Fibonacci target price as the *anchor* for the offset calculation.\n  This skill computes the final submitted price around that anchor.\n\n---\n\n## Quick Decision Tree\n\n```\nNeed to place an Alo limit order — what price?\n│\n├── 1. Fetch live l2Book → best_bid, best_ask, mid_price\n├── 2. Compute raw_spread_bps and volatility_bps (last 5m trades)\n├── 3. Get book_fragility from liquidation-cascade-risk if available\n├── 4. Classify spread regime (tight \u002F normal \u002F wide \u002F illiquid)\n│     └── Illiquid (> 10 bps)? → Defer or escalate to taker decision\n├── 5. Set urgency: normal (default) \u002F patient (wide spread or low urgency)\n├── 6. Run compute_limit_offset_bps() → offset_bps\n├── 7. Run compute_limit_price() with tick_size from live meta → limit_price\n├── 8. Submit order with tif=\"Alo\" at computed limit_price\n│\n├── Alo FILLS → log event with fill_latency. Done.\n├── Alo REJECTS → price moved. Recompute offset from fresh data. Reassess entry.\n└── Alo EXPIRES (GTC timeout) → Recompute. Re-evaluate setup validity.\n```\n",{"name":5,"category":29,"description":7},"main","cc32fdacf303e9c64064829787a5e690bb29cd47","multiclaw\u002Fmetaclaw\u002Fskills\u002Fexecution\u002Flimit-offset-bps-calculation",0,"https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm","https:\u002F\u002Fgithub.com\u002Fenuno","https:\u002F\u002Fenuno.github.io\u002FDynamicCareerCanvas","Digital Nomad, Blockchain Evangel, and Digital Solutions Architect. \r\nCreator of TerraHash Stack.\r\nCEO of Ryno Crypto Mining Services.","2026-07-02 12:46:02",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add enuno\u002Fhyperliquid-trading-firm --skill limit-offset-bps-calculation",{"tool":59,"command":60},"bunx","bunx skills add enuno\u002Fhyperliquid-trading-firm --skill limit-offset-bps-calculation",{"tool":62,"command":63},"pnpm","pnpm dlx skills add enuno\u002Fhyperliquid-trading-firm --skill limit-offset-bps-calculation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fmulticlaw\u002Fmetaclaw\u002Fskills\u002Fexecution\u002Flimit-offset-bps-calculation\u002FSKILL.md",true,[],[68,98,123,146,171,194],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M6J14V7SBT7MBPZ9VK8NRQR8","supermemory","Supermemory is a state-of-the-art memory and context infrastructure for AI agents. Use this skill when building applications that need persistent memory, user personalization, long-term context retention, or semantic search across knowledge bases. It provides Memory API for learned user context, User Profiles for static\u002Fdynamic facts, and RAG for semantic search. Perfect for chatbots, assistants, and knowledge-intensive applications.","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsupermemory\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[70,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,25,97],"ai agents","memory","rag","semantic search","infrastructure","search","user context","applications","api","knowledge","context","Art","personalization","across","learned","retention","profiles","persistent memory",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":39},"01M6J14PEXHE2QBAWM3YZ2GM63","wolverine-strategy","WOLVERINE v2.0 — HYPE alpha hunter. Entry-only scanner, DSL-exit-only architecture. v1.1 lost -22.7% because the scanner's thesis exit chopped 25\u002F27 trades before DSL could manage them. v2.0 removes thesis exit entirely. Scanner decides entries (score 8+, 4H\u002F1H aligned, SM consensus). DSL manages all exits (wide Phase 1 for HYPE volatility, trailing tiers starting at +15% ROE). Leverage lowered to 7x. Max 4 entries\u002Fday. 3-hour cooldown between entries. DSL exit managed by plugin runtime via runtime.yaml.","MIT","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsenpi-skills\u002Fwolverine\u002FSKILL.md",[],[106,107,108,109,37,110,34,111,112,113,114,115,116,117,118,119,120,121,122,25],"strategy","wolverine strategy","architecture","alpha","consensus","trading","scanner","manage","max","exit","hyperliquid","entries","thesis","runtime","leverage","hunter","at",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":39},"01M6J14FQY9YG5QB45QK4D98AZ","wolf-strategy","WOLF v6.3 — Fully autonomous multi-strategy trading for Hyperliquid perps via Senpi MCP. Manages multiple strategies simultaneously, each with independent wallets, budgets, slots, and DSL configs. 5+N cron architecture: 5 shared wolf crons (Emerging Movers 3min, SM Flip 5min, Watchdog 5min, Risk Guardian 5min, Health Check 10min) plus one DSL v5.2 cron per strategy (native Hyperliquid SL sync via dsl-dynamic-stop-loss skill v5.3.1). Same asset can be traded in different strategies simultaneously. Enter early on first jumps, not at confirmed peaks. Dynamic risk-based leverage per strategy. Requires Senpi MCP connection, python3, mcporter CLI, OpenClaw cron system, and dsl-dynamic-stop-loss skill (provides dsl-cli.py + dsl-v5.py).","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsenpi-skills\u002Fwolf-strategy\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发",[106,133,134,135,136,137,108,138,139,111,116,140,141,142,120,28,143,144,122,145],"wolf strategy","MCP","openclaw","cli","sync","watchdog","autonomous","perps","strategies","shared","native","wallets","hyperliquid perps",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":39},"01M6J14A20TMQ772M3H80XNB2T","wolf-howl","HOWL v2 — Hunt, Optimize, Win, Learn. Nightly self-improvement loop for the WOLF autonomous trading strategy. Runs once per day (via cron) to review all trades from the last 24 hours, compute win rates, analyze signal quality correlation, evaluate DSL tier performance, identify missed opportunities, and produce concrete improvement suggestions for the wolf-strategy skill. v2 adds fee drag ratio (FDR) analysis, holding period bucketing, LONG vs SHORT regime detection, rotation cost tracking, cumulative drift detection, and gross vs net profit factor separation. Use when setting up daily trade review automation, analyzing trading performance, or improving an autonomous trading strategy through data-driven feedback loops. Requires Senpi MCP connection, mcporter CLI, and OpenClaw cron system.","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsenpi-skills\u002Fwolf-howl\u002FSKILL.md",[152],{"categoryNo":130,"categoryName":131,"taxonomyType":77,"taxonomyTypeDesc":78},[154,134,155,136,156,157,158,159,160,161,139,162,163,164,165,166,167,168,169,170],"wolf howl","review","performance","learn","analysis","loop","analyze","short","up","optimize","drift","missed","self","factor","loops","profit","data-driven",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":175,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":39},"01M6J1469QYZMD7E6JDP8Z9X1V","whale-index","Auto-mirror top Discovery traders on Hyperliquid. Scans top 50 traders, scores on PnL rank (35%), win rate (25%), consistency (20%), hold time (10%), drawdown (10%). Creates 2-5 mirror strategies with overlap checks. Daily rebalance with 2-day watch period before swaps. Use when setting up trader mirroring, copy trading, or portfolio auto-rebalancing based on Discovery leaderboard performance.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsenpi-skills\u002Fwhale-index\u002FSKILL.md",[],[179,180,181,156,182,183,184,35,185,186,162,187,188,141,189,190,191,192,25,193],"index","whale","whale index","auth","monitoring","discovery","auto","portfolio","daily","time","with","consistency","top","mirror","pnl",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":102,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":39},"01M6J141MJ2JMM7X3BGEEW30J9","vixen-strategy","VIXEN v1.0 — Dual-mode emerging movers scanner. Built from FOX v1.6 live trading data (+34.5% ROI). Two entry modes: STALKER (steady accumulation, score 6+, catches the SM buildup BEFORE the explosion) and STRIKER (violent FIRST_JUMP, score 9+, with raw volume confirmation to filter blow-off tops). 2-hour per-asset cooldown after Phase 1 exits. DSL High Water Mode mandatory.","https:\u002F\u002Fgithub.com\u002Fenuno\u002Fhyperliquid-trading-firm\u002Fblob\u002Fmain\u002Fskills\u002Fsenpi-skills\u002Fvixen\u002FSKILL.md",[],[106,201,202,203,204,205,111,112,116,206,207,208,28,189,209,210,211,212,213,214],"vixen strategy","roi","data","first","confirmation","volume","live","filter","explosion","mode","high","v1","modes","emerging movers"]