In-depth analysis of the Safe dilemma: Can Guard reconstruct the contractual Babel?

Author: flush & kong

Editor: Liz

background

On February 21, 2025, the cryptocurrency industry encountered the worst asset management crisis in history. The multi-signature wallet on the chain of the trading platform Bybit was targeted and nearly $1.5 billion in assets were quietly lost through a "legally signed" transaction. Subsequent on-chain analysis showed that the attacker obtained multi-signature permissions through sophisticated social engineering attacks, implanted malicious logic using the delegatecall function of the Safe contract, and ultimately bypassed the multi-signature verification mechanism to transfer funds to an anonymous address.

This incident exposed a cruel reality: "multi-signature" does not mean "absolute security". Even a security mechanism like the Safe multi-signature wallet is still at risk of being hacked if there is a lack of additional protection measures. This is not the first attack case against the Safe multi-signature wallet. Last year, WazirX (loss of $230 million) and Radiant Capital (loss of $50 million) both suffered similar attacks. As analyzed in the article SlowMist: Hacker Methods and Questions Behind the Theft of Nearly $1.5 Billion from Bybit, the Safe multi-signature wallet attack incident presents the following technical homology:

Over-reliance on signature mechanism: putting all security responsibilities in the custody of private keys.
Lack of dynamic defense: Lack of real-time risk scanning before transaction execution.
Coarse-grained permission control: No whitelist mechanism is established for high-risk operations such as delegatecall.

 (Bybit theft process: using Safe v1.1.1)

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

Safe

Safe is a multi-signature wallet that is mainly used to manage 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 to prevent a single administrator or hacker from using a single point of failure to perform malicious operations. It is widely used in DAO governance, corporate fund custody, decentralized fund pools and other scenarios. The contract was developed by the Safe (formerly Gnosis Safe) team and is the current industry standard on-chain asset management solution. The contract uses the EIP-712 standard to implement structured data signatures, thereby improving the security and verifiability of transaction data.

Core Purpose

Fund security management: The contract requires multiple pre-set owners to jointly confirm the transaction before it can be executed, thereby effectively preventing single point errors or malicious operations and ensuring fund security.
Transaction execution and management: Through the built-in multi-signature verification mechanism, the contract can execute external transfers, call other contracts or process complex business logic when the signature threshold conditions are met, and support the payment and fee compensation of tokens and native currencies.
Modular extension: The contract adopts a modular design. By inheriting and combining multiple management modules (such as OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), its functions are flexible and easy to expand, providing customized support for different application scenarios.

Function analysis

The execTransaction function executes a transaction verified by multiple signatures:

Calculate the unique hash value of the transaction (combined with transaction parameters, nonce, etc.);
Verify the validity of all signatures, ensuring that each one comes from the 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;
Supports flexible gas fee handling to ensure accurate calculation of transaction costs when paying compensation.

The checkContractSignatures & checkNSignatures functions verify the signature data of a transaction or message:

Handle EOA account signature, contract signature (EIP-1271), and pre-approved hash separately;
Ensure that signatures are arranged in order of owner 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 to prevent replay attacks:

Use the EIP-712 standard to perform structured hashing on transaction data;
Use inline assembly to optimize memory operations and improve computing efficiency;
Combined with the current nonce value, the uniqueness of each transaction is ensured.

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

The payment amount is calculated based on the actual gas fee consumed and the base fee;
Supports payments in ETH and other tokens to ensure accurate fee compensation.

onBeforeExecTransaction is an internal virtual hook function that is called before the execTransaction function is executed. This function is designed to allow subcontracts that inherit the Safe contract to perform custom logic processing before the transaction is executed. The parameter set received includes:

to: Target address - the contract or account address to be called by the transaction
value: Ether value - the amount of Ether sent with the transaction
data: data payload - call data containing function selector and parameters
operation: Operation type - determines whether it is CALL or DELEGATECALL
safeTxGas: Transaction gas limit - the amount of gas reserved for transaction execution
baseGas: Base gas - gas cost independent of transaction execution
gasPrice: gas price - the gas price used to calculate transaction fee compensation
gasToken: gas token - the token address used to pay transaction fees
refundReceiver: Refund Receiver - The address that receives the transaction fee compensation
signatures: signature collection - the owner's signature data on the transaction

Although multi-signature wallet contracts provide efficient and secure solutions for digital asset management with their rigorous security design and flexible modular structure, and realize full-process security control from transaction initialization to final execution, and become an important tool for blockchain security management, it is also important to note that most victims rely on hardware wallets for signing, and some hardware devices have poor display effects for structured data signatures, which can easily lead to users being unable to accurately identify transaction data in a short period of time, thus posing a risk of "blind signing". In response to this phenomenon, in addition to optimizing the hardware and its data display effects, we can also explore measures such as adding multiple confirmations, intelligent prompts, and enhanced signature verification tools to further reduce the security risks brought by blind signing.

Safe Guard

The Safe Guard mechanism is an important security feature introduced by the Safe contract in version 1.3.0. This mechanism is designed to provide additional restrictions for the standard n-out-of-m multi-signature scheme to further enhance transaction security. The core value of Safe Guard is that it can perform security checks at different stages of transaction execution:

Pre-transaction check (checkTransaction): The Guard mechanism can perform a programmatic check on all transaction parameters before the transaction is executed to ensure that the transaction complies with the preset security rules.
CheckAfterExecution: After the transaction is executed, Guard will perform additional security verification to check whether the final state of the Safe wallet after the transaction is executed is as expected.

Architecture Analysis

In Safe, multi-signature transactions are generally executed through the execTransaction function. When Safe Guard is enabled, when a 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 performs a multi-signature transaction pre-check through the Guard mechanism, its checkTransaction function will receive complete transaction context data, including the target contract address, calling method, execution data (such as delegatecall), owner signature information, Gas configuration and payment information. This mechanism enables developers to implement multi-dimensional risk control strategies, such as contract whitelist control (limiting interactive addresses), function-level permission management (disabling high-risk function selectors), transaction frequency restrictions, and dynamic rules based on capital flows. By properly configuring the Guard strategy, attackers can be effectively blocked from using non-contractual levels to attack.

In the context of recent security incidents, all parties are paying more and more attention to 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 Safe contracts to prevent similar risks from happening again. After the Bybit incident, many project parties began to focus on Safe contracts and explore upgrade and expansion solutions based on the Guard mechanism. Among them, there are many innovative applications based on the Guard mechanism, building an intermediate layer security solution based on the Safe multi-signature wallet, providing additional security between the underlying assets and user assets. Its core function is to pass the target contract, calling method, execution data, owner signature information, payment information, and gas information involved in the Safe multi-signature transaction into the checkTransaction function to achieve extremely fine-grained inspection of the transaction, including whitelist contract calls, whitelist function operations, whitelist transfer targets, transaction frequency and other permission controls.

It is worth noting that Safe itself only provides Guard management and callback functions. The actual multi-signature transaction check logic is implemented by the user, and its security depends on the quality of Guard implementation. For example, Solv Guardian expands this idea and configures a dedicated Guardian in each Vault to specify the allowed target address and operation permissions, realizing the three major permission control elements of specifying allowed contracts, defining allowed function operations, and ACL verification requirements. At the same time, a separate governance mechanism is adopted, with Vault Guardian responsible for execution, and Governor controlling governance permissions to ensure that even if Guardian has problems, remedial measures can be taken in time to protect user assets. A similar design concept is also applied in Elytro's SecurityControlModule, which intercepts key operations through the preExecute function and uses the whitelist mechanism to finely control high-risk operations such as module installation, hook settings, and validator management, thereby ensuring that only trusted contracts can be added to the system, providing lasting security for the wallet.

In the Bybit event attack chain, if the Safe contract deploys a properly configured Guard mechanism, the malicious delegatecall initiated by the attacker through execTransaction will be intercepted by multiple strategies in the pre-check stage: Guard's checkTransaction function first identifies the delegatecall operation type and triggers the disabling rule (such as forcing the operation to be a normal call only), then parses the data field to detect the unconventional contract address (0x4622...7242) and high-risk function selector, and directly rolls back the transaction through the preset contract whitelist and function blacklist strategies, ultimately forming a "strategy interception → logic blocking" defense system to completely block storage tampering and fund transfer paths.

 (When using Safe version ≥ v1.3.0 Safe Guard module verification operation https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

In general, Safe only provides the Guard function after version 1.3.0. Although Guard can provide extremely fine-grained multi-signature transaction checks, users have a high threshold when using the Guard function. They need to implement the Guard check logic themselves. A rough or flawed Guard implementation may not help users improve the security of their Safe wallets, so a security audit of the Guard implementation is necessary. There is no doubt that a safe and appropriate Guard implementation can greatly improve the security of the Safe wallet.

Conclusion and Outlook

The Bybit attack highlights the importance of updating security infrastructure in a timely manner. Bybit used the Safe contract version v1.1.1 (<1.3.0), which means they could not use the Guard mechanism, a key security feature. If Bybit upgraded to the Safe contract version 1.3.0 or higher and implemented a suitable Guard mechanism, such as specifying a whitelist address that only receives funds and performing strict contract function ACL verification, this loss might have been avoided. Although this is just a hypothesis, it provides important ideas for future asset security management.

The Safe Guard mechanism is like an intelligent security system added to a digital asset safe. Its effectiveness depends on the rigor of rule design and the quality of implementation. In the face of increasingly sophisticated attack methods, we need to:

Automated Verification: Establish an automated transaction verification mechanism
Dynamic policy adjustment: adjust security policies in real time based on threat intelligence
Multi-layer defense: combining multiple security mechanisms to build a deep defense system
Continuous Auditing: Perform regular security audits of Guard implementations

The future of digital asset management will be a co-evolutionary process of smart contract security mechanisms and continuous attack and defense evolution. Only by integrating security concepts into every link can we build a real security barrier in the game between the hacker's "spear" and the guardian's "shield".

References

[1] https://github.com/safe-global/safe-smart-account/blob/v1.3.0/CHANGELOG.md

[2] https://docs.safe.global/advanced/smart-account-guards

[3] https://docs.solv.finance/security/solv-guard

[4] https://github.com/safe-global/safe-smart-account/tree/main/contracts/examples/guards

[5] https://github.com/Elytro-eth/soul-wallet-contract/blob/v0.6/contracts/modules/securityControlModule/SecurityControlModule.sol