A signer doesn’t have to be a person with a passkey. If Conduit has enabled a programmatic signing mode for your customer, your backend can hold a signing key and approve payouts server-to-server, with no browser and no human. See Signing modes for the three modes and Programmatic payout signing for the machine flow.
Choosing your signing threshold
Customers provision non-custodial wallets via theclaim-non-custodial endpoint. A business customer’s roster has exactly two admins; an individual customer’s roster has exactly one admin (see Individual customers). You choose the M-of-N signing threshold: as low as 1 (a single stamp clears each payout) or higher for multi-party approval.
Every business wallet is a roster of exactly two admins plus any number of signers; the signing threshold M is what you choose. Threshold 1 clears on a single stamp, higher thresholds need M stamps. The passkey columns above describe the passkey-required signing mode; in a programmatic signing mode, signers (and, in the unattended variant, admins) can be machine API keys instead; see Signing modes.
Individual customers
An individual customer can hold a self-managed wallet. Its roster has exactly one admin and at most one person:- With the person. The person is the member under the email on file for the individual, with
role: "admin"andcredentialType: "passkey". That member is the only admin. Every other member is anapi_keymember withrole: "signer", so your server can sign payouts for the customer. - Without the person. Under the programmatic unattended signing mode only, the roster can be all machine keys: one
api_keyadmin, and every other member anapi_keysigner.
api_key members are the same as for a business, with one difference: an individual’s wallet has one admin, so a roster with the person and an api_key admin is refused, also under programmatic unattended. signingThreshold is at least 1 and at most the roster size. Any other roster (a second person, a second admin, a person who is not the admin, a person under another email) returns 422 INDIVIDUAL_ROSTER_INVALID. After the claim the roster can only gain api_key signers: a POST /wallet-signers for a passkey member or an admin, and a promote to admin, return the same error.
- Two passkeys. The person enrolls two passkeys, for example on a phone and a laptop, before the wallet activates. With one passkey the person stays
activating, the claim staysprovisioning, and the person cannot approve a payout. The second passkey is the recovery path: one lost device does not lose the funds. - One admin, one Conduit approval. A governance change needs the admin and Conduit. Conduit cannot sign a payout or change the wallet alone, and the customer cannot change the wallet’s governance alone.
Concepts
Roster. The ordered list of named signers attached to a customer’s non-custodial setup. Each signer has an email, a role (admin or signer), and a credential: passkey members enroll passkeys (plain signers one, admins two on two separate devices; see Backup passkeys), while machine (api_key) members carry a registered compressed public key — P-256 by default, or secp256k1 when the member selects a secp256k1 / secp256k1_eip191 signatureScheme — and enroll nothing. The email identifies and dedups the signer. Conduit never contacts the signer directly; distributing each signer’s enrollment link is your responsibility (see Lifecycle endpoints below). Roster size and threshold are decoupled: a 5-member roster can require 2 stamps; a 2-member roster can require 2.
The customer’s signing mode constrains the roster, both at claim time and on later adds: api_key members are rejected in the passkey-required mode, and an api_key member with role: "admin" is rejected outside the unattended mode, both with 422 SIGNING_MODE_ROSTER_INVALID. The mode limits api_key members only. Passkeys count toward signingThreshold in every mode, so an all-passkey roster is valid in either programmatic mode.
Threshold. The integer M in M-of-N. Every payout collects stamps until M are recorded, then auto-broadcasts. The threshold is set at claim-non-custodial time and can be adjusted later via the signing-quorum endpoints. See Signing thresholds for the constraints.
Admin vs signer. These are the only two roles. Both stamp payouts; only admins approve roster and governance changes (add or remove a signer, replace an admin, change the threshold). A business has exactly 2 admins and an individual 1, chosen at claim time, so you can never lock yourself out.
Governance. The customer’s signing setup itself (the roster, the threshold, the underlying keys) changes only with the customer’s admins and a Conduit approval together. The admins alone can never clear a governance change, and Conduit alone can never clear one either; that is the governance veto.
Ceremony. A short-lived background flow that replaces an admin (on promote) or rolls the roster (on add/remove). A change that conflicts with one already in flight returns 409 CEREMONY_IN_FLIGHT; retry after it completes. You see this surface as: a promote returns 202 Accepted and the change shows up after the ceremony completes.
Roster changes and the payout threshold are separate. Adding or removing a signer takes a single admin approval, no matter what signing threshold you set. Your signingThreshold governs only how many stamps a payout needs; it does not change how many admins must approve a roster change. So a one-admin approval on an add or remove is expected even on a wallet that requires several stamps per payout; the two settings are independent.
Ghost-vote scrubbing. If a signer is removed while a payout is sitting at the quorum gate, that signer’s already-cast stamps are scrubbed from every in-flight payout for the customer. Affected payouts re-fire transaction.signature_collected with the new count; payouts that can no longer reach quorum on the new roster terminate with failureCode: "roster_changed" so clients can re-submit against the current roster.
Backup passkeys
A plain signer enrolls with one passkey; an admin enrolls two, on two separate devices, so losing one device never costs an admin the role. The second passkey is what makes a lost device recoverable: an admin who still holds one passkey replaces the lost one through Recovery. The Conduit-hosted signer profile athttps://app.conduit.financial/signer-profile is one stable page for every signer, with no per-signer token, that you can publish to your whole roster: an admin opens it, signs in with the passkey they still hold, and starts that recovery. Conduit never contacts signers directly.
Because an admin must hold two passkeys, a plain signer has to add a second passkey before it can be promoted to admin.
Recovery
Recovery replaces a passkey that an admin lost, without re-onboarding the customer or re-claiming the wallet. It needs the passkey that the admin kept. Such an admin always holds two passkeys, so they, and an individual customer’s one person, can recover after losing one device. To recover any other signer, contact Conduit support: the start answers409 RECOVERY_REQUIRES_ROOT_ADMIN.
- Start the recovery with
POST /v2/customers/{customerId}/wallet-signers/{signerId}/recovery, or the signer starts it from their signer profile. The response andwallet_signer.recovery_openedcarryverificationUrl, the signer’s recovery link. Deliver it to the signer. A repeat call with a newidempotency-keyreturns the same open recovery with a live link. - On the link the signer creates the new passkey, then confirms twice with the passkey they kept: once to add the new passkey and once to remove the lost one.
- Those confirmations are the admin approval, so no other admin has to approve.
- Conduit co-approves after a cooling-off period of about 20 hours from the start, adds the new passkey, then removes the lost one:
wallet_ceremony.completed. The signer keeps their role and their other passkeys.
POST /v2/customers/{customerId}/wallet-signers/{signerId}/recovery/cancel stops a recovery the signer did not ask for. Conduit refuses high-risk patterns, such as a second recovery for the same signer within 30 days (409 RECOVERY_UNAVAILABLE at the start). wallet_ceremony.failed reports a recovery that was declined, cancelled, expired, or refused by a risk check. A signer who lost every passkey cannot use the recovery link; contact Conduit support.
Recovery changes no roster membership, so wallet_signer.added and wallet_signer.removed do not fire. For a business, when an admin can no longer be recovered directly, the other admin approves a replacement: promote a signer with demoteSignerId set to the lost admin (see Replacing an admin). An individual customer has no second admin, so when its person lost every passkey, contact Conduit support.
Replacing an admin
A business has exactly two admins, so you never add an admin: a signer becomes an admin only in place of one of the two, in one ceremony. Worked example. A customer claims with two admins, Ada and Grace, plus a signer, Ken. Later they want Ken as an admin instead of Grace. Promote Ken withdemoteSignerId = Grace’s signer id. One ceremony makes Ken an admin and Grace a signer: wallet_signer.promoted fires for Ken and wallet_signer.demoted for Grace. The customer still has two admins (Ada and Ken), and the threshold is unchanged.
A promote without demoteSignerId returns 409 ROOT_AT_CAPACITY_SWAP_REQUIRED; a demoteSignerId that is not one of the customer’s admins returns 409 DEMOTE_TARGET_NOT_IN_ROOT. To remove Grace afterwards, remove her as a signer.
Lifecycle endpoints
For the quorum-threshold endpoints (per-customer + per-wallet overrides) see Signing thresholds.
Sandbox simulators
The signing and enrollment levers (
mark-enrolled, simulate-stamp, simulate/cosign on payouts and on orders, setup-stamp, ceremony-stamp) are not available on this sandbox: each signer enrolls through the invite verificationUrl, or the roster uses machine signers.