Signing modes

A non-custodial wallet releases funds only when a signing quorum approves. The customer’s signing mode decides who on your side can produce those approvals: people with passkeys, your servers with server-held keys, or a mix. This page sets out the three modes and what each one commits you to. Conduit sets the mode for each customer. New production organizations start in programmatic, earlier ones in passkey required; new sandbox organizations start in programmatic unattended. To confirm or change a customer’s mode, ask your Conduit representative. A customer’s wallets keep the mode they were claimed with.

​

What never changes

Whichever mode you pick, these hold:

• Conduit is always a required co-approver. Reaching your own signing threshold is necessary but never sufficient: Conduit’s compliance approval is the final vote on every payout, and it is cast last.
• Conduit can never move funds without you. Conduit holds no seat in your signing quorum and cannot reach it alone. Neither side acts alone, in any mode.
• You hold your private keys. Conduit receives public keys only. This is true of passkeys and of server keys alike; the custody position is identical in all three modes.
• At least two administrators. The minimum-admin floor on your side of the roster does not change with the mode.
• No gas to manage. Network fees are sponsored; the wallet never holds a native-coin balance.

The modes differ in one thing only: how much of your side of the approval is automatic.

​

The three modes

​

What each mode commits you to

​

Passkey required

Every payout waits on a person. That is the control, and it is also the constraint: each approval attempt has a signing deadline (the expiresAt on the transaction.awaiting_signature event; always drive your timers off that value), and a window that lapses without quorum is rebuilt and re-offered a limited number of times before the payout fails. Volume and time-zone coverage are the questions to ask here. This mode suits low-volume, high-value, deliberately reviewed flows.

​

Programmatic

Payouts can clear at machine speed; changes to who can sign still need a human passkey. Two facts shape your roster:

• Machine and human approvals count the same. Any active signer’s approval, machine or passkey, counts toward the threshold. The mode sets no minimum number of machine signers: a roster of only passkeys is valid, and so is one where the passkeys are needed to reach the threshold. The only threshold rule is the one every mode has: the active signers together must be able to reach it.
• The threshold decides whether a person must approve. When your machine signers alone can reach the threshold, a payout can clear with no human. When the threshold is higher than your number of machine signers, every payout needs at least one passkey approval.

A machine signer cannot be an administrator in this mode. Administrators are passkey holders, so governance (adding or removing a signer, changing the threshold) always comes back to a person.

​

Programmatic unattended

The mode requires no human on your side of any decision, including governance. Your key management becomes your control environment: anyone who can use those keys can approve payouts up to your threshold, and can change the roster. Conduit’s compliance approval still stands between that and money moving; when your machine signers alone can reach the threshold, nothing on your side does. New sandbox organizations start in this mode, because sandbox moves no real value. On live, Conduit enables it per customer only after an additional approval review; plan for that review before you build against it.

​

Operational facts for both programmatic modes

• You generate the keypair; Conduit gets the public half. A 33-byte compressed public key, on the curve of the signer’s signatureScheme: P-256 by default, or secp256k1 for a secp256k1 or secp256k1_eip191 signer. There is no private-key field on any endpoint.
• Your raw approval signature is never stored. Conduit relays it and discards it, keeping an audit record of what was signed and which key signed it.
• A single rejection is terminal. Any one signer, machine or human, declining a payout ends it. It cannot be revived by another approval.
• Re-submitting an approval is safe. A retry returns the request’s current state, never a double count. The approve and reject calls require an Idempotency-Key header: a missing key is refused with 400, and reusing a key with a different body returns 409.
• Approval windows expire. If a window lapses before quorum, the request is rebuilt with a new signingRequestId and your servers must stamp the new one. Handle the second webhook, not just the first.
• Containment is a removal, not a setting. If a key is compromised, remove it at once when the other active signers can still reach the threshold. Otherwise seat a replacement signer first, then remove the compromised one. Each step is a governance change under an admin approval. A removal that would leave the active signers unable to reach the threshold is refused with 403 SIGNER_REMOVAL_FORBIDDEN, and the minimum roster (active signers = threshold) is always in that position. Once the removal is accepted, that key’s signatures stop being accepted immediately. Changing the signing mode does not deactivate a live machine signer; planned key rotation is the same add-then-remove sequence.

The signing loop itself (generate the key, register it, discover requests, stamp them) is in Programmatic payout signing.

​

Which mode fits

• Need a person to see every payout: passkey required.
• Need payouts to clear without waiting on a person, but want people to control who can sign: programmatic.
• Need a signing path with no human step at all, and can evidence the key controls to justify it: programmatic unattended.

The mode is fixed for each customer at claim time, so decide before the customer claims. A mode change arranged with Conduit applies to customers who claim after it; for a customer that has already claimed, talk to your Conduit representative.

​

Related