How to Design a Multi-Signature Wallet with PQC

A multi-signature (multisig) wallet requires multiple private keys to authorize a transaction, a standard for securing high-value assets and DAO treasuries. However, the underlying digital signatures, like ECDSA or EdDSA, rely on mathematical problems that a sufficiently powerful quantum computer could solve using Shor's algorithm. This creates a long-term security risk for any wallet where public keys are exposed on-chain. Post-Quantum Cryptography (PQC) offers cryptographic algorithms designed to be secure against both classical and quantum attacks, making it essential for future-proofing wallet designs.

Designing a quantum-resistant multisig involves replacing the classical signature scheme with a PQC alternative. The National Institute of Standards and Technology (NIST) has standardized several PQC algorithms. For digital signatures, CRYSTALS-Dilithium is the primary recommended algorithm, with Falcon and SPHINCS+ as alternatives. A quantum-resistant multisig smart contract would verify signatures from these algorithms instead of, or in addition to, traditional ones. This requires implementing new signature verification logic in your wallet's smart contract code.

A critical design challenge is state management. Many efficient PQC schemes like Dilithium are stateful, meaning the signer must track which signature index they are on to avoid nonce reuse. For a multisig where multiple parties sign independently, coordinating this state securely is complex. Stateless schemes like SPHINCS+ avoid this issue but produce much larger signatures (~41KB). Your design must choose between the efficiency of stateful schemes with coordinated key management or the simplicity of stateless schemes with higher on-chain gas costs.

Implementation requires updated libraries and tools. For development and testing, you can use the Open Quantum Safe (OQS) project's liboqs library, which provides open-source implementations of NIST PQC candidates. In a Solidity smart contract, you would implement a verifyQuantumSignature function. Due to the computational complexity, verification is often performed off-chain via a zero-knowledge proof (e.g., a zk-SNARK) to minimize gas fees, with the contract only verifying a small proof of correct PQC signature verification.

Migration is a key consideration. A practical approach is a hybrid signature scheme, where a transaction requires both a classical ECDSA signature and a PQC signature from each signer. This provides security during the transition period. Wallets should also implement a key rotation protocol to allow signers to update their long-term PQC public keys on-chain without locking funds. The design must be forward-compatible to integrate newer PQC algorithms as standards evolve after NIST's ongoing standardization process.

A multi-signature (multisig) wallet requires M-of-N signatures to authorize a transaction, where M is the approval threshold and N is the total number of key holders. This is a fundamental security upgrade over single-key wallets, mitigating single points of failure. To design one, you need a solid grasp of digital signature schemes, public-key cryptography (PKI), and how they are implemented on your target blockchain, such as Ethereum (using EIP-712 for structured signing) or Solana (with the @solana/web3.js library). Familiarity with smart contract languages like Solidity or Rust is essential for on-chain logic.

Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to be secure against attacks from both classical and quantum computers. The imminent threat is Shor's algorithm, which can break widely used schemes like ECDSA and RSA. For a PQC multisig, you must understand lattice-based cryptography (e.g., CRYSTALS-Dilithium, Falcon), hash-based signatures (e.g., SPHINCS+), or code-based cryptography. These are the algorithms being standardized by NIST. Your design will involve replacing the classical signing/verification module with a PQC alternative, which impacts signature size, gas costs, and key management.

Development requires specific tools. For Ethereum, you'll use the Foundry framework (with forge and cast) or Hardhat for writing, testing, and deploying smart contracts. You will need a PQC library; options include the Open Quantum Safe (OQS) project's liboqs for C/C++ bindings or a JavaScript/TypeScript wrapper like pqc-js. For testing, you'll simulate transactions on a local Anvil node or a testnet like Sepolia. Understanding how to manage private keys securely in a development environment and how to interact with a wallet's Application Binary Interface (ABI) is non-negotiable.

You must architect your system to handle the unique constraints of PQC algorithms. Signature and public key sizes are significantly larger than their classical counterparts—a Dilithium2 signature is ~2.5 KB, compared to 64-65 bytes for an ECDSA signature. This has major implications for blockchain gas costs and transaction calldata. Your smart contract must efficiently verify these large signatures, potentially using verification optimizations or signature aggregation. Furthermore, you need a strategy for key generation and distribution that maintains security without relying on quantum-vulnerable key exchange protocols.

