Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Leonard Tan & Yong Zhen Yu: The Decentralized Key Management and Login System for Web3

Episode Date: December 18, 2020

Torus is an open-source and universal key management system for the Web3 ecosystem. It's simple, secure and non-custodial, and suitable for anyone to manage their keys. Torus runs a Distributed Key Generation protocol built on Shamir's Secret Sharing.Supporting over a hundred thousand authentications a month on popular applications like AAVE, KyberSwap, Augur, GoodDollar, and MyCryptoHeroes, Torus empowers decentralised applications with seamless user onboarding flows while maintaining recoverability and high standards of security for key management.The Torus Wallet is the second layer to the system and allows one-click login and authentication on partners including Gmail, Facebook, or passwordless logins on Web3 applications. It is however reinforced behind the scenes by a clever distributed architecture. Notably, clever cryptography makes it possible for users to send crypto to social accounts that don't yet have crypto wallet. For example, one could send crypto to a Twitter username, which could be claimed once the recipient creates an account.The team also recently released a custom version of two-factor authentication (2FA), tKey.We were joined by Founders of Torus, Yong Zhen Yu and Leonard Tan, who gave us fascinating insight into why and how Torus was built, the recent products released, and what their aims are for the future.Topics covered in this episode:Zhen and Leonard's backgrounds and how they got into cryptoHow and why Torus was formedThe path Torus has followed over the past yearUnwrapping the base layer, the Torus NetworkHow Shamir's Secret Sharing works and why Torus chose to build on itThe Torus Wallet and a step by step of how it worksTorus and account portabilityUse cases and applications built on TorusThe second layer of security, tKeyTheir plans for introducing Touch IDHow Torus educate their users on how to stay secureThe long term goal for Torus and how users are protected in the futureEpisode links:Torus websiteTorus StatusA beginner’s guide to Shamir’s Secret SharingDeveloper documentationTorus on TelegramTorus Charity Twitter CampaignWhat Distributed Key Generation IsKey Assignments, Resolution and RetrievalHow to Share a Secret in ProductiontKey - An open standard for threshold key management - HackMDTorus on TwitterZhen on TwitterLeonard on TwitterThis episode is hosted by Sebastien Couture. Show notes and listening options: epicenter.tv/B003

Hi and welcome to Epicenter Aftershock. These Aftershock podcasts are wholly sponsored, which means that everyone you hear on this edition of the show paid to be here. But that's okay because we have some amazing sponsors. If you're looking for the regular edition of Epicenter, just look for the numbered episodes in your podcast player. Today are my guests are Zen Huang and Leonard Tan of Taurus. Taurus is a flexible, decentralized key management system designed to be accessible to everyone. At the core of the Taurus stack is the Taurus network. And its function is to generate cryptographic key shares using Shamir Secret Sharing.

People can use the Web 2 services they know, like email and social media accounts, to log in to Web 3 services and defy apps. This promotes a user-centric key management environment without sacrificing usability. Taurus provides web and mobile native support, and unlike other solutions which try to solve the Ux complexities of key management, while it's blockchain agnostic. In fact, it's compatible with non-blockchain applications as well. What's great about Taurus is that it's easily accessible for developers, and integrating Taurus into your Web3 app takes just a few minutes.

From the application's perspective, Taurus is just another Web3 provider, and adding it to your app means that you simply have to import the library and pass it as a parameter to the Web3 object. Have a look at docs. for the Quickstart guide. Once it's integrated, your users will be able to create a crypto wallet by logging into Google, Facebook, Twitter, or about a dozen other services they support. There are a few things I really appreciated about this company and what they've built.

First, well, they've built a company that combines a SaaS business model and blockchain infrastructure, which I think is really cool. They're focused on providing a core key management infrastructure layer, which, combined with other solutions, can create a highly secure yet, easily usable system for key recovery. And finally, this infrastructure is useful not only for Web3 apps, but any use case which might leverage public-private key infrastructure. This extends to things like encrypted data storage, encrypted email, and so on.

And any progress in terms of facilitating access to these types of applications, I think is positive. We're seeing more and more applications which leverage cryptography as a means to protect people's data and privacy. And I can see a future where these apps, could simply allow users to bring their own keys, much like we've seen in the crypto space. And having access to a public good like the Taurus network makes it a lot easier for folks to have a higher level of sovereignty over their keys. So with that, here's my conversation with Zen Huang and Leonard Tan. I'm here with Zen Wang and Leonard Tan of the Taurus team.

And today we're going to be talking about Taurus and the products that they've built to help people manage their keys. So Taurus is a universal decentralized key management system. It's designed to be accessible to everyone. It uses really advanced threshold cryptography and it's being used by hundreds of applications and hundreds of thousands of users per month. And they're helping make it easier for people to manage their keys in crypto. And we know that this is, well, a big problem. It's always been. So the crux of the crypto problem is like, how do you manage your keys? And we've come a long way from having air gap laptops, you know, seven or eight years ago to now having really user-friendly and mature solutions for people to manage your crypto keys. So Zen and Leonard,

thanks for joining today. No, thanks so much for the introduction. Thanks for having us. It's actually a pleasure to be on this show. We've been big fans of it for a while. Exactly. I've followed every time of podcast in all power. Yeah, so it's great to finally kind of talk. Yeah, and it's, it's, we, we're just excited for this to happen. Yeah. Cool. So tell me a little bit about your background and how you guys became involved in crypto.

So that was for me, actually, the first, my first involvement of crypto was with doge coin. I'm not sure if you remember. The Reddit community. They had an amazing trailer. I think it was like Dogecoin to the moon, where Doge would be fly. I mean, if you guys haven't watched it, you guys should definitely watch it. It's a piece of art. It's a classic.

It was my first foray into cryptocurrencies. Back then, Bitcoin was interesting to me, and I mined a little bit. But it wasn't until a theorem came about when I really, really got hooked. I actually managed to chance upon Vitaleck whilst I was working at a V-Chi-Chi. see way back then. And he just gave a talk and he did it in, you know, everybody else was in a fintech convention. And they were in like suits and all, but he was in a unicorn shirt.

But he was so eloquent and he has his own charisma all around him. And from then on, it was just kind of like a rabbit hole and downhill from there. Just full quick all the way. So, yeah. So I used to work on previous plasma research and all. and Leonard used to... That's kind of why I met Zen also. Like, we were schoolmates, but we only really got to meet each other

when Zen was working at on its platform, Peace Bridge, right? Yes, yes. So for me, I started a lot later, actually, like early 2017. And then I was working on a side project with my friends. And we only just found out Ethereum. Back in the day, there was no infura.

So in order to do any querying at all, you had to run your own Ethereum node, which cost you $500 a month. So we got that spun up. We wrote this quick project to prevent ticket rescalping and all that, ran in a bunch of problems. And at that point, I was pretty much hooked. I mean, it's like once you get into the ecosystem, there's a lot to explore, and there's a lot of things that I wanted to learn.

