Create sip onchain checkpoint oracle

[92GC]

No description provided.

[mystenmark]

Sorry for the delay in getting to this. Very interesting idea. A couple of notes:

• This would have to be done with commit timestamps, not checkpoint timestamps, because checkpoint construction and execution are asynchronous. But the overall idea would be the same.
• I think this could be added as an extension to the system Clock object relatively easily.

The proposed sliding mechanism window is efficient in theory, but will be somewhat difficult to implement due to crash recovery requirements.

As an alternative, what if we exposed exponential moving averages for a handful of different α values? (say 0.1, 0.01, and 0.001)?

[92GC]

Thanks @mystenmark for the review!

Commit vs checkpoint timestamps: Makes sense - we'll revise to use commit timestamps.

Extending Clock: Cleaner approach, happy to revise the spec for that.

On EMAs: We thought about this more. Our concern is that EMAs smooth out spikes - a 2-hour stall gets diluted rather than being directly queryable. But you're right that we need something self-adjusting to handle protocol upgrades.

Counter-proposal: What about exposing max and median?

/// Max gap between consecutive commits where both fall within [start_ms, end_ms]
public fun largest_commit_gap_between(start_ms: u64, end_ms: u64): Option<u64>;

/// Median gap in the history window (what's "typical")
public fun median_commit_gap_in_window(): u64;

Our circuit breaker logic would then be:

let market_gap = clock::largest_commit_gap_between(market.start, market.end);
let typical = clock::median_commit_gap_in_window();
if (market_gap > typical * 100) { /* stall detected */ }

Why median over EMA:

• More intuitive ("typical gap" vs abstract α values)
• Resistant to outliers - a single stall doesn't skew the baseline
• Self-adjusts to protocol upgrades

The median doesn't need to be live - "median as of recent checkpoint" works fine for our use case. Could be precomputed/cached at checkpoint boundaries and recomputed once on crash recovery.

We're flexible on implementation details - the core need is: "compare this market's max gap against what's normal."