The Defipunk Bank

Transcript

Okay, sorry about that. Um, great. So, before I talk more about Fluid Key and what we're doing, um, maybe just as a very one-s sentence explanation of what Fluid Key is, um, Fluid Key is a privacy focused wallet, um, that I think you can almost consider as your onchain bank account in many ways. So, we've really focused on making it simple to moving money, um, holding money, earning yield, moving money also to bank accounts, for example. And, um, I'll show you a little bit about this in a second. Um, before that, I want to also tell you a little bit about why um, Fluid Key and why I've been starting to to build Fluid Key. Um, so, prior to working on on Fluid Key, I

was the CEO of a digital media company called Pulse based in Africa. And so over the last 10 years, I've pretty much lived in all of the countries you're seeing there in in yellow. Um, and I think one issue I've like very early um noticed is that moving money globally is really hard, but even moving money locally is um is a problem for many people in the world, right? Like I think if you live in Europe, this might less be be less of a problem within a certain country, but in different other regions that's not the case. And so um you know the the onchain kind of infrastructure um that has been emerging over the last

few um years is really I think something we can build a better system on. And so that's what we're trying to do with fluid key really building a financial home where um you have control and you can move money at the speed of the internet. Um the chart below here is um not a shitcoin. It's um the currency of Nigeria and the Naira. Um I also used to live there and and earn some money in in Naira. And that's another problem I've been seeing um as well as just you know saving in in local currencies um in in some regions in the world is is really um a losing way to save because you're you're basically um losing money um on a on a daily basis if you if you look at

it against the the dollar. Um, so yeah, Fluid Key is pretty much your onchain financial account. Um, so far we've had over $700 million transacted on Fluid Key. Um, have 15,000 users and um, over 800,000 privacy preserving addresses were created. So um in this uh talk I'll show you first a little bit like how we got to the product format that is fluid key today and then we'll talk also a little bit more technical around how self addresses work and how we enable privacy in this um relatively userfriendly way that um we we offer. So um I think last year was a really big year for um for us not just in terms of

fluid key but also in terms of the ecosystem. I feel like earlier there was always a bit of a disconnect between on one side DeFi and on the other side um you know Ethereum the Ethereum foundation and so on and so forth. I think last year those two worlds were um I think the ethos of Ethereum as well as um DeFi came together to offer at scale um what Vitali calls lowrisk DeFi um and um I think this DeFi punk ethos of using you know offering yield that is secure open source that gives users financial sovereignty um and also privacy is really the direction we're going with fluid key and so we're excited about you

know more people talking about this and basically this also being the direction the ecosystem is taking today. Um so I wanted to start by also you know explaining a little bit what we mean by that right um when you think of a wallet or you think of um uh yeah self-custodial wallet I think there's three dimensions that you can kind of think about uh that wallet usability on one side um safety and privacy. So I want to give you um three examples I think that are really good at one thing but not as good on on other metrics. Um I think when it comes to safety um safe multiscs are the gold standard. Um it's really hard to um yeah lose assets if you uh use a safe multisig in the right

way and have the right checks. Obviously you know about probably the by bits uh hack of last year. So that's not um always the case but I think that's still the gold standard and and something that is really um great on on this one metric. But when it comes to usability and privacy, it's not really um a great wallet to use. Then you have Farcaster, which I don't know if you know Farcaster, the social network. They've now also gone um really into um offering a wallet that's really integrated into the social network where it's really easy to send users money um from the wallet to um get access to DeFi through Farcaster directly and also basically um you know buy sell tokens and so on. So I

think on the usability from Farcastaster is really good. And then when it comes to privacy, there are a few wallets that are very focused on privacy. I think railway railway is one. It's rail guns wallet. Um but if you've ever tried to use it, it's really really hard to use. So um you really need to know what you're doing. You need to wait a long time as well. It costs a lot of money as well. And so I think all of these are good on one dimension but um I think you know in the end they don't really have a good balance between these three dimensions. Most other I guess like mainstream wallets are somewhere around this axis between usability and safety where um they do have good safety features for many of them. They also are relatively usable but actually privacy

isn't really something that any of them um you know offer right now. you get an address that uh you know anybody who sends funds to will uh see what you've done before with the same wallet um how many assets you have on that account and so on and so forth and so fluid key really I think the idea is to kind of you know tick all these three boxes in the best way possible and and find the right middle ground in these three axes um and I think yeah that's a little bit of the background as to how we've been thinking about building fluid key at a high Um, before I show you a little bit more how privacy works on Fluid Key, I wanted to give a shout out to Wallet Beat. I don't know if you've heard of Wallet Beat. Um, fun fact is I actually started

