Synthetix sKRW Oracle Outlier-Filter Failure / Bot Arbitrage Incident (2019-06-25)

  • Name: Synthetix sKRW oracle outlier-filter failure / bot arbitrage incident
  • Date: 2019-06-25
  • Protocol: Synthetix
  • Chain: Ethereum
  • Category: minimum live-source threshold failure / offchain oracle aggregation failure / synthetic-debt-pool distortion
  • Loss: over $1B of temporary synthetic profit was created during the incident window, but Synthetix said the bot owner agreed to reverse the trades in exchange for a bug bounty, so the protocol did not ultimately crystallize the full loss
  • Summary: Synthetix’s June 2019 sKRW incident was not a classic onchain market-manipulation attack. The root failure sat in the oracle stack itself, and more specifically in a minimum-live-source threshold collapse. One commercial FX API intermittently reported the Korean won about 1000x above its real value, and Synthetix’s outlier-handling logic degraded badly because an earlier unrelated outage had already reduced the KRW feed to only two live APIs. Instead of discarding the bad source, the system averaged the two remaining values and published a wildly wrong sKRW rate onchain. A trading bot detected the mispricing, repeatedly traded into and out of sKRW while the bad rate was live, and generated more than $1B of synthetic profit in under an hour. Synthetix halted oracle updates and trading, then negotiated reversal of the trades for a bug bounty. The preserved lesson is that oracle safety is not only about manipulation-resistant markets; it is also about feed redundancy, source-count assumptions, and the exact sample-size floor below which an outlier filter no longer deserves settlement authority.
  • Trigger / entry point:
    • Synthetix’s offchain FX oracle stack relied on several commercial APIs for KRW pricing.
    • Around 3am Sydney time on 2019-06-25, one of those APIs began intermittently reporting KRW at roughly 1000x the real rate.
    • Synthetix said its oracle normally discarded outliers, but only two KRW APIs were live at the time because an earlier unrelated outage had not been caught by exception reporting.
    • With only two prices left, the oracle averaged the bad print with the remaining good source and pushed the resulting false KRW price into the onchain exchange-rates contract.
    • A representative public trade from the incident window is tx 0xfc394ccdc54e4a16f10e41abedf1e9687017d2d92fb910872df7a008441fcdb7, which search-indexed Etherscan metadata describes as an Exchange call from 0xEDb85C31...8Fa5757da on 2019-06-24 16:19:43 UTC.
  • Root cause:
    • The decisive failure was not that one upstream source was wrong; it was that Synthetix’s oracle-safety assumptions depended on redundancy that was no longer present.
    • The outlier filter was designed for a multi-source setting whose real safety floor was higher than two live APIs, but the KRW feed had silently degraded to exactly that unsafe sample size, so one bad API effectively became half of the final answer.
    • Exception reporting failed to surface the earlier provider outage, so operators did not realize that the outlier filter had lost the source diversity it needed.
    • Because Synthetix treated the resulting onchain KRW price as authoritative for exchange settlement, a bot could turn the bad FX quote directly into synthetic profits.
  • Exploit path:
    1. An upstream commercial API began intermittently publishing a KRW rate about 1000x too high.
    2. Synthetix’s KRW oracle path had already lost other data sources because of an unrelated outage, leaving only two active API feeds.
    3. The offchain oracle aggregated those two remaining prices instead of rejecting the bad one, then forwarded the distorted KRW rate to the exchange-rates contract.
    4. A trading bot detected the false sKRW pricing and rapidly traded into and out of sKRW while the stale / bad rate was live.
    5. Those trades generated more than $1B of synthetic profit in less than an hour, a gain large enough to distort Synthetix’s debt pool if left standing.
    6. Community members alerted the team, and Synthetix’s CTO stopped the oracle service from pushing rates onchain, which halted trading and transfers.
    7. Synthetix then contacted the bot operator, who agreed to reverse the trades in exchange for a bug bounty, after which trading resumed.
  • What the attacker needed to be true:
    • The KRW feed had to be operating with too little live redundancy for one bad source to dominate the final answer.
    • The bad source had to survive long enough for the averaged price to be published onchain and consumed by exchange logic.
    • Synthetix had to keep settling trades against the false rate instead of pausing automatically when feed composition degraded.
    • A bot had to be fast enough to notice the bad price and route repeated exchanges before operators halted the oracle.
  • Technical anatomy worth remembering:
    • This incident is a strong minimum live-source threshold failure case, not a thin-liquidity spot-manipulation case. The market did not have to be pushed; the protocol’s own oracle stack published fiction.
    • The key failure was second-order: the outlier filter may have been acceptable with several live sources, but it became unsafe once silent provider loss reduced the sample size below the threshold where averaging still deserved settlement authority.
    • It therefore belongs under minimum-live-source-threshold-failure first and oracle-source-independence-failure second. The broader independence story still matters, but the decisive break was that the feed kept full trust semantics after redundancy had already collapsed below its safe operating floor.
    • Synthetix’s architecture mattered because exchange settlement flowed directly from the oracle into the debt pool. A bad FX quote did not just misprice one account; it threatened the system’s shared synthetic liabilities.
    • The operational lesson is ugly and durable: exception reporting on the oracle pipeline is part of the balance-sheet defense. If operators do not know redundancy has disappeared, they are already trading on a weaker oracle than they think.
  • Representative transactions and addresses:
    • Representative exchange tx: 0xfc394ccdc54e4a16f10e41abedf1e9687017d2d92fb910872df7a008441fcdb7
    • Representative trader address from indexed public explorer metadata: 0xEDb85C31...8Fa5757da
  • Response / mitigation:
    • Synthetix halted oracle updates, which in turn halted trading and transfers.
    • The team added more redundancy to price feeds and improved exception handling so a provider outage would not silently reduce oracle safety again.
    • Synthetix later migrated its synth oracles onto Chainlink’s decentralized oracle network, explicitly framing oracle robustness as core protocol infrastructure.

