It was originally added to v1 as an extra protection to ensure that not too many signers were added in case something went wrong with the maxSupply of the signer hat. But after 2 years of hats usage there haven't been any issues with maxSupply (neither contract bugs or user accidents), so I don't think the extra protection is needed.
That was for single HSG. For multi HSG — where multiple hats are valid signer hats — things are a touch different, since obviously we can't rely on the maxSupply of a single hat in that scenario. But even then, I don't think we need it. In practice, usage of MHSG has not been with high-supply hats where there is a race among hat-wearers to become signers on the safe. And this makes sense: why would anybody design a system of multiple hats where such a race would be required? Better to define the maxSupply of the relevant hats such that the number of signers on the multisig is always reasonable.
One challenge that maxSigners creates is that it forces us to do extra work to replace an invalid signer who is nonetheless taking up one of the signer slots. This challenge is especially annoying if we want to enable multiple signers to be added at once, since we have to keep track of them and the progress towards the maxSigners limit as we add each signer.
Why would we want to add multiple signers at once? Related to migrating/upgrading a Safe from one instance of HSG to another.
Why might we want to migrate? To use a new version or to remove signer hats.
Why does migrating require adding multiple signers at once? To not force existing signers to re-claim after migration, ie to claimFor the signers as part of migration.
This PR fully removes the
maxSignersparam.It was originally added to v1 as an extra protection to ensure that not too many signers were added in case something went wrong with the
maxSupplyof the signer hat. But after 2 years of hats usage there haven't been any issues withmaxSupply(neither contract bugs or user accidents), so I don't think the extra protection is needed.That was for single HSG. For multi HSG — where multiple hats are valid signer hats — things are a touch different, since obviously we can't rely on the
maxSupplyof a single hat in that scenario. But even then, I don't think we need it. In practice, usage of MHSG has not been with high-supply hats where there is a race among hat-wearers to become signers on the safe. And this makes sense: why would anybody design a system of multiple hats where such a race would be required? Better to define themaxSupplyof the relevant hats such that the number of signers on the multisig is always reasonable.One challenge that
maxSignerscreates is that it forces us to do extra work to replace an invalid signer who is nonetheless taking up one of the signer slots. This challenge is especially annoying if we want to enable multiple signers to be added at once, since we have to keep track of them and the progress towards the maxSigners limit as we add each signer.