Worked example · 2025-04

KiloEx oracle-feed manipulation — multi-chain (BNB Chain, Base, Manta, Taiko) — 2025-04-14

Loss: approximately $7.5M extracted across four KiloEx deployments — BNB Chain, Base, Manta Pacific, and Taiko — within a single attack window beginning approximately at the time of the first manipulation transaction on April 14, 2025. KiloEx is a perpetual-futures DEX with synchronised deployments across multiple EVM chains; the attack hit each deployment's on-chain price-update path in close temporal succession, with the attacker reusing the same funding cluster and the same flash-loan-funded execution pattern across chains.
Recovery: approximately full recovery (~100% of the extracted balance) via on-chain bounty negotiation. KiloEx published an on-chain return-address offer within hours of detection, framed as a 10% bounty in exchange for return of the residual 90%. The attacker accepted the offer; funds were returned across the affected chains within ~72 hours of the initial extraction. Per the KiloEx public communications and corroborating SlowMist analysis, the recovery covered the full operational loss; user-margin balances were re-credited and trading on the affected deployments was restored under a coordinated re-launch.
OAK Techniques observed: OAK-T9.004 (Access-Control Misconfiguration) as the primary mechanistic classification — the _setPrices() function on KiloEx's MinimalForwarder contract lacked an onlyKeeper access-control modifier, allowing any external caller to set an arbitrary oracle price that the protocol's mark-price computation then consumed as authoritative. OAK-T9.001 (Oracle Price-Feed Manipulation) as the downstream effect — the attacker-supplied price reading drove the protocol's mark-price computation to an attacker-favourable value, enabling position extraction against the manipulated price. OAK-T9.002 (Flash-Loan-Enabled Exploit) as the precondition — the manipulation transaction was funded via a flash loan that supplied the inventory necessary to drive the oracle reading and execute the resulting position extraction within a single atomic transaction. The Pyth oracle network was the specific oracle vendor in the integration path; the public forensic write-ups attribute the failure to KiloEx's integration of the Pyth feed (specifically, the handling of price-update authorisation on the protocol side), not to a fault in the Pyth network's signed-price-message infrastructure itself.
Attribution: pseudonymous. No public named-individual attribution; on-chain investigators traced the funding cluster across the affected chains and confirmed that the same operator-cluster ran each chain's leg of the exploit in close temporal succession, but no off-chain identification has been published. The bounty-acceptance interaction was conducted in pseudonymous form on-chain. There is no public OAK-G01 / state-actor attribution for this incident.
Key teaching point: synchronised multi-chain deployments amplify a single integration flaw into N near-simultaneous extraction events. KiloEx's deployments on BNB Chain, Base, Manta, and Taiko shared the relevant integration logic for consuming Pyth price updates. A single root-cause flaw in that integration produced four distinct extractions in rapid succession because the attacker did not need to re-discover or re-instrument the failure on each chain — the attack pattern was portable across deployments by construction. Defenders running multi-chain protocols should treat shared-integration code as a fan-out amplifier in their threat modelling: a single audit miss propagates linearly to every deployment that shares the code path, and the operational response time to detect-pause-isolate must contend with N deployments in parallel rather than one. KiloEx is the canonical 2025 worked example for this fan-out pattern in the perp-DEX category.

Summary

KiloEx is a perpetual-futures DEX that operates synchronised deployments across multiple EVM chains, sharing core protocol logic — including the price-feed integration path used to compute mark prices for open positions — across BNB Chain, Base, Manta Pacific, and Taiko. The protocol consumes signed price updates from the Pyth oracle network via the standard Pyth on-chain integration pattern: a relayer submits a signed price-update message that the consuming contract verifies before applying the new price to its mark-price state.

On April 14, 2025, an attacker exploited a flaw in KiloEx's integration of this update path. Per the public forensic write-ups (PeckShield, SlowMist, and KiloEx's own post-incident disclosure), the integration on the KiloEx side did not adequately authorise who was permitted to trigger price updates against KiloEx's oracle-consuming contracts, allowing the attacker to submit a price-update sequence that drove the protocol's mark-price reading to attacker-favourable values within a single atomic transaction. The attacker funded the exploit with a flash loan, opened outsized positions against the manipulated price, closed them against the protocol's true reserves, and repaid the flash loan within the same atomic block.

The exploit ran in close temporal succession across each of the four deployments. The attacker did not need to re-discover the integration flaw on each chain because the relevant code path was shared across deployments. Cumulative on-chain extraction reached approximately $7.5M across the four chains.

KiloEx detected the anomaly, paused the affected deployments, and within hours published a public on-chain return-address offer framed as a 10% bounty. The attacker accepted the offer and returned the residual 90% across each affected chain within ~72 hours. KiloEx subsequently coordinated a protocol re-launch under a corrected oracle-integration path; user-margin balances were re-credited at the recovered values.

