Cowrie Research

oracle-independence-inventory-and-degraded-mode-discipline

15 min read

Oracle Independence Inventory and Degraded-Mode Discipline

  • Name: oracle independence inventory and degraded-mode discipline
  • Category: oracle reference / dependency-graph checklist / degraded-mode safety note / fake-diversification companion
  • Summary: Oracle hardening does not start with adding more feeds. It starts with proving what is actually independent, what only looks separate on a dashboard, and what the protocol will do when that supposed diversity collapses. Healthy systems inventory oracle dependencies as a graph of economic roots, operator sets, caches, adapter families, and update paths, then bind borrowing, liquidation, and settlement authority to the amount of real independence still live. The healthy target is not merely feed continuity; it is continuity under narrower credit powers: repay-only windows, collateral-factor zeroing, capped or disabled liquidations, staged feed restoration, and explicit offboarding when independence falls below the threshold that justified full-size trust. This note exists to preserve the positive design target behind Synthetix sKRW, UwU, Polter, Cheese Bank, and the later Venus-LUNA response: redundancy should degrade into narrower authority, not into full-size trust with fewer hidden roots.
  • Why this note exists:
    • oracle-source-independence-failure already preserves the negative family: protocols mistake correlated evidence for independent truth.
    • What deserves its own positive-design note is the operating model on the other side of that failure: how teams should inventory shared roots, declare degraded modes, and connect those modes to solvency permissions.
    • Many sources is not a defense until the protocol can answer many sources of what, with which common dependencies, and what happens when one root disappears?

What this note means by independence inventory and degraded-mode discipline

  • Independence inventory means documenting each oracle branch by its real dependency roots: venue family, provider cohort, operator stack, cache layer, adapter code path, quote asset, and time basis.
  • Degraded mode means the oracle is still producing a number, but no longer under the diversity, chronology, or operator assumptions that justified full trust.
  • Discipline means those degraded states are not only observable; they change what the protocol is allowed to do.
  • The core rule is simple: the protocol should trust the number in proportion to the independence still demonstrated, not in proportion to how many labels remain on the status page.

The five questions healthy oracle operations should always be able to answer

1. What are the real roots behind each branch?

  • A protocol should be able to trace every spot, TWAP, previous, fallback, and median leg down to its economic and operational roots.
  • The meaningful objects are not contract addresses alone. They are:
    • venue families and liquidity complexes
    • operator or reporter cohorts
    • caches and publication layers
    • provider credentials, request cohorts, and API or CDN paths that may be allowed to see different answers
    • adapter and normalization code paths
    • timestamp and chronology assumptions
  • If the team cannot sketch that graph quickly, it probably does not actually know how much independence exists.

2. What exact minimum diversity is required for safety?

  • A median, outlier filter, or fallback tree is only safe above some real threshold of independent roots.
  • That threshold should be written down concretely, such as:
    • at least 3 independent providers
    • at least 2 venue families plus one time-separated anchor
    • primary plus one truly independent stale-safe fallback
  • If the rule is not explicit, the protocol is usually relying on intuition right up until an outage or manipulation turns intuition into credit risk.

3. What counts as degraded mode?

  • Degraded mode should be a first-class state, not an after-the-fact incident description.
  • Typical triggers include:
    • two supposedly separate branches resolving to one venue family
    • provider count dropping below the filter’s real design threshold
    • previous and current values collapsing onto the same live state read
    • primary and fallback branches sharing the same cache or operator path
    • a bridge, sequencer, or adapter outage reducing the feed to one remaining live root
  • The important design habit is that still producing a number does not mean still entitled to full solvency authority.

