[Grant Request] Purple Pay

About PurplePay:

Purple pay is a regulatory-compliant privacy-enabled payment protocol to power borderless payments in emerging markets. Purple Pay’s tech infrastructure is built on privacy first (ZK snark technology) and follows AML region-specific (AML and KYC) guidelines. Our payment technology infrastructure has two critical components- ensuring regulatory compliance and enabling privacy. We conduct our compliance using ZK proofs to issue and verify claims and have a whitelisted shielded pool technology for obfuscated transactions. Polygon POS Blockchain will become the infrastructure layer for the stack.


To create a new use case for the 0x engine in the form of payment processor and enable atomic swaps for merchants using the Purple Pay API. Today the 0X API’s are majorly used for swaps which is a big use case in DeFi. However, we want to increase the use cases of the aggregator and use it to function as an atomic swap provider to enable the receiver of crypto the choice to receive the crypto of his choice irrespective of the crypto they are paid in.

  1. To be used to enable atomic swaps under the hood: We will be using the 0x API’s to enable atomic swaps which will function to swap crypto’s under the hood to enable crypto payment of choice.

  2. To be used for private transactions: Another feature of purple pay would be to enable private transactions via a pool service which will also utilize the 0x API’s to function.

  3. To enable more liquidity and swaps through 0x API: By using PurplePay with 0xAPI, we would be able to increase the volume and number of trades happening through the aggregator.

The Polygon ecosystem is already emerging as a payment hub and using the 0x aggregator API’s we want to increase the adoption of the payment services enabled on the platform.

Application Questions:

1. What category best describes your grant request?

The grant application captures multiple categories including use of 0x orderbook, polygon deployment, and a new use case being built on top of 0xAPI’s. You can read more about this in the proposal details explained earlier.

2. Grant amount requested?

The grant amount we requested is $40K.

3. Point of contact?

