DAPPCON 2018: ERC777: a New Advanced Token Standard - Jordi Baylina (Giveth.io)

Transcript

yeah 777 as she talked as she said it's an evolution of the year see 20 a brief introduction of why we need an upgrade on air see 20 first we need to be aware that years see 20 is one of the most successful ER sees that we are in the space that we have in this in the in the space if not the most right now there is more than 500 value tokens the capitalization of those tokens of course

depends very much in the market but above for 25 billion dollars so we would say that LC 20 is a huge success but your C 20 the people starts using your C 20 even before the standard was finalized and your C 20 has some still has some issues that stops evolving and stops especially from the user perspective and from the application perspective to evolve and to create more more advanced applications some of these problems that your C 20 are are especially that when your C 20 you send tokens to a contract the contract is not

aware of that and in general when you send tokens to a contracting them in the most natural way just transferring to the contract the easiest that will happen is that your tokens will be locked in that contract unless the contract has some mechanism to recover that but that's the most typical and if we see the quantity of tokens that are just locked in those contracts are are are quite high in order to transfer to a contract because sometimes you for example you you want to do an IC o---- with tokens or you want to buy something or you want to change some tokens in what you have to do is you have to first approve it's a transaction and then you call a function on that contract that actually makes a transfer for you which

this is something that's not intuitive for general user so of course there is some other more technical other more technical issues like there is a defining race condition in the elements process and also you cannot attach that for a transaction and you also cannot prevent from receiving tokens of any kind okay so the main proposal the big proposal of the triple7 your si is to use tokens very much as you use ether so in ether we have a transaction in general the transaction has three three three parameters to who we send how much amount and add add a

data a data is general is what function you Cal and what are the parameters of the function okay and so when you are sending ether to a contract the contract is aware that is that's receiving that ether that somebody is calling with the specific parameters so what we do is exactly the same but with token so we define we define a sin we define as we define a sin transaction that also has an a destination we had has an amount and has a data this is much the triple seven so it works very much the same way that works with with with with ether okay next step the other thing that we do is we remove all the other ones

mechanism and we introduce the operators we see that most of the most of the times in the year see 20 the way that the people is using the other ones mechanism is the way that that we are just allowing full allowing a specific smart contract to move the tokens for us we call this special contract an operator okay and this is a very powerful idea on that we don't define how much this contract can move because we should define like a lot of conditions on that so we let the smart contract to define that conditions and we just approve we just approve this operator we just allow this operator to

act with us and this is an opt-in for action that the user of the ERC can handle we expect that there are many operators and we expect that in the future we'll be many standards that will be built on top of that that will define some operators okay so examples examples of operators we see for example a Czech processor so I can write the check and I send it a check to the to her and here you can keep the check and maybe use the check by sending that check to a Czech operator that will actually do the move the Czech operator contract will actually move do the transfer on that relays we saw yesterday is Alex understand all the usability

part that there are star using the layers on that this is a relay or can also be an operator on that so it's like instead of myself moving I just allow I just alpha writes an operator after layer operator that moves the tokens for me as far as the rules on the smart contract of the operator are fine to me and then the operator can can allow can make these transfers in my in my in my name of course on exchange the centralized exchange payment subscriptions one for example that I'm buying a magazine that every my Alpha rights to some smart contract to make a payment once a month we can do it that with a subscription manager description

manager operator financial services and many other applications that we built on top on that in that and that the the way that works an operator is of course there is an authorization so each address needs to authorize an operator it's possible for a specific token that there is like predefined operators that are define it with with the same token itself and the operator just do just that do like like the transfer from its equivalent very much like the transfer from in a year see 20 we call it different but operator sin and from two amount and data and we also add that the operator that operator data could be for

example the check number or the invoice number or some other information that operator could that in the payment on that on that part okay well here you can see for example this a an operator for example to allow for example to transfer tokens from a code word wallet from a specific account with some restrictions you could do it for example in order to not have to use a cold wallet and a low another token that for example let remove one either daily from your account you can use that for as an example of an operator and that another functionality that we add in the year C

20 is the capacity of hooks what are hooks hooks are functions that can be called before so during a transfer so the transfer how it happens so I'm going to transfer I'm a contract and I'm going to try I'm going to transfer to another contract some some tokens so before the the actual transfer the token contract calls me and says the a and you are going to transfer that so I have the option for example to a stop transferring and to book some limitations in my smart contract it's um a half the option to be called before the transfer is done and the same way once the transfer is

done in the in the in the recipient part has the choice to do to do something for example he the recipient can't reject accepting the tokens for example or for example I can take part of the tokens and give part of the Tongass to a donation campaign or it can maybe distribute send take the tokens and give them to some distribution contract for something else so we have this a possibility of having control having like the last chance for a sender to for a sender to to do not know to not allow to control what's going out of my account of my contract and from the receiver we have also the

