A fintech team has launched onchain payouts. The MPC ceremony completed, the wallet is funded, and the API returns a signing request. Then a withdrawal is rejected at 3 a.m. Operations asks who can approve it. Security asks which service owns the key share. Compliance asks for the policy decision and audit trail. Engineering discovers that everyone understands the threshold protocol, but nobody owns the co-signer.
That gap is the practical meaning of the responsibilities of a co signer. In lending, a co-signer can be pursued for repayment. In MPC infrastructure, the co-signer is the threshold party responsible for participating safely, enforcing policy, remaining available, recording evidence, and recovering without reconstructing a private key. The technology may be distributed, but accountability still needs a named owner.
Table of Contents
- Why Teams Need a Named Co-Signer Role
- What a Co-Signer Actually Does in MPC
- Core Duties Every Co-Signer Owns
- Client-Controlled vs Vendor-Controlled Co-Signers
- Co-Signer Responsibilities in a Non-Custodial Flow
- Risks, Controls, and Common Failure Modes
- Operational Checklist and Buyer FAQ
Why Teams Need a Named Co-Signer Role
The first production incident usually exposes the problem. A transaction fails because the co-signer is offline, a destination falls outside an allowlist, or a policy bundle has drifted from the version approved by compliance. The system has behaved correctly, but the team can't answer the operational questions quickly enough: who investigates, who can pause signing, who can rotate a share, and who explains the decision to an auditor?
A threshold protocol doesn't assign those duties automatically. Engineering may own the MPC library, security may own the host, operations may own payout queues, and compliance may own transaction rules. Without a documented boundary, each team assumes another team is responsible for the co-signer's behavior.
Liability needs an owner
A named co-signer owner should appear in the runbook, service catalogue, incident matrix, and vendor contract. That owner doesn't need to be one person permanently operating a node. It can be a service team with an on-call rotation, provided the accountabilities are explicit.
The owner should be able to answer five questions without reconstructing the system from logs:
- Who operates it: Which team owns deployment, uptime, patching, and operator access?
- Who controls policy: Who approves allowed chains, assets, destinations, limits, and emergency pauses?
- Who receives alerts: Which escalation path handles quorum failure, suspicious requests, and signing latency?
- Who proves execution: Which immutable records show the request, policy result, partial signature, quorum event, and broadcast?
- Who leads recovery: Which people can initiate share refresh, restore service, or perform a documented backup ceremony?
A co-signed financial obligation creates direct exposure, not merely a courtesy promise. The FTC guidance on co-signing loans explains that a co-signer can be equally responsible for repayment, and may be pursued without the lender first exhausting collection efforts against the primary borrower. The MPC analogy is operational rather than legal, but the lesson is similar: the supporting party isn't a passive backup.
Practical rule: If nobody's name appears beside uptime, policy, audit, and recovery, the co-signer isn't operationally owned.
The rest of the design follows from that rule. Define what the co-signer does, assign each duty, select the control model, and test the failure path before a customer depends on the withdrawal flow.
What a Co-Signer Actually Does in MPC
A useful anchor is a 2-of-3 MPC scheme. Three parties hold separate key shares. The private key never exists as a complete value on one machine. A valid transaction signature requires cooperation from any two permitted parties, so one unavailable or compromised party shouldn't be able to sign alone.
The co-signer is one of those threshold parties. It might be a service in the client's environment, an HSM-backed process, or a vendor-operated node. It isn't the wallet itself, and it doesn't hold customer funds as a conventional custodian. It holds a key share and performs defined protocol and policy work.
The co-signer's protocol duties
During distributed key generation, the co-signer creates or receives its share through the ceremony and persists it in its protected environment. During signing, it validates the signing session, contributes its share of the cryptographic protocol, and returns a partial result only when the request satisfies the rules assigned to it.
The responsibilities are easier to understand as a sequence:
- Participate in key generation: The co-signer joins DKG without exposing a complete private key.
- Protect its share: It stores the share using controls such as an HSM or secure enclave, with restricted operator access.
- Validate the request: It checks authentication, policy version, network, asset, recipient, amount, and session context.
- Run the signing round: It performs its cryptographic contribution and rejects malformed or unauthorized sessions.
- Persist evidence: It records the request, decision, protocol outcome, and relevant identifiers for later review.
- Support lifecycle operations: It participates in share refresh, rotation, suspension, and recovery ceremonies.
The distinction between holding a share and operating a co-signer is critical. A stored share that never checks policy is only a cryptographic component. A production co-signer must also be an enforcement point and an auditable service.
For a broader explanation of wallet architecture, see the MPC wallet design overview. It helps separate wallet interfaces, policy services, signing participants, broadcast, and ledger systems that teams often bundle together under the word “wallet.”
A co-signer also needs clear boundaries. It shouldn't unilaterally change transaction rules, bypass authentication, or approve a request because another service says it is urgent. Its authority comes from the signing policy and quorum design, not from informal access to an operator console.
Core Duties Every Co-Signer Owns
A production co-signer carries six distinct accountability lines. Each line has its own failure mode, evidence requirements, and operational owner. Treating the role as a single configuration item leaves gaps that appear during incidents, audits, or recovery.
Custody
The co-signer owns the secure lifecycle of its key share, from generation and protected storage through access control, backup ceremonies, refresh, rotation, and retirement. An HSM or secure enclave can protect share material. The operating team still must document who may invoke signing, which controls apply, and how each lifecycle event is approved.
Exposure often begins outside the signing service. A share copied into a build artifact, debug log, developer laptop, or unmanaged backup can weaken the threshold design. Custody therefore includes storage boundaries, operator permissions, and evidence that old or replaced material is no longer usable.
Signing policy
Before contributing its partial signature, the co-signer evaluates the transaction context. Inputs can include the chain, asset, destination, contract, amount, velocity, approval state, emergency pause, and compliance outcome.
Syntax validation alone cannot enforce business intent. The policy layer must apply the rules that determine whether the transaction is permitted, then preserve the exact policy version used for the decision. That record lets an investigator connect an approval to the rule set active at signing time.
Availability
A co-signer that cannot participate can stop the quorum. Its owner manages uptime, health checks, capacity, latency, maintenance windows, and graceful degradation. Redundant nodes and tested failover provide stronger protection than a nominal availability statement because an authorized withdrawal must still complete during an infrastructure fault.
Dependency behavior belongs in this duty. A healthy node can still freeze the signing path if it waits indefinitely for a policy service, authentication provider, or network route. Timeouts, clear failure states, and operational ownership prevent those dependencies from becoming silent blockers.
Security
The security boundary covers the host, runtime, dependencies, operator identities, deployment pipeline, and monitoring stack. Controls should include workload identity, strong operator authentication, least privilege, patch management, tamper monitoring, supply-chain review, and data-loss prevention around share material.
Monitoring should cover more than successful signatures. Unusual policy queries, repeated rejected requests, unexpected deployment changes, and attempts to access protected storage can expose misuse before a signing event becomes a larger incident.
Auditing
The co-signer must produce evidence that explains the decision. Logs should connect signing intent with its authentication result, policy decision, policy version, partial-signature event, quorum result, and broadcast outcome.
Records should be append-only or otherwise protected against alteration. A trail containing only the final transaction hash cannot show why the co-signer approved the request, which identity initiated it, or which policy governed the decision.
Recovery
Recovery restores threshold operation without reconstructing the full private key. The runbook should cover share refresh, replacement of a failed host, social or institutional backup ceremonies, quorum changes, emergency pauses, and controlled re-enrolment of a new co-signer.
Recovery exercises should include both a dead host and a suspected compromise. A backup that has never been tested remains an assumption rather than a working control.
| Duty | What the Co-Signer Owns | Primary Failure Mode |
|---|---|---|
| Custody | Share generation, protected storage, lifecycle, and rotation | Share exposure or uncontrolled reuse |
| Signing policy | Transaction checks and policy-version enforcement | Unauthorized or non-compliant signing |
| Availability | Node health, quorum participation, and failover | Frozen withdrawals |
| Security | Host, identity, pipeline, and monitoring controls | Exfiltration or operator compromise |
| Auditing | Immutable signing and policy evidence | Inability to prove a decision |
| Recovery | Share refresh, replacement, and disaster procedures | Prolonged outage or unsafe reconstruction |
Client-Controlled vs Vendor-Controlled Co-Signers
The deployment model changes who carries the operational burden. In a client-controlled model, the customer runs the co-signer in its own VPC or HSM-backed environment. The customer retains direct control of the share, policy enforcement, deployment pipeline, logs, and recovery procedures.
In a vendor-controlled model, the provider hosts the co-signer as a managed service. The client reduces infrastructure work, but must demand evidence about node operation, key ceremonies, policy execution, incident handling, and recovery. Vendor operation doesn't necessarily mean the vendor holds the complete key or has unilateral signing power. It does mean the vendor must answer when its node is unavailable or its share environment is compromised.
| Responsibility Area | Client-Controlled Co-Signer | Vendor-Controlled Co-Signer |
|---|---|---|
| Key-share storage | Client's protected environment | Vendor's protected environment under contract |
| Policy enforcement | Client deploys and governs rules | Vendor operates enforcement, client defines or approves scope |
| Key refresh | Client schedules and executes ceremony | Vendor performs or coordinates ceremony |
| SOC 2 reporting | Client provides its own control evidence | Vendor supplies relevant reports and mappings |
| Disaster recovery | Client owns topology and recovery test | Vendor owns service recovery, client validates obligations |
| Incident accountability | Client leads technical response | Vendor leads platform response, client handles product impact |
The control question is more useful than the custody label. Ask who can approve a new destination, pause signing, alter a policy bundle, rotate a share, access logs, and declare an incident. Sokko's granularity best practices offer useful context for designing permissions narrowly enough that these powers don't collapse into one administrative role.
A self-custodial DeFi product often fits a client-controlled co-signer when the team can operate secure infrastructure and needs direct policy authority. A regulated custodial offering may prefer a vendor-controlled service for managed operations, but only with clear evidence, contractual responsibilities, audit access, and incident SLAs. The non-custodial meaning explained for product teams is useful here because non-custodial architecture doesn't remove operational responsibility. It redistributes it.
Co-Signer Responsibilities in a Non-Custodial Flow
Consider a user withdrawing USDC from a self-custodial MPC wallet. The user controls the wallet relationship, but the product still needs a safe signing path. The co-signer is where authentication, transaction policy, threshold participation, and evidence meet.
The withdrawal path
The user initiates the withdrawal. The application creates a signing intent containing the network, asset, destination, amount, nonce context, and authenticated user or agent identity. The co-signer receives a request identifier rather than an informal instruction.
The co-signer authenticates the request. It verifies the required authentication factor or trusted service identity. A request from an unapproved session, stale credential, or unknown workload should stop before cryptographic participation.
The policy engine evaluates the transaction. It checks the destination allowlist, supported contract, amount threshold, velocity rule, chain identifier, asset, approval state, and any compliance-related result. The co-signer can approve, reject, or route the request to manual review.
The signing protocol runs. Another MPC party and the co-signer exchange protocol messages. Each contributes only its share-based computation. The complete private key isn't assembled on the co-signer, the other party, or an operator workstation.
The transaction is aggregated and broadcast. The fully signed payload is assembled and sent to the network. WebSocket events should report policy outcomes, signing progress, broadcast status, and confirmation state so operations doesn't infer success from a missing error.
The co-signer records evidence. The audit record links the request, identity, policy version, decision, protocol session, transaction hash, and broadcast outcome. Finance can reconcile the result against the operating ledger instead of relying on a wallet screen.
A deposit follows a different path. The co-signer may participate in address derivation and quorum bookkeeping, but it doesn't sign the inbound transfer. The system should still emit deposit-observed and deposit-confirmed events, record the movement in the ledger, and reconcile the expected address with the account or user.
Autonomous signing needs stronger boundaries
An AI agent payout replaces human MFA with an approved workload identity and policy envelope. The co-signer checks the agent's scope, destination set, transaction limits, and action context before signing. The agent can request a payment, but it shouldn't be able to expand its own permissions or alter the policy that judges the request.
Idempotency is part of co-signer responsibility too. A retry must preserve the original intent or receive a clear duplicate result, not create a second valid payout. Bind the request to a unique identifier, nonce, chain, and policy version, then make every state transition observable through events and ledger records.
Risks, Controls, and Common Failure Modes
The passive-key-share mental model fails in production. The co-signer can be cryptographically unable to sign, operationally willing to sign the wrong transaction, or technically healthy while its evidence and policy state are unusable.
Reliability and quorum
A node outage can halt withdrawals even when the application, wallet interface, and blockchain are healthy. Use redundant, geographically separated nodes, health monitoring, bounded retries, and an explicit degraded mode. Operators should know whether the system rejects new requests, queues them, or pauses all signing when quorum isn't available.
Network latency creates a related failure. Signing sessions need timeouts, correlation IDs, and safe retry behavior. A timeout must not leave the team guessing whether the transaction was rejected, partially signed, broadcast, or merely missing an event.
Share and policy compromise
A compromised CI/CD pipeline can expose share material or deploy code that changes signing behavior. Protect shares with hardware-backed wrapping, restrict production deployment authority, scan artifacts and logs for sensitive material, and monitor unusual access patterns.
Policy drift is quieter and often more dangerous. Use signed policy bundles, version pinning, approval workflows, and a record of the exact bundle evaluated. Bind the signing payload to the intended chain ID, nonce, asset, and contract so a valid signature can't be reused in a different context.
The accounts payable workflow best practices from Loopfour provide a useful comparison for approval separation, evidence, exception handling, and reconciliation. Those controls apply to crypto payouts even when the final approval is a threshold signature.
Teams have also faced threshold wallet outages and share-leak incidents that required emergency key refreshes. The relevant lesson isn't that MPC removes risk. It limits unilateral authority only when operators protect each share, enforce quorum rules, and maintain recovery procedures.
Use an audit workflow process that connects technical events to business decisions. A co-signer's negligence should be discoverable in records, not dismissed as an abstract cryptographic failure.
Operational Checklist and Buyer FAQ
Before selecting or deploying a co-signer, put these items into the runbook and vendor questionnaire:
- Name the owner: Assign uptime, policy, security, audit, and recovery responsibilities.
- Verify the SLA: Define quorum behavior, event delivery, maintenance handling, and incident escalation.
- Test key lifecycle: Document DKG, share refresh, rotation, revocation, and host replacement.
- Pin policy versions: Require approvals, signed bundles, and evidence for every decision.
- Connect the records: Reconcile WebSocket events, signing sessions, transaction hashes, and ledger entries.
- Test failure paths: Simulate node loss, policy rejection, duplicate requests, and suspected share compromise.
Buyer questions
Who owns co-signer uptime? The party named in the SLA and runbook. Don't accept “the platform” as an answer. Identify the team, escalation path, and quorum behavior.
What proves the co-signer signed? Request correlated evidence for the policy decision, protocol session, partial-signature event, final transaction hash, and broadcast result.
What happens if the host dies? A tested share-recovery or refresh procedure should replace the host without reconstructing the full private key.
Who owns KYC-relevant policy decisions? The contract should state whether the client defines and approves the rules, the vendor enforces them, or both share responsibility.
How should buyers compare MPC providers? Compare control boundaries, policy evidence, recovery tests, event semantics, ledger reconciliation, and incident obligations. Protocol terminology comes after those operational answers.
BroLabel provides embedded MPC wallets, a client-controlled Co-Signer through BROsettlement, policy-aware signing, WebSocket events, an append-only operating ledger, reconciliation support, and AI agent wallets with role-based controls. If your team is turning the responsibilities of a co signer into a production runbook, visit BroLabel to evaluate the infrastructure and move from sandbox design to a controlled launch.
