> Also - why would you ever set up a system where the majority of its assets can be drained by a single transaction, whether legitimate or not? Just because it's not centralized doesn't mean every transaction is made equal; one could require timeout periods for transactions above a certain amount, or any size of transactions could trigger a halt once a certain amount has been bled in aggregate, that requires supermajority consensus to "unlock" the chain. That this wasn't built in, in an ecosystem where hacking is rampant, by a team focused on creating a cross-chain transmission utility, is surprising, to say the least.

Easier said than done. This is obviously vulnerable to sybil attack- the attacker just make a lot of different transactions. You could build in a circuit breaker that would slow down transactions to only allow a certain rate of increase in total dollar volume going through the bridge. Hopefully this would slow the attacker down enough.

Now you're basically trying to devise a heuristic of what every single attack might look like in terms of transaction volume increase. If you're wrong, the bridge will freeze right when a lot of people want to use it. Plus, you also need to build a price oracle now.

All of this is possible, but maybe it's better to spend that effort on just making sure the code is secure in the first place.