3

In DeFi I have seen that users are prompted to give access to their funds. Why not just send those funds to the smart contract instead?

What is the advantage of this design?

1
2

There is no "advantage". The reason most DeFi apps ask users to "allow" the transfer of their funds is that those funds are represented as ERC-20 tokens. The Ethereum community is confronted with an instance of the classical path dependence problem.

Here's a guide that dives deep into ERC-20 allowances. And here are some practical solutions:

  • ERC-20 Permit: adds a "permit" function to the ERC-20 standard.
  • ERC-777: a new token standard altogether. This doesn't have much traction as far as I know.
7
  • 1
    It is possible for a DeFi frontend app to integrate a protocol that they didn't build themselves. E.g. 1inch.io, which is an aggregator of DEXes. But yes, when the creator of DeFI frontend is the same as the creator of the DEX, there is no third-party. Sep 18 at 14:04
  • 1
    If my answer helped you, could you hit the upvote button, or potentially mark the answer as accepted? Sep 18 at 14:04
  • 1
    If there is no third-party but the tokens are ERC-20, you still need allowances. The token smart contracts would be the same. Sep 18 at 14:21
  • 1
    If they weren't ERC-20 tokens, then yes, potentially there would be no need for users to approve the tokens before transferring them. Read about ERC20Permit and ERC-777. Sep 18 at 14:22
  • 1
    Re path dependence - what I meant is that ERC-20 is an old standard. It dates back to 2016. Lots of things improved in Ethereum in the meantime. If we were to design a token standard from scratch, we would make it quite different today. Sep 18 at 14:22
2

Generally, there are two ways to transfer (ERC20) tokens:

  1. Direct transfer with transfer. You can call this function to transfer your tokens directly to another address.

  2. Indirect transfer with approve and transferFrom. This way you do two different transaction: first you give approval for the receiver to withdraw your tokens. Then you call some functionality in the receiver, and that executes transferFrom which takes your tokens.

I think there are two advantages of using the indirect method:

  1. Functionality. If you use a direct transfer, the receiver has no idea he has received tokens. You would anyway need a second transaction to tell the receiver that "hey, I sent you tokens, now do your part of the deal", and you'd suffer also in security. Also, with approvals, if you trust the receiver, you can just approve all of your tokens and do multiple trades with the same approval - so just one approval and multiple "second" transactions.

  2. Security. It's harder to trick users into sending tokens to the wrong place if it requires two separate transactions. Also, this way you can in advance read the receiver's contract code and see what happens when you do the second transaction. With direct transfer you'd simply have to hope that the receiver does what it promised to do.

3
  • First: Why not just have a function that is payable that users call and it executes the necessary code? Second: Wouldn't my first point mean that you can still, in advance, read the receiver's contract code and see what happens when you do the second transaction?
    – YulePale
    Sep 18 at 14:06
  • Payable function has nothing to do with transfering tokens; it's only used for Ether transfers. Tokens are always transferred by calling the token contract's functionality Sep 18 at 15:33
  • 1
    Now I understand. To the blockchain all you are doing is calling another smart contract's function.
    – YulePale
    Sep 18 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.