How does Dfns’s infrastructure work?

Each API call initiated by a client (aka a request to create keys or sign transactions) prior to reaching the key management network will go through a Dfns’s infrastructure composed of a sequence of cloud-based microservices. These microservices are designed to ensure the scalability and availability of various functions like message queuing, lambdas, gateways, elastic search, and over 20 other services. While predominantly relying on AWS, Dfns retains the flexibility to adapt its infrastructure components to different availability zones, other cloud environments, and even on-prem bare metal setups. This adaptability allows Dfns to cater to the compliance and regulation requirements of our enterprise plan clients on a case-by-case basis.

How resilient is Dfns’s infrastructure?

Dfns chose to leverage the services of the world's largest cloud providers, such as AWS, to tap into their extensive experience in fault tolerance, DDoS protection, and infrastructure management spanning several decades. Serving as a cryptographic coordination layer across diverse cloud and computing setups, Dfns goes a step further than just relying on AWS as we integrate backup solutions for various parts of its infrastructure directly, ensuring redundancy.

Dfns Status
For real-time updates on our product's status, please visit our status page.

Which cloud platforms is Dfns able to work with?

Dfns is compatible with Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. We have upcoming plans to extend support to OVH Cloud, IBM Cloud, Oracle Cloud, and Digital Ocean in the near future.

Is load balancing utilized in Dfns's system?

Indeed, Dfns employs AWS's Elastic Load Balancing (ELB) for this purpose.

AWS's Elastic Load Balancing (ELB)

Does Dfns implement function segregation? 

Yes, the API endpoints are categorized into dedicated Lambdas.

AWS Lambda

Are users divided into separate pods? 

Yes, Dfns allocates distinct resources (AWS ECS containers) for each client.

AWS Elastic Container Service


Is Dfns’s network federated or distributed?

Dfns is a federated key management network. This means that distinct organizations retain authority over specific keys, all working cohesively within a unified coordination framework. This setup guarantees that each entity hosting a set of keys maintains its autonomy while also leveraging shared resources and capabilities. Unlike distributed networks such as blockchains, which distribute control across interconnected nodes, federated networks establish equilibrium between the centralization of each separate organization and collaborative interaction among them. Federated networks ensure that no single party has complete control over the network, thereby bolstering resilience, scalability, security, and the network's capacity to manage faults.

Important to note that both federated and distributed networks are regarded as decentralized networks by distributing authority across multiple entities rather than a single, centralized one.

What is a "key host"?

A key host, also known as a “signer”, is a specialized node responsible for generating, signing, and authenticating private keys using certificates managed by “delivery CAs” and “gRPC CAs”. Each client has their own distinct key host group, also referred to as a “signing group”. Key hosts have an established connection with a Delivery Server to facilitate the communication among themselves. Each key host possesses two secret keys: an identity key, which is an asymmetric digital signature key used for signing outgoing MPC messages, and an obfuscation key, which is a symmetric encryption key employed to encrypt key shares before storing them in the database. These keys are generated during the provisioning stage and are integrated into the docker image of the key host.

Is Dfns’s network permissioned or permissionless?

The Dfns network maintains strict permission controls and carefully vets key hosting partners, regardless of the network's level of decentralization and commitment to minimizing trust. Dfns' security stance is selective, affirming that the storage of sensitive key material achieves genuine security only when situated within professionally-operated computing environments that adhere to the highest standards of information security.

What’s the difference between fully-managed and on-prem keys?

The difference lies in how key management is approached. With fully-managed keys, third-party service providers handle them externally. On the other hand, on-premises keys are managed within your organization's own infrastructure. You can also utilize co-managed keys through multisignatures or threshold signatures, where external parties and your organization hold some keys each.

Who are the key hosting partners of Dfns?

We prioritize security and cannot publicly reveal the precise identities and locations of our key hosting partners. Their information remains confidential and is exclusively shared with clients upon inquiry.

To learn more, please get in touch with us at

Where are Dfns’s key hosting partners located? 

Currently, key shares are situated across two availability zones: one in France and the other in Germany. In 2023, we are expanding our presence to encompass three additional availability zones in Switzerland, the United States, and Canada. Additionally, we are in the process of integrating additional network partners in France, Italy, the US, the UAE, with more to come.

Dfns aims to be versatile in key deployments and strives to maximize composability. To illustrate this, we have collaborated extensively with CryptoSat for over a year to generate key shares within low Earth orbit (LEO) satellites that are able to sign Bitcoin transactions from space. Depending on requirements and priorities, we are open to exploring the deployment of key shares in alternative locations and cloud environments, as long as they adhere to our security standards. Note that we do not operate on all devices like personal laptops or phones for e.g.

Space Wallet
The Space Wallet provides enhanced security against physical access-based attacks.

How does Dfns select key host partners?

To become a revenue-sharing partner within the Dfns network, it's essential to demonstrate a track record of being capable of implementing and maintaining a key hosting node, adhering to the standard security directives provided by Dfns. Our partners are expected to assume full legal accountability for independently implementing and maintaining secure enclaves in Tier 3+ or Tier 4 data centers situated in countries not subject to OFAC sanctions. Additionally, a minimum of SOC 2 and/or ISO 27001 certification from a reputable audit firm is required. The integration of a new partner is only finalized once all eligibility criteria are satisfied, and an SLA agreement is in place. 

For further insights into the procedure, please contact us at

Is it possible to deploy keys on premises?

Indeed, this option is available only to certified Enterprise Plan clients who have a demonstrated history of successfully adhering to industry security best practices. 

Dfns will not allow all clients to deploy keys on-prem as we do not want to subject ourselves to potential damage to our reputation by engaging with clients who wish to manage keys without possessing the necessary internal capabilities to ensure due security.

