Modern multisig attacks may involve a twofold threat:

1. Malware infections on signer devices that compromise the transaction approval process.

2. UI hacking, where the user interface (or its underlying code) is manipulated to present false or benign-looking information while actually instructing signers to authorize malicious transactions.

This self-assessment form enables you to evaluate your team’s vulnerability along both dimensions without requiring disclosure of any sensitive internal procedures. Use it to assign scores for each criterion and identify actionable improvements.

How to Use This Form:
For each criterion, assign a score from 0 (High Risk) to 5 (Low Risk). Then indicate your risk category (Low, Medium, High) based on the score. The accompanying recommendations below the form explain how increasing your score in each area will reduce both malware and UI exploitation risks. You may sum or average the scores to gauge overall security. 

Self-Assessment Form

Use the table below to record your team’s evaluation for each criterion:

1. Signing Threshold (n/m Multisig Setup)

Score (0-5):

• 0 (High Risk): A highly imbalanced threshold - if too few signatures are required (low n), a single compromised device or hacked UI on one machine can trigger an unauthorized transaction; if too many are required, the increased number of devices creates more attack vectors (high m), and increases the chances that insufficient signers are available to execute a high priority transaction. 

• 5 (Low Risk): A balanced, well-thought-out n-of-m configuration that minimizes the chance that any single or small group of compromised signers (via malware or UI manipulation) can execute a transaction.

Explanation:
A carefully chosen multisig threshold ensures that no attacker can exploit a single compromised environment - whether through malware or a hacked UI - to meet the signature requirement. Striking the right balance limits the attack surface while ensuring operational efficiency.

Recommendation:
Regularly re-assess your n-of-m configuration. A threshold like 3-of-5, for example, is often a good compromise: it prevents a lone compromised signer (or a hacked UI on one device) from being sufficient to authorize a transaction, while still being manageable operationally.

2. Hardware Wallet Homogeneity

Score (0-5):

• 0 (High Risk): All signers use the same hardware wallet brand/model, which creates a single point of vulnerability if that vendor’s device or its UI firmware is exploited.

• 5 (Low Risk): A mix of hardware wallet brands (e.g., Ledger, Trezor, Coldcard) that reduces the risk of a single vendor-specific exploit - whether malware-driven or UI-based.

Explanation:
Using identical hardware across signers means that if an attacker discovers an exploit (for instance, a vulnerability in the wallet’s UI firmware), every device is at risk. A heterogeneous mix forces an attacker to overcome multiple independent vulnerabilities.

Recommendation:
Increase diversity by incorporating different reputable hardware wallets. This makes it harder for an attacker to deploy a one-size-fits-all exploit that compromises the UI or firmware across all devices.

3. Signing Device Homogeneity

Score (0-5):

• 0 (High Risk): All signing devices run the same operating system and hardware configuration, exposing them to common exploits that can alter the UI and inject malicious code.

• 5 (Low Risk): A varied mix of operating systems (macOS, Linux) and device types (desktop, laptop, mobile), and software/hardware wallets, making it more challenging for malware or a hacked UI module to affect all signers simultaneously.

Explanation:
Homogeneous signing environments not only increase the risk of widespread malware infection but also mean that if the UI libraries or frameworks are exploited on one platform, all signers might see the same manipulated display. Diversity in devices and operating systems helps ensure that a compromise on one platform doesn’t translate into a full-scale attack.

Recommendation:
Encourage diversity in operating systems and device types among signers. This layered approach creates hurdles for attackers who rely on replicating the same UI exploit or malware across every signing environment.

4. Dedicated Signing Devices

Score (0-5):

• 0 (High Risk): Signing is conducted on devices that are also used for everyday activities (email, browsing, etc.), exposing them to a broad range of threats including UI spoofing malware.

• 5 (Low Risk): All signers use dedicated, hardened devices solely for signing transactions, reducing the likelihood of exposure to general malware and UI compromise risks.

Explanation:
When signing devices are used for multiple purposes, they’re more likely to be exposed to phishing attacks or malicious downloads that can alter the UI or inject harmful code. Dedicated devices minimize this risk by restricting use to only secure signing operations.

Recommendation:
Deploy dedicated hardware or isolated environments for transaction signing. Limit these devices to essential software only, and keep them offline when not actively signing, to reduce exposure to both malware and UI hacking threats. For example, using a dedicated iPhone which is only ever used for signing transactions. 

5. Out-of-Band Transaction Verification

Score (0-5):

• 0 (High Risk): No out-of-band or independent verification - signers rely solely on the primary interface, which may have been compromised by malware or hacked UI code.

