XRP Multisignature Explained: 2 of 3 vs 3 of 5 Security Math

By XORA Research · Published August 3, 2026

XRPL multisignature lets one account require several independent keys before a transaction is authorized. A SignerList can hold 1 to 32 addresses, each with a weight, and valid signatures must reach the quorum. Under the illustrative independent key model below, 3 of 5 cuts threshold compromise probability about 30.3 times versus 2 of 3 at 1% per key compromise risk, while also reducing quorum loss risk 6.26 times at 5% per key unavailability.

What XRPL multisignature actually does

Multisignature is an account authorization method built into the XRP Ledger. A SignerListSet transaction creates or replaces the account's one current SignerList. Every proposed transaction is still an ordinary XRPL transaction. The difference is that its Signers array contains enough valid signatures to meet the stored quorum.

The list supports 1 to 32 unique signer addresses. It cannot contain the account it controls. Each entry receives a positive SignerWeight, stored as an unsigned 16 bit value, so the maximum individual weight is 65,535. SignerQuorum is an unsigned 32 bit target that must be above zero and no greater than the sum of all weights. These constraints appear in the official multisigning guide and are enforced in the xrpld 3.2 release source.

Original calculation: threshold compromise

Consider a hypothetical one year planning period. Let every key have the same independent probability p of compromise. Assume compromise means an attacker gains a usable signature, key events do not affect one another, and there is no shared cloud account, signing service, seed backup, administrator, or physical location that can fail all keys together. Those assumptions are intentionally strict so the threshold itself can be isolated.

For 2 of 3, an attacker needs exactly two keys or all three: 3p²(1−p) + p³. For 3 of 5, the binomial tail is 10p³(1−p)² + 5p⁴(1−p) + p⁵. At p = 1%, the results are 0.0298% and 0.00098506% respectively. That is about 298 versus 9.85 threshold compromises per million independent account years.

The result is powerful but fragile. Add a hypothetical 0.1% annual common event that compromises every key, while retaining the 1% independent risk otherwise, and the modeled totals become about 0.1298% for 2 of 3 and 0.1010% for 3 of 5. The apparent 30.3 times advantage shrinks to roughly 1.29 times. Five seeds in one password manager are five cryptographic keys but one operational failure domain.

Original calculation: losing the ability to sign

Security also has a liveness side. Let each key have an independent 5% probability q of being unavailable during the same planning period because it is lost, destroyed, inaccessible, or held by a signer who cannot participate. A 2 of 3 account becomes unable to sign after two or more unavailable keys. A 3 of 5 account becomes unable to sign after three or more. The formulas use the same binomial tails, now with q instead of p.

This does not prove that every 3 of 5 deployment is safer. More participants create more coordination, identity, and device management work. If the added signers share the same administrator or recovery channel, independence is overstated. The math is best used as a design test: list each failure domain first, then decide whether the keys deserve to be modeled separately.

Current reserve and fee mechanics

XORA queried Ripple's public Mainnet server with the documented server_info method on August 3, 2026. At validated ledger 106,040,988, the response reported a 1 XRP base reserve, a 0.2 XRP incremental owner reserve, a 0.00001 XRP base fee, and load factor 1. The official reserve documentation reports the same current reserve values. Validators can change reserve and base fee settings through consensus, so production software should query them rather than hardcode them.

A modern SignerList counts as one owner object regardless of whether it contains three signers or five. An otherwise empty account therefore has a 1.2 XRP reserve requirement after creating the list, before allowing for transaction fees. This reserve is not a payment to a third party. It is a minimum balance requirement, and removing the list releases its 0.2 XRP owner reserve. Rare lists created before the April 2019 MultiSignReserve activation can count as more objects until replaced.

The multisigned transaction fee is the base fee multiplied by one plus the number of signatures provided. At the current 10 drop base, two signatures require at least 30 drops, or 0.00003 XRP. Three require 40 drops, or 0.00004 XRP. The fee is destroyed, not paid to a validator, and load scaling can raise the required amount. All transaction fields, including Fee, Sequence or TicketSequence, and LastLedgerSequence, must be fixed before signatures are collected because multisigned transactions cannot be auto filled afterward.

Five controls that matter more than the threshold label

1. Eliminate hidden single key paths. A signer list can coexist with the master key and a regular key. If either remains usable, the account is not forced to use the threshold. Disabling alternatives can enforce multisignature, but it also makes loss of quorum an account recovery emergency.
2. Separate failure domains. Use distinct devices, backups, administrators, authentication systems, and physical locations. Avoid cloning one seed or recovery credential into several places and calling the copies independent signers.
3. Make every signer verify the full intent. Destination, destination tag, amount, fee, network, sequence, expiration, and memos are all signed. A hardware key cannot protect funds if its operator approves a malicious payload without reading it.
4. Collect only the signatures needed. Official XRPL guidance warns that extra signatures can make a transaction malleable, changing its identifying hash without changing its effect. Use one assembler, submit one final version, and monitor account sequence plus validated history, not only the expected hash.
5. Rehearse rotation and recovery. Test signer replacement, a missing participant, an expired transaction, and secure restoration on Testnet or a low value account. Record who can initiate, approve, assemble, submit, and reconcile each action.

What multisignature does not solve

Multisignature reduces dependence on one secret. It does not validate the business purpose of a payment, prevent a threshold of insiders from colluding, secure a compromised transaction builder, guarantee backups, insure custody, or recover funds sent to the wrong destination. It also does not make an investment return safe. Custody, counterparty, market, liquidity, operational, and regulatory risks remain.

For holders evaluating a service, ask which authorization paths are enabled, how signer independence is established, how changes are approved, how transactions are reconciled, and what happens when a signer disappears. Do not ask for private seed locations or operational details. Public controls, audit practices, incident response, and clear disclosures are more useful. XORA's public approach is summarized on the security page.

Put XRP to work with risk in view

Multisignature is one control inside a larger custody system, not a return guarantee. Before depositing anywhere, understand withdrawal rules, custody, liquidity, and counterparty exposure. Compare the ways to earn yield on XRP, model scenarios with the XRP yield calculator, and review the security disclosures.

Put your XRP to work with XORA and earn up to 22% APY value, never guaranteed, instead of leaving it idle on an exchange. The offer is framed as up to 22% APY value (15% native XRP yield, treasury-subsidised during a disclosed bootstrap, plus estimated XORA reward value). Rates and reward value are variable, losses are possible, and no outcome is guaranteed.