Vladut Muresan - Argent Wallet and Card for Real-World Spending

Um hey everyone I am um Vladz I am a tech lead at Argent now ready from from Tuesday and uh today I'll be talking about uh our crypto card and why I think it's the the best in class and I will dig a bit deep into the technical uh bits and pieces of of it. Um so let me start with a one word statement peri. We are now ready for uh for mass adoption. We have the same mission as in 2018 but yeah now we have bigger goals. So uh for those of you who don't know it all started for us in um 2018 on L1.

Um we had a mission to make crypto accessible for all. We initially yeah um found out that yeah citruses of course are not the way to go and we pioneered things like uh social recovery guest abstractions and we actually were the first smart wallet on L1 on um on Ethereum. Everything went very well. We had a lot of users a lot of traction but uh as you know in 2020 uh there was the gas war and because of that uh it was very clear for us that it's not scalable for the next billion people. Um so from 2020 we actually were in the look for a for a new home.

Uh during this research we had two key properties that we're looking for. So one was the throughput because like I said we actually want to make it accessible for all. So for ne the next billion people uh so I can imagine that um scalability TPS and speed is actually very important. Uh during this we found out uh early that ZK rollup is the way to go and the second property was the UX because we want to offer a great experience for our users and in this um this part we again quickly identified that native account abstraction for us it's very important and back in 2021 the only viable solution that actually checked both of this was Starnet so from back then we are building on Starnet and Staret is our Um you heard me mentioning native account abstraction. So let me untangle that a bit.

What is what does it mean? Uh it's basically programmable accounts. So you can imagine that if you can program different methods of an account, you can achieve a better UX. For example, if you can program the authorized part, you can do things like uh signing with pass keys, face ID, biometrics, whatever. You can have things like social recovery.

If you can program the execute part, you can have things like multicolors. And if you can program uh things like paying the minor or the fees, you can have things like sponsor transactions or paying in other ERC20 tokens. All of this is happening at the protocol level on Starnet. That's why it's it's called native. Uh you can achieve some sort of behavior like this now on on L1 with um 4337.

Uh but it's happening at application level. Uh indeed with with the pect I become a bit better with 7702 but I haven't seen much adoption from wallets or from uh from DEP. So it's still very very early. Um what else can we achieve with native account abstraction? Something that's very cool it's session keys.

Uh actually we pioneered this in 2018 at um uh ready as well. We called it dab keys, but it was way too early and people really uh didn't care and it um didn't have any usage. Um for those Yeah. Um there is this video. It's an actual web free game.

It was very popular like um one year ago on crypto Twitter. Um being an onchain game, every action is actually a transaction. And as you can see, this is a terrible terrible UX. everything that the user um does he is prompted to to sign a transaction which of course it's not uh not what you want during the during the gaming session. Um what's what is session key and why um is it helping us solving this issue?

So a session key is basically a key generated locally by by the DEP. With that key the uh the DEP can sign on behalf of the user. Uh you might ask yourself if this prompts any security uh issues. um it does and it doesn't uh because the uh user is prompted transparently to sign the session key with some um under certain conditions and uh restrictions. So for example, the session key can be time boxed.

So I can I don't know allow the game to sign on behalf of me only for 15 minutes the the time that I want to play. Maybe I want to allow the DAP only to to sign certain um smart account methods and can I can even uh restrict the the token spending. Maybe I I'd want to spend only 10 USDC while playing this game. Um here you have an example of influence. Influence I'm not sure if it's visible but it's a again an onchain gaming on Staret mainet.

Uh it's a very complex game. You can give it a try. Uh but I hope you can clearly see that the UX it's uh miles better because you don't see any wallet. you don't see any um onchain actual interaction even though everything that you see here it's an actual transaction on on starnet. Um very quickly how this does this work from a technical point of view.

Uh again here we have different entities. We have the DAP and the wallet. The DEP is asking the wallet to to approve the session key. Again the user will transparently see what um what he's approving. Um because of our powerful um uh smart account model uh we also have a notion of co-signer which is basically a second signer a guardian uh more or less our back end here.

Let's say um in order for the session key to be signed I need both of the the keys here both the uh the yellow and the blue one. So if the user and our cosigner approves this, the cosigner also does things like fraud monitoring or uh making sure that the session key falls under the conditions and restrictions that we we expect. If both of these are are true and signed, uh we return to the DAP assigned token. With that token, the DAP can actually kick out the the wallet from the equation. And you can see simply communicating with the uh with a cosigner with our back end the dev can sign any transaction that falls under the conditions that we expect.