And also, I majored in finance and economics, and I'm a, I was just, it was just like a good crossroad, right? Because finance, economics, and software engineering, that's pretty much what crypto is all about. So I did that, and then I went out to do a corporate job at Visa. And then meanwhile, I was still exploring this thing. And when the opportunity came, I decided to go for it and start doing more blockchain work. And this was also part of consensus.

And then after that, I did Torres together with Zen while we were doing some research. So Torres really started off as a sideboard. projects with us. Yeah, exactly, yeah. We were trying to explore ring signatures. Yes. So the name comes, you know, Torres is a donut chip. It comes from a ring. So we were trying to explain, so we're trying to do a private information marketplace. So back in the day when we were exploring this technology, we realized the potential for it to be able to, for information reselling. And what are the problems with information is that it suffers, from the problems of a public good in the sense that once you sell it once, you can't resell it.

And that can be solved with things like designated verifier signatures. Via ring signatures. But we quickly really realized that, you know, ring signatures basically require for everybody to have public keys. And nobody had PGP keys. Nobody had any keys at all. There was no way to identify users at all, even if you wanted to tie a dynamic. So we just went back and back and tried to solve each problem.

And we kind of chanced upon like the tourist infrastructure and architecture. that point in time. And we really felt that it would be a great way to kind of make public key infrastructure accessible to everybody and usable by everybody. And that just became our mission and vision. And what we tried to solve in the ecosystem as well as time moved on. So the rest of history. And we got funding from finance and then we just kind of just pretty much just came up for us trying to solve the developer tooling problem that didn't Thanks this back then. Time really flies. It's been two years.

Yeah, it certainly does. In fact, I was just, we were talking earlier that Zen, we met at ETC last year. Tell us what have you been able to accomplish in the last year since, well, I guess almost a year, like nine months or so. What has come about in the Taurus product line since then? At the start of the year, we launched a new product called, or a way of integrating Taurus called Direct. So for those viewers who don't know us out there, go check out app.org. It's really a lot easier for you guys to check it out and feel the experience for yourselves. And what you get from a application that integrates either the Torres Wallet or Torres Key Management in general, any one of the SDKs,

is you get a Web 2 experience via Google, Facebook, Reddit or even passwordless logins on a WebTree application. And this is, and we launched earlier in the year a different way to integrate the Taurus key management. We basically, we made it directly embedded into applications. We also launched in this year a key match from architecture called Tiki, which is another abstraction over the Taurus network. And I'll go a little bit more into those abstractions and how keys manage a little bit further down. the line. But it's, we've just basically been busy listening to developer requests. They ask us,

oh, would this be possible? And then we go, oh, yeah, yeah, yeah. And then we go it for them. We put it for them and then see how much traction it gets. So it's been, it's been, so direct off has been great. We've really managed to come a long way with both the direct off and Torres Wall integrations as well as Tiki. To date, we are directly integrated into over 250 applications. We're seeing over 100K monthly active users with hundreds of thousands of authentications. We're really happy with where we've come today. We're really excited for what's

coming in the future as well. So Taurus is a bunch of different things. So there's the Taurus network, which we'll talk about. There's the Taurus wallet. There is this direct off product and there's Tiki. So let's talk about the Taurus network there. What is the Taurus network and Or that maybe it means that kind of good. So the base is exactly if you said. The base layer is the Taurus network. Everything else are like wrappers around it. Like the Taurus wallet is a wrapper around the Taurus network so that you have a user interface to actually use the Ethereum blockchain. And that comes with a bunch of things like showing what tokens you have, what Kitties or what YRC 7-2 wants you have. So that says one other products. Direct Off is an SDK that allows you to integrate it. And then T-K is yet another abstraction layer on top of T-Tor. network, which we'll cover later. So starting with the base layer, it is basically this thing called a DKG. So it's distributed key generation. And for those that are unfamiliar, the idea is basically a group of servers and or nodes come together. They all generate a key jointly. They participate in this DKG process and they generate a key. At no point is the key ever

reconstructed. And at the end of this process, you get shares, of these keys on each one of these nodes. And you need a threshold number of them, so a majority of these servers, to build a reconstruct the key. And we run this process, this DKG on the Taurus network, in parallel to a separate layer, which does the mapping. So this DKG layer does this key generation. And then this mapping layer allows users to tie their social accounts or any type of login, really, that has a unique ID to one of these keys. So it's generic. We support basically any JWT login.

We also support in specific the OOF2 standard. And this is a standard that if people aren't familiar with, it's what like Google, Facebook, we chat, all of your different login solutions that allow other people to log in. It's a specification by WebTree. OOF2, yeah. It's a specification that is widely used in the Web 2 space.

Yeah, so this is the login with your Google account or login with your Facebook account that every website uses these days. Exactly. So the combination of this allows basically for a network to store, assign, generate, and allow people to retrieve these public-private key pairs via these modes of authentication. So this is the base layer doing its day-to-day operations. But there are other things that you need to solve before this is actually usable and secure. So you need to solve issues around replay attacks.

How do you prevent somebody from taking your Google token and replaying it to get your key? You need to solve things like migration. So let's say one of the servers decides to call it quits. I don't want to run a note anymore. So you want to migrate to a different set of servers. How do that do that without losing people's keys? How do you do that so you don't even reuse the same shares? So there's a protocol for that called Share Refresh, and we've also implemented that.

You also have to think about issues like asynchronousity, like how do you make sure that a single server isn't able to delay a login for very long? So these are all problems that the Torres Network solves, and interested readers can just go find out more. It's based off Cashin's paper from 2002. So the Torres Network is really the base layer that powers all of these user applications on top. The way I like to think of the Taurus network is it's a distributed system that does key share generation. Like that's kind of its only function. It's just generate keys and store those keys for later retrieval. And if you think of that level, if you kind of abstract away the applications,

it's kind of a nice public utility to have because you can use this for all kinds of applications beyond crypto. I mean, like, if we think about wanting people to, or encouraging people to encrypt their data on cloud storage or to encrypt their email, like, this is a really good public utility to have at the disposal of all kinds of applications that could potentially benefit from have this kind of like key generation system. Is this something that you think about when exploring what perhaps like tourist network could become in terms of like a utility? Do you think about other types of applications? We actually... We're like direct off start. Yeah.

And basically direct off and the Torres World and all are just different ways of integrating with the Torres Network. And direct off is, allows any application to directly assign store and retrieve keys. And we really see the Torres Network as kind of like a decentralized Amazon Cognito, for example. Or a decentralized Google Firebase. if you are off zero. It's like that back end which you can interact with to store and do your user authentication

and all that, but instead of it being one centralized entity, AWS or something like that, it's distributed and decentralized out into a note set. So the Taurus network generates shares of keys that are generating using Shemir's secret sharing.

I'm not an expert on cryptography, but I've got the basics about how this stuff works. And I know that there are different ways in which you can generate key shares. So Shemir secret sharing is one. There's also the ECDSA threshold signature algorithm that other systems use. I think like Zengo uses this for their official recognition key generation system. And then of course there's other methods like the, you know, if you look at, you know, Argent or Gnosis safe, you know, they do key generation, using a smart contract.

