Introducing 0xramp: non-custodial ZEC ↔ local fiat (Pix and more) for emerging markets

Hello, Sewa!

First, thank you very much for battle-testing the app with your friend and for the thoughtful feedback that followed. This is super valuable for us, especially as we are still in the early days of developing 0xramp and improving it.

Second, while I appreciate the feedback, I would like to address some of the things you mentioned here for clarity.

0xramp requires no installation at all. It’s a web app.

Anyone (both of you included) can access it from any browser (Brave, Chrome, Safari, Firefox, etc), just like this forum. This not only facilitates access worldwide, but also makes it resistant to app store-level censorship, which is more common than most people think – especially for crypto and privacy apps.

Zingo is a wallet and it does require installation. It’s open-source and there is where the trust-layer leaves on. I understand that not many people care (or even understand) that, though. Hopefully, we all can work together to bring more education and foment adoption of freedom tools like those.

Can he elaborate on what was missing to give that confidence?

Maybe that’s something we can implement and use this feedback for constructive improvements.

Colombian payment terminology was a valuable feedback!

We will implement the fixes you suggested. That’s exactly why we need and appreciate local testings. There are many things that only locals can help us with and your participation here was fantastic for that. Thank you very much!

As far as I can see from the report, there were no real problems with the transaction status. The order-monitoring panel worked as it should and reflected the current status of the order the entire time. The only problem was the waiting period (~6-10 minutes), which is mostly due to (i) ZEC confirmation time, and (ii) the time for the P2P Colombian merchant to accept the order and send the payment after the ZEC confirmed.

Is this a correct understanding? If not, I’m not sure exactly what the problem with the transaction status was. I would appreciate it if you could elaborate on that.

The cancel + refund in USDC flow is a known friction point and we are working to improve that.

Thank you very much for pointing it in the report as well. Unfortunately, there is not much we can do because of our system being self-custodial (non-custodial). So, in some situations when the ZEC has already been swapped by USDC via NEAR Intents and the transaction is canceled on the P2P.me side, the refund is sent in USDC and only the user has the keys to move it again (which is why the system can’t send it to the Zcash wallet). Only a cancelation before the Zcash reaches NEAR Intents can be returned in ZEC. This is a deliberate security-focused architecture decision (self-custody).

That said, we are aware of that and researching solutions.

0xramp captures zero fees from the app. There is a small fee on the NEAR Intents side and most of the fees are actually paid to the P2P.me merchant, that is the swap’s counterpart (there is a small fee to P2P itself).

From my experience, these are significantly low fees for KYC-less, P2P transactions. I have seen fees averaging between 3% and 9% for these rails that preserves users’ privacy and freedom to transact.

Not sure where he would be able to get 0.9% fees from BTC. Maybe it’s from a CEX?
In this case there isn’t something we can compete with, really. Using P2P rails has this tradeoff (pros and cons).

This is one of our favorite use cases, indeed!

From my perspective, the best way for you to use 0xramp is not to send the cacao producer ZEC (if what he wants is fiat or bitcoin), but to use the app so you can spend Zcash while he receives the payment in the fiat he wants (or even BTC, via our swap function).


Once again, thank you very much for the experiment and thoughtful feedback!

Sincerely,

Vini B – 0xramp.app

1 Like