Oracle Security Module (OSM)

The OSM's primary function is to delay the publication of new price data from its source oracle (e.g., a Medianizer) for a fixed period, typically one hour. This creates a time-locked price feed where the current on-chain price is always the price from one hour ago. This delay provides a predictable window for the system to react to malicious price updates before they take effect.

The delay is a direct defense against flash loan-based oracle manipulation. In a typical attack, a malicious actor could borrow vast sums, manipulate a spot price, trigger liquidations or mint excessive debt, and repay the loan—all within a single transaction. The OSM's delay makes this impossible, as the manipulated price would not be available on-chain until long after the transaction concludes.

Key OSM parameters are managed by Maker Governance through executive votes. This includes:

• Delay duration: The length of the price delay (e.g., 1 hour).
• Source oracle: The address of the feed provider (e.g., the Medianizer contract).
• Authorized readers: Which contracts (like Vaults and Liquidators) are permitted to read the delayed price. This ensures centralized, democratic control over a critical security component.

The OSM exposes two primary view functions with different security levels:

• peek(): Returns the future price (the most recent raw feed data) and a validity boolean. This is used for system monitoring and off-chain analysis.
• read(): Returns the current, time-delayed price that is safe for use within the protocol. Only contracts explicitly authorized by governance (like the Vat core accounting contract) can call read(), enforcing the security boundary.

The OSM does not hold collateral or manage debt directly. It is a peripheral contract that feeds data into the core Vat system. When a liquidation engine or vault needs a price, it calls the OSM's read() function. This architectural separation follows the principle of least privilege, isolating the oracle security logic from the core monetary functions of the protocol.

The one-hour delay represents a calculated trade-off between security and price freshness. While it provides robust protection, it means the protocol operates on slightly stale data. This design assumes that the market cannot be reliably manipulated for a full hour without the price correcting. It is a deliberate, conservative security choice suited for a decentralized stablecoin backbone, prioritizing system integrity over ultra-low latency.

The OSM acts as a time-delayed buffer between the Maker Protocol's oracle relays and its core smart contracts. It stores the latest price feed but only releases the medianized price from one hour ago to the system. This creates a mandatory delay window where the price used for critical actions like liquidations is already public and immutable on-chain, preventing attackers from exploiting new price data instantly.

The primary security function is to neutralize flash loan-based oracle manipulation. In a typical attack, an attacker uses a flash loan to dramatically move a market price, triggering unfair liquidations. With the OSM, the price used by the system is one hour stale, making it impossible for an attacker to both manipulate the current price and have that new price affect the protocol within a single transaction block.

This contrasts with a direct oracle feed, where the latest price is used immediately.

• Direct Feed: Vulnerable to instantaneous price spikes and MEV (Maximal Extractable Value) extraction.
• OSM (Delayed Feed): Uses a historical, verifiable price, sacrificing some immediacy for byzantine fault tolerance. Vault users can see the pending price change with full transparency and have one hour to react by adding collateral or repaying debt.

The OSM is integrated with Maker's Liquidations 2.0 (Dog and Clip) system. The delayed price from the OSM determines the collateral auction kick price. This ensures auction start prices are based on stable, historical data, not a momentarily manipulated market. Keepers monitoring the system can see the future price and prepare for liquidations predictably, improving market efficiency.

The OSM provides complete transparency. The peek() function shows the current, delayed price in effect, while the peep() function shows the future price that will become active after the delay. This gives vault owners a one-hour grace period to take corrective action if the future price might put their position at risk, acting as a final automated warning system.

Implemented as a smart contract that is fed by the Medianizer from Maker's oracle network. It uses a simple queue-like storage for price data, with a new price poke()ed in every hour. The system's security guarantee relies on the assumption that an attacker cannot manipulate an oracle price and sustain that manipulation on external markets for over an hour, which is economically prohibitive.

The OSM's primary function is to enforce a one-hour delay (configurable per collateral type) between when a new price is reported by the oracle and when it becomes available for use by the Maker Protocol. This creates a critical security buffer, allowing time for the community to detect and react to potentially harmful price data before it impacts the system's collateralization ratios and triggers liquidations.

The delay is a direct defense against oracle manipulation attacks and flash loan exploits. Without an OSM, an attacker could theoretically manipulate a spot price, instantly drain a protocol via undercollateralized loans, and exit before the market corrects. The one-hour window makes such attacks economically unfeasible, as the manipulated price would be visible to all, allowing for emergency shutdown or other defensive governance actions.

The OSM introduces a fundamental trade-off between price freshness and security. While it prevents instant manipulation, it also means the protocol operates on slightly stale data. This can be problematic during periods of extreme market volatility, where a one-hour-old price may not accurately reflect current market conditions, potentially leading to delayed liquidations or suboptimal keeper incentives.

The OSM works in tandem with the Oracle Medianizer (or OSM). The process is:

• Medianizer: Aggregates price data from multiple oracle relayers to produce a single canonical price.
• OSM: Takes this canonical price as input, stores it, and only releases it to the core Vat contract after the delay has elapsed. This separation of concerns ensures the delay logic is isolated and auditable.

The OSM's delay parameter is not static; it is a governance-controlled variable. The MakerDAO governance community can vote to adjust the delay (e.g., osm.wait) for specific collateral assets based on their liquidity, volatility, and perceived risk. This allows the system to optimize the security-latency trade-off on a per-asset basis.

The OSM is not a complete oracle security solution. Its effectiveness relies on other components:

• Robust Oracle Feeds: A diverse set of high-quality data sources is still required.
• Emergency Shutdown (ES): The ultimate circuit-breaker if malicious data passes the OSM.
• Circuit Breaker Modules: Some protocols implement additional logic that can freeze oracles if price deviations exceed certain thresholds within the delay window.

A Decentralized Oracle Network is a collection of independent node operators that collectively source, aggregate, and deliver data to smart contracts. The OSM is a security feature that can be deployed within a DON. While the DON provides data availability and censorship resistance, the OSM adds a final delay to protect against flash loan attacks targeting the oracle's price feed.

A price feed is a continuous stream of asset price data (e.g., ETH/USD) published by an oracle. It is the primary data type secured by an OSM. The OSM does not create the price; it receives the latest aggregated price from the oracle's reporting nodes and releases it to consumer contracts only after a predefined delay, making front-running the updated price impossible.

The time delay (or delay period) is the core security parameter of an OSM. It is a fixed window (e.g., 1 hour) during which a new price value is held in the OSM contract before becoming available for on-chain use. This delay neutralizes flash loan attacks by removing the atomicity between a price update and a malicious trade that depends on it.

A flash loan attack is a type of exploit where a borrower takes a large, uncollateralized loan within a single transaction, manipulates an asset's price or a protocol's state, and repays the loan before the transaction ends. The OSM is specifically designed to mitigate oracle-based flash loan attacks by enforcing a mandatory delay between a price update and its availability, breaking the atomicity required for such attacks.

Oracle manipulation is the act of artificially influencing the data provided by an oracle to profit from connected smart contracts. Methods include:

• Flash loan attacks to skew an on-chain price.
• Data source manipulation at the API level.
• Sybil attacks on decentralized oracle nodes. The OSM defends against the first type by introducing a mandatory time delay, forcing attackers to hold a position and bear market risk.