# 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`.