For OAK's purposes the structurally important features are (a) the integration-side (not vendor-side) nature of the oracle failure — Pyth's signed-price infrastructure was not itself compromised — and (b) the multi-chain fan-out dynamic, where a single integration flaw in shared code produced four near-simultaneous extractions across four chains.

Timeline (UTC)

When	Event	OAK ref
Pre-event	KiloEx deploys perp-DEX contracts on BNB Chain, Base, Manta Pacific, and Taiko, sharing the oracle-integration code path that consumes Pyth signed-price updates	T9.001 surface (latent)
Pre-event	Authorisation gap in KiloEx's price-update path: protocol-side check on who may trigger a price update against the oracle-consuming contract is inadequate	(latent integration flaw)
2025-04-14	First manipulation transaction submitted against one of the affected KiloEx deployments; flash-loan-funded, single-block atomic extraction pattern	T9.001 + T9.002 extraction
2025-04-14	Attacker repeats the pattern across the remaining KiloEx deployments (BNB, Base, Manta, Taiko) in close temporal succession; cumulative outflow reaches ~$7.5M	T9.001 + T9.002 fan-out
2025-04-14	KiloEx operations team detects anomalous mark-price activity and outsized PnL events; pauses affected deployments	(operator response)
2025-04-14	KiloEx publishes public on-chain return-address offer framed as a 10% bounty in exchange for return of the residual 90%	(recovery negotiation)
2025-04-14 → 2025-04-17	Attacker accepts offer; funds returned across each affected chain; KiloEx confirms receipt	L1-equivalent recovery via bounty negotiation
2025-04 onward	KiloEx publishes post-incident write-up; corrected oracle-integration path deployed; user-margin balances re-credited; trading restored	(transparency, re-launch)

What defenders observed

The failure was integration-side, not vendor-side. Pyth's signed-price infrastructure was not the failure surface. The Pyth network's signed-price messages remained authentic; the price values they carried were consistent with the network's published feeds. The failure was in how KiloEx authorised the consumption of those signed messages on its own contracts — specifically, in who could trigger an update and against what state. Defenders integrating signed-oracle feeds (Pyth, Chainlink CCIP-style, RedStone, others) should treat the authorisation of update-triggering as a first-class part of the integration, not a peripheral concern. The signed-price layer is one half of the trust boundary; the protocol-side authorisation layer is the other half, and a flaw in either half is sufficient.
The flash-loan precondition was load-bearing. The attacker's economic ability to manipulate the resulting mark-price state and execute against it depended on supplying outsized inventory within a single atomic transaction. A flash loan was the natural funding source. Defenders running per-protocol threat models for oracle-consuming contracts should expect the T9.001 + T9.002 pairing — oracle-manipulation exploits in 2025 are flash-loan-funded by default; the OAK-T9.002 page is correctly mapped as a precondition rather than as the primary class.
Multi-chain deployment was the amplifier. The attacker's expected-value calculation for working out the integration flaw was repaid four times over because the flaw was portable across all four deployments. The temporal density of the four chains' extractions — close temporal succession rather than sequential days — is the on-chain signal that the same operator and the same code-path understanding ran each chain's leg. Defenders monitoring shared-code multi-chain deployments should pre-build alerting that fires across all deployments when an anomaly is detected on any one — the operational response time to detect-pause-isolate must contend with N parallel deployments, not one.
The bounty-acceptance outcome was conditional on speed and credibility. KiloEx's public bounty offer was issued within hours of detection. The 10% offer was credible — it was high enough to make acceptance economically attractive against the attacker's laundering-cost expectation, low enough to not signal panic. The on-chain return address was published in a verifiable form. The attacker accepted; the funds returned. Defenders running incident-response playbooks should treat the bounty-offer surface as a real first-tier option but should also recognise that the offer's effectiveness is highly sensitive to speed and to the credibility of the published return mechanism.
Pyth's network reputation was protected by the public forensic clarity. SlowMist, PeckShield, and KiloEx's own disclosure all attributed the flaw to KiloEx's integration, not to Pyth. This is operationally important because confused or vendor-blaming forensic reporting in oracle-related incidents has, in earlier cases, produced reputational damage to oracle vendors that did not bear the technical responsibility. The KiloEx case is a useful 2025 reference for the integration-attribution discipline: when the failure is on the consuming-protocol side, the public write-ups should say so explicitly.

What this example tells contributors writing future Technique pages

