Architecture

Walkthrough of the DFNS architecture and how the platform helps businesses securely manage digital assets across authentication, policies, and MPC signing.

Overview

DFNS is a Core Banking Platform for onchain finance. It handles the security infrastructure so clients can focus on building their products and services.

At the core is a wallet infrastructure built on Multi-Party Computation. Rather than a single private key that can be stolen or lost, MPC splits the signing key across multiple nodes in separate secure enclaves — so there is no single point of failure, and no single party that could unilaterally move funds. The platform exposes this through APIs and SDKs covering 30+ blockchains and 1,000+ tokens, with support for both org-controlled wallets (where your team manages signing) and user-controlled wallets (where your end users hold signing authority from within your app).

Layered on top of the signing infrastructure is a policy and permissions engine. It lets you define exactly who can do what: multi-level approval workflows, role-based access, destination allowlists and denylists, and a real-time audit log of every action taken on every wallet.

The signing key shards themselves can be deployed to match your regulatory requirements — fully managed by DFNS in geographically distributed data centers, split between your infrastructure and DFNS in a hybrid model, or hosted entirely on your own infrastructure.

---

Transaction walkthrough

The following describes the full lifecycle of a transfer request in a DFNS-powered application.

1. Authentication

Alice, a finance operator at Acme Corp, opens the treasury app and logs in with her passkey. Her device’s secure hardware signs a challenge from the DFNS authentication service. DFNS validates the signature and issues a session token.

2. Authorization check

Alice submits a payment order: “Send 50,000 USDC to Vendor XYZ.” DFNS checks her session token against the wallet’s permission rules. Her Finance Operator role has permission to initiate transfers on this wallet. The request proceeds.

3. Policy evaluation

The Policy Engine evaluates the request against Acme’s configured policies:

• Destination address is on the approved vendor list. ✓
• Amount is within the daily transfer limit. ✓
• Amount exceeds $10,000 → requires manager approval.

The transaction moves to Pending Approval and an approval request is sent to the configured approvers.

4. Approval

Bob, a treasury manager, receives a notification. He logs in with his own passkey, reviews the transaction, and approves it. The approval quorum is met and the transaction is cleared for signing.

5. MPC signing

The approved transaction is sent to the MPC signing cluster. Each node holds one shard of the signing key in a Secure Enclave — no node ever holds the full key. The nodes run a multi-party computation protocol: each contributes its shard to produce a valid signature without any shard leaving its enclave.

6. Broadcast

The signed transaction is submitted to the blockchain. Once included in a block, a confirmation flows back through the system. Alice and Bob see the status update: “Payment Complete.”