Talk about the process which led you to use Shemir's secret sharing and did you explore some of these other methods? Why choose this particular technology? So one of the main benefits of using a crypto primitive. So Shemir secret sharing is a crypto primitive in that it sits on the same level. The end result of Shemir's secret sharing is always a primitive private key. year. And the main, one of the big reasons, we evaluated the going like the smart contract wallet style. We also evaluated different forms of secret sharing. So other forms of secret sharing

and certainly our main goal at that point in time was to bridge Web 2 to Web 3. And it continues to be that moving forward. We want to make public key infrastructure universal to everybody. And when specifically comparing the public-private key pairs and something like to smart contract wallets, public-private key pairs have the power of, like, for example, some of the things you take for granted, for example, like signatures, like representation, like composability across different systems. It can be used to encrypt, decrypt. These things are possible for a public-private key pair, which aren't possible with a smart-compet. contract wallet. So how, like, the way to phrase it would, another way to phrase it would be like, you can't really use a smart contract wallet to sign a transaction for a blockchain. That's one

problem. The other thing is also cheese are off-chain, so they don't take gas to deploy, and they can potentially be private. So if you do any of this, this share reconstruction off-chain, if you have separate hierarchies or different other systems, not necessarily using Taurus, but using another different system to do it, you could keep it completely. completely offline. So no one even knows that your keys split into how many pieces. And that could be useful, like for, like, let's say someone who will coerce you, right? And if you hand me your device, you can just say, okay, you can have my device, but they don't know that your keys actually split across three devices, for example. So, I mean, these are some of the benefits. The other

big one, I think, is also cross-chain compatibility. Smart contract wallets are only Ethereum. And Ethereum has a bunch of applications, but there are also other chains, right? Like Bitcoin's a chain, and beyond chains, right? So we also want to, like, public key infrastructure is not supported just in the general mainstream applications and use cases today. And you've seen certain applications, I'm not sure if you've tried the messenger like Signal or back in the day, key base. So these guys are also trying to proliferate public key infrastructure.

And we share the same ideal admission of them. It's just to make it mainstream and make it accessible. and applications just beyond blockchain as well. Right, okay. So with Samir's secret sharing, by generating keys that are cryptographic primitives, you open up potentially, you know, all kinds of other applications outside of crypto,

but also just generally, like, these keys are compatible with any crypto, any blockchain. Exactly. One more correction about threshold signatures and Sharmu's secret sharing. Threshold signatures actually require Sharmes secret sharing. So, Shred Shepard Shepard Shepardt's signatures already, already, they assume that you already have a key

similar to shares, and then you can use that to do some protocol called threshold signature protocol, and then use that to generate a normal signature. So if you want to support threshold signatures, you already need to do Sharmai secret sharing. What are some of the pitfalls of Shemir's secret sharing? So I'm curious if there's any security or sort of like threat model disadvantages of

using this particular technology and if you've thought about ways to mitigate those. Like I think there's something, I'm not sure about this and maybe you'll correct me on this, but I believe that with Shemir's Secret Sharing, there's necessarily the presence of a master key that is derived. And so they're like, am I correct there? Is there sort of like a master key generation process and from which the shares are derived or is it a more horizontal process? There's no master key.

The best way to explain it is actually visually. So imagine if you draw a line, right, a straight line, and you have three points on the line, right? If you only have one of those points, you can't get back your line because any number of lines can go to a single point. But with two points, you can. And this is basically a two out of three Sharmac secret sharing. And this is true for higher power. So for x squared, you need three points, X cubed, you need four points. And so on.

And you can do this. This is Sharmé's secret sharing at its core. And you can do this multiple times. And the reason why you want to do this is if you have just one line, the person who drew the line knows the line, right? And that's kind of maybe where you read about like the master secret and all that. Like there's a dealer. That's the official cryptographic term.

The dealer knows the secret, yes. So the problem, that's the problem with Shama's secret sharing. And DKG's distributor key generation solves that by running. N rounds of Sharmai secret sharing. So everybody creates their own line. And if you sum up all the points across these multiple different lines, you get something that is still a Shamaicry share, but nobody knows the line because everyone contributed randomness to it.

So that's the base. You can't derive the original lines because you have to add up all these different values to get to the final value. Everyone has to have all the lines. So, I mean, Shemir's secret sharing in itself because it's a primitive form, doesn't really, it's hard to find like I mean that it allows you

to split it into a threshold manner but a lot of the problems arise when you try to use Shemir secret sharing in a usable form exactly so for example security it's more usability

so it's more like like how just like how what Leonard just mentioned we want to generate in a distributed manner how do we do that and that's how what DKG solve but it's also like

oh we we have shares now, right? But what if we want to revoke the share? What if we lost our phone and one of our shares are there and we don't want it anymore? So revocability? What if our devices

are offline? How do we refresh shares? How do we ensure that our key hasn't been stolen before and isn't compromised? Exactly. So it's, yeah. It's those usability problems that kind of creep in and you start building features around it, they get more complicated. And there's some things that are harder to

achieve with Shamir secret shares, then with something like a smart contract wall. And with a smart contract wall, it's really easy, right? Just remove the key, and that's it. Key equals to no. That's about it. And with Sharmier secret sharing,

it's slightly harder. You also need to solve other problems, like incentive compatibility on, when updating the structure. I guess on a technical level, it's also a little bit more complex in that. So this is just

evaluating terms in terms of like do you want to build a smart contract wallet or do you want to build? Not saying that smart contract wallet work is easy. By all means smart contract wall is complicated. It's hard. You require the audits and all. But cryptographically, you have to understand

the primitives a lot more and you're a bit more constricted to some of those primitives relative to smart contract wallets which have that general computation. One benefit though that smart contract wallets have is the easy access to Ethereum state. So that's useful in a bunch of ways.

Like, for example, if you want to do daily spending limits, that's going to be quite hard on a Sharmac secret share. You have to do it something like locally. But with smart contract wallets, you can enforce it on the Ethereum blockchain. So that's that. One wouldn't be prevented from using a key generated with Taurus to access a smart contract wallet. That's the thing with, you know, using this primitive is that you're, it's basically, it's your key. You can then go do whatever you want with.

Exactly. And no one even knows, actually. You wouldn't be able to tell. And actually, and actually we, so via direct off, right, we've had actually some, several wallets integrate us doing exactly just that. So, Nose is safe. Naturally just makes it accessible to everybody. Skyweaver, I'm not sure if you've heard of Horizon Games,

but they were like, they're a project invested by Reddit. They've also built a wallet called Sequence, which also integrates Direct Off. So it's Torres Key Management to a smart contract. wallet or to like a multi-sick. So these abstractions are always entirely possible because if you're playing with a cryptographic primitive.

