Multisig Contract 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
Multisig Contract Development
Medium
~2-3 business days
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1215
  • 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
    1043
  • 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

Multisig Contract Development

Multisig is not about paranoid security. It's about ensuring that no single person on the team can unilaterally withdraw the treasury, update the contract, or change a critical protocol parameter. With $3M in treasury, one compromised Ledger or leaked private key is enough — and recovery is impossible.

Gnosis Safe vs Custom Multisig

Most tasks are covered by Safe (Gnosis Safe) — an audited contract with 4+ years on mainnet, $100B+ under management, support for all EVM networks. Under the hood — an M-of-N threshold scheme: M signatures out of N authorized owners. Safe stores transactions on chain, each owner signs off-chain (EIP-712 structured data), when M signatures are collected — anyone can execute.

When a custom multisig is needed:

  • Non-standard authorization logic (timelock + multisig + DAO vote)
  • On-chain voting with weights (weighted multisig)
  • Specific execution conditions (only after an oracle event)
  • TON, Solana, Aptos — where Safe doesn't exist

What's Behind "M-of-N Signatures"

Implementing a multisig in Solidity is textbook material for auditors, because they regularly find one and the same class of problems.

Replay attack. A contract takes a list of signatures and verifies them. If nonce isn't included in the signed hash — the same transaction can be replayed. Correct structure: keccak256(abi.encode(to, value, data, nonce, chainId)). ChainId is mandatory — otherwise a signature valid on Ethereum mainnet is accepted on Polygon.

Signature malleability. ECDSA has two valid signatures for one message (s and -s mod n). OpenZeppelin ECDSA.recover handles this correctly from version 4.x, checking s <= secp256k1n / 2. Home-grown ecrecover without this check allows duplicating one owner's signatures.

Duplicate signer. A contract collects N signatures, checks each against the owners list, but doesn't check signer uniqueness. Attack: one owner provides M signatures of the same message — the transaction executes with M/N = 1 actual participant. Protection: require(signer > lastSigner) — sorting addresses in ascending order guarantees uniqueness.

Here's the minimal correct checklist for signature verification:

function _verifySignatures(
    bytes32 txHash,
    bytes[] calldata signatures
) internal view {
    require(signatures.length >= threshold, "Below threshold");
    address lastSigner = address(0);
    for (uint256 i = 0; i < signatures.length; i++) {
        address signer = ECDSA.recover(txHash, signatures[i]);
        require(isOwner[signer], "Not an owner");
        require(signer > lastSigner, "Duplicate signer"); // key check
        lastSigner = signer;
    }
}

Timelock as a Mandatory Layer

A 2-of-3 multisig with three keys in one office — not a multisig in terms of security. Real protection — a combination of multisig with TimelockController (OpenZeppelin). A transaction backed by M signatures is queued with a delay (usually 24-72 hours). Within this window, the community can notice malicious action.

For protocols with TVL > $1M, TimelockController with 48-hour delay is baseline. The minDelay parameter is set at deployment and cannot be reduced by the timelock itself (only through governance vote or multisig).

Weighted Multisig and DAO Integration

If signers have different weights (VC fund with 40% voting power vs individual contributors with 5% each) — we need a weighted scheme. Implement via mapping weights[address] and check totalWeight >= requiredWeight instead of threshold by count.

Integration with Governor (OpenZeppelin) allows building hybrid schemes: small operations (up to X ETH) — via multisig, large ones — via DAO vote with timelock.

Multisig on Solana and TON

On Solana we use Squads Protocol — Safe's analogue for Solana. Squads v4 supports programmable spending limits, roles, Serum/Jupiter integration. We write custom multisig on Anchor when Squads doesn't cover the logic.

On TON — custom implementation in Tact or FunC. Official TON multisig wallet (from TON Foundation) works for simple TON storage cases. For jettons and complex logic — custom contract with bounce message handling.

Timelines

Integrating Safe + configuring owners/threshold + deploying TimelockController — 2-3 days. Custom multisig in Solidity with full test coverage — 3-5 days. Weighted multisig with DAO integration — 1-2 weeks.