This question might seem a little bit weird, but I’m trying to wrap my head around the things that ERC777 brings to the table vs ERC20.
Now, I know that ERC777 is a much more complex standard that has a lof of flexibility and provides the tools for much more complex operations than ERC20, but it’s perhaps because ERC20 is, in essence, very simple what makes it really attractive from a dev perspective.
In this case I want to wrap my head around the ERC20 concept of approval vs the ERC777 concept of operator. What is the actual difference? For example, what is the practical difference between approve(address, MAXUINT) vs authorizeOperator(address) is all the difference that actually matters contained within the concept of hooks and the fact that operators can send operatorData from the ERC777 part ? or am I missing something ?
Comparing ERC20 approve and ERC777 authorizeOperator, the main differences are the concept of default operators, and operator data. Both of which can be very powerful.
The holder can “authorize” and “revoke” operators which can send tokens on their behalf. These operators are intended to be verified contracts such as an exchange, a cheque processor or an automatic charging system.
Operators
The standard defines the concept of operators as any address which moves tokens. While intuitively every address moves its own tokens, separating the concepts of holder and operator allows for greater flexibility. Primarily, this originates from the fact that the standard defines a mechanism for holders to let other addresses become their operators. Moreover, unlike the approve calls in ERC20 where the role of an approved address is not clearly defined, ERC777 details the intent of and interactions with operators, including an obligation for operators to be approved, and an irrevocable right for any holder to revoke operators.
Default Operators
Default operators were added based on community demand for pre-approved operators. That is operators which are approved for all holders by default. For obvious security reasons, the list of default operators is defined at the token contract creation time, and cannot be changed. Any holder still has the right to revoke default operators. One of the obvious advantages of default operators is to allow ether-less movements of tokens. Default operators offer other usability advantages, such as allowing token providers to offer functionality in a modular way, and to reduce the complexity for holders to use features provided through operators.
The operatorData MUST only be provided by the operator . It is intended more for logging purposes and particular cases. (Examples include payment references, cheque numbers, countersignatures and more.) In most of the cases the recipient would ignore the operatorData , or at most, it would log the operatorData .
Let me know if that helps clarify, or whether you have more questions.
All questions are good and help the knowledge base of the community.
I just got to learn more about default operators.
My main concern is a practical one. Don’t get me wrong, I understand that ERC777 is far more powerful in terms of flexibility than ERC20, but in the average use case (i.e transfer tokens or transfer tokens on behalf of another) does it really bring anything to the table besides a lot of complexity?
i.e If, let’s say, I’m interested in the concept of operator I could simply do IER20.approve(address, MAXUINT) and I would achieve a similar functionality (minus the operatorData). It’s true that with defaultOperator you can achieve this without individual approval from every user, but that also introduces a trust issue by default.
Perhaps, where I’m trying to arrive at - is that the ERC777 seems limited to quite complex use-cases in which you want holders to have the ability to execute arbitrary code when funds are being sent/received and not so much as an “upgraded-alternative” to ERC20 (which, in my understanding, seems to be the selling point of the EIP).
All in all, it seems to me (with my current view) that using ERC777 in the average case is more a problem than a solution - specially with so many moving pieces (ERC1820, ERC777Recipient, ERC777Sender) and hooks executing arbitrary-code on top of it.
For me the most important ERC777 feature is the ability to send tokens in a single transaction. ERC20 requires two transactions, first to approve an allowance and second to use the tokens with transferFrom which is problematic for users.
There have been several attempts at a light weight approve and call mechanism. I think permit looks very promising (see: Add ERC20 permit() function)
@miohtama created an ERC777 recently after researching alternatives, so would be interested in their thoughts.
defaultOperators are hugely powerful but you do have to trust the operator (users always have the option to revoke an operator).
Hey guys, would love to hear some comments from you. I am implementing a token using ERC777 (simple enough), but I am struggling to understand the place, where authorizeOperator should be called.
I have a Token itself, inherited from ERC777, and I have a Bank, that accepts those Token tokens. Naturally, I expect that Bank would be an operator for all holders of tokens, but it is kind of a chicken and egg problems - I use Token address in Bank ctor, and I don't see how I could fit a Bank address in Token ctor to list it among default operators of Token.
So I am trying to call an authorizeOperator from inside of a Bank so-called "deposit" function, but getting an expected error.
So the question is - having such a simple structure from just two contracts, what would be "right" and "correct" place to call "authorizeOperator"?
Appreciate your response.