Yeah, the key can do a bunch of things, right? Okay, that's really cool. Let's talk a little bit more about the higher levels of abstraction in the kind of tourist stack. Well, let's maybe dive into the wallet and the direct off. So on top of this key management infrastructure, there's a wallet, which logically, like, allows people to store funds and, you know, interact with, with the Ethereum blockchain. What does these, what are these products look like? And I think maybe a good way to segue

into the user experience aspect is to walk us through what the process of creating your key looks like. Like, what does a login look like for a user? And, you know, in the, in the background, what's happening when, when someone creates an account using Taurus? Can we share our screen for this one or does it not record? Go for it. Yeah, I mean, so for those of you listening on the audio podcast, you can always check out the YouTube video, which will be in the links for this episode. And you can check out this screen share. So for a returning user and as well as a new user, the login process is, as your login process is, as you're a

logging in, Google verifies that you're logging correctly and returns to you a signed JWT token. This token is then sent to all the Taurus Network nodes. They verify independently against Google. And then it's valid. They return the shares to you. And then in the front end, your key is reconstructed. And that's where your key is going to stay. It's not going to leave the front end. Once you close the tab, it's gone. And this is the Taurus wallet. If you log in at app.orgata us, but you often see us integrated on different sites and the apps. And over there, we are running this entire process within an eyeframe, which then communicates with the external data, allows them to do metamast-like transactions via like confirmations and

signatures. So an example is on Avey, who has integrated us. And you can see that the Torres Wall here, essentially, this is the experience on another application with the Torres Wall. So describe what we're seeing here. So what we're seeing here is Avey basically integrates an SDK called the Torres Embed. And this loads up an I-frame that runs in the background. I-frames are protected via the domain security model.

When I log in, this I-frame presents this model. And when I interact with this, I'm basically interacting with the Taurus domain. on app.org. On app.org. And thereby also the Torres name. Okay. So this model window shows login with Google, login with Facebook,

login with the different service providers that you support. You've clicked on login with Google. Now you're picking your user account. Basically, it's a one-click login into your AVE application. And a user can immediately start interacting with the application

he or she wants to do, be it like trade, be it buy variable items. So important point to note about the domain security model is that your key is kept on app.taught us domain. So Avey.com can't directly access the private key if you're using the Taurus wallet in this way via this integration. So it's interacting with the Web3 API. Exactly. It's a VATRRU provider that routes these requests to the I-frame, and then it's signed there and return back out.

So this way your key is kept safe. So if you use the Taurus wallet on like a less trucker. site, it's still okay. It's the same domain security model that, for example, Chrome extensions, like Metamask and all use, it's the exact same. It's the browser. It's what the web is built on. So this is the Torres Wall integration, and with this integration, we're integrated in most of the top

defy applications out there. You can get started here. We also have a Chrome extension, which is a little bit less known. But because users asked for it, we just basically have a Chrome extension that users can and download and use to interact with different applications as well. We, and this is more of like the front ends that Torres provides. And the developer experience for this, right, is they get a WebTree provider. That's the way this integration works.

Right. So a lot of it is really just being around simplifying the developer integration for them. So we could, in theory, with just the Torres Network return a private key and then have the developers do with everything. But that would be extremely developer-friendly. So we built this UI, this nice interface that mimics all of these things that are already used to with known web three providers like Metabast. However, we also had a lot of requests for people wanting to directly interact the Taurus Network without a pre-built UI. They wanted full control of the user experience. They wanted to either build a wallet for themselves or have it very customized and tailored to their application.

As such, Direct Off was created. And direct off really just abstracts all of the interactions. So that key assignment that you saw, the retrieval of shares, the reconstruction, all of it happens in the direct-off SDK on the applications front end itself. And any application can basically emulate that exact same experience by integrating this. So you have the wallet, which you've built, which is sort of like the base layer in terms of user experience, right? So like any application can integrate Taurus. It's transparent to the user that they're using Taurus. They can always go check their Taurus wallet, you know, on the Taurus website,

access the funds there, et cetera. But for those who want a more custom experience and something that's maybe a little bit more white labeled and don't necessarily want to have like Taurus kind of, you know, as part of this as it is experience, they can build their own wallet on top of basically this SDK that abstracts away all of the user experience aspects you mentioned. Imagine a Toros wallet and remove all the UI. That's basically what DirectOth is. And so it's important also to note that DirectOth is also secured via the similar same domain security model. So applications, if you integrate DirectOth, it's not like they're getting your user's Taurus key.

It's a different key. It's a different key. It's a different key. It's specific to application. So do these then, are these different, I'm thinking about them in sort of like namespace terms, right? So perhaps some app uses the direct off SDK and users are able to retrieve their funds using their specific wallet. Can they then log in, say, with Taurus or some other service provider and still access their funds or are they kind of like locked in

in some namespace? So for direct off, it's namespace. And the reason for that is security, right? Because if a user logging in on any random integration with direct off could access all of their keys elsewhere, then our security is basically the weakest link, which is the weakest, most insecure that that uses direct off. Which can be pretty insecure. Which can be pretty insecure. So for direct off, it's actually nainspace. The private keys are completely separate for each application. But I mean, in terms of like the ecosystem, and, uh,

whether or not they can leave the ecosystem, of course. We give back the public-private key pair. So as long as the wallet integrating direct-off or even via the Taurus wallet, keys are always exportable. You can always take it away. You can import keys into Taurus as well if you want to do so. And people have decided to do. And that actually is what facilitates our account linkability flows that a lot of users in the Web 2 space I used to.

For example, in the Web 2 space, I can connect. Let's say if I log in and start playing some game, I can connect both my Facebook account and Google account to it. And you can do so. You can implement these flows via the Torres Network as well. So this is one of the things I wanted to ask you about is kind of portability. With this key generation method that uses Shemir secret sharing, what you get in the end is a private key. The combination of those shares, you know, populates or generates a private key that you can then export and go plug into Metamask or plug into whatever wallet you want. I like this because with other solutions that do this kind of threshold thing or,

or, you know, Arjun, for example, that uses a smart contract, you're, you're kind of locked in. It's, I think it's, it's more difficult to take your entire account in your account history and like bring it somewhere else. You'd have to transfer the funds. And I like the fact that with Taurus, you can just take the private key if you want to leave and you can bring it somewhere else and manage it through another interface or even just have like two interfaces from which you're managing your funds. You might want to have like, I don't know,

like on some secure system, like have your private key there where you can also have a backup or something like that. So I like that portability aspect. And I think it's important because I would hate to see, you know, crypto end up in this space where all these different solutions

aren't necessarily compatible with each other. And, you know, some of them are less, less compatible, I'd say, like smart contract while it's harder to move away from that. My view is that there's two ways to make like portability happen, right? Like one way is you use established standards. So examples of established standards are like

Web3 providers, C phrases, private keys. If you implement your solution in a way such as it natively relies on that, then it's obviously possible to migrate your keys. And that's kind of what we do. We try to make it just a private key. So you can use the private key elsewhere. And then the other way is try and push a standard. It's a lot harder, but it is possible.

