One way to improve the workflow would be to use a pull model instead of a push model.
So instead of “transaction on chain A triggers message on chain B”, it’s “transaction on chain B synchronously reads chain A” (eg. through a Merkle proof, or in the future this could be batched with some KZG or SNARK or other scheme)
This still has the same key property: safes live on chains B, C, D… but the validation rules live on chain A, so you only have one copy of the validation rules that needs to be edited, but it has a number of important benefits:
- Transactions are faster: there is no asynchronous step required, it’s all one single synchronous transaction on chain B
- Avoid spending gas on chain A - really important because I expect many people will want to have the “home” of their safe be ETH layer 1, where gas will be far more expensive
- Avoid UX and economic complications of paying for gas on multiple chains