Institutional Custody Solution Development

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
Institutional Custody Solution Development
Complex
from 2 weeks to 3 months
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1214
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1041
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

Institutional Custody Solution Development

Retail wallet manages keys for one person. Institutional custodian manages keys on behalf of organization with multi-level policies, audit log, compliance requirements, and responsibility to regulators. This is different class of problems. MetaMask doesn't fit like Excel doesn't fit banking accounting.

Institutional custody covers: hedge funds, DAO treasury, crypto exchanges (internal treasury), family offices, payment providers. Common requirements: multi-party authorization, segregation of duties, hardware key isolation, complete audit trail, policy enforcement on-chain and off-chain.

Key Architectural Decisions

MPC vs Multisig: Fundamental Difference

Two dominant approaches to institutional key storage — MPC (Multi-Party Computation) and Multisig (on-chain). Choice between them determines entire solution architecture.

Multisig (Safe{Wallet} / Gnosis Safe): keys exist as separate private keys held by each signer. Smart contract requires M-of-N signatures for transaction execution. All on-chain, transparent, auditable.

MPC Threshold Signature Scheme (TSS): single private key never exists wholly in one place. Generated as N shards via Distributed Key Generation (DKG), each shard stored separately. For signing each shard participates in computation, resulting signature is standard ECDSA/EdDSA, indistinguishable from single-key. On-chain no indication of multi-party.

Parameter Multisig (Safe) MPC (TSS)
On-chain privacy Public M-of-N Standard signature, unnoticed
Gas cost Higher (contract call) Standard (EOA-like)
Chain support EVM-only natively Any chain (Bitcoin, Solana, TON)
Key recovery Difficult without quorum Possible via key refresh
Smart contract risk Yes (contract bugs) No
Regulatory familiarity High (auditable) Low (less understood by auditors)

For EVM-only — Safe{Wallet} with custom modules more convenient. For multichain treasury with Bitcoin, Solana, TON — MPC only path. Many large solutions (Fireblocks, Copper) use MPC for this reason.

Policy Engine

Policy Engine is set of rules determining when and who must authorize transaction. This is core element of institutional custody, distinguishing it from just "multisig."

Typical rules:

IF transfer.amount < $10,000 AND transfer.asset IN [USDC, USDT] 
    THEN require 1-of-3 (Trader role)

IF transfer.amount >= $10,000 AND transfer.amount < $100,000
    THEN require 1-of-3 (Trader) AND 1-of-2 (Risk Manager)

IF transfer.amount >= $100,000
    THEN require 2-of-3 (Executive) + time delay 4h + notification to Compliance

IF transfer.destination NOT IN whitelist
    THEN BLOCK + alert to Security team

Policy Engine can be on-chain (like Safe Guard — smart contract validating each transaction before execution) or off-chain (approval workflow in backend, on-chain only final signature).

Safe Guard — most reliable option for EVM: each execTransaction call in Safe passes through checkTransaction guard-contract. Policies impossible to bypass even if all keyholders agreed.

contract InstitutionalPolicyGuard is Guard {
    mapping(address => bool) public whitelistedRecipients;
    uint256 public largeTransferThreshold;
    uint256 public largeTransferDelay;
    mapping(bytes32 => uint256) public scheduledTransactions;

    function checkTransaction(
        address to,
        uint256 value,
        bytes memory data,
        Enum.Operation operation,
        uint256 safeTxGas,
        uint256 baseGas,
        uint256 gasPrice,
        address gasToken,
        address payable refundReceiver,
        bytes memory signatures,
        address msgSender
    ) external override {
        // Whitelist check
        require(whitelistedRecipients[to], "Recipient not whitelisted");

        // Large transfer delay check
        if (value > largeTransferThreshold) {
            bytes32 txHash = keccak256(abi.encode(to, value, data));
            require(
                scheduledTransactions[txHash] != 0 &&
                block.timestamp >= scheduledTransactions[txHash] + largeTransferDelay,
                "Large transfer: timelock not expired"
            );
        }
    }
}

Hardware Security Module (HSM) Integration

In enterprise custody keys or MPC shards stored in HSM — specialized hardware device from which private key never exits in plaintext. Signing happens inside HSM.

HSM options for crypto:

AWS CloudHSM / Azure Dedicated HSM — cloud HSM, FIPS 140-2 Level 3. Scalable, no physical device at customer. Fireblocks uses cloud MPC based on similar solutions.