T9.001 should explicitly distinguish vendor-side failure from integration-side failure. The OAK-T9.001 page covers oracle price-feed manipulation broadly; the KiloEx case is the canonical 2025 worked example for the integration-side sub-pattern, where the oracle network's signed-price layer is operating correctly but the consuming protocol's authorisation layer is the failure surface. Contributors writing T9.001 worked examples should preserve the distinction explicitly — the defender controls are different (integration-side is fixed by the protocol team; vendor-side is fixed by the oracle network), and confusing the two categories in the corpus would degrade the page's defender-utility.
T9.002 is the modal precondition for T9.001 in 2025; the pairing should be assumed. The 2024–2025 corpus of oracle-manipulation exploits is overwhelmingly flash-loan-funded. Contributors writing T9.001 examples should expect the T9.002 mapping to apply unless explicitly excluded; the unfunded oracle-manipulation case is now the exception, not the rule.
Multi-chain fan-out deserves its own defender-handbook section. The KiloEx case is the strongest 2025 evidence that shared-code multi-chain deployments amplify single-flaw exploits linearly with deployment count. Contributors writing OAK Mitigation pages should call this out: detection / pause / isolation infrastructure for multi-chain protocols must scale with deployment count, not just with TVL. A protocol with 4 chains and 1× TVL faces a different response-time problem from a protocol with 1 chain and 4× TVL, even though the headline numbers look similar.
~100% recovery via bounty negotiation is achievable and is becoming a recognisable 2025 pattern. The KiloEx case pairs with the ZKsync case at examples/2025-04-zksync-airdrop.md as the two 2025 examples of full or near-full recovery via bounty offer. The Loopscale case at examples/2025-04-loopscale.md is the partial-recovery sibling. Together they establish the conditional-recovery surface for 2025; contributors writing recovery-rate documentation should treat bounty-mediated recovery as a real but case-conditional outcome.
pseudonymous is the correct attribution status, even with bounty acceptance. As with ZKsync, the attacker's engagement with the public return address produced no off-chain identification. Contributors should not over-claim attribution simply because the actor was responsive to negotiation.

Public references

[kiloexpostmortem2025] — KiloEx Protocol's official post-incident disclosure describing the integration-side authorisation gap, the affected deployments, and the bounty-mediated recovery.
[peckshieldkiloex2025] — PeckShield on-chain analytics and forensic walkthrough for the extraction transactions across BNB / Base / Manta / Taiko, used as the cumulative-loss reference.
[slowmistkiloex2025] — SlowMist incident analysis covering the integration-side attribution and the multi-chain fan-out pattern.
[blocksecsuikiloex2025] — BlockSec forensic write-up emphasising the flash-loan-funded execution pattern and the cross-chain temporal-succession signal.
[chainalysis2025rug] for category-level context on 2025 DeFi-incident loss totals (used as the broad-context citation).

Discussion

KiloEx is OAK's canonical 2025 case for the integration-side oracle manipulation with multi-chain fan-out pattern. The 2024–2025 corpus contains a number of T9.001 worked examples — the long tail of perp-DEX and lending-protocol oracle-manipulation cases — but the multi-chain dimension is structurally novel within the corpus. Earlier T9.001 cases were single-deployment events; KiloEx is the 2025 case that establishes the four-chain simultaneous-extraction pattern as a first-class threat shape.

The integration-side framing is the technical teaching point that pairs with the multi-chain framing. The Pyth oracle network's signed-price infrastructure was not compromised — the network continued to publish accurate, authentically-signed price updates throughout the incident. The failure was on KiloEx's side, in the protocol's authorisation logic for triggering a price consumption against its own contracts. This is a recurring pattern in the 2024–2025 oracle-exploit corpus: vendor-side oracle infrastructure has matured substantially (Pyth, Chainlink, RedStone, and others all run hardened signed-price layers), and the residual surface is on the consuming-protocol side — in the integration code, the authorisation logic, and the assumptions the consuming protocol makes about who can update what state and when. Contributors writing future T9.001 examples should expect this distribution: a substantial majority of 2024–2025 cases are integration-side, not vendor-side.

The bounty-mediated recovery is the second-order observation worth preserving. The KiloEx 10%-for-90% structure was operationally clean: a credible offer published within hours, against a verifiable on-chain return address, with explicit public framing as a bounty rather than as a hostile recovery action. The attacker's expected-value calculation converged toward acceptance — the laundering surface for $7.5M of mixed assets across four chains is wide enough to be feasible but narrow enough to leave non-trivial residual risk, and a 10% bounty against that risk is a defensible offer. The KiloEx outcome pairs with ZKsync (~100% recovery, ~24-hour negotiation) and contrasts with Loopscale (partial recovery, more contested negotiation) as the three 2025 worked examples that bracket the bounty-mediated-recovery surface for the year.

For OAK's broader credibility, including KiloEx in v0.1 closes two gaps: it adds a multi-chain-fan-out worked example to a corpus that has under-documented this pattern at the perp-DEX layer, and it provides a clean case for the integration-side-versus-vendor-side distinction within T9.001 that the page's general framing could otherwise leave ambiguous.