Finally, consider the user experience and integration layer. How will users generate and store their PQC keys? You may need to modify a wallet provider like MetaMask through its Snaps system or build a custom frontend using WalletConnect and Ethers.js v6 or Viem. The frontend must handle the larger cryptographic payloads and potentially longer computation times for signing. Thorough auditing of both the smart contract and the cryptographic implementation is critical, as PQC is still a nascent field in blockchain. Start by reviewing existing research and implementations, such as the Ethereum Foundation's PQC efforts or the PQ-TLS standard for inspiration.

A multi-signature (multisig) wallet requires multiple private keys to authorize a transaction, significantly enhancing security over single-key wallets. In a post-quantum cryptography (PQC) context, the traditional elliptic curve signatures (like ECDSA) used by wallets such as Safe (formerly Gnosis Safe) become vulnerable. The core architectural shift involves replacing these classical digital signatures with quantum-resistant algorithms, such as those selected by NIST (e.g., CRYSTALS-Dilithium for signing). This protects the wallet's transaction authorization process from future attacks by quantum computers capable of breaking current public-key cryptography.

The smart contract architecture for a PQC multisig wallet must be algorithm-agnostic. Instead of hardcoding signature verification logic for ECDSA, the contract should use a generic verification function that can validate signatures from different PQC algorithms. This is often implemented via a verify function that accepts the signature, message, and public key as bytes, delegating the complex cryptographic verification to a pre-compiled contract or a library. The contract stores a list of approved quantum-resistant public keys for the wallet's owners and defines a threshold (e.g., 2-of-3) for transaction execution. This design ensures upgradability as PQC standards evolve.

Key management presents a major challenge. PQC public keys and signatures are significantly larger than their classical counterparts—a Dilithium2 public key is about 1,312 bytes, compared to 33 bytes for a secp256k1 key. Storing these on-chain is expensive. Optimization strategies include:

• Hashing and On-Chain Registry: Store only a hash (e.g., SHA256) of the public key on-chain, submitting the full key with each signature for in-memory verification.
• Key Aggregation: Use advanced schemes like MuSig2 adapted with PQC, allowing multiple signatures to be combined into one, reducing on-chain data.
• Layer-2 Solutions: Perform signature verification off-chain on a rollup, submitting only a validity proof to the mainnet contract.

A basic Solidity function for generic PQC signature verification might look like this. The contract calls a pre-deployed verifier for a specific algorithm ID.

solidityCopy
interface IPQCVerifier {
    function verify(
        bytes calldata publicKey,
        bytes calldata message,
        bytes calldata signature,
        uint256 algorithmId // e.g., 1 for Dilithium2
    ) external view returns (bool);
}

contract PQCMultisigWallet {
    IPQCVerifier public verifier;
    mapping(address => bytes32) public ownerPublicKeyHash;
    
    function executeTransaction(
        bytes calldata pqcSignature,
        bytes calldata fullPublicKey,
        uint256 algorithmId,
        Transaction calldata txData
    ) external {
        bytes32 keyHash = keccak256(fullPublicKey);
        require(ownerPublicKeyHash[msg.sender] == keyHash, "Invalid owner");
        bytes memory message = abi.encodePacked(txData.to, txData.value, txData.data);
        require(verifier.verify(fullPublicKey, message, pqcSignature, algorithmId), "Invalid PQC sig");
        // Proceed with transaction execution
    }
}

Integrating this architecture requires careful consideration of gas costs and user experience. Each transaction will have higher calldata costs due to large signatures. Wallets and dApps must adapt to handle key generation, storage, and signing with PQC libraries like liboqs. The transition path is gradual: a hybrid wallet could accept both classical ECDSA and PQC signatures, eventually phasing out the former. The ultimate goal is a cryptographically agile system where the smart contract can securely update its accepted signature schemes without requiring asset migration to a new wallet address.