• 5 (Low Risk): Every transaction is cross-verified using an independent device (or the hardware wallet’s built-in display) before any signatures are applied.

Explanation:
Out-of-band verification is a critical defense against both malware and UI exploits. Even if the signing device’s interface is manipulated, an independent offline check can reveal discrepancies between the transaction details shown and what is actually being signed. This secondary check is the best defense against deceptive UI overlays.

Recommendation:
Implement a standard procedure where signers always confirm transaction details on a separate, isolated device. Transaction details should also be confirmed out of band (e.g. on Telegram or Signal) with other signers for additional verification. Whether using the built-in display on hardware wallets or an offline computer, always cross-check the transaction data before signing. This simple step can catch manipulated UI data and prevent unauthorized transactions. For example, the person drafting the initial transaction could post the Domain Hash and Message Hash in a Signal channel, and the other signers can verify the hashes on their signing devices before adding their signature using tools like OpenZeppelin’s Safe Utils to calculate these hashes locally. Alternatively one person could generate a batch transaction using Safe’s Transaction Builder and share the resulting JSON file along with the expected hashes. 

6. Transaction Signing Process Segmentation

Score (0-5):

• 0 (High Risk): The same system or personnel handle both transaction preparation and signing, which increases the risk that a single point of failure - be it a malware infection or a hacked UI - will compromise the entire process.

• 5 (Low Risk): Clear segmentation between the environments and roles for transaction preparation versus signing. Ideally, one system (or team role) drafts the transaction, and a separate, secure device or personnel approves it.

Explanation:
Segmentation adds a checkpoint between the creation of a transaction and its final approval. Even if the initial environment is compromised and presents manipulated UI data, a separate signing process can catch the discrepancy. This split reduces the chance of a single attack affecting the entire workflow.

Recommendation:
Establish a strict workflow that separates transaction drafting from approval. Where possible, use different machines or teams for each phase, and require that signers only approve transactions after verifying them independently. This separation minimizes the risk that a compromised UI in one phase leads to a successful attack. One approach is to use OpenZeppelin’s Safe Utils or pcaversaccio's safe-tx-hashes-util. 

7. Transaction Verification Process

Score (0-5):

• 0 (High Risk): There is no process for independently verifying the transaction details before it is submitted onchain; signers rely solely on what the primary UI or hardware wallet displays.

• 5 (Low Risk): A robust, routine process is in place where every transaction hash is independently recalculated and verified using alternative tools (such as alternative web UIs or command-line-based tools) to ensure it matches what the signing device displays.

Explanation:
While the multisig UI may display a transaction hash that appears correct and matches the hash displayed on a hardware wallet, a compromised UI might manipulate this information. Without independent verification, signers risk authorizing a transaction where the underlying hash - and thus the transaction details - have been altered. Independent hash verification provides a critical cross-check to ensure data integrity and detect potential UI manipulation.

Recommendation:
Establish a mandatory verification process for every transaction. Require signers to use at least one additional method - be it a command-line tool or an alternative web UI - to independently compute the transaction hash. Compare this independently generated hash with the one displayed on the signing device. If any discrepancy is found, do not proceed with the signing process. This practice reinforces trust in the multisig process by ensuring that all signed data has been thoroughly validated.

8. Programmatically Enforced Policies  

Score (0-5):

• 0 (High Risk): No Transaction Guards are in place; the system does not enforce any additional controls such as timelocks or policy-based restrictions.

• 5 (Low Risk): Comprehensive Transaction Guards are integrated into the multisig setup, consistently enforcing timelocks and blocking unauthorized transaction types per the organization’s security policies.

Explanation:
Enforcing policies directly from the multisig contract ensures they cannot be bypassed or forgotten. For example Safe Guards add an extra layer of security to Safe multisigs by enforcing rules beyond the standard multisig confirmation. They can delay the execution of transactions, allowing for additional review, or block transactions that do not comply with predefined policies. This helps mitigate risks from both UI manipulations and unauthorized transactions, ensuring that even if a malicious transaction is initiated, there is time to detect and prevent it.

Recommendation:
If not already implemented, consider integrating Transaction Guards into your multisig workflow. Configure them to enforce critical security policies such as mandatory delays for high-value transactions, ensuring that all transactions undergo an additional layer of scrutiny. This adds time for independent verification and potential intervention if a transaction appears suspicious. Regularly review and update these policies to adapt to evolving threats.This sort of workflow can be achieved both on and offchain depending on the tooling and ecosystem involved. 

