Cowrie Research

minimum-live-source-threshold-failure

12 min read

Minimum Live-Source Threshold Failure / Silent Source-Count Collapse

  • Name: minimum live-source threshold failure / silent source-count collapse
  • Category: exploit pattern / oracle-composition failure / degraded-mode aggregation bug / provider-quorum collapse
  • Summary: Minimum live-source threshold failure happens when an oracle path was only safe under a higher number of genuinely live inputs, but the protocol keeps publishing and honoring prices after that source set silently collapses below its real safety floor. The dangerous move is not merely one source was wrong; it is that the filter, median, trimmed mean, or outlier logic kept acting as if it still had enough independent evidence to justify trust. Once one bad print becomes half the sample, or one stale branch becomes the deciding tie-breaker, the protocol turns degraded observability into full settlement, collateral, or liquidation authority. The review mistake is to flatten three different claims into the oracle still works: some live sources still answer at all, those surviving answers still deserve to count as enough evidence for the aggregation rule, and the result still deserves healthy-mode balance-sheet authority.
  • What it is:
    • A protocol or offchain oracle service aggregates several sources and relies on that plurality for safety.
    • The aggregation rule only makes sense above some minimum live-source threshold: enough branches to reject outliers, enough independent roots to survive one bad answer, or enough temporal separation to stop one wrong print from dominating.
    • One or more sources drop out, stall, or become operationally unavailable.
    • The system keeps operating without clearly reclassifying itself into degraded mode.
    • A remaining bad source, stale source, or correlated source now has much more influence than the protocol’s design story assumes.
    • The downstream consumer still treats the published number as money-good truth.
  • Typical preconditions:
    • The feed uses an average, median, trimmed mean, or outlier filter whose safety depends on three or more live sources.
    • Source loss is silent, under-instrumented, or only visible to operators off the happy path.
    • Downstream markets do not narrow permissions when live-source count falls below the aggregation rule’s real safety floor.
    • The remaining sources are either too few to reject a bad print or too correlated to count as independent evidence.
    • Settlement, collateralization, or liquidation continues automatically while the feed is already in a degraded operational state.
  • Common vulnerable surfaces:
    • offchain FX and commodity oracle pipelines with manual or API-based source aggregation
    • multi-provider price feeds whose outlier rejection only works when at least three independent providers remain live
    • fallback trees that silently reduce to one live source plus one stale or correlated source
    • median-of-N or average-of-N systems where N can drop without changing downstream trust semantics
    • operational dashboards that show feed healthy because a price is still publishing even though the diversity assumptions behind that price have already failed
  • Failure sequence:
    1. The protocol or oracle operator designs a feed around multiple live sources and an aggregation rule that assumes a minimum healthy sample size.
    2. One or more sources fail, disconnect, freeze, or are removed from service.
    3. Monitoring and policy do not force the feed into degraded mode, so the same aggregation rule keeps running anyway.
    4. A remaining bad source, stale source, or correlated source disproportionately shapes the published answer.
    5. The downstream protocol keeps borrowing, liquidating, or settling against that degraded answer as if the original safety assumptions still held.
    6. Attackers or opportunistic arbitrageurs monetize the false price before operators recognize that the real failure was source-count collapse rather than just one isolated bad input.
  • Variants:
    • Outlier-filter collapse — a filter that safely rejects one bad print at N >= 3 becomes unsafe at N = 2 because the outlier is now half the sample.
    • Median quorum collapse — a median that once tolerated one bad source loses Byzantine tolerance when one honest source drops out.
    • Average-with-hidden-degradation — operations assume many sources, but the live result is effectively just one source averaged with one stale or weakly checked fallback.
    • Fail-open degraded mode — the feed knows it lost diversity but keeps publishing the same trust semantics anyway.
    • Operationally silent collapse — telemetry and alerting emphasize price still updates rather than safe provider threshold no longer met.

Three degraded-quorum promotions reviewers should not collapse

  1. Some source branches are still live enough to return a number at all

    • One or more APIs, reporters, or cached branches still answer, so the oracle can keep publishing a scalar price.
    • This is only a liveness fact: some inputs survived.

  2. Those surviving inputs still deserve to count as enough evidence for this aggregation rule

    • The harder question is whether the remaining live set is still above the real safety floor for the median, average, trimmed mean, or outlier filter being used.
    • Two surviving providers may keep the pipeline warm while already destroying the exact safety story the aggregation rule depended on.

  3. That degraded answer still deserves full collateral, liquidation, or settlement authority right now

    • Even if the feed can still publish one plausible number, a below-threshold sample should not automatically keep healthy-mode borrow limits, liquidation permissions, or settlement size.
    • This is the authority-budget question: what should the protocol still be willing to spend against once the live-source floor has already failed?

