Multisig management system development

Development of multisig management system

Ronin Bridge lost $625M in March 2022 — 5 out of 9 validator keys were compromised. Sky Mavis held 4 keys in one place "for convenience." Multisig existed, threshold existed. But physical isolation of keys — no. Technically correct multisig management system requires proper key storage protocol not less than right smart contract.

This is important to understand before development starts: contract is one part. Second is organizational procedures around it.

Gnosis Safe as foundation

Safe (formerly Gnosis Safe) is de facto standard for multisig management in Web3. Used by Uniswap DAO, Aave, Lido, ENS and hundreds other protocols. Audited multiple times, open source, modular architecture.

Why Safe, not custom contract: 3+ years in production on >$100B TVL — stronger argument than any audit of new contract. Custom multisig developed only with explicit constraints: non-EVM chain, nonstandard quorum logic, privacy requirements.

Safe architecture

Safe works on M-of-N scheme: transaction executes when collecting M signatures from N owners. Under hood — execTransaction() with array of ECDSA signatures in ordered form. Signatures can be collected off-chain (via Safe{Wallet}) or on-chain via approveHash().

// Signature format for Safe
// r (32 bytes) + s (32 bytes) + v (1 byte)
// v=1: approved hash on-chain
// v=2: eth_sign signature
// v>30: EIP-1271 contract signature

Safe Modules: extension without custom contract

Modules are separate contracts with right to call execTransactionFromModule() on Safe. Allows adding automation (daily payouts up to limit X without multisig) without changing main contract.

Standard modules: Allowance Module (delegates spending right up to limit), Safe{Recovery Module} (social account recovery). Custom modules developed for client specifics.

Main module risk: vulnerable module bypasses entire multisig. Any custom module requires audit with same rigor as treasury contract.

When custom multisig needed

Three cases from practice:

Nonstandard quorum rules. Protocol wants: 2/5 signatures for <$10k transactions, 4/5 for $10k-$1M, 5/5 for >$1M. Safe doesn't support dynamic threshold. Solution — Safe + custom guard (SafeGuard), checking transaction amount and requiring additional signatures.

On-chain voting on transactions. If decisions must pass token voting (snapshot + execution via multisig), standard Safe + Governor + Timelock works. If delegated voting with weighted votes needed — custom integration.

Non-EVM chains. For Solana — Anchor program with M-of-N logic via secp256k1 verification or native multisig accounts. For Aptos/Sui — custom Move modules.

Safe Guards: additional control layer

Safe Guard is contract called before and after each Safe transaction. Allows adding restrictions without changing main Safe:

• Whitelist approved recipient addresses
• Transaction amount limits
• Time-based restrictions (no weekend transactions — for regulated protocols)
• Lock ownership changes without additional approval

interface Guard {
    function checkTransaction(
        address to, uint256 value, bytes calldata data,
        Enum.Operation operation, uint256 safeTxGas,
        uint256 baseGas, uint256 gasPrice, address gasToken,
        address payable refundReceiver, bytes memory signatures,
        address msgSender
    ) external;

    function checkAfterExecution(bytes32 txHash, bool success) external;
}

Organizational requirements for system

Technically correct multisig with poor key management is security illusion. Minimum requirements:

• Keys in hardware wallets (Ledger, Trezor), not hot wallets
• Geographic distribution of signers
• Documented process for replacing compromised key
• Regular checks that all signers have access to their keys
• Timelock on top multisig for critical operations

We help not only with technical deployment, but also with operational procedures development.

Process and timeline

Cost calculated individually after describing management requirements: signer count, operation types, automation requirements.