Instant Payment Liquidity via zkTLS Deposit Proofs - Ricardo - zkTLS Day @ Devconnect 2025

Transcript

So good afternoon everyone. Thanks for coming. I am Hikaro Santos the CTO of Mansa Finance and uh essentially Mansa is backed by Tedar. We help fintex and payment companies to to move money across the globe instantly. And today I'm going to show you um a short demo uh real real use case how we are using and the KTLS and I hope you enjoy it. So let's move on. So uh before going through the specifics let me uh go through the the problem statement. Uh incent payment uh has a liquidity trap. So even though we

are moving stable coins in and out we we need to do on ramp off ramp right. So and when you we do it so you need to to live with the bank rails and and and interact with them but the biggest problem is liquidity. uh essentially in merger market we don't have enough liquidity to to do on-ramp off ramp and we have many in several issues like capital controls we have effects windows close we have uh regulatory issues and and money can't move at the speed of the internet at the

speed that we we should um we should like to to to have but So we have $4 trillion trapped inside the bank system because those biggest companies that do emittance like Moneygram, Wise or Western Union, they need to have refund accounts all across the globe in local currencies and those they need to to have these no accounts in every single country to to fake it. that transaction is the payment is an instant. So then the time to settlement using swift is

two plus one or 2 plus 5. Even though we are using stable coins, we we still need to to use the bank uh system which is terrible, right? So the problem that we are solving here is how can we enable fintex and payment companies to to have instant liquidity. But in order to do that, we are lending USDT, but we need to have some proof that they need the assets even uh incoming on the swift network or on the balance sheet or in a bank account. So that's the why the KDLS uh is very important for us because we need to to prove without revealing any

sensitive data that the that specific company uh holds the money inside the bank account. So just for example, let's assume that there's a company that wants to send money money from Lagos and and we interact with a payment company. They will send 100 USDT then they will sell USDT to US dollars, right? So right now the the US dollars is trapped in a correspondent bank in the swift network or in some US bank. So but in the meanwhile the same company needs to send money to Brazil. So first we have this

mismatch uh windows time. Eventually Brazil is sleeping or the FX is market is closed and they need to to to have liquidity up front. So they call Mansa and the Mansa provide us and send the money up front but Mansa needs to have some guarantee that the the company has the money. So that's why and how Zikls help us because right now how this company do do right they they are sending PDFs uh spreadsheets uh screenshots whatever. So it's not reliable. It's not proofable and there's

zero cryptographic guarantees. Right? So and here's a a screenshot of a swift uh end to end track transaction reference. So and why we need transparency because liquidity providers they they need to make sure that the money is being used by in the terms like is a payment only. Uh they need to to have some guarantees about the default the full risks. So and also they need to to make sure that the money is being used for this specific corridor or this specific uh flow that we we are lending money we are

borrowing money for the liquidity provider and and lending money for the the the payment company. So and this is the one of the the the missing part that we have. So how can we prove for the liquidity providers and the public in general that we can use this money as a collateral. So and that's when why is it KLS of course because we have all the data flowing on chain we prove that uh via dashboards in doing or whatever but again we don't have this uh proof and this guarantee on chain that

the money that we are lending has a collateral offchain. So what we have done so we are using V layer and the the way that we are integrating with payment provider is we they have their API and they use our SDK and our SDK is using V layer on top of that. So the they connect with the bank API. So mostly all of those on ramp off for companies they have uh local rails. So they have access to the bank APIs. So but they need to prove us right now instead of sending spreadsheets or PDF

or screenshots they need to prove onchain that they have that the balance in their bank account or a swift track uh number or whatever. So then they they generate the xenon proof using uh valier and we are storing this zology proof either in IPFS and onchain. We also generate a etherization service uh to be very easy to to be verified. So they ser service points out the proof to IPFS and also onchain. So you can either either verify onchain or offchain. So

