SCCP-52: Change Debt Snapshot Stale Time to 4 Hours

Simple Summary

This SCCP proposes changing the debt snapshot stale time to 4 hours.

Abstract

The pDAO will call SystemSettings.setDebtSnapshotStaleTime(15000). Note that the argument is 15000 seconds, which is actually 4 hours and 10 minutes. This is to allow a snapshot heartbeat frequency of 4 hours, allowing the keeper bot 10 minutes of leeway to mine the transaction. This will save significant resources. The keeper bot will still take snapshots earlier than 4 hours if the deviation exceeds the configured threshold of 2%, so lowering the frequency should not unduly impact the integrity of the system.

Motivation

Since SIP-83 went live, snapshots have been operating approximately once per hour to ensure the accuracy of the snapshot. This cannot be slowed down as the current stale time is also 1 hour. This stale time was initially set at a cautious level to protect the system, but has proven to be unnecessarily aggressive. Consider the following chart of the percentage deviation of the cached debt from the true total system debt over the day following the Deneb release.

The dashed lines indicate the times at which complete snapshots were performed to prevent the snapshot going stale. The upper and lower bounds of this chart are the limits the deviation would have to breach in order to trigger a fresh snapshot.

Note in particular that the keeper's configured deviation threshold of 2% was never close to being breached. Over this period, the deviation at snapshot time exceeded 0.06% only twice. Those two snapshots occurred at deviation levels of 0.21% and 0.33%, so in order to trigger a debt snapshot, the maximum deviation would need to be sixfold greater. As each complete snapshot presently costs around 1.5 million gas, it is wasteful to spend these resources updating a debt cache that is already highly accurate.

The current stale frequency eliminates most of the benefit of SIP-83's main snapshot update mechanisms. First, as the deviation is so low, deviation snapshots are never triggered, so the partial snapshot mechanism is never able to operate. This mechanism would allow minimal deviations to be maintained with much less gas expenditure by targeting only those specific synths which have caused the price to deviate. Second, the high snapshot frequency obscures the extent to which the deviation is corrected by cache updates due to synth exchanges.

In effect the high snapshot frequency entails paying more to learn less, and for this reason and those described above, this SCCP proposes slowing the heartbeat down. In the long run it may be a better approach to lower the stale time substantially, while also lowering the deviation threshold on the keeper bot.

Copyright

Copyright and related rights waived via CC0.