option to do something once we receive that once we receive the tokens okay so the mechanism is how we create a contract that handles that supports this that supports this this cooks how we define a contract to be called before transferring or after transferring well we use the year C 20 standard your C 20 standard mainly is a registry where it says okay this address implements this interface so it's a centralized database but this centralized because it's mark on track

its own trust untrusted the smart on trusting a smart a smart smart contract so mainly that the main idea is that the contract just defined say I'm implementing this interface so when the token wants to do the transfer before actually doing the transfer will come to me or in the other side I'm implementing the token recipient interface so once I get the transfer the token contract will call me we'll call me after that after after their tokens are are transferred this year C to 820 has some interesting insights technical insights for example is well it's of course it's an unknown

or less trusted contract it's a it's a contract that can be deployed in any network having exactly the same address using an interesting mechanism I would I'm not going to go deep on that but you can read the standard it's a very interesting way of deploying smart deploying smart contracts so the idea is to put a predefined signature and then recovering the address that will deploy that smart contract then we send easier to that address and then broadcast the transaction okay and also it's interesting because this this this contract is the IP 165 compatible so you can ask for example to this a smart

contract if a specific smart contract implements an interface and can be a near the IP 165 interface so it acts very much also as a cache of the sixty-five so it follows all the compatibility on on that another thing that has this this DISA standard we seen that we have seen that in the in the year see twenty there has been a lot of conflict with decimals there there are contracts with six decimals with adding decimals with two decimals with 2500 with many decimals so what we are doing here we are changing a little bit around

we are saying okay the number of decimals that all the tokens will have is 18 which is the standard in in the theorem and then we add a new concept as the granularity is how much what's the smallest unit of tokens that we can transfer for example if we have a something that's just one one chip something that you cannot divide then it would be that the granularity would be one to the 18th that's the minimum unit in general if your token is fully revisable for example if there this would be this would be one but for example if you have a token that would resents with coins then maybe it would be ten to the ten okay so or a new row

that just two decimals and you cannot divide the same then maybe will be 10 to the 16 okay so that's the granularity and we change that way importance this standard so you can its think so it's mainly design it in order to be fully a backwards compatible with your c2 any now so you can right now you can implement a new token that's a newer see triple 7 token and it's fully compatible with all your seats so you have a token that's your C 3 plus 7 bytes also ER c 20 and fully in fully compatible at least almost fully compatible wills you

know the small small differences but that means that you can implement the token that you can still use the transfer you can use the reproof you can still use the transfer from and the standard defines how you have to implement that in order to be compatible on that what are the small exceptions that on that the smallest the small extensions on that is that if you define if your contract has hooks that we defined before the hooks the hooks are goes takes precedence over over that so if you have a hoop that you cannot receive tokens because you have put something on the recipient and say you I knew I don't

want to receive tokens even if they are using a legacy transfer transfer from from the ERC 20 you your tokens so this function will throw and you will not be able to receive tokens so except for that there are other things you can still use on that one thing that for example when you are trying to send in a triple seven if you are trying to send tokens to a contract that is not prepared for receiving tokens then this this transaction is this this this transaction will throw of course if you are using transfer for compatibility reasons it will not throw but if you are using a sin if you are using then the normal way that triple 7 does it means

that that the contract needs to be prepared in order to receive that tokens for to use for the same this keeps the compatibility for example if I'm using a token that is not a triple 7 compatible but triple but your seat only compatible I still am able to do an approve on a normal ERC 20 transfer to there and it will continue it will continue to work and that so that that's very important because this allows to create new tokens keeping the full compatibility and without having to code and having this problem of backwards compatibility and so it's not breaking sort of breaking a

standard on that yeah well of course there is a mechanism that if at some point letter letter in the future you want to disallow this backwards compatibility you can do it if you want okay but we I expect that this will take like a long time but it's in the standards preventer than that so that's very much what's the LC triple seven about just to summarize it solve the mind you'll see 20 problems is backwards compatibility with LC 20 is similar to other theorems method to send tokens to a contract we have these extra fields for for

transferring the data and some operator operator data that we can use on the transfers we have all the operators with half of the hooks have this granularity and well it's as said before it's a this standard is having a good acceptance in the community the status of the project right now well right now we expect that during this weekend it will go to the last call set so once enters in Alaska then it takes maybe something like between two and three weeks to be final if there is no more issues phones from that so we expect that yeah for you August this standard we should be

finalized maybe takes a little bit more a little bit less depends of the community depends on depends very much on how things works but that's very much the standards and once this once is finalized and sub to you to start doing your to creating your own contracts okay so that's that's my presentation [Music] [Applause]