So yeah like I I mentioned at the beginning we at Argent we are pioneers of of greater UX. So we asked ourselves what else can we achieve with session keys beyond gaming. And uh I would like you to introduce you the the ready card. um cards, crypto cards have been around for uh 3 four years and here in this table you can see um clear comparison between uh different type of cards. So you have on the left hand side uh cards that are coming from centralized exchanges like by bit, binance, crypto.

com and so on. Uh these type of cards are custodial. They have some sort of account recovery. All of them they are uh they work like a top up debit. So you have to manually uh top up that uh account with how much you want to spend and of course you cannot uh join any any D5 protocols with that.

In between you have things that are um somehow self-custodial. They some of them have um account recovery. All of them sadly are still top up debit account. Uh and the D5 part is non-existent or very very restricted. And on the right hand side you have our ready card whom which is fully self-custodial.

You have onchain recovery. It works with your native starnet account. You can actually use it as a debit plus credit um card because you can do uh fully native uh defy on um on staret. So you can imagine a world where you uh use a protocol like Visa on Starnet. You deposit your wrapped BTC.

you earn maybe four or 5% yield on that BTC and you borrow USDC for your spendings or you can simply earn yield or on your USDC like 7 8% and you use that for your day-to-day uh shopping. Um let me get a bit deep uh technical on how a traditional card um works. Um so um when you tap um your card on a merchant u terminal uh the first thing that happens is an authorization call. Uh it goes from your merchant bank to through the payment network to Mastercard or Visa and it hits your uh personal bank. Then the bank is checking if you have enough balance to actually pay for that um transaction and it actually holds uh that amount to prevent double spending.

Uh then we have the clearing and the settlement. These actions happens in like two or three days. The clearing it's just uh batching a bunch of authorized transaction. It computes the amounts minus the the fees that have to go to the bank and then the settlement is just the step where the money actually moves from your bank to the merchant bank. Um and the question is how can we achieve this in a uh non-custodial way?

um the holding to prevent double spending and the actual settlement without any user interaction. Uh the typical cryptocard solutions so the things that existed until now um like I said all of them have a custodial top-up account because um uh and usually the crypto card provider either um has an infinite approval on a topup account or the topup account is fully self-custodial. So they are solving the holding and the um settlement with uh with this approach which of course it's not uh the way to go. It's not what we believe in because we are here for uh full decentralization. So um the question is can we replicate this in a fully um web to UX plus adding fully self-custodial uh and I think we can and I think we we achieved this at uh at ready.

We partner with Kipa. Kulipa helps us with the uh debit card issuance. They are helping us with the onchain settlement and that together with our um session key implementation help us achieve I would say the best-in-class um card experience. Uh so again we have three steps we have the authorization the clearing and the settlement. So we are we solve the authorization uh by using our cosigner.

Uh so the cosigner is the one that is checking the balance of the account and the cosigner is the one that is holding that amount to preventable spending. The cosigner is involved in any transaction that we signed. So before uh they are giving the thumbs up that everything is good. They are checking the balance and see if there is any amount that is being held and uh uh if there is yeah it will uh reject the the transaction. If it makes sense, then the clearing and the settlement happens with our session key.

KIPPA has a a session key that they are allowed to spend USDC on behalf of um of uh of our account. So with this um we also solve the second uh and third step um again in a bit more more detail. So we have no double no double uh spendings because we are leveraging our powerful model with the cosigner. We have transparent uh settlement with the session keys uh without any user involvement or interactions. And we have the user who is fully in control being fully self-custodial.

The user can at any point um reject or remove the session key. So they can kick out Kipa from the equation and they can uh also um even escape our cosigner. So they can move from something u that becomes a fully standard account. Um to summarize the the key benefits of um of our approach one you don't need to create an extra um account a topup account. You can use your native staret account that you use for any kind of defi that you have.

It's fully self-custodial. It's built on Starnet who is the most which is the most scalable ZK rollup out there. And uh a side benefit is that you can have some sort of um uh privacy. The settlement part happens once per day at the end of the day. And every transaction that you do is bundled with uh with that.

So you have some sort of privacy because even if I know your account address or your start domain um I don't know exactly what amount you spend and at what point in time. Um we just launched the um the light model. So we started at the beginning of the year with our metal. Metal is a premium card with a comes up with a with a subscription. You can have like 10% cash back in your first month then 3% on the subsequent months.

You have some onchain and off-chain perks. And we also launched the uh the light one which is free comes with some shipping costs but um yeah uh you have some perks and um yep if you are interested in it and if I got your attention uh yeah I can offer you a 30% discount on our ready metal. Just download the app uh register with your email and hit me up with your um your address and email. I I can um I can help you with that. Thank you.

That is amazing gone through dude. Thank you. And ready really has the top of the wallets, right? So we had a little question come in while you're talking here. Why did you abandon CK sync wallets in the last wallet?

