# increaseAllowance and decreaseAllowance ERC20
**URL:** https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596
**Category:** Support
**Tags:** erc20
**Created:** [February 19, 2024, 11:02am UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596 "2024-02-19T11:02:56Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@irma\_maghradze](https://forum.openzeppelin.com/u/irma_maghradze)
#### Post date: [February 19, 2024, 11:02am UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/1 "2024-02-19T11:02:56Z")
We all know the problem ERC20 has about front-running `approve`, so I won't go into explaining this. in OZ v4, `increaseAllowance` and `decreaseAllowance` was added to mitigate this and honestly, the way I look at these functions, they really solved the problem. Assume Bob has 100 tokens allowed to spend by Alice.
- If Alice wants to update the allowance to 150, she calls `increaseAllowance(50)`. Even if Bob front-runs this and calls `transferFrom` beforehand, Bob will only be able to end up in the end with 150 Tokens. The same goes for decrease.
- If Alice wants to update allowance to 30, she calls `decreaseAllowance(70)`. If bob front-runs this, Alice's `decreaseAllowance` tx will fail [here](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/b53c43242fc9c0e435b66178c3847c4a1b417cc1/contracts/token/ERC20/ERC20.sol#L199)
This seems to me the neat solution.
**Question 1:** Do these 2 functions solve the approve problem ? to me, it does, but i might be missing something. Thoughts ?
**Question 2:** If these 2 functions solve the problem, why was it removed from OZ v5 ? You might say that this is because it's not original ERC20 standard, but then I ask: even though they're not a part of standard, I don't think, they being in the contract was doing any harm at all. Could you elaborate on that ? Because without these functions, the whole risk and attention must be put on client side and that's so easy to mess it up.
---
### Author:  [@barakman](https://forum.openzeppelin.com/u/barakman)
#### Post date: [February 19, 2024, 11:40am UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/2 "2024-02-19T11:40:48Z")
> [@irma\_maghradze](#):
>
> If these 2 functions solve the problem, why was it removed from OZ v5 ? You might say that this is because it's not original ERC20 standard, but then I ask: even though they're not a part of standard, I don't think, they being in the contract was doing any harm at all. Could you elaborate on that ? Because without these functions, the whole risk and attention must be put on client side and that's so easy to mess it up.
1. These functions are not part of the standard
2. Incorrect usage may lead to security vulnerabilities
3. The implementation itself may contain a (so far undetected) security vulnerability
4. Increased byte-code size (more expensive to deploy AND brings closer to the max limit)
In short, removing these functions improves the gas-cost, the security and the simplicity of the contract.
---
### Author:  [@irma\_maghradze](https://forum.openzeppelin.com/u/irma_maghradze)
#### Post date: [February 19, 2024, 1:46pm UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/3 "2024-02-19T13:46:50Z")
Thanks for the answer.
By any chance, are you working at OZ ? I don't mean to be the pain, but I don't buy these reasons. Saying that it improves gas-cost is not a good and useful answer. By looking at the code with increaseAllowance, gas cost comparison is unnoticeable - as for the simplicity, I also don't buy this.
I might agree with security, but still, anything in the smart contract can be risky, so I also don't buy this reason.
Don't get me wrong, these are just my opinions. I also would appreciate @frangio's answers on this.
---
### Author:  [@barakman](https://forum.openzeppelin.com/u/barakman)
#### Post date: [February 19, 2024, 2:14pm UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/4 "2024-02-19T14:14:49Z")
> [@irma\_maghradze](#):
>
> are you working at OZ ?
No
> [@irma\_maghradze](#):
>
> Saying that it improves gas-cost is not a good and useful answer
It's not an answer, it's a fact!
Reduced byte-code size leads to reduced gas cost during contract deployment.
In addition to that (though not directly related to gas cost), it also allows implementing other functionality, which might otherwise cause the byte-code to exceed the maximum limit of 24KB.
> [@irma\_maghradze](#):
>
> as for the simplicity, I also don't buy this
Simplicity allows for:
1. More simple (hence better-quality) audit of the contract code
2. More simple (hence better-secured) usage of the contract functionality
In short - you don't add code which is "nice to have", you add code which is "must have".
> [@irma\_maghradze](#):
>
> I also would appreciate @frangio's answers on this
Sure thing, but note that most if not all of what I wrote is mentioned in various OZ posts and discussions (and probably even in the release notes of v5 itself).
---
### Author:  [@irma\_maghradze](https://forum.openzeppelin.com/u/irma_maghradze)
#### Post date: [February 19, 2024, 2:21pm UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/5 "2024-02-19T14:21:46Z")
Thanks so much for your help. I have a favor to ask. Can you put a link where OZ guys discussed this and came to the same conclusions as you have ?
---
### Author:  [@barakman](https://forum.openzeppelin.com/u/barakman)
#### Post date: [February 19, 2024, 2:23pm UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/6 "2024-02-19T14:23:20Z")
I initially pasted a `Let Me Google That For You` link, but as it turns out, this is now considered an offensive way of sharing knowledge. So I've added one such discussion below, and you may find additional discussions pointed from within that one, but feel free to Google more of them yourself...
>
>
> \> If there is another issue that discusses the same topic, feel free to close th…is one.
>
> I wanted to quickly get your opinion on whether it would make sense to remove the functions \`increaseAllowance\` and \`decreaseAllowance\` from the \[\`ERC20\`\](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) contract and move it to an extension contract instead. My arguments are the following:
>
> \- These functions are \_not\_ part of the \[EIP-20\](https://eips.ethereum.org/EIPS/eip-20) specs.
> \- These functions may allow for further phishing possibilities (instead of the common \`approve\` or \`permit\` ones; see e.g. just 12 hours ago someone lost $24m since he got tricked into signing a malicious \`increaseAllowance\` payload https://etherscan.io/tx/0xcbe7b32e62c7d931a28f747bba3a0afa7da95169fcf380ac2f7d54f3a2f77913).
> \- The security concerns that fix \`increaseAllowance\` and \`decreaseAllowance\` are not critical nor high in the wild (and \`decreaseAllowance\` can be frontrunned also) and thus I think the responsibility can be delegated to the devs to decide whether to include it or not.
> \- If such a change is implemented, the upcoming breaking version \`5.0.0\` would be suitable.
---
### Author:  [@irma\_maghradze](https://forum.openzeppelin.com/u/irma_maghradze)
#### Post date: [February 19, 2024, 6:00pm UTC](https://forum.openzeppelin.com/t/increaseallowance-and-decreaseallowance-erc20/39596/7 "2024-02-19T18:00:26Z")
I can google myself, no worries. I asked you to copy/paste the link because I wanted us to be on the same page(we must be reading the exact same thing , so it's easy to ask questions). If you're reading something else and I am reading a different discussion, we would end up in a loop hole.
Thanks for the link.