Healthy oracle review gets materially better once teams stop collapsing some sources still answer, the surviving sample is still sufficient evidence, and the resulting price still deserves full production authority into one comfort statement called the feed is still up.

  • Detection heuristics:
    • Ask what minimum number of live, independent sources the aggregation rule needs to remain safe. If nobody can answer, the design is probably already hand-wavy.
    • Inspect whether source-health monitoring tracks only liveness or also tracks safety-class transitions such as healthy, degraded, and unsafe to settle.
    • Re-run the feed logic with one, two, or several sources removed and ask what price semantics the downstream protocol would still honor.
    • Trace whether operators, guardians, or automated controls actually see source-count collapse quickly enough to matter.
    • Distinguish number of responses returned from number of independent roots still live.
    • Test whether the feed can keep publishing apparently plausible prices long after the diversity assumptions behind those prices have already died.
  • Defenses:
    • Define explicit minimum live-source thresholds for each aggregation rule and fail narrower when the threshold is not met.
    • Publish degraded-mode status as a first-class oracle output or tightly coupled risk signal, not as an operator-side dashboard footnote.
    • Separate can still display a number from can still underwrite borrowing, liquidation, or settlement at full size.
    • Alert on diversity loss, not just on full feed outage.
    • Prefer aggregation rules whose safety properties are documented against concrete source-count assumptions.
    • Couple degraded-source detection to automatic collateral quarantines, tighter caps, or settlement pauses.

What sound design looks like

  • A healthy oracle stack can state, per feed, the minimum number of live and genuinely independent roots required for each safety claim it makes. Some sources still answer, the remaining sample is still enough evidence, and the resulting price still deserves settlement-grade authority are treated as separate states rather than one fuzzy feed alive judgment.
  • Source-count changes are policy changes. When live inputs fall from four to two, the system should change permissions, not just arithmetic. Borrow power, liquidation authority, and minting rights should narrow automatically unless the remaining roots still satisfy the intended safety model; see oracle-independence-inventory-and-degraded-mode-discipline.
  • Degraded mode is machine-readable and economically meaningful. Operators, guardians, and downstream consumers should see healthy, degraded, or unsafe for settlement as part of the feed’s usable state rather than inferring it from scattered dashboards.
  • Publication should carry quorum semantics with the price itself. Downstream consumers should know not only the number but also how many live sources and independent roots still support that number, plus whether the feed remains above the threshold for settlement-grade use.
  • Monitoring inventories real independence, not provider labels. Two APIs that ultimately depend on one upstream source or one data vendor family do not rescue the live-source threshold story just because both endpoints still answer.
  • Rollout, migration, and maintenance procedures preserve sample-size safety explicitly. A feed should not temporarily or accidentally lose half its trusted inputs without the same ceremony a collateral-policy downgrade would deserve; see oracle-migration-quarantine-and-canary-design.
  • The healthy target is simple: one documented safety floor, one explicit degraded-mode state machine, one clear split between surviving liveness and surviving evidence, one automatic narrowing of credit semantics when the floor is breached, and no period where collapsed redundancy still enjoys full production trust.

Failure-prevention checklist

  • Write down the minimum live-source threshold each feed needs for its aggregation rule to remain safe, and make that threshold visible to both operators and downstream protocol logic.
  • Treat healthy source count, independent source count, and publishing a value as separate metrics. All three matter.
  • Publish quorum metadata alongside the price: live-source count, independent-root count, last-known healthy threshold, and a safety class such as healthy, degraded-monitor-only, or unsafe. If consumers only receive a scalar price, they cannot enforce threshold-aware policy.
  • Fail narrower when live-source count drops below the documented safety floor: disable fresh borrowing, raise haircuts, pause liquidations that rely on the feed, or gate settlement to unwind-only mode.
  • Alert on source-count degradation before full outage. The dangerous state is often still publishing, no longer safe, not completely offline.
  • Record which sources are merely live and which remain economically independent. Two surviving siblings from the same provider family should not satisfy a three-source safety story.
  • Test aggregation behavior at degraded sample sizes directly. If the team has never simulated N = 2 or N = 1, it probably does not really know the feed’s fail-open behavior.
  • Make the degraded-mode signal available where risk is actually consumed: liquidation engines, collateral configs, settlement routers, and market-pause automation should not need human interpretation of an ops dashboard.
  • During maintenance, migration, or incident response, treat temporary source removal as a balance-sheet event. If the feed will run with fewer sources, pre-commit the narrower permissions that apply during that window.
  • Keep runbooks for the ugly middle state: the oracle still emits a plausible number, but the diversity behind that number is no longer sufficient for full trust.
  • Audit exception reporting and stale-source handling together. A feed that silently loses providers and keeps averaging the rest is already in the exploit window.

