Nested Gnosis Safes - more granular control of permissions

Knowledge Base Archive
1

I initially posted on the Discord channel but sharing also here for additional visibility.

Maybe you know? Maybe you’ve done this already or know some creative workarounds?

Problem

Gnosis Safe offers m-of-n pattern but does not allow a granular control.

For example, 3 dudes from Colombia office can collude and leave the entire company out of luck.

Ideally, we would like to ensure that such collusion cannot take place, because some of the confirmations have to come from the members of another group.

Suggested design

flags nested
flags nested725×483 21.4 KB

I believe that is a sufficient level of security, decentralisation, redundancy.

Nested multisig (OLD)

Example: Aragon Legacy Documentation | Aragon Legacy Documentation | Aragon User Documentation

Aragon Association Multisig: Luis, Jorge, Community

Community: 6-of-9 reputable people in the ETH space

Using OLD multisig I was able to initiate a transaction and then using Safe I was able to confirmTransation but that is far from ideal.

Wallet Connect as a workaround?

BUT: Facing some issues…

  • Upper left: 0x76eE via Wallet Connect
  • Bottom left: 0x76eE not logged in.
  • Upper right: 0x823C logged in via MetaMask
  • Bottom right: 0x823C logged in via MetaMask, using Wallet Connect Safe App

0x76eE is 2-of-n, one of the members is 0x823C.

Steps:

  1. Connect via Wallet Connect.
  2. Go to Apps → Wallect Connect
  3. Paste the connection string
  4. New Transaction → Send Funds
  5. Popup bottom right 0x823C Wallet Connect
  6. Confirm in upper right 0x823C

Now… The confirmation from 0x823C is not propagated. Bottom left 0x76eE reloading. Connecting via MetaMask. The signature from 0x823C is not visible in the transaction list. In other words - nested Safes do not receive notification about the transaction to be signed - so it doesn’t work in practice :cry:

If I make the Final Safe to be (1-of-n) then Wallet Connect to another Safe works - this is because transaction can be executed instantly with a single confirmation, lack of notification to other Safes is not an issue.

Other workarounds possible?

Tapping into the power of the crowdsourcing and community… Maybe you will know?

Or maybe the existing flow with Wallet Connect is ze best, just the Transaction Service needs some finetuning to properly propagate such signatures?

Related: EIP 1271

  • https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1271.md
  • https://github.com/gnosis/safe-contracts/blob/94f9b9083790495f67b661bfa93b06dcba2d3949/contracts/GnosisSafe.sol#L190

Signature data that should be verified. Can be ECDSA signature, contract signature (EIP-1271) or approved hash.

2

Hey,

I got back to you on Discord about this just now. Just linking the Discord message here for reference.

Also, here’s the related Github issue I created: https://github.com/gnosis/safe-react/issues/1743

In terms of workaround right now, I only see these 2 options:

(1)
Add 1 owner which is an EOA (e.g. Metamask) Use that owner to initially create (and sign) the tx. All other owners can be Safes via WalletConnect. Since the tx has initially been created in our backend, the subsequently on chain confirmations via approveHash should be picked up

(2)
Manually create the tx via our API (https://safe-transaction.gnosis.io/) That’s a bit tricky though since you need all raw tx params.

1 Like
3

Magic :crystal_ball:

I verified the workaround works: just use EOA to initiate the transaction.

Thank you for helping!

1 Like
4

@tschubotz, will this be fixed in a future release?

Or do you intend that no Gnosis Safe could ever have only other Gnosis Safes as owners?

5

This will be fixed in a future release. So far we haven’t optimized the interface at all for using Safes as owners of other Safes, hence these issues.

3 Likes