> ## Documentation Index > Fetch the complete documentation index at: https://v2.docs.conduit.financial/llms.txt > Use this file to discover all available pages before exploring further. # Signing thresholds > How M-of-N thresholds, minimum-admin floors, and per-wallet overrides work together on multi-signer non-custodial wallets. A multi-signer customer has two separate constraints that govern who can do what. They are independent: changing one does not satisfy the other. This page covers both. For the broader multi-signer mental model see [Multi-signer wallets](/concepts/multi-signer-wallets). For the payout-side walkthrough and roster ceremonies see [Multi-signer wallets recipe](/sandbox/multi-signer-wallets#the-6-step-recipe). ## Threshold (M-of-N) The number of stamps any single payout needs to reach quorum and broadcast. Set per customer at claim time as `signingThreshold`. A 5-member roster with `signingThreshold: 2` collects 2 stamps and proceeds; a 3-member roster with `signingThreshold: 3` requires all three. The threshold can be adjusted later via the signing-quorum endpoints. Per-wallet overrides are allowed, with one constraint (see [Per-wallet overrides](#per-wallet-overrides) below). **Constraints:** * Threshold must be between `1` and the number of `active` signers. * Raising the threshold above the active signer count returns `422 THRESHOLD_EXCEEDS_ROSTER` (at claim time) or `422 QUORUM_THRESHOLD_EXCEEDS_SIGNERS` (on a quorum update). * Lowering the threshold below `1` is rejected at the DTO layer. ## Minimum admins The floor on how many `admin` signers must remain at all times. Admins are the only role that can change the roster (add, remove, promote, demote). The floor is enforced on every roster mutation and on every demote: an attempt that would drop the admin count below the floor returns `409 WOULD_BREAK_MIN_ADMINS` (or `422 ROSTER_BELOW_MIN_ADMINS` at claim time). The current floor is **2 admins**. The reason is recoverability: with a single admin, losing access to that admin's passkey would lock you out of the roster permanently. Two admins means the roster can always swap one of them out for a fresh admin if the other is compromised or unavailable. Demoting a root admin always triggers a root-quorum ceremony, even when the floor would still be satisfied. Removing an admin directly is rejected with `409 SIGNER_IS_ROOT_MEMBER`: you must demote first, then remove. ## The root quorum is fixed The governance layer that protects the signing setup — the **root quorum** — holds a fixed number of customer seats: **two**. The customer chooses which two of their admins hold those seats at claim time. Additional admins are fully-fledged admins who can co-approve governance changes, but they do not hold a root seat (they are non-root admins). Because the root quorum is fixed, you cannot grow it. Promoting a signer or non-root admin into the root quorum is a **seat swap**: a single ceremony that seats the new admin and unseats an existing root admin at the same time. This is the only way to change who holds a root seat. * The promote endpoint takes an optional `demoteSignerId` naming the current root admin to unseat. * When both root seats are already filled, `demoteSignerId` is **required** — promoting without it returns `409 ROOT_AT_CAPACITY_SWAP_REQUIRED`. * `demoteSignerId` must name a current root-quorum admin (`409 DEMOTE_TARGET_NOT_IN_ROOT` otherwise), and the swap must leave at least 2 admins on the roster (`409 SWAP_WOULD_BREAK_F12` otherwise). The root quorum always needs all but one of its members to approve a change, and only two of those members are the customer's. So the customer's admins alone can never clear a governance change — a Conduit approval is always required on top. That is the governance veto, and a fixed root keeps it intact through every seat swap. ## How the two constraints compose | Scenario | Threshold check | Min-admin check | Outcome | | -------------------------------------------------------------------------------- | --------------- | ---------------------------------------------- | ------------------------------------------ | | Claim with 3 signers, threshold 2, 2 admins | Pass (2 ≤ 3) | Pass (2 ≥ 2) | Accepted | | Claim with 3 signers, threshold 2, 1 admin | Pass | Fail | `422 ROSTER_BELOW_MIN_ADMINS` | | Claim with 3 signers, threshold 4, 2 admins | Fail | Pass | `422 THRESHOLD_EXCEEDS_ROSTER` | | Remove signer when 2 admins, 3 total, threshold 2 | n/a | Pass (2 admins remain if target is a signer) | Accepted | | Remove admin when 2 admins, threshold 2 | n/a | Block (direct remove on admin) | `409 SIGNER_IS_ROOT_MEMBER` (demote first) | | Demote a root admin at the default 2 root seats | n/a | Fail (would drop root below 2 customer admins) | `409 WOULD_BREAK_MIN_ADMINS` | | Demote a non-root admin (3 roster admins, 2 in root) | n/a | Pass (root untouched, 2 roster admins remain) | Accepted, tag-only | | Promote a signer while both root seats are filled, no `demoteSignerId` | n/a | n/a | `409 ROOT_AT_CAPACITY_SWAP_REQUIRED` | | Promote a signer with `demoteSignerId` = a current root admin (3+ admins remain) | n/a | Pass (≥ 2 admins after swap) | Accepted, seat swap runs one ceremony | ## Per-wallet overrides A customer can set a different threshold on a specific wallet. Use this when one wallet holds higher-value assets that should require more signatures than the customer default. **One-way constraint:** a per-wallet override may only **lower** the threshold relative to the customer default. Raising via override returns `422 QUORUM_WALLET_OVERRIDE_CANNOT_RAISE`. The reason is policy composition at the signing layer: the customer-default and per-wallet policies are evaluated in parallel, and the effective threshold is the lower of the two. A raise-above-default override would be silently under-enforced because the default still passes at the lower count. This constraint goes away once the customer-default policy is rewritten to exclude override wallets. Until then, design your override scheme around the one-way rule. ## Common pitfalls * **Threshold of 1 on a multi-signer claim.** This is allowed, and it collapses the multi-signer surface back to "any one signer can release." Useful for testing; not what most teams want in production. * **Expecting to add a third root seat.** The root quorum holds exactly two customer seats. Promoting a new admin into the root quorum while both seats are filled hits `409 ROOT_AT_CAPACITY_SWAP_REQUIRED` — pass a `demoteSignerId` to swap out a current root admin instead. * **Demoting the second-to-last admin.** Hits `409 WOULD_BREAK_MIN_ADMINS`. Promote another signer into the root quorum first (via a seat swap if both seats are filled). * **Removing an admin without demoting.** Hits `409 SIGNER_IS_ROOT_MEMBER`. Demote, wait for the ceremony to complete, then remove. * **Sequential roster changes.** Promote/demote/add/remove all go through ceremonies, and ceremonies run sequentially per customer. A second mutation while the first is still in flight returns `409 CEREMONY_IN_FLIGHT`. Retry with a short backoff.