Safe Multisig Error GS013: Transaction Failed Execution Revert
Safe multisig error GS013 "Safe transaction failed" is emitted by the Gnosis Safe contract when an inner contract call executed via execTransaction reverts. Because Safe encapsulates transactions inside an internal call, the outer multi-sig execution succeeds up to the failure point, and the Safe contract throws GS013 to indicate the target interaction failed. Simulate the transaction with Tenderly or Foundry to inspect the underlying revert reason.
# Root Cause & Technical Architecture
Inside `GnosisSafe.sol`, `execTransaction` executes the transaction payload using low-level `call` or `delegatecall`: `success = execute(to, value, data, operation, ...); require(success, "GS013")`. If the target contract reverts (due to slippage, missing ERC-20 allowance, paused state, or insufficient gas), the low-level call returns `success = false`, and Safe reverts with `GS013`, masking the real sub-call revert reason.
# 4-Step Actionable Diagnostic Protocol
Step-by-Step ResolutionSimulate Safe Transaction via Tenderly or Foundry
Export the Safe transaction payload and simulate it in an execution sandbox to view the internal call stack and original revert reason.
Check Token Allowances and Balances of Safe Address
Ensure the Safe contract address (not the signer address) holds the required asset balance and has approved the target spender contract.
Audit safeTxGas Parameter Setting
When safeTxGas is set to 0, all available gas is forwarded to the inner call. Ensure your RPC or UI does not enforce a restrictive safeTxGas cap.
Inspect Target Contract Reentrancy Locks and Pauses
Verify that the target DeFi protocol or bridge is not paused or rejecting calls from contract addresses (non-EOA check).
# Diagnostic Verification Code / Command
bash# Trace underlying sub-call revert behind Safe GS013 using Foundry cast
cast call \
--rpc-url https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY \
--trace \
--from 0xSafeOwnerAddress \
0xYourSafeMultisigAddress \
"execTransaction(address,uint256,bytes,uint8,uint256,uint256,uint256,address,address,bytes)" \
$TARGET $VALUE $DATA $OPERATION $SAFE_TX_GAS 0 0 0x0 0x0 $SIGNATURESLaunch ERC-4337 UserOp Decoder
Execute client-side cryptographic simulation and parameter checks safely in your browser via native WebCrypto without sending private keys or mnemonics over the wire.
Read Full Investigation & Recovery Workflow
Explore complete architectural diagrams, edge-case failure trees, and detailed post-mortem analysis in our verified deep guide.
# Related Diagnostic Codes in ERC-4337 & Safe
Related Hex StatusesERC-4337 Error AA10: Sender Already Constructed UserOp Fix
Fix ERC-4337 error AA10 sender already constructed. Resolve non-empty initCode sent for deployed smart accounts, bundler estimation, and counterfactuals.
ERC-4337 Error AA20: Account Not Deployed EntryPoint Revert
Fix ERC-4337 error AA20 account not deployed. Troubleshoot empty initCode for counterfactual smart accounts, factory calldata, and pre-deployment.
ERC-4337 Error AA24: Signature Error UserOp Validation Fix
Fix ERC-4337 error AA24 signature error. Resolve validateUserOp signature mismatch, userOpHash EIP-712 hashing errors, and signature aggregator faults.
# Frequently Asked Questions
FAQ SchemaWhy does Safe hide the original revert reason behind GS013?
Safe contracts use low-level assembly calls for gas efficiency and modular execution, requiring a simple boolean success check rather than bubbling up custom errors.
Does GS013 mean owner signatures were invalid?
No. Signature validation failures trigger GS020 through GS026. GS013 confirms signatures were valid, but the target contract call itself failed.
Can gas price increases fix error GS013?
No. GS013 is caused by logical reverts in the target contract (e.g. slippage, allowance), not by mempool fee underpricing.