Pattern tags

  • minimum-live-source-threshold-failure
  • oracle-source-independence-failure
  • One bad upstream KRW print only became settlement-authoritative because the feed had already fallen to two live APIs, below the real sample-size floor where Synthetix’s outlier handling still made sense
  • Exception reporting failure let the protocol keep full trading semantics after source-count collapse had already downgraded oracle safety
  • The exploit path was pure protocol-authored price publication: no onchain market push was needed once degraded offchain aggregation started writing fiction into the exchange-rates contract

Why the exploit worked

  • Synthetix’s own incident response makes the decisive sequence unusually clear: one API went 1000x wrong, the KRW path was already down to two live APIs because of an unrelated outage, and the oracle therefore averaged the only two remaining values instead of rejecting the bad source. The exploit window existed because the feed kept full authority after it had already lost the sample-size assumptions behind its own filter.
  • The operational miss mattered as much as the arithmetic. Synthetix said the earlier outage had not been caught by exception reporting, so operators were not consciously choosing to settle on a degraded two-source feed; they were unknowingly doing it.
  • Downstream trust semantics never narrowed when redundancy collapsed. The same exchange logic and debt-pool accounting kept honoring KRW prices even though the feed was no longer in the mode its safety story assumed.
  • The attacker only needed speed and detection, not market power. Once the protocol published the bad sKRW rate onchain, a bot could monetize it by repeatedly cycling through the mispriced synth until humans halted the oracle.
  • The follow-on migration lesson is also explicit in Synthetix’s own later retrospective: the protocol treated stronger oracle decentralization and availability as core balance-sheet infrastructure, not as a peripheral ops improvement.

Detection and audit pivots

  • Ask every multi-source oracle what minimum live and independent source count its outlier filter, average, or median actually needs. If the answer is three or more, then two sources left but still publishing should already be a degraded-risk state, not a healthy one.
  • Monitor exception reporting for diversity loss, not only for total feed outage. Synthetix is the clean reminder that one provider failed silently can be more dangerous than all providers stopped if the protocol keeps settling value on the survivors.
  • Tie source-count collapse to automatic narrowing of permissions: pause fresh trading or borrowing, raise haircuts, or mark the feed unsafe for settlement until enough independent roots are back.
  • Rehearse the ugly middle state where the oracle still returns a plausible number but no longer has enough live sources for its filtering story to be meaningful. That is the state Synthetix actually failed in.
  • Review whether one bad input can become half the sample for any production feed. If yes, the feed needs either a higher minimum-source gate, a stronger degraded-mode path, or both.