Wallet Beat two years ago as a like weekend project. And um, basically just you know um built a website with like um very simple check of different features. Does it support ENS? does it support you know hardware um uh wallets and so on and so forth and um then you know I obviously worked on fluid key a lot and and wasn't able to maintain it and um polymutex who is now leading um wallet beat kind of took over um the work on this and also like built a real community around wallet beat and so it's been really cool to see this now become something that's more than you know just a weekend project um but yeah um if you haven't heard of it check it out I think

there you can really also check what wallets are offering in a in a really good way. Um so now let's get into privacy. So on Ethereum um if you didn't know your account is publicly visible, right? So, if you have an address, anybody can look it up on Ether Scan. And if you're reusing the address for every transaction, that means they can see who else paid you, how much you earned from that address, what you did with your funds, um how your portfolio is doing, and so on and so forth.

If you want to check your own address, you can actually do that. We created this tool um a few weeks ago. So, if you go to privacy-report.flicky.com, flitkkey.com. Um, you can basically just run a report and see, you know, what was your peak net worth on this address, how many different addresses did that you interact with, how did they interact with each other, um, and a lot of other interesting things. It's a kind of v0ero, but uh, if you have any feedback or um, thoughts on how to improve this, let me know because I think it's a cool tool to just get a better sense of what your address actually reveals.

So, how do we give users better privacy without adding extra friction? Right? That's I think really the the question here. And I think the best way to explain this is to show you how create key works. So, I'll go onto my demo account just here. Let me zoom in a bit. Cool. So at f at the first site I think fluid key looks really similar to many other wallets. Um you have your total balance here and you have different ways to send and receive funds. What's different is this receive section over here where um you get an ENS. So this morets demo.f.id is actually an ENS. So you can input it into a wallet and um if

you input it into a wallet, it will resolve an address, but that address changes every time you input it in the wallet. So if now 10 people in this room type morrisdemo.fid um on a web browser or um in their wallet, they will see basically 10 different addresses. And if you then send me money, I will see obviously all of the payments that's that go into this account, but you wouldn't know about who else paid me, how much they paid me, how much I already have on this account, and so on and so forth. That's really at a high level how fluid key works. And um how you can think about about this um there's like three modes to receive money. One is there's a web link. So this morris demo.fk.id is also web link

over here. Um, it's an ENS, so I can paste it into my MetaMask and it'll work there as well. And then you can also just generate a new address here. So, you can pretty much create an infinite amount of addresses um and uh yeah um get paid without worrying about uh disclosing any any previous payments and so on. Let me stop here and just ask if there are any questions about this before I go deeper into it. All right, everything's clear.

I can continue. I think another thing to um mention is that the more recent wallets you're seeing, so like this these kinds of onchain neo banks, many of them from a privacy perspective are actually even worse than traditional wallets. And traditional wallets, I think, you know, your address isn't abstracted away. So you can kind of still, you know, add new addresses and manage your privacy in a very manual way. Um, when it comes to onchain neo banks, many of them basically give you one address and that's the address that will have all of your transaction history forever on chain um as as much as you use the the that onchain neo bank. And so I think there's a spectrum as well where um we're on the other side

and um every time you transact you basically can be sure that it's a different address that isn't linked to any of your your previous payments. So this is a little bit of an overview of how you can think about it. Um in uh the kind of traditional Ethereum world, you have your ENS or your address and all of your balance is linked to it. And then with um fluid key, every address is a new um yeah is holding your balance separately. So now we're going into uh cryptography and I'm going to try to explain also still at a pretty high level how self addresses actually work. So first if you want to receive funds um there are um multiple elements you you have to think

about and all of this is by the way is abstracted away in fluid key. This is just to give you a little bit more context as to how this works because this is all self-custodial and um you can on your own basically reproduce this without having to interact with the fluid key UI or anything like this. So first every user gets a meta public key. That meta public key, you can think of it as your like meta address that doesn't change over time and anyone who knows your address, you can share it publicly is able to create a stealth address from that kind of root um user meta public key. To create a self address with that, you basically do elliptic curve cryptography. So stealth addresses don't use any zk or any of

that. It's all elliptic curve cryptography. Um and you basically multiply um the user meta pub key with the secret and that's how you um yeah get this t address p key which is basically the ethereum address that you send funds to. In the case of fluid key this t address is actually an owner of a one out of one safe. So there's a layer on top of that but it doesn't really matter in this case. I think in the case of fluid key we're doing this because we want to do gas sponsorship want to do other things that are not possible if we were to use a simple EOA. Um and so

