Key Management Run any key anywhere, from one platform.

Store keys in MPC, HSM, or offline.<br /> Run them in our cloud, yours, or on your metal.

dashboard northwind-treasury OrgID: or-01k11-419cq-efcanlnjan3oj2if
env: live sdk@dfns/sdk v0.6.12 V2.04Read patch notes docs
SummaryWebhooksAPI CredentialsKey stores
Key stores
Where signing keys live: Dfns MPC signer network and your own hardware security modules.
Offline Signing App
MPC
Each key is split across independent signer nodes. A signature requires a threshold of shares; no node ever holds the full key.
rotate shares
signer-01
regioneu-west-1
hosted byDfns
versionv4.12.0
heartbeat2s ago
signer-02
regioneu-central-1
hosted byDfns
versionv4.12.0
heartbeat1s ago
signer-03
regionus-east-1
hosted byOnPrem
versionv4.12.0
heartbeat2s ago
signer-04
regionap-southeast-1
hosted byDfns
versionv4.11.2
heartbeat41s ago
signer-05
regionme-central-1
hosted byOnPrem
versionv4.12.0
heartbeat1s ago
KEY IDSCHEMECURVETHRESHOLDWALLETSLAST ROTATED
key-01j7p-7m3qx-cs4e ECDSA secp256k1 412 12d ago
key-01j7r-2k8vn-ab0d EdDSA ed25519 188 12d ago
key-01j8b-9p1ws-lf6t ECDSA secp256k1 96 30d ago
key-01j9c-4x7mq-zr2h Schnorr secp256k1 41 30d ago
Triple-ASphereGeminiHercleDamisaStables

Keys born
distributed

Generate your keys with advanced multi-party computation. The key never exists in full.

No SPOF

No mnemonic, no recovery sheet, no HD tree rooted in a single secret an attacker can target.

Independent entropy

Each share derives from its enclave's hardware RNG. No shared seed, no correlated randomness.

Every curve

secp256k1, Ed25519, Stark, Schnorr, covered by KU25 for ECDSA and FROST for Schnorr.

dashboard northwind-treasury OrgID: or-01k11-419cq-efcanlnjan3oj2if
env: live sdk@dfns/sdk v0.6.12 V2.04Read patch notes docs
SummaryWebhooksAPI CredentialsKey stores
Key stores
Where signing keys live: Dfns MPC signer network and your own hardware security modules.
Offline Signing App
MPC
Each key is split across independent signer nodes. A signature requires a threshold of shares; no node ever holds the full key.
rotate shares
signer-01
regioneu-west-1
hosted byDfns
versionv4.12.0
heartbeat2s ago
signer-02
regioneu-central-1
hosted byDfns
versionv4.12.0
heartbeat1s ago
signer-03
regionus-east-1
hosted byOnPrem
versionv4.12.0
heartbeat2s ago
signer-04
regionap-southeast-1
hosted byDfns
versionv4.11.2
heartbeat41s ago
signer-05
regionme-central-1
hosted byOnPrem
versionv4.12.0
heartbeat1s ago
KEY IDSCHEMECURVETHRESHOLDWALLETSLAST ROTATED
key-01j7p-7m3qx-cs4e ECDSA secp256k1 412 12d ago
key-01j7r-2k8vn-ab0d EdDSA ed25519 188 12d ago
key-01j8b-9p1ws-lf6t ECDSA secp256k1 96 30d ago
key-01j9c-4x7mq-zr2h Schnorr secp256k1 41 30d ago

Earn every
signature

Before any key share participates, the request must be user-signed, policy-cleared, and cryptographically authorized. Compromise one layer and nothing signs.

Policy-gated signing

Quorums, limits, and allowlists are evaluated before a signature exists, not after it settles.

Auth ≠ key

Passkeys authenticate the request; MPC keys authorize the action onchain. They are different.

Signed user actions

Sensitive requests carry a WebAuthn signature from the user's device, bound to the exact action.