And we've seen some standards be pushed for these kind of things. Yeah. But it's a lot harder. That's definitely tough. It's a lot tough. Yeah. And I mean, we definitely resonate with that statement that you just made and that, like, intropability is definitely very important.

In particular, what we feel as well with regards to portability is the way we've kind of thought about, oh, maybe it should be developer facing, maybe developers should choose where the keys go, maybe it should be all. But ultimately, I think it all boils down, and this is the same in the Web 2 space. It all boils down, I think, to, to, it should be user sovereign and user-controlled.

Basically, if a user-so chooses to be on a particular platform, he or she, ultimately, the end vision that we have is he or she can choose to migrate when he or she wants to, as a how to call it. and yeah, as with minimal resistance possible, as you feel to see. One of the things I also

I thought here, and I don't know if this is something that you guys do already or are planning to do, but because you're integrating with all of these Web 2 platforms, how easy is it then for someone to send funds

using an email address or a Twitter handle is that something that you orchestrate for the user or is that kind of an added user experience layer on top of towards that someone would have to build in their app? So you can already do that

in our wallet today. You can already send to Twitter, actually. You can send a Twitter. In fact, our latest campaign, the charity campaign, Bitcoin Tuesday, the Giving Block is using that. So you can send directly to the handles. And these are taxed by the way,

just chilling a bit here. These are tax deductible charity donations. So if you guys want to if you guys want to donate I've been looking to donate some crypto wallet, the booming market,

it's always good time to give back. Christmas, right? Yeah, check out the giving block and a Bitcoin Tuesday and donate via the Torres wallet. Yeah. And it's totally possible and not only do we do it via Torres wallet,

direct off also has this functionality. So Darrya off allows you to just look up a key based on a known user ID. So there are a few caveats, though. There are few caveats. The first caveat is that not all social logins support this. And for example, one example, and this may be surprising to some, is Facebook.

Facebook doesn't allow you do this because Facebook is actually really privacy conscious with their SDKs. And if a user has not logged into Taurus before, there's no way to know what ID they have. And the IDs are also app scoped. So this way you can't actually send to a Facebook user. So this is another question then. If I send crypto using Taurus to some random Twitter account, do they need to have a Taurus wallet already? Or is that something that they can do posteriori and like create that wallet later?

They can create a wallet later. So how that works kind of, kind of to go a bit into technical details, right? Because it sounds impossible, right? How do you do that? Yeah. How is the key, how is the key known if it's not yet generated? So as part of the DKG generation process, there are commitments made to the shares. So commitments are almost like the hierarchy works something like this. Private keys have public keys, right?

And shares have commitments. They're kind of like on the same, the relationship between private key and the public key is the same relationship between share and a commitment. And as part of the DKG process, you have to publish commitments. Otherwise, you could just send bogus information to other servers. By reconstructing these commitments in a certain way, in the same way almost as how you reconstruct a shares, you can actually get the public key because the relationship is the same. And this is a known result that's already used in other DKGs. So you guys are free to check out on the one called DKG in the wild by Anna Kidd K, who is our advisor.

and that kind of allows us to get the keys, the public keys of unassigned keys. And then remember back at the start of this podcast, I mentioned that there are two parallel systems, right? There's a DKG key generator system and then a mapping system. So what we do is the mapping system assigns you a new user who has never logged in before, assigns the user to an unused DKG setting, and DKG, right? And then that has a corresponding public key. So we do that and because it's completely parallel, there is no reliance on this, this DKG setup. It is possible to send to this public key first and then later on when he is a locks in, he can reconstruct his key.

The public key is generated first and then the DKG will kind of construct the private keys from the different shares. Is that right? So as part of the construction of the shares, the public key is already known. It's already constructable. I wouldn't say it is constructed because the actual. protocol doesn't require to construct it. But it is already possible. Because the DKJ is done, it's already possible to get the public key from the commitments. The funds are actually transferred then on the blockchain because the key is already known. So it's not like it's just sitting

in your system waiting for the. Yes. Yes. Yes. Yes. It's actually recent. You can see your ether scan. And that's kind of, um, and it basically can only, it makes, because the keys are assignable, you, you, it allows for sending ahead of time. And you can basically retrieve it afterwards whenever you like. Yeah. As long as you have the authentication to that. So there's some caveats. There's some caveats, right?

So the caveat is you, like I said, Facebook doesn't allow you look up. Some systems also are harder. Like, for example, there are some which are, which give you back random IDs. So same problem as Facebook. And the last thing is also, you have to remember that this is a threshold lookup. So you're sending it and the servers are reconstructing the keys. So these are some of the caveats. Overall, it was almost the same as Torres.

I'm thinking here. Could you do like PGP style email? Like, could you do this with PGP where you say, okay, I've sent you an encrypted email. If you want to decrypt it, log in with Taurus. Yes. On some email client that would implement Taurus. Yeah, you could.

And that's exactly how Schizzle works today. We have an application. You can download a Chrome extension, Chrome store, as a not our Chrome. our application. Somebody built via direct auth. That's how it works exactly today. They basically generate your key ahead of time.

They use your public key to encrypt an email attachment that you want to receive. And you send it to that. And then when you log in, you get back the key and you decrypt that. Yeah, exactly. Wow, that's really interesting. I think that's super powerful to be able to say to someone, or just like send an encrypted email without them having to generate any kind of like even knowing about

PGP and then telling them hey you can unencrypt this email by using you know this application and I think that's super powerful yeah that's cool I mean that that unlocks all kinds of use cases that I like I'd like to talk about Tiki we haven't we haven't talked about that yet and so if we kind of recap so the the Taurus network generates these key shares, a user can log in to a wallet using either the wallet you've

generated or a third-party applications wallet. But essentially, those keys are kind of only secured by the Taurus network. And what you've built is you've built like another layer on top called Tiki that allows for I'd like to call it like a two-factor authentication on top of that where one either has to provide a password or do some kind of like browser cookie thing and maybe we can talk a little bit about like those different types of second factor. But essentially it's like an added layer of security. Describe for our listeners what this does and how it improves on the security model

that you've already built in with this secret sharing. You've very aptly described it, Sebastian. So it is kind of like a form of 2FA, and really it's for basically users who right now who want to detach even more from the Torres Network assumptions or less of the Torres Network and more of the assumptions with regards to, let's say, your account being pegged to your Google account, for example. So with the Torres Network, if your Google account is accessed and compromised, right, because we use these faucets of authentication to validate and retrieve your public-private key pair, you also, your key gets compromised.

And that makes, that's basically a central point of failure that we wanted to definitely address with future, I mean, we've had people want it. and as well as we wanted to provide a solution that allows for this. And there are multiple ways to address it, right? You could do it in a centralized way. We could just send you an SMS code, right? Or we can do other things as well. You can do like a smart contract wallet and use more keys to secure and all that. But we want to stay true to our vision of just providing private keys, primitive private keys that are usable in any use case, not necessarily even on blockchain.

