Institutional Wallet Security

Institutional web3 security best practices

FullSun, an RWA investing company, started to custody $1M on Base. One day, they logged into their self-custody wallet and realized the balance was $0. What was the cause? Was it the 1 of 2 multisig? Was it the plaintext seed phrase in a password manager? Was it that strange potential partner email last week?

While the above situation is fictional, these are real questions we often see in exploits. The lessons from recent crypto hacks, particularly those stemming from improper wallet security and failures in transaction data verification, offer critical insights into security lapses. While an expensive lesson, it’s a stark reminder that security is an ever-growing challenge. 

This blog outlines some strategies to help you increase your security and understand what you are signing.

Disclaimer: This blog will assume that hot wallets are not being used. If your team is using a hot wallet, you should immediately move your funds to a more secure configuration. If you need assistance, please contact help@zeroshadow.io.  

Beyond basic wallet security: institutional-grade key management

The private keys that control your institution's digital assets are the ultimate target. Securing them requires a multi-layered approach:

Multi-signature (multisig) and multi-party computation (MPC) wallets

• Policy, Not Just Technology: Implement clear, audited policies defining who the signers are, the M-of-N signature requirements (e.g., 3-of-5, 5-of-7), and the physical security of each private key (Multisig) or key share (MPC).

• Geographic and Personnel Distribution: Ensure private keys or key shares are held by different individuals in geographically distinct, secure locations. No single individual or compromised location should lead to a loss of control.

  • Storing all keys in one location does not diversify risk. 

  • Additionally, keys should always be stored offline. 

• Regular Key Rotation: Establish protocols and procedures for secure key generation and rotation.

Multisig solutions

Safe and Squads provide multisig solutions and have embedded decentralized applications (dApps) on their front-end to reduce security risks with users leaving the applications. By using these solutions, the team is solely responsible for private key management. If managing private keys properly is a concern, then it is recommended to use regulated custodians.

Institutional custody solutions (MPC)

For significant holdings, compliance, or to offload private key security, consider qualified regulated third-party custodians who specialize in digital asset security. Many regulated custodians (such as Fireblocks or Anchorage Digital) use MPC solutions to secure client funds. 

Regular audits of wallet infrastructure

Conduct periodic internal and third-party audits of your wallet systems, key management processes, and associated infrastructure.

The unseen threat: verifying every transaction, every time

As the industry matures, attacks will continue to become more sophisticated. Exploits such as the Bybit hack highlight a critical security vulnerability in which the front-end displays a different transaction than what was intended to be signed. However, there are multiple ways to verify to ensure what you are signing is the intended transaction.

Trusted display and verification on hardware wallets

Mandate that final transaction verification occurs on the screen of a trusted hardware wallet, isolated from the potentially compromised computer initiating the transaction. The hardware wallet's display is the ground truth. 

Even if your device is compromised with malware, the hardware wallet will only display the transaction details given to it. This means that even if you see the intended transaction on the UI and malware is actually under the hood trying to trick you into signing something else, the hardware wallet will only display the malicious transaction. 

Transaction simulation and monitoring

Transaction data should be verified on the hardware wallet to ensure the correct data is being signed. Once done, the transaction should be simulated to see the output of the result. If the transaction simulation shows an unintended result, then the transaction process should be immediately halted. 

Additionally, monitoring can be set up to monitor when multi-sig transactions are initiated. These can act as a guard against accidentally signing malicious transactions.

For technical details on decoding transaction data, please see the Bonus: Transaction Decoding section at the end of the article

Strict whitelisting and address management

Maintain rigorously controlled whitelists of approved addresses for withdrawals and interactions. Any changes to this list should require a high level of scrutiny and multiple approvals.

Dedicated Signing Devices

Signing devices (e.g., laptops, computers, etc.) should be exclusively used for signing transactions, then immediately powered down and stored securely. These practices greatly limit the exposure to potential vulnerabilities. 

The people problem

As the industry matures, it will be easier to target employees than it will be to find vulnerabilities in the code. 

Rigorous Access Controls & Least Privilege 

Implement strict, role-based access controls for all systems managing digital assets. Ensure individuals only have the minimum necessary permissions to perform their duties. (e.g., a non-technical employee does not need the ability to run PowerShell or terminal scripts). 

Intensive and Continuous Security Training

• Phishing & Social Engineering: Conduct regular, sophisticated phishing simulation exercises and training on identifying social engineering tactics specifically targeting crypto asset holders.

• Crypto-Specific Threats: Educate on attack vectors like malicious browser plugins, compromised software updates, etc.

Thorough Checks 

For personnel in sensitive roles, particularly those with access to private keys, transaction approval systems, or administrative controls.

Well-Rehearsed Incident Response Plan

Develop and regularly test a detailed incident response plan specifically for digital asset security breaches. This should cover containment, eradication, recovery, communication, and forensic investigation.

Conclusion

Security is not a one-time checklist but an ongoing, dynamic process that is ever evolving. There is no one tool or best practice that will save your team from a bad day, but a combination of best practices can greatly limit the chances of this happening.

Bonus: transaction decoding

The image below illustrates how to retrieve the raw transaction data necessary to decode the transaction. You can retrieve this from your wallet provider, and it will be shown during the signing process. You will need to copy the entire hexadecimal string found in the field labeled 'data'. 

“0x3593564c000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000681e590c00000000000000000000000000000000000000000000000000000000000000070….000000000000000055ca564cc545b8d17dbbcf12d696db7945e3d08b00000000000000000000000000000000000000000000000000000001797c364b0c”

We also need to make note of the address where the data is being sent. This can be found below the “data” field.

However, for educational purposes, we are going to use the following transaction hash taken from Ethereum block 22445461.

Transaction Hash: 0x8ff0e58d8d28b8861ed7517e860b7f4ed577db7d859404bbcfdd3e440a698da1

As shown in the image above, the transaction data is being sent to: 0x111111125421cA6dc452d289314280a0f8842A65. We can verify this is 1inch by doing a quick search of the address and looking at publicly available data on Arkham. 

Back to the transaction, copy the input data and then open Etherscan’s Decoder

We want to click “without ABI” because when we copy and paste the transaction data from our wallet provider, we will only have the data.