Switchboard Integration: Hidden Risks of Statistics

In DeFi, where smart contracts manage real assets, accurate and timely price data is critical. Consider a lending protocol where users deposit ETH to borrow USDC - the system must continuously monitor ETH's price and trigger liquidations if it drops too far. This logic depends entirely on reliable oracle data. In a recent audit, while evaluating switchboard integrations, we observed several cases where statistical parameters were misapplied, reducing feed reliability and introducing subtle but significant vulnerabilities.

Oracles

To set the context, it is crucial to understand the difference between two categories of price sources: external data oracles and on-chain protocols.

External data oracles such as Chainlink, Pyth, and Switchboard typically consist of a network of providers delivering external data in the form of a feed, while complying with strict rules for the data to be considered valid.

In contrast, on-chain sources like AMM pool data and TWAP directly originate from smart contracts exposing data for other protocols to use.

Oracle networks are often considered more secure than their on-chain counterparts as they are usually harder to manipulate, but this comes at a price: Trust.

The Architecture of Trust

Modern oracle systems employ various mechanisms to ensure data reliability. Rather than relying on a single source, decentralized oracle networks aggregate information from multiple independent data providers. By combining multiple sources, financial incentives, and statistical methods to filter out anomalies, oracles aim to provide robust, manipulation-resistant data feeds.

Switchboard Price Feeds

The Switchboard price feeds can be permissionlessly deployed and expose detailed live information and configuration options. A price feed admin can define configuration parameters such as:

• max_variance - ensures only submissions with acceptable statistical consistency are accepted
• min_responses and min_sample_size - enforce that a sufficient number of independent oracle submissions contribute to each price update
• max_staleness - ensures price freshness

Mean, Median and Standard Deviation

Before diving deeper into the vulnerability, let's clarify the fundamental statistical concepts at the center of this issue:

Mean (Average)

The mean is the sum of all values divided by the number of values.

Example: Prices [100, 102, 104, 106, 108] → Mean = 104

The mean considers every value equally, making it sensitive to extreme values. A single outlier can significantly shift the mean.

Median (Middle Value)

The median is the middle value when all numbers are arranged in order.

• Normal: [100, 102, 104, 106, 108] → Median = 104
• With outlier: [100, 102, 104, 106, 500] → Median = 104 (still the middle value, unaffected)

The median ignores extreme values, focusing only on the center of the distribution. This makes it more "robust" against manipulation.

Standard Deviation (Spread)

Standard deviation measures how spread out values are from the mean. Crucially, it is calculated relative to the mean, not the median. It is highly sensitive to outliers.

Mistake #1: Mixing up Median and Standard Deviation

We observed an incorrect application of standard deviation to the median. This approach is mathematically inconsistent because:

• Standard deviation measures the spread around the mean, not the median - the resulting confidence intervals lack a sound mathematical basis
• These statistics belong to different mathematical frameworks - the median is a robust statistic resistant to outliers, whereas standard deviation is not

Scenario 2: One Outlier

Submissions: [2000, 2005, 2015, 2020, 2200]
Mean = 2048 (Shifted by approximately 2%)
Median = 2015 (Still the middle value, demonstrating robustness)
Standard Deviation = 84.3 (Massively inflated)

While the median successfully identifies the true market price despite the manipulation attempt, the standard deviation calculation is corrupted by the same outlier that shifted the mean. When you apply an SD-based bound to the median, you get a bound that's far too wide due to the inflated SD, allowing the outlier to pass validation checks that should reject it.

Mistake #2: Incorrect Variance Scaling

The second issue we observed was applying the wrong scale to the max_variance parameter. Switchboard's variance is expressed in basis points (bps), where 1 bps = 0.01%.

Some integrations we reviewed set the variance threshold as a raw decimal like 0.05 (5%), but the parameter expected a value in basis points like 500. The result: a threshold that appears to be "5% tolerance" is actually operating at 0.0005% - so restrictive that almost every valid price update would fail validation, causing the feed to appear stale.

Recommendations

1. Use median and MAD together - Median Absolute Deviation (MAD) is the robust counterpart to standard deviation. It measures spread around the median, not the mean.

2. Verify your variance units - Always check whether the parameter expects basis points, percentage, or a decimal fraction. Read the contract source or documentation carefully.

3. Test with adversarial inputs - Simulate scenarios where one oracle submits an extreme value and verify that your validation logic correctly rejects or accepts it.

4. Monitor feed health on-chain - Build monitoring that alerts you when the number of oracle responses drops below your min_responses threshold, or when the staleness check fails.

Oracles are one of the most critical external dependencies in DeFi. Getting the statistical configuration wrong can silently degrade your security guarantees in ways that only become apparent during a market stress event - exactly when you need them most.