Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@gnosis.pm/safe-contracts

Package Overview
Dependencies
Maintainers
6
Versions
9
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@gnosis.pm/safe-contracts - npm Package Versions

1.3.0

Diff

Changelog

Source

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.

rmeissner
published 1.3.0-rc.0 •

rmeissner
published 1.2.0 •

Changelog

Source

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.

rmeissner
published 1.1.1-dev.2 •

rmeissner
published 1.1.1-dev.1 •

rmeissner
published 1.1.1 •

rmeissner
published 1.1.0 •

denisgranha
published 1.0.0 •

denisgranha
published 0.1.0 •

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc