It adjusts as you expect it to, with one distinction: the lateness is expressed in seconds, not in blocks.

Recall that ASERT stands for absolutely scheduled exponentially rising targets. The adjustment is invariant of current block height, but that’s not obvious from the formulae.

These are the formulae, adapted (from Toomim’s writeup):

From those we can simply calculate relative adjustment by dividing some blocks difficulty with the difficulty of block before:

The constants cancel each other out, and 2 targetTimestamps reduce to a constant of -10min and we get:

It is just the block time deviation and `tau`

which affect the magnitude of adjustment, and in the spec the `tau`

has been set to 172800 seconds (2 days).

Why 2 days? There’s a section on that in the spec:

A half-life of 2 days ( `halflife = 2 * 24 * 3600`

), equivalent to an e^x-based time constant of `2 * 144 * ln(2)`

or aserti3-415.5, was chosen because it reaches near-optimal performance in simulations by balancing the need to buffer against statistical noise and the need to respond rapidly to swings in price or hashrate, while also being easy for humans to understand: For every 2 days ahead of schedule a block’s timestamp becomes, the difficulty doubles.