 My name is Wei Wu and the founder and city of smart token labs. We are a team of about 40 people and we have been working in tokenization for four years. And in the last two years, we have witnessed a lot of brands take their huge interest in the NFT and blockchain space and we helped many of them to tokenize their brands. And this is our learning. First, there's a strong demand for brand brands to connect their audience with an NFT. There's a difference between a brand lover and a holder of brand token. That gives the brand access to their audience, allow their users to access the ecosystem and put a value into their loyalty. But there are two barriers. First, wallet. Not many people in the brand's audience user base have wallet and it's not easy to get it there. And second, signature. So a lot of users hesitate to sign any message or transaction when they are holding brand tokens and understandably so. I'm going to talk about three cases where we helped brands to tokenize and I will explain how we overcome or amended these barriers and share our learnings. So first, La Prairie is a Switzerland luxury skin care brand. It's the world's number one and their user base high net worth people with a love for art. So they do art exhibition, art review, art auction. And that's basically their market position. What we did for them is a space beyond an NFT project for everlasting digital art. However, these are not traditional, these are not technical audience. These are traditional art buyers and you can imagine most of them never had a wallet before. And the format of the sales is quite traditional as well. You can imagine a giant hall with a rotating light and display of digital art moving slowly and people holding champagne in their hand and sales was done in that moment. And you can understand that this is not perfect moment to teach them how to install a wallet and get the seed freeze. So what we did for them is we allow them to purchase the art with their credit card. And we will send them an email with a magic link that contains the cryptographic information needed to later prove their ownership of this digital art if they need to use that with a smart contract or debt. So after the sales, the buyers can set up their wallet in the later time. And these sales was linked with their email address and they need to obtain the email address attestation and link that with their email address. And from that moment on, debts and smart contracts will recognize them as the legit owner of this digital art. This way effectively have pushed the moment of install wallet to a much later date. Therefore, smooth out the onboarding process. And that's the first example. The second one is actually this devcon and the target audience is everybody in this room. This time, understandably, our audience is more sophisticated and most of us have a wallet. But we still find it beneficial to smooth out the sales process, use attestation and there are user experience improvements using this technology. So we did permissionless perk, which is a project where third party websites can recognize devcon ticket holders and give them special perks and offers. This is done by sending an email to every ticket buyer with the ticket attestation magic link. If you click that link, the cryptography information to prove that your ticket holder is stored in your browser. And later when you access third party websites, these information will be working to prove that your ticket holder. And again, if you should sign a message or do a blockchain transaction, the link in the cryptography information will be linked with your wallet that can be configured later stage. Therefore, users can buy devcon ticket with credit card without worrying about wallet and get wallet set up later. Beautiful thing about this design is devcon does not have to verify the ownership. It's not like Google, for example, every time when you use Google ID, Google has to be online and you connect to them. Devcon can be offline when you're using permissionless perks. So that's what we did for devcon. And the last example is Shopify, where we provided, worked on the VIP shopping experience via NFT. The idea is if you hold an NFT, you can access gated content, special discount or special offers on the Shopify website. What we discovered is user hesitated to connect to their wallet on e-commerce website. So we give them our product, Brand Connector, which allows users the option that they can be brought to a safe website, connect to their wallet, choose which token to use in the shopping process, and the proof will be sent back to the shopping website for the shopping experience. And this allows users to not having to expose their wallet address to the Shopify websites. And the users will not have to sign a message on the Shopify website. So these are the three projects we did that I want to share with you today. And if you observe all these, you will notice that all these projects about how websites can interact with token holders, third tokens. And all the technical details such as wallet connection and signature are just infrastructure to support this happening. And in terms of user experience, they are actually the hurdles. So that brings me to this point that we are working on the infrastructure to support use of token on websites. But there is a much bigger infrastructure issue at play. That is, today's Web3 websites lack the trust anchors. Now, before I explain the trust anchors, let me ask a question. We know today that Web2 websites are built around centralized points, such as Facebook, Google and Apple. And we know that Web3 is decentralized web, which does not depend on these centralized services. And we have been building depths for that future. But which depths we built today can replace Google and Facebook and Apple to provide these essential Internet central services. I will elaborate this with an example. So suppose you are buying the ticket from movie theater. Let's see the minions. You go to movie theater, log in. You probably will log in with Google ID. You probably will pay with Google Pay or Apple Pay. Once you got movie ticket, it can be saved into your Apple wallet. And once you finish purchase, you might want to share it on Facebook or you might want to add it in your Google calendar. Or you might want to get a Google Map pointer. This is a typical Web3 Web2 experience. It is very smooth. In five minutes, you used five or six central services provided by Web2 by Google, Facebook and Apple. These are not just central services. These are trust anchors because movie theater website cannot do this by themselves. Even they have the software and code. They cannot provide Google ID login even if they have the login code. If they don't use it, they would have to end up with user management password. They cannot share it on your shared movie purchase to your friends because you are not entrusting them the movie theater to manage your friendship. It's not because they don't have the code. They can have open source social media, but they don't have the trust anchor to do so. So today's Web2 experience was enabled much by these trust anchors. And today's customers are already used to that. They will not go back. They will expect no less from Web3. But where are the things that can serve at this function Web3? And DApps will not do that. We've been building DApps, but DApps is not for it. Three reasons. First, user demand convenience. Users don't like to go to a third party website to go to... While they are shopping, go to a DApp website, prove they have the token and come back to the shopping. Similarly, in Web2, they don't want to go to PayPal, finalize payment and go back to the checkout process. Second, DApps suffer from the same security and availability issue. DApps are just normal websites. They are not secured by blockchain consensus. Blockchain smart contracts are. DApps are not. They are repeatedly hacked and they are sometimes not available. Compared to Google and Facebook, which have very high availability. And finally, DApps are not designed to be composable. So I'll give you an example. Let's say the movie theater allows you to pay the movie ticket with Ether. Unless you have an AAVE line of credit which you can draw Ether from. Today, you will go to AAVE DApp, draw Ether and then go to the movie theater and pay it. It's not an integrated process. Smart contracts are composable, DApps are not. So there's three reasons DApps couldn't do the trust anchor role. But can it be tokens? We have been working on tokenization for four years and we have seen a lot of cases. And I'm going to share my experience with you on token working and the trust anchor. But let's hold on for a moment to think about it. Today, everything is based on the existence of the central trust anchors. It's actually quite hard to imagine Web3 without them. It's hard to imagine what will the trust anchor be if we don't have Google. Will the Google login, Google ID be an identity token? Will the Google calendar become a calendar item token that is in users wallet? Will the friendship, the connections you have on Facebook be tokens? It's difficult to have a picture of the Web3 with new trust anchors. We don't know what they will exactly look like and how will they exactly work. But we figured out four requirements for tokens to act as a trust anchor. And these four requirements are trust, interoperability, privacy and security. Happen to be TIPS for you to remember. Trust means that users should not trust websites as much as they trust their tokens. Again, take the movie ticket for example. If you have NFT, let's say the minions, and if you want to buy discount ticket with that, you won't trust the movie theater website as much as you trust your minion token. You don't want to connect your token there, connect your wallet and do any transaction. The website might be insecure and steal your minion. So trust anchor should be on tokens, not on websites that uses tokens. And second, interoperability. That means you should not depend on websites to have the correct code for your token. So you don't want to go to a website which sells you. Sorry, we cannot serve you because we only recognize version 2 of the minion token. You have version 3. You don't want to wait for them to upgrade. Or you don't want them to, if you have a new token, take them the next cycle to understand your new token. So token and the website code should be separate and interoperable in between. And then we have privacy which simply means that the website should not know everything in your wallet. It's not okay if you go to movie theater and now they know how much ether you have or everything you have. And finally there's security meaning that you cannot trust, you cannot dedicate transactions to the websites. Let's say you have the minion token, let's say you can lend it to a friend to get this discount ticket. You don't want the movie theater to do the lending because how do you know the movie theater website is doing it correctly and not taking away your money or your minion token. So transaction should be done by secure code that comes with a token. And with these four requirements satisfied we developed our core technology called token script which is enabling technology for token to work as trust anchor. I don't have too much time to go into technical details, but I will explain the design principles and the technical characteristics of token script. First, it is strongly bound to contracts meaning that the users should trust token script as much as they trust contracts. They are written by the same team and there's cryptography proof about their linkage. And second, token script is not executed on a blockchain. They are executed in the user's wallet, in user's agent. For example, our for wallet which is our wallet product leading open source wallet with more than 700 fox. It has a runtime environment for token script so that token code can run the wallet and interact with the website. And then it is composable meaning that you can use multiple tokens in one web process which is not often seen in today's steps. So you can use one token for payment, one token for discount, and you can get a movie ticket as a new token downloaded from the website into a wallet. It's composable on the front, not only on the blockchain. And finally, it has both UI and API. And this is different than most tokenization solutions. So most tokenization solutions today build tokens like API, for example, the graph. You can acquire a token and get, for example, the date of creation for the token who is the current owner. But it's crucial for token to be a trust anchor. It's crucial that tokens have user interface. If you go to a movie theater website and login as Google, you will hesitate if it doesn't display the Google logo or if the login box deviates from the Google experience. Similarly, if you want to use the Minion token on the movie website, token has to control the part of the UI that interacts with the website. So it's essential that tokens generate UI in a trusted environment. So we have eight minutes left for my talk and then I have finished sharing all my knowledge. But I want to pause here and let all do a thought experiment. We have been living in the world enabled by blockchain center points for so long. It's actually hard to imagine what internet could look like if we did not have to depend on the center points. For example, if you have a Tesla car, they have integration with Google, with Apple wallet. Tesla car key can be an Apple wallet and you can send it to your friend if he wants to borrow your car to do this on iOS as long as you're in the same ecosystem. This is the organization. It's done in the iOS system, it's not done on the blockchain. But you can do this now today, but can you flow to your Tesla car on the rental market by ours through the same technology? You cannot do this today because Apple is not allowing it. I don't know why they probably don't say it profitable. It probably is too complicated, but you need Apple's permission to do this. What internet would have looked like if you didn't have to depend on Google to permit you, Apple to permit you to do this? You would be able to set up a rental market very easily as long as tokens support them. And the smart car vendors will produce their own smart car tokens to allow this to happen. You can rent a market in Bogota or any city. You don't have to be a world leader to operate a rental market. I'm not getting it. What is the license of the codebase? Is it a parent source or something? License. Our implementation is in MIT license. Right now it's embedded in our wallet and it's not a standalone product. We will make it a standalone product. Right now, our wallet has 700 folks and most of them didn't tell me about it because we allow MIT. Hello, how are you? I was going to ask, what do you think are the main barriers for tokenizing traditional banking or finance products such as portfolio purchases? And what do you think would be the position of traditional banking system towards this kind of innovations? If history is proven true again, they will be the last wave to be tokenized. So they will be under a lot of pressure and eventually move their ass. How do we know which token providers can we trust? We don't know. The thing is, although token is used as a trust anchor to enable web services that doesn't require users to trust them as much as token, token itself needs to be trusted. And the level it can be trusted is actually a game-free market competition. How would they know that this company isn't, let's say, a phishing scam? I actually don't know. I imagine that the wallet will have a calendar integration. So if you enable wallet calendar integration, the wallet will create a calendar token on your behalf, on your name. But whether or not other people will believe that you will actually realize your promise if you sell your calendar item to other brand. That would require some form of testation, like you have reputation, stuff like that. We are building these things, but I don't know how it would look like in the end. Well, thank you so much for the presentation.