@gnosis.pm/safe-contracts
Advanced tools
Changelog
Version 1.3.0
Solidity compiler: 0.7.6 (more info see issue #251)
Solidity optimizer: disabled
GnosisSafe
at 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552
GnosisSafeL2
at 0x3E5c63644E683549055b9Be8653de26E0B4CD36E
GnosisSafeProxyFactory
at 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2
DefaultCallbackHandler
at 0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd
CompatibilityFallbackHandler
at 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4
MultiSend
at 0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761
MultiSendCallOnly
at 0x40A2aCCbd92BCA938b02010E17A5b8929b49130D
CreateCall
at 0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4
SimulateTxAccessor
at 0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da
File: contracts/GnosisSafe.sol
Issue: #170
Expected behaviour:
The chainId
has been added to the EIP-712 domain. In case of a change of the chainId
(e.g. hardfork related) the new chainId
will automatically be used for future signature checks.
Issue: #224
Expected behaviour:
It is possible to add a transaction guard, which can check all of the parameters that have been sent to execTransaction
prior to execution. For this check the checkTransaction
needs to be implemented by the guard. In case that checkTransaction
reverts, execTransaction
will also revert. Another check that can be implemented by the guard is checkAfterExecution
. This check is called at the very end of the execution and allows to perform checks on the final state of the Safe. The parameters passed to that check are the safeTxHash
and a success
boolean.
Issue: #201
Expected behaviour:
It is possible to use simulateDelegatecallInternal
to simulate logic on the Safe by providing a contract and calldata. This contract will then be called via a delegatecall and the result will be returned via a revert.The revert data will have the following format:
success:bool || response.length:uint256 || response:bytes
.
Important: This method will always revert.
Expected behaviour:
It is not possible anymore to change the singleton address (formerly known as master copy) via a method call. To make the implications of a singleton address change more visible it is required to use a delegatecall with a migration contract. (See example migration in libraries)
Issue: #248
Expected behaviour:
The checkSignature
method is now a view method that is public. This makes it possible that it can be used in other contracts (e.g. modules) to make it easier to reuse existing signature check logic. The function expects that there are at least enough valid signatures to hit the threshold.
Another method that has been added to make the usage from external contracts easier is checkNSignatures
which allows to set how many valid signatures are expected.
Note: The storage allocated by approveHash
will no longer be zeroed when being used in checkSignature
. If this is required a delegatecall with a contract that zeroes past approved hashes should be used.
Issue: #247
Expected behaviour:
To make it easier to interact with this method (e.g. by providing a wrapper). The requirement that the method can only be called by the Safe itself has been removed. The method will still always revert.
Note: This method is superseded by the StorageAccessible
logic and will be removed in the next major version.
Issue: #223
Expected behaviour:
As EIP-1271 is still changing the logic for it has been moved to a fallback handler. The fallback handler uses the checkSignatures
method to validate the signatures. Also this fallback handler supports the latest version of EIP-1271. The logic to mark a message hash as signed in the contract also has been moved to other contracts. getMessageHash
has been moved to a fallback handler and signMessage
into a library that can be used via delegatecall.
Note: The checkSignature
method still uses the previous version of EIP-1271 that uses the data to be signed instead of the hash of the data.
Changelog
Add Migration example to downgrade from 1.3.0 to 1.2.0
File: contracts/examples/libraries/Migrate_1_3_0_to_1_2_0.sol
Note: This contract is meant as an example to demonstrate how to facilitate migration in the future. This should not be used in production without further checks.
Expected behaviour:
This migration can be used to migrate a Safe to another singleton address. Once the migration has been executed the singleton address will point to the address specified in the constructor of the migration and the domain separator will be properly set in storage (as this is required by the 1.2.0 version of the Safe contracts). Note: This is meant as an example contract, only to be used in production if you know what you do.