How is collusion prevention among key host partners ensured?

  • Dfns restrict logins to key hosting nodes, preventing unauthorized access.
  • Dfns maintains anonymity of key host identities and locations.
  • Dfns enforces functional separation among employees managing key host coordination (partnerships, engineering, security, infrastructure, etc.).
  • Dfns enforces dual control for production code change management as outlined in our SDLC.

Blockchain Nodes

Does Dfns offer support for testnet and mainnet?

Yes, both.

How do you communicate with blockchain nodes?

Dfns collaborates with a range of reliable and redundant Node-as-a-Service providers, including Alchemy, Ankr, Infura, GetBlock, and Quicknode, among others. As part of our future plans, we aim to spin up and run our own blockchain nodes, beginning with major chains like Ethereum.


How is revision control established across all platforms and versions?

Yes, revision control is present across all platforms and versions. It is facilitated through the utilization of both private and public repositories on Git and GitHub.

Is the development process driven by tests?

Yes, we incorporate comprehensive automated regression testing.

Is continuous integration utilized in the system?

Yes, we employ Jenkins CI/CD for this purpose.

How is the deployment process carried out?

Deployments occur on a weekly cadence, and they are initiated manually following the approval of software packages from the Lead Test Engineer and Head of Infrastructure.

Is the source code easily understandable and consistently styled?

Yes, the team upholds uniform coding standards across all repositories, which includes the utilization of automated tools for this purpose.

Does the source code contain comments?


Does each code unit (e.g. objects, methods) have commenting?


Does Dfns operate on the latest versions of underlying software?

Yes, we are enrolled in AWS upgrade notifications and promptly executing upgrades whenever necessary.


What is Dfns’s guaranteed signatures per second rate?

We conduct regular load tests to evaluate our signing performance. These tests encompass both single and multiple parallel executions for both ECDSA and EdDSA signing. In our most recent test batch, the results demonstrated ~2 ECDSA signatures per second and ~20 EdDSA signatures per second. Note that ECDSA signatures (using CGGMP21) exhibit slightly slower performance compared to EdDSA (using FROST) due to the required inclusion of Paillier encryption and zero-knowledge proofs. 

In terms of signing speed, threshold signatures, which involve multiple parties and zero-knowledge proofs for signature generation, inherently operate at a slower pace compared to signatures generated by a single signer. Encouragingly, recent advancements in MPC protocols have introduced promising techniques that substantially enhance signing speed. Compared to legacy MPC protocols (e.g. Lindell17, GG18, GG20, etc.), we anticipate a minimum 10-fold acceleration of signing by 2023 and 80 to 100-fold improvement by 2024.

Research Team
For further information on this topic, you're welcome to contact us at

What is Dfns’s guaranteed wallet generation rate?

We regularly carry out load tests every quarter to assess the efficiency of our key generation process. At present, Dfns has the capability to produce ~250 public-private key pairs per hour through the current DKG of the CGGMP21 protocol. By using hierarchical deterministic (HD) derivation paths, it is possible to generate a substantially greater quantity of keys within a given timeframe.
However, note that these keys won't be distinct, separate pairs; instead, they are derived keys which could be susceptible to hacking if the main key pair becomes compromised. 

Our research team has recently unveiled a new DKG paper, “Round Optimal Robust Distributed Key Generation” which is anticipated to greatly enhance the speed of key generation. Implementation is planned for 2024.

How many wallets can I generate with Dfns?

You can create an unlimited number of wallets using Dfns, there are no restrictions on the quantity.

Is automatic scaling enabled with Dfns?

Yes, Dfns employs AWS Lambdas for seamless and automatic scaling. Lambdas are a serverless computing service provided by AWS that allow Dfns to run code in response to events without provisioning or managing servers. They are designed to scale seamlessly with the incoming workload. These Lambdas enable the system to dynamically allocate and deallocate computing resources in response to the workload, ensuring that Dfns tasks are executed efficiently and without interruption, regardless of variations in demand.


Where can I find Dfns’s Service Level Agreement (SLA)?


What is the annual uptime rate of Dfns?

Dfns guarantees a 99.9% availability rate, which equates to an annual downtime allowance of 8 hours, 41 minutes, and 38 seconds. Our objective is to achieve a 99.995% availability ("four nines five") as we transition from tier 3+ to 100% tier 4 data centers in 2024 and 2025.

How reliable and thoroughly tested are Dfns’s APIs?

Since the launch of our product in February 2021, we have not experienced any unplanned service interruptions with our API, nor have we encountered any security issues. Presently, Dfns's platform facilitates the transfer of tens of millions of dollars' worth of digital assets, and substantial yearly investments are made to maintain the highest security protocols for our clients. Our system has successfully withstood all open tests and audits from top-tier firms, and we have consistently received positive feedback. Our test engineering division conducts over 100 manual and automated tests and quality assurance controls every month.

Upon NDA signing, we can provide you with the relevant documentation. Contact to get more information.

From where do Dfns's teams operate?

Our teams operate entirely in remote fashion, with offices spanning from San Francisco to Dubai, encompassing key locations such as New York, London, and Paris. This strategic dispersion empowers us to deliver 24/7 support and achieve near-instant response times.


Does Dfns log incidents with sufficient detail to troubleshoot them?

Yes, they are logged comprehensively.

Does Dfns dispatch alerts in real time to clients?

Yes, alerts are sent immediately.

Are user actions (e.g., logins, downloads, checkouts) employed to establish business metric monitors?

Yes, user behaviors are utilized for creating business metric monitors.

Are post mortems carried out and integrated into the system?

Yes, formal post mortems are conducted for all incidents, accompanied by specific action points to avert future problems.