Off the top of my head:
- Watch for reorganisation messages in the debug log showing excessive (say 10+ blocks) disconnects.
- Regular audit to check that deposit transactions are still marked as valid and have sufficient confirmations.
- Watch for large negative changes in computed/reported coin supply.
Good points, watching the debug.log for consecutive orphans/disconnects is probably best and easiest, I guess in its simplest form that are a few dozen lines of shell/python script.
Or instead of delisting coins out of nowhere, they could have asked them to implement the NLR feature that Ravencoin and Flo recently implemented which limits the number of blocks in a reorg. If they then set the required deposit confirmations twice as high they should be safe against any malicious reorgs.
I believe for many coins that are based on something more recent than Bitcoin core 0.8 this could be as easy as cherrypicking the commits from the Flo or Ravencoin repo. I wildly guess this could even be done unilaterally from an exchange without the support of the respective coins community, in worst case the exchanges wallet would just disagree with the rest of the network but would not credit transactions from later orphanized chains to their customers accounts.