once you have these two things then obviously if you want to um uh if you want to send money to this address you need to communicate to the recipient that this address has been generated somehow. And there's different ways of doing this. Um with um with ERC5564, there's an onchain standard where you can basically announce a payment. And that means that you basically create a um a transaction on chain that is encrypted and that will allow um the recipient to scan the blockchain and find all the payments that are related to them. Um, another much simpler way of doing this is to just um use a trusted third party that will have all of these addresses, but um on a publicly on ether

scan, you wouldn't be able to to link these addresses together. Um, and then the third one, and that's what we're using with fluid key, is that these um addresses can also be um generated uh pseudo randomly. So instead of having a secret that just like is completely random, that secret is pseudo random. And that means that as long as you know the kind of meta secret that is used to generate all of these secrets, you can always recover your account without even having to, you know, use any kind of onchain scanning.

Um, now you have money on a stealth address and you want to send money out to uh to someone from that address. How do you do that? um in sync with that uh meta public key, the user also has a meta private key that basically is completely um you know known only by the user. So this is obviously completely private and stays on the device of the user and should never be shared with anyone because if someone has access to this meta private key, they basically have access to all of your addresses, right?

Like this is the same thing as a seed phrase or as a private key. Um but the secret is known by the recipient and the sender. And so if you multiply the private key with the secret, you're basically able to um create the self address private key. And with that you control the stuff address and and the public key um above. And so that's how stuff addresses work. It's pretty simple. Um if you're interested in kind of digging more into the code around this um you can just go to fluid keys GitHub. It's all open source. Um so you can also play around with it and uh kind of build your your own stuff with that.

There are few recovery interfaces as well that third parties have built um without us. So you can also know that if you ever you know worry about not recover being able to recover your funds if our UI was to disappear there are actually already um third party interfaces available for that. Any questions around this? All right. So, what are the downsides of what I showed you just before? I think the main downside is that this is all like EOA stuff. So, it's all based on elliptic curve cryptography, which means that things like key rotation or multi-IG support aren't really possible with um

with the system. And so I think that's kind of a downside if you want to, you know, use this to hold and and move very big amounts. Um, many users still do it. Many users also still use EOAs, right? Um, but I think in the future we can do better and have a system that's even uh more robust. And to do that, we kind of have to think about stealth addresses in a slightly different way. So on the left here um you can see the V1 that is in use today with with fluid key where each um smart contract. So each safe smart account that holds funds also has the private key not the private keys but the public keys the signer directly associated with that specific smart contract right they're literally um you know stored when the when the smart

contract is is generated. Um, and what that means is if you want to rotate keys in in this for in this case and you have a 100 different addresses, you'd have to rotate keys for 100 different addresses at the same time, which is really expensive. Also leaks all of your privacy because if you're doing it at the same time, then somebody can very easily connect all of these addresses together um and and just doesn't work really well. In the second case, um, you can actually decouple the signing from the smart contracts that actually um, hold the funds. Um so the way this works is you have a key store. So a key store is a central smart contract where on each slot a user basically just sets their keys. So um each person in this

room will have just one slot saying okay these this is the way I want to um approve transactions and and set my keys. And then each of the addresses that that contain funds, each of these smart contracts actually points to the slot on the key store that um will uh that will that will basically allow you to sign. So you have this kind of decoupling where each of these is connected to um to the same slot on the key store. And by doing that you are able to um to basically rotate the keys with just one transaction. you just rotate the keys over here in this key store and any you could have like 100,000 addresses pointing to the same

slots. They would all rotate at the same time just based on that. So that's really powerful. Um the problem of this is that it's more complex and um the complexity is twofold. I think the first one is in a multi-chain world, you'd have to have the key stores also sync across different chains. And the second thing is when it comes to privacy, you obviously don't want to have like a public link between your keys and all of these different contracts because like then you could like connect all of these together to the same slot on um on the on the key store. And so to to solve this, you we we actually built a proof of concept that allows you to sign these transactions with um with a ZK proof. So

you have a ZK proof that proves that you the owner of the keys on the slot that you know this smart contract is actually pointing to a certain slot and um with that you can basically then sign transactions. So um that's something that is already possible today. It's not production ready yet, but I think that's going to be the future of how stealth addresses work. And so if you're interested in checking out the proof of concept, it's also now GitHub and there you can kind of dig deeper. I know this is a lot to like kind of figure out and and take in. So if there are any questions, just let me know.

