Skip to main content
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. For the payout-side walkthrough and roster ceremonies see Multi-signer wallets 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 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

​
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.