Operations
Recent Pending 7 Completed Failed
Date
Status
From (Sender)
To (Recipient)
Amount
Asset
Type
Approval
Sep 9
14:30
Pending
Treasury Vault
ETH
Kraken Corporate
0x4f2a…b71c
−10.5 ETH
−$35,400.00
ETH
Ethereum
Transfer
1 of 2 signed
Awaiting you
Sep 9
11:20
Pending
Hot Vault
USDC
Coinbase Prime
0x4f2a…b71c
−120,000 USDC
−$120,000.00
USDC
Polygon
Transfer
1 of 2 signed
Awaiting you
Sep 9
09:42
Pending
Settlement Vault
USDC
Anchorage Digital
0x2c88…a417
−340,000 USDC
−$340,000.00
USDC
Ethereum
Transfer
2 of 3 signed
Awaiting Sarah
Sep 8
16:10
Pending
Trading Vault
ETH
Uniswap v3
0x7a3f…e2d9
−4.2 ETH
−$14,280.00
ETH
Ethereum
Swap
0 of 2 signed
Awaiting you
Sep 8
10:35
Pending
Operating Vault
USDC
Payroll Batch 09
0x55ce…7d31
−86,400 USDC
−$86,400.00
USDC
Polygon
Payout
1 of 3 signed
Awaiting you
Sep 7
21:14
Pending
Hot Vault
BTC
Bitstamp
bc1q…4kd8
−0.75 BTC
−$43,500.00
BTC
Bitcoin
Transfer
1 of 2 signed
Awaiting Justin
Sep 7
11:06
Pending
Treasury Vault
USDC
Circle Redemption
0x91b0…cc28
−500,000 USDC
−$500,000.00
USDC
Ethereum
Transfer
1 of 3 signed
Awaiting Marc

Zero keys lost.
Ever.

Key shares span multiple regions. Signer quorums remain available when nodes fail. No whole key exists to rotate, expire, or lose.

No key to rotate

MPC doesn't depend on freshness. Rotate the credentials that touch it; leave the key in place.

Survives outages

A region can go dark, the signing quorum carries on. Continent-level failures degrade gracefully.

Built-in recovery

The threshold tolerates losing nodes and missing shares by reconstituting them under attestation.

dashboard northwind-treasury OrgID: or-01k11-419cq-efcanlnjan3oj2if
env: live sdk@dfns/sdk v0.6.12 V2.04Read patch notes docs
SummaryWebhooksAPI CredentialsKey stores
$ tail -f requests.log live
14:32:08.412 GET 200 /wallets/wa-4k9s2/assets sa-ci-deployer 81ms
14:32:08.207 POST 201 /wallets/wa-4k9s2/transfers us-3k8f2-a91mq 219ms
14:32:07.981 POST 200 /auth/action/init us-9pl4x-r7c3e 47ms
14:32:07.640 GET 200 /wallets?limit=50 sa-treasury-bot 69ms
14:32:07.118 POST 403 /policies us-7hq1c-m02zt 32ms
14:32:06.902 GET 200 /policies/approvals to-2nd8-x4kq 91ms
14:32:06.455 POST 202 /keys/key-7m3q/signatures sa-ci-deployer 301ms
14:32:06.031 GET 200 /networks/ethereum/fees us-3k8f2-a91mq 58ms
14:32:05.772 DELETE 204 /auth/pats/to-2nd8 us-9pl4x-r7c3e 44ms
14:32:05.310 GET 429 /wallets/wa-1p8x/history sa-treasury-bot 12ms
14:32:04.720 POST 200 /keys/ke-k9s2/signatures us-7hq1c-m02zt 12ms
14:32:04.203 GET 200 /networks/fees to-2nd8-x4kq 65ms
14:32:03.349 GET 200 /policies sa-ci-deployer 118ms
14:32:02.878 DELETE 204 /webhooks/wh-z3rd us-3k8f2-a91mq 171ms
14:32:02.070 PUT 200 /policies/po-2nd8 us-9pl4x-r7c3e 224ms
14:32:01.645 GET 500 /wallets/wa-f6c1/tags sa-treasury-bot 277ms
14:32:00.883 GET 404 /wallets/wa-b8tw/nfts us-7hq1c-m02zt 40ms
14:32:00.504 GET 200 /wallets/wa-k9s2/assets to-2nd8-x4kq 93ms
14:31:59.788 POST 202 /policy-approvals/ap-1p8x/decisions sa-ci-deployer 146ms
14:31:59.455 POST 201 /wallets/wa-7mq4/transfers us-3k8f2-a91mq 199ms

Hold the keys or
hand them over

