Transaction size caps for defi protocols
I have a very idiotic mechanism, which would prevent multi-million dollar defi hacks on any protocol from ever happening again: simply impose size caps on transactions.
We could just make it so in any one transaction, any trader can trade at most, say, $500k. If you want to trade more, just do multiple transactions. Also, we could build in some kind of kill-switch so that devs can turn off the protocol at will (perhaps, say, only if a sufficient dollar volume of withdrawals happen in some time).
This implies that a hacker can't steal $100mil in one transaction. They have to do a bunch of transactions, and while the transactions are in the mempool, if the devs are awake, they can flip the kill-switch and stop the hack from taking more than a few $500k's.
This world would have an interesting kind of "MEV for social good". Detecting a series of hack transactions in mempool would lead to a gas race for devs to try and outbid the hacks to flip the kill-switch. Note that the devs have an advantage here. The hacker needs to get hundreds or thousands of transactions through to steal all the money. The dev only needs to get the killswitch through once, so the dev has a natural advantage in the MEV race here.
Devs need sleep occasionally. Rather than constantly monitoring for hack transactions themselves, devs could contract the hack monitoring service out to MEV bots. If bots see hack transactions in mempool, they race to outbid and flip the kill-switch, and are paid a bounty from devs for this.
Another possible design: we could also allow larger transactions, but through a manual approval process. When a tx >$500k hits mempool, devs have to proactively approve the transaction for it to go through. Devs cannot edit the transactions — only approve or reject. Since presumably the approve/reject is designed to fix bugs in code, we could make it so a reject automatically freezes all transactions for some time. This prevents devs from using approve/reject power to discriminate among customers: they can only use it for bug fixing.
To keep devs' incentives aligned, there might be some cost of rejection. Like, devs might have to donate $50k to some charity to flip the kill-switch. So they'd only flip it if they expect to lose more than $50k on the bugged transaction going through.
The logic behind this stupid idea is that, if we think code generically has bugs, rather than assume code doesn't have bugs, we should just look for ways to bound the loss from bugs happening, through size caps, some elements of discretion, and so on. Interestingly, this is (to my knowledge) essentially how things are done in tradfi. There's different levels of security for transactions of different sizes. You can easily send a dollar. Send a couple thousand and you might be subject to review. Send a couple tends of thousands and bank needs more info. I haven't sent more than that but I assume similarly security is more intense for bigger transactions. And at some point, security involves discretion: a human being stares at the transaction and is like, "hmm, does this look legit or is something fishy going on here?"