serai/docs/protocol/Multisig.md

# Multisig

Multisigs are confirmed on-chain by the `Multisig` contract. While the processor
does create the multisig, and sign for it, making it irrelevant to the chain,
confirming it on-chain solves the question of if the multisig was successfully
created or not. If each processor simply asked all other processors for
confirmation, votes lost to the network would create an inconsistent view. This
is a form of the Byzantine Generals Problem, which can be resolved by placing
votes within a BFT system.

Confirmation requires all participants confirm the new set of keys. While this
isn't BFT, despite the voting process being BFT, it avoids the scenario where
only t (where t is the BFT threshold, as used in the t-of-n multisig)
successfully generated shares, actually creating a t-of-t multisig in practice,
which is not BFT. This does mean a single node can delay a churn, which is
expected to be handled via a combination of slashing, and if necessary, removal.

Validators are allowed to vote multiple times across sets of keys, with the
first set to be confirmed becoming the set of keys for that validator set. These
keys remain valid for the validator set until it is changed. If a validator set
remains consistent despite the global validator set updating, their keys carry.
If a validator set adds a new member, and then loses them, their historical keys
are not reused.

Once new keys are confirmed for a given validator set, they become tracked and
the recommended set of keys for incoming funds. The old keys are still eligible
to receive funds for a provided grace period, requiring the current validator
set to track both sets of keys. The old keys are also still used to handle all
outgoing payments as well, until the end of the grace period, at which point
they're no longer eligible to receive funds and they forward all of their funds
to the new set of keys.

### `vote(keys: Vec<Option<Key>>)`

Lets a validator vote on a set of keys for their validator set.