Run company wallets and user wallets on the same key management layer. Custody what you hold. Delegate what they hold.

Custody-agnostic

Hold keys for your users. Or delegate signing so they approve, you operate per wallet.

Embedded wallets

Add user wallets inside your product with a passkey. No seed phrase to manage.

Audit log

However the key is held, every signature lands in the same signed, timestamped record.

Dashboard Settings
Security
Control how members authenticate into this organization.
WebAuthn
Require a hardware key or platform passkey to sign in.
Single Sign-On
Let members sign in through your identity provider.
Manage Tokens
Add, price and verify the custom tokens this organization supports.
Developers
Programmatic access and network-level services.
Webhooks
Receive events for wallets, transfers and policies.
Personal Access Tokens
Generate tokens to authenticate API requests.
Fee Sponsorship
Cover network fees on behalf of your wallets.
Canton Validators
Manage the validator nodes securing your Canton network.
Compliance
Records kept for review and reporting.
Audit Logs
Every action taken across this organization, exportable for review.

0 keys lost
$0B+ secured
0 breaches
2020 securing since

Discover how Zodia Custody secures keys on DFNS.

Thanks to their collaborative team and institutional-grade wallet platform, we've enhanced our operational capabilities and widened our business lines. Our security framework has also been reinforced by their state-of-the-art MPC cryptography.

Thierry Janaudy CTO, Zodia Custody

Your keys. Your hardware.
Your jurisdiction.

Three archetypes. Three configurations. One platform.

The Central Bank

Sovereign, on-premises, never on a cloud.

Air-gapped Offline Signers in a sovereign data center. HSM inside the country’s borders. Every key generation witnessed as a ceremony. Every signature is a four-of-seven quorum.

See our deployment options
The Global Custodian

MPC alongside the HSM fleet you already trust.

Hextrust runs sub-organizations per client and per jurisdiction. Hybrid deployment matches controls to asset class — SaaS for new chains, on-prem for the assets that demand it.

Discover our integrations
The Neobank App

Every wallet is the user’s, not the app’s.

Due provisions non-custodial wallets for tens of thousands of users through DFNS. Passkeys on the user’s device. Co-controlled signing with the neobank’s policy engine.

Read the Due story
Choose your security model

MPC or HSM. Mix them by wallet, entity, or mandate. Our key layer adapts to your risk model.

Deploy on your own terms

Managed SaaS, hybrid, or fully on-premises. Same API, same controls, wherever the keys live.

Eliminate the single-key risk

MPC across enclaves, no seed phrases. The key is never assembled and signing never stops.

Access every chain from one key

A single key derives wallets on 100+ networks. Manage access once, apply it everywhere.


Four steps from key to signature

Generate the key. Derive wallets. Govern access. Sign safely. The same primitive whether you have one wallet or ten million.

0 client key losses since 2020 · MPC across enclaved nodes in multiple regions · Curves: secp256k1, Ed25519, Stark, Schnorr · 100+ chains served from one key

Create a key the cryptographic way.

One API call. The MPC network generates independent shares across enclaves. No seed phrase produced. No master secret stored. The key is referenced by keyId and never exists in complete form.

// Generate an MPC key — distributed across enclaved signers from the start
const key = await dfnsApi.keys.createKey({
  body: {
    scheme: "ECDSA",          // or "EdDSA", "Schnorr"
    curve: "secp256k1",        // or "ed25519", "stark"
    name: "Treasury Master Key — EU Region"
  }
});

// key.id, key.publicKey, key.scheme, key.curve
// The private key is split, sealed, and distributed.
// It has never existed as a complete value, and never will.
Generate, don't import. Keys created natively by DFNS have never existed in complete form — that's the strongest security guarantee MPC offers. Import only when a contract address or non-transferable asset forces it.

One key, every chain you operate on.

Reference the same keyId to derive wallets on any compatible network. Same address on every EVM chain. Different address on Bitcoin or Solana, same underlying key. Rotate access once, propagate everywhere.

// Same key — wallets on Ethereum, Polygon, Base, Arbitrum, etc.
const ethereum = await dfnsApi.wallets.createWallet({
  body: { network: "Ethereum", signingKey: { id: key.id }, name: "Treasury — ETH" }
});
const polygon  = await dfnsApi.wallets.createWallet({
  body: { network: "Polygon",  signingKey: { id: key.id }, name: "Treasury — MATIC" }
});

