Skip to main content
This page explains how Dfns’ governance layers work together to secure your digital assets.

​
Overview

Every Dfns API request passes through multiple security layers before a blockchain transaction is signed:

​
Layer 1: Authentication

Every API request must prove identity through two mechanisms:

​
API Token

The Authorization: Bearer <token> header identifies who is making the request:
  • User tokens: Short-lived, obtained through login flow
  • Service account tokens: Long-lived, for server-to-server communication
  • Personal access tokens: Long-lived user tokens for development

​
User Action Signature

For state-changing operations (POST, PUT, DELETE), the X-DFNS-USERACTION header proves the caller controls a registered credential:
  1. Client requests a challenge from Dfns
  2. Client signs the challenge with their credential (passkey or asymmetric key)
  3. Dfns verifies the signature matches a registered credential
This ensures that even if a token is stolen, an attacker cannot perform sensitive operations without the credential.

​
Layer 2: Authorization (Permissions)

After authentication, Dfns checks if the user has permission to perform the requested action. Permissions follow a whitelist model - users can only perform actions explicitly granted: Example: A user with Wallets:Read can view wallets but cannot transfer assets (requires Wallets:Sign). See Permissions for the full list.

​
Layer 3: Policy Engine

Even with valid authentication and permissions, the Policy Engine can add additional controls:
Policy actionEffect
BlockTransaction is rejected
RequestApprovalTransaction held until humans approve
NoActionTransaction proceeds (used with Chainalysis for logging)
Policies evaluate rules like:
  • Transaction amount limits
  • Velocity limits (amount or count over time)
  • Recipient whitelisting
  • Chainalysis screening
See Policies for details.

​
Layer 4: MPC Signing

Once a transaction passes all checks, the MPC signing ceremony begins: Key properties:
  • No complete key: The private key never exists in one place
  • Threshold security: Requires k-of-n shares to sign (not all shares needed)
  • Geographic distribution: Nodes are in different data centers/regions
  • Audit trail: Every signing ceremony is logged

​
Layer 5: Broadcast

The signed transaction is broadcast to the blockchain network. Dfns monitors for confirmation and updates transaction status.

​
Security model summary

LayerWhat it protects against
AuthenticationUnauthorized access
User action signingToken theft, replay attacks
PermissionsPrivilege escalation
PoliciesUnauthorized transactions, fraud
MPCKey theft, single point of compromise

​
Separation of concerns

A critical security property: credentials and keys are completely separate.
Credential (Authentication)Key (Signing)
Proves identitySigns transactions
Stored on user device (passkey) or server (service account)Stored in MPC network
Can be revoked/rotatedKey shares are immutable
Compromised credential ≠ stolen assetsProtected by all layers above
Even if an attacker steals credentials, they still face:
  • User action signing requirements
  • Permission checks
  • Policy enforcement
  • MPC threshold requirements

How MPC works

Deep dive into MPC technology

Policies

Configuring transaction policies

Permissions

Understanding permission model

Authentication

Authentication flows