Multisig design for Cosmos SDK (DRAFT)

Things we'd like to have

• Dynamic members: with enough signatures, the account participants can change its members.
• Flexible sig power: we want different member structures to be possible (by weight, m-of-n, tiers of members, etc).
• Many signing algos.
• Migration of existing multisigs
• Allow sending messages in behalf of individual members (most likely a separate implementation)

Dynamic members & flexible sig power

We want to allow members of an account to be able to update it with a specific message for it.

message MsgUpdateMembers {
    repeated Member members = 1;
}

message Member {
    bytes pubkey = 1;
    uint64 weight = 2;
}

We'll also want to accept the usual multisig member "structures", I propose we use members weights and threshold to allow these structures without having to code specifically for each one of them. So it will be up to a front end to decide how to show things.

• m-of-n: All members have the same weight, threshold = m * member_weight
• by weight: This would be considered like "raw usage"
• tiered members: Inspired by DAODAO, we can use a frontend to allow different levels of participants that hold different powers depending on an arbitrary off-chain rule.

My idea is that with weight and threshold you could represent almost any kind of multisig. Although I haven't really tested this statement enough.

Many signing algos

We can have a set of supported algos, which would translate in some Authenticate functions.

Desired signatures algorithms:

• secp256k1
• BLS
• ???

Each one of them can have different ways of getting SignBytes, as for example BLS requires that each signature is made to a different message (to be verified by someone that knows more about it).

We could also have different ways of calculating sign bytes, allowing signatures from Metamask for example.

Signature parsing

Each authentication method will have its own way of parsing signatures.

Migration of existing multisigs

We'd need to allow accounts to set their own address for this. Then the MsgInit would need to require existing members signatures, and we'll query the multisig account's sequence and number???.

Haven't give this much thought yet

Allow sending messages in behalf of individual members

This won't be part of the multisig account, as it works too differently. Right now it's more a workaround than a proper design.

There's going to be a type of account abstraction that will be initialized during the init genesis. This account's address will be a known one, and anyone wanting to send a multi-signer message will have to know it (MULTISIGNER_ADDR).

The multisigner will be an abstracted account that can send messages in behalf of other accounts, like a SudoSend (but always performing a signature verification).

To send a multi-signer message, a UserOperation will be assembled with MULTISIGNER_ADDR as the sender.

execution_messages will contain a list of messages signed by different accounts.

authentication_method will contain a list of authentication methods, the length must match execution_messages's length (one auth method for each message).

authentication_data will contain a list of signatures, one for each msg in execution_messages.

For bundler_payment_messages we could either:

• make the first/last signer in execution_messages sign over this too
• add another signature to authentication_method that only signs over bundler_payment_messages.

I like the second approach as it will be simpler to do imo, as we treat it as an extension of execution_messages.