4. Which powers shrink when the oracle is degraded?

  • Good systems connect oracle-health states to balance-sheet permissions.
  • Typical degraded-mode responses include:
    • repay-only or repay-and-supply-only emergency lanes when users still need an unwind path but the protocol should stop extending fresh credit
    • collateral factor reduction or collateral factor zeroing for the affected market
    • fresh borrowing pause
    • narrower or delayed liquidation powers until marks are trustworthy again
    • capped minting or settlement size
    • withdrawal throttles for oracle-shaped equity
    • isolation of affected markets from deeper-liquidity sibling markets
    • explicit feed-zeroing or market offboarding when there is no longer enough independence to justify any borrow-side solvency authority
  • If no permission changes when diversity assumptions fail, the protocol has observability but not control.

5. How does the oracle recover trust?

  • Recovery should require more than the dashboard is green again.
  • Healthy recovery often includes:
    • verifying the missing independent roots really returned
    • reconciling current answers against independent references
    • checking stale caches and quote-asset bindings
    • keeping repayment and exit lanes separate from credit restoration
    • restoring permissions gradually rather than instantly, with feed restoration and liquidation re-enablement staged rather than merged into one unpause everything gesture
  • The protocol should regain trust deliberately, not accidentally.

What sound design looks like

1. Dependency graphs instead of source lists

  • A healthy oracle runbook records both the branch labels and the common roots underneath them.
  • 11 inputs should be accompanied by how many independent venue families, provider stacks, and cache layers those 11 inputs really represent.
  • This is the difference between architecture theater and actionable risk information.

2. Dependency-aware fallback trees

  • Primary and fallback should be labeled by how independent they actually are.
  • A fallback that shares the same venue family, reporter set, or cache layer as the primary path is still useful operationally, but it should be treated as a degraded continuity path rather than full-strength redundancy.
  • That distinction matters because the protocol should not grant the same balance-sheet rights to both cases.

3. Chronology should be treated as a dependency too

  • A previous answer is only independent along the time axis if it was truly stored at a different moment.
  • Recomputing current state through a different function signature is not a historical check.
  • Time-separated storage and publication are part of source independence, not an optional nice-to-have.

4. Degraded-mode permissions should be pre-committed

  • A healthy design does not wait to invent policy during the incident.
  • It already knows what happens when diversity drops below threshold: which markets freeze, which feeds are zeroed, which collateral factors go to zero, which caps narrow, which liquidations stop, which actions fall back to repay-only, and which markets move into explicit offboarding.
  • The important distinction is keep the unwind path alive versus keep credit expansion alive. Venus’s post-LUNA recovery sequence is the right preserved shape here: zero feeds first, unpause into a repayment window, restore live feeds in stages, and only then reopen narrower pieces of normal operation.
  • This is the oracle-side companion to collateral-admission-lag-and-borrow-side-quarantine.

5. Operator visibility should match risk visibility

  • The people changing feeds, swapping adapters, or responding to outages should see shared dependencies directly.
  • If only deep code archaeology reveals that three branches all depend on one Curve pool family or one API cohort, the system is over-trusting hidden structure.
  • The operating target is not just machine-readable health; it is human-readable independence truth.

6. Monitoring should not share the oracle’s blind spot

  • At least one reconciliation and route-health path should sit outside the main provider, cache, or API-key cohort that feeds live solvency decisions. Otherwise the protocol is asking compromised infrastructure whether compromised infrastructure still looks healthy.
  • Selective-lie scenarios deserve first-class review. A provider or cache that serves attacker-shaped data only to one credential set, one region, or one request path can keep ordinary dashboards green while the live oracle consumer is already wrong.
  • The goal is not only oracle is up; it is risk monitors can still disagree when the live path is being shown a lie.

Useful positive design shapes

1. Independence budgets instead of raw source counts

  • A protocol can think in terms of independence budget: how many distinct trust roots remain for a given asset or market.
  • The budget should be consumed by known correlations, not ignored because the headline source count still looks large.
  • This helps risk teams reason about why 11 sources can still degrade into effectively 2 roots.

2. Healthy degraded modes should fail narrower, not fail open

  • The purpose of degraded mode is not to keep every feature alive.
  • It is to keep only the features whose safety assumptions still hold under the smaller independence set.
  • If the protocol cannot identify those smaller-safe permissions, it probably has not really threat-modeled the oracle.

