Exceptions during smart contract execution
During the execution of code, exceptions can happen. This includes execution of smart contracts on Ethereum.
An exception can have various reasons. Examples include the usage of an opcode unknown to the Ethereum virtual machine or a failed access check programmed in by a smart contract developer (cf. error handling in Solidity).
Whenever an exception occurs, there are generally 2 options:
The entire transaction fails, thereby reverting anything that has been executed before this point.
Add logic to the smart contract to handle the exception and still attempt to execute the remainder of the smart contract (cf.
The latter option is what is used inside the Safe smart contracts.
A Safe transaction can generally be separated in 2 parts:
Checking signatures + threshold and optional handling of the transaction fee payment.
Executing the actual transaction the user wants to make.
The reason for that separation is that the Safe supports so called meta transactions. This essentially enables decoupling owners and signers of an account from the actual executing account. If enabled, the executing account is paid with funds from within the Safe. The owners and signers of a Safe do not necessarily need ETH on their accounts.
The fee payment part of a transaction should never fail even in case the actual user transaction fails for whatever reason, since transaction fees on Ethereum have to be paid even for failed transactions.
The user transaction is a so called "internal transaction". That internal transaction can fail while the outer Ethereum transaction succeeds.
Etherscan only reports the status of the outer transaction while for the Safe and the user only the status of the inner transaction is relevant.
Please refer to the Safe Developer Portal for more technical information on Safe transaction execution on the contract level.
Etherscan reports "Success" but mentions "Although one or more Error Occurred [Reverted] Contract Execution completed."
Safe reports "Failed".
Both is true in its respective context for the reasons described above. However for Safe users, "Failed" is more accurate since the actual intended action of transferring 1000 DAI did not succeed.
In order to figure out the actual reason, why a transaction failed, you will have to check the contract and potentially the execution trace. This requires technical knowledge.
Tenderly is a good tool for this. It reports that there is insufficient DAI balance, just as expected.