Deployment options
You choose where the signers run. Dfns supports three configurations:- Dfns Cloud
- Hybrid
- On-premise
Dfns manages all signers in our geographically distributed cloud infrastructure. This is the default and most popular option.
- All key shares are secured and stored by Dfns.
- Zero operational overhead for your team.
You can choose your preferred MPC threshold scheme. We recommend 3-out-of-5, but any configuration can be implemented (e.g. 2-of-3, 4-of-7).
Architecture
The signer network consists of the following components:| Component | Description |
|---|---|
| Signers | Dfns signer software instances that hold key shares and participate in MPC ceremonies (key generation and signing). Each signer runs as a container or standalone process. |
| Delivery server | Handles inter-signer communication during MPC ceremonies. In hybrid deployments, Dfns operates the delivery server. In full on-premise deployments, you host it. |
| Database | Stores encrypted key shares. Each signer has its own database instance, ensuring no signer can access another’s key shares and avoiding a single point of failure. |
| Encryption keys | Keys used to encrypt and decrypt key shares at rest. When hosting signers on-premise, you manage these encryption keys. In the Dfns Cloud model, Dfns manages them. |
Key generation
Distributed Key Generation (DKG) is the ceremony where signers collaboratively generate key shares without any single party ever holding the complete private key. All signers in the scheme must participate.- Your application requests a new wallet through the Dfns API.
- The API initiates a DKG ceremony by contacting each participating signer.
- Each signer generates its key share locally and communicates with other signers through the delivery server using mTLS.
- Once the ceremony completes, each signer persists its encrypted key share in its database.
- The public key is returned to your application.
Transaction signing
Only the threshold number of signers need to participate in a signing ceremony.- Your application submits a transaction through the Dfns API.
- The API initiates a signing ceremony with the required threshold of signers.
- Each participating signer retrieves its encrypted key share, decrypts it, and participates in the MPC signing protocol via the delivery server.
- The threshold signature is produced without any single signer holding the complete private key.
- The signature is returned to your application.
Threshold schemes
The threshold scheme (t-out-of-n) determines:
| Property | Effect |
|---|---|
| Signing availability | Only t out of n signers need to be online to sign. |
| Fault tolerance | Up to n - t signers can be offline without affecting operations. |
| Security | An attacker must compromise t signers to reconstruct a key. |
Add-on features
When running signers on your own infrastructure, additional features are available:- Validation gate: Add a pre-signing authorization step where your HTTP handler approves or rejects every transaction before the signer proceeds.
- Layer 4 disaster recovery: Automatically encrypt key share backups with your own public key and store them in your S3 bucket for independent recovery.