So on the technical level, what this looks like, right, is, you know, the Shemir secret key that you get, the key that you get back from the Taurus network, that actually, the shares to that key are actually just private keys as well. And similarly, that private key can be another share to another hierarchy of Shemir secret sharing. So Taurus Network provides one key right now. But instead of using it as a key, use it as another share. As a share, yeah. As a share. And then your browser also holds a share, and then you have some user encrypted share as well via password or secret questions.

And its base flow is basically 2 or 3. These two-fay, these ways that you manage to shares are basically flexible to the end use. Exactly. And ultimately, the base flow that we propose is one of the Torres Network, one starred on the user's device, be it browser or a mobile application, can start natively. and the last one being kind of like a recovery share being pegged to a password or something like that but this recovery share could go above and beyond

and because what you're sharing on this share is I mean what you're securing is one share and not the whole key you're allowed to basically do security questions on top of that you could do 2FA solutions which mainstream users are more familiar with like sending it to a recovery email for example sending it to a SMS phone number So we still retain a base flow that is convenient. At the same time, offer a higher level of security and better guarantees to the end user.

And to kind of like to just walk through it, like imagine if you're a user on Tiki and you had a share on your device, one on Taurus network and a recovery share that stored somewhere and protected by a password. If you're using it day to day, you wouldn't use a recovery share because you were on an existing device, right? So you already have one of the shares. You log into the Taurus network and then you're done because you already have two or three. And if let's say your Google account gets compromised, right, the hacker tries to access your account, your TK account, but he doesn't have a device. So that attack is also blocked. And if you lose your recovery share, let's say you lose it. And people lose these things all the time, right?

like who actually keeps a piece of paper in a safe. Right. So people lose this all the time. If you do lose it, as long as you didn't also lose your device on the same day, you're able to generate, because you're 2 out of 3, you still have 2 out of 3,

the Torres Network and your device, you can generate another recovery share. So you can throw away the one that you lost and recreate your recovery share. This gives you some form redundancy, and it's actually a very popular way that existing enterprise-facing security companies like Bitcoin and all that use, they already do something like this.

Yeah. And additionally, it's really designed. So most users today have more than one device, right? We have our laptops or our desktop, and then we have a phone, right? Users using Tiki, Tiki is designed to be flexible to the end user and use device-based security. And to that end, when you use, let's say if you try logging in, if end users you guys can try login via your phone and your desktop, you can actually create

a tool of four sharing. So you have one share stored in your laptop, one share stored in your phone, and then you have like a share up on the Torres Network and a recovery share. And that automatically improves a amount of redundancy. It's unlikely you lose your phone and laptop at the same day. Could it be that you have

say one share kind of attached to a Google account and one share attached to maybe a Twitter account or is it or is it necessarily you know the kind of like Taurus stack on one side and then like a password or another device or something like that

so you can do that but we advise not to do that because you you don't okay so so the reason for that is twofold right so a lot of people's Facebook accounts actually are tied to their Google accounts already. Right.

So a hacker just needs to access your Google account and he can get your Google share and reset your Facebook account. So you're still like basically having only one factor. That's one problem. The other problem is also by just relying on Torres Network shares,

you are still subjecting yourself to the threshold assumptions of Torres Network. And you could very easily avoid that by having just a device share. And if you're going to go through trouble Of actually having more factors authentication Why not go ahead and give yourself even better security guarantees But I mean if you're okay of it

If you like it? Yeah sure go ahead Just don't use the same email Yeah And yeah And we also enable for people who want A even higher level of security You can do more

You can actually increase this threshold So right now it's like 2 hour 3 or 2 out 4 But you could very easily increment this threshold to three out of four, for example. And that makes it more like a 2FA experience where a user

has to, I mean, very similar to your banking accounts. You log into your banking account, you need to access your phone and tap something. For us, it's you log in with your desktop, you log into Google, you need to tap your phone on your phone something and to sign a transaction, for example. So this all sounds pretty complicated,

but we've already simplified the entire flow such that a user can just use it today. And it's already live on Aetotah. Yeah, I signed up for it yesterday. And I did the, well, I did create like my first kind of Taurus wallet. And then it prompted me to do the T-key, which I was surprised, but I guess I understand now. It actually creates a second wallet.

And that's normal because you're generating a new key set essentially. Exactly. And the options I had, so I need two out of three. One is the Taurus network. The other is a cookie. that's stored in my browser. So this, I guess, is like the device authentication that you mentioned earlier.

And the third is like a password. I suppose there's other, on your roadmap, you probably have other forms of second factor authentication that you're planning to roll out. Browser cookies seem like a bad place to store a second share because I, like, personally delete those, like, once a week. What kind of things are on your roadmap to make this process a little bit more, yeah, maybe like having two devices or something like that?

Yeah, so definitely, as you mentioned, the two devices. Mobile application is slowly rolling up as well. The two devices. If you try logging in on a different device, it will prompt you to use that as a recovery factor. Okay. In the browser. Yes. In the browser.

Okay. And we are also planning to use secondary email for this. We naturally have to order style of also you can copy and paste it today. But we'll be offering it that in the onboarding UI as well. Now you can do it in settings, but we'll be offering that. and onboarding UI. You can send it to your email, a recovery email address.

So we recommend something separate from an existing Google account, and you can send a share there, as well as phone number, SMS, and really, if you have any other ideas. Yeah, let us know. If it's implementable, we'll build it. So something we've also been contemplating

is touch ideas. Yes, exactly. And we've been working towards that. I don't know whether we want to segue into that. next or should we Yeah, sure. I mean, let's talk more about the kind of UX challenges here.

Yeah, what kind of things are you thinking about in terms of building touch ID? Were there, would those keys be stored? And I think most importantly, how are they backed up in such a way that like if I lose my phone, I can still access the key, but it's not like unencrypted somewhere on my cloud. Exactly, exactly.

So there's this standard that has been around for years. I think it's like three or more years. It's crazy. It's called WebOthen. So WebOthen, it's become recently more popular because it's finally made it into mainstream browsers and properly support it. And that's how long it takes for WAN. Yeah, that's how long it takes for these standards to actually make it to mainstream.

But WebOthend basically allows you to use things like Touch ID to sign information, to sign in. And its purpose is for... In the web browser. In the web browser, yes. Yeah, I think my bank recently told me to kind of prompt me to do this. It is being used. It is being used by quite a few, like, security conscious companies in the mainstream. Right now, mainly it's being used as a 2FA solution.

Exactly, yes. So they use it additionally on top of a password login, for example. Or they use it with a UB key. I'm not sure. I'm not sure. So like a security external key. But really, this is actually, the reasons why this is doing so, they're doing so, it's because

they are trying to comply of legacy systems. Right. And if you think of, if you think of a login system from first principles up, you can actually create a completely usernameless experience. Yes.