Yeah. >> Do you have a migration plan for us? >> Yes. So I think it it will depend. So first it's not going to be like we roll out in the next few few weeks and um obviously v1 doesn't mean you like you can still use v1 as long as you know the chain exists so there's no like immediate kind of um issue there I think there's two options right like one option is the two systems kind of exist in parallel but new addresses are generated with v2 and v1 is just uh still there for for a relatively long time um the other option is for users to kind of migrate with a with the push of of the button. The problem with that is

you obviously don't want to migrate everything at the same time. So then it needs to be like spaced out over time and so on and so forth. So um we'll we'll have to see um what makes sense or if we just give users the choice to like pick one of these two options, but um I think that's all things that are relatively solvable. Um yeah. All right. Good. So the next thing I wanted to talk about as well is like the kind of privacy we're providing with fluid key because I think a lot of people you know like when you look at crypto Twitter and so on everybody talks about privacy and and so on is a bit of the new meta but privacy

can mean so many different things and I think it's really important to know what um what we mean with privacy and and kind of differentiate between different types of privacy. So what fluid key provides with staff addresses is what's called unlinkability. And what that means is that um nobody knows when an address is generated that is your address that this is actually an address owned by you. Right? So like you can't link we can't link your main public ENS with this new address that is being generated. But you can still trace funds. So you can still see that oh USDC was sent to this specific address. we just don't know it's your address, right? So like if somebody pays you, you

still have that onchain kind of link of the payment going to that address. Um the benefits of this is it's really fast. This is elliptic curve cryptography. So in a few milliseconds you can generate an address and so you can do this like at scale. There's no there's nothing on chain happening or anything. So so it's really really fast. Um, and the other cool thing is that it's compatible with pretty much every counterparty and smart contract on public EVM chains because it's just a normal safe smart account. So, you can do pretty much anything you'd want to do with this. If you want to interact with like a D5 protocol, you can do this and so on and so forth. It's pretty much just a normal address. Um, as I said, it doesn't break traceability. I think you

know for some users this is also benefits because from a compliance perspective it's much easier to explain where the funds came from. If you want to unra off ramp funds for example you don't worry about you know mixing your funds with someone that is doing some kind of illicit activity or anything like that. That's pretty much solved from um the beginning because it's just like your addresses. You can really think of it of having like a MetaMask wallet with like hundreds of different addresses right? On the other side, we have untraceability. And that's I think what most people think about first when they hear about, you know, onchain privacy.

Um, and you can think of like I guess the simplest example there is tornado cache. Um, and lots of other now newer, more modern and I think more advanced shielded pools like privacy pools, like rail gun and so on that, um, are more in this category. Um the downside here is that this is not instant. Um you can't just you know do a transaction where money goes into the pool and out because that wouldn't really give you any privacy, right? Um so you have to deposit funds first. Then also most of these newer pools will check that the funds are not coming from you know any illicit kind of um activity, a hack contract or anything like this. And so it takes at least a few hours to move funds through a a pool. And the longer

you take them, you keep them in the pool, the more privacy you kind of also get from that. So they are relatively slow. The other thing is that you have a relatively limited set of operations you can do with them. So you can um with some of them you can like kind of just move money in and out. Um with most you can at least also send to other participants in in the pool and with some like rail gun you can also do some like basic DeFi like swapping some tokens and so on and so forth. Um, but obviously, you know, you can't just interact with an arbitrary smart contract and do anything you want with uh within the the privacy pool. So, you're much more limited in the kind of all of the things you could do with on on public EVM chains. The cool thing is

it breaks traceability. So, if you want to do that, um, you can pick a shielded pool. So I think the future is actually a combination of both where um we're combining unlinkability and untraceability in a way that when you want to receive money and you want to um basically do basic things self addresses are sufficient um but we can also break traceability when needed. So the graph here on the left is a graph that um Vitalik um added in his blog post about what he would love to see in a wallet.

Um and I think this is a really interesting way of thinking about it, right? Like having funds in a shielded pool in the middle where um these can kind of be moved into a different direction based on what you um what you want to do either directly with the shielded pool or by just moving money back to a self- address and then interacting with different other contracts, right? Um and so I think at some point on fluid key you'll also be able to use um shielded tools in in some way. Um because yeah it will help um really give you privacy that is uh even stronger in the cases you need it to be stronger, right? Like one case you can think about is oh you now receive like

