@gnosis.pm/safe-contracts

Gnosis Safe Contracts

Usage

Install requirements with yarn:

yarn

Run all tests:

yarn build
yarn test

Deployments

A collection of the different Safe contract deployments and their addresses can be found in the Safe deployments repository.

To add support for a new network follow the steps of the Deploy section and create a PR in the Safe deployments repository.

Deploy

:warning: Make sure to use the correct commit when deploying the contracts. Any change (even comments) within the contract files will result in different addresses. The tagged versions that are used by the Gnosis Safe team can be found in the releases.

This will deploy the contracts deterministically and verify the contracts on etherscan using Solidity 0.7.6 by default.

Preparation:

• Set MNEMONIC in .env
• Set INFURA_KEY in .env

yarn deploy-all <network>

This will perform the following steps

yarn build
yarn hardhat --network <network> deploy
yarn hardhat --network <network> etherscan-verify
yarn hardhat --network <network> local-verify

Custom Networks

It is possible to use the NODE_URL env var to connect to any EVM based network via an RPC endpoint. This connection then can be used with the custom network.

E.g. to deploy the Safe contract suite on that network you would run yarn deploy-all custom.

The resulting addresses should be on all networks the same.

Note: Address will vary if contract code is changed or a different Solidity version is used.

Verify contract

This command will use the deployment artifacts to compile the contracts and compare them to the onchain code

yarn hardhat --network <network> local-verify

This command will upload the contract source to Etherescan

yarn hardhat --network <network> etherscan-verify

Documentation

• Safe developer portal
• Error codes
• Coding guidelines

Audits/ Formal Verification

• for Version 1.3.0 by G0 Group
• for Version 1.2.0 by G0 Group
• for Version 1.1.1 by G0 Group
• for Version 1.0.0 by Runtime Verification
• for Version 0.0.1 by Alexey Akhunov

Security and Liability

All contracts are WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

License

All smart contracts are released under LGPL-3.0

Changelog

Version 1.3.0

Compiler settings

Solidity compiler: 0.7.6 (more info see issue #251)

Solidity optimizer: disabled

Expected deterministic deployment addresses

Core contracts

• GnosisSafe at 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552
• GnosisSafeL2 at 0x3E5c63644E683549055b9Be8653de26E0B4CD36E

Factory contracts

• GnosisSafeProxyFactory at 0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2

Handler contracts

• DefaultCallbackHandler at 0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd
• CompatibilityFallbackHandler at 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4

Lib contracts

• MultiSend at 0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761
• MultiSendCallOnly at 0x40A2aCCbd92BCA938b02010E17A5b8929b49130D
• CreateCall at 0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4

Storage reader contracts

• SimulateTxAccessor at 0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da

Changes

Core contract

File: contracts/GnosisSafe.sol

Add chainId to transaction hash

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.

Add transaction guard

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.

Add StorageAccessible support

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.

Remove changeMasterCopy

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)

Make checkSignature public

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.

Remove authorized from requiredTxGas

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.

Move EIP-1271 logic to fallback handler

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.