The Safe Predicament: Can Guard Restructure the Contract Babel Tower?

Authors: flush & kong
Editor: Liz

Background

On February 21, 2025, the cryptocurrency industry faced the most severe asset management crisis in its history. The on-chain multi-signature wallet of the trading platform Bybit was deliberately breached, resulting in the silent outflow of nearly $1.5 billion through a transaction with a “legitimate signature.”

Subsequent on-chain analysis revealed that the attacker had gained multi-signature authorization through a sophisticated social engineering attack. Exploiting the delegatecall function of the Safe contract, they injected malicious logic, ultimately bypassing the multi-signature verification mechanism and transferring the funds to an anonymous address.

This incident exposes a harsh reality: “Multi-signature” does not equate to “absolute security.” Even with security mechanisms like the Safe multi-signature wallet, the absence of additional protective measures still leaves room for potential breaches.

This is not the first attack targeting Safe multi-signature wallets. Last year, both WazirX (losing $230 million) and Radiant Capital (losing $50 million) fell victim to similar attack techniques. As analyzed in SlowMist’s report Hacker Techniques and Questions Behind Bybit’s Nearly $1.5 Billion Theft, attacks on Safe multi-signature wallets exhibit the following technical commonalities:

• Over-reliance on the signature mechanism: Security responsibility is entirely placed on private key management.
• Lack of dynamic defense: No real-time risk scanning before transaction execution.
• Coarse-grained permission control: No whitelist mechanism for high-risk operations like delegatecall.

(Bybit Exploitation Process: Using Safe v1.1.1)

The core issue behind this series of incidents does not lie in the Safe contract itself but rather in the security vulnerabilities introduced during the integration process — particularly in the front-end validation stage.

This raises a critical question: How can we enhance the security of multi-signature wallets through additional protective mechanisms within Safe?

Safe

Safe is a multi-signature (Multi-Sig) wallet designed for the secure storage and transfer of high-value assets and digital currencies. As a foundational infrastructure for decentralized asset management, it ensures transaction security through a collaborative verification mechanism, preventing single-point failures from being exploited by either a single administrator or a hacker. Safe is widely used in DAO governance, enterprise fund custody, and decentralized fund pools. Developed by the Safe team (formerly Gnosis Safe), this contract is the industry-standard on-chain asset management solution. It adopts the EIP-712 standard for structured data signing, enhancing the security and verifiability of transaction data.

Core Use Cases

• Fund Security Management: The contract requires multiple pre-designated owners to jointly confirm a transaction before execution, effectively mitigating single-point failures or malicious operations to ensure asset security.
• Transaction Execution & Management: Utilizing a built-in multi-signature verification mechanism, the contract enables the execution of external transfers, contract calls, and complex business logic once the required signature threshold is met. It supports both token and native coin payments and fee compensation.
• Modular Expansion: Designed with a modular architecture, the contract integrates multiple management modules — such as OwnerManager, ModuleManager, GuardManager, and FallbackManager—allowing for flexible functionality and easy customization to support diverse application scenarios.

Function Analysis

execTransaction Function – Executes a transaction after multi-signature verification:

• Computes a unique transaction hash (incorporating parameters, nonce, etc.).
• Verifies the validity of all signatures, ensuring each originates from an authorized owner or pre-approved address.
• Calls the target address’s business logic and records the success or failure status via events.
• Supports flexible gas fee handling, ensuring accurate cost calculations during fee compensation.

checkContractSignatures & checkNSignatures Functions – Verify transaction or message signature data:

• Process signatures from EOA accounts, contract signatures (EIP-1271), and pre-approved hashes.
• Ensure signatures are arranged in owner order and originate from valid addresses, preventing replay attacks and signature tampering.

getTransactionHash Function – Generates a transaction hash for signature verification and replay attack prevention:

• Utilizes the EIP-712 standard for structured hashing of transaction data.
• Optimizes memory operations with inline assembly, improving computational efficiency.
• Incorporates the current nonce to guarantee transaction uniqueness.

handlePayment Function – Manages gas fee compensation during transaction execution:

• Calculates the payment amount based on actual gas consumption and base fees.
• Supports payments in ETH and other tokens, ensuring accurate fee compensation.

onBeforeExecTransaction is an internal virtual hook function that is called before executing execTransaction. It is designed to allow child contracts inheriting from the Safe contract to implement custom pre-execution logic.

The function receives the following parameters:

• to (Target Address): The contract or account address that the transaction interacts with.
• value (Ether Value): The amount of Ether sent with the transaction.
• data (Payload): The calldata containing the function selector and parameters.
• operation (Operation Type): Determines whether the transaction is a CALL or DELEGATECALL.
• safeTxGas (Transaction Gas Limit): The amount of gas allocated for executing the transaction.
• baseGas (Base Gas): Gas costs independent of transaction execution.
• gasPrice (Gas Price): The gas price used for fee reimbursement.
• gasToken (Gas Token): The token address used for paying transaction fees.
• refundReceiver (Refund Receiver): The address that receives the gas fee reimbursement.
• signatures (Signature Set): The collection of signatures from owners authorizing the transaction.

Despite the robust security design and modular architecture of multi-signature wallet contracts, which provide efficient and secure digital asset management, victims of past attacks have often relied on hardware wallets for signing. However, some hardware devices do not display structured data signatures clearly, making it difficult for users to accurately verify transaction details in a short time, leading to blind signing risks.

To mitigate these risks, in addition to improving hardware display capabilities, other potential security enhancements include:

• Multi-step confirmation processes
• Intelligent transaction prompts
• Enhanced signature verification tools

These measures can further reduce the security risks associated with blind signing.

Safe Guard

In version 1.3.0, the Safe contract introduced a key security feature — the Safe Guard mechanism. This mechanism is designed to add additional restrictions to the standard n-out-of-m multi-signature scheme, further enhancing transaction security.

The core value of the Safe Guard mechanism lies in its ability to perform security checks at different stages of transaction execution:

• Pre-Transaction Check (checkTransaction):
  The Guard mechanism can programmatically validate all transaction parameters before execution, ensuring that the transaction complies with predefined security rules.
• Post-Transaction Check (checkAfterExecution):
  After the transaction is executed, the Guard performs additional security verification, checking whether the final state of the Safe wallet meets the expected security conditions.

Architecture Analysis

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

function execTransaction(
        ...
    ) external payable override returns (bool success) {
        ...
        address guard = getGuard();
        {
            if (guard != address(0)) {
                ITransactionGuard(guard).checkTransaction(
                    // Transaction info
                    to,
                    value,
                    data,
                    operation,
                    safeTxGas,
                    // Payment info
                    baseGas,
                    gasPrice,
                    gasToken,
                    refundReceiver,
                    // Signature info
                    signatures,
                    msg.sender
                );
            }
        }
        ...
        {
            ...
            success = execute(to, value, data, operation, gasPrice == 0 ? (gasleft() - 2500) : safeTxGas);
            ...
        }
        {
            if (guard != address(0)) {
                ITransactionGuard(guard).checkAfterExecution(txHash, success);
            }
        }
    }

When the Safe contract executes a multi-signature transaction pre-check through the Guard mechanism, its checkTransaction function receives the complete transaction context data, including the target contract address, call type, execution data (such as delegatecall), owner signature information, gas configuration, and payment details. This mechanism enables developers to implement multi-dimensional risk control strategies, such as contract whitelist management (restricting interactive addresses), function-level permission control (disabling high-risk function selectors), transaction frequency limits, and dynamic rules based on fund flow. By properly configuring Guard policies, attacks that bypass contract-level security measures can be effectively blocked.

Amidst the growing number of security incidents, the security of multi-signature wallet contracts has become a rising concern. Hardware wallet providers such as KeyStone, OneKey, and RigSec have been advocating for enhanced parsing and protection capabilities in Safe contracts to prevent similar risks. Following the Bybit incident, many projects have turned their focus to Safe contracts, exploring upgrades and extensions based on the Guard mechanism. Some have even developed innovative applications leveraging Guard to build an intermediate security layer on top of Safe multi-signature wallets, providing additional protection between underlying assets and user funds. The core function of this approach is to conduct granular transaction checks by passing the target contract, call type, execution data, owner signature information, payment details, and gas configuration into the checkTransaction function. This allows for precise permission control, including whitelisting contract calls, function operations, transfer destinations, and transaction frequencies.

