The Future of Token Contracts: MiniMe, Governance, LiquidPledging & ERC223

I'm honored to be here i'm jordan valina I'm a developer and answering fan and founder of givethe I'm a little distracted today because just now in Catalonia there were eight members of my government detain it for defending democracy and my people right of self-determination we have a huge opportunity to bring the center lights tools - dreaming catalonia we need it but I'm here to share a bit of my passion for smart contracts in this presentation I will first talk about the mini-me token contract then give you some highlights on how I see the future of token contracts and finally I will briefly introduce my latest development the liquid pledging contract which we are currently using at givethe let's start with the mini-me contrac mini-me has been developed a year ago it was it follows the year C 20 token a standard and has been used extreme extensively by many important projects in the interim space here you can see some of these projects from City Oregon status given district 0x and many others so what makes mini-me contract different it's more than just a simple year C 20 token contract the token has many functionalities that any tab may need these functionalities includes creating and destroying tokens black or white listing addresses freezing transfers among others but let's get to the real innovation of what it is of what is a smart contract the contract tracks the token distribution history on the blockchain this property is what makes mini-me contract different and allows this token to be cloneable for cable if you want that means that you can create a new token whose initial distribution is the same as the original token this clone fork can be done at any given block in the past or can be said for the future after the fork each clone token is independent of each other much like it is a fork or BT Bitcoin cash for it all these properties do not count for free and the main disadvantage of choosing Minami token is that the gas cost of each transfers is a little bit higher that the non clone of all ones all these functionalities are important for the next use cases the first one and one of the most important one is the voting application use it in many governance systems this means that at the beginning of a voting process a clone token is generated and born after the token holder boats making it impossible for him to vote twice using the token contract this way prevents having to lock the mine token while the boating token was the voting takes place another interesting application is the distribution of rewards among talking holders when you want to distribute your words on a regular basis it's possible that you ran in the problem that the distribution of the token may change as token holders trade the coin mini-me solve this problem because you know the balance of any token holder at any time in the past so you can easily create a contract that distributes rewards according to the holdings that each token holder had at the moment its reward both issued the same way you create a boating token you can also create many functionalities like this cone token or rotation token a disk on token would work this way the disk on token may be used to buy another token at a given discount and it will be redeemed when the new tokens are purchased and the discount is supplied another usage is to create a token for a spin-off down the mini token also makes your project future-proof making it easy to upgrade to a new version of the contract but probably the most incredible facet of this token is that anyone can create a clone token in permissionless way so that anyone can add value to the community let's talk now a little bit about the future of the token smart contracts the future clearly points to the ERC two to three standard proposal there is mainly one operation in this standard that operation is transfer and with this transfer you can attach data once the transfer is done if the recipient is a contract the token fallback function is of the recipient is called with this extra data as you can see the mine idea of this standard is to work very much like either works right now this estándar is not ready yet to get there the two main points that needs to be resolved our first backwards compatibility which I think it's solvable for example you can always create rubber contracts in the worst case and the other point that is necessary in my opinion is to define a pseudo introspection stander mainly through the introspection means that you can ask to a smart contract about the implementation of a specific interface to standardize this we currently have two very different proposals JP 165 and the AAP six seven to EAP 165 is very straightforward you just define a support interface function that is the smart contract may implement then anyone can use this function to query if this contract implements a specific interface or not the other proposal ip67 to in my opinion makes more sense and it's much more scalable the idea of EAP success 6 7 2 is to use reverse ENS to keep a database of interfaces implemented on each existing contract let me give you an example of how this would work imagine that a contract implements a token fallback interface and the constructor of the token would add this entry in the reverse ENS for people that don't know how reverse ENS works it mainly defines a domain for each address normally this address is assigned to a human readable name so you can set a name for your address but you have full control of this special domain assigned to your address so you can create subdomains in our case we define a subdomain with the interface name that the contract implements and make it point to the address responsible for implementing the interface in most cases this will point to itself if the contract implements the interface but that not strictly necessary and this is where the standard gets interesting this entry can point to a different proxy contract think about it this allows for future functionalities and future interface to be easily supported when they come coming back to the year see 2 to 3 standard one of the biggest shortcomings is that it cannot transfer tokens to the current multi-sig implementation because they are contracts that don't implement the token fallback function to work around these a new version of the multi-sig should be deployed but this can be solved easily with a ip67 - by creating a reverse E&S entry for the iTalk and fallback interface that points to a proxy contract that just accepts the transfer and this is very exciting this also gives the possibility of executing some code not only when tokens are sent to a contract but also when tokens are sent to a regular account if you assign a proxy to a regular account you can for example prevent receiving a payment you don't want or trigger any code you desire when regular account receives tokens at this point if you put together all the minimal functionality and the year see 2 to 3 token with the a ip67 - we get a super flexible contract this is the new token contract giveth is working on right now we call it internally yoga token you can imagine in choir in my opinion this yoga token could be a perfect candidate to be considered for a standard aetherium token especially if the theory on base government systems like carbon boating or protocol voting are to be developed of course the gas problem may still be an issue but this can be minimised by enforcing only epoch snapshots instead of blocking up shots now the last topics to finish this talk I would like to introduce liquid pledging this is one of the main open-source mark contracts that have been developed at givethe well not exactly a token contract it extends some powerful functionality that can be applied to any token what's liquid pledging about liquid pledging is where requite democracy meets fund management essentially you can your tokens or let someone else manage them with oversight with a normal wallet you manage your tokens you have a balance you have transfer functions inputs outputs and that's effectively all with liquid pledging not only you can manage your own tokens but you can also manage someone else's tokens you do this by creating a hierarchical chain of delegation you can give the authority of the tokens to a delegate the delegate can do the same with a sub delegate and so on the most important feature is that after you delegate the tokens you are still empowered to make decisions regarding the use of these tokens as the owner you have the complete oversight to make it clear let me give you an example gap is a community member that's very concerned for security in the blockchain and once to the Nate 100 inner two projects that improve security he wants to do good but he is very busy person and don't have the time to analyze all the projects in the space on the other hand we have wookie who is very active member of the community and also very much concerned with security he has complete overs overview of all the projects in the space and know which key projects should be supported with liquid pledging gap can delegate the authority over his 100th ether to baki - so he can select the right project boo-ki decides that the best one to support is the two factor authentication frost project for my other world so he pre-commit the aether at this point Deb has three days or any time pre-configured to veto if he done doesn't if he does not agree with bogies choice but if he does nothing my the wallet project is a great supporter this can be a normal account or it can have a smart contract plug-in attached where a reviewer let's call this reviewer grief if grief decides that the work is done the ether go to tailor for successfully implementing two-factor authentication but if the project does not meet the conditions it in the in the given amount of time he can cancel the project and the money goes back to Buki and gap and gap has again oversight over how the 100 either can be used as you can see this contract has many advantages the owner has full control of the tokens full transparency and knowledge of where their phones go I want to mention that this contract is all is also extensible contract via plugins in these plugins you can add a specific condition like token allocation when the project is phoned or setting a harp at for a haircut for exceed for a given project the liquid pledge account the liquid logic contract can be used not only for donations but also for organizations management in an organization they the investors delegates the funds to Co the CEO soup delegates that the budget to the directors the city of delegates to the system department and so on and the investors still have full control on where the funds are spent and invested the same idea applies in fund management where a delegate pre commits the ether to a specific projects and the investors has the last word on where the investment goes there are many other great ideas one that I like a lot is liquid lending and by the way this is done from a startup from Mexico it's called Aurora Libre in this concept a microcredit is made via a higher akiko delegation chain of trust to wrap up I would like to leave you with three key takeaways first if you need an advance talking contract consider the mini-me contract which has been fully tested and implemented second the yoga token it brings together the features of mini-me plus the year C 2 to 3 with with a ip67 - this is a powerful token to be considered as a standard for the theorem community once the standards are approved and third the liquid pledging contract could be ideal I could be ideal for many usages it's especially sweded or block chain based donation systems that can make a world a better place but it could also add interesting functionalities for many dubs and no we have reached the end of my talk I welcome comments and feedback please feel free to reach out to me to grieve or to any givethe team members if you want to learn more about our open source contracts you can always you can always check or a guy giveth dot IO website here are some links and thank you to the foundation for having me here and thank you to all of you for your attention [Applause] you [Music]