And I do see my presentation. So what I present today is a protocol and a use case for it, which combines verifiable credentials and NFTs to do what, to basically tokenize digital assets in an A interoperable and from, for me, from the world where I come from, that specifically means cross chain and secure way and secure means crypto level, secure. And by combining these two protocol worlds, we believe that we are achieving something that is very close to the best of two worlds and the best of the two worlds. Being that in general, and this is not a qualified statement, it's just an impression that I had through many, many discussions with stakeholders. Verifiable credentials are very acceptable to business people. They're acceptable to policymakers, they're acceptable to the eu. We've heard the word quite, quite often in Germany, you, you, you have ID union, which is now expanding into Europe.
So the kind of fear of the unknown, which very often people that work on in the pure blockchain world are facing is not really an issue when you come and explain you delivering secure communication using decentralized identifiers, verifiable claims, verifiable credentials and verifiable presentations. The other advantage is if you do it right, a verifiable claim or a verifiable credential can be made to look and feel very much like a hello sign DocuSign or DocSend because the doc, the, the data that you see in a PDF and then sign in DocSend, that actually from a use user perspective is pretty much what you do when you par, when you issue a verifiable credentials to somebody and that person then counter signs. So, and most of all verifiable credentials are completely interoperable. The colleagues from Serian did mention it already. It's not blockchain specific, it exists self-contained, contained and, and it is crypto, it's as secure in its own way as blockchain.
So those are the advantages for the, I call it the D I D world, but if you want to program transaction systems markets, then well, anybody who's honest enough with himself knows there is nothing available in the D I D world and I'd be blunt enough to say there will be nothing available in the next five years. On the other side, you have very, very, very lively markets, transfer of tokens, transfer of value, very secure without intermediaries using E R C 20 tokens, using NFTs, et cetera. Very easy to program programming once you get the nick of IT, programming smart contracts is actually very smooth and very fast and very efficient. And by combining these two worlds, we believe we can create a system that has the acceptability and the transparency of verifiable credentials, but comes with the market size and the market power and the programmability that we know from the world of E R C 20 tokens.
From N and from NFTs. Okay, now what are we trying to do? Well, trying to tokenize digitized assets and the use case that I'll be presenting it, we will be tokenizing renewable energy certificate. It's a form of energy attribute certificate. Most of you know carbon credits, which is another form of energy attribute certificates. So the point is you basically is buy them, issue them, trade them in a way that can be traced to a source, a source of truth, the issuer of the original actually in the real world pd, it's mostly PDFs, energy attribute certificate. And then you convert this to verifiable credentials and from there you convert it again into an nft, which is the protocol I will be sketching out. And then you can trade it on zein, you can trade it ont, which are crypto exchanges. You can, and also you can just transfer it in your own way.
So what are we trying to do here? What we're trying to do is, in order to be able to do any of this, basically for in order to digitize an asset, you need to prove the identity of everybody involved, the issue with the holder, the buyer, et cetera, then you need to verify and digitize the asset. So the asset exists for instance as a vehicle title document, the asset exists as a carbon credit in certified by gold or VERA standards. So which is as far as we are concerned in the crypto world and also from the D I D perspective and the VC perspective still offline. So you need to have the ceremony, the know your asset, know your customer, verify the origin, the source of it so that you now have it in a digital format where you can apply digital signatures and tie it to identities.
Then you need to prove the ownership. So this asset is now digital. It appeared in the hand of somebody with A D I D. How do we know in the real world this asset which is being traded here actually belongs to the person who has this D I D. So you need to prove the ownership and then that all of that is in the world of decentralized identifiers and verifiable credentials. Now you've done what you need to do and what you basically want to do now is now I have ownership, I can start business now we can trade this and the trading, we then switch the the thinking, we switch the protocol and we say, let's not bother doing the trading based on verifiable credentials. We're not gonna get anywhere. Let's try to just use NFTs because NFTs are eminently tradable, they're really smooth, we all know that.
And thanks to Dr. Kaska of severity, one of my big gurus when it comes to D I d, I'm not sure whether he's at the conference, I assume he probably is. So he pointed out to me that if you look at a very fiber credential and if you look at an N F T, they are equivalent or to be precise, you can buy software design by architecture, you can make them be 100% equivalent. Roughly speaking the d i D of holder and issuer be the equivalence to that is the wallet that's holding the NFT and the data and the actual claims and credentials that are being signed in the verifiable credentials are equivalent to the data that are being managed by the ERC 7 21 contract and linked to the token with that specific id. So that's in a nutshell how they are actually equivalent.
Okay, so verifiable claims are interoperable certificates of asset ownership. So we, I believe I would expect that most of the participants in this conference know what the verifiable claim is. I'm using the word verifiable claim rather than verifiable credential because in this example that I'm, it will be a claim to an asset. So the word applies better when you use the same technology. For instance, for ticketing, which we do for blocks move mobility, then a verifiable credential is a good equivalent or a ticket. But if you're dealing with title document certificates, et cetera, then the word verifiable claim seems semantically closer to the, to the origin of what you're trying to do. And once you have a verifiable claim, you can basically issue the issuer can give it to the, to a new holder, which would be the customer, which is a transfer of asset ownership.
And what is being transferred? Well, the verifiable credentials need to contain the necessary data, the necessary verified data of what ownership it presents. The simple example is a vehicle title document. You would take the data fields that are in a vehicle title document, kind of set brief titled . For those of you in Germany you would essentially from a software perspective, you can just j make Jason's out of it. That's okay. What matters is that that Jason is signed by identities that correspond to the real authorities in the real world in this case the the, that actually has the real world rights to certify ownership of a vehicle title document. Okay? So an asset can be expressed as a verifiable claim certificate. Then we will now move on to, we will now show how this can then be trans transformed into an nft. So we have a claim, it's valid, it's valid in the world that all of you in this conference know and that actually you use libraries like spion for to program it.
So all of you, I'm assuming this is pretty much known territory, but then you go forward and what you do is you convert this into an N F T and you make sure that it's always tied correctly. And the only real interesting problem that you need to solve is doubles. You need to avoid double selling because we are trying to achieve interoperability, which means the origin is the verifiable claim. Then you can transform it into an NFT on polygon, you can bur you can transform it back. So you can transform the N F T burn it, reissue the same verifiable credential, go to Binance smart chain and then reissue the, basically transform the same verifiable credential which is still valid back into a Binance margin. Nft. What you need to ensure, that's the important part is that as the, the object must only exist on one chain or as a verifiable claim and the protocol must ensure that otherwise you could be double selling and triple selling and quadruple selling for that.
An important part that you will require is not many chains have that, not many protocols have that you do. A key element that you need is verifiable credential revocation actually, and this is a call out to the Syrian colleagues, I what you really need here is not revocation. What you really need here is suspension. So ideally you would be able to suspend the verifiable claim when you transform it into an NFT because if it's traded as an nft it must be frozen as a verifiable claim because otherwise you could sell sell in this world as well as in this world and that is not allowed. So if anybody out there sirian, hello, anybody out there knows of a protocol or a library or an S D K that does very, that does verifiable claim suspension, that would actually be perfect. So suspend and unfreeze, freeze and unfreeze, that's a protocol which we haven't found yet.
So we actually revoke and reissue, which is kind of not exactly perfect, but long story short, the main point here is to avoid the double selling, you do it, the verifiable credential needs to be revoked once an equivalent N F T has been minted. Okay? And then you have an nft. And once you have an nft, I consider my job done because anybody who's ever used a blockchain and traded NFTs knows how bloody easy it is. It's just piece of cake. And then you talk to a developer, you can program a whole market exchange system. Two developers in three weeks can program you actually a very, very compelling proof of concept slash mvp.
So these NFT certificates, as I will now be calling them, are essentially NFTs which provide secured digitization of access rights business claims as well as ownership. They are part of a bigger protocol suite which blocks move is developing. So you might Google NF ticket blocks move than you'll find a lot about it actually NF ticket, the protocol upon which this is based is actually the core engine for our mobility platform because we use the ticketing and the payment for mobility access control based ticketing, we use also NFTs for that NF tickets and the use case for these digital certificates is actually a subset in terms of software complexity of what the wider ranging NF ticket protocol was built was built for.
Okay, now the summary of the how is this possible? How can this guy come here and we are in a conference which is essentially identity based and this guy is coming and you know what fiber claims and D I D is all nice and well we all know it but actually NFT is the same. So I'm sure the one or the other of your of the purists in here is already kind of making notes know that is not correct. And then with arcane educators we can discuss this endlessly, but the fact is they are equivalent and I'm going through the main arguments here. So verifiable credentials, I'm so it's verifiable credentials. Verifiable claims are based on decentralized identifiers. Decentralized identifiers are being standardized by the worldwide web consortium. The standard is getting wide traction and acceptance among policymakers and organizations. So the regulated world likes that protocol.
The regulated world generally speaking seems to have an aversion to crypto and verifiable claims or verifiable credentials are an excellent way for secure and very, very decentralized exchange of validated documents. At the end of the day it's a document because just like DocSend, when you sell a car, you you or you sign a contract with a counterparty, you're doing it by DocSend. So there there's a business underlying, but what you're doing in the software world, you're doing document signing. So these are validated documents. Jason's usually which can then be formatted more eye pleasing on the web front end and they express credentials such as a driving license or a ticket or public transport. They can author express access rights, they can express. That's another very compelling use cases invoices actually. And last but not least, they can express carbon credits or renewable energy certificates. So that's verifiable credentials.
Now what's an N F T? The shortest I believe complete definition that I have that I have for NFTs is an NFT is a token with a serial number that covers it. It's simply a token with a serial number and it is also and here comes the beef, here comes the power, here comes the beauty due to the genius of Vitalik brine and the people that essentially dreamt of E R C 20 and then E R C 7 21 and now E R C 1155. It is actually executable content within the operating system of the respective blockchain. You are coding it in and NFTs are always contained within a wallet. So there is an owner by nature, by protocol, there is an owner and the owner of that NFT is a wallet. So they are irrefutably tied to their current owner for visible to the public, to the owner's public key and secured by the owner's private key.
And now comes the part where how do we do this NFTs and NFT is just a very, very simple interface standard the action, it's less than 400 lines of code. This the a default ERC seven to one contract is less than 400 lines of code. So it's actually tiny and it leaves the world open. It's an interface so you can extend it as much as you like as long as you don't break the interface. What that means is you subclass it and if you guys know oriented programming, you subclass it and you add additional data to your heart's content so you can add any type of data into this and that's basically the power that you now get for somebody that knows how to code. Plus you have this kind of nice thing of the meta data where you have link where you can basically have links to data and documents and that's important because remember a verifiable credential is a document you have da, you can have links to documents for instance on IPF F s which is usually used which are part of the NFT data and transferring an N F T is first of all much, much easier.
There's, I dunno how big the market is currently is anyway, it's billions of dollars per week prob and at the heyday it was billions of dollars per day that are being transferred as NFTs and transferring an NFT is equivalent to presenting a vc. Alright? That is the design considerations which we put at the bottom of all of this.
So we are using it to resell and trade energy attribute certificates with our partner NR verse and our verse that I own. And what they are doing is they are sourcing energy attribute certificates from a well known in the real world organizations such as Zet or others you can also go to Vera or Gold standard et cetera. So you do rely on a root of trust in the real world, which you then need to prove that it is this root of trust which is actually issuing the original document. Then what you do is you basically issue the first verifiable credential with A D I D which you can prove is held for instance by the owner of this. Let's take the example Ecot, the way you tie this in, you use something called D I D config, the well-known protocol. So you anchor it actually to the X 5 0 9 HTTPS SSL certificate.
So essentially anybody who owns https my domain.com will be given a D I D and can then with this prove that this d I d is indeed representing the real world already pre-authorized X 5 0 9 certificate authority route trust tree and the D I D now has is tied to this trust anchor. So this is how the trust anchor is created. Then we create an NFT cert and then we convert it to the smart contract and that is when we start trading them. So the actual use case was here, this is here. So n r verse which is was our partner and this can be done, this is as far as we are concerned, this is our user. They get from the supplier for instance eco, they actually get DocuSign PDF documents. You just bought X amount of kilowatt hours of renewable energy region Africa type wind and you get that essentially as a third P D F, you pay for it.
Then you have this organization issue, this P D F sign it with the D I D that's tied to their HTP X X 5 0 9. So now you have a very fiber credential which can be tied back to the original supplier of the real world, which then will be issued to and others they know, they know have a claim that proves we now own these kilowatt hours which have been issued to us by a known trusted party and this known trusted party has obviously signed it because we have a very final claim of them. Then we do our magic. So we convert this into an NFT and NF ticket gets minted a payment happens and it now is an NFT and it can be traded on open C or any other marketplace or your own marketplace that is able to display, visualize an N F T and then at the end of it execute a sale and the transfer of the N F T because that's all you need to do.
The security being the same because the wallet address and the D I D based on the protocol that we're using, which is the very simple but very standardized or quai standardized D Ethereum, the wallet address and the d i the corresponding D I D address are one-to-one full duplex link. So if you have the D I D, you can always derive the wallet. If you have the wallet you can always derive the D I d. Okay? And then you basically sell these to customers and they can now be traded downstream. So this is an example and with this I will end. So at the end of it, how does this look? So what do you see on the left side? On the left side you see open C, that's the main point here. So this is a screenshot of open C. Why am I showing open C?
Here I'm showing open C to emphasize the point that this is a fully standard conforming N F T. So here we got some nice visuals from blocks move but, and now come in comes the metadata. Do look at the properties. These are what's called the traits of the N F T and these are part of the metadata in the E R C seven to one standard. You will see 13,123 wat hours solves is actually solar Africa. Then you will see 7,323 watt hours wind for continental Europe and we have the field, this NF ticket is actually issued by whom blocks move. And that's us. Then here you will recognize that this is at the A part of a verifiable credential and you will see now here the you have regions Africa, continental Europe, Africa, continental Europe, volumes 13,123, 13,000 1 23, 17,323, 17,000 3 23 NF ticket by blocks move in total it's 30,446 kilowatt.
And from here on below this you have the signatures. So, and we basically transformed this verifiable credential, which was the source of the whole game. We transformed this into an N F T that actually contains exactly the same data. And then to add insult to injury, what we are doing in the metadata, you will see this little picture here. They have now disabled it, but it's still in the metadata. There is something in the metadata which is called external U url. And now comes the part that's, I like it, it's, it has humor. We basically store the verifiable credential on I P F S. You will see this here and that very fiber credential which was used to create the N F T is then pa the external U URL field in the metadata of that very same url. And if you click on this external URL arrow here on open C wbo, it takes you exactly to the original verifiable credential. So not only have we transformed it marshaled and unmarked, serialized and des serialized it, but we actually always keep them together. That's the main point how this protocol works. Okay, and with that I would like to end, I hope there's some questions and with that I give back to the moderator or the audience.
Thank you so much. Thank you so much. It was a great presentation. We actually have some questions from the audience. How do you assure that the verifiable credential is not transferred simultaneously to two different blockchains?
Yes, I mentioned that actually during the presentation. We, we, this is what you need revocation for. So as part of and as part of the transaction atomic, it must be atomic obviously as part of the transaction where you actually mint the NFT and connect the external URL to the now defunct verified the credential. You do need to revoke it. If you don't do that, then you will be able to double sell. So the answer is you need revocation or against sirian post. Ideally we would have a more flexible approach, which is not revocation and recreation, but rather suspension and unfreezing.
Great. Thank you for this answer. And another question is, how do you assure that the verifier credential representing the ownership initially is revoked? Is revoked when transferring it to NFT? And is there an appropriate policy for the ID issue defined and publish as a standard?
Can you give me the second part of the question one more time?
Yes, yes, yes. So how do we assure that the verifier credential representing the ownership initially is revoked when erring it to nft? And apart from that, is there an appropriate policy for the ID issuer defined and published as a standard?
Okay, number one, that is by design. So the answer is through the design of this protocol. That is how we ensure it. So we ensure it with our code is the short answer. And no, this is not a standard we, it'll become open source, but we as in blocks move, we do not have the time for these standardization committees. So frankly said, we don't bother, we cannot, we can't be bothered with that. So we are just rolling it out. It's free for everybody to use. But no, it's not a standard. And as far as we concerned, it will also probably never be a standard because we don't have the resources to play the standardization game.
Great. Thank you so much for your answer. Thanks for this presentation.
Yes, another round of applause for Dr. Harry Barrons.
Thank you so much.
