increaseAllowance and decreaseAllowance ERC20

Support
1

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

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.

2
  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.

3

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.

1 Like
4

No

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.

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".

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).

5

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 ?

6

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...

2 Likes
7

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.

2 Likes