Multi-Approval for Institutional Wallets

One compromised key — and the fund's assets are gone in minutes. Institutional clients — DAOs, hedge funds, family offices — cannot rely on a single point of failure. A multi-approval system solves this: it combines on-chain multisig (Safe{Core}) with off-chain policies, HSM integration, and a full

Blockchain Development Services

Frequently Asked Questions

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1441
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    998
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1267
  • image_logo-advance_0.webp
    B2B Advance company logo design
    713
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    1003

One compromised key — and the fund's assets are gone in minutes. Institutional clients — DAOs, hedge funds, family offices — cannot rely on a single point of failure. A multi-approval system solves this: it combines on-chain multisig (Safe{Core}) with off-chain policies, HSM integration, and a full audit trail. We have 5+ years of experience developing such systems for 20+ projects. We guarantee asset protection and compliance with stringent requirements. Implementing multi-approval prevents the loss of millions of dollars — statistics show that 80% of DAO treasury incidents occur due to the lack of multi-level approval. Savings from implementation can reach $500k per year for transaction volumes above $10M, and the average cost of a single security incident is $2M.

Technical complexities that multi-approval eliminates

Key compromise — one private key does not grant full control. Even if an attacker gains access to one approver, they cannot withdraw assets — N signatures are required. For HSM keys, the private key never leaves the secure hardware. Human error — a mistaken transaction is blocked at the policy check stage. The Policy Engine rejects transfers to unknown addresses or amounts exceeding the daily limit of $10k. Audit and compliance — every step is logged: who created the request, who approved, from which device. Export logs in auditor format with SIEM integration via webhook. Flexible management — roles are separated (Admin, Initiator, Approver, Executor, Auditor). Policies change without redeploying smart contracts — updates via API take minutes.

How multi-approval works for institutional wallets

We use two layers: on-chain multisig and off-chain policies. On-chain ensures immutable execution of transactions when the signature threshold is reached. Off-chain adds flexibility: amount limits, address whitelists, time-locks, the four-eyes principle. The combination provides security and adaptability.

Aspect On-chain multisig (Safe) Off-chain policies (Fireblocks-like)
Execution Smart contract Smart contract + policy engine
Flexibility Low (only threshold) High (limits, roles, time-locks)
Policy changes Contract migration Configuration update without contract
Security Keys on client HSM + physical protection
Implementation cost Low Medium/high
Policy type Example configuration Change time
Spending limit $50k/day USDC 5 minutes via API
Whitelist List of approved addresses 10 minutes with Admin approval
Time-lock 24 hours for amount >$100k Fixed in config

Detailed system architecture

Policy Engine — service that stores and enforces rules:

  • Whitelist of recipient addresses
  • Spending limits (daily, weekly per token)
  • Time-based rules (transactions only during UTC working hours)
  • Amount thresholds (up to $10k — 2 signatures, above $100k — 5 signatures)
  • Asset-specific rules (operations with certain tokens require CFO approval)

Approval Workflow Engine — manages request states: PENDING_APPROVAL → COLLECTING_SIGNATURES → READY_TO_EXECUTE → EXECUTED ↘ REJECTED ↙ Each transition is logged with timestamp and actor_id — mandatory for compliance.

Signature Aggregator — collects EIP-712 (or EIP-1271 for smart contracts) signatures. Stores partial signatures until threshold.

Notification Service — notifies approvers via email, Telegram, Slack with a deep-link for quick approval.

HSM integration — for large institutions, approver keys are stored in AWS CloudHSM or Azure Dedicated HSM. Signing occurs inside HSM without exporting the private key. Implementation:

import * as pkcs11js from "pkcs11js"; class HSMSigner { private pkcs11: pkcs11js.PKCS11; async sign(txHash: Buffer, keyLabel: string): Promise<Buffer> { const session = this.pkcs11.C_OpenSession(this.slotId, pkcs11js.CKF_SERIAL_SESSION); this.pkcs11.C_Login(session, pkcs11js.CKU_USER, this.pin); const privateKey = this.findKeyByLabel(session, keyLabel); this.pkcs11.C_SignInit(session, { mechanism: pkcs11js.CKM_ECDSA }, privateKey); const signature = this.pkcs11.C_Sign(session, txHash, Buffer.alloc(64)); this.pkcs11.C_Logout(session); this.pkcs11.C_CloseSession(session); return this.convertToEthSignature(signature); } } 

Key point: private key never leaves HSM.

Safe{Core} — de facto standard for Ethereum. A transaction requires accumulation of off-chain signatures and a final execute call. Transaction structure:

struct SafeTx { address to; uint256 value; bytes data; Enum.Operation operation; uint256 safeTxGas; uint256 baseGas; uint256 gasPrice; address gasToken; address refundReceiver; uint256 nonce; } 

Why combine on-chain and off-chain policies?

A pure on-chain multisig adapts slowly to new requirements: any policy change requires contract migration. The off-chain Policy Engine is 10x faster — limits and roles change via API without gas. And on-chain execution guarantees that policies cannot be bypassed. For transactions above a threshold — a mandatory time-lock (e.g., 24 hours), during which other owners can cancel. Emergency pause freezes all outgoing activity upon compromise. Get a consultation on your system architecture — we will assess the risks of your current solution.

Implementation process

  1. Requirements audit: analysis of current infrastructure, roles, compliance needs. Risk assessment.
  2. Design: architecture selection (on-chain only Safe or with off-chain engine), policy design, role model.
  3. Implementation: smart contract development (Safe Modules), backend (Node.js + PostgreSQL), frontend (React + wagmi), HSM integration.
  4. Testing: unit tests, integration tests, fuzzing (Echidna), formal verification (SLither, Mythril).
  5. Security audit: external audit of contracts and entire system. Fixes.
  6. Deployment and training: deployment in client infrastructure, CI/CD setup, team training.

Timeline and what's included

Estimated timeline:

  • Basic system (Safe + workflow + UI): 8–10 weeks
  • With HSM integration: +3–4 weeks
  • With compliance/audit export: +2 weeks
  • Security audit: +3–6 weeks
  • Total production-ready: 4–5 months

What's included:

  • Set of Safe Modules smart contracts
  • Backend (API Policy Engine + Workflow Engine)
  • Frontend management panel
  • Integration with HSM (AWS/Thales/Utils)
  • Audit logs and export
  • Documentation and training
  • Post-launch support (2 months)

Pricing is determined individually after a requirements audit. Savings from implementing multi-approval can reach $500k per year for transaction volumes above $10M, as confirmed by our project experience.

Order a multi-approval system implementation today. Get a consultation — we will assess the risks of your current solution and propose an architecture. Protect your assets with a multi-approval system proven on 20+ projects.

According to Wikipedia, multisig is used to enhance the security of cryptocurrency wallets.