The digest of an NTT message doesn't include the source manager address. What this means is that if an NTT deployment changed a peer to a new NTT manager on the remote chain, there is a very small possibility of digest collisions (since the sequence number of that deployment would start from 0 again). For a collision to happen you would need the same sequence, sender, amount, source token, recipient and toChain to be sent from the new NTT peer. The net impact is that a legit message would not be deliverable as it would be fail the replay protection check.
This is not exploitable unless an attacker somehow has prior knowledge that a sender will be sending the same amount of the same token to the same recipient on the same chain and can bump the sequence number by frontrunning. But this would be a griefing attack with no profit motive. Similarly, this could happen by accident.
NTT owners should upgrade peer contracts rather than replacing peers where possible.
The digest of an NTT message doesn't include the source manager address. What this means is that if an NTT deployment changed a peer to a new NTT manager on the remote chain, there is a very small possibility of digest collisions (since the sequence number of that deployment would start from 0 again). For a collision to happen you would need the same sequence, sender, amount, source token, recipient and toChain to be sent from the new NTT peer. The net impact is that a legit message would not be deliverable as it would be fail the replay protection check.
This is not exploitable unless an attacker somehow has prior knowledge that a sender will be sending the same amount of the same token to the same recipient on the same chain and can bump the sequence number by frontrunning. But this would be a griefing attack with no profit motive. Similarly, this could happen by accident.
NTT owners should upgrade peer contracts rather than replacing peers where possible.