9. Use of Anti-Malware Measures

Score (0-5):

• 0 (High Risk): No anti-malware tools or outdated protection on signing devices, leaving them vulnerable to exploits that can not only infect the system but also manipulate the UI.

• 5 (Low Risk): Comprehensive and regularly updated anti-malware solutions across all signing environments.

Explanation:
Effective anti-malware measures reduce the risk that an attacker can compromise a device in the first place. These tools add an essential layer of defense against both malware infections.

Recommendation:
Ensure that every device used in the signing process is equipped with advanced, up-to-date anti-malware software. Regularly schedule scans and maintain strict security protocols on all endpoints.

10. Physical Security of Signing Devices

Score (0-5):

• 0 (High Risk): No controlled physical access - signing devices are stored or used in unsecured areas, increasing the risk of direct tampering, including the injection of malicious UI components.

• 5 (Low Risk): All signing devices are kept in highly secure, access-controlled environments (e.g., locked safes, restricted rooms) to prevent physical tampering.

Explanation:
Physical security is just as crucial as cyber security. Unauthorized physical access could allow an attacker to implant malware or tamper with a device’s UI - perhaps even installing persistent malicious software or altering the firmware. Protecting the hardware is a key step in defending against both digital and physical manipulation.

Recommendation:
Implement strong physical security controls. Store signing devices in locked, monitored areas and limit physical access to trusted personnel only. Regularly audit physical security measures and verify that devices have not been tampered with.

11. Signer Education & Awareness Training

Score (0-5):

• 0 (High Risk): No formal training provided - signers may not be aware of the risks posed by both malware and compromised UIs, making them vulnerable to phishing and social engineering.

• 5 (Low Risk): Regular, comprehensive training that covers both malware risks and the potential for UI-based attacks. Signers know how to recognize suspicious interfaces and verify transaction details independently.

Explanation:
Human error is often the weakest link. Even with robust technical controls, if signers are unaware of how a hacked UI might present false information or how malware might interfere with the signing process, they could inadvertently authorize malicious transactions. Training builds a critical line of defense by ensuring that every signer is a vigilant and informed security gatekeeper.

Recommendation:
Conduct regular security training that covers both phishing/malware threats and specific tactics used in UI manipulation. Train signers to always verify transaction details via independent channels (such as an air-gapped device or hardware wallet screen) and to be skeptical of any unexpected UI behavior. Reinforce a culture of “if in doubt, verify” across the organization.

Final Notes

• Overall Risk Evaluation: Once you’ve completed the assessment, review which areas are rated as high risk (scores of 0-1) and prioritize improvements based on the provided recommendations.

• Continuous Improvement: Perform this self-assessment regularly (e.g., quarterly or after any process changes) to track progress and adjust defenses against both malware and UI-based threats.

• Confidentiality: This form is for internal use only. Do not share detailed responses or operational specifics that might help an attacker, though you may share a high-level risk summary if desired.

By assessing your multisig setup against these criteria, you can identify potential areas for improvement and address them proactively. A perfect score (5 in all categories) is a gold standard to strive for, indicating a robust, well-rounded security posture. Even if you’re not there yet, using this self-assessment regularly will guide your team in continuously improving the safety of your multisig holdings. 

Remember that threats evolve, so revisit this assessment over time (especially after organizational changes, adding new signers, or learning of new attack vectors in the ecosystem). Secure and effective multisig management is all about layers of protection - from how keys are stored, to how transactions are verified, to how the system is monitored. Strengthen each layer by practicing defense in depth. By keeping security best practices at the forefront and following the recommendations outlined, your team can significantly reduce the risk of multisig failure or compromise.

Learning from Examples:

• Solid Practices:
  Leading teams in the DeFi and institutional sectors have set the benchmark for multisig security. For example, custodians like BitGo implement multi-signature solutions with diversified signing devices, dedicated hardware wallets, and rigorous out-of-band verification. These teams also use air-gapped devices and independent tools for transaction verification. Security researcher Patrick Collins recently shared his in-depth review of hardware wallets, highlighting which devices allow for effective data verification.
  

• Big Hacks:
  Rekt.news is a great source for learning about real-world attacks. Recent incidents underscore the risks:

  • The Radiant Capital hack led to losses of around ~$50M due to compromised signers who were tricked by a manipulated UI.

  • The Bybit hack resulted in approximately ~$1.4B being stolen when attackers exploited a similar vulnerability.

These hacks illustrate that even when using multisig protocols, strict verification policies are required to remain safe.

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.