Back to Blog

Secure the Solana Ecosystem (6) — Multi-Sig2

April 24, 2022

0. Review

1. Overview

In the previous post, we discussed the implementation of the Multi-Sig. However, the implementation assumes that the signatures from multiple users can be collected at the same time off-chain. In this post, we introduce a more general Multi-sig program that allows users to sign fully on-chain.

2. Design Of Test Program

The multi-sig program allows valid signers to sign the proposer in separate and anyone can execute the proposer once it is approved (enough signatures are collected). All the test code can be found here.

3. Code Review

This program introduces two more structs and they are TransactionAccount and Transaction. Struct TransactionAccount is designed for recording the account information used for the proposed transaction. Struct Transaction is used to record the information of a proposal. Note that the attribute signers is used to record the number of valid signatures. did_execute and is_initialized ensure the execution and the initialization can only be done once.

The program provides five different instructions. Instruction AllocatePDA aims to create a unique PDA account, and uses it as the multisig account. It will record all the valid signers' information. In instruction InitializeMultisig, we set the number of signatures required to execute the instruction, and the array of valid signers' public keys as well. Instruction CreateTransaction is used to create a proposal while signer can approve the proposal via the instruction approve. Once the number of the approval reaches the threshold set in multisig, the instruction ExecuteTransaction can be invoked to execute the transaction.

To submit a proposal, users can invoke the instruction createTransaction(). It takes three accounts, which are created transaction account, the next two accounts are used by the target transaction. To prevent the account from being re-initialized by malicious users, we check the attribute is_initialized (line 161-163). After that, we init the struct TransactionAccount with specified data and serialize it into the data account(line 188).

In function Approve(), we first check whether the Transaction account and the multisig account are owned by the program. Note that accounts created from other programs may be used by malicious users here if there is no check. Next, we match the pubkey of the signer with the keys stored in multisig account. If matched, it will validate your signature, and change the value to true correspondingly.

In instruction ExecuteTransaction(), we count the number of valid signatures. If the number doesn't reach the threshold, the program will revert.

After that, we init the target Instruction with specified attributes and invoke the instruction of the target program via the function invoke_signed(). We finally set the attribute did_execute to true in case the proposal is executed repeatedly.

We deployed the program on testnet and it can be find in the following link.

https://explorer.solana.com/address/CPzn7ptnJntjUB4NGKqQGRai8NFLNwFaspmJ7nEGbMHe?cluster=testnet

4. Send Transaction

After the deployment, we create the multisig account first and set the multisig account as the admin of the config account when initialize the config account. Related transactions are shown below, and the order is: createMultisig() (in General-Multisig) -> Deploy PriviligeOwner program -> Allocate() (in PrivligeOwner) -> InitializeConfig() (in PrivligeOwner).

https://explorer.solana.com/tx/2vXHmwbCsARstx8wi4eLACbrb6PuZZMktsqU8VnJLp64fvrpaE62QSTn5QLczzxnTvxRLWMSR3dKLGYXZasGMn69?cluster=testnet
https://explorer.solana.com/tx/2EMq9y6HNnXq1n2XsqrBkJd8RGL27PCj5T4JyJ71ZoA3ipUggT6dF6S6uDv4TtxGGKk8BmiAJHS7BFRgZqWjkWVb?cluster=testnet
https://explorer.solana.com/tx/3UhXKsTubUiPqRtLyNYskxvbyrTKHsbeptxuAfJQ348AU4b8gQET2HAMaqxwud6Wo3MKTYHWBneqa9z2WhCpwV6t?cluster=testnet
https://explorer.solana.com/tx/5NA7Yw23uRf48Q3BYM21dtS7gD9YMECij43ZaRLMPe7svt3bsv2TPWwbCRP5akDmttjLEHWZtpqrZrVLNr9QLyJY?cluster=testnet

Next, we invoke instruction InitializeMultisig(). We pass in four accounts and they are the multisig account and three valid signer's accounts. We set the value of m to 2, which means two of the three signers' signatures is required to execute privilege functions.

In function CreateTransaction(), we pass in the created Transaction account, the pubkey of the target program (PrivilegeOwner) and the pubkey of the config account (line 306 -line 307). Besides, we should also set the _data to 3, which corresponds to the instruction unlock() in PrivilegeOwner program.

For the first test, only one signer approves the created proposal. In this case, ExecuteTransaction() fails as limited signatures are collected. The console prints the following output.

Another signer approves the created proposal and invokes ExecuteTransaction(). The total number of signatures has reached to the threshold so that the proposal can be executed successfully.

https://explorer.solana.com/tx/55Qy93RxybsT7c5v9AFgN8Dt1h3AVJfbsosLbstYVB6paY1wmau5sdtLfGpfryXnZTsBNRauvwLSmAu2nABFxVCe?cluster=testnet
https://explorer.solana.com/tx/4XF4MUhL4oftkDt4sn7NoREmGqcDMVP6HGypvJQMtiAbBKiCuy4B98vhQKtvm4mPv7SprrDDVsiwgb6pNwgJcTwz?cluster=testnet

4. Summary

In this article, we introduce the general implementation of the multisig in Solana. The implementation makes use of the feature of PDA, which enables the program to sign the transaction by PDA automatically when the number of valid signatures meets the requirement. Keep following, and we will share more in the upcoming posts.

About BlockSec

BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world in order to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaSuites extension for web3 builders surfing efficiently in the crypto world.

To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.

Official website: https://blocksec.com/

Official Twitter account: https://twitter.com/BlockSecTeam

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.