Decentralize QR Payments | Sebastian Burkhard | ETHMumbai 2026

So, hello everybody. I'm Sebastian. I'm founder at Yodl Pay. And today I'll talk about our adventures in decentralizing the app layer. So, typically when you hear the word decentralization, your first kind of reaction is, "Okay, that's probably going to be bad for the UX.

It's going to be bad for the users." Uh it's going to make everything more complicated. Now, when we started decentralizing our app, specific systems part of it, every time we did so, we made the UX somehow better. Now, what we are doing is QR code payments. Our mission is to make every QR code payable with any token, any chain, from any wallet.

We are now live in four countries, Vietnam, Brazil, Argentina, and the Philippines. We have got the partners in the pilot live for the rest of Asia, including, hopefully, by Devcon UPI in India. Now, the way it works as a user, you first download our app. There is a built-in non-custodial wallet. You top it up with stables.

You scan the local QR code. Pay with the stables. Done. The merchant receives fiat instantly and he's not aware that you paid with crypto, unless you tell him. Now, the way it works under the hood is when you scan the QR code, it is being sent to a local payment processor, regulated local entities.

They will resolve the QR code and return a payment request with a quote of how how much stable coins exactly they need to authorize the payment. As a user, you simply confirm the transaction and there is an on-chain transaction that sends tokens from his wallet directly to the processor's wallet address. The moment the processor gets his tokens, he then exchanges them into fiat and sends transfers the money towards the merchant. Payment is done. Very simple process, and the local processor they wrap the fees and the effects quote in that particular quote, so it's very easy and understandable.

Now, there's an issue. While the on-chain transaction with USDC or Tether is fully decentralized, permissionless, non-custodial, the rest of the systems aren't. The native app, it requires our the Yodel Association to maintain. If we walk away from our app, users won't be able to pay anymore. So, they're fully dependent on us.

And we are fully dependent on the app stores. If they block our app, it's no longer going to work. The same thing with the processors, full dependence, it's a single point of failure. If they stop operating, if they no longer want to work with us, there's nothing we can do. If they're down for technical reasons, people won't be able to pay.

So, to address that, we started working on these issues separately. So, first, we're starting to make the clients from one potential client into multi-client landscape. While the native app is excellent for UX, it's the best possible UX you can get, everybody understands it, it has one major limitation, and that the users have a new wallet that they first have to top up with tokens, and then they have to keep maintaining the token balance in order to pay. Now, the second annoying thing is the App Store. There's App Store reviews.

You can be blocked. It's not nice. You don't like it. So, what's the next possible thing? And that are the PWAs.

So, PWAs are simple single-page web applications. East Mumbai has one for the agenda. You can download it on your phone and it feels a little bit like a native app. However, it's still inferior and most people regular mainstream users do not understand PWAs. They only understand apps.

They want to go into the App Store to download your app. So, that's not a very good option. But, what is actually solving a real user problem is by distributing our client as a dapp into existing mobile wallets. So, a dapp you all know Uniswap is a dapp. Every DeFi protocol has a dapp.

It's a webpage that connects to a wallet directly. So, with that, users can open the dapp in the wallet they already know and trust and where they have existing token balances. Scan the QR codes and pay with the tokens in the wallets they already have. It's for us an excellent distribution channel. For the user, it's an excellent way to make their tokens payable in the world.

But, unfortunately, the UX is terrible in that case. You in a different app, it's complicated. Uh it's all all a bit different. It's web UI. It's not perfect.

So, therefore, we decided to move on and focus on SDKs. SDKs is the best of both worlds. It's a native payment experience. You can integrate as a wallet the SDK into your wallet and then all your users can are ready to pay. Now for a user it's the same benefit, native UI UX, and you can use your existing tokens to pay.

So with that, we turned from one client that is blockable uh permissioned into a fully decentralized payment protocol. If one of the uh client architecture if one of them is down, it still works for the others. The next issue we saw is with the processor. So previously we had a single processor. Single point of failure, if they're down doesn't work, if they're don't want to work with you, nothing you can do.

If they give you bad quotes, there is no competition for them uh to give you the best quotes. So we decided that for every country we have a multiple processors. Where we aggregate the quotes from them and we give you the best quote available. It's great for the users, best price. It's great for redundancy.

It's very hard for all of them to go down. But it opens a lot of complexity. Because every processor is a little bit different and completely works in a different uh uh setup. So you have to adapt to their needs. That's okay.