$10 million and you want to spend that over lots of different transactions of like you know $1,000. self addresses aren't really good at that because you'd basically have one address with $10 million and then you'd spend out of it like a bunch of times. So you still link a lot of actions together, right? Um and so in these cases, if you move the $10 million first into a shielded pool and from there you move it into, you know, hundreds of $10,000 addresses, you kind of get the benefits of both worlds. And and I think that's where we're we're kind of heading in the in the future. Any questions here?

If no questions, I will um head to the last part of the the presentation. Um yeah, I want to show you something that's not privacy related. Um, so I think privacy is obviously one key feature within Fluid Key, but um, many of our users like Fluid Key because we're also offering a very simple way to move money and to earn yield from DeFi in a I think relatively safe and smooth way. So um, that's something that um, is really appreciated and I want to talk to you a little bit about how this works.

So with fluid key the first thing is that you can get paid um directly from a bank transfer and it will settle in fluid key on a new self address every time. So if you're a fluid key user you can create an a account an IBAN account to your name um and if somebody pays you on this account so we have users that for example receive a salary to fluid key um it will go to a new self address every time. So you benefit of the same like from the same privacy as well. Um and once you get this on on the the stealth address is obviously converted into either USDC if it's an a transfer or euro if it's a um a euro transfer. So that's the the kind of bank rails part.

And you can obviously also directly receive funds to your self address without receiving a bank transfer. just uh thought it'd be worth to to mention that. And then without clicking, without even opening the app, you can start earning yield on these funds as well. That's the power of using say smart accounts as our uh account system because users can basically enable a module that allows auto deposits of these funds. So as soon as you receive funds from um you know either bank transfer or a normal transfer into fluid key within 15 minutes these funds automatically get deposited into uh 4626 vault so Morpho vault a vault um or or some finance vault and so you kind of

earn yeah automatic defy lending yield the moment you receive funds inside of fluid key and I think that's um something that also is uniquely possible on chain because we have this cop um basically permissions to move these funds to one spec specific vault and only move them on behalf of the user without being able to do anything else. And so you have the kind of um security of having very limited scope of what we can do with having automations that um are really powerful and allow you to earn yield right away. So that's um what I wanted to end this uh kind of overview with as well and and and show you a little bit about how fluid key works.

Would love to answer any questions you have as well. And um before we we end this as well, I have a QR code here. If you're not on Fluid Key yet, you can um check out this QR code to either download Fluid Key or um you know, open it on your your browser. If you then open it through the link that appears at the second step, you'll um upgrade directly to 20K in free monthly bank transfers from it. And there's also a small um USDC surprise that will get dropped to you. Most likely it'll be one USDC, but if you're lucky, it'll be enough to have a nice dinner later. So, um yeah, we'll uh we'll see if anyone gets it. It's like a there's the same

probability for everyone, but uh I think we have 40 invites on this, so we'll see. Please let me know if you get it. Um yeah, and if you want to follow us as well, um it's fluid key on Twitter and Farcaster and also on uh Telegram. And I'm Moritz Fluidkey on Telegram as well as Twitter as well. So feel free to reach out. happy to you know chat more as well if you're interested in fluid key I'd love to onboard you answer any questions and yeah thank you very much >> yes >> thank you so I have a question let's say

if I have uh $10 in each of my 10 wallets address and if I'm sending 100 to other user So it or let's say if I'm sending $60 to other how can you decide it which the allocation of the money form and also uh will it cost uh any more gas fee during the process? >> Yes. So really good question. Um so to your second question yes it's slightly more expensive than a normal transaction because you have to move funds from different accounts and so um yeah gas fees are higher. Looking at gas costs today, honestly, it will really not make a big difference. Um, on L2s, it'll be sub 1 cent and on L1 as well, it'll be

relatively low. So, I think to the end user, it doesn't really um change a lot, but it will be more expensive than a normal um kind of transaction. Now, about how we're moving money, if you move money from different um addresses, the way it works is that generically it will compute the most privacy preserving path to do the transfer. So, um, if you say, you know, receive $10, $100, and $100,000, if you want to send $90 out, it'll take those funds from the $100 address generically to move the funds. Now, maybe you want to send $110 out, then what it will do is it will combine the $110 address to to do that.

Sometimes you want to make sure that a certain address doesn't get connected to a certain transfer as well. You can do that, too. So you can label different incoming payments and say, "Hey, I only want to send money out of this specific label." And so that gives you more control as well about what is being sent and revealed to whom. So um we're trying to give you that control, but for many users, you know, what they care about is just not having like this one massive onchain footprint of all of their, you know, past history forever connected to one address. And so um many of our users also just use the kind of more generic algorithm um to to send funds out.