Why do I even need like an email to login if the touch ID alone has some kind of public key that I can use to anonymous, mercilessly sign it, right? So that's a, and it will be a much better user experience as well. There's no need to remember any credentials.

I can just touch and get in. So that's kind of like what we've been working towards. But at the same time, you also mentioned a great problem, which is that what happens if you lose a device, right? If you lose a device, because the authenticator and touch IDs on your device, then that means your only way of logging is gone, which means you need to kind of solve challenges around how do you link a touch. It's actually, and basically we've solved, we solved that on a daily basis because this is actually public-private key pairs. This is metamask. Yes.

This is like Argent on your phone, for example. And we use very similar flows as well as potential social recovery flows. So basically, it's all about account linkability. It's about using your account on different phones. It's about linking it up to your social account as well. Google, Facebook, or whatever. It's actually the same concept. Yeah, we're glad that we can reuse a lot of the work we've already done,

Partiki as well as TAR's wallet. No, this is really cool. I like the flexibility that you guys have built into the kind of base layer infrastructure where you're thinking of all of different ways in which people can construct their own security model around their keys, I guess. But I wonder, in terms of user experience, what responsibility do you think you have in educating users I guess primarily on, to what extent they should be securing their keys based on things like how much money is in their account, right? So like if I open an account using Taurus and I've got like maybe a hundred bucks in there, I'm like, I don't know, buying some NFTs or something. The risk of losing my keys and like catastrophic loss of my crypto is fairly low.

So maybe I'm not going to enable Tiki. But like if I start using this to store lots of money, lots of crypto, lots of crypto, investments, et cetera, then, you know, I would think that those users would want to secure their accounts in more meaningful ways. What kind of things are you doing to educate users or kind of help them along the way to say, hey, you know, there's a lot of money in this account or there's lots being secured here. You might want to think about implementing a second factor or you might want to think about like, I don't know, things like encrypting your hard drive on your computer. if you haven't done so already, because even if you lose your computer, well, someone could have access to your account by the simple fact that, A, there's a cookie in your browser, and B, you know, your Google account is already logged in.

Like, just kind of simple education around personal operational security. So one of the benefits here is there are a lot of large companies who are a lot further along this roadmap of, like, educating users for security than we are. And we already prompt users to use. use 2FA or for their Google. And that's really important because that attack you just mentioned actually wouldn't work if the user, if the person who stole your device is on a different Wi-Fi, right? Because then Google will prop the 2FA. And what you would do, actually, if you lose a device, is you would sign out from all Google devices, right? That's often what a lot of people do.

If they lose, like, their Android phone, you would say sign up from all my devices. And now, to re-log in, they will have to somehow hack your account. So that's, that's a lot of, you know, That's one way to kind of use these already pre-existing solutions to do it. The other way is more native to Tiki. And we do prompt users when their account in the Taurus wallet exceeds a certain threshold. But we don't do that as part of the Torres Network. And one of the reasons is exactly as you said, in order to keep the network flexible and as useful as possible to a bunch of applications, it makes sense to limit functionality to what is good at.

And the Toros Network is good at holding, and holding, generating, retrieving, and sharing private keys, not necessarily prompting users when their amount on a specific blockchain exceeds a certain USD equivalent. That's going to be quite hard to do from a network's perspective. Instead, we leave it to front-end implementations to do this. And we have recommended guidelines for exactly when to do it. But I would say it's definitely use case dependent. Ultimately, these recommended guidelines are really dependent on all.

audience as well. Exactly. And particular users to users. If you're a game, maybe not so much of issue. Well, I mean, depends on how much you spend in the game. How much investment of your time? But essentially, it's like if it's going to hurt, if you expect your audience, like, if your account gets lost, nothing happens, then, well, you don't really need much at all.

But once it starts maybe, once it's kind of goes like maybe outch, that's an inconvenience. then maybe you might want to start adding maybe one to FAA or maybe ensuring that you have redundancy out there. And then once you basically, it's really going to cost a lot. That's when you start using Tiki with high levels of authentication. We also have external tools to allow you do this. So you can do this natively in the Taurus wallet already. You can import existing shares and keys.

But we're trying to build external tools such that a user can completely export each of its shares on hot. Let's say you have two devices and shares on each one of them. We want our users to use these external tools that they can run locally to reconstruct their keys. So not only, this is important because not only do they actually back it up securely, they also fully understand the model they're in. They understand that this is what I'm doing. These are how the thresholds work and they can choose what they will with it, what they want to do with it. And ultimately, this is a very ongoing process for us, to be honest. It's we kind of, we go through user testings.

We constantly kind of ask what these thresholds are. We think about the guarantees that we need to offer. And then we think about whether we had the right people to do it. Yeah. Another thing I think that's important is, you know, oftentimes if you create an account, you might secure it in the beginning. Maybe, you know, you've got like a secondary device or something. And then you get rid of that device, not remembering that you had one of your shares of your keys

there. I think one of the things I've seen companies do, like Signal does this. Signal has a second layer of security on top of the key, which is a pin code. And like every couple of weeks or whatever, it reminds you. It's like, what's your pin code? Just to keep you aware that there's this thing securing that device or securing the data in this case. And I think like reminding users, constantly reminding them like once every couple of weeks, say, hey, by the way, you know, you've got a, there's a security key that's on this device, you know, you just re-authenticated or just re-check it to make sure everything's working to, and that helps, I think, keeping that system kind of top of mind for people and remembering that they have,

you know, maybe like lots of funds, like stored. And if they lose this device, then they would kind of lose access to it. That helps them remember their pin as well. I've seen that have, I've seen that being used as well on like Authenticator app, Authi. So they also have like this, this master passive backup. And it remind you frequently. And it doesn't matter if you forget it, you just have to remember to reset it before you lose your device. So that's kind of how to do it as well.

I got a couple of extra questions here on, you mentioned this briefly. You talked about people reconstructing their shares. What happens if Taurus disappears? If the company disappears, and what assurances do we have that the network will continue to provide, you know, with shares, key shares for their users,

what's the incentive for that model to continue to live on? That's actually a great segue into our next tournament. But, I mean, initially, we can talk about how things are done now. We're initially right now with Tiki, right? That's the reason why we always advocate a two-hour three flow where a user is always in control of two shares. In the event where Torres is,

Torres leaves and all, the user is always kind of secured via him being, able to reconstruct his or her share locally. And it's always accessible and always possible for a user to do so. And this is, this attack is more, there are things that could happen that could make this attack possible. And it might not even be us just disappearing. It could be maybe your country decides to ban the Torto us domain.

Yeah. And then because of DNS look up and all that, there is, it's going to be really difficult for you to get access to the site. It could even be just maybe Google just thinks this is a bad idea And then they decided to block all kinds of things that are like Torres Or any kind of crypto application that could also happen So I mean yeah so there are a lot of these potential events And basically that's how Tiki kind of solves it

