Skip to main content

Introduction to co-signing

Co-signing, often referred to as multi-signature (multi-sig), provides an enhanced layer of security for blockchain transactions. It requires approvals from multiple parties before a transaction can be executed. This guide details how to implement a 2/2 co-signing setup using Turnkey, where both the end-user and your application backend (via API key) must approve transactions.
See the with-cosigning example for a full working implementation using Next.js, OTP login, SSE webhooks, and a 2-of-2 root quorum.

Co-signing architecture

The following diagram illustrates the setup and transaction flow for a co-signing wallet managed by Turnkey and your backend application:

Implementation steps

1

Create a Sub-Organization with Multiple Root Users

To set up a multi-sig wallet in Turnkey, you first need to create a sub-organization with two root users. This sub-organization will function as a separate entity with its own wallet and security settings.The key configuration here is setting up:
  • A root user for the end-user, authenticated with their passkey
  • A root user for your application service, authenticated with an API key
  • A root quorum threshold of 2, requiring both users to approve critical operations
This creates a true multi-sig arrangement where neither party can unilaterally control the wallet. The following code shows how to implement this setup on your backend:
2

Client-Side Transaction Initiation

When the user wants to sign a transaction using their multi-sig wallet, they need to initiate the process from your frontend application. This step involves:
  • Authenticating the user with their passkey (handled automatically by Turnkey)
  • Creating a transaction signing request to Turnkey
  • Receiving an activity fingerprint that needs further approval
  • Forwarding this fingerprint to your backend for the second signature
The transaction won’t be fully signed yet - it will be in a CONSENSUS_NEEDED status until your backend approves it. Here’s how to implement this flow in your frontend:
3

Backend Activity Approval

Your backend needs an endpoint to receive the activity fingerprint from the frontend and approve it using its own API key.
The quorum is symmetric — the backend can also initiate signing (vote 1) and the user approves (vote 2). See the with-cosigning example for a full walkthrough of both flows.

Security considerations and best practices

  • Validation Before Approval: Always validate transaction details (recipient, amount, etc.) before approving activities.
  • API Key Security: Protect your backend service’s API key.
  • Authorization: Ensure the authenticated frontend user is authorized for the subOrgId they are interacting with.
  • Webhooks: Use Turnkey Webhooks to get notified about activity status changes (e.g., when a transaction is fully signed and confirmed).