The advertised window is 600 seconds and the margin is sized for 900, and the 300 second
difference is deliberate rather than a number chosen to feel safe. The quantity the margin has
to cover is the accrual between the block the preview READ at and the block the transaction
SETTLES in. A caller cannot make that second block the first one: a transaction is always mined
after it is priced. Sizing the margin for exactly the advertised window therefore leaves zero
slack for the settlement block itself, and the amount is short by whatever the Trove accrued in
it.
Measured, on the fork, at the moment the base was corrected. Until MK-089 this margin
accrued on the entire debt where the protocol accrues on the principal
(InterestRateMath.sol:12-22), which over-stated it by the interest already owed. On the
redeem-boundary.fork.test.ts fixture that was about 1 percent, worth roughly 6 seconds of
accrual, and that accident was what had been covering the settlement block: correcting the
base to the contract's quantity turned the 600 second row of the ladder from send=success to
send=reverted with nothing else changed. A guarantee resting on an over-estimate nobody had
named is not a guarantee.
900 covers the advertised 600 plus five minutes of settlement. The upper bound is still
asserted: the ladder requires the margin to FAIL at 3600 seconds, so this is a bounded claim
and not an ever growing cushion.
The contract's own 600 (TroveManager.sol:1276-1285) bounds the staleness of a partial
redemption HINT, which is a different quantity from a caller's settlement delay. Reading one as
the other is what produced the original figure.
The window RedemptionPreview.nextViableAmount is sized for, in seconds (MK-095).
The advertised window is 600 seconds and the margin is sized for 900, and the 300 second difference is deliberate rather than a number chosen to feel safe. The quantity the margin has to cover is the accrual between the block the preview READ at and the block the transaction SETTLES in. A caller cannot make that second block the first one: a transaction is always mined after it is priced. Sizing the margin for exactly the advertised window therefore leaves zero slack for the settlement block itself, and the amount is short by whatever the Trove accrued in it.
Measured, on the fork, at the moment the base was corrected. Until MK-089 this margin accrued on the entire debt where the protocol accrues on the principal (
InterestRateMath.sol:12-22), which over-stated it by the interest already owed. On theredeem-boundary.fork.test.tsfixture that was about 1 percent, worth roughly 6 seconds of accrual, and that accident was what had been covering the settlement block: correcting the base to the contract's quantity turned the 600 second row of the ladder fromsend=successtosend=revertedwith nothing else changed. A guarantee resting on an over-estimate nobody had named is not a guarantee.900 covers the advertised 600 plus five minutes of settlement. The upper bound is still asserted: the ladder requires the margin to FAIL at 3600 seconds, so this is a bounded claim and not an ever growing cushion.
The contract's own 600 (
TroveManager.sol:1276-1285) bounds the staleness of a partial redemption HINT, which is a different quantity from a caller's settlement delay. Reading one as the other is what produced the original figure.