POC-027 · MakerDAO OSM Standing Staleness
ProtocolMakerDAO OSM
CouplingL2×L5 — 1 hour lag structural
Lag duration60 minutes (by design)
Attack windowFull 60 min · always open
Adelic sorry: galaxy orbits a black hole 1 hour behind — structurally unstable orbit, not just attack window. The staleness is not a bug, it's built in.
Theorem: osm_standing_stale
∀ (t : Time),
L5.price(t) = L2.price(t − 3600)
OSM design:
price update queued → 1 hour delay → used
→ L5 always operates on stale data
→ attack window = 60 minutes always
→ NOT: "if attack happens within 60 min"
→ YES: "orbit is permanently 1 hour behind"
OSM DESIGN INTENT vs ACTUAL RISK
Design intent:
OSM = Oracle Security Module
Purpose: 1 hour delay gives governance time
to respond to oracle manipulation
Intent: security feature
Actual structural risk:
Attacker knows price will update in 1 hr
Can front-run update for entire window
Governance cannot respond fast enough
1 hour delay = 1 hour attack window
Adelic framing:
L2 price at time T is always actual T−3600
L5 orbits on data that is permanently stale
Not "sometimes stale" — ALWAYS stale
Standing staleness = structural coupling flaw
Worst case stalenessMarket moves 100% in 60 min
Historical precedentFlash crashes, depegs
ADELIC LAYER ANALYSIS
L2 (ℚ₃)OSM oracle — 60 min stale
L5 (ℚ₁₁)DAI stability liquidation engine
CouplingL2.output → L5.liquidation_price
Missing invariantL5 freshness verification of L2
Black hole analogy:
Singularity = DAI system
L2 ring = 1 AU outside true orbit
L5 ring orbits faithfully using L2 data
Galaxy permanently 1 hour behind the truth
"Not an attack window — a standing orbit flaw"
FILING DETAILS
ProgrammeMakerDAO · Immunefi
StatusREADY TO FILE
Priority4 of 8 in queue
↑ ADELIC BOABIXER
ARB2-POC027