In certain circumstances you might like to use a Safe as a signatory to another Safe. We call these “Nested Safes”. These can provide an extra layer of security when implemented. Each subsequent nested Safe's inherits the security of the parent
This article will walk you through the steps to take to make this setup operational.
Scenario:
Example of the safe setup;
2 Owners. One owner signs using an EOA (Metamask) while the other owner uses another safe. The threshold for this safe is 2 implying that both owners must sign the transaction in order for it to be successful.
The transactions are executed in a tree structure.
The transaction is proposed in the original Safe
The transaction is broadcasted and then pops up in the queue on the nested or signer safe
Each signatory of that Safe must then sign the transaction, these could also be other Safe's. You could potentially have chains of nested Safe's
Finally, transaction is then executed on the original Safe
You can see clip below on how the process works.
💡 Child-Safe's also function as de facto proposers
Child Safe owners can propose transactions directly to their Parent Safe using pre-validated signatures, enabling immediate processing in nested configurations.