Oracle Manipulation

The oracle is the protocol’s contact point with the outside world. A manipulated oracle → manipulated mark price → manipulated PnL → manipulated liquidations. This is the single highest-impact attack surface in perpetual futures protocols, and SportsPerp has specific mitigations.

The attack

An attacker succeeds at oracle manipulation if they can cause oracle_price to deviate materially from the true OBV Index for long enough to extract value before defenses engage.

Three attack models:

Key compromise. The hot oracle_authority key signing update_oracle (separate from the admin/upgrade authority since the B5 cutover) is stolen or coerced.
Data-source manipulation. The upstream data partner’s data is corrupted or the feed is spoofed.
Timing attack. An attacker is not the oracle but can observe a push and front-run it with transactions that benefit from the imminent price change.

Each is handled differently.

Mitigation: layered by design

No single mitigation is sufficient. Six layers stack:

1. Composite mark ≠ raw oracle

The oracle is one of two inputs to the mark price. The vAMM contributes 50% (during live matches) to 70% (between matches). See Mark Price.

Even if an attacker controls the oracle, they must simultaneously manipulate the vAMM — which requires real open-interest imbalance backed by real USDC — to move the mark materially. The vAMM impact factor is 0.1% per full OI imbalance, so moving the mark 1% requires either:

1% oracle manipulation + no vAMM manipulation (50–70% attenuated), or
10× vAMM imbalance at max (economically expensive) on top of oracle manipulation.

2. Per-update deviation cap + EMA smoothing

The hard bound on any single oracle push is the SP-007 deviation / rate-limit gate: an update_oracle is rejected on-chain if it moves oracle_price more than 20% from the previous value, or arrives less than 60s after the last accepted update. So one push — even from a compromised key — can move the oracle at most ±20% per 60s.

On top of that, the composite mark is smoothed with a 150-second EMA. At the deployed 300-second push cadence the EMA weight on each new composite is ~75% (α ≈ 0.75), so a single capped push propagates mostly within one cycle rather than over many minutes — the EMA dampens jitter, but it is not the primary single-snapshot defense. The deviation cap above, the composite/vAMM attenuation (layer 1), and the anti-manipulation liquidation floor (layer 6) are what actually bound a single manipulated push.

3. Confidence-based leverage throttling

If the oracle publishes with wide confidence (> 800 bps), max leverage automatically drops to 0.4×. At > 1000 bps, trading halts entirely. An attacker who pushes a wide-confidence value is deliberately trading their own ability to exploit it.

4. TWAP funding over the 8-hour interval

Funding rate is computed from a TWAP of premium samples accumulated over each 8-hour interval, then clamped to the ±10 bps cap. To move the funding rate against open positions, an attacker has to sustain the dislocation across most of the interval — materially harder than a single-block attack. Additional sample-level statistical hardening is on the post-launch roadmap.

6. Anti-manipulation liquidation floor

Profitable positions cannot be liquidated unless they’ve lost ≥ 18.3% of collateral vs their last margin transfer. An attacker who manipulates the oracle to briefly flip a profitable position into a margin-ratio violation still cannot liquidate it — the profitability check protects it. See Three-Layer Cascade.

This is the dedicated defense against “oracle spike → quick liquidation → revert oracle” attacks that have happened on other protocols.

Specific attack scenarios

Scenario: a single manipulated oracle push

Even a meaningfully off oracle value is heavily attenuated before it can be monetized: a single push is hard-capped at ±20% per 60s by the deviation gate, the composite mark blends the (capped) oracle with the vAMM, and the result is EMA-smoothed. Opening into the dislocation runs into the premium check, and liquidating an otherwise-healthy profitable position runs into the anti-manipulation floor.

Net attacker extraction: essentially zero without a coordinated vAMM manipulation backed by real USDC that costs more than the manipulation could profit.

Scenario: data-partner feed is compromised upstream

A bad actor gains access to the partner’s publishing pipeline (improbable) and publishes incorrect OBV values. The crank propagates these, the oracle pushes them, the mark follows.

Defenses:

The live overlay pipeline validates per-event OBV deltas against sanity ranges; outliers are rejected.
The mainnet multi-source oracle uses an independent second pricing source — a different vendor or an internally-computed backup — so that a single vendor’s compromise doesn’t reach the chain.
Monitoring alerts fire on anomalous single-update index moves.

For mainnet, this scenario is the primary reason the multi-source oracle is a launch gate.

Scenario: front-running a price push

An attacker observes a pending update_oracle transaction and tries to trade ahead of the imminent change.

This is structurally limited. Opens and closes settle against the oracle, any single push is capped at ±20% per 60s, and the liquidation-eligibility mark is the 150-second EMA of the composite — so a trade placed just before a push cannot straddle an unbounded step. Acting on an anticipated data update is ordinary market behaviour, not a protocol exploit, and it ceases to be even theoretically interesting once the decentralized multi-source oracle removes any single party’s privileged view of push timing.

Where multi-source comes in

Everything above concerns a single trust point. The deployed pusher already runs 2-of-N weighted-median consensus on devnet, but both legs are SportsPerp-derived — server redundancy, not yet independent sources — so the single-party trust still stands today. The fully independent form replaces that trust point with consensus across genuinely independent sources, and is a mainnet gate.

Under multi-source:

At least 2 independent pushers must agree (within tolerance) for a price to land on-chain.
Each pusher has an independent key, independent host, independent data source. Compromising one doesn’t move the consensus.
Weighted median defaults to equal weights at launch; reputation weighting can be added post-launch based on accuracy history.

Multi-source is a mainnet launch gate. See Oracle Design and Roadmap → Devnet to Mainnet.

Residual risk

No mitigation stack makes oracle manipulation impossible — the honest framing is that a sufficiently resourced, patient, and well-positioned adversary willing to spend more than they could plausibly gain is deterred economically, not absolutely. The layered design (composite mark, the per-update deviation cap, EMA smoothing, confidence throttle, TWAP funding, anti-manipulation liquidation floor, and the mainnet multi-source consensus) is built to keep the cost of a successful attack above its payoff. Perfect oracle security is not achievable; economic security is.

How traders can observe oracle health

Every trader can check oracle state on-chain without needing to trust our monitoring:

const market = await client.getMarket(marketId);
const age = Date.now() / 1000 - market.oracleTimestamp;
 
if (age > 7200) console.log("Oracle stale — trading paused");
if (market.oracleConfidenceBps > 1000) console.log("Oracle uncertainty — trading blocked");
// Mark-vs-oracle divergence is informational only — useful for understanding
// liquidation-eligibility behaviour during fast moves. It is not an
// on-chain trade-rejection gate.
const divergencePct =
  Math.abs(market.markPriceEma - market.oraclePrice) / market.oraclePrice;
if (divergencePct > 0.05) {
  console.log(`Mark/oracle divergence ${(divergencePct * 100).toFixed(2)}%`);
}

These are public signals. The protocol doesn’t require trusting our dashboards.