This website is no longer actively supported. Please see the Ripple Developer Center for up-to-date documentation and other resources.


From Ripple Wiki
Revision as of 21:03, 16 October 2015 by MDuo13 (Talk | contribs) (multi-sign not in 0.30.0 anymore =()

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Multisign (aka Multi-signture and M-of-N)


Multi-signatures are in development, with features being released in stages. The first stage, simple multi-signing, is currently targeted for inclusion in a forthcoming version of rippled. Until the feature has been released, the contents of this page are still subject to change.


You can add a "SignerList" to a Ripple account so that a quorum of signatures can authorize transactions to the account. The SignerList has the same permissions level as a Regular Key. (Basically, it can do everything except disable the master key or enact a global freeze.) You can use a SignerList alongside other methods of authorization, or you can disable the master key and remove any regular key, so that the SignerList is the only way to authorize transactions for the account. As before, the account must keep at least one method of authorizing transactions.

The members of a SignerList can be "actual" Ripple accounts or "phantom" accounts (addresses that aren't funded in the ledger). If the referenced account exists in the ledger, it can use a regular key (if one is defined) or the master key (unless it's disabled) to provide a signature for a multi-signed transaction. If the account doesn't exist, it can sign using the master key only. Each member of a multi-signature must be a single signature, not another multi-signature, even if the referenced account has a SignerList enabled.

Primary use cases:

  • Two factor authentication
    • Can require multiple devices to authorize a transaction.
  • Group management a Ripple account.
    • Including groups of automated processes, that must cooperatively sign transactions. As long as a quorum of these processes is not compromised the account is not compromised.


  • If someone changes their regular key or disables their master key, then their outstanding signatures can become invalid. They will need to construct new signatures.

Protocol changes:

  • New node type in the ledger, "SignerList", which is owned by an account and contains a list of accounts that can sign for it.
    • An account can have at most 1 SignerList.
    • Each member in the SignerList has a weight value.
    • The SignerList has a quorum value. The weight of the signers must be equal or greater than the quorum to authorize a transaction.
    • Together, weight and quorum allow flexible requirements for allowing multi-signatures, such as "all members", "any 3 members", "any two members plus a specific member", and more.
    • A SignerList must have at least 1 member and no more than 8 members.
  • New transaction type, "SignerListSet", which provides a way for an account to specify a SignerList.
    • SignerListSet has no special transaction fee requirements
    • SignerListSet can add, replace, or remove the SignerList from an account.
  • AccountSet and SetRegularKey transactions are modified such that you can disable the master key and remove the regular key if a SignerList is available.
  • Multi-signed transactions have the same permissions levels as regular-key-signed transactions. They cannot disable the master key, but they can re-enable it.
    • Any other transaction can be multi-signed.


As usual, rippled servers only distribute a candidate transaction if the sending account can pay an XRP fee. A multi-signed transaction requires a larger XRP fee to distribute. If the network fee for a simple-signed transaction is N XRP, then a multi-signed transaction requires an addition N XRP for each signature in it.

Example: If the current network fee is 12,000 drops of XRP, a transaction signed by 3 signatures requires (3+1) * N = 48,000 drops.

The SignerListSet transaction has normal fees.


As usual, nodes in the ledger owned by an account contribute to that account's XRP reserve requirement. A SignerList node requires a larger reserve than an Offer or RippleState (Trust Line) node. The SignerList itself contributes 2 to the owner count, and each member of the SignerList adds another 1 to the owner count. The total owner reserve is N XRP times the owner count.

Example: if the "owner reserve" is 5 XRP per item, a SignerList with 8 members requires a reserve of (2+8) * N = 50 XRP. A SignerList with 1 member requires a reserve of (2+1) * N = 15 XRP.

Not Included

Many features that have been discussed for multi-signatures in Ripple are not included in the first stage of multi-signing. These features will not be included in the initial feature set, but may still be considered for future releases.

  • Tickets - holding a place for a transaction while you collect signatures
  • In-ledger communication regarding pending transactions that require additional signatures
  • Multi-level multi-signatures: using a multi-signature as a member of a multi-signature.
  • Multiple signer lists for a single account
  • Fine-grained permissions for multi-signatures


This feature was discussed on the Ripple Forums, under the thread Multisign (aka multi-signature, M of N, 2FA, escrow)

Detailed reference documentation regarding multi-sign will be released when the multi-sign feature is released.