In certain circumstances you might like to use a Safe as a signatory to another Safe. We call these “Sub Safes”. These can provide an extra layer of security when implemented This article will walk you through the steps to take to make this setup operational.
For Nested Safes to work one of the owners of the Safe has to set it up using an Externally Owned Account (EOA) using any one of our supported wallets. This owner account will be used to initiate whatever transactions you might want to carry out.
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.