Saumya Saxena, Co-Founder, PurplePay (Twitter :slight_smile:

4. Team Background


(i). Arunank: . Having worked in early-stage teams (Unacademy, Skillate, Jio-AICOE) throughout his career, he has extensive experience in building global award-winning products. He has been teaching and training 300+ students to get into Data Science and Analytics.
(ii). Swarnava Bhattacharya- Swarnava is an ex-founder with over 5 years of experience in product management. He’s led teams at India’s high-growth startup Udaan and was leading Leap wallet’s cosmos initiative.
(iii). Abhishek Kumar- Abhishek has a background in frontend and smart contract development. He’s worked with cross-chain bridge aggregator LiFi and Zomentum. He’s also built several web3 products that have received critical acclaim from the tech community.


(iv). Shaunak Kamalapur- Software engineer turned designer with experience in branding and UX/UI. Shaunak has worked closely with DAOs to build and design web3 projects.


(v). Saumya Saxena: Saumya has more than 10 years of experience in financial consulting, investment banking, and strategy for large institutions. He’s worked with S&P Global, KPMG, and LGT and was a founder in residence at Antler. He’s led and managed large teams and operated in South East Asia, Africa, US, and UK geographies.

(vi). Ishika Mukerji - Previously worked at Hulu/Disney streaming as a product manager intern, she also has as worked at 3 startups in a product and growth role shipping products.


(vii). Aishwary Gupta- Aishwary Gupta is the Chief of Staff at Polygon DeFi. He has immense experience in building DeFi/FinTech projects and serves as an advisor to a lot of web3 projects.
(viii). Jamal Raees- Jamal is the head of strategy at Wyre and has extensive experience in the payments space. He’s an advisor to large crypto projects such as Limewire, Square, Block studios. He was also the global BD head for Bitpay.

5. Project Background:

Purple pay is a regulatory-compliant privacy-enabled payment protocol to power borderless payments in emerging markets. Purple Pay’s tech infrastructure is built on privacy first (ZK snark technology) and follows AML region specific (AML and KYC) guidelines.

6. Description of the work to be funded with its breakdown?

The funds requested will have the following breakdown:

Product Development: A sum of $25k to be requested for the product development and to enable integrations with 0x to ensure all the swapping and atomic swaps run seamlessly on 0x engine.

Bootstrap Protocol: A sum of $15k to incentivise the use of Purple Pay. If protocols enable PurplePay as payment platform we incentivise them to bootstrap the use case.

7. Benefit to the 0x Ecosystem:

The proposal is immensely beneficial to the 0x ecosystem. Below points outline those benefits:

  1. Creation of a new use case: 0x API’s have never been used in the payments business. This is going to be the first of many protocols which will use 0xAPI for their payment infrastructure. Payments is one of the booming use case in the Web3 space.

  2. Increase in the total user base using the 0x ecosystem: Through the use of the 0x API infra, on Purple pay, it will bring an influx of new usebase and also volumes which will swap and generate revenue for the protocol.

  3. Increasing the 0x awareness by using it in marketing material along with Purple Pay marketing.

  4. The team will commit to using 0x Protocol as the settlement layer and ensure that unless there is an operational challenge it will continue to grow the 0x ecosystem.

8. Conclusion:

While the 0x API system is powering the swap use case of DeFi and is one of the biggest aggregator on Polygon, we want to enhance its use case and create a new use case which not only enables the existing infrastructure to be used in yet another way with no technical overhaul but all brings volume and user base which will be able to increase the revenue of the protocol.


I think this proposal for 0x Ecosystem is amazing! With PurplePay and 0x API’s, people can choose the crypto they want to receive when making a payment.

Also, the use of PurplePay with 0x API’s can increase the number of trades happening on the platform. This means more liquidity and more options for people to make trades. Overall, this proposal is a win-win for both 0x and its users.


A regulatory-compliant privacy-enabled payment protocol is exactly what the ecosystem needs right now. It will help onboard the next set of users while also speeding up the process of cross-border payments.

By making use of 0x’s API to enable atomic swaps, Purple pay will reduce the step of swapping tokens after receiving payments. This is extremely useful for non-web3 natives.

Overall, this project deserves the grant as they’re building for scale from the very beginning.


Look forward to Purple Pay!

I believe crypto will form the rails for payments worldwide in the next few years and Purple Pay can enable this future.

Purple Pay will be a massive addition to the 0x ecosystem as it will increase the use cases of the aggregator. The ability for a payment receiver to receive the token of their choice irrespective of the token they are paid in is also a huge UI improvement in the crypto payments ecosystem.

Would really like to see Purple Pay get this grant and jumpstart the future of crypto payments.

1 Like

I have been working with Global clients for my design work for years, and the biggest pain I have after getting them to pay is getting paid, So many problems, so many huddles and charges.

But Purple pay sounds like a breeze, Use blockchain to solve this, Amazing!!

1 Like

It’s long overdue that somebody started working not just on technology innovation in the web3 payments space but also made sure it was compliant across geographies.

I believe Purple Pay is the need of the hour precisely because it is prioritizing both of them equally. If this works, its only a matter of time before adoption reaches critical mass. Looking forward to seeing Purple Pay make that happen!

1 Like

There are very few who are focused on solving & thinking about UX for crypto payments along with making sure it’s compliant across different geographies.

The complex layers that exists today on top of a transaction needed to be solved at the core before casual audience understand things. Brining in 0x API’s into PurplePay moves lot of functions into the back hood that casual audience don’t have to worry about + serves the purpose.

1 Like


First of all thank you for considering 0x protocol for your project :raised_hands:

This an interesting use-case, so I’m curious to get a bit more details on how it works. I’ve read the product documentation but it seems still a work in progress so I’ll try to list here all the questions I have left.

  • Could you elaborate on how the privacy feature will work? especially how will it be using 0x as at the current time 0x protocol is not available on a zk evm network

  • The documentation only shows crypto-crypto payment use-cases. Is there plans for fiat on-ramps? what KYC/AML are used for?

  • Do you have estimations of swap volume that will go through 0x?

  • Could you please include a more detailed development cost (maybe an estimation of number of hours)?

To be honest $25K for integrating an external api seems excessive, as there is no server costs that comes with it. And the api already has a pretty extensive toolkit used by many integrators and that make it really easy to setup

Also I think grants are not meant for financing marketing campaigns or product adoption incentives, so the bootstrap protocol section may have negative effect on the grant attribution


The overall proposal seems a good fit for the protocol, but better breakdown of where the development expenses will be could help us decide better on the proposal.

  1. Increase in the total user base using the 0x ecosystem: Through the use of the 0x API infra, on Purple pay, it will bring an influx of new usebase and also volumes which will swap and generate revenue for the protocol.

Do you have some rough numbers for this? What will be the expected volume having this solution available

  1. To be used to enable atomic swaps under the hood: We will be using the 0x API’s to enable atomic swaps which will function to swap crypto’s under the hood to enable crypto payment of choice.

If you are using Polygon Pos what you mean by atomic swap? Are you doing BTC to Polygon?

Btw, Is this implementation open source?

1 Like

Thanks for the questions! We’re quite excited about building it. The product documentation, as you said, is a work in progress and we should have it cleaned up in the coming week.

On the privacy feature piece, we are evaluating partnerships with railgun and zkBob through which we help us with these kinds of transactions. This will enable us to go ahead and create private transactions on public chains. Another approach we’re evaluating is creating our own whitelisted sharding pool for these transactions.

Yes, we are currently in conversations with multiple on and off-ramps. Transak, Wyre, Onmeta, Onramp.money and even aggregators like magik labs. These integrations will allow us to service multiple geographies and reduce dependencies on a single player.

Once fully up and running, we are closing down on multiple merchants which can enable us to do swap volumes of over a million per day by the end of Q4.

The aim for the grant of 25K is to be used to not only integrate the APIs but to work on creating multiple integrations. We essentially see 0x as the settlement layer and based on our conversations with several merchants, these integrations make us much superior payment product.

We have multiple other integrations like cross-chain swaps, while settling things on the Polygon chain over 0x. Hence the ask. If we ask for an estimated drawdown of hours that would be put in, it would be around 200 hours for 3 devs at 40$. If you’d like a further breakdown I’m more than happy to help on that.

So the bootstrap aspect has two parts:

  1. To incentivize the adoption of the protocol which we are seeing as one of the necessary steps to get more volume and acquire more customers. We chose to do this, instead of marketing campaigns since we wanted to give benefits directly to people helping with adoption.

  2. The second aspect is to host a co-branded hackathon. Per our analysis, we have seen tremendous growth in Polygon owing to their hackathons right from the start of the protocol and we are planning to use the same hack. This hackathon could bring in more ideas and use cases on the application layer of the product.

Hope this brings some more clarity to our thought process. Happy to chat in more detail if you’ve further questions.

1 Like

Hello @saxenasaheb :wave:

  1. Can you elaborate a bit more on how you see the role of the 0x orderbook in the payments use case?

  2. Can you please explain in more detail where/how 0x API would be integrated in the payments workflow?

  3. If you are in discussion with payments gateways/networks and fiat on/off ramps, are you aware of any compliance requirements that could potentially impact 0x Protocol or 0x API as an up/downstream “service provider”?

1 Like

Thanks for the questions! Nikita. Here are my thoughts on them-

On 1 and 2, the use of 0x’s orderbook is two-fold-
a. Customer- It allows consumers of our merchants to seamlessly pay in different cryptocurrencies at the checkout layer
b. Merchant- It allows merchants to collect in the cryptocurrency of their choice

So essentially from a payment flow pov, we give the flexibility to the consumer to pay in their choice of token (through 0x APIs) and the merchant to collect in his choice of token.
The first piece happens at the checkout option on the merchant’s site, the later happens automatically based on the preferences the merchant has set up in the dashboard.

  1. We are in talks with several fiat on/off ramps (Transak, Wyre, Magik Labs, Onramp.money) and compliance requirements are at the consumer and the merchant level (KYC/KYB).

Hope this answers your questions.

I’m trying to understand whether you are using the term “0x orderbook” generically as a term that is interchangeable with 0x API, rather than referring to resting limit orders? Because if you do actually mean resting limit orders, I’m still not clear on how this would work in a payments use case. My takeaway from your answer is that you will be using 0x API (for swaps), but will not be using orderbook (for limit orders) – is that correct?

For the compliance question, does this mean that the products you are working with don’t require e2e compliance for service providers in the solution stack? I am asking because we would want to avoid a situation where at some point we are informed that 0x technology can’t be used in your solution for some compliance reason after funding was provided.

1 Like

Hi Nikita, thanks for the follow up questions. Here is our response:

  1. The 0x API and the orderbook has different use cases. Initially we will be picking up 0x API’s for the swaps to enable merchants/dApps to accept crypto of their choice irrespective of the payment crypto used by the user to make the trade. This is something which Uniswap enabled in their NFT purchases.

  2. The limit orderbook will be used in another product offering which would be developed as soon as we start to pick volume. The limit orderbook will be used to enable merchants to set an auto-converter in case when there are large swap volumes and merchants/dApps want to setup specific values while making swaps, and till these values are not achieved it will be put out as a limit order. An example of this could be when merchant/dapp has a specific rate in mind to do the swaps and hence will be using the orderbook.

As far as the complinace pience is concerned, when the money is moved, we will be using products like Chainalaysis or TRM Labs to ensure that the funds are passing the checks and the fund moment is not happening to OFAC sanctioned countries. Apart from that all the merchants onboarding will pass through a KYB/KYC to ensure that we are complying with all the rules. We are evaluating protocols like synaps and polygon ID to ensure all the fund movements are within the regulatory compliance. Hence we do not see a situation where we will have to forego the 0x technology due to compliance reasons.

ok thx for clarifying!

1 Like

Hi, so to be clear on this answer. Is the grant requested 25K or the 40K?

Can you provide the breakdown?

1 Like

Hey Joao, thanks for your question.

The breakdown remains the same.

The grant request is of 40K, divided into 25K for development of the product and the balance to help around kickstarting the protocol with activities like hackathons, kickstart liqudity and also marketing activities around it.


Thanks for the detailed explanations

My general feeling is that you need a lot more than the provided estimate to build the described product, which raises the question of how do you plan to fund that on the long run and make sure to deliver at least a usable MVP?

Given that observation it seems too early to decide on funding marketing/hackathon efforts. I think the community will always be open for other grant proposals once you have a working product

That said I don’t think we have clear rules regarding the purpose of the grants. The rule I mentioned was drawn from what we practiced as part of the 0xEVE grant scheme (which is out of scope here)

Overall and given the requested amount, I’m leaning toward voting for this grant. The main reason is the novelty of the use-case in regards to using 0x protocol

Thanks for the question and your faith to vote for us. As far as the costs are included, we are also bootstrapping some expenses and conversing with VC’s to do a small raise. We have already completed the tech work to some extent (the basic SDK being tested) and with this funding we are more than sure to be able to complete the integrations.

The marketing expense is poised to get the word out on the protocol and we can take it as a milestone product once the tech work is done.

I agree with @0xSHA I believe the marketing efforts will be done after the product done right? So I think is better separate that on two grants.

I believe as well a breakdown detailing each step of development and partial deliveries should be made, and detail each grant allocation for it. I am still trying to understand which custom solutions will be made for 0x API, are you guys planned to run your own instance with some customizations done on the API @saxenasaheb ?

1 Like