Custody Providers
Architecture overview of DALP's custody provider integrations covering DFNS and Fireblocks MPC signing, policy engines, configuration requirements, and the unified signer abstraction that makes providers interchangeable.
Purpose
DALP integrates with institutional MPC custody providers to protect private keys controlling digital assets. This page documents the integration architecture for DFNS and Fireblocks --- what each provider offers, how they connect, and how the unified signer abstraction makes them interchangeable.
- Doc type: Reference
What you'll find here
- Provider comparison: MPC models, policy engines, and API contracts
- DFNS integration architecture and configuration surface
- Fireblocks integration architecture and configuration surface
- Unified signer abstraction and provider switching
- Storage tier mapping from development through regulated production
Related
Provider comparison
| Capability | DFNS | Fireblocks |
|---|---|---|
| MPC type | Threshold MPC | MPC-CMP (continuous key refresh) |
| Policy engine | DFNS Policy Engine | Transaction Authorization Policy (TAP) |
| Mobile approval | No | Yes (Fireblocks app) |
| Programmatic approval via DALP | Full API resolution | Console / Co-Signer only |
| API model | REST API | REST API |
| Wallet model | Flat wallet list | Vault account hierarchy |
| Multi-chain token registration | -- | EVM, Stellar, Algorand, TRON, and more |
Both providers use MPC signing so that no single private key ever exists in one place. The fundamental difference is operational: DFNS allows fully programmatic approval workflows through its API, while Fireblocks requires approvals through its own console or mobile app.
DFNS integration
DFNS provides delegated MPC custody where key shards distribute across DFNS infrastructure. DALP connects through a service account with the following configuration:
| Setting | Description |
|---|---|
| API URL | DFNS service endpoint |
| Organization ID | Tenant identifier |
| Auth token | Service account authentication |
| Credential ID | Identifies the signing credential |
| EC private key | Elliptic curve key for API authentication |
Policy enforcement
The DFNS policy engine evaluates transaction rules before MPC signing proceeds. Policies support auto-sign rules, amount thresholds, IP/time restrictions, and multi-party approval requirements. When a policy requires approval, DALP surfaces the pending approval through its API --- operators can review, approve, or reject without leaving the DALP interface.
Audit integration
DFNS audit logs synchronize with DALP audit records, providing unified compliance reporting across both the platform and custody layers.
Fireblocks integration
Fireblocks provides institutional MPC-CMP custody through vault accounts. Key material distributes across Fireblocks infrastructure and the customer's co-signer node, with continuous key refresh eliminating static key shares.
| Setting | Description |
|---|---|
| API key | From the Fireblocks Console |
| RSA private key | PEM format, for API authentication |
| API endpoint | Production or sandbox URL (auto-detected) |
Vault-based wallet model
Fireblocks organizes keys into vault accounts, each containing one or more asset wallets. DALP supports creating vault accounts, activating asset wallets, and querying vaults across the organization.
Transaction Authorization Policy (TAP)
Fireblocks enforces custodian-level policies through TAP rules that evaluate before signing. Rules cover transaction amount thresholds, whitelisted destination addresses, velocity limits, and multi-approver requirements.
When a TAP rule blocks a transaction, DALP surfaces the pending approval. However, unlike DFNS, Fireblocks does not support programmatic approval resolution through external APIs. Blocked transactions must be approved through the Fireblocks Console or a Co-Signer appliance.
Unified signer abstraction
The unified signer interface abstracts over all custody backends. Switching between DFNS and Fireblocks requires only configuration changes --- no workflow modifications, no code changes, no API contract differences for consumers.
This abstraction boundary means:
- Platform workflows call the signer interface without knowing which provider handles the request
- Adding a new provider requires implementing the signer adapter, not changing platform flows
- Provider-specific behavior (approval model differences, vault hierarchies) is encapsulated behind the adapter
See the Signing Flow for the complete end-to-end sequence showing how the signer interface delegates to the active provider.
Storage tiers
Custody providers represent the highest tier in DALP's key storage hierarchy. Organizations select the appropriate tier based on asset value and regulatory requirements:
| Tier | Protection | Use case |
|---|---|---|
| Encrypted database | Application-level encryption | Development and low-value assets |
| Cloud secret manager | Platform-managed encryption | Standard production deployments |
| Hardware security module | FIPS 140-2 Level 3 | Regulated financial services |
| Third-party custody (DFNS / Fireblocks) | Delegated institutional MPC | Highest security requirements |
Each tier escalates protection. The Key Guardian routes signing requests to the appropriate backend based on key metadata. See Key Guardian for the full storage hierarchy and routing architecture.
See also
- Key Guardian for the complete key storage and routing architecture
- Signing Flow for the end-to-end transaction signing sequence
- Authentication for API-level security controls
Overview
Overview of DALP's integration architecture covering custody provider connectivity, supported blockchain networks, and the platform's approach to external system boundaries.
Supported Networks
Reference for blockchain networks supported by the DALP platform, covering EVM-compatible Layer 1 mainnets, Layer 2 rollups, testnets, and private consortium networks with their configuration differences.