update_guardian_public_key lets the multisig quorum rotate the guardian public key to any value, including an existing approver's key, without a signature from the current guardian and without comparing the new key against the approver set. verify_signature skips the guardian signature check whenever update_guardian_public_key is the only non-auth procedure called in the transaction, so a quorum meeting the multisig threshold can set the guardian to one of its own approvers in a single transaction. From that point on, the same signature satisfies both the multisig check and the guardian check, even though AuthGuardedMultisigConfig::new rejects this exact configuration at deployment time.
Rotation already allows the quorum to set the guardian to any key it controls without the current guardian's cooperation, so this gap does not grant the quorum meaningfully more power than the rotation design already permits. Its main practical relevance is catching an accidental misconfiguration during a legitimate rotation, such as mistakenly rotating the guardian to an existing approver's key.
Consider re-validating guardian != approver when rotating the guardian, mirroring the check already performed in AuthGuardedMultisigConfig::new, most naturally as a deployment-time or off-chain safeguard rather than an on-chain assertion.
update_guardian_public_keylets the multisig quorum rotate the guardian public key to any value, including an existing approver's key, without a signature from the current guardian and without comparing the new key against the approver set.verify_signatureskips the guardian signature check wheneverupdate_guardian_public_keyis the only non-auth procedure called in the transaction, so a quorum meeting the multisig threshold can set the guardian to one of its own approvers in a single transaction. From that point on, the same signature satisfies both the multisig check and the guardian check, even thoughAuthGuardedMultisigConfig::newrejects this exact configuration at deployment time.Rotation already allows the quorum to set the guardian to any key it controls without the current guardian's cooperation, so this gap does not grant the quorum meaningfully more power than the rotation design already permits. Its main practical relevance is catching an accidental misconfiguration during a legitimate rotation, such as mistakenly rotating the guardian to an existing approver's key.
Consider re-validating
guardian != approverwhen rotating the guardian, mirroring the check already performed inAuthGuardedMultisigConfig::new, most naturally as a deployment-time or off-chain safeguard rather than an on-chain assertion.