Scale
Scale orders distribute one total size across N limit orders between Start and End. Full reference: distribution math, skew, TP ladder, fees, edge cases.
A scale order is N independent limit orders posted in one batch, distributed across a price range you define. It is the right tool when you don't want to commit to a single entry level but want to lay down a structured ladder across a range of acceptable prices.
Execution Model
A scale order produces exactly one order action containing N OrderRequest legs, sent in one signed request. Each leg is independent on the exchange — they fill, rest, or get cancelled separately. Hyperliquid does not track them as "one scale order"; that's purely a client-side concept.
Wire format
{
type: "order",
orders: [
{ a, b, p: p₁, s: s₁, r, t: { limit: { tif } } },
{ a, b, p: p₂, s: s₂, r, t: { limit: { tif } } },
...
{ a, b, p: pₙ, s: sₙ, r, t: { limit: { tif } } }
],
grouping: "na"
}
The grouping is "na" (no grouping). If you enable scale TP, a second batch is sent — see TP Ladder below.
Distribution Math
Given start price S, end price E, total size T, order count N, price skew α, and size skew β:
Prices (no skew, α = 0):
pᵢ = S + (E − S) × (i / (N − 1)) for i = 0..N−1
N evenly spaced points across the range.
Prices with skew (α ≠ 0):
tᵢ = i / (N − 1)
pᵢ = S + (E − S) × tᵢ^(1 + α) if α > 0 (clusters toward E)
pᵢ = S + (E − S) × (1 − (1 − tᵢ)^(1 + |α|)) if α < 0 (clusters toward S)
α is the "Top / Low" slider. Range −3 to +3. Positive bends the distribution toward End; negative toward Start.
Sizes (no skew, β = 0):
sᵢ = T / N
Equal size per leg.
Sizes with skew (β ≠ 0): The size-skew slider is mapped to a multiplier between the largest and smallest leg:
multiplier = sizeSkewFromSignedEdgeMultiplier(β) // 1× to 100×
weightᵢ = 1 + (multiplier − 1) × tᵢ if β > 0
weightᵢ = 1 + (multiplier − 1) × (1 − tᵢ) if β < 0
sᵢ = T × weightᵢ / Σ weightⱼ
The total still sums to T — what changes is where the weight concentrates.
Inputs
| Input | Required | Notes |
|---|---|---|
Side | Yes | Long/Short. |
Start | Yes | Lower price boundary. |
End | Yes | Upper price boundary. |
Orders (N) | Yes | 2–99. Number of legs. |
Size (T) | Yes | Total base-asset size across all legs. |
TIF | Yes | GTC / ALO / IOC. Default GTC. |
Price skew (α) | Optional | −3 to +3. Bends price distribution. |
Size skew (β) | Optional | Bends size distribution. |
Reduce Only | Optional | Applies to every leg. |
Take Profit | Optional | Adds a paired TP leg per entry — see below. |
TP Ladder
When Take Profit is enabled, every entry leg gets a matching reduce-only TP. The TP fires when mark price hits the configured level.
Two modes
% per leg (mode: "percent"):
tpᵢ = pᵢ × (1 ± percent / 100)
sign = +1 for long entries, −1 for short
Every leg exits at the same R:R regardless of where in the range it filled.
TP range (mode: "range"):
tpᵢ = tpStart + (tpEnd − tpStart) × tᵢ^(1 + tpSkew)
Same distribution shape as the entry ladder, just on the TP range. Paired 1:1 by index.
Order kind
- Limit — resting limit at the TP price. Earns maker on the exit.
- Market — trigger market when price touches the TP. Pays taker but guarantees exit.
Submission flow
The entries and TPs are sent in two separate batches because Hyperliquid limits how the normalTpsl grouping can be used. The flow:
- Batch 1: all N entry orders,
grouping: "na". - Batch 2: all M valid TP orders,
grouping: "na", eachreduceOnly: truewith atriggerorder type.
You'll see two toasts: one for entries, one for TPs. If the entry batch succeeds but the TP batch fails, entries are not rolled back — re-add TPs manually or via order modify.
Auto-fit for invalid legs
In range mode, if your TP range is narrower than the entry range or skewed wrong, some TPs end up on the wrong side of their entries (e.g. a long leg with TP below entry — that's not profit, it's loss). The UI scans for the smallest TP-skew adjustment that makes every leg valid. If none exists, invalid legs are dropped at submission and a warning shows.
When to Use
- You don't want to commit to a single entry level — the range matters.
- You're laddering into a position over a price range you find acceptable.
- You're a maker building inventory and want structured passive placement.
When Not to Use
Fees
Per-leg, based on TIF:
- ALO entries → maker fees on every fill.
- GTC entries that crossed at submit → taker on the crossed portion of those legs.
- GTC entries that rested → maker when later filled.
- TP limits → maker on fill.
- TP markets (trigger market) → taker on fill.
The summary box in the panel computes total expected fees assuming the typical case (maker on entries, depending kind on exits). Actual fees depend on actual fill paths.
Edge Cases & Failures
- Range with
start = end. Rejected client-side. - Total size below
N × $10. Some legs would be below the $10 minimum. The UI warns and you must increase total size, reduce N, or both. - All legs on one side of mid. Possible if start and end are both above (for sells) or both below (for buys) mid. The legs that cross on send will fill immediately as takers; the rest rest passively.
- ALO + price crosses. Any leg whose price would cross on submit is rejected by Hyperliquid with the post-only error. The other legs may still succeed. The response statuses tell you which.
Concrete Example
Buy 1 ETH between 1,950 and 2,000 using 5 orders, no skew. Each leg = 0.2 ETH.
i=0: 0.2 ETH @ 1950
i=1: 0.2 ETH @ 1962.5
i=2: 0.2 ETH @ 1975
i=3: 0.2 ETH @ 1987.5
i=4: 0.2 ETH @ 2000
Add Price Skew = +2 (cluster toward End): leg prices bend so most cluster near 2,000. Add Size Skew = −1 (more size at Start): leg sizes become a decreasing series toward End, while still summing to 1.0 ETH.
Add TP = +3% per leg:
TP 0: 1950 × 1.03 = 2008.50
TP 1: 1962.50 × 1.03 = 2021.38
...
TP 4: 2000 × 1.03 = 2060.00
Each leg exits at +3% from its own entry, regardless of where in the range it actually filled.