Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Omer Shlomovits & Ouriel Ohayon: ZenGo – The ‘Keyless’ Crypto Wallet

Episode Date: September 24, 2019

Those who have been in crypto long enough remember the not-so-good-ol’ days when an air-gapped machine was the only way to store private keys securely. Thankfully, the wallet space has come a long way from that era. But we still live in a world where the seed phrase is the single atomic point of failure. Enter threshold signatures schemes (TSS), a multi-party computation (MPC) where different parties generate a key and are all required to create a valid signature. We’re joined by Omer Shlomovits and Ouriel Ohayon, Co-founders of ZenGo. Their product is a ‘keyless’ crypto wallet, which means users never need to generate or store a key which gives them access to their funds. Keys are created with an MPC, where both ZenGo and the user are required to sign a transaction. TTS opens up exciting new possibilities like social recovery, user permissions for teams, and inheritance planning schemes. The important distinction between ZenGo and existing multi-signature wallets is that they achieve this using only cryptography, and do not rely on on-chain elements like smart contracts or op_scriptSig in Bitcoin.Topics covered in this episode:- Omer and Ouriel’s respective backgrounds in academia and online consumer-facing products- What lead them to want to build yet another crypto wallet- The state of custody in the crypto wallet ecosystem and the challenge which remain unaddressed- A quick refresh on cryptographic primitives and multi-party computations (MPC)- The building blocks of cryptographic signatures and threshold signature schemes (TSS)- How TSS is different from Bitcoin multi-sig and smart contract multi-sig- TSS in ECDSA vs. Schnorr signatures- Applications and use cases for TSS- ZenGo’s on-boarding, restore process and use of biometrics- The future of wallet interoperability in a world of proprietary cryptographic schemesEpisode links: - [ZenGo: Bitcoin & Cryptocurrency Wallet](https://zengo.com)- [‎ZenGo: Bitcoin & Crypto Wallet on the App Store](https://Zengo.com/enjoy)- [Threshold Signatures Explained](https://www.binance.vision/security/threshold-signatures-explained)- [ShareLock: Mixing for Cryptocurrencies from Multiparty ECDSA](https://eprint.iacr.org/2019/563.pdf)- [KZen Networks on GitHub](https://github.com/KZen-networks)- [Zengo Research](https://zengo.com/research/)- [KZen Research Telegram Group](https://t.me/kzen_research)- [Tel Aviv Blockchain Week Recap with Anna Rose of the Zero Knowledge Podcast](https://www.youtube.com/watch?v=ccywXWTSFKM)Sponsors: - Vaultoro: Trade gold to Bitcoin instantly and securely starting at just 1mg - http://vaultoro.com- Trail of Bits: Trust the team at the forefront of blockchain security research - https://trailofbits.comThis episode is hosted by Sebastien Couture & Brian Fabian Crain. Show notes and listening options: [epicenter.tv/306](https://epicenter.tv/306)

This is Epicenter, Episode 306 with guests, Omer Schlumovitz, and Oriel O'Hion. This episode of Epicenter is brought to you by Valturo, the gold hedging platform for the crypto community. Trade gold to Bitcoin instantly and securely, starting at just one milligram. Go to Voltoro.govol.com slash epicenter to get early access to their V2 platform and to start trading. And by Trail of Bits, don't leave your project's security audit to just any first. Trust a team with decades of experience at the forefront of blockchain security research. Go to trail of bits.com to learn more. Hi, welcome to Epicenter. My name is Sebassiakutio.

And my name is Brian Crane. So today we're speaking with Oriol-Ojayan and Omar Shlomovitz. They're the co-founders of Zengo. I met them in Tel Aviv. I was just in Tel Aviv for the blockchain week there. And they are building a really impressive, of what they call a keyless wallet, and we'll go into the details of what that means,

but effectively, they're really revolutionizing, sort of the UX and the user experience around wallet onboarding and wallet recovery, which, as many of you know, is a difficult problem to solve. Yeah, I know.

I mean, the episode was very technical. So that's kind of on the one hand, but on the other hand, right, really it's a simple user experience. And I think that's, one of the things that's really cool is that we're starting to have these simple and just great user experiences. I think there's Zengo, there's a reason to try that Argent on Ethereum, which is also like that. So that's really cool. So I think the wallets are getting there to when the next

masses enter the space, they'll have something that will actually be pleasant to use. Yeah, so Argentin is another wallet in the space that I've been following quite closely. I've been using it. But the difference here, I think, is, you know, it's good to mention the difference is that Argent is a smart contract wallet, so it uses on-chain smart contracts to do sort of multi-sig and social recovery and these sorts of things that, you know, one needs in a good user experience for a wallet. Zengo has a different approach. They're using advances in cryptography, so what we call threshold, signature schemes to allow different parties. to sign transactions. And so they've got a whole research team there doing really advanced

work in cryptography and multi-computations. And I think are probably one of the most competent teams in this space. And being in Israel as well, you know, they have access to some of the world's best cryptographers. You know, they work, I think, very closely with Aal, who's been on the show before and is a professor of Technion. So, yeah, very good team working on a really good product. So I would encourage everybody to try it out. Yeah, absolutely. So speaking of Israel, you were just in Tel Aviv, as you mentioned at the Tel Aviv blockchain week. How was Tel Aviv? What are your main takeaways? How is surfing? So, I mean, I was there for 10 days, about 10 days. Yeah. So it was a really packed week. So there were three conferences overlapping over two weeks. So there was scaling Bitcoin, Ethereum and Starkware sessions. I mean, I'm not going to go into all of the details of those three. conferences here, but I did do a short Anna Rose of the Zero Knowledge podcast was also there,

and we sat down actually in the Zengo office and we recorded a short recap of those three conferences and that will be on YouTube probably midweek. So just as this comes out, go to our YouTube page and you'll see that short video I did with Anna. I mean, at a high level, I think it was really great. You know, the Scanlan Bitcoin conference, I was kind of pleasantly surprised that there wasn't any of the Twitter tribalism there, at least when people meet in person, they're quite decent to each other. And the Stark Recession's conference was also really, really fantastic. They put on a really great event, and we should definitely have them on at some point. So look forward to that on the YouTube channel. And also, we'll be releasing, in the next

coming days, some bonus content from DAPCon. So that was actually about a month ago, but we've receive the content from them. So the Epicenter Live episode that we did there will be released to the feed in addition to some other panels. So I, Sonia did a governance panel and I did a user experience panel. So we'll push that out as a bonus episode on the feed in the next coming days. So with that, here's our interview with Zengo. Hi, we're here with Oriole O'Hoyan and Omar Schlomervitz, both of whom are co-founders of Zengo. Hi, guys. Hi.

Hello there. Thanks for joining us today. So we're going to get to talk about Zengo, the product you're building, which is a keyless cryptocurrency wallet. We're also going to talk quite in depth, I think, about cryptography and some of the new techniques that you're working on, specifically multi-party computations and threshold signature schemes. But first, let's spend a little bit of time speaking about your backgrounds.

Perhaps starting with you, Oriel, you have a background in Web 2.4. and previously you co-founded TechCrunch France, I believe over 10 years ago. How do you transition into crypto? Actually, I started at Wet 1.0. I saw the internet's blossoming on our computers. And then indeed, I saw the birth of Web 2.0 with blogs and social networks. I had multiple experiences as an entrepreneur, one of which is the one you described. I was the founder of Tech Ranch in France.

I also worked many years in venture capital, both here in Israel, countries where I moved 16 years ago, but also in France where I started a venture fund there. And I built multiple companies. A lot are related to consumer technologies, and now obviously in cryptocurrency. So we're going to talk about that. And I've been bouncing back and forth between building and investing. So with the cryptocurrency space, you know, how did you get into that and what appealed to you about the crypto space and specifically the problem of building a wallet? Well, it was very interesting because I've been an early adopter of virtually everything that has been around for the past 20 years except crypto.

I came very late to the space and I'm ashamed to admit that today because. it's 100% of my time and I wish I did that earlier, but I've been building apps for, for other platforms for many, many years. And sadly, you really quickly realize that your business is depending on the back of others. And when I saw the possibility to build apps that would not depend on a dead switch and only on a platform to decide whether you should exist or not, it was attracting to me and that started to get me excited and curious. And very quickly I discovered it was a real revolution, not just for apps, but for money and trust and in general anything that we do in the society. So I wanted to invest all my time in it.

Quickly, I met Homer, my co-founder right here, and we decided to build this company with two other co-founders. And now we're building this crypto wallet, which we launched recently. And, Omar, you come from the world of academia, which for longtime listeners who have followed our podcast, for a while, probably be aware that Israel has a very vibrant scene in the sort of cryptography space. Tell us a little bit about your background and what's your relation to the broader cryptography scene in Israel. Yeah, so I think I grew up kind of naturally into the space. Starting a few years ago, I was doing my CS PhD supervised by Professor Yudalindel. By the way, I was focused on multi-party computation. But I, I,

search for what to do my, on what to work. And then I encountered these whole concepts of who of work and smart contracts and it attracted me. It was back in the day where it was easy to follow on everything that is published in the space. And special thanks to Stefan de Zimbowski, which I think his work and papers kind of inspired me and also Vitalik, obviously. And it's And yeah, and after a few years, I met Oriel, he pitched me about his idea, the problem of wallet. And I was fascinated by it. So I just grew up everything and joined him. I think Oriel, you had to pull Omer out of his previous startup to get him to join you at Zengo, right?

Well, he pulled himself great. Yeah, I think he's a smart guy and a studio opportunity and was just a good timing. So on the wallet question, what was it about, I mean, cryptocurrency wallets have been around since, you know, for a very long time. I mean, you had initially the, you know, Bitcoin QT wallet, people started doing mobile wallets. There are certainly hundreds of wallets a day. Why did you guys feel there was an opportunity or like, why focus on that particular aspect of, you know, all of the different things you could build? So just zooming out, the problem that we were really focusing on was private key management, which is indeed directly correlated to what wallets are about, but not just.

And when I stepped into that space, I was expecting something that would be, you know, the level of experience that I've been used to for the past 10 years, you know, on a mobile smartphone and all these great apps that we've been using developed by other developers. And what I discovered instead was something that was looking, to be honest, a bit of a praise story and jump back in terms of what, you know, user experience means. So that was really the first kind of break for me. But what I quickly discovered, it was not just a user experience issue. It was also something that has deep consequences in terms of security and what it means in terms of liability. And, you know, if the first 10 years of crypto have been about.

trying to become your own bank, the episodes and the accidents and the hacks have proven that being your own bank comes with a price, which is very expensive. And sadly, that was related to the fact that the solutions in place were just not good enough. And I could not imagine blockchain and crypto being a revolution, reaching hundreds of millions of users with the same type of experiences. And so for me, that was the first thing that got me started, like identifying. this problem that seemed pretty obvious, that was actually solved many, many times, but in such a way that was not really scalable for the existence of that industry. I was just not able at that time, at least not without Homer, to identify the right technical solution to build something that would be more appropriate,

that would be at the same time extremely simple but also extremely secure. and all the solutions I could find were either extremely not simple or too secure in a way. And that was just something that we thought was very important to work upon, no matter how much solutions were coming to the market, actually still coming until today. So we still think it's early days and that we still have an opportunity to build something that matters. Well, Brian and I have been in the space long enough to remember a time when one had to install Armory on an air-gapped laptop and sign transactions on one machine and carry those transactions with a USB stick to another. And things have certainly improved a lot since then. But I'm happy to

know that you guys are working on improving that user experience even more. And I think that that really helps to bring new people into the space. I mean, like hardware wallets, for instance, we're a great step in the way of user adoption and improving user experience around security. But, you know, as we discussed when we were together in Tel Aviv, like that's still a long ways away from just being able to, you know, open an app and use crypto and have the same types of assurances that you have with something like a hardware wallet. Where do you see the state of crypto custody today?

Like, how do you differentiate the different types of wallets? You put wallets in classes and how do you see that sort of broadly? Actually, the analysis we have is very simple. There are today's wallets with private keys, and that's the entire category of the space. And this principle forces to a certain type of user experience, whether you are on a hardware wallet or on a software wallet or on a paper wallet, you have to manage your private key, which forces a tedious onboarding process, recovery process, is likely to be prone to accident, human error, and hack. And so this is how we're looking at the entire space. We are bringing something of a different color, which requires no capability to be able to handle your private key, because there is no private key to handle. There is no secret to remember.

There is no password to store. So we call that keyless and passwordless experience. Homer in a second will explain how we have enabled that technically, and there is a lot behind it. But the end result is extremely simple. And so the space today is really fragmented between solutions that are built around private key as atomic unit of secrets that you have to manage. And if they get compromised, it's game over. There is no button called my, I forgot my password. The reality is that today most people who own crypto prefer to store their funds on exchanges, so on centralized solutions.

because the other alternative is just too painful. And so today the majority of custody happens on centralized exchanges, which also is not great. It's another form of poison because you are not in control of your funds. If a hack happens, everything is gone. The insurances that they provide are just fractional, and so they're not good enough. And so there is something better that needs to happen.

And we're trying to bring up this kind of hybrid solution, best of both world, where at the same time you are in control, you are the owner of your funds. Funds are on chain, but there is no typical complexity, tediousness associated to onboarding that type of solution. And we are as a server, as a service, unable to spend or unable to become a point of failure to the user like custodian or exchanges. So this is the new flavor we're bringing to this market.

The best way to understand is to try it because it's obvious from the first second you're trying the app. And I think it may be worse today right now to explain a little bit more how this magic is being possible because there is a lot behind it. If you're holding a significant portion of your net worth in crypto, you're probably waiting for your portfolio to moon any time. But holding crypto doesn't mean you should be irresponsible in the face of volatility risk. That's where Voltauro comes in. Voltauro is the leading gold hedging solution for the crypto community.

And as a stable asset, trusted for millennia, gold is the perfect long-term hedging solution. And at Epicenter, we've been using Volturo since 2014 to protect a portion of our company's assets against volatility. Now, you might ask, why not use a stablecoin, Seb? Which is a great. And don't get me wrong, stablecoins are great and a real benefit for crypto adoption. But algorithmic stablecoins are still very new and experimental asset type. And some asset-backed stable coins have been scrutinized for being under-reserved. With Voltoro, your gold is 100% insured and secure it in vaults deep in the Swiss mountains protected by Brinks. Every single gram of gold is audited and holdings are made transparently available on their website for anyone to verify.

And most importantly, it's quite literally your gold. You can choose to have it delivered to you at any time. To learn more and to get access to Volturo's brand new V2 platform, which includes an interface overhaul and trading in dash, like coin, ether, and silver, go to Volturo. That's V-A-U-L-T-O-R-O dot gold slash epicenter. We'd like to thank Valtoro for their support of the podcast. Before we go there, though, what other companies in the space do you put in the same category as Zengo? I would personally put Argent, for example, in that space. Are there any others that you see there?

I've not seen a lot doing what we're doing. We've seen companies that are using multi-party computation to provide private key solution management. We've seen institutional solutions trying to, bring this kind of also solution, but we have not seen any wallet being implemented that way. At least none that is cross-blockchain and not, you know, Bitcoin-specific or Ethereum-specific, so that tie users to a specific blockchain or set of features. And we haven't seen any definitely none that is using threshold signature and multi-party computation that is, we call that consumer grade.

So I do see, though, we do see, though, new generation of players that are trying to improve the experience with all sorts of ways. whether this is by using multi-sig or smart contract or all sorts of creative ways to do things. But you know, it's interesting to see this kind of new generations of solution coming. So we're going to get into, you know, the details. I mean, right now we talked about Keyless wallet.

Probably people have no idea what that means. So we'll get into how this is actually done with Sengo. But before we get in there, we wanted to speak a little bit about, you know, kind of this landscape, of cryptographic work and research that, you know, what you're doing is situated in. And of course, there's been so much advances, right? There's things like zero knowledge, cryptography, multi-party computation, homomorphic encryption, you know, in addition to the existing technologies.

And now you guys are focusing on threshold signatures. Are you able to provide maybe just a little bit of, you know, kind of a landscape? and help us to understand where threshold signatures fit in this, you know, in the kind of overall space of cryptography? Cryptography, yeah, advanced cryptography is really nice breakthroughs over the last few years, and we are focused on the field of multi-party computation, where eventually a set of parties or people want to, to jointly compute a function, any function, but in a trustless manner.

So it's without trusting each other by exposing some private information. Okay, so let's say that we want all of us to compare our salaries without exposing the exact amount that we make. Just we want to see who is the one that is making the most. Okay, so this is the function here. So this is like a very basic example of MPC. Now over the MPC has been, has been around for a few decades, almost 40 years now. And it started with like a very basic way of doing it between two parties, which was not very efficient.

And it got better and better until now we have excellent ways or frameworks that you can do a multi-party computation with any sort of. set or any number of parties that you can define the setting of the how many of them are corrupted. There are also for specific functions like digital signatures, for example, there have been works that have focused specifically on those problems and came out with excellent solutions that are super efficient on how to produce a multi-party computation just for this specific type of problems. Okay. So threshold signatures usually refers to this kind of bucket of solutions on how to do digital signature algorithm with multiple sets of parties in a very efficient way. And just over the last couple of years, there's been an explosion of academic papers just around this topic or now you can do it in a way that is applicable to the cryptocurrency and blockchain space.

Now, the entire field of MPC is, as you said correctly, is related to homomorphic encryption and also to zero knowledge proofs. So zero knowledge proof are a tool that is being used inside multi-party computation. Usually, it's being used when you want to, let's say there are two types of adversaries, generally speaking in MPC. One, which we call the semi-honest, which means that I cannot do anything to change the protocol, but maybe given the entire transcript, he can deduce all sorts of information that would break privacy, and there's the malicious adversary, which is like maybe similar to a Byzantine cult in distributed systems.

It's like, do not restrict him and he can do whatever you want. And when we are moving from a semi-onist to a malicious adversary, what it means is that basically we need to prove along the way throughout the computation that everything is done correctly. So each step that the party is taking, it also involves some zero knowledge proof that shows that this step was done in a correct way without exposing the private information, right?

Because in MPC we do not want to reveal the inputs, and zero knowledge proof has this property that you are able to prove some statement without exposing the witness or, again, the secretive. So this is how you, usually they are related. There's also more involved ways. I mean, you can also do zero knowledge proofs nowadays based on MPC.

That's also possible using some technique called MPC in the head. Now about homomorphic encryption, so this is a very useful tool also that's being used extensively in MPC, right? Because again, if you think about it, MPC allows you to do this kind of secure computation on private inputs, and homomorphic encryption gives you a way to do it, right? because you are basically manipulating ciphertext. So homomorphic encryption means that you can encrypt some message and then you can manipulate it.

So a good example is if you want some database to do some database queries, so you want to put your data on a database, but you put it encrypted. And then you still want to be able to get some queries on the encrypted data. So there are also a bunch of companies that are doing this. This is a very useful tool in MPC because it's exactly the tool that we need in many cases to actually perform the MPC

to take the cipher text, so all the parties for example can encrypt using this type of homomorphic, some type of homomorphic encryption, their input shares, and then you can do the manipulation over the cipher text, and eventually you can do some kind of a decryption or distribute a decryption, and you get

a result without learning the inputs. So those are both, like I would say, very useful tools that are used by MPC protocols. So, I I guess what it sounds like you're saying is that MPC is kind of at the root of a lot of these techniques that we hear of, whether it's CKP, homomorphic encryption or threshold signatures. They're all rooted in multi-party computations.

MPCs is a technology. Now, it's a beautiful technology because it allows you, it's an enabler, right? It's an enabler for a trustless way to getting some results. And to do it, people from academia, along the, throughout the years have used all the tricks that are possible in cryptography. And zero knowledge proofs and amorophic encryption are definitely one of the most coolest tricks in the disposal of the cryptographer protocol designer. So they are used in MPC and it's, again, MPC is very, very much, it's not new.

So it exists for many years now. It's a technology that is used. There are different protocols that are doing MPC. and each one is utilizing like different types of this kind of cryptographic tricks to achieve this goal. Cool. Well, thanks so much, Omar, for giving this overview. I would say let's dive into the details here. So threshold signatures, how are they used in Zengo?

Can you just walk us through, yeah, how they're used to secure the wallet, how they're generated, and how they use to sign transactions as well? Okay, so first we need to understand that threshold signatures, or in general, a digital signature is actually referring to three protocols, three algorithms. So the first one is the key generation, which allows you to generate the key, the secret key and the public key, which later can be used to derive a public address. Then you can do, there's the second algorithm which is the signing, and finally there's the verification, which happens on chain. This is what the verifiers, the miners, the validators are doing. And in TSS, it stands for threshold signatures scheme. The verification algorithm stays the same.

Okay, so the magic here is how you can generate the signature without exposing the private key in a specific location, but still get the chain to think it's a regular signature. So in order to do it, you start with this distributed key generation. Okay, so we place the key generation, with a distributed key generation. What it means is that basically each party will generate

a secret, the secret will never leave this party device, and using some computation will be able to compute a public key. So here, if you remember for what to explain about MPC, the joint function is the public key,

and the secret information is secret shares of the secret key. So this is the first step. Afterwards, you need another protocol for threshold signature, which is what will eventually output the digital signature, a regular-looking digital signature. So it means that the function here to be computed is a digital signature, and the inputs are the secretures from the key generation that was the output of the

key generation, distributed key generation. And there are few ways that you can use this framework, because now you have multiple parties that do not necessarily need to trust each other. So you introduce an assumption into your system, which says that you are trusting that some threshold of the parties will behave honestly, that they will not get attacked or hacked. So this is a new kind of assumption that is not existing in today's blockchains. In today's blockchains, you are using only like a very classical public key cryptography assumptions. And now all of a sudden I'm introducing this threshold assumption. So assuming that, let's assume that we are fine with this assumption.

Now the question is who are those parties, right? To whom I distribute the private key? Because remember, it's not like I'm generating a private key. There is no single point in time where there's a single private key. So it's not like I'm generating it in a single point and then distributing it. I'm doing a computation where the end result is that I have this secret information, secret shares generated in a distributed manner to the parties that are doing the computation. So one option to do it is by.

just doing it over multiple devices that you own. So this is not what we are doing, but this will give you definitely this extra security because now you need, it's like a multi-factor signing. You need multiple factors to become online, depends on your threshold. The problem here is that it's very hard to actually do a signing now because you need to actually collect your devices

to be online at the same time. One of the issues with MPCs needs this interactivity, and you need this, the whole devices to be. at the same time. So it's kind of a trade-off between the security and the availability. The other option is that you can have, let's say, some servers that will act as parties, and they will run the key generation and signing for you. So a set of servers will do it for you. Now, the question is, how can you trust those servers? So it's true that we introduce this assumption that there is at least threshold, honest servers, but still, who is the one

that deployed the software to these servers? I mean, eventually if you go high enough in the chain or in the chain you'll get to this kind of admin or this guy that actually wrote the software. So it's a single point eventually. Also, those servers eventually, like in real life, can collude and sign for you on transactions and steal your key or steal your funds. So also it's not what we're doing in Zengor. So what we are doing is kind of an hybrid solution where we have only two secretures. So it's a two-party computation, which sounds simple compared to a multi-party, but it's a two-party.

It's actually not because it's assumed that both parties must behave honestly to make a signature, which is kind of a hard demand for MPC protocol. It is what's called dishonest majority because it's enough that one party is misbehaving. You need both of them to act honestly. One of the signatures will be on the user device, on the mobile device. The other one will be on our servers. So if you can imagine it, it's kind of like a start apology when you have our servers, that, by the way, can also use MPC or threshold cryptography to maintain our secrets,

our secretures. In the start, there are the devices that each one is connected only to us, not to the others, and we run a joint computation within. So this is the setting that we are using in here. We have kind of joining both worlds that we give this kind of no single point of failure assumptions throughout the system, because we started from cryptography, we actually build the entire stack or the entire system using this assumption of no single point failure. So it's leveraged security and also in terms of availability and usability, it's easier

because you communicate with our server and assuming you are passing the authentication, you are allowed to do the signing. So it's very fast. Cool. Thanks so much. That was really a great explanation. So I just wanted to basically kind of rephrase it and provide a brief summary. If we contrast this something like multi-sig, right? People will know that. And then basically, let's say Sebastian and I, we can have a multi-sig on Bitcoin. And then, you know, we both generate signature and then jointly sign his message. You know, we may have to send it between each other, broadcast it, and then on the chain it says, okay, you know, both both keys signed and it's okay. Now, what you guys here are doing is that the Bitcoin address would

look just like a normal Bitcoin address. But afterwards, we both have a private key and we can basically jointly create this, the signature for this Bitcoin address. And then we basically have sort of, you know, almost the best of both worlds. On the one hand, we, we don't have to a higher transaction fees of a multi-sig. You don't see on the chain that a multi-sick basically it's almost like a multi-sig was used. But you have a similar. kind of security. And of course, that model is sort of well known in the multi-sake paradigm, right? You have something like BitGo or there were other wallets too, right? Where there was a wallet provided that holding one key and me as a user would hold the other key and then jointly

we would sign it. And now in your example, you're doing that, but you're using threshold signatures. So there's no multi-sick being used. But maybe you can talk a little bit. So there's a How do you look at this versus multisig? Like, do you see it as one benefit that you can use it on many different chains, even when they don't have multisig? Or what are some of the other kind of pros and cons versus multisic? It's a great question. So my claim is that multisig is kind of an emulation of a threshold signature.

So a threshold signature, another way to look at it is the threshold signature is a multi-sig that happens in the cryptographic level. So even before it meets the blockchain, you don't need a multisig is kind of the application level and threshold signature is the cryptographic level. So it means that all of the benefits that you mentioned in terms of privacy of the access structure on the blockchain, in terms of the fees that you are paying,

in terms of the support for other chains that might not allow some kind of multisig in their blockchain. So this is kind of immediate benefits that you can have. We, for instance, once we add the threshold signature for Bitcoin, it took us like a day to implement it for Ethereum because it's the same elliptical and the same digital signature. So it was very fast. And if it was multisig, so as you are aware,

to actually write a multi-sig contract in Ethereum, it's hard. It requires you to do all sorts of today. formal verification for the smart contract, so there are many errors that can happen, so it takes more time. Now, looking at Bitcoin example, which is using a digital signature

that is called ECDSA, which is very popular and very old also. This is what's used today, and we are hoping that in the future will move to its support also for Schnorr type of signatures. So it was not very trivial that threshold signatures

got to the point where they are today. Like I mentioned earlier, there was an explosion in threshold ECDSA research just in the past couple of years, something like nine different protocols. And the end result is that you have kind of like a mix of protocols that you can choose one depending on your use case. And for example, one interesting result that this academic research has led to is in the sense of the security. Because like I mentioned, Multisig is using the crypto-Britory. of the blockchain, which is a classical public cryptography. So the assumptions of the security assumptions are very solid. Trashold signatures on the other end, or threshold ECDSA specifically,

was usually assumed some additional assumptions on the security. So you had to compromise in some sense. But nowadays there are protocols, which are both very fast, and second, they are secure in the same security that the blockchain is assuming. So you don't need to assume anything more on the security like the existence of some encryption scheme, some kind of hardness assumption. You can just use the same assumptions. I think there's still room to improvement. And I think that the most immediate one is in term of interactiveness.

So multisig is non-interactive protocol, right? So it means that you can sign and then pass it along and someone else will sign and then it will pass the transaction along. until you get enough signatures. In an MPC-based signature or treasured signature, I mean, I'm speaking in general because there are some cases where you don't need this interactivity, but in general, you do need an MPC interactivity. So you need all the parties to be online at the same time.

And this is something that I think can be avoidable in the specific signature schemes that are used in blockchain, and we have one work on how to do it, but I know that there are others that are also doing it. And again, it's a general statement for specific signature schemes and for specific assumptions, you can already use kind of a non-interactive threshold signature or threshold DCDSA for Bitcoin. Big silence. Yeah.

Yeah, yeah. I mean, I wanted to bring up the pitfalls where a TSS falls short with regards to multisig. Just to repeat what Homer has said, there is three benefits to threshold signature compared to multisig. The first one is blockchain agnostic. So we can support any type of assets, right? We're not constrained to the fact that the multi-seek capability is baked in the protocol, built in the protocol. And we see the limitation of that, for example, in Ethereum with the multiple bugs that have happened. And for us, it takes us really very little time to add another blockchain.

That's why we could support very quickly, for example, Binance Chain or Libra and others will add very soon. The second one is privacy. which because we don't expose the scheme of signatures between the parties, although today we just, you know, a client and a server, but you can imagine in the future we're going to be more. The privacy scheme is not exposed. And so, you know, the signature scheme is not exposed. And so you're not exposing something that is very sensitive,

which means which wallets are involved or which parties are involved in the process of signing. And associated to that is the cost of a signature. Because in a multi-sig every time a party sign, there is a public signature meaning, mining fees associated to it. So eventually you end up with something that is at the same time, private, more private, and much cheaper and also agnostic to any assets. So I would say those are the three main properties associated to the fact using TSS over multi-s. Let's talk about security. You know, DAPs are pretty unique because unlike other types of software,

they can hold astronomical amounts of value. That's why getting systems audited, creating robust security, processes and fostering a culture of security in your organization is so important. And to do this, you should only trust experts with real security expertise. There are a lot of security firms in the blockchain space, but few have the experience and track record of Trail of Bits. And they've been in business since 2012, long before things like the Dow hack were even imaginable. Trail of Bits works with your team to audit every aspect of your project. And smart contract code is just the beginning. They'll help you implement best practices around things like DevOps, key storage, and user-facing applications.

And once your software has been rigorously tested and reviewed by Trail of Bits, they'll provide the tools you need to make sure that your code remains safe over every new commit. They can even put a software security expert at your team's disposal who'll give you advice and answer your questions when you need them. It's like having your own security engineer on staff, but don't take my word for it. Go to their publications repo on GitHub to read their papers, presentations, and security reviews. It's no wonder teams like parody, status, Newseifer, and organizations like Facebook and DARPA trust TrillowBits for their security audits. To learn more, go to TrailfBits.com, and if you decide to reach out, make sure you let them know you heard about them on Epicenter.

We'd like to thank TrilofBits for their support. I'd like to touch on some of the criticisms of TSS that we've heard in the space. So there is, especially in the Bitcoin space, people tend to be a little bit more favorable to this other type of signature scheme called Schnor signatures, which apparently have some advantages with regards to like the size of the signature and the efficiency. And then also the security. Some claim that schnors are more secure because they've been verified, whereas TSS on ECDSA has not been. sort of formally verified. Can you walk us through, like, what are these criticisms and, you know, why do you think we should trust threshold signatures today? Yeah, so let me try to unpack this question. And first, let me say that, like, implementing TSS is extremely hard. Okay, it's, as we mentioned before, it's an advanced form of cryptography. It uses zero knowledge proofs.

It uses amorphic encryption. It's using distributed computing. And in general, those protocols can tend to be like a multi-round and highly and require sometimes a lot of computation. And eventually, this is one aspect that needs to be considered. And for example, what we are doing, so we have open-sourced all of our cryptography. And I think this is probably the best decision we've made so far.

we get tons of contributions and like battle testing of our libraries and improvements. So it's fantastic. And I think that this is what makes us unique because there aren't a lot of TSS implementations out there. Now, TSS, I mean, what you said about Schnoor compared to TSS, we can divide it into several elements. So let's first compare TSS with ECDSA, which is what's currently used in Bitcoin. and Ethereum and some other leading blockchains to TSS based on Schnoor. So because Schnoor is a linear type of digital signature, it is much more MPC-friendly than ECDSA.

This is why we saw those many papers around ECDSA or threshold ECDSA in the last years. And Schnoor, it's not trivial, but it's easier to do it. It's like easier to the concepts that are the building blocks of thresholds, shno or thought of like many years ago and it's easier to implement. So there are less risk of introducing some kind of vulnerabilities when you are doing this type of threshold shno. We have, by the way, both threshold schnoe signatures and threshold DCDSA libraries so we can definitely compare them. We had like an entire walk in breaking Bitcoin about vulnerabilities in threshold DCDSA because this is very, as I said, very hard to actually do. Now,

Having said that, let's assume that you have the cryptographer on board and that you are willing to take this risk. There are other aspects that might be like a deal breaker, but I want to correct them. So one of them is about the security of Schnor versus ECDSA. So Schnoor is a provable security. So there's a paper that gives like the entire security proof of Schnoor under a very solid cryptographic assumptions. To assume the discrete log hardness and random oracle model. It's not true for ECDSA. So UCDSA kind of was invented the opposite way.

So first, because Schnoe was patented, there was kind of this invention, that ECDSA should just work like this, and there was the protocol. And afterwards, people started to came up with proofs. The level of the security proof and the assumptions needed just got better and better. And I assume that the analysis would keep getting better in ECDSA. So like to say that ECDSA is less secure than Schno, I would argue that it's not very much accurate. like ECDSA has some very solid security proofs by now.

And also there's kind of the crypto analysis aspect, right? Like Bitcoin is a huge bug bounty for finding bugs in ECDSA, other blockchains as well. And also there was like formal efforts to break ECDSA, which over the years did not succeed. There's another issue with ECDSA, which is about melability. What it means is that if you can take a signature and then change the signature such that it will still have a meaning it will be valid maybe on a different message. But without going into the process of resigning it, okay? Now, Schno was proven to be non-melabel, which is the property is like strong unforgeability.

So you cannot do this with Schno. This is a stay, it was assumed to be melabel, and one of the security proofs that I mentioned showed that it's kind of, there's one melability, which is known, which is the signature, and the opposite of part of the signature will still be a valid signature. And this is arguably problem, but because this is the only mailability here, this can be covered. So what you see in the recent papers is that you just need to define one of the two ECDSA signature results to be the one, the correct one. And this is also what was suggested in Bitcoin. It was one of the beeps.

And it's also effectively Segwit, like if you use Segwit, you kind of eliminate the problem altogether. Looking at schnoor, on the other end, even though it was proven to be non-melabel, in fact, because it's not standardized like ECDSA, there are many standards for schno. So anyone can just say that take some variant and this is a schnoor signature. And eventually what can happen is that, for example, we have a blockchain called Zilika that have one variant of Schnoch, and Bitcoin, Bip Schnor is another variant. And what might happen is that one signature in one blockchain would have a meaning in another blockchain, which is kind of like the point of mailability.

So I'm not sure if it's a strong claim to SNO. So to conclude, I would say that like ECDSA is valid, is secure to some good extent. Taking ECDSA and doing TSS on ECDSA is definitely harder than doing TSS over linear schno. Okay. Thanks so much, Omar. Well, let's talk a little bit more about just a Sengo Wallet user experience. So Uriel, can you walk us through?

What's the process of, yeah, setting up a wallet and using the Sango wallet? So first it's going to be how to sound as smart as Homer after all those great explanations. So I try to make a point here. Let's just first like remind. I mean, I'm sure your audience already knows that. But typically when you onboard a new wallet and I will not talk about exchanges which are like centralized service. and you just create a login and a password and, you know, KYC usually, but typical non-custodial wallet.

The experience will be the following. You will open it. You will be presented a set of 12 or 24 words. You will have to somehow write it down, think about a mobile first experience where you don't have the possibility to take side notes or something. So you probably will do a screenshot of that, which is a very bad idea. Although the apps will tell you not to do it. And then you will have to repeat.

some of those words to validate you have them, and then at some point you'll get into a fully the wallet. Some wallet will allow you to skip that phase and at some point, for example, when you buy a new phone, you realize you have not backed up and because you have not your seed or your seed phrase with you, your money that you thought was here is gone and is gone forever. So that's typically the experience that you would have on normal wallets, right? So here is how it works with Zango. With Zango, you do not have to memorize any secret. The only thing that you need to know is your email address, the access to your email address.

So you open Zango, we'll ask you your email address, you put your email address, you receive a magic link, which is a bit like Slack is doing, which is like a way to pass a password without actually revealing a password. You click on this email to validate your email. You get to the second step which is validating the existence of your device by allowing the permission to your device biometrics, whether this is touch ID or face ID. And then you get to the wallet. At this stage, the wallet is set with zero funds. The wallet is at this stage not yet backed up.

So we have made the decision to not force a backup at your onboarding until the owner wants to deposit funds. So when you press, receive, to deposit your first funds, you will be forced to do a backup. But unlike traditional wallets, which ask for you to store 12 or 24 words, it works with advanced biometrics, which is not the biomics of your device, but a server-side operating biometrics, which we can do thanks to the TSS architecture that we have. So here it's very simple for the user. All he has to do is to do a kind of live video which is encrypted on it. phone of his face, right? So it's like a face map that is encrypted on his phone. And then

the encryption is sent to the server and start there in a secured way. Obviously, we cannot trade it. We cannot see it because it's stored. And that's it. Your wallet is backed up, meaning that you have in three steps, no password required, set up your Zengal wallet. I did that before, and it is a very nice user experience. Now, of course, the thing is, So we have this chair or basically this key on the, on the my phone, right? And then there's another one on the send go server. And we just talked about before how that works. And now you talked about the backup with this biometrics.

And I think the idea of the backup is, right? So I have my iPhone. I lose my iPhone. At a later point, I want to basically recover my share so that I can keep accessing my funds. and then I use again this biometric camera. Can you talk to them curious on this point? How does that recovery work? So I've lost my phone, I have my new phone.

I download the ZenGo up again. And then I use this face camera. How does it recover and regenerate the share that I originally generated in my, you know, in my previous phone? So excellent question. So the most important thing is that it works. And the second thing is now to understand how it works. So indeed, let's say you broke your phone, you lost your phone or whatever.

You just bought a new brand new shiny iPhone 11, right? Which I'm sure you guys have done already, if not maybe probably very soon. I'm in seven. Seven. Oh, my God. All right. So you still like using the Minitel here. Anyway, you got your new phone with you and you download Zango.

And you go through the same exact steps I described before. So you will put the same email that you are, you have used to create your account. You validate it with the magic link. You give permission to the device biometrics. And you will scan again your face. Now, what it does is remember when you first scan your face and it works with any selfie camera. So your phone does not have to have a special capability. Just have any cell phone, a selfie camera.

what it does is that it again scan your face and encrypts it on your phone and then he's going to compare it with the encrypted version that we have stored for you and remember it's encrypted so we cannot see it no one can see it if someone has that file is completely useless and matches it so as it matches it it it restore the share of the of the phone that has been encrypted also and stored with us and it's being restored on the device. and then you get access back to your funds. So I know there's been a lot of ping pong here between a lot of encryption and mechanisms and security, but the simple message is that the face unlocks one of the factors that has been served to encrypt your private share on your device, stored encrypted on Zerngo servers, and sent back to your phone as you have restored.

And so all of that is obviously invisible to the Zango user and restore this fund that, of course, let's remind very important, it's a non-custodial wallet. So all funds are on chain. Just a quick question on that. So I think this kind of puzzles me. So if I'm using my phone with this face thing and, you know, it basically generates, you know, some, it uses the data from my face when I move it around, it generates, you know, some key. So this is deterministic. I'm going to do it again with a phone and it's going to generate the same thing or is there some sort of like similarity and then it roughly matches? So basically it's not deterministic. It's using a learning machine learning model. So what it does is

basically it encodes your face at time of registration. And also it gives you this kind of when you try to authenticate it gives you also a liveliness test to see that it's not a picture that it's really like a 3D human being. And by the way, interesting fact is that you can also use MCC. This is another use case for MPC because you can, I mean, some people don't want the face or encoding of their face will be sent to some remote server, which is understandable. So you can do it over encrypted data.

So you encrypt your face and you do the machine learning over the encryption of your face. That way this remote server will do the entire process of authentication, over the encrypted data, like the entire machine learning, like getting those elements from your face and comparing it to some kind of previous encoding and all of this, and we'll send you the results without knowing that you are really who you are, like keeping a copy of your face. So just to complete on that, because, you know,

there is a lot of market narrative right now around the capacity to break face ID technologies and deepfakes and all these things. So I want to make a few things clear. First, what's these technologies doing is measuring the liveliness of your face, the fact that your face is alive and real. So if you are trying to spoof it with like a picture, even of good quality or a video. Or a mask, as you've showed me at your office.

Exactly. Oriel has a 3D printed mask of his face. It's like super weird. But yeah, it doesn't work with that apparently. It doesn't work exactly why? Because the technology is actually measuring the fact that your face is alive. So anything that is not that, that is not you, will not pass the test and we'll break there. And think about it, it's the first time in the history, definitely in the history of crypto, maybe in the history of fintech, that you can prove and guarantee that the funds will be only accessible by the owner. Right? Because with any other solution, anyone who has the problem.

password is the owner and can spend the money. So here you have a solution that for the first time guarantees that only you can spend your own money, which is like great to know, right, no matter what device you have or no matter what secret you're supposed to know. So the liveliness factor is very important to remember. And of course, there's a lot of encryption that is on back and forth to guarantee the privacy and the security of the system so that, you know, the user can confidently use this solution. Okay, so I wanted to address a few things here. So this face scanning technique, you're leveraging a third-party solution.

I believe it's called Zoom, if I'm not mistaken. And so it's not like the face ID that is used by Apple device or whatever. It's a separate solution. So there are a couple of things that I think are meant to be addressed here. So one, this is a proprietary solution. that I guess you guys are probably paying for, or anyway, there's some sort of a business relationship there. And so if this solution goes away and all the proprietary intellectual property techniques or whatever that exist there, if they also go away, what happens to that

encrypted key that is encrypting that share? So that's question number one. And my other question is, what are the assurances that users have that, you know, because you have the user's email address that you're not also sharing or somehow storing the key that's generated on the device that's meant to secure the secret share. Can you address both those issues? Yeah. So one principle in the entire Zengu system is that there's no single point of failure. So what it means in relation to your question is that if there is a single point of failure, then we cannot guarantee anything if there's another point of failure, right? There are two points of failure. But if there's a single point, like for example, this third-party service biometrics, something happens to them.

So this is still one factor. So we are still left with the main method of extracting the keys from the wallet. And we assume that this is still a valid way to do it. So it's very simple in this way. In that way, you can just either sign transaction or recover it using another factor. Second question was about how can you protect the user that we cannot steal the funds by pretending to be them. So if we analyze this specific scenario of recovery, we see that there are no, at no point in time, there is like a single point that holds the entire solution.

Okay, so the user is iCloud, which is something that we cannot access. So we assume that today, it's iCloud. tomorrow it's another kind of storage that the user owns, but Zengbo is no access to. And this solves one part of the unlocking mechanism, like a key or something like this. What we have is only a way to authenticate the user based on the biometric information that we are using this mechanism. So in our side, we have an encrypted secret chair that we cannot do anything with without access to this iCloud or storage of the user. And also the biometric third-party company that provides us this solution

has only, let's say, access in the worst case to the actual face, but they cannot use it. They also don't have access to the iCloud and also to the secret share that is encrypted on our servers. So no one in this scenario is like access to the iClaught. entire secret key, except for the user that needs to combine his iCloud, the file from the cloud, meaning the access for the iCloud, the email that he owns, and his face. So only combining those. Now, the server has no way to, even if we had access to the face, we still

don't have access to the iCloud. Okay. So the secret share, which is residing on the device, gets backed up encrypted by this key that's generated by the facial recognition software, it gets backed up to one's iCloud account or any cloud service, perhaps in the future.

But my question was more around what are the assurances? Because this is, I mean, it's essentially a closed source software. You know, one could say that that's the case for any other mobile wallet or crypto wallet because, you know, it's the,

the app store and we don't have access to the source code, are there, if any, any assurances that that secret share isn't being sent over the wire to Zengo or that the encryption key isn't also being sent over the wire? Are there any assurances at all there? Or do we have to trust Zengo that your software is not doing this? Okay, so first of all, one correction. We are not using the face to generate a key. I would argue that this is very dangerous. we're using the strong randomness of the device to generate this key that encrypts the secretures that is later sent to the server and the key is kept on the device connected iCloud. Okay, so this is one correction.

Now, you are touching a very good point, right? I mean, eventually there comes, it's all about trust. And the question is, what can you trust and what you cannot trust? I mean, eventually your device is designed and you are using software for many vendors and the hardware manufacturers and you need to put some trust in them. And I think that here it's also, you know, there's a project about how to

minimize the trust base in the Bitcoin full node. And eventually you need to think about it like who is writing the full node code. So there's a compiler that needs to run in order to actually compile it. Now who is writing the compiler? So there's another compiler and who is writing this compiler?

Eventually this project aims, I don't remember his name, but aims to get to the minimal trust base that you need. And here, I think we've done something similar, right? We try to minimize the trust base. So eventually, right, there are some close-source elements that I hope that will be open. We hope that it will be open soon. We are doing our efforts to open as much as possible from the system.

And even if it was completely open-source, it's still hard to make sure that eventually what's open-sourced and you see it on GitHub is actually used in your application, right? And it's true for any application. Yeah, it's actually impossible to do so with it. with an app in the app store or even Google. I agree with you that, I mean, to my knowledge, it's impossible to do it. It's a great computer science question. So what we are trying to do, and this is what we're all about,

is trying to minimize the trust base that the user has to trust. So again, this is a specific scenario of recovery, and there's like a huge tree of scenarios for recovery or other stuff that you can do with that. And in this specific case, you are looking for a specific attack surface, and we try to do the best to minimize the trust, basically. So what I was saying is that the, remember, open source is never a guarantee of security. There is a long track record of open source solutions that have been compromised, including in the wallet space.

So what we've tried to do is, as Homer said, to be in a more strict, minimized environment. We have open source entirely our cryptography, which has been peer reviewed. We've run multiple security audits, penetration tests. They have been made public on our. website. We have created, maybe we'll talk about it, about a guaranteed access, a solution that even if we get out of business and stop operating, the funds will remain accessible. And over time, as we progress, things will be more transparent, more open, more distributed, more decentralized, if we can say. We had to start somewhere. We're bringing a new flavor,

and this new flavor will blossom fully over time. Okay. We're not going to have time to go into this procedure that you've outlined in case Zengo goes out of business. But I will link to that in the show notes. If anybody's interested there, Zengo has a whole process around like what happens if the company ever goes out of business. How can one recover their funds? So I wanted to ask you about the broader evolution of the wallet space. So right now, I mean, wallets are pretty much compatible. So for example, you generate a seed on a ledger. You can take that. and move it into Electrum and still be able to recover your Bitcoins. I think you could probably even put it in like a multi-currency wallet,

like Jacks, for example, and have access to the whole tree of HD keys there, giving you access to funds in different currencies. So there's interoperability there. With something like Zengo, now that we're relying on multi-party computations and where there isn't a standard at the, moment. Do you foresee that different wallets will effectively be different closed ecosystems and users will not have that interoperability? Or do you see some form of standardization emerging in the space? So our bet is that convenience is going to trump principles and that people will

value more anything that makes them their life easier, as long. as a set of core principles are respected. And not everyone is a security expert or not everyone has to know that everything is perfectly decentralized. As you know, there are many, many projects that are going to onboard very soon. A lot of people to the crypto space, whether this is Telegram, whether this is Kakao in Asia, whether this is possibly maybe even Facebook one day, who knows? And these type of users don't even ask those questions.

They will need something that just works and that feels crisp and that can be used on a daily basis. It is true and you are correct to point to the fact that the users will need to understand that they are in control, then they have the proper guarantees and that the security is in a way safe and of quality. So it is our job to build that over time to provide the right foundation of trust, the right services around it, the right protection mechanism. I cannot reveal secret plans already, but I can tell you for a fact that a few months from now, people will look at Zango

and we'll understand why they have an interest to store their funds with us versus like a traditional wallet as they exist today. And so I think it's still very, very early days. What we do see from our first users that are trusting us to deposit their funds and sometimes in very high volumes is that for them, the convenience

is the primary factor that they have chosen over the rest. And this is why, by the way, the majority of the funds are still stored in exchanges. It's not because they are by design more secure. They are by design the opposite. They are everything but secure. They are traditional point of failures. And we've seen that with the hacks that have happened recently.

It's just that they are so convenient. They are just easier to use. And so as long as the space is still in this current status, where non-custodial are less convenient to use than their counterparties, people will prefer custodian solutions. And what we're trying to bring here is something that is kind of, like I said, in introduction, best of both worlds where you are still in control, your funds are on chain, you have guarantees that your funds will be accessible if we stop operating.

You are not constrained to a specific asset because a smart contract works for this and doesn't work for that. You are not constrained to multi-sig here because it's not bad. baked in other chains. It's just more convenient and you still are in control, but you still enjoy the services of a server that is always on and can assist you, of course, for onboarding you, for helping you recover, do all sorts of wonderful things that a server can done in the wallet space. So our take on that is that the market is evolving, the needs are evolving, and that we are in a phase where convenience is going to become a lot more important than

pure core principles of decentralization and security. Now, they are not important, but the weight is being revaluated. Totally. Just before we wrap up, I wanted to talk about, and you've touched on this point, when it comes to the evolution of the wallet space, right? So today already we are seeing, you know, different worlds have different kind of specializations in focus. So there are a bunch that maybe is something like Instadap or Xerion or some,

Ethereum wallets very much, you know, fully focused on Ethereum and maybe focused on different defy applications there. There will be some others that are focused on Bitcoin, some others that are focused on, like, supporting lots of cryptocurrencies, maybe others focused on staking. How do you see that space evolving and where do you think Zengo will fit in this, you know, larger universe of different wallet providers? So the space is definitely very crowded and definitely very noisy. We do believe in the future there will be many, many, many, many flavors of wallets,

the same way we have today in our Fiat First World, many, many flavors of banks and financial services. So it's not going to be a winner-winner take it all, not even winners take it all. It's going to be just very, very atomized. Need to make a difference, though, between, like what you mentioned, there are companies that are just interfaces and some that are actually. wallets, meaning managing the private key. So some of them are not handling that at all. They are just like pretty cosmetic services.

And private key management is handled by others. We are in both spaces. We overlap both. And again, convenience is what matters. So we handle both parts. We do believe that in the future, you will have solutions for every taste. You will have people who will value absolute privacy and control.

And they will be comfortable with a solution where they handle alone their own security, as it was the case until today. And you will have people will value certain specific chains more than others for doing whatever collectibles or defy, and they will be fine with that thing. And they will have people who will value convenience and there will be a variety of solutions there.

What we do not see happening is having consumers or investors download 30 wallets and 40 solutions on their mobile phone around them. It's just unimaginable. And the way we think about Zango is as the remote control of your digital assets. So it's true we're operating in the cryptocurrency space. We operate with Bitcoin, Ethereum, Binus, Libra to more or more. But we are essentially designed for helping consumers and investors managing all their digital assets, no matter what they are, whether they are cryptocurrencies, digital identities, title of properties, collectibles, and all those things. And so we believe in the existence of remote controls, and we believe in the simplification of the space.

I don't know if we will certainly not be the only one to do that, but this is how we see the space going. Also, I don't think there will be room for many wallace that don't have a business model. And this is actually, sadly, the case today. Most of them depend on third-party revenues. They don't control. So we think there will be an evolution also in that area. Yeah, so I think that brings us to our last question, which is, is around the business models.

We haven't talked about that so far at all. Yeah, how do you see that evolving? What are different, you know, possible business models that you will pursue for Zengo? So I won't really reveal all the secrets

that we are preparing because our route is pretty unconventional. But I will give you just some hints about where we're going. First, like today, most wallets are depending on third-party integrations, which means that most wallets do not control their revenues. They kind of deriving the revenues from affiliate fees, whether this is by

generating traffic to exchanges, to outward wallet sales, or to plugging services like to buy crypto with credit card or loans and stuff like that. The reality is that most of those revenues are not enough to sustain a company and a wallet and it's not said enough is an extremely expensive operation to handle. It's not a lightweight software. There is a lot of things behind the development, the security, the auditing, the maintenance. of the platform, the support. So you need something better for that. And so what we want is to launch probably early next year a set of services that will be

specific to the way we operate and that will augment the experience of the wallet. And hopefully those services will provide sustainable revenues, revenues that we control, that we are able to operate and to perform at scale. And I cannot reveal all the details of what they will be right now. So let's do another podcast if you want Q1 next year. Maybe we will have an opportunity to discuss that more. But I can tell you that they will not be dependent on the integration of third-party services. Okay, cool.

Well, I'm curious to see what's going to come there. And, yeah, certainly, I think business models for wallet is a very interesting space, and we'll see lots of evolution in that. So, yeah, thanks so much for joining us. It was a pleasure. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts.

And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.