With both options, you can remove and add multi-sig signers.
Native multi-sig
In @xStelea’s way, multi-sig works via the OwnerRole of the multi-sig account. Just like on any component (an account is a component), you can change the owner role to requiring a badge. Normally, the OwnerRole of an account is set to a single Ed25519 Signature Resource, which is a virtual badge which proof can only be added to the worktop by signing with the correct private key corresponding to that proof. When, for example, you’d want a 3 out of 5 multi-sig, you can set the OwnerRole of an account to ‘require 3 of 5 non-fungibles’ with the specific non fungibles set to the Ed25519 Signature Resources of the multi-sig signer’s accounts. This way you require 3 out of 5 signatures of multi-sig signer’s accounts to be present in order to access the account.
Changing the multi-sig is a matter of changing the OwnerRole on the account. This is possible, as long as you still have enough people that are a part of the multi-sig. In our 3 out of 5 multi-sig account, if you don’t have at least 3 out of 5 people left that can sign transactions, you’re stuck forever.
Component-based multi-sig
In @StakingCoins’ way, you can mint badges that allow you to be part of the multi-sig. You can then give these badges to people you want to give multi-sig access. These badges give you permission to vote for certain actions defined in the component. Once a threshold of enough people that have a badge voting for defined action has been reached, it can be executed. You can also disable badges you’ve already given out.
This is essentially the same as with native multi-sig: once you cannot reach the threshold of sufficient signers anymore, you’re stuck (because you cannot approve the action of minting new badges). So for both of these methods, it’s important that never happens.
Considerations
The you’re stuck sounds a bit dramatic - and it probably is - because it’s intended behaviour. If there aren’t enough signers, transactions shouldn’t be able to happen. For both options, while there are enough signers, you can add and remove multi-sig signers as you please.
An interesting side note though, is that if you’d use PrimeVault it’s probably easier to recover access once you’ve lost access to sufficient people that can sign multi-sig transactions. They probably have a whole compliant process to recover access (because they still have access, even if we don’t have enough people to sign anymore). AND, if something goes wrong with custodying our assets, we’ve got someone to point to, and demand our funds back. The money we’d pay them for using their solution is not only for the technical side of the product they offer, we’re outsourcing the risk.
Edit: on the bad actors part of your question. These all seem to be fairly safe solutions to me. The only issue I have with the component based approach, is that you either need to predefine EVERY action you want to be able to take in the component, or you’d need to trust a single person whenever you want to handle funds in a non-predefined way.
Example, imagine we want to take 10k XRD out of our treasury, sell for hUSDC, and then deposit the hUSDC in Weft:
- Through native multi-sig, you can do this all atomically, we’re just controlling an account: we write a tx manifest for this transaction, and we’re good.
- PrimeVault, I believe, also supports transaction manifests
- With our component-based solution, it is possible, but then this entire sequence of actions needs to be defined inside of our multi-sig component (through Scrypto). In practice, this is not really viable. So what would happen is that we do a multi-sig for withdrawing 10k XRD to some managing member. This managing member would then solely have access to the 10k XRD, and we’d trust them to swap the 10k XRD to hUSDC, deposit into Weft, and send back the receipt to our multi-sig treasury.
