# Key Guardian Source: https://docs.settlemint.com/docs/architects/architecture/components/infrastructure/key-guardian Understand how DALP routes each signing request to local signing, DFNS, Fireblocks, or Luna HSM while keeping custody-provider policy outside the business workflow. ## Overview [#overview] Key Guardian is DALP's signer routing layer. When a workflow needs a signature for an EVM transaction, message, typed data payload, or UserOperation, the workflow calls the Transaction Signer. The Transaction Signer prepares the request, and Key Guardian sends it to the signer backend configured for that deployment. Read this page when you need to know where key control sits in a DALP deployment. For the full path from policy checks to broadcast and confirmation, read [Signing Flow](/docs/architects/architecture/flows/signing-flow). For custody model selection, read [Custody Providers](/docs/architects/architecture/integrations/custody-providers). ## Where signing requests go [#where-signing-requests-go] Key Guardian does one job: route the prepared signing request to the active backend and return the result. It does not replace the custody provider console, approval app, vault policy, or HSM operator process. Secret managers support selected integrations by storing runtime credentials and configuration values. They do not sign transactions and they do not define custody policy. ## Supported signer backends [#supported-signer-backends] | Backend | Protection model | What DALP sends | Typical use | | ------------ | ---------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Local signer | Private key material available to the deployment runtime. | The prepared payload and the configured local wallet reference. | Evaluation environments or controlled self-hosted deployments where the operator may hold runtime signing material. | | DFNS | DFNS wallet custody with provider policy controls. | The prepared payload and DFNS wallet context. | Managed MPC custody for EVM transaction and message signing. | | Fireblocks | Fireblocks vaults, workspace policy, and provider approval flow. | The prepared payload and Fireblocks vault wallet context. | Institutional custody workflows that already use Fireblocks controls. | | Luna HSM | Luna partition keys with HSM access and quorum controls. | The prepared payload and the configured Luna key reference. | Deployments that require hardware-backed EVM signing and operator quorum. | ## Request handling [#request-handling] The business workflow does not branch on DFNS, Fireblocks, Luna, or local signing. It passes the wallet reference, payload, and expected signer address scope to the signing layer. Key Guardian loads the active provider and returns one of three outcomes: | Outcome | What it means | What the workflow can do next | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | Signature or signed transaction | The active backend completed the request. | Continue with broadcast, confirmation tracking, or the next workflow step. | | Pending provider approval | The backend needs provider policy approval, HSM quorum activation, or another external custody step before a signature is available. | Surface the pending state, wait, poll, or retry through the workflow path that owns the operation. | | Terminal configuration or authorization error | The configured wallet, expected address, credentials, or provider state cannot satisfy the request. | Stop the operation and correct the wallet mapping, address scope, provider policy, or deployment configuration. | This boundary keeps workflow behavior stable when the signer backend changes by deployment. A workflow can request a signature without knowing whether final approval happens in DFNS, Fireblocks, Luna HSM, or the local runtime. ## Wallet references and address checks [#wallet-references-and-address-checks] DALP records provider wallet references alongside the participant, issuer, or organisation context that needs to sign. The signer path uses those references to target the correct provider wallet and check that the returned address matches the expected on-chain actor. That address check matters in regulated issuance workflows. A claim issuer, transfer agent, or organisation signer must sign from the expected address scope, not merely from any key held by the same custody provider. ## Provider responsibilities [#provider-responsibilities] Key Guardian routes signing work. The provider remains responsible for provider-side custody controls. | Responsibility | DALP boundary | Provider or operator boundary | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Wallet selection | Store and pass the wallet reference tied to the DALP actor that must sign. | Maintain provider wallet inventory, vault structure, HSM key labels, and approval users. | | Policy approval | Surface pending, approved, denied, expired, blocked, or error states returned by the signer backend. | Evaluate custody rules, mobile approvals, policy thresholds, HSM quorum, and recovery procedures. | | Evidence | Record platform workflow state, request status, returned signatures, transaction identifiers, and provider errors needed to continue or retry the business process. | Preserve provider approval logs, custody audit trail, wallet lifecycle evidence, and HSM partition records. | | Runtime credentials | Read credential references for the selected integration through the deployment's secret manager. | Protect API keys, partition credentials, provider service accounts, and operational recovery material. | ## Failure and pending approval states [#failure-and-pending-approval-states] Local signing usually returns a signature or an immediate error. DFNS, Fireblocks, and Luna HSM can involve provider-side approval, policy checks, quorum activation, or temporary provider failures before a signature is available. DALP returns those states to the calling workflow so the operator can continue from the right place: wait for approval, retry a transient provider failure, or correct an address or wallet configuration problem. The workflow state stays in DALP. Provider policy decisions and custody audit records stay in the custody or HSM system. ## Choosing a signer backend [#choosing-a-signer-backend] Choose the signer path from the custody and operational controls required by the deployment: 1. Use local signing only when the deployment operator is allowed to hold runtime signing material. 2. Use DFNS or Fireblocks when custody policy, approvals, and provider audit records should live in an external custody platform. 3. Use Luna HSM when the deployment requires hardware-backed EVM signing and quorum-controlled access. 4. Confirm wallet references and expected signer addresses before issuing assets, changing claim issuers, or approving regulated transfers. For production programmes, choose a signer path that matches the organisation's custody policy. Confirm recovery steps, incident response ownership, and evidence export before asset issuance starts. ## See also [#see-also] * [Transaction Signer](/docs/architects/architecture/components/infrastructure/transaction-signer) * [Custody Providers](/docs/architects/architecture/integrations/custody-providers) * [Signing Flow](/docs/architects/architecture/flows/signing-flow) * [Wallet Verification](/docs/compliance-security/security/wallet-verification) * [Rotate provider claim signer key](/docs/operators/runbooks/rotate-provider-claim-signer-key)