// ethereum.address === polygon.address — same key, same EVM address
// On Bitcoin or Solana, different address derivation, same underlying key
Use one key for an entire wallet class — operating, treasury, custody, issuance. Manage permissions at the key level; they apply to every derived wallet. Use distinct keys for distinct trust domains, not distinct chains.

Separate authentication from signing.

Passkeys and API credentials authenticate the request. MPC shares authorize the signature. Compromise of one doesn't compromise the other. Layer policies on top — quorums, limits, allowlists.

// Authenticate the request with a passkey-signed user action
const userActionSignature = await dfnsApi.auth.signUserAction({
  challenge,
  credential: await navigator.credentials.get({ publicKey: { challenge } })
});

// Sign a payload — the policy engine evaluates BEFORE the MPC network signs
const signature = await dfnsApi.keys.generateSignature({
  keyId: key.id,
  body: {
    kind: "Hash",
    hash: "0xabc...def"            // 32-byte hash to sign
  },
  userActionSignature
});

// Authentication credential ≠ signing key. Two domains, two attack surfaces.
// Compromise of either alone signs nothing.
Treat authentication credentials and signing keys as distinct primitives. Rotate passkeys on schedule. Rotate API keys often. The MPC key never needs rotation — its security model doesn't depend on key freshness.

Pick where the shares live.

Managed SaaS for speed. Hybrid cloud when sovereignty matters. On-premises when regulation requires it. Same MPC protocol, same audited code, your choice of where the enclaves run.

// Managed SaaS — the default. All shares in DFNS enclaves.
const dfnsApi = new DfnsApiClient({
  baseUrl: "https://api.dfns.io",
  // ...
});

// Hybrid — you hold one or more shares in your own infrastructure
// Configured during onboarding; the signing flow is otherwise identical
// DFNS cannot sign without your share; you cannot sign without DFNS

// On-premises — entire MPC stack inside your data center
// Same SDK, different base URL, full operational control
const onPremApi = new DfnsApiClient({
  baseUrl: "https://dfns.your-bank.internal",
  // ...
});
Pick by regulatory regime, not by preference. Managed SaaS for fintechs. Hybrid for systemically important institutions. On-premises for central banks and sovereign deployments. Migration paths exist between models.
Keys → New Key → Scheme + Curve + Name → Generate
Keys → New Key → Scheme + Curve + Name → Generate
Keys → Key → Derived Wallets → New Wallet (Network)
Keys → Key → Derived Wallets → New Wallet (Network)
Keys → Key → Permissions + Policies → Approval Matrix
Keys → Key → Permissions + Policies → Approval Matrix
Org → Deployment → Active Configuration → Share Locations
Org → Deployment → Active Configuration → Share Locations
FAQ

Common questions
about MPC key management

What is MPC key management for digital assets?
MPC (multi-party computation) key management generates and operates cryptographic key shares across multiple independent nodes — the private key is never assembled in a single location. DFNS uses MPC to eliminate the single-key risk that makes traditional HSM-based custody vulnerable to insider attacks and node compromise.
How does DFNS MPC differ from HSM key management?
An HSM holds the full private key on dedicated hardware — if the HSM is compromised or lost, the key is gone. DFNS MPC generates key shares distributed across independent, enclaved nodes. No single node ever holds the full key; signing requires quorum participation. Both models can coexist: DFNS supports MPC alongside existing HSM fleets.
Does DFNS ever have access to private keys?
No. DFNS never has access to client private keys. Key material is generated within enclaved nodes and never reconstructed in any single location — including DFNS infrastructure. The cryptographic separation is enforced at the protocol level, not by policy alone. DFNS has recorded zero client key losses since inception.
Where can I deploy DFNS key management?
DFNS key management runs in DFNS-hosted cloud, your cloud (AWS, Azure, GCP), or fully on-premises in your own data center. All deployment models use the same MPC protocol, governance controls, and audit trail.
What happens if a key share node fails?
Key shares are replicated across independent nodes with geographic distribution. If a node fails, the remaining shares are sufficient to continue operations under the configured quorum threshold. DFNS has recorded zero client key losses across $200B+ secured and 20M+ wallets since 2022.
Contact us