3. Shared roots should be explicit at listing and migration time

  • Oracle independence is not only an outage problem.
  • Listing new collateral, changing fallback precedence, migrating adapters, and introducing new wrappers can silently change the dependency graph even when no feed is obviously broken.
  • This is where oracle-migration-quarantine-and-canary-design becomes the rollout companion.

4. Time-separated anchors are different from same-state double reads

  • A robust design values chronology as a distinct defense surface.
  • The goal is not merely to have two ways to ask the contract. It is to preserve one answer that the attacker cannot rewrite by manipulating the current block’s live state.
  • This is why stored anchors, snapshots, or delayed publication can matter more than one more correlated live feed.

Negative exemplar cluster: what no dependency discipline looks like

  • Synthetix sKRW — the protocol counted on an outlier filter that only made sense with more live independent providers than remained in practice.
  • UwU Lend sUSDe — the protocol described an 11-source fallback tree whose real economic roots were much less diverse than the headline count implied.
  • Polter Finance BOO — a previous guard looked independent in code shape but not in actual state chronology.
  • Cheese Bank — the protocol treated a two-leg construction as diversified even though both legs still lived inside one manipulable Uniswap V2 family.
  • The common lesson is not only the price was wrong. It is the protocol never wrote down what kind of independence it thought it had, so it kept full trust after that independence was already gone.

Red flags that usually mean the oracle is relying on fake diversity

  • We have many sources without a dependency graph showing common venue families, caches, or operator cohorts
  • Fallback will protect us when primary and fallback share the same root dependency
  • Previous value is a safety check when it is recomputed from the same mutable present
  • At least one feed is still live when the aggregation rule was only safe with several independent roots
  • The adapter addresses are all different when the economic source and publication path are the same
  • This is only an observability issue even though the degraded oracle still controls borrowing or liquidation at full size
  • We can restore normal parameters when the status page recovers without verifying that shared dependencies and chronology assumptions actually recovered too

Design questions worth asking first

  • What are the true economic and operational roots behind each oracle branch for this asset?
  • How many independent roots does the current aggregation rule require to justify full borrowing, liquidation, or settlement authority?
  • What exact events classify the oracle as degraded, and are those events machine-detectable, operator-visible, or both?
  • Which protocol actions automatically narrow when independence drops below threshold?
  • Does the system distinguish service continuity from full solvency trust, or does any surviving number keep all old permissions alive?
  • How does the protocol verify chronology independence for previous, historical, anchor, or cached answers?
  • During migrations or feed-composition changes, who reviews whether the dependency graph changed even if the source count did not?
  • What proves the oracle has earned full trust back after degraded mode ends?

Failure-prevention checklist

  • Maintain an oracle dependency inventory per asset and per market that records real roots: venue families, provider cohorts, caches, adapter families, quote assets, timestamps, and fallback relationships.
  • Define independent root in policy before using source count in risk logic. Different labels, contracts, or pairs do not count if they still collapse onto one manipulable market family or one reporter stack.
  • Make degraded mode explicit and binding: source-count collapse, chronology collapse, shared-cache fallback, or venue-family concentration should each map to a named operating state.
  • Tie degraded-mode states to concrete permission changes such as lower collateral factors, paused fresh borrowing, capped settlements, isolated markets, or halted liquidations.
  • Store historical guards as genuinely time-separated values and test that they cannot be rewritten by the same current-state manipulation the protocol is trying to defend against.
  • Review fallback trees for hidden common roots whenever feeds, adapters, wrappers, or quote assets change. Configuration changes can destroy independence without changing source count.
  • Predefine degraded-mode constitutions in executable terms: zero-feed switches, repay-only windows, collateral-factor-zero paths, liquidation pauses, and staged feed restoration should be named controls rather than improvisation.
  • Monitor the oracle dependency graph, not only feed uptime: shared-root concentration, stale branches, missing providers, and same-state history paths should all raise risk alerts.
  • Keep at least one monitoring and reconciliation path outside the primary provider, cache, and credential cohort so provider-specific lies or selective cache poisoning cannot keep both the live oracle and the dashboards wrong in the same way.
  • Rehearse degraded-mode response and recovery so operators know which rights narrow, what evidence restores trust, and how to stage that restoration gradually.
  • Keep market-level blast-radius controls available even when the oracle stack is not formally down. Fake diversity is dangerous precisely because the system may look nominally healthy.
  • Document independence assumptions where governance, operators, and auditors will actually see them. If the protocol cannot explain why a branch is independent, it should not monetize that assumption.

