# Key Guardian

Source: https://docs.settlemint.com/docs/architecture/components/infrastructure/key-guardian
The Key Guardian service manages cryptographic key material with
defense-in-depth security across local signing, DFNS, Fireblocks,
and Luna HSM backends. Secret managers store local keys and Luna
authentication material for those supported signer providers.




The Key Guardian protects private keys that control digital assets. It routes each signing request to the configured signer backend.

Supported signer backends are local signing, DFNS, Fireblocks, and Luna HSM partition signing.

Secret managers provide underlying key or PIN storage for the local and Luna backends. Secret managers are not a separate signing backend.

Local signing loads the private key inside the local signer process. DFNS, Fireblocks, and Luna keep signing inside their provider or hardware controls.

Key Guardian sits behind the [Transaction Signer](/docs/architecture/components/infrastructure/transaction-signer), which requests signatures for DALP workflows. For the full transaction path from policy checks to custody signing and broadcast, see [Signing Flow](/docs/architecture/flows/signing-flow).

## Signer backend hierarchy [#signer-backend-hierarchy]

| Signer backend | Protection model                  | Secret-manager role                                     | Use case                                               |
| -------------- | --------------------------------- | ------------------------------------------------------- | ------------------------------------------------------ |
| Local          | Configured secret-manager backend | Stores private keys under the local signer's key prefix | Operator-managed signing with local key custody        |
| DFNS           | Provider-managed MPC custody      | Not used by the signer adapter                          | Custody signing with DFNS policy controls              |
| Fireblocks     | Provider-managed MPC custody      | Not used by the signer adapter                          | Custody signing with Fireblocks TAP controls           |
| Luna HSM       | Thales Luna 7 partition signing   | Stores the Luna PIN and optional client key references  | Hardware-backed signing with out-of-band M-of-N quorum |

## Security architecture [#security-architecture]

