One share almost closed a $400M market
A single SK Hynix share printed 29.96% below the prior close on a thin Seoul pre-market. The print travelled 5,500 miles into an on-chain perpetual, the mark fell 18.7%, and roughly 960 long accounts were liquidated. The risk was in the reference market, not in the crypto venue. How that happened, and what it tells you about any perp tracking an asset that does not trade 24/7.
On 28 July 2026, at 08:00 in Seoul, a single share of SK Hynix changed hands. It printed at 1,272,000 won, which is 29.96% below the previous close of 1,816,000 won, right at the daily lower price limit. The stock recovered into the 1.7 million won range about two minutes later.
The recovery was irrelevant. By then the print had been relayed into a USDC-margined perpetual on Hyperliquid, and the damage was done.
The mechanism is the risk here, not the incident.
The contract tracks one share, and one share is all it needs
The market is xyz:SKHYNIX, a USDC-margined perpetual allowing up to 10x leverage. Hyperliquid's live API still lists it at a maximum leverage of 10, on a deployment running 131 assets. It is not a small or experimental market: open interest was $638 million as of 30 July, making it the largest HIP-3 market on the network by open interest, per Hyperliquid's HIP-3 documentation.
The contract is transparent about its pricing. [trade[XYZ]'s perpetual market specification](https://docs.trade.xyz/perpetuals) states:
The SKHYNIX oracle price tracks the USD value of 1 common share of SK Hynix Inc. The oracle price can be replicated by dividing the KRW price of 000660 KS Equity by the USD/KRW exchange rate.
That is the whole specification. One share. Whatever venue reports that share last is what the oracle carries, divided by USD/KRW to get the dollar price the contract is margined against.
trade[XYZ] also documents the schedule, and the schedule is the second half of the problem. For Korean equities the relayer takes external prices during three windows:
- Pre-market Session, 8:10 to 8:50 Korea time
- Main Session, 9:01 to 3:30
- After-hours Session, 3:40 to 8:00
Everything else falls to an internal pricing mechanism that drifts off the venue's own order book, and that internal phase runs from 8:00 pm to 8:00 am on weekdays and from Friday 8:00 pm to Monday 8:00 am. A Korean equity's reference market is shut for roughly 19 of every 24 hours.
The bad print arrived exactly at the handoff
This is the detail that makes the case worth reading rather than dismissing as a fat-finger rumour.
Galaxy Research notes that trade[XYZ] switches from internal pricing to external pricing the moment the pre-market opens, and that "the anomalous print landed precisely at that handoff." On-chain records show the oracle component submitting an external price of $868.17 seconds after the switch.
The 7/28 changelog entry in trade[XYZ]'s own documentation shows the pre-market window moving from 8:00 am to 8:10 am. The docs carry no intraday timestamp, so I cannot establish whether the change was in force before or after the print. What I can say is that the print landed inside the old window by about a minute.
A corrupted price is easiest to dismiss if you imagine the system sitting comfortably inside a normal session. It arrived at the seam instead.
The safeguards ran, and they were not enough
trade[XYZ] builds the mark price as the median of three inputs. From their mark price documentation:
The mark price, used for margining, liquidations, stop/limit triggers, and unrealized P&L, is the median of three components: 1. The oracle price. 2. The sum of the oracle price and a 150-second continuous-time exponentially weighted moving average of the difference between the perpetual's mid-price and the oracle price. 3. The median of the best bid, best ask, and last trade.
A median of three should isolate one bad input, which is exactly what a median is for.
Galaxy's figure for how much it absorbed is the most useful number in the event: the smoothing "absorbed about 11 percentage points of a 30% corrupted input." The mark still fell 18.7%.
So roughly a third of the move got eaten. The rest passed through. Discovery bounds restrict the mark within plus or minus one-over-max-leverage of a reference price, which at 10x is plus or minus 10%, and trade[XYZ] clamps each relayer update to plus or minus 50 basis points.
Neither control limits the total move. A clamp is per update, so an 18.7% reprice accumulates across successive updates. Their own risk disclosure puts it plainly: "A limit on the size of an individual price update does not guarantee that cumulative movements will be small or that liquidation will be avoided."
The provider's own documentation predicted it
This is the part that should stop a reader who thinks this was bad luck. It was documented.
From trade[XYZ]'s perpetual risk disclosure:
A source value may be genuinely published by the relevant source and still be erroneous or economically unrepresentative. For example, a source may reflect an erroneous order or trade, a small transaction during a thin or extended-hours session, a venue-specific dislocation, a reopening auction, a trading halt, or a stale quotation. An authentic source-market print is not necessarily fair value but may nonetheless be incorporated into a market.
And on why a median does not save you:
Because the oracle price is an input into more than one component of the xyz mark-price methodology, median construction does not guarantee that an erroneous or anomalous oracle input will be isolated. A source anomaly can affect the mark price and cause funding payments, order triggers, margin changes, or liquidation even when no trade occurs at that price on the xyz order book.
The second paragraph explains the failure exactly. The oracle price feeds both deployer-supplied components of the median, so two of the three votes were wrong together and the median had nothing to isolate against. A median protects you from one bad input. It does not protect you from one bad input that arrives twice.
Who owns the risk when a deployer sets the price
On Hyperliquid's builder-deployed perps, whoever launches the market sets its price. The HIP-3 proposal states the deployer "is responsible for" market definition including the oracle definition, and for "market operation, including setting oracle prices, leverage limits, and settling the market if needed."
At the protocol level the split is uneven. Hyperliquid's API documentation shows the protocol computing one input itself, the local mark price as the median of best bid, best ask and last trade. The deployer supplies the rest. Prices are clamped to 10x the start-of-day value and mark moves to 1% from the previous mark.
Protection against abuse is economic. A deployer must stake 500k HYPE, and validators can slash that stake by stake-weighted vote. Hyperliquid concedes the limit: "Slashing is technical and does not distinguish between malicious and incompetent behavior," and "In the most likely outcome, slashing never happens on mainnet."
Nobody here acted maliciously. The deployer followed their published specification. The system worked as written and still cost roughly 960 accounts their positions.
What actually happened to the traders
At 23:01 UTC on 27 July the SKHYNIX mark price went from $1,127.9 to $917.25. Open interest fell from $481 million to $331 million within minutes. On-chain analysts put liquidated notional between $57 million and $80 million across roughly 960 long accounts. Profitable shorts were auto-deleveraged on the way through, and a system backstop address absorbed 406 long positions before being liquidated itself.
trade[XYZ] called the print "based on an executed trade which was relayed by multiple independent data providers," and said "The oracle system worked as intended according to its specification." They committed to covering eligible losses, adding plainly: "This is a one-time discretionary decision and is not a guarantee of similar future action."
Distributions went out on 1 August. Each eligible liquidation was measured against a reference price of $1,115.5. Anything under 10,000 USDC was credited in full; above that, an initial 9,999 USDC was credited pending enhanced due diligence.
Two things about that settlement deserve attention. It was discretionary, not policy. And $1,115.5 is not the entry of anyone liquidated into the fall. A reimbursement is a goodwill gesture, not a hedge.
What this means for a perp you are actually trading
The lesson is narrow, and it is not about SK Hynix or Hyperliquid specifically. It is about the structure of the instrument.
A perpetual tracking a 24/7 asset takes its price from a 24/7 market, and that reference is deep enough to argue with. A perpetual tracking an equity, an index, or a commodity inherits a reference market that is closed for most of the day and thinnest at the exact moment it reopens. The mark is set by something you are not trading and cannot see.
The check is simple. Before taking leverage in any perp whose underlying is not a crypto asset, answer one question: what is the reference market, and is it open right now? If the answer involves a venue in another time zone that is closed or pre-opening, your liquidation is measured against a market with almost no participants in it. The contract is quoted, margined and marked continuously while the thing it is about is asleep.
Two habits follow. Keep size smaller than the leverage number suggests, because the reference has less liquidity than the contract does. And treat a reimbursement as a decision someone made afterwards. The engineering answer is to assume the print is exactly what the oracle says, because on the evidence here, it was.
The risk you bear in this structure is not a bug in the crypto venue. It is a gap in the data you were never shown, and the code that consumed it behaved correctly all the way into the loss.
Cryptocurrency trading, leveraged perpetual futures, and automated algorithmic strategies carry significant risk of rapid and total financial loss. Never risk funds you cannot afford to lose completely.
Sources
Every figure in this piece traces to one of these:
- [trade[XYZ] documentation](https://docs.trade.xyz) and its perpetual market specification: the oracle definition, the 10x leverage cap, the relayer and mark-move clamps, and the staking and slashing rules.
- Hyperliquid's HIP-3 documentation: how builder-decentralised markets price and settle.
- Galaxy Research's write-up of the incident: the mechanism detail: the EMA absorbing about 11 percentage points of a 30% bad input.
- Hyperliquid's robust price indices documentation: how a mark price is constructed from multiple sources.
- CoinDesk, 29 July 2026 for the contemporaneous account and trade[XYZ]'s own response.