the flow is the bank API the the PSP app call the bank API using minus SDK then uh generate this zero knowledge proof but of course they can redact the other data because they could not reveal uh sensitive datas such as uh account number or the name of the company or uh the beneficial CR number or whatever. So then they push this data to the Monsa API and Monsa submit broadcast the transaction to the blockchain and also generates the attestation and also the

APFS to be verifiable offchain. So this is the the whole flow everything happens in the back end and and that's the way that uh we are doing right now. So just to show you a little bit how how easy is like to to build it. It's like one side we have the the solidities mask contract that will generate the proof and again we can easily uh parse the JSON uh in solidity and in the right side uh we can easily verify it and with the center. So I just have the amount and the PSP address. So

I don't need to reveal any sensitive information here and I can prove that the the money was the money came from the bank account. The money uh the PSP used the the right uh bank API URL and the TLS is is is the right one. Right. So and in the SDK side very very easy you just need to retrieve all information generator hash and using relay client just just call it improve it so let me go to the to the demo it's very

this is just a PC is not our our application just for you guys have some some idea. So here I have the three entities. One is the bank, another one is the payment company and the third one is Mansa. So the payment company needs to get access to the bank statement and prove to MASA they have uh they have assets there. So I went to the bank statement. So let's suppose that the bank provides the statement to the client and then the the PSP

he sees USDT and we go you do the the offramp and so they will sell USDT they will get back US dollars and put this US dollar in a bank account. So right now uh we are generating the zero knowledge proof. So from here you can see that we have the proof hash, we have the IPFS proof storage, the Ethereum service um pointing to the IPFS and I can also prove this transaction on chain force.

So this is the proof. [snorts] Now we can see the data station just having um the amount and the and the the address and the onchain verification and now I can verify. So and the verification as I said could be offchain or onchain. So I will verify and this is will become like a public goods everyone can verify this transaction and of course the liquid provider will verify. So now I can have all the the the the proofs on my side on Mona's side then I I'm avoiding manual warehores to receiving uh all those you

know PDF and screenshots. So the whole flow now uh will takes like under the one minute. So, and that's why that's how we can scale crossber payments because again under the hood behind the scenes there will be always a liquidity trap always you'll need to sell Argentina pesos to buy US dollars. You'll need to sell Brazilian high to buy US dollars. So, and you need to you you always have this connection with the banking rails. So that's that's the the the solution that we we came out. So and

let me go back to the presentation. Yes. So and that's it. 30 minutes. So guys feel free to to contact me after this uh presentation. Uh I'll be around. Please can uh send me a message on X on Telegram and follow M. Thank you.

Hey, uh, great talk. Um, I just have a small clarifying question on who's providing the zero knowledge proof of the like transactions correctness and stuff like is it some third party? Can they be trusted with sensitive information? >> That is a great question. um as a liquidity provider uh I have access to the payments uh service provider but I don't have access to their bank account. So in order to borrow money from from me they need to prove me they have uh the US dollars or the assets on their bank account. So the payment provider you

using our SDK they can generate this proof heat and just send to us the the zero knowledge proof and then we broadcast this proof onchain >> I I didn't >> the payment provider isn't getting any like extra information they wouldn't need all the information anyway, right? >> Exactly. Exactly. So is is their information.

>> Yeah. >> So they can or there are some situation that let's suppose they have many payments and they need to aggregate all the payments in just one zage proof. Uh they can do it. So I just need to know that they have the collateral. So I'm kind of tokenizing the collateral uh offchain and lending money up front on chain. >> Thank you. >> Thank you. Thanks for asking. >> I think we have one more 50 seconds issue.

Is there a privacy challenges with publishing it to EAS? >> Uh actually no because uh you you mean like for a decision? >> Yes. >> No because in I'm just saying that we have the zero knowledge proof. >> Okay. >> So there's many uh levels of the decision. We have to say the company, we have to say the transaction, we have to say the the he payments. So everything uh could be uh a test on chain. So >> okay, thank you so much. Uh coffee, your turn.

>> So thank you. Thank you. Bye-bye.