Security Considerations when using Pull Oracles
summary
Pull oracles require the user to supply price payloads (examples: Pyth, Chainlink Data Streams, Redstone) and come in atomic execution, deferred execution and internal validation flavors. Concrete risks: future timestamps and stale-price replays, multiple valid prices in one transaction amplified by flash loans, compromised signer keys breaking immutable contracts when using on-chain signature checks, and integration mismatches needing multicall or EAS workarounds (example: GMX uses deferred resolution, Compound V3 can be driven via multicall). Mitigations include strict timestamp checks, non-reverting on old payloads, and per-asset adapter contracts.
AI-written summary · about
chapters (14)
- 0:00Pull oracles introduction
- 2:30Push oracles limitations
- 5:40Pull oracle execution patterns
- 7:04Payload validation methods
- 9:30Pull oracle types examples
- 10:39Pull oracle integration steps
- 13:49Pull oracle security pitfalls
- 15:16Timestamp and DoS risks
- 16:45Flash loan attacks
- 17:48Immutable protocol risks
- 18:30Compatibility challenges
- 19:58Compound V3 integration
- 21:01Other oracle types
- 21:23Q&A
related talks
13mTWAP Oracle Manipulation Risks
24mOracles Secure The Data - Who Secures The Oracles?
22mAlpha for Auditors: The Vulnerabilities of Tomorrow
18mNot Quite Water Under the Bridge
15mChainlink Oracle Reputation
26mFinancial Use Cases for Blockchain & Oracles
14mContract Security, Digital Identity, & Becoming a Blockchain Dev
20mSolidity's most common security pitfalls and its best safeguards