<Mermaid
  chart="`flowchart TB
  subgraph TX[&#x22;Transaction Signer&#x22;]
    REQ(Signature Request)
  end

  subgraph KG[&#x22;Key Guardian&#x22;]
    API(Guardian API)
    ROUTER(Storage Router)
  end

  subgraph STORAGE[&#x22;Signer backends&#x22;]
    LOCAL(Local signer)
    DFNS(DFNS custody)
    FB(Fireblocks custody)
    LUNA(Luna HSM)
  end

  subgraph SECRETS[&#x22;Secret storage&#x22;]
    SM(Secret manager)
  end

  REQ --> API
  API --> ROUTER
  ROUTER --> LOCAL
  ROUTER --> DFNS
  ROUTER --> FB
  ROUTER --> LUNA
  LOCAL --> SM
  LUNA --> SM

  style REQ fill:#8571d9,stroke:#654bad,stroke-width:2px,color:#fff
  style API fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style ROUTER fill:#6ba4d4,stroke:#4a7ba8,stroke-width:2px,color:#fff
  style LOCAL fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style SM fill:#5fc9bf,stroke:#3a9d96,stroke-width:2px,color:#fff
  style DFNS fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style FB fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff
  style LUNA fill:#b661d9,stroke:#8a3fb3,stroke-width:2px,color:#fff`"
/>

The Guardian API receives signature requests without exposing raw key material. The storage router directs each request to the configured signer backend. The local backend reads encrypted private keys from the configured secret provider, and the Luna backend reads PIN material and optional client key references from the same secret-provider layer.

## Key lifecycle [#key-lifecycle]

* **Generation**: HSM-backed keys generate entirely within hardware. Software keys use cryptographically secure random sources with immediate encryption before memory clearing.
* **Rotation**: Replaces active signing keys while maintaining historical keys for verification. Coordinates with blockchain address updates and registry notifications.
* **Recovery**: Enterprise deployments use sharded backups with threshold signature schemes requiring multiple custodians.
* **Revocation**: Compromised keys are immediately removed from active use. Smart contract permissions update to reject signatures from revoked keys.

## DFNS integration [#dfns-integration]

DFNS provides delegated MPC custody as a pluggable backend.

* **Policy enforcement**: DFNS policy approvals remain provider-owned. See [DFNS policy enforcement](/docs/architecture/integrations/custody-providers#policy-enforcement) for the canonical status vocabulary, error handling, and approval handoff, and [Signing Flow](/docs/architecture/flows/signing-flow) for interaction details.
* **Multi-party approval model**: DFNS policy approvals are separate from DALP smart-wallet multisig approvals, which use a UserOperation approval flow instead of a custody-policy decision flow.
* **Audit evidence split**: DALP records signing workflow state, transaction identifiers, provider status, and operator activity. DFNS keeps the provider audit trail for custody-policy decisions in the DFNS control plane, so treat the two records as complementary evidence.

## Fireblocks integration [#fireblocks-integration]

Fireblocks provides MPC custody through vault accounts. Switching between DFNS and Fireblocks keeps DALP signing requests consistent, while provider-specific approval and wallet behavior remains behind the signer adapter.

* **Vault model**: Keys organized into vault accounts, each containing one or more asset wallets. DALP supports creating, listing, and managing vaults.
* **Transaction signing**: All signing happens through Fireblocks MPC. No single private key ever exists. Fireblocks supports message signing, transaction signing with fee estimation, and typed data signing.
* **Transaction Authorization Policy (TAP)**: Enforces amount thresholds, whitelisted destinations, velocity limits, and multi-approver requirements.
* **Approval limitation**: Fireblocks approval remains provider-owned and is resolved through the Fireblocks Console or a Co-Signer appliance. See [Fireblocks TAP behavior](/docs/architecture/integrations/custody-providers#transaction-authorization-policy-tap) for the canonical polling and approval flow.

## Luna HSM integration [#luna-hsm-integration]

Luna HSM provides hardware-backed signing through a configured Thales Luna 7 partition. DALP keeps the signer interface consistent with the other backends, while quorum activation remains outside DALP.

* **Partition signing**: The Luna adapter signs EVM transactions, messages, typed data, and raw 32-byte digests through PKCS#11.
* **Scoped wallet labels**: Luna wallet labels encode the organization and system scope so a signer cannot use a wallet outside the calling scope.
* **M-of-N quorum activation**: When the partition is waiting for quorum activation, DALP records a pending provider state and resumes after the out-of-band Luna control process activates the partition.

## Comparing custody providers [#comparing-custody-providers]

| Capability                    | DFNS                       | Fireblocks                                    | Luna HSM                            |
| ----------------------------- | -------------------------- | --------------------------------------------- | ----------------------------------- |
| Signing model                 | Threshold MPC              | MPC-CMP with continuous key refresh           | Thales Luna 7 HSM partition signing |
| Provider policy decision flow | Provider-owned status flow | Console/Co-Signer only                        | Out-of-band quorum activation       |
| Policy engine                 | DFNS policy rules          | Transaction Authorization Policy (TAP)        | HSM M-of-N quorum controls          |
| Wallet model                  | Flat wallet list           | Vault account hierarchy                       | Organization-scoped HSM key labels  |
| DALP signing use              | Configured EVM wallets     | Fireblocks vault wallets for EVM transactions | Hardware-backed EVM signing         |

## Access control and audit [#access-control-and-audit]

* Only Transaction Signer components can request signatures
* Signature requests require valid workflow context
* Rate limiting prevents bulk signature extraction
* All access attempts log for security review

| Operation         | Logged attributes                                                      |
| ----------------- | ---------------------------------------------------------------------- |
| Key generation    | Key identifier, algorithm, storage tier, generator identity            |
| Signature request | Key identifier, message hash, requester identity, workflow correlation |
| Rotation          | Old key identifier, new key identifier, initiator, approval chain      |
| Access denial     | Key identifier, requester, denial reason                               |

## See also [#see-also]

* [Transaction Signer](/docs/architecture/components/infrastructure/transaction-signer) for signature operations
* [Custody Providers](/docs/architecture/integrations/custody-providers) for DFNS, Fireblocks, and Luna HSM provider behaviour
* [Signing Flow](/docs/architecture/flows/signing-flow) for the end-to-end transaction signing sequence