2 - Approvals as a way to automate value flow.
Someone new to Ethereum and coins in general looking at the interface for ERC20 I’ve left above might ask: “yea, I understand what are all these balanceOf(), mint() and transfer() for, but why would I ever need to approve()?”. At least for me, when I was reading about all of these tokens for the first time, it seemed like a very niche mechanics. Like… okay, if I have a friend whom I’d like to allow to spend some of my crypto, I could just send it to them, right?
Let’s read the original description for transferFrom method.
The
transferFrommethod is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies.
So, it is used not like I was first wondering. It is used to let smart-contracts transfer your tokens and automate actions. Okay, but why did they choose to do it this way?
Is this the only way? - No, there is at least one more (we’ll talk about it a little later).
Is this the most efficient way? - No, you have to make two transactions to send your tokens to a smart-contract, since they are reactive and only do something when they’re told (one to approve an amount and one to trigger a smart-contract to call transferFrom for you).
Is this the safest way? - Maybe. Back in those days they were really afraid of famous re-entrancy attack, and since the approach with approvals is immune to this attack by default, I believe, they decided to stick with it. But now re-entrancy is studied well and while we write our code carefully we’re good to go. So, I believe, while approvals are safe, they are inconvenient to integrate with and misleading to understand, but that’s not the real problem.