Failure-prevention checklist

  • Define an explicit minimum live-source threshold per asset and aggregation rule. If KRW needs at least 3 independent quotes for outlier rejection to mean anything, then 2 live quotes must fail closed or enter a sharply narrowed degraded mode.
  • Publish feed-health metadata alongside price truth: live source count, stale / failed providers, independence class, and current operating mode should be visible to operators and, where practical, to downstream settlement code.
  • Separate we still have a number from we still have settlement-grade confidence. A feed that has lost quorum should not keep the same trading, borrowing, or liquidation authority just because an average can still be computed.
  • Treat source-loss monitoring as treasury infrastructure. Alerting, exception reporting, and provider-liveness checks should page humans before a degraded feed keeps writing prices onchain.
  • Predefine degraded-mode policy per asset: freeze new exposure, widen fees or haircuts, cap trade size, or pause entirely when source diversity collapses below the safe floor.
  • Test the exact bad-shape state, not only total outage and healthy quorum. The dangerous case is often one provider dead, one provider wrong, one provider good or two sources left and one is insane, not all feeds offline.
  • Demand meaningful independence across providers. Different API brands are not enough if they share the same upstream publisher, regional market data choke point, or operational failure domain.
  • Keep an operator kill-switch and a rehearsal path for halting publication quickly. Synthetix ultimately contained the loss by stopping oracle updates; the important design lesson is to make that brake fast, clear, and routinely practiced.

Audit prompts

  • What exact minimum source count does this feed’s median / average / outlier filter assume before its result deserves settlement authority?
  • When live source count falls below that floor, what exact permissions narrow automatically and where is that policy encoded?
  • Can one bad provider become 50% of the final answer for any production asset today?
  • How does the system distinguish provider outage, provider staleness, provider disagreement, and healthy but volatile market move, and which of those states still permit trading or borrowing?
  • Are operators alerted on source diversity loss itself, or only when the final published price looks obviously wrong?
  • What evidence shows the supposedly different providers are actually independent in data origin, infrastructure, and operator control?
  • Can downstream consumers inspect feed-health state, or do they only see a scalar price with no indication that quorum has already collapsed?
  • If humans need to halt publication manually, how quickly can they do it, who can do it, and has that path been rehearsed under time pressure?

Lessons that should already be standard

  • Outlier rejection exists is not a complete control statement. The real safety question is what minimum live-source count makes that rejection logic meaningful in production.
  • A price feed that has lost quorum but still publishes is often more dangerous than a feed that has gone fully offline. Full outage is visible; degraded authority with hidden sample-size collapse can keep settling bad state.
  • Feed health is not just the final number. Source count, freshness, disagreement, and independence are part of the price object’s security boundary.
  • Exception reporting is balance-sheet defense. If operators do not know a feed has silently fallen below its safe redundancy floor, the protocol is already running on fiction with official status.
  • Degraded mode should narrow permissions automatically. Trading, borrowing, minting, or liquidation flows should not retain healthy-mode authority merely because the system can still compute a scalar output.
  • One bad provider must never be able to become half the truth for a settlement-grade feed without tripping a harder fail-safe.
  • Migration to stronger oracle infrastructure is not just decentralization theater when the incumbent design cannot express we still have a number, but we no longer have enough independent roots to trust it.

Why this incident matters

  • It is an early canonical example of offchain oracle infrastructure failure turned directly into onchain economic truth.
  • It broadens the exploit corpus beyond attacker-manipulated AMM reads and stale feeds: here the issue was source diversity collapse plus bad aggregation logic under degraded conditions.
  • It is also the corpus’s cleanest exemplar that outlier filter exists is not the right control question; the real question is what happens when the number of live sources falls below the filter’s minimum safe threshold.
  • It usefully sharpens the taxonomy between independence was fake all along and independence or liveness may once have been adequate, but the feed silently kept full authority after sample-size collapse made the aggregation rule unsafe.

Internal linkages

Control surface

  • The decisive leverage sat in source redundancy, outlier-filter assumptions, exception reporting, and the operator-controlled pipeline that turned offchain FX data into onchain settlement prices.
  • Synthetix did not fail because KRW markets were manipulable onchain. It failed because one bad upstream print plus silent source-count collapse became protocol truth.

Sources

Last reviewed

  • 2026-07-26 UTC