A number of projects (e.g. MakerDAO, Balancer, DefiSaver) make use of DSProxy contracts to allow improved UX by grouping several transactions into one by using script contracts such as Balancer's BActions.
Due to its ability to batch transactions, a Safe can fulfill much the same role by making calls to ERC20 contracts to give approvals, etc. before sending the "proper" transaction. This is less flexible than a script contract as shown by the createSmartPool function in the BActions contract. Here we deploy a smart pool controller contract and then immediately call a function on that new contract to deploy the underlying pool, something not possible to do through transaction batching.
In this case, ownership over this smart pool is transferable so it can be created by another contract and then transferred to the Safe in a single transaction; were this not the case then the user of a Safe app would be required to perform 2 separate transactions to deploy a smart pool.
Allowing the use of delegatecalls would allow a "GnosisBActions" (without all the tokens transfers) script contract to perform atomic deployment in this situation.
A number of projects (e.g. MakerDAO, Balancer, DefiSaver) make use of DSProxy contracts to allow improved UX by grouping several transactions into one by using script contracts such as Balancer's BActions.
Due to its ability to batch transactions, a Safe can fulfill much the same role by making calls to ERC20 contracts to give approvals, etc. before sending the "proper" transaction. This is less flexible than a script contract as shown by the
createSmartPool
function in the BActions contract. Here we deploy a smart pool controller contract and then immediately call a function on that new contract to deploy the underlying pool, something not possible to do through transaction batching.In this case, ownership over this smart pool is transferable so it can be created by another contract and then transferred to the Safe in a single transaction; were this not the case then the user of a Safe app would be required to perform 2 separate transactions to deploy a smart pool.
Allowing the use of delegatecalls would allow a "GnosisBActions" (without all the tokens transfers) script contract to perform atomic deployment in this situation.