# OpenZeppelin Contracts v2.4 **URL:** \ **Category:** Announcements\ **Created:** [October 30, 2019, 10:56pm UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665 "2019-10-30T22:56:17Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![nventuro](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/nventuro/32/8_2.png) [@nventuro](https://forum.openzeppelin.com/u/nventuro)\ **Post date:** [October 30, 2019, 10:56pm UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665/1 "2019-10-30T22:56:17Z")
![OpenZeppelin Contracts 2.4](https://us1.discourse-cdn.com/flex022/uploads/zeppelin/original/2X/2/2f5e8a7a7614c5e36fbf759bc6853a377f59e2f9.png) We’ve recently released version 2.4 of the [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/2.x/) library, featuring support for seamless user onboarding via the Gas Station Network, and utilities reflecting the latest security best practices, in preparation for the [upcoming Istanbul hardfork](https://forum.openzeppelin.com/t/an-overview-of-the-upcoming-istanbul-hard-fork/1391). Strap in! ## The Gas Station Network (GSN): fixing user onboarding ⛽ 2019 saw the rise of meta-transaction solutions and industry-wide efforts such as the [MetaCartel](https://www.metacartel.org/) to improve adoption of web3 applications by bringing their user experience more in-line with regular everyday webapps. The [Gas Station Network](https://gsn.openzeppelin.com/) is the result of collaboration of the GSN Alliance, a group of companies of which OpenZeppelin is part of. In a nutshell, **the GSN lets users interact with web3 applications without having to ever hold Ether** 🙀. Not only does this mean that MetaMask is no longer mandatory, but also that users don’t have to go through the grueling process of procuring Ether _before_ they can actually use the application. Version 2.4 includes first-class support for the GSN in _all_ of the OpenZeppelin contracts: by simply inheriting from the [`GSNRecipient`](https://docs.openzeppelin.com/contracts/2.x/api/gsn#GSNRecipient) contract, all functions will be able to be called without the user having to pay for gas. By mixing `GSNRecipient` and long-standing contracts such as `ERC20` or `ERC721`, you can create a gas-less token in under a minute! ✨ While there are some details that you need to be aware of when dealing with the GSN, we’ve wrote multiple guides and tutorials to help you get up to speed quickly: the [GSN Starting Guide](https://docs.openzeppelin.com/openzeppelin/gsn/getting-started) will tell you everything you need you know regarding development, testing, and interaction with GSN-capable contracts. Go check it out! ## `transfer` considered harmful 🚫 The upcoming Istanbul hardfork (scheduled for late 2019/early 2020) will reprice certain opcodes, breaking many contracts that are running on mainnet today. Much has been discussed in different security-oriented Ethereum channels, and one of the takeaways is that **relying on Solidity’s `transfer` function to send Ether is often a mistake** that will lead to applications being **irreversibly broken** in the future. You can read more about this in [Consensys Dilligence’s article suggesting dropping `transfer` immediately](https://diligence.consensys.net/blog/2019/09/stop-using-soliditys-transfer-now/), and our own analysis of [how the hardfork will cause issues with OpenZeppelin upgradeable contracts](https://forum.openzeppelin.com/t/openzeppelin-upgradeable-contracts-affected-by-istanbul-hardfork/1616). `transfer` is, however, a superior option to the native alternatives, `call` and `send`, which can be easily misused and lead to security vulnerabilities. Because of this, we’ve created [`sendValue`](https://docs.openzeppelin.com/contracts/2.x/api/utils#Address-sendValue-address-payable-uint256-), a **drop-in replacement for `transfer`** : ```auto pragma solidity ^0.5.5; import "@openzeppelin/contracts/utils/Address.sol"; contract MyContract { using Address for address payable; function wrong(address payable receiver, uint256 amount) external { receiver.transfer(amount); // do not use! } function right(address payable receiver, uint256 amount) external { receiver.sendValue(amount); // use sendValue instead of transfer } } ``` The only difference between `sendValue` and `transfer` is that `sendValue` will forward all gas to the recipient, Because of this, saying goodbye to `transfer` also means having to be more aware of possible reentrancy vulnerabilities your contract might have. We will be publishing guides on how to deal with these and stay safe soon, but in the meantime, consider using our [`ReentrancyGuard`](https://docs.openzeppelin.com/contracts/2.x/api/utils#ReentrancyGuard) and [`PullPayment`](https://docs.openzeppelin.com/contracts/2.x/api/payment#PullPayment) contracts. ## Better error messages Often, `SafeMath` is used to e.g. check that a user transferring tokens has enough balance via `balances[user].sub(amount)`. An unfortunate side effect of this is that, on reverts, the error message you’ll get will come from `SafeMath` itself instead of the token, making debugging harder. We can do better. We’ve now added variants to [`sub`](https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath-sub-uint256-uint256-string-), [`div`](https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath-div-uint256-uint256-string-) and [`mod`](https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath-mod-uint256-uint256-string-) that let you specify custom error messages, greatly improving the development experience. Additionally, we’ve retrofitted our contracts with these new helpers to improve our own errors, so instead of `ERC20.transfer` emitting `SafeMath: subtraction overflow`, you’ll now get a much clearer `ERC20: transfer amount exceeds balance` message. Yay easier debugging! 🎊 ## Better documentation 📖 We’re constantly improving our [documentation site](https://docs.openzeppelin.com/contracts/2.x/), making sure all information you need to safely develop your smart contract application is available in a clear and concise manner. A special thanks to all the open source contributors that are constantly opening PR with fixes and suggestions! 🙌 ## Changelog As always, we also provide a detailed changelog with all new features, breaking changes, etc. [Take a look!](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md#240-2019-10-29) ---
**Author:** ![Agusx1211](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/agusx1211/32/1337_2.png) [@Agusx1211](https://forum.openzeppelin.com/u/Agusx1211)\ **Post date:** [October 31, 2019, 2:26pm UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665/2 "2019-10-31T14:26:24Z")
> [@nventuro](#): > > The only difference between `sendValue` and `transfer` is that `sendValue` will forward all gas to the recipient, Because of this, saying goodbye to `transfer` also means having to be more aware of possible reentrancy vulnerabilities your contract might have. We will be publishing guides on how to deal with these and stay safe soon, but in the meantime, consider using our [`ReentrancyGuard`](https://docs.openzeppelin.com/contracts/2.x/api/utils#ReentrancyGuard) and [`PullPayment`](https://docs.openzeppelin.com/contracts/2.x/api/payment#PullPayment) contracts. There is another way of doing transfers of ETH without reentrancy risks, the `SELFDESTRUCT` opcode could be used, with something like this: ```solidity library Address { function sendValue(address _to, uint256 _val) internal { bytes memory code = abi.encodePacked(hex"73", _to, hex"FF"); assembly { pop( create( _val, add(code, 0x20), mload(code) ) ) } } } ``` With a cost of 5000 GAS, it would be more expensive than using the `ReentrancyGuard` util (only after Istambul). Also, the `SELFDETRUCT` method doesn’t revert if the account receiving the ETH is a contract and it doesn’t implements a fallback method. ---
**Author:** ![nventuro](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/nventuro/32/8_2.png) [@nventuro](https://forum.openzeppelin.com/u/nventuro)\ **Post date:** [October 31, 2019, 4:46pm UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665/3 "2019-10-31T16:46:18Z")
Interesting! I had not considered that approach. However, you’d lose the ability for the recipient address to react to the funds sent, which is often a desirable property since it leads to composability. To be frank, I’m not a fan of `selfdestruct` being able to bypass this. ---
**Author:** ![glowkeeper](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/glowkeeper/32/911_2.png) [@glowkeeper](https://forum.openzeppelin.com/u/glowkeeper)\ **Post date:** [November 4, 2019, 4:52pm UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665/4 "2019-11-04T16:52:43Z")
> [@nventuro](#): > > balances[user].sub(amount) I've fallen foul of that, so the `SafeMath` error improvements is very welcome.... ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [November 19, 2019, 4:02am UTC](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665/5 "2019-11-19T04:02:14Z")
OpenZeppelin Contracts Ethereum Package v2.4 has been released. > [@OpenZeppelin Contracts Ethereum Package v2.4](https://forum.openzeppelin.com/t/openzeppelin-contracts-ethereum-package-v2-4/1783): > > OpenZeppelin Contracts Ethereum Package v2.4 has been released and is tailored for use with the OpenZeppelin SDK. See the [OpenZeppelin Contracts v2.4 announcement](https://forum.openzeppelin.com/t/openzeppelin-contracts-v2-4/1665) for details of what is in this release. For details on how to use OpenZeppelin Contracts Ethereum Package, please see the documentation: [Linking OpenZeppelin contracts](https://docs.openzeppelin.com/sdk/2.5/linking) To link the OpenZeppelin Contracts Ethereum Package into your project, simply run the following: openzeppelin link @openzeppelin/con…