 I'm honored to be here. I'm Jordi Bailina. I'm a developer and Ethereum fan and founder of Giveth. I'm a little distracted today because just now in Catalonia there were eight members of my government detainent for defending democracy and my people right of self-determination. We have a huge opportunity to bring these centralized tools minus three in Catalonia. We need it. But I am here to share a bit of my passion for smart contracts. In this presentation, I will first talk about the minimi 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 Giveth. Let's start with the minimi contract. Minimi has been developed a year ago. It follows the year C20 token standard and has been used extensively by many important projects in the Ethereum space. Here you can see some of these projects, Swarm City, Aragon, Status, Giveth, District 0x, and many others. So what makes minimi contract different? It's more than just a simple year C20 token contract. The token has many functionalities that any DAB 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 this smart contract. The contract tracks the token distribution history on the blockchain. This property is what makes minimi contract different and allows this token to be cloneable, forkable 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 set for the future. After the fork, each clone token is independent of each other. Much like ETC fork or Bitcoin Cash fork. All these properties do not come for free. And the main disadvantage of choosing minimi token is that the gas cost of each transfers is a little bit higher than the non-cloneable 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 burned after the token holder votes, making it impossible for him to vote twice. Using the token contract this way prevents having to lock the mind token while the voting takes place. Another interesting application is the distribution of rewards among token holders. When you want to distribute rewards on a regular basis, it's possible that you run in the problem that the distribution of the token may change as token holders trade the coin. Minimi solves 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 was issued. The same way you create a voting token, you can also create many functionalities, like discount token or reputation token. A discount token would work this way. The discount 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 applied. Another usage is to create a token for a spin-off DAO. The Minimi 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-223 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 of the recipient is called with this extra data. As you can see, the main idea of this standard is to work very much like Etherworks right now. This standard is not ready yet. To get there, the two main points that needs to be resolved are first backwards compatibility, which I think is solvable. For example, you can always create wrapper contracts in the worst case. And the other point that is necessary, in my opinion, is to define a pseudo-introspection standard. Mainly pseudo-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, EIP-165 and EIP-672. EIP-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, EIP-672, in my opinion, makes more sense and it's much more scalable. The idea of EIP-672 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 iTokenFalback 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's 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 ERC-223 standard, one of the biggest shortcomings is that it cannot transfer tokens to the current multi-seq implementation because they are contracts that don't implement the token-Falback function. To work around this, a new version of the multi-seq should be deployed. But this can be solved easily with EIP672 by creating a reverse ENS entry for the IToken-Falback 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 mini-me functionality and the ERC-223 token with the EIP672, we get a super flexible contract. This is the new token contract Giveth is working on right now. We call it internally YogaToken. You can imagine it quite. In my opinion, this YogaToken could be a perfect candidate to be considered for a standard Ethereum token, especially if Ethereum-based government systems like Carbon Voting or Protocol Voting are to be developed. Of course, the gas problem may still be an issue, but this can be minimized by enforcing only epoch snapshots instead of block snapshots. Now the last topics to finish this talk. I would like to introduce liquid pledging. This is one of the main open source smart contracts that have been developed at Giveth. While 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 liquid democracy meets fund management. Essentially, you can manage 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 subdelegate 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 wants to donate 100 ether to projects that improve security. He wants to do good, but he's a very busy person and doesn't have the time to analyze all the projects in the space. On the other hand, we have Buki, who is a very active member of the community and also very much concerned with security. He has complete overview of all the projects in the space and knows which key projects should be supported. With liquid pledging, Gap can delegate the authority over his 100 ether to Buki so he can select the right project. Buki decides that the best one to support is the two-factor authentication project for MyEtherWallet, so he precommits the ether. At this point, Gap has three days or any time pre-configured to veto if he does not agree with Buki's choice, but if he does nothing, MyEtherWallet project is a great supporter. This can be a normal account or it can have a smart contract plugin attached, where a reviewer, let's call this reviewer griff, if griff decides that the work is done, the ether go to Taylor for successfully implementing two-factor authentication. But if the project does not meet the conditions 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 ether 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 funds go. I want to mention that this contract is also an extensive contract via plugins. In these plugins, you can add a specific condition like token allocation when the project is phoned or setting a hardcap for a given project. The liquid pledging contract can be used not only for donations, but also for organizations management. In an organization, the investors delegate the funds to CO, to delegate the budget to the directors, the CTO 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 predominates the ether to a specific project, and the investor 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 hierarchical delegation chain of trust. To wrap up, I would like to leave you with three key takeaways. First, if you need an advanced token contract, consider the Minimi contract, which has been fully tested and implemented. Second, the yoga token. It brings together the features of Minimi plus the ERC223 with EIP672. This is a powerful token to be considered as a standard for the Ethereum community once the standards are approved. And third, the liquid pledging contract. Could be ideal for many usages. It's especially suited for blockchain-based donation systems that can make a world a better place, but it could also add interesting functionalities for many dApps. And now, we have reached the end of my talk. I welcome comments and feedback. Please feel free to reach out to me, to Griff, or to any Giveth team members. If you want to learn more about our open source contracts, you can always check our Giveth.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.