The three messages
MsgUpdateSystemContract : We can modify the validate basic to add the required validation
MsgWhitelistErc20 : We can modify the validate basic to add the required validation
MsgVoteInbound: This is more complicated as rejecting outright in the validate basic might be too harsh , for the end user as this does not give up any opportunity to refund back to the sender address .

With regards to evm_deposit , I am considering validating the receiver address based on coin-type,

https://github.com/zeta-chain/zeta-node/blob/8da507f0cdfb5affbc5121a712670fbd1feaab11/x/crosschain/types/cctx.go#L175-L218

Which can be called at the beginning of the function HandleEvmDeposit
https://github.com/zeta-chain/zeta-node/blob/8da507f0cdfb5affbc5121a712670fbd1feaab11/x/crosschain/keeper/evm_deposit.go#L27-L30

This Validate is for ZEVM gateway only, and I considered placing this validation in the validate_inbound.go as well
https://github.com/zeta-chain/zeta-node/blob/8da507f0cdfb5affbc5121a712670fbd1feaab11/x/crosschain/keeper/cctx_orchestrator_validate_inbound.go#L14-L57
And use gateway+cointype for conditions.
This would have made more logical sense; however, due to the current structure of the code, this would not allow us to create a revert back to the sender address.

Draft pr for reference #2707