Background

On February 21, 2025, the cryptocurrency industry experienced the most severe asset management crisis in history. The on-chain multi-signature wallet of the trading platform Bybit was breached in a targeted attack, and nearly $1.5 billion in assets quietly disappeared through a "legally signed" transaction. Subsequent on-chain analysis showed that the attacker obtained multi-signature privileges through a sophisticated social engineering attack, used the delegatecall function of the Safe contract to implant malicious logic, and ultimately bypassed the multi-signature verification mechanism to transfer the funds to an anonymous address.

This incident exposed a cruel reality: "multi-signature" does not mean "absolute security". Even for a security mechanism like the Safe multi-signature wallet, if there is a lack of additional protective measures, it still faces the risk of being breached. This is not the first attack case targeting the Safe multi-signature wallet. Last year, WazirX (lost $230 million) and Radiant Capital (lost $50 million) also encountered similar attack methods. As analyzed in the article "The Hacking Techniques and Questions Behind the $1.5 Billion Theft from Bybit" by Slowmist, the Safe multi-signature wallet attack events show the following technical commonalities:

Excessive reliance on signature mechanisms: Placing all security responsibilities on private key management.

Lack of dynamic defense: Lack of real-time risk scanning before transaction execution.

Coarse-grained permission control: No whitelist mechanism established for high-risk operations such as delegatecall.

The core problem of this series of events is not the Safe contract itself, but the security vulnerabilities in the integration process of the entire system, especially in the front-end verification link. This prompts us to think: How can we strengthen the protection capabilities of multi-signature wallets through additional security measures of Safe?

Safe

Safe is a multi-signature (Multi-Sig) wallet, mainly used for the secure storage and transfer of high-value assets and digital currencies. As the infrastructure for decentralized asset management, it ensures the security of fund operations through a multi-party collaborative verification mechanism, preventing malicious operations by a single administrator or hacker using a single point of failure. It is widely used in scenarios such as DAO governance, corporate fund custody, and decentralized fund pools. The contract was developed by the Safe (formerly Gnosis Safe) team and is the current industry standard on-chain asset management solution. The contract implements structured data signing according to the EIP-712 standard, thereby improving the security and verifiability of transaction data.

Core Uses

Fund Security Management: The contract requires multiple pre-set owners to jointly confirm the transaction before it can be executed, effectively preventing single-point failures or malicious operations, and ensuring fund security.

Transaction Execution and Management: Through the built-in multi-signature verification mechanism, the contract can execute outbound transfers, call other contracts, or handle complex business logic when the signature threshold conditions are met, supporting token and native coin payments and fee reimbursement.

Modular Expansion: The contract adopts a modular design, inheriting and combining multiple management modules (such as OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), making its functions flexible and easy to extend, and providing customized support for different application scenarios.

Function Analysis

The execTransaction function executes transactions that have undergone multi-signature verification:

· Calculate the unique hash value of the transaction (combining transaction parameters, nonce, etc.);

· Verify the validity of all signatures, ensuring that each signature comes from a legitimate owner or pre-approved address;

· Call the business logic of the target address, and record the success or failure status through events after the transaction is executed;

· Support flexible gas fee handling to ensure accurate calculation of transaction costs when paying for reimbursement.

The checkContractSignatures & checkNSignatures functions verify the signature data of transactions or messages:

· Separately process EOA account signatures, contract signatures (EIP-1271), and pre-approved hashes;

· Ensure that the signatures are arranged in the order of the owners, and that each signature comes from a valid address, preventing replay attacks and signature tampering.

The getTransactionHash function generates a transaction hash for signature verification and prevention of replay attacks:

· Use the EIP-712 standard to perform structured hashing of transaction data;

· Use inline assembly to optimize memory operations and improve computational efficiency;

· Combine the current nonce value to ensure the uniqueness of each transaction.

The handlePayment function handles the payment of gas reimbursement during the transaction execution process:

· Calculate the payment amount based on the actual gas consumed and the base fee;

· Support payment in ETH and other tokens to ensure accurate fee reimbursement.

The onBeforeExecTransaction is an internal virtual hook function, called before the execTransaction function is executed. The purpose of this function is to allow child contracts that inherit the Safe contract to perform custom logic processing before the transaction is executed. The received parameter set includes:

· to: Target address - the contract or account address that the transaction is to call

· value: Ether value - the amount of Ether sent with the transaction

· data: Data payload - the call data containing the function selector and parameters

· operation: Operation type - determines whether it is a CALL or DELEGATECALL

· safeTxGas: Transaction gas limit - the amount of gas reserved for the transaction execution

· baseGas: Base gas - the gas cost independent of the transaction execution

· gasPrice: Gas price - the gas price used to calculate the transaction fee reimbursement

· gasToken: Gas token - the token address used to pay the transaction fee

· refundReceiver: Refund receiver - the address that receives the transaction fee reimbursement

· signatures: Signature collection - the signature data of the owners on the transaction

Although the multi-signature wallet contract, with its rigorous security design and flexible modular structure, provides an efficient and secure solution for digital asset management, realizing full-process security control from transaction initialization to final execution, and becoming an important tool for blockchain security management, it is also necessary to note that the victims mostly rely on hardware wallets for signing, and some hardware devices have poor display effects for structured data signing, which can easily lead to users being unable to accurately identify transaction data in a short period of time, thereby posing a "blind signing" risk. In addition to optimizing hardware and its data display effects, measures such as adding multi-confirmation, smart prompts, and enhancing signature verification tools can also be explored to further reduce the security risks brought by blind signing.

Safe Guard

