Content
@
0 reply
0 recast
2 reactions
bbuddha
@bbuddha
Are there any existing implementations of Gnosis Safe that restrict the ability change its threshold and signers to a configurable address rather than the safe itself?
2 replies
0 recast
3 reactions
meetm
@meetm.eth
Hard to restrict anything and cover all tracks as long as it has modules and delegate calls. First step would be to strip those out.
2 replies
0 recast
3 reactions
Spencer Graham 🧢
@spengrah.eth
Its tough (and adds gas overhead) but you can use the guard hook to check for and prevent those types of changes. This is what we did for Hats Signer Gate: https://github.com/Hats-Protocol/hats-zodiac#hats-signer-gate
1 reply
0 recast
0 reaction
meetm
@meetm.eth
Not particularly familiar with zodiac. But guards don't execute on module transactions.
1 reply
0 recast
0 reaction
Spencer Graham 🧢
@spengrah.eth
That's true, but in our case the signers initiate txs via the normal Safe.exec() path, not from the module. The "only" thing module does is manage who can be a signer, sets the threshold appropriately, and constrains the signers' txs accordingly.
1 reply
0 recast
0 reaction
meetm
@meetm.eth
Looking at the gate seems like owners can get out of sync if no one synced it after the hats was revoked?
1 reply
0 recast
0 reaction
Spencer Graham 🧢
@spengrah.eth
True, though... 1. anybody can remove an invalid signer 2. the guard validates signatures based on current hat wearer status, so signatures from invalid signers are rejected
1 reply
0 recast
0 reaction
meetm
@meetm.eth
ah right
1 reply
0 recast
1 reaction
meetm
@meetm.eth
but yeah its hard to guarantee anything on a safe as long as delegatecalls exist
1 reply
0 recast
1 reaction
meetm
@meetm.eth
best you can do is add a guard before any modules are added and prevent adding modules with the guard thereafter. but even then there is no way for guard to know if no modules existed previously by direct storage write to the module slot
1 reply
0 recast
1 reaction