>> How does the key rotation actually work? Is it like updating the secret? >> So you mean by key rotation do you mean like changing um the signer of the addresses or like just generating a new address? >> Uh about the key store. >> Ah okay. So this is so this is not just to be clear this is not in production today right. Um so the way it would work is basically just by um doing a transaction on this key store that um is signed by the former keys and that sets new keys. So very similar to and you can really think of it like when you're updating a key on safe multisig right um you would also have to meet a certain threshold and if you meet that threshold

then you can rotate a certain signer um it would be very similar here um yeah >> and and the the key story how does the mapping actually what maps to map what maps what on the key store. >> So my co-founder Antonio is the I think he's the the brain behind this. So he would be able to answer this better. But I think the short is the really cool thing here in the key store is that we can the first slot we assign to a user actually doesn't cost any gas because you it's basically based on the hash. So like as long as you know the hash in the

in the Merkel tree um you can basically um already generate smart contracts that point to this hash this like generic hash and you know that like with these addresses you can also um update that specific hash that's my very like top level explanation of this um yeah sorry >> so so it's is something like all of the underlying address can be um comput back to a single hash that's store on the contract with a hash.

>> Exactly. So like if you you you basically just take like not all of the under so all of the underlying addresses are basically I guess compressed into your like meta private keys right in a way right or like your signing settings and then those you can basically transform into a hash and the hash determines the position on that key store if that makes sense. Awesome. Yes. >> Is the sign key right now the key or the key of the of the key?

>> Um, so what what do you mean by signing key? >> Because right now if you want to switch different devices, right, you can choose to use the same key to login. Yeah. >> Right. Yeah. So, is that the meta key of the master key or >> that's pretty much the the meta keys or are the ones you switch between devices or it's like the the one key the one key from which all the like other private keys >> the login. >> Yes. Well, so yeah. So the login one is basically so the way the the stealth private keys are derived is based on one private key as well. Um and so yeah, you can say like there's like kind of a meta private key of the meta private keys. Um

so the login key is the meta key, right? >> Yeah. >> Yeah. >> Got it. And do you have to track all the still address that's being derived from uh by derived by the meta key like in your database? >> Yeah. So um if you like so so there's two things, right? you don't need to rely on us to like you know store uh any addresses or anything for you to recover funds because these all pseudo randomly generated right the thing though is if you want to have an experience where you get a notification as soon as you receive a payment um you just type in the ENS and and and the addresses return and so on we do need to kind of sync and index those addresses for these specific

things but again you can always access your funds without us without you know any any of our Got it. Yeah. Cuz what I'm curious is um would that incur additional workload on your end if you grow more users because you have to uh receive like because stuff address can be infinite right can be randomly generated and you have to track like let's say there are end us uh end users yeah >> and you can generate like m addresses for each one so you have to kind of like monitor every potential modification or receiving things on >> yeah that's a really good engineering question because we probably already have generated more addresses than most

like mainstream wallets you you know um just because of this right and so we definitely can't rely on like uh normal like wallet API and just be like querying it every time you open fluid key if we were to query your like hundreds of different addresses that wouldn't work right um so we have our own indexing system that um works a bit differently where um we we basically look at every transaction that gets uh published on chain and check if it's um connected to any of the addresses that our users use and so that scales >> pretty well. Yeah, because what I'm curious is like traditional indexing in front doesn't work.

>> Yeah, exactly. So we had to kind of build our own for that. >> Got it. Thank you. >> Quick question. Uh is the code base open sourced? >> Yes, go ahead. >> I I found a not old one, but it it was like not up to date. But >> you found so the all of the core cryptography is open source and you can let me just open it here as well so you can see that. Um let me check. So here we go. this fluid key stealth account kit um over here that's contains all of the

cryptography you need to generate all of these addresses as up to date we're using the same package we're not using anything else um there's even like a recovery interface um it's also hosted on another domain but we are hosting it on our own domain we didn't build this this was built by a third party um that you can that basically uses the same kind of underlying um you know cryptography to basically recover addresses is also without us. Um, and I also like a few weeks ago I did a kind of video tutorial on YouTube where I walk you through the steps to use this as well. So, um, you should have everything really to kind of do this.

What isn't open source yet fully is all of the front end. So, that's something we're uh we're working on. >> Yeah. Awesome. If there are no other questions, thank you so much. Um, it was a pleasure to be here and uh, see you soon.