But we also are constantly thinking about how Torres V2 solves Yes and actually there's a lot of things in Taurus that already solved this So like for example our network isn't right by just us, is run by a bunch of no operators. And our code is completely open source. So anyone can just fork the code and run their own network. Right now, the state of the network is, it is right now, the Taurus network exists as a permission network.

And this, it exists as how it launched about a year and a half ago when we first launched to the public. And the reason why we kind of launched it that way is because we're kind of like a team that progressively decentralizes. We wanted to provide value from day one. We didn't want to be one of those. Back in that 2017 period, it was like, you know, all the shilly projects

or tokens and all that. We really didn't want to be one of those projects at upon the time. So we kind of went this route and we provided, we launched our solution, and we launched with Torres V-1. And today it exists with nine node operators in a federated setup,

which are all large ecosystem stakeholders. These include a... Can you talk about who some of these? because some stakeholders are. Ethereum name service, EtherScan, Binance, Tendomintemint, Core, Zilica. The list goes on here. There are nine nodes in total. And we run one of them.

Users can check this out at status dot, torus node.com. And for developers, you can actually check the network calls that are happening in your browser. When the SDK logs in, they actually go to these different servers, like they're owned by Zerner. or Binance. And you can see what's returning. Yeah. So, I mean, right now it's a permission network. But we are constantly thinking, and we are actually an active development of shifting

this permission set up, slowly to become more decentralized. So the first step of that naturally is with a kind of introducing governance into the system itself. Right now, it's fully permissioned. We choose who the nodes are. It's governed via a smart contract on the theorem. And the first step there would basically be making it such that participants of the network, including applications, users as well as different, like the nodes themselves, can opt to choose who can basically run nodes.

And this can work because our note set is dynamic. That's tough with DKGs itself. We've put a lot of work there. So just about to mention that. But anyways, and shortly, after, we're actually shifting to basically a completely permissionless setup. And part of the challenges there is also like incentives, right? How do you incentivize these servers to participate?

How do you kind of like make sure that being offline has like a penalty? So you have to be able to slash them for not responding. So we've thought about it. We actually have a pretty working model already. So we're thinking about like exactly what's the right way to kind of make that happen. And very likely what's going to. to happen is a large, a large part of this will run this initial test net, and then we'll see how to make that work first.

The end vision, the end vision ultimately is a naturally all of your participants being incentivized. Very similarly to how the ecosystem is incentivized today. With token economics, et cetera, like, you know, fees. Yeah, so it's like a utility token. I mean, we charge. a software as a service fee today, specifically to validate that applications

would pay for this on their users' behalf. And that's similarly how we foresee kind of like the ecosystem playing out. The fees and incentives being paid by developers. Ultimately, what we're aiming for is a decentralized key management system that is competitive with centralized systems today. So it's very similar to, I guess,

you would call it Filecoin and Sire, whereas they are for competing with Dropbox. For us, it's a decent system. centralized permissioner setup. Anybody can run a node. Anybody can offer their services. Anybody can be part of the DKG setup. And the things that we replace are centralized solutions like Amazon Cognito

of Zero or Google Firebase that exists in the ecosystem today. And there are a lot of challenges that we are trying to solve along the way as well. Like, for example, the OOF2 standard is by design very centralized. And it actually leaks information about the user. Like, for example, their email or their name. And if you're in a decentralized setup with a permissionless setting where anybody can join and leave, you can't just send these tokens everywhere. Then you'll be violating privacy of a lot of users. And we are actually doing an ongoing research grant as well with Waitier, who is doing a way to validate all of two tokens using ZK zero knowledge proofs.

And what that would do is allow you to validate a token on the client's side. side without sending a whole information to the back end. So just these different endeavors, which basically in totality our end vision is a decentralized decentralized. This is something I wanted to ask you too, is to what extent does using

Taurus leak information about funds held by an account or transactions executed on like Ethereum or any blockchain? Can anyone say look at an email address and figure out

what the public key for that email address would be, or even perhaps you guys, like, is that possible? And is this something that this ZKP solution would address? So via Google, via Google and via basically all different authenticators, the authenticators don't know anything, except that you have logged in.

It's just basically your handshake, and that's all of the information that Facebook or Google or Twitter. Yes. that we yeah after that um and in terms of what like data is accessible to an end user um or to a user like looking at let's say your email address via t key there is no information available as well because basically we don't actually know your t key on your google setup but via your torus key set up there's basically there is a mapping that exists on the torus network itself that maps like the corresponding unique identifier for a login to your social account.

And that is necessary because of the authentication requirements. So the ZKAP would help with obfuscification of all other data pertaining to the login, but that unique identifier would still exist. And it's really like a double-edged sword here because that thing that you were very excited about those lookups that you are very excited about is necessary in authenticating a user and is necessary in that particular handshake but it also leaks that that particular information is leaked and accessible because of that so kind of like we recommend if you're trying to use like a more private setting use tiki tekey gives you better security guarantees you are also private no one

knows what association is we are just tiki just uses your google login as a factor authentication but if you really like the lookup feature or like if you're just sending to a friend a couple of dollars and he's never used crypto before, definitely try using the lookup feature. Or also on that end, like because again, we're crypto native. We've always felt that this particular, we want, we've always wanted to censor privacy to the maximum, like as in like ensure the least amount of information is leaked possible. But for extreme privacy, right, it's always, it's always possible to use other solutions, which, touted, right? So like Aztec, electric coin. And that's easy to do because you use private keys. So if you want it to do, you can use it once a tech. So it's compatible with that.

Cool. So where can people find you and how can people start building in Taurus into their web three apps? So definitely if you're a developer, do check us out on our main page and our docs, docs.orgs.org.

And also, we We are very, we're very active on Telegram. So do check us out on Telegram. We have a developer chat as well on Telegram. Just specifically for developers who have questions, we answer everything there. A lot of our new features actually come from request there. And we have kind of like, we work hand and hand. Key management is a critical part of a lot of adaptation and application stack.

And for us, we particularly work hand in hand of a lot of applications. We help you guys. I mean, not that everybody needs help, but if you guys do, we assist in kind of like architecting of the key management system in terms of like trying to make it as seamless as possible

for the guarantees necessary for your application. So really just do get in touch with us and talk to us. We really love to help. That said, you can get started and check out our code base as well. To get started with Taurus

really is a five-minute integration. Yeah. And it's all open source code. All our, Dutertele for Tiki, a bunch of term for Torres public. So yeah, check it on. Cool. Well, I'll link to all of those links, your documentation and your telegram in the show notes. And of course, I mean, anybody, even if you're not developing an app, I think you should just go to Tor. Us and just try creating a wallet. It's a pretty incredible experience to be

able to create a crypto wallet using, you know, your Google account or your Twitter account or whatever kind of account you like and just walk through a process and give yourself an idea of what this process looks like and how you can create a crypto key using just a Web 2 login. It's quite cool. Yeah, 100%. Yeah.

And do let us know what you guys think as users as well. Always open to, always love to hear. Great. Thanks a lot for joining me, guys. Thanks so much, Sebastian. It's been a pleasure. Thank you.