Audit prompts

  • What exact minimum number of live and independent sources does this aggregation rule require to stay safe?
  • Where in code or operational policy is that threshold enforced, and what concrete downstream permissions change when it is breached?
  • Can the oracle keep publishing a plausible number after losing enough inputs that its outlier or median logic no longer has the intended safety properties?
  • Do operators and onchain consumers see a first-class degraded-mode signal, or would they need to infer the problem from dashboards and incident chatter?
  • Does the consumer receive quorum metadata with the price, or only a scalar answer? If the feed fell from four live roots to two, what exact machine-readable signal tells downstream markets to narrow authority?
  • Are the surviving inputs truly independent, or are several remaining sources still just aliases of one provider family, venue family, or cache?
  • What happened the last time this feed lost one source? Did any market permission narrow, or did the system merely keep going with weaker evidence?
  • If one remaining source goes wrong while the feed is already below threshold, how much real value can the protocol lose before the degraded state is detected and acted on?
  • During migrations, outages, or vendor churn, who owns the invariant that sample-size degradation must trigger economic-policy degradation too?

Lessons that should already be standard

  • Outlier filtering is not a magic property of averaging. It only exists above a real sample-size floor.

  • Some sources still answer, the remaining sample is still enough evidence, and the result still deserves full authority are different claims. Healthy systems do not collapse them into feed is still up.

  • Still publishing can be the most dangerous oracle state if the protocol mistakes degraded evidence for healthy evidence.

  • Redundancy loss is a risk-state change, not just an ops-state change.

  • A scalar price without quorum context is incomplete truth. If downstream consumers cannot tell how much evidence still stands behind the number, they will usually over-trust it.

  • Many oracle incidents begin one step earlier than teams admit: the bad value mattered because source-count collapse made it decisive.

  • A feed that depends on silent operator awareness of provider loss does not really have a degraded-mode design.

  • If the system cannot say exactly when two sources left stops being safe, it will eventually settle value in a mode it never intentionally designed.

  • High-signal incidents:

    • bot arbitrage incident (2019-06-25) — the clean preserved exemplar: Synthetix’s KRW feed had silently degraded to two live APIs, so one bad 1000x print became half the sample and the outlier-handling story that might have worked at higher N no longer protected settlement.

Where this pattern helps most

  • Use this note when the sharper failure is not merely sources were not independent but the system crossed below the minimum live-source threshold where its aggregation rule still made sense, and nobody narrowed trust semantics when that happened.
  • Use oracle-source-independence-failure when the broader question is whether the feed ever had real diversity in the first place, including cases where several branches were always economically correlated.
  • Pair with oracle-independence-inventory-and-degraded-mode-discipline when the healthy-side question becomes how the protocol should inventory independence, publish degraded mode, and tie source-count collapse to automatic risk narrowing.
  • Pair with oracle-migration-quarantine-and-canary-design when the dangerous source-count collapse can happen during maintenance, rollout, or vendor replacement rather than in the middle of a market event.

Internal linkages

Control surface

  • The leverage sits in live-source thresholds, degraded-mode publication, exception reporting, operator visibility into provider loss, and downstream policy that decides whether a degraded feed still gets full solvency authority.
  • The decisive review split is some sources still answer, those survivors still satisfy the aggregation rule's safety floor, and their output still deserves healthy-mode balance-sheet authority.
  • The recurring mistake is to let arithmetic continue after the safety proof for that arithmetic has already expired.
  • The most useful review question is simple: when this feed loses enough sources that one bad input becomes decisive, what exact market permissions shrink immediately?

Sources

Last reviewed

  • 2026-07-31 UTC

Graph View

Backlinks