Few comments after review

[ismaelsadeeq]

SwiftSync alleviates both of these limitations, allowing for IBD with assume-valid assumptions in as fast as 66 minutes.

Having only a benchmark for the assume-valid variant is optimistic; should add both or not mention at all. The i/o and utxo lookup elimination benefit remains a strong motivation.

$Agg = H_{salt}(Coin_{0}) + ... + H_{salt}(Coin_{i})$

Should add the modulo:
$Agg = H_{salt}(Coin_{0}) + ... + H_{salt}(Coin_{i}) \bmod 2^{256}$

If you want to be more formal, replace "salt" with the tweakable hash formalism:
$H : \mathcal{T} \times \mathcal{M} \to {0,1}^{256}$, where each client sample t from the Tweak space randomly

Using the undo data, validate the block

What do you mean by validate the block here? You should be explicit here to mention all the block validation done; if we do everything except validating whether inputs are spending unspent transaction outputs, mention that.

[ismaelsadeeq]

It seems there is an issue with the Protocol definition.

it states that all spendable outputs are added to $\mathsf{AggOutputs}$, then verifies $\mathsf{AggOutputs} = \mathsf{AggInputs}$.

This is incorrect because some outputs could be added to $\mathsf{AggOutputs}$ but never appear in $\mathsf{AggInputs}$, (because they are unspent), so the equality can never hold on any valid chain with a non-empty UTXO set at height n.

The original SwiftSync protocol is clear:

"If the hint indicates the output will remain unspent: write it to the UTXO set. If the hint indicates the output will get spent: hash its outpoint and add it to the hash aggregate."

Step 4.3 should therefore only add outputs to $\mathsf{AggOutputs}$ if they are not in $\mathsf{HintsFile}_n$:

4. For all outputs:
   1. If the output is unspendable, continue
   2. If the output is in $\mathsf{HintsFile}_n$, add it to $\mathsf{UTXOn}$ and continue
   3. Otherwise, add it to $\mathsf{AggOutputs}$

Or else you can add everything as done in the current version, and then subtract the UTXO aggregate from the Output aggregate, then that will always match.

[ismaelsadeeq]

Also, as requested above, it would be less ambiguous to explicitly mention all block validation steps done.

It is not obvious what prevents spending a coin that has not yet been created, until @RubenSomsen recently clarified that inputs are validated to ensure their creation height is not in the future.
Is it worth defining a separate standard for AssumeValid SwiftSync or expanding on that section? Based on my recent review, the two have different security assumptions.

[rustaceanrob]

Having only a benchmark for the assume-valid variant is optimistic; should add both or not mention at all.

The fully validating version requires a new peer-to-peer message and would be difficult to benchmark in a reasonable way without spending an excessive amount of time and money (e.g. running dozens of full nodes across different cloud providers). There are clients, such as Floresta, that will make use of the AV variant long before there is a fully validating client, so I think it is appropriate to list the immediate benefit.