It is worth noting that Safe itself only provides Guard management and callback functions, while the actual multi-signature transaction validation logic must be implemented by users, with its security relying on the quality of the Guard implementation. For example, Solv Guardian extends this concept by configuring a dedicated Guardian for each Vault to specify permitted target addresses and operation permissions, achieving three core access control elements: specifying allowed contracts, defining permitted function operations, and ACL verification requirements. Additionally, this mechanism adopts a separated governance architecture, where the Vault Guardian is responsible for executing specific policies, while the Governor controls governance rights, ensuring that even if the Guardian encounters issues, remedial measures can be promptly taken to protect user assets. A similar design philosophy is also applied in Elytro’s SecurityControlModule, where the module intercepts critical operations via the preExecute function and utilizes a whitelist mechanism to precisely control high-risk operations such as module installation, hook setup, and validator management, ensuring that only trusted contracts can be added to the system, thereby providing long-term security for wallets.

In the attack chain of the Bybit incident, if the Safe contract had deployed a properly configured Guard mechanism, the malicious delegatecall operation initiated by the attacker through execTransaction would have been intercepted at the pre-validation stage by multiple strategies: the Guard’s checkTransaction function would first identify the delegatecall operation type and trigger a disabling rule (such as enforcing the operation to be limited to regular calls). Then, by parsing the data field, it would detect an abnormal contract address (0x4622…7242) and a high-risk function selector, rolling back the transaction based on predefined contract whitelists and function blacklists. Ultimately, this would form a “policy interception → logical blocking” defense system, completely preventing storage tampering and unauthorized fund transfers.

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

Overall, Safe only introduced the Guard feature in version 1.3.0 and later. While Guard enables highly granular multi-signature transaction validation, there is a significant barrier to its adoption. Users must implement the Guard validation logic themselves, and a rough or flawed Guard implementation may fail to enhance the security of their Safe wallet. Therefore, conducting a security audit of the Guard implementation is essential. Undoubtedly, a secure and well-implemented Guard mechanism can significantly improve the security of Safe wallets.

Conclusion and Outlook

The Bybit attack highlights the critical importance of timely security infrastructure updates. Bybit was using Safe contract version v1.1.1 (<1.3.0), meaning they lacked access to the crucial Guard security feature. If Bybit had upgraded to Safe v1.3.0 or later and implemented an appropriate Guard mechanism — such as restricting fund recipients to a whitelist and enforcing strict contract function ACL validation — they might have been able to prevent this loss. While this remains hypothetical, it provides valuable insight into future asset security management strategies.

The Safe Guard mechanism functions like an intelligent security checkpoint for digital asset vaults, with its effectiveness depending on the rigor of rule design and implementation quality. Given the increasingly sophisticated attack methods, we need to focus on:

• Automated Verification: Establishing automated transaction validation mechanisms
• Dynamic Policy Adjustments: Adapting security strategies in real-time based on threat intelligence
• Layered Defense: Integrating multiple security mechanisms to build a robust defense-in-depth strategy
• Ongoing Audits: Conducting regular security audits of Guard implementations

The future of digital asset management will be shaped by the co-evolution of smart contract security mechanisms and continuous offensive-defense advancements. Only by embedding security principles into every aspect of the system can we build a true security fortress in the ongoing battle between hackers’ “spears” and defenders’ “shields.”

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

About SlowMist

SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as HashKey Exchange, OSL, MEEX, BGE, BTCBOX, Bitget, BHEX.SG, OKX, Binance, HTX, Amber Group, Crypto.com, etc.

SlowMist offers a variety of services that include but are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. We also offer AML (Anti-money laundering) software, MistEye (Security Monitoring) , SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) and other SaaS products. We have partnerships with domestic and international firms such as Akamai, BitDefender, RC², TianJi Partners, IPIP, etc. Our extensive work in cryptocurrency crime investigations has been cited by international organizations and government bodies, including the United Nations Security Council and the United Nations Office on Drugs and Crime.

By delivering a comprehensive security solution customized to individual projects, we can identify risks and prevent them from occurring. Our team was able to find and publish several high-risk blockchain security flaws. By doing so, we could spread awareness and raise the security standards in the blockchain ecosystem.