Cowrie Research

compound-open-price-feed

7 min read

Compound Open Price Feed

  • Name: Compound Open Price Feed
  • URL: https://github.com/compound-finance/open-oracle
  • Category: signed-data oracle baseline / reporter-poster split / anchored price-feed middleware
  • Tags: ethereum-ecosystem
  • Summary: Compound Open Price Feed is better filed as a reference oracle baseline than as a live project note. The useful part is the architecture: signed reporters, permissionless posters, and a guarded view layer that can fall back to anchor pricing when the reporter path stops looking trustworthy.
  • What it does:
    • Lets reporters sign structured price messages offchain using a known public key, without requiring the reporter itself to pay gas
    • Lets any poster submit those signed messages onchain to authenticated storage, removing the need for a single permissioned posting role
    • Stores the latest signed value per source and key in OpenOraclePriceData, which downstream view contracts can read directly or aggregate
    • Ships view-layer contracts such as UniswapAnchoredView that compare a reporter price against an onchain Uniswap TWAP anchor before updating the authoritative price
    • Supports a reporter invalidation path where the reporter can signal compromise and force the system to fall back to anchor pricing until governance selects a new feed arrangement
    • Was explicitly proposed as a governance-era decentralization step for Compound, with room to add more reporters and more aggregation logic over time
  • Key claims:
    • The repository README says Open Oracle is a standard and SDK for reporters to sign key-value pairs and for clients to build shared aggregates such as a median from several sources.
    • Compound’s governance posts framed the migration as a decentralization milestone because anyone can post signed prices onchain, eliminating dependence on a single permissioned poster run by Compound Labs.
    • The migration design is analytically useful because it keeps three roles separate: reporters produce signed prices, posters transmit them onchain, and view contracts decide what counts as the protocol-facing price.
    • The OpenOraclePriceData contract exposes the underlying authenticated-data layer clearly: it stores the freshest source-signed (key, value, timestamp) record and rejects stale or implausibly future-dated writes.
    • The UniswapAnchoredView contract exposes a second, distinct policy layer: reporter prices are accepted only if they remain within configured upper and lower anchor ratios around a Uniswap TWAP, otherwise they are guarded rather than stored.
    • The reporter invalidation mechanism is an especially important control surface. The governance docs describe a signed invalidation message that flips the system into anchor-only mode if the reporter key may be compromised.
    • Open Price Feed belongs in the active corpus because it gives a clean baseline for comparing signed-source oracles, protocol-owned price views, fallback design, and the difference between data authorship and transaction submission.
  • Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were the repository README, core contracts, and Compound governance threads collected in ../../whitepapers/compound-open-price-feed-primary-sources-2026-05-13.md.

Failure-prevention checklist

  • Keep reporter authorship, poster submission, and protocol-facing price selection as separately reviewable roles. Anyone can post is only safe if the reporter key, freshness rules, and view-layer acceptance policy are still explicit and narrow.
  • Inventory every reporter key and invalidation path as oracle authority, not operational garnish. If one signer can still define the live price path or flip the system into anchor-only mode, that key is part of treasury risk.
  • Demand real anchor independence before treating the anchor as a safety rail. Distinct code paths do not help if the reporter and anchor still share the same market structure weakness, liquidity venue, or manipulation window.
  • Keep freshness, timestamp, and future-dating bounds visible and per-asset. Signed prices that can linger too long or arrive too far in the future turn authenticated data into stale oracle authority.
  • Review anchor-ratio tolerances as live market-risk policy. A 20% guard band or similar threshold is not just a parameter; it decides when the reporter remains authoritative and when the fallback takes over.
  • Make invalidation mode operationally boring. Compromised-reporter handling should clearly define who can trigger it, what prices downstream markets continue to trust, and how a replacement reporter is admitted without ambiguity.
  • Ensure downstream consumers know which layer they are trusting. Lending markets, liquidation bots, and governance tooling should not quietly mix raw signed data, anchored view outputs, and fallback prices as if they were interchangeable.
  • Bound loss under reporter or anchor failure. Caps, pauses, borrow-side throttles, or market-specific containment should assume the signed-source path or the anchor path can still publish wrong truth once.
  • Treat poster openness as a transport property, not a security proof. Open posting removes one permissioned relay bottleneck, but it does not remove source-key concentration or bad-policy risk in the view contract.
  • Re-audit oracle consumers whenever anchor venues, reporter sources, or market windows change. Independence and manipulation resistance are route-local properties, not one-time architectural claims.

Audit prompts

  • Who can author the economically authoritative price today: the reporter key, the anchor formula, governance-set bounds, or some combination of them?
  • What exact condition makes the view contract accept the reporter price, reject it, or fall back to anchor-only mode for each asset?
  • How independent is the anchor from the reported source in practice? Could the same exchange venue, liquidity regime, or market shock corrupt both sides of the check at once?
  • What happens if the reporter key is compromised, unavailable, or falsely invalidated? Which prices remain live, and who decides when the system leaves degraded mode?
  • Are timestamp checks and stale-price bounds tight enough for the markets consuming the feed, or can an old signed value still masquerade as current authority?
  • Which downstream contracts consume OpenOraclePriceData directly versus the anchored view, and could any integration accidentally bypass the guard layer?
  • How are per-asset anchor ratios chosen and updated, and what evidence shows they are narrow enough to catch bad prices without creating constant liveness failures?
  • Can an attacker cheaply manipulate the Uniswap TWAP or whichever anchor venue is configured long enough to bless a bad reporter price or make fallback pricing unsafe?
  • If the poster role is permissionless, what prevents spam, griefing, or selective posting games from becoming an availability or ordering problem for markets that depend on timely updates?
  • If one asset’s reporter, anchor window, or invalidation state changes, what inventory tells operators which Compound markets, liquidations, and integrations inherit that exact oracle risk?

Lessons that should already be standard

Internal linkages

Control surface

  • The leverage sits in reporter-key custody, poster openness, view-layer anchor policy, invalidation authority, and the downstream choice of whether markets consume raw signed data or the guarded view.

  • Open Price Feed is most useful as a reminder that oracle stacks are layered systems: data authorship, transport, authenticated storage, and protocol-facing policy each create a different place where truth can narrow or drift.

  • The architecture is safer than a single permissioned poster only when teams keep asking the harsher question: who actually gets to decide when a signed price becomes money-good protocol truth?

  • Last reviewed: 2026-07-17 UTC

Graph View

Backlinks