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, for the customer or for one wallet (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 400 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.

​
Admins

A business customer has exactly 2 admins; an individual customer has exactly 1. Every other roster member is a signer. Admins are the only role that approves a roster change (add, remove, replace an admin). The count is fixed at claim time: a business roster with fewer admins returns 400 ROSTER_BELOW_MIN_ADMINS, and one with more returns 400 ROSTER_ABOVE_MAX_ADMINS. Two admins make the roster recoverable: when one admin loses access, the other admin approves a replacement. An individual has one admin, the person, and recoverability comes from the person’s two passkeys. Every other member is an api_key signer. See Individual customers. The count never changes after the claim, so an admin leaves the role only when a signer replaces it:
  • Replace an admin. Promote a signer with demoteSignerId set to the admin it replaces. One ceremony makes the signer an admin and the admin a signer. The admin count and the governance approvals stay the same.
  • demoteSignerId is required: a promote without it returns 409 ROOT_AT_CAPACITY_SWAP_REQUIRED. It must name one of the customer’s admins (409 DEMOTE_TARGET_NOT_IN_ROOT otherwise).
  • A later add is always a signer: POST /wallet-signers with role: "admin" returns 409 ROOT_AT_CAPACITY_SWAP_REQUIRED.
  • Demoting an admin on its own returns 409 WOULD_BREAK_MIN_ADMINS, and removing an admin returns 409 SIGNER_IS_ROOT_MEMBER. Replace the admin first; it is then a signer that you can remove.
The customer’s admins alone can never clear a governance change: a Conduit approval is always required on top, and Conduit’s approvals alone are never enough either.

​
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. An override can be above or below the customer default. It applies to that wallet only. Your EVM wallets on different chains share one address, and an override on one of them does not change the threshold of the others. A payout from the wallet needs exactly the override’s number of approvals, and the customer default no longer applies to that wallet until you clear the override. A later change to the customer default does not change an override. One change at a time. A customer takes one signing-quorum change at a time, for the customer default or for any wallet. While a change waits for approval, a second change returns 409 WALLET_THRESHOLD_CHANGE_PENDING. Send it again after the first change is approved, declined or expires.

​
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 a third admin. A business has exactly two. Adding an admin or promoting a signer without demoteSignerId hits 409 ROOT_AT_CAPACITY_SWAP_REQUIRED: name the admin the signer replaces.
  • Demoting or removing an admin. Hits 409 WOULD_BREAK_MIN_ADMINS or 409 SIGNER_IS_ROOT_MEMBER. Promote a signer in place of the admin, wait for the ceremony to complete, then remove the former admin as a signer.
  • Sequential roster changes. Promote, add and 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.