That's technical. You can get agents to program that all stuff these days. But what's really really hard from a UX perspective is that every processor has a different set of tokens that they accept. Processor one takes USDC on Arbitrum, processor two Tether on Binance Chain, and the third only a European stablecoin on a chain you've never heard of. So that for the user is completely not understandable.

How can I pay with in these systems? And they always have to have different tokens. It's very intransparent. That's where we moved to token abstraction. I said for the user it shouldn't matter what token you want to pay.

And we add a swap before the payment. So with that the user can pay with any token whether that's a stable coin or a meme coin. And we look up the best rates on a decentralized exchange. And add that swap before the actual payment. So it's a single operation for the user to confirm, one-click payment, and you can pay at all the processors at the same time.

That's basically our little journey making step-by-step improvements. Questions? Yeah. So good news is that there's once the user sends the blockchain transaction with the fast L2s like Arbitrum and Base it's less than a second. Arbitrum about a second, Base about 2 seconds.

And after that money arrives at the processor and he has time to send to the the merchant and that's about 3 seconds. So in total 5 seconds.

Yes. Yes, it's not fully decentralized. But we are we are working towards that goal. But the moment you have a centralized party to make the payment happen like UPI, you cannot decentralize that. All the way up up in that up in the there it is.

Yeah, uh that uh that's uh was all my questions. Like I understand like uh if you are building over a centralized system, you uh cannot make it fully decentralized. I was just uh wondering like how you were you were uh building it. So, yeah. Thank you.

So, earlier you mentioned that uh the recipient would only know that the crypto transaction was done if he's informed. Is that so?

Yes. Uh as the recipient, as the merchant, you will not know that it's a the payment. It will

Okay. So, uh like when we do the on-chain transfer, right? The there would be some fees. So, uh the user would be paying that fees and that would be deducted in that off-ramp amount?

Yeah, so there's there will be fees. Uh generally where we have uh there's a processor who takes a fee on the quote. In general, it's cheaper than credit cards because it's a local FX rate and there's less middleman involved that take a cut. So, in Vietnam, we're about 1% or 2% cheaper. In Argentina, up to 4% cheaper than cards.

Okay. Uh like is this similar to Cash App in USA?

Uh Cash App, it's uh peer-to-peer kind of app where it's a It's a fintech. It's a a neo bank. It's a a regular fully custodial payment system, yeah.

And also one more question. So, uh you move from multiple processors to a single router, right? And you are doing a middle swap in between and then you are transferring to a processor. So, there would be an extra fee over there, right? When you swap

be a fee on the AMM swap.

Yeah.

Well, that the user has to pay. But, he usually has to pay that anyway.

Okay, so

Other than that, there are there's a convenience fee on our side. Other than that, there's no more fees.

So, is the sender notified about those extra charges or

Oh, yes, sir. How much you pay for what?

Okay. Thank you. Like I also one one more doubt. The processes you mentioned like are those living entities? Like who are doing the

regulated local entities, payment processors, off-ramps.

Okay, so like are those like automated cuz if you're saying like when a transaction is made to a processor, it takes around uh like maybe two to three seconds for the chain block time and we take like two to three more blocks to like verify that transaction. And when the processor receives the payment, so like it is like automated automatically payment is being made or like he has to manually come

No, it's automated. It's they check the has the transaction arrived on our tools like Arbitrum. You don't have to wait for extra blocks to verify. So, that's actually super fast these days.

No, actually my part is in the second part. My question is from second part. Like when processes like like when we say merchants or processor or whatever you say. So, when they make the payment, so they have like the automated they're automatically making the payment or they have to come to their device and then make the payment themselves?

No, that's automated.

So, like which software are you using for the automation for UPI?

Uh that's not our business. That's the processor's business. But,

as I know like there are a very few like maybe a couple of softwares in India that allows automated UPI payments but uh like again they cannot be used by single entities since they are they should be like business owned they can be only used by business owned businesses. So like I still have the question like uh which kind of software like do you have any idea?

Yeah so the way they do it it's up to them uh they told us they will eventually get it by around that time. They've got the deals.

Okay so you you are still planning to launch it in India or you have already launched

It's not live yet yeah.

It's not live oh okay okay. Thank you.

Hi I'm Ali. I wanted to know um how has been the adoption in Latin America and the response to the product?

Ma'am can you please stand up?

Oh great Latin America is particularly Brazil is one of our uh popular spots there. They love it because it works everywhere. So you go to the merchant you have the QR code you don't have to ask it just say PIX. Uh and it's like a regular app. And so for them particularly tourists who don't get the local app that's the big thing they can't just get a banking app to start paying in PIX.

So that's their only way they can actually pay local.

Thank you.

Thank you.

Woo!

One two three