Hot Wallet Security Checklist: Signing Service Controls

Every service, job and person that can ask the signing service for a signature is on a written allow-list with a named owner, and unknown callers are refused.

Each caller proves its own identity to the signer (workload identity or mutual TLS), instead of being trusted because of where it sits on the network.

Every signing path other than the normal withdrawal flow is inventoried. Each one is removed, or put under the same policy, approval and limit checks as withdrawals.

The signing policy is deny-by-default: it lists the transaction and message types it allows, and anything not listed is refused.

The policy covers ALL transaction types, including EIP-7702 set-code transactions (type 0x04) and the authorization messages that are signed for them (prefix 0x05). Delegation is either blocked or limited to an approved list of delegate addresses.

For each signature the policy checks destination, asset, amount and, for contract calls, the function being called, against an allow-list of counterparties.

Transfers above a threshold, and any change to signing policy, need approval from different people on a channel separate from the system that requested the signature.

Approvers see the decoded transaction (destination, amount, what the call does) produced by software independent of the requesting interface, and compare it to the intended action.

The person or device that requests a signature can never also be the one that approves it, and approvers use hardware-backed credentials.

Each hot wallet has per-asset, per-window value caps enforced by the signer itself, not only by the application that calls it.

Hot wallets hold a bounded float. Refills from cold storage are a separate, approved flow with their own review.

Velocity limits cap how many signatures a wallet or a caller can obtain per minute. Breaching one pauses signing and pages a human.

A large transfer out of any hot wallet raises an alert to an on-call human within minutes, whatever path requested it.

Alerts go to a person who has the authority and a tested route to halt signing. An alert that only creates a ticket is not a control.

Signing requests are scored for behaviour: new caller, unusual hour, new destination, a transaction type never signed before.

There is a documented kill switch that halts signing at the signing layer (policy engine or key shares), not only the withdrawals interface or API.

The runbook states what the kill switch does NOT stop: authority already granted on-chain (delegations, approvals), transactions already broadcast, and other chains.

On-call staff can trigger the kill switch without a long approval chain, and nothing running on the protected systems can disable it.

The pipeline that deploys wallet-service containers sits in a different trust zone from the signing service. Deploying code cannot by itself grant signing access or change signing policy.

Changes to the signing service, its policy or its configuration need review by a second person, and deploying into the wallet environment needs an approver other than the deployer.

The wallet environment can be rebuilt from signed, known-good images in a clean environment, and drift from the baseline is detected.

No long-lived deployment or permission token is stored on any workstation. Credentials are short-lived and issued at deploy time.

Tokens are scoped to one environment and one action, bound to a device or identity, and any use from an unexpected host raises an alert.

Workstations and repositories are scanned for stored credentials. After any device replacement or install anomaly, the credentials and tokens the person could reach are rotated and their colleagues’ exposure is reviewed.

People with wallet or signing access do that work on dedicated, hardened devices. Their everyday browsing, chat and email happen elsewhere.

Code from outside the company (recruiter assignments, take-home tests, repositories shared in chat) runs only in a disposable, isolated environment, never on a work computer.

Developer tools are installed from approved internal mirrors or vetted vendor paths, not from search-engine results. An install anomaly is treated as exposure of the whole team.

Internal AI tools run with least privilege. They cannot reach other engineers’ machines, deployment credentials or the signing environment, and their access is logged and reviewed.

Key shares sit with different parties, hosts and administrators, so one compromised machine or one administrator cannot reach the signing threshold. Who holds each share is written down.

Changes to the signing threshold, quorum membership or share holders need multi-person approval and raise an alert.

Policy is enforced by the participants in the signing quorum, not only by the coordinator that receives requests, so a compromised coordinator cannot widen what gets signed.

Recovery, resharing and share rotation procedures are written and have been exercised, including the emergency signing path used for revocations.

For every chain and mechanism where an attacker could leave standing authority (EIP-7702 delegations, token approvals, session keys, module or owner changes), there is a revocation runbook with owner, steps and a time estimate.

The first-hour runbook lists contacts for stablecoin issuers, exchanges, blockchain analytics firms and law enforcement, and who calls whom.

Decision rights are explicit: who may suspend withdrawals, trigger the kill switch and speak publicly, with holding statements prepared.

The kill switch is tested at least quarterly in a production-like environment, and the time from decision to signing stopped is recorded.

You have drilled a revocation: delegate a wallet that holds no value to a harmless contract on a test network, then clear it through your real custody path, and record how long it took.

A tabletop or red-team exercise runs the whole chain: a lure aimed at a developer, a workstation foothold, a stolen deploy token, then a request to the signer. It measures time to detect and time to stop.