Token Program Multisig Guidelines (May 2025)

General
1

Hey all,

The Governance Team has just published a set of Multisig Guidelines to support the ongoing security of Token Programs.

You can read the guidelines here:
:point_right: Multisig Guidelines – Token Program

As always, feedback is welcome—drop your thoughts or questions below.

4 Likes
2

Hi! First of all, we’re glad to see a Multisig Guideline, since security is an unavoidable matter which tends to become evident once it’s too late. Therefore, tackling it in advance is the right way to proceed.

When it comes to the Guidelines themselves, we think that the thresholds sound logical, and we mostly agree with all the recommendations given. Nevertheless, due to the importance of the task of being a ‘multisigner’ within Token Programs, we would like to leave some suggestions intended to strengthen the security precautions even further. Therefore, we believe it would be good to:

  • Have an exhaustive list of approved hardware wallets for this task;
  • For Medium and High signers, require two hardware wallets for each key/multisig with the same PIN, one as the primary device and the other one as backup. After confirming that both devices can create valid signatures, the seed phrase should be destroyed;
  • For all signers, hardware wallets must not be reused on different multisigs simultaneously;
    For all signers, hardware wallets must not be used for any activities other than signing multisig transactions;
  • Keys should be rotated every certain period, let’s say two years; and
  • Multisigs should avoid changing the number of signers without approval from the Token Assembly; and
  • A good practice is to use the ‘approve’ function, if available, when transferring tokens.

Lastly, we believe that the approach taken by other DAOs, such as Gitcoin and Optimism, regarding required training before participating as a multisig signer, certainly decreases the risk of compromised multisig signers. Something like a 30-minute call with security specialists from the Security Council or the Foundation in which security recommendations, tools and practices are presented, should be enough.

All in all, we believe that by adding these extra measures to the already well-thought-out Multisig Guidelines drafted by the Governance Team, security when handling this critical task would be increased to the peace of mind of everyone involved.

2 Likes
3

Hey @SEEDGov! Apologies for the slow reply - thanks for sharing your feedback!

I would like to start by saying that the guidelines shared above are not enforceable. The purpose of the guidelines is to provide a starting point for Token Program leads/proposal authors to reference when designing a program that may require a multisig. Program leads and proposal authors can choose to add additional layers of security depending on the amount that the multisig controls or the importance of the contract they are the admin of.

Good observation. We will reach out to our security advisors and ask for a list of hardware wallets.

We can add these two suggestions to the “For high-risk multisig, here are additional measure to consider:” list under the Signer Guidelines Checklist.

Agree. This is included under the Signer Guidelines Checklist.

Multisigs may have to change the number of signers for a variety of reasons throughout a program. We’ve added in the guidelines that any changes of multisig signers should be communicated publicly on the governance forum.

In addition, all multisig signers in relation to a Token Program will be contractually bound to deliver the scope of each Token Program through ZKGPS. The Token Assembly is allowed to “pull the plug” on a Token Program at any time by passing a TPP to remove the minter role from all relevant capped minters if they do not agree with the changes to a multisig.

In most cases, multisig signers for Token Programs will never have custody of minted tokens. Rather, they will be managing capped minter contracts / minting rights to capped minter contracts.

2 Likes