Audit prompts

  • For each branch in the oracle, what are the real underlying venue families, provider sets, caches, adapters, quote assets, and time bases?
  • If one venue family, one provider cohort, or one cache layer fails or is manipulated, how many supposedly separate branches disappear with it?
  • What exact number of independent roots does the protocol need before it is safe to allow full borrowing, liquidation, or settlement size?
  • Do previous, historical, or anchor values come from genuinely stored earlier state, or are they just recomputed views of the same current object?
  • Can governance or operator actions change real source independence without changing the dashboard source count?
  • When the oracle degrades, which downstream permissions narrow automatically and which still require human reaction time? Can the protocol actually enter a repay-only or repay-and-supply-only state, zero collateral factors, or stage feed restoration without reopening full borrow and liquidation authority too early?
  • Are fallback branches labeled by continuity value only, or by real economic independence as well?
  • Can providers, caches, or API-key-scoped paths serve different answers to live oracle consumers and monitoring tools, and if so who would notice before the protocol keeps lending against a selectively poisoned view?
  • What evidence does the protocol require before restoring full trust after an outage, migration, or provider-count collapse, and does restoration happen in stages rather than as one feeds back on, protocol normal action?
  • Can responders tell, during an incident, whether they are looking at one bad branch or many labels wrapped around one bad root?
  • If the protocol says 11 sources, can it also say how many independent roots remain if one venue family or one provider stack goes away right now?

Lessons that should already be standard

  • Counting feeds is not the same thing as counting trust roots.
  • A number that survives degraded mode is not automatically a number that deserves unchanged balance-sheet authority.
  • The oracle safely froze is not the same thing as the protocol safely stopped extending credit; a degraded oracle state still needs an explicit credit constitution.
  • Historical checks only add independence if they preserve real chronology.
  • Fallback continuity and fallback independence are different properties, and good risk policy distinguishes them.
  • Oracle health is not binary. Systems often fail in the middle ground where the feed is up but the assumptions that justified full trust are already broken.
  • Hidden shared dependencies are balance-sheet risk, not documentation trivia.
  • Monitoring should disagree on purpose. If dashboards, reconciliations, and live solvency reads all share the same provider, cache, or credential path, the protocol may discover selective poisoning only after balance-sheet damage is already done.
  • If a protocol cannot explain why its sources are independent, it should assume they are less independent than the architecture diagram suggests.

How this note complements the exploit corpus

  • Start with oracle-source-independence-failure when the sharper question is how did fake diversification or shared dependencies make the oracle unsafe?
  • Use this note when the sharper design question becomes how should a protocol inventory those dependencies and narrow authority when real independence collapses?
  • Pair with oracle-migration-quarantine-and-canary-design when the sharper operational question is how migrations, feed changes, or new wrappers can silently change the dependency graph before an incident begins.
  • Pair with stale-price-exploitation when the sharper exploit-side lesson is that once independence or freshness collapses, the dangerous failure is usually not bad feed exists but the protocol kept extending credit anyway.
  • Pair with collateral-admission-lag-and-borrow-side-quarantine when the next design question is how reduced oracle confidence should translate into reduced downstream lending or liquidation authority.
  • Pair with delayed-snapshots-and-same-block-quarantine when the chronology boundary itself needs strengthening so a previous or anchor check becomes meaningfully independent in time.

Internal linkages

Control surface

Graph View

Backlinks