The multisig wallet is a powerful organizational primitive, enabling individuals to share control over funds and assets, and to collectively execute smart contract interactions. They can be created quickly and inexpensively, and they facilitate international financial cooperation.
While this tool has been around for a few years, allowing individual wallet addresses to operate as signers, what is new is the ability to abstract this signer role into a token which can be transferred from one wallet address to another, thus transferring signatory status from one person to another. One tool which enables this is SignerGate, which is currently being developed by the team at Hats Protocol.
When considered in the context of a single, isolated multisig, this new capability may not seem to be much more useful than the default "account-bound" setting. After all, static signers can still propose to add or remove signers to the multisig, so why incur the complexity of interacting with an additional smart contract?
As usual, the answer depends on one's situation. If the multisig is only being used by a few people in a small organization with no membership body or auxiliary departments, then perhaps the simplicity of the default "account-bound" multisig makes it the better choice. If, however, the multisig in question is part of a larger organizational structure, or is subject to oversight from a higher committee or group of shareholders, then the composability of a role-bound multisig starts to take on more importance.
Before exploring said composability, first I will highlight the fundamental innovation of role-bound multisigs.
Account-Bound Multisigs vs. Role-Bound Multisigs
Where normal account-bound multisigs have their signer slots assigned to wallet addresses, role-bound multisigs have their signer slots assigned to tokens, tokens which represent roles and which can be transferred between wallet addresses.
Below is a diagram illustrating the difference between an account-bound multisig and a role-bound multisig, in terms of how each would go about replacing a signer.
In isolation, the difference between these methods may not bring much utility, and in fact the standard account-bound multisig may be more straightforward to operate, all else being equal. That said, the benefits of the role-bound multisig begin to emerge as the organization in question develops a more complex and hierarchical system of permissions and authority.
For example, imagine there is a multisig for a project management team, and they have a certain budget given to them from the organizations primary treasury multisig. Just using account-bound multisigs, the primary treasury team would not be able to actively oversee operations of the project management team, and would not be able to intervene if something goes wrong. Whereas, if the project management multisig were a role-bound multisig, and if the primary treasury multisig had admin over transferring signer hats, then the treasury team would be able to dynamically appoint and reappoint signers on the project management multisig.
Another example, and perhaps the most exciting one, is the prospect of giving a DAO, or some other tokenholder community, admin control over a given role-bound multisig, thus allowing the community to collectively elect who has signer status for their treasury. Operationally speaking, this can be done in a number of ways, such as giving the top hat* of the organization's hat tree to a Moloch DAO contract, or even running a contest on jokerace to nominate and elect hat wearers.
Takeaways
Whether to use a regular account-bound multisig or a role-bound multisig depends on the context in which the multisig will be used. If it will be used in relative isolation, such as for a small core team to co-manage funds, the simplicity of the account-bound multisig makes it a preferable option for less technical users. However, if the multisig in question will be nested in a larger hierarchical system of oversight and management, the role-bound multisig enables a whole field of sophisticated possibilities.
Footnotes & Resources
*The term "Top Hat" refers to the master admin hat in a given hat tree. The top hat can create, modify and transfer "child hats" which represent different roles in an organization, and these child hats can create, modify, and transfer child hats of their own. For more information, see the Hats Protocol documentation listed below.
Guide for integrating Hats Protocol with a Safe multisig (using the SignerGate contract)
Zodiac wiki (SignerGate is a "Zodiac Module" for multisigs)