uh we did it because so we indeed had for a couple of months uh ZK Sync um again back at that point in time it was not fully um uh it didn't have fully native account abstraction support and we really wanted to have um that at the protocol level and to be sure that we we can achieve the UX that we uh that we want in our products.

That is quite fair. Now the next one is actually also what everybody else is thinking. Is KYC required?

Sadly. Yes.

So what how much limit does that going to give you once you KYC? What is your daily limit on that card?

Uh it's a good question. I don't know exactly. I think we we can so we had users that hit a limit and they asked for a raise and we can do that. So we had a I would say one of the best support teams in in the crypto space. So don't hesitate to contact our support team.

I think it's somewhere around 10k or something like that, but it can be raised if it's needed. Sure.

Oh, so you have the ability to raise the limit. But what is your max uh max limit that you

I'm not sure. I I we

you're not even sure you're going to reach it. Well, that's perfect. Let's go buy a yacht together just for fun.

So, do we have any more questions down here?

Well, yeah, please.

Actually, that one is going to be very fun, I think, right here. uh when you mentioned the kind of privacy or semi-privacy element, how exactly does it work? So like is not each individual transaction reflected on the blockchain or just the one that you settle with uh the card provider or whoever.

Exactly. So the settlement all the transaction let's say I I do today 10 um u payments with my card at the end of the day you'll only see one transaction on chain the one that is the third step the settlement

but isn't because you mentioned that uh like every transaction is an onchain transaction effectively for the user right on on or or

not necessarily no only the settlement it's it's an onchain transaction

okay so each each each time a user taps a card it doesn't necessarily neessarily create an onchain transaction.

No, our cosigner will hold that amount and at the end of the day, Kipa will uh uh settle that transaction on chain.

Okay. And cosigner is an internal function of your uh uh like uh

yeah our smart account smart account model they have a second signer we call it the guardian.

Uhhuh. And that's uh has the power to actually hold um or uh yeah reject or approve a transaction

in which case certain volume of like daily operational liquidity needs to be sitting in that account that enables instant transactions right

sorry

like because if if the money if the funds are taken from the user's wallet are they

uh not necessarily they are being held until the end of the day

right so then you need to have this buffer somewhere else to enable those transactions or how does it work?

No, no, they are just being held by by our cosigner. At the end of the day, they are transferred uh on chain to to Kipa.

Okay. So it's more or less like in traditional banking because if you um do a a transaction with your card with your traditional card you might see that uh if you check your eban your bank account sometimes it doesn't reflect your your spending that you did right now because the settlement takes uh even some days.

Okay. Thank you.

Yeah. Okay, I wanted to ask if you are going to support um fiat deposits as for example I use Kosis Kosis pay and how it works. Uh I also have an eban assigned to the the wallet that does the spending and I can now transfer like uh euro or USD or even uh uh pounds British pounds and that will be deposited in my in my safe account and that can be spent then spent.

Uh yes, we're actually working on that and it will come very soon. So we'll partner with do uh which will help us to have an eban on every account. Yeah.

So we just had one more come up here. Can you talk a bit about the threat model of session keys? For example, could there be a scenario in which there is a session key hijack and the user would rather interrupt the session? Can the co cosigner interrupt that the session?

Uh yes. That's what's actually very powerful about our model. So indeed maybe I don't know I um approve a method on a smart contract and maybe the actual code of that method uh is changing uh in the meantime indeed the cosigner can interrupt that session because I'm not sure if I can go back but uh even though the user is kicked out of the equation uh the cosigner is still asked to sign every transaction. So uh it's still a communication there. So yeah, at any point in time the cosigner can kick it out and actually every transaction is being um sent to to it for some fraud monitoring.

So yes. So we're just getting them to get up the sign. There we have it. Now we can go a little bit back to go to it.

Uh yes yes yes. I'm not sure where it is. Uh here. So indeed now we signed the DAP has a signed token. um you don't see any wallet anymore but the DAP can it still uh has to communicate with our cosigner and that's the point where it can inter uh interfere and actually mark uh a DAP a smart contract or even an account as um as fraud and yeah it will not happen it will not go through anymore

I love it

yes please

uh is your support for browser wallets uh changing ing at all.

Sorry.

Is the support for browser wallets in already changing now?

We support this in our browser wallet.

You do now, right?

Uh now it's more or less on the um on the phone apps.

But just in the browser wallet, is there is there going to be

um probably not because we actually uh have now two we try to differentiate the product. So the browser extension is now fully focused on supporting the developers uh because we believe that the way to go is not in the browser. Actually if we want to on board people that are like we call it today normies uh they will not use a browser wallet right they will use a phone and uh we separated the products and we call the the mobile products now some sort of neopank actually want to be more or less revoluton chain uh and we keep the browser extension as something uh focused to developers