Thales Luna / nCipher — physical HSM. Installed in customer infrastructure or colocation data center. Regulators in some jurisdictions (Germany, Switzerland) require physical HSM.

YubiHSM2 — budget option ($650). Insufficient for serious institutional but suitable for MVP or small fund.

HSM integration into custody stack:

[Approval Workflow] → [Policy Engine] → [HSM Signing Service] → [Blockchain]
                                              ↑
                              Private key/MPC shard never leaves HSM

With MPC: each shard stored in separate HSM (different cloud providers or physically different locations). DKG and signing protocol run between HSMs via secure channel.

Transaction Authorization Workflow

Segregation of Duties

Principle: person initiating transaction shouldn't be able to authorize it alone. Not only best practice — requirement of many financial regulators.

Roles:

  • Initiator — creates transaction in system, has no signing key
  • Approver (1st level) — operations person, signs transactions below threshold
  • Approver (2nd level / Risk Manager) — for large amounts
  • Executive Approver — for critical operations
  • Compliance Officer — view only, receives alerts
interface TransactionRequest {
    id: string;
    initiatedBy: string;           // email/ID, has no keys
    to: string;
    value: bigint;
    asset: string;
    chain: string;
    businessJustification: string;
    requiredApprovals: ApprovalLevel[];
    currentApprovals: Approval[];
    status: 'pending' | 'approved' | 'rejected' | 'executed' | 'failed';
    createdAt: Date;
    expiresAt: Date;               // transaction cancelled if not signed in time
}

Approval via HSM-backed Signature

Approver authorizes via hardware device (YubiKey or Ledger in enterprise context). System doesn't accept software keys from approvers — only hardware-backed signature. Protects from compromised workstation.

Audit Trail and Compliance

Every action logged immutably: request creation, each approval/rejection, who viewed transaction, policy changes, policy violation attempts. Timestamp, IP, user agent.

For enterprise: SIEM system integration (Splunk, Elastic) via webhook or API. Auditors must have read-only access to complete log.

On-chain logs automatically provide part of audit trail. Off-chain approval workflow needs append-only log storage (PostgreSQL + immutable audit table, or Merkle tree structure for tamper evidence).

Travel Rule and Compliance

FATF Travel Rule requires transmission of originator and beneficiary info on transfers above $1000/$3000 (depending on jurisdiction). Institutional custody must integrate with Travel Rule protocols: TRISA, VerifyVASP, Sygna Bridge.

Technical implementation: before executing transfer system sends travel rule data to receiver's VASP, receives confirmation, only then executes transaction. Requires API integration with one of protocols.

Disaster Recovery

What happens if quorum lost? If 2 of 3 keyholders died, quit, or lost keys — need emergency recovery mechanism.

Safe Dead Man's Switch. If no transactions happen for N days, emergency key gets ability to take action. Emergency key stored with notary or in hardware sealed envelope.

MPC Key Refresh. On participant replacement shards updated via re-sharing protocol without changing public key (address). New participant gets new shard, old destroyed.

Cold Recovery Kit. Encrypted backup on physical media in different geographic locations. Decryption requires physical presence of multiple holders.

Stack and Tools

Component Technologies
On-chain custody Safe{Wallet} + Safe Guard + Safe Modules
MPC (if needed) Fireblocks SDK / Tss-lib (Binance) / ZenGo MPC
HSM integration AWS CloudHSM SDK / PKCS#11 for physical HSM
Policy Engine Custom backend (Node.js/Go) + Safe Guard (on-chain)
Approval workflow React admin UI + WebSocket real-time notifications
Audit log PostgreSQL + immutable audit table / Apache Kafka
Travel Rule TRISA SDK / Notabene API
Notifications Slack/Telegram bot + email for approvals

Development Process

Analytics and Design (2-3 weeks). Regulatory requirements of specific jurisdiction, roles and segregation of duties, MPC vs multisig decision, HSM choice, travel rule obligations.

Policy Engine and Workflow (3-4 weeks). Authorization workflow backend, policy rules engine, approval UI, notification system.

Custody Layer (3-5 weeks). Safe Guard contract with policy enforcement, MPC/HSM integration, on-chain execution.

Compliance and Audit (2-3 weeks). Audit log, travel rule integration, reporting for regulators.

Testing and Audit. Security audit of contract, penetration testing backend, disaster recovery drill.

MVP (Safe + basic approval workflow without HSM) — 8-12 weeks. Full institutional solution with MPC, HSM, travel rule, compliance reporting — 5-8 months. Cost calculated after detailed scope.