An important security feature introduced in the 1.3.0 version of the Safe contract is the Safe Guard mechanism. This mechanism aims to provide additional restrictive conditions for the standard n-out-of-m multi-signature scheme, further enhancing transaction security. The core value of Safe Guard lies in its ability to perform security checks at different stages of transaction execution:

· Pre-transaction check (checkTransaction): The Guard mechanism can perform programmatic checks on all parameters of the transaction before execution, ensuring that the transaction complies with the pre-set security rules.

· Post-execution check (checkAfterExecution): After the transaction is executed, the Guard will also perform additional security verification, checking whether the final state of the Safe wallet is as expected.

Architecture Analysis

In Safe, multi-signature transactions are generally executed through the execTransaction function. When the Safe Guard is enabled, when the user executes a multi-signature transaction, the Safe contract will call the checkTransaction function of the Guard contract to perform a pre-transaction check, and when the multi-signature transaction is completed, the Safe contract will call the checkAfterExecution function of the Guard contract to check the execution result of the transaction. The specific implementation is as follows:

When the Safe contract executes a multi-signature transaction pre-check through the Guard mechanism, its checkTransaction function will receive the complete transaction context data, including the target contract address, call mode, execution data (such as delegatecall), owner signature information, Gas configuration, and payment information.

This mechanism allows developers to implement multi-dimensional risk control strategies, such as contract whitelist management (restricting interactable addresses), function-level permission management (disabling high-risk function selectors), transaction frequency limits, and dynamic rules based on fund flows. By reasonably configuring the Guard strategy, the attack vectors at the non-contract level can be effectively blocked.

Against the backdrop of the recent series of security incidents, various parties have become increasingly concerned about the security of multi-signature wallet contracts. Hardware wallet providers such as KeyStone, OneKey, and RigSec have called for enhancing the parsing and protection capabilities of the Safe contract to prevent similar risks from occurring again. After the Bybit incident, many projects have begun to focus on the Safe contract and explore upgrade and expansion solutions based on the Guard mechanism.

Among them, there are innovative applications based on the Guard mechanism, building a middle-layer security solution based on the Safe multi-signature wallet to provide additional security protection for the underlying assets and user assets. Its core function is to achieve fine-grained transaction checks by passing the target contract involved in the Safe multi-signature transaction, the calling method, the execution data, the owner's signature information, the payment information, and the gas information into the checkTransaction function, including whitelist contract calls, whitelist function operations, whitelist transfer targets, and transaction frequency permission control.

It is worth noting that Safe itself only provides Guard management and callback functions, and the actual multi-signature transaction check logic is implemented by the user, and its security depends on the quality of the Guard implementation. For example, Solv Guardian has expanded on this idea, configuring a dedicated Guardian for each Vault to specify the allowed target addresses and operation permissions, realizing the three key permission control elements of specifying allowed contracts, defining allowed function operations, and ACL verification requirements.

At the same time, a separated governance mechanism is adopted, with the Vault Guardian responsible for execution and the Governor controlling the governance rights, ensuring that even if there is a problem with the Guardian, remedial measures can be taken in a timely manner to protect user assets. A similar design concept is also applied in Elytro's SecurityControlModule, where the preExecute function intercepts critical operations and uses a whitelist mechanism to fine-tune the management of high-risk operations such as module installation, hook setting, and validator management, ensuring that only trusted contracts can be added to the system, providing persistent security protection for the wallet.

In the attack chain of the Bybit incident, if the Safe contract had a properly configured Guard mechanism, the malicious delegatecall initiated by the attacker through execTransaction would have been intercepted by multiple strategies in the pre-check stage: the Guard's checkTransaction function would first identify the delegatecall operation type and trigger the disable rule (such as forcing the operation to be a regular call only), then parse the data field to detect the abnormal contract address (0x4622...7242) and high-risk function selector, and directly roll back the transaction through the pre-set contract whitelist and function blacklist strategy, ultimately forming a "strategy interception → logic blockade" defense system to completely block the path of storage tampering and fund transfer.

In summary, Safe only provided the Guard function starting from version 1.3.0, and although Guard can provide extremely fine-grained multi-signature transaction checks, users have a relatively high threshold when using the Guard function. They need to implement the Guard check logic themselves, and a rough or defective Guard implementation may not help users improve the security of their Safe wallet, so security auditing of the Guard implementation is necessary. Undoubtedly, a secure and appropriate Guard implementation can greatly enhance the security of the Safe wallet.

Conclusion and Outlook

The attack on Bybit highlights the importance of timely updating security infrastructure. Bybit used the v1.1.1 (<1.3.0) version of the Safe contract, which means they were unable to use the key security feature of the Guard mechanism. If Bybit had upgraded to the 1.3.0 or higher version of the Safe contract and implemented a suitable Guard mechanism, such as specifying a whitelist of addresses to receive funds and performing strict contract function ACL verification, they might have avoided this loss. Although this is just a hypothesis, it provides an important approach for future asset security management.

The Safe Guard mechanism is like a smart security check system installed on the digital asset safe, and its effectiveness depends on the rigor of the rule design and the quality of the implementation. Facing increasingly sophisticated attack methods, we need:

· Automated Verification: Establish an automated transaction verification mechanism

· Dynamic Policy Adjustment: Adjust security policies in real-time based on threat intelligence

· Multi-Layer Defense: Build a deep defense system by combining multiple security mechanisms

· Continuous Auditing: Regularly conduct security audits of the Guard implementation

The future of digital asset management will be a co-evolutionary process of smart contract security mechanisms and ongoing attack-defense evolution. Only by integrating security concepts into every link can we build a real security barrier in the "spear" of hackers and the "shield" of guardians.

Original Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Twitter Official Account: https://twitter.com/BlockBeatsAsia