Migrating a Gnosis Safe to use post-quantum cryptography (PQC) is a proactive security upgrade, not a simple signature algorithm swap. The standard Safe uses the ECDSA (Elliptic Curve Digital Signature Algorithm) with the secp256k1 curve, which is vulnerable to attacks from sufficiently powerful quantum computers. A PQC migration involves replacing this core cryptographic primitive with a quantum-resistant alternative, such as a lattice-based scheme like CRYSTALS-Dilithium or a hash-based signature like SPHINCS+. This requires significant changes to the wallet's smart contract logic, signature verification flow, and off-chain tooling.

The primary technical challenge is the signature format and size. A Dilithium2 signature is approximately 2,420 bytes, compared to a 65-byte ECDSA signature. This exceeds Ethereum's calldata limits for simple bytes memory parameters in standard functions. Your migration strategy must therefore redesign the signature handling. Options include: using signature aggregation off-chain before submission, implementing a new isValidSignature function that accepts a structured data type, or utilizing a signature abstraction layer where a relay contract verifies the PQC signature and forwards a validated, condensed proof to the Safe.

A practical migration path involves deploying a new, upgraded Safe singleton contract with PQC-enabled GnosisSafe.sol and GnosisSafeProxyFactory.sol versions. You cannot upgrade the logic of existing proxy contracts directly to such a fundamentally different interface. Instead, you must create a migration module or use the createProxyWithNonce method from a new factory to deploy new PQC-safe proxies. Funds from the old Safe are moved via a execTransaction calling a delegatecall to a migration helper, which must be approved by the old Safe's signers using their legacy ECDSA keys, ensuring a secure transition.

Off-chain components like the Safe Transaction Service, Safe{Wallet} UI, and Safe SDK must be updated to generate, serialize, and submit the new PQC signatures. The @safe-global/safe-core-sdk would need a new signTransaction method using a PQC library such as liboqs. The transaction service's signature validation logic must also be extended. It's crucial to maintain backward compatibility during a transition period, allowing signers to use either ECDSA or PQC signatures until the migration is complete for all signers in a specific Safe.

Thorough testing is essential before mainnet deployment. Use Goerli or Sepolia testnets to deploy your modified Safe contracts and updated front-end. Test all critical flows: Safe creation, adding/removing owners, changing threshold, and executing transactions with PQC signatures. Conduct gas cost analysis, as PQC signature verification on-chain is computationally intensive and will significantly increase transaction costs. Monitor the ongoing NIST PQC standardization process and be prepared to adopt the finalized algorithms, which may require another future migration to the most secure, vetted standard.

Designing a post-quantum cryptography (PQC) multi-signature wallet is a proactive security measure, not a speculative exercise. The transition from classical algorithms like ECDSA to quantum-resistant ones such as CRYSTALS-Dilithium or Falcon involves fundamental changes to key generation, signature schemes, and on-chain verification logic. The core takeaway is that security must be designed in layers: the PQC algorithm forms the cryptographic base, while the multi-signature logic (e.g., M-of-N thresholds, policy engines) and secure key management (HSMs, MPC) provide the operational framework. Always prioritize using NIST-standardized algorithms and well-audited libraries from reputable sources like Open Quantum Safe.

For developers, the next practical steps are clear. First, prototype the signing flow using a PQC library in a test environment, focusing on signature size and gas cost implications for on-chain verification. A Dilithium2 signature is ~2.5KB, significantly larger than a 65-byte ECDSA signature, which impacts transaction costs. Second, design the smart contract verifier. This contract must contain the PQC verification logic, which may require custom precompiles or optimistic verification schemes to manage gas efficiently. Third, integrate with existing wallet standards; consider extending ERC-4337 account abstraction or Safe{Wallet} contracts to house PQC signing logic, ensuring compatibility with the broader Ethereum ecosystem.

Looking ahead, the ecosystem needs continued research and development. Key areas include standardization efforts for PQC signatures in Ethereum (EIPs), the creation of efficient verification precompiles to reduce gas overhead, and the development of hybrid signature schemes that use both ECDSA and PQC for a transitional security model. For ongoing learning, monitor the NIST PQC Standardization Process, follow Ethereum Foundation research on quantum resistance, and experiment with emerging SDKs. Building a quantum-resistant wallet today prepares your project for the long-term future of blockchain security, making it a critical investment for any protocol managing high-value assets or requiring long-term guarantees.