[Grant Request] Alcancía

GRANT REQUEST: Alcancía - Be your own bank for Latin Americans

Basic Details

Project name: Alcancía (Piggy Bank in Spanish)

Point of contact: juandi@alcancia.io, @jewandidi on Telegram, Juandi#0382 on Discord.

Team background:

Experience from NGOs (UNESCO), Startup Impact Accelerators (Unreasonable México), National Reserve Bank Hedge Funds (AFI Reservas) from the Dominican Republic and Fortune 500 companies like Oracle and Microsoft.

Co-Founders LinkedIn(s):
Juan Diego Oliva
Juan David Torres
Guelmy Salcedo

Other sources of funding and approximate amounts (grants, VC, etc.):

$120,000 USD. $60,000 USD in grants from Celo (Prezenti), Aave Grants DAO, Compound Grants Program, and Push Protocol. $60,000 USD from three Angel Investors (Julio de la Cruz, Salvador Ciccone, and Daniel Navarro - he did the first digital wallet in the Middle East)

Project Details

Describe the problem being solved:

We are looking to use the current 0x documentation to implement unwrapping of rebase tokens for our new debit card integration. Alcancía is currently on the final talks with institutions that sponsor BIN (Bank Identification Numbers) to open our own non-custodial debit card business model for our users and letting us earn a revenue from the Mastercard/VISA payments processor stream. Currently both Mastercard and Visa settle payments in USDC but do not settle payments in cUSD or rebasing tokens. Our proposal is to unwrap the token using the 0x swap so that under the hood the end currency will be USDC and the non-custodial debit card business model is seamless and functional while our users can still save and earn using their favorite protocols.

Explain how the funding will be used:

  • $28,000 USD will go towards development overhead during the next three month sprint. Expected to complete this grant proposal by August 2023.
  • $7,000 USD will go towards promotion efforts of our new debit card.

Indicate whether your solution/product will integrate directly with the 0x Protocol contracts (such as the 0x Exchange Proxy) or via APIs. If APIs, please list them (if known):

Most of our integration will be done through the exchange proxy as our router technology currently uses a swap from USDC to aPolUSDC (Aave interest bearing USDC on Polygon) and cUSD (Celo Dollar) to mcUSD (Moola Interest Bearing Celo Dollar). This exchange proxy will unwrap the token once received in our settlement address with Mastercard so we can pay for users debited balance when they make an expense on their debit cards. Currently our technology is built with Matcha but we are looking to make everything in-house with the 0x documentation (included a diagram of how it works below)

List any critical milestones and dependencies (if applicable):

This is a disbursement schedule and/or milestone funding program.

Describe how the solution/product benefits the 0x Protocol Ecosystem:

New use case that makes the viability of non-custodial wallets and debit card integrations with the real world cost-effective and scalable.

Do you agree to tag your solution/product for visibility in [0x Explorer]
We agree to tag it in the 0x Explorer plus keeping all of our repositories open-source.

What are the actual and/or target usage metrics (such as users and volume) for your solution/product:

Currently we have 203 registered users with $11,000 USD in assets under management. By the month of June we are onboarding businesses which will move quantities more than $5,000 a month between DeFi protocols such as Compound and Aave. Currently we have closed a total of 4 B2B customers. Our target by the end of October is onboarding a total of 5,000 consumer-based users into the application with an average deposit of $40 USD a month and 30 businesses with a moving average of $5k USD a month into the wallet and protocols. Helping us reach our breakeven point.

Provide links to any of the following for the project (if available):
Demo: Alcancia Demo - March 2023 - YouTube, https://play.google.com/store/apps/details?id=io.alcancia.alcancia&pli=1
Website: https://landing.alcancia.io/
Twitter: https://twitter.com/Alcancia_io
Discord/Discourse/Community: N/A
Github: Alcancía · GitHub

Funding Request

Grant amount requested (in fiat): $35,000 USD

Grant amount by token (ratio of tokens): 155,555.55 ZRX tokens as of 15/5/2023 at a $0.225 USD price per ZRX token. We can happily take a full disbursement in ZRX or a 50:50 disbursement between fiat/stables and ZRX.

Receiving address and chain: 0x86792D8d875a06ccC787096304647aA98C5FB9Bb

1 Like

Hi :wave:

Very interesting proposal, a few questions come to my mind regarding the 0x integration bit.

  • Is the Alcancía team committing to exclusively using 0x for the swap to USD, or are they exploring other protocols as well?

  • Can you elaborate on the “exchange proxy” you mentioned and how it integrates with the 0x protocol? Are you going to be using the 0x API as a taker or are you going to be putting up limit orders?

  • Are there any potential legal or regulatory challenges for launching a non-custodial debit card business model, especially for Latin Americans?

1 Like

Hi Acilia!

  • For now we are going to use 0x for the swap functionality. It is the most straight forward option to redeem/unwrap rebasing tokens from top DeFi protocols. Especially Aave and Moola Market which is where our integrations are done right now.

  • Basically it the exchange proxy will use the 0x router to find the fastest and cheapest swap from the rebase token to the settlement token (USDC) we don’t really put out limit orders as the conversion is mostly 1:1 because it swaps directly from the Aave pool and the Moola Market conversion from cUSD to USDC is cheap due to partnerships with bridges and swaps like Curve and Axelar to convert the cUSD into USDC. (Edited here because it is indeed using the taker model in 0x, this can clear the answer a bit more.)

  • Yes! And I am glad you ask this. Currently our legal infrastructure lets us buy and sell digital assets in Mexico and the Dominican Republic. We have legal clearance from authorities as long as we get audited in our KYC processes more or less every 6 months. There are already startups who use custodian methods and approve debit cards using crypto such as Lemon, DolarApp or Belo but they still depend on centralized institutions to be able to access yield. At Alcancía we did direct integrations and found the way to make it scalable :slight_smile:

P.S. for legal infrastructure we count with a Delaware C-Corp for investment. SAPI de CV in Mexico for operations, LLC in the Dominican Republic for operations and with a Lithuanian Holding Company to later acquire our VASP License (same that Binance and other exchanges use) so we can have a better legal framework to stick to while LATAM gets straight with regulations. But as long as we complete successfully our audit process and pay our taxes both the Mexican and Dominican authorities are pretty straightforward with it.


Could you please clarify how the swap transaction is built? do you rely on 0x Swap API (by 0xLabs) or you build the swap/unwrap transaction yourself and directly interact with 0x proxy?

If the only use case is unwrapping tokens where ratio is always 1:1, why do you need 0x aggregation? If my understanding is not wrong this would make a big overhead for no clear benefit

Also you mention that some cases might use limit orders, this is also not clear to me. Limit orders have no guarantee on execution, basically depends on market makers and if they can extract profit from the order. Also they might only be viable for medium to big value trades


Hi 0xSHA (first of all nice peng)! We currently use the same 0x Swap API as Suarmi (the grant proposal you also gave comments on in the forum, send my regards to Cuau the founder if you manage to speak to him hahaha)

We have not mentioned the case to use limit orders, maybe you touched with Acilia’s post but it is not in our roadmap to implement limit orders. Our swap is viable for medium to big value trades because the card settlement for user is sent from the provider (in this case VISA or Mastercard once a day).

Let me see if I can detail a bit more, for this example we will be using Aave Polygon USDC (aPolUSDC):

  1. User wants to buy something using his card, he passes it through the payment system.
  2. Card Provider sends a request to see if that Alcancía user has the balance in his wallet or in our system.
  3. If he/she has the balance the transaction passes, if not it gets declined.
  4. When the transaction passes, Alcancía takes the amount paid in aPolUSDC from every user that makes a card payment, purchase or transaction and once a day makes a big swap in the Polygon and Celo blockchains to USDC and settles the card statements sent by the provider in the same day.

Instead of a debit card see it more as a pre-approved credit card. Indeed the 0x swap API is pretty straightforward but it manages to create some valuable use case towards settling IRL payments with a non-custodial wallet.

In terms of sustainability, we make a 1.5% of every purchase an user makes using the card. So we know that this is economically viable with unit economic calculations we did for this.

I am more than willing to keep this grill session running. This is honestly one of the best questions right now we’ve received about our integration.

1 Like

Hey @Juandi

Nice to meet you, thanks for coming to the protocol.

I’ll start by saying I generally don’t think Grant programs should pay for marketing a team’s product unless it directly generates revenue for the protocol.

How has your Grants so far from Aave, Compound, and Celo helped you reached your goal?

What is different about this request and its size? Why 0x?

Seems like this single ask is 3x the average size of your past grants at $12,000 each.

Hey fig. First of all let me tell you that I love the devil’s advocate role you play in the grants forum discussions, also happy that you followed-up the conversation here.

For the marketing budget we always put it in a grant proposal but it almost never passes and the cost is reduced. Is this proposal something you will support if we remove the $7k USD proposed in user-acquisition and promotion efforts? (we would be more than happy to cover this cost ourselves)

Grants from the previously mentioned protocols have enabled us to keep improving the product with access to constant mentorship, contacts and of course the commodity of capital. Those grants have helped us release our wallet into the market, create the technological base for the first cash-to-crypto bridge in the region (special shoutout to the Celo Prezenti team for this) and helped us spread the word around to reach the 200 user milestone in less than 2 weeks of launch with no investment at all in marketing, all has been done by pure word of mouth from the respective grant programs.

Will like to state that the average grant size is actually $19,000 USD rather than the $12,000 USD previously mentioned. This grant size for now a total of $28,000 USD is ±30% bigger than the average due to the development from both ends with Bank Identification Numbers, Debit Card launch and a swap bridge from rebasing tokens to USDC as settlement payment for the users debit cards.

Startups in LATAM that use crypto as settlement services like Lemon and Belo use custodian services to settle payments with their respective debit cards. This is easier in terms of scalability but harder when they have a bug amount of Assets Under Management invested in crypto because they depend on Centralized Exchanges to generate yield (the most common case in the LATAM region being Nexo Earn).

At Alcancía we are developing non-custodial wallets and integrations to DeFi (we never touch your capital that generates yield) and currently building the debit card feature with a complete non-custodial platform is something that has never been seen in the region. We decided to use the 0x tech stack to ease the process of swapping rebasing tokens into one we can use for settlements without compromising user custodianship.

The grant is bigger than those we have previously requested but we have the track record of making product that really creates impact and use-cases for the region – If need can also ping a message to the respective domain allocators of the previous mentioned grant programs to vouch for Alcancía. If you want to further chat about this please feel free to ask any other questions and suggestions about how we can further land this proposal.


hey @Juandi grants for plain vanilla 0x API integrations are generally not seen as bringing a lot of value/innovation, therefore there is currently a broader discussion whether they should be sponsored at all. Also, the 0x API are the best dex aggregator API out there imo in terms of API quality and ease of integration, so it should be pretty logical for a project to using them regardless of grant support from this treasury. Also the time for going from idea to full 0x API integration are very short, so the integration cost is not justified imo.

Can you please give a bit more context, should I be missing something here? You are planning on using the 0x exchange proxy for settlement, correct? If confirmed, you will have the extra benefit of now having to maintain a smart contract router?

Hey Gabriele,

Thank you for taking your time to answer this forum proposal. I understand your concern about using 0x API in its most rudimentary way to ‘innovate’ and make it a potential fit inside the 0xEVE/Grants Program. Still, I believe you’re missing on the bigger picture which is stated in the 0xEVE forum post “A proposal to establish the 0x Ecosystem Value Experiment (0xEVE) was passed in early June with a budget of 400K ZRX, which was then transferred to the 0xEVE multisig to fund operations. Shortly afterwards, 0xLabs and 0xPolygon allocated 3.3M ZRX and 4.2M MATIC to the 0xDAO Treasury with the shared goal of bringing 1M new users to the Polygon Network via 0x-powered applications.”

Our product is focused on two crucial verticals to onboard Latin Americans:

  • The ability to onramp using a low-spread bank deposit using the national deposit system called SPEI. We got greenlighted for this by making a partnership with the biggest bank in Mexico (Banco BBVA).

  • Using Banco BBVA’s infrastructure we are releasing a new cash-to-crypto product where people can go inside convenience stores such as 7-11 to onboard themselves using physical mexican pesos and receiving USDC/cUSD generating yield on DeFi (receive the rebasing token).

Aside from this two developed initiatives already funded respectively by Aave and Celo. We are moving towards the hot trend of providing a way for people to actually use their stablecoins that rebase yield with a debit card, provided through a BIN (Bank Identification Number) sponsorship provided by VISA. This has been a killer-use case in Argentina where using stablecoins as a settlement mechanism with a card provider has onboarded more than 1.8M users in less than a year (keep in mind that the Total Addressable Market for this is 200M people and >$300B USD stuck in traditional savings accounts.).

Although the 0x technology we want to implement is rather basic, the development team will be working on two ends. The endpoint where we have to integrate VISA’s settlement infrastructure into our 100% non-custodial wallet repository (which is going to be one of the hardest tasks, one never before seen in the industry because it has always been developed using Centralized Exchanges/Custodians) and also working on the 0x integration that swaps the rebase token to a settlement token such as USDC without the user needing to sign for gas (for this we are developing a relayer using metatransactions that sponsors the gas for all of Alcancía’s users).

We are believers of core technology, but personally, I have to differ here that to fit to be part of the 0xEVE/Grants Program we have to dig deeper into the technology. This has been a proven mechanism to onboard the next million users into not only crypto, but both Polygon and 0x dApps and we stand by the decision of keeping it simple and stupid.

If you think there is a better way to implement this that can help us scale and dig deeper into the 0x tech stack and documentation, the team is more than willing to hear you out and pivot the integration strategy if it fits into the development roadmap.

Thanks for your post here @Juandi and all your work in the Celo ecosystem. Some exciting developments on your end!

Some questions here:

  1. Could you clarify why 0x is needed? On the Celo side, this would all be on Ubeswap correct since it’s only a single swap from mcUSD? And I imagine similar on Polygon where this could be done on a single exchange where you would look at the most liquid one.
  2. On Polygon you can swap from aPolUSDC to USDC. On Celo would this be from mcUSD to cUSD? Or are you swapping mcUSD to cUSD, then swapping cUSD to Wormhole-wrapped USDC or axlUSDC (Uniswap/Curve), and then bridging this to Ethereum? Just wondering how you would do this since on Celo, you would then either need to do a separate integration with Wormhole or Squid Router on Axelar and the 0x part here becomes a bit less relevant.
  3. Could you provide a bit more context on why $28K is needed for the integration? My understanding here is that this would be a 0x API integration which would involve much smaller grant size, but I could be missing something.


Hello Nikhil @nraghuveera, pleasure speaking with you again!

  1. 0x is needed to find the fastest and cheapest swap between rebasing tokens and its native token (aPolUSDC → USDC in the case of Polygon) for Celo we actually use Matcha to convert cUSD into mcUSD as it has the same stack used for 0x, just that Matcha is easily available for the Celo blockchain. We used Ubeswap at first but decided to just use 0x-related tech to make it easier for the development team who had a hard learning curve on web3/crypto topics. The good thing about Moola is that because of it being an Aave fork then it follows the same principles of its rebasing tokens (which was a dope find because we never knew, made our integration with Celo faster).

  2. We would actually bridge this to the Polygon network using the Squid Router (which we already use it for payroll when we have cUSD in our treasury). Actually 0x would still be relevant because we can use the technology to unwrap the cUSD from Moola and later bridge it to settle our payments with the provider, the technology would be the same just with an extra step in between that we already have implemented in our company processes (we do it in the most manual form possible but it has currently worked for us… Is there any documentation you can guide us to make our Squid Router process automatic and make it available in our repo? - Would help out a ton some guidance on your end)

  3. As mentioned in previous replies. We would not only be working with the 0x integration. This is literally a new use-case where we are going to connect the whole Alcancía repository followed by an 0x integration that settles the payments of users debit cards directly with VISA (how cool is that? We can finally spend our cUSD or USDC like if it was a normal bank account). It is going to be an integration effort of around 3-4 months to pull this off. The $28k USD is based on the runway we use for development costs of new products and building new integrations. For what we have seen this is going to be harder than both our Aave and Celo integrations where we actually raised $42k total from the respective community funds/grant DAOs.

In conclusion, this is an experiment that we are running at cost. Which we believe is going to change the wallet thesis for the region. With the track record that we have shown with little capital this is something that we can pull off and add to the history of connecting TradFi financial products to the tech stack that makes DeFi and DEXs run. (On a personal note, I see it as art haha)

The conversation so far appears to indicate that an integration with the 0x Swap API should be more than sufficient for the type of swaps and workflow described. Integration should be fairly straightforward, and it is my understanding that in addition to recently updating the API documentation, 0x also provides direct support for integrators using their API at dashboard.0x.org. Generally, this type of integration would be considered for a grant of around $5k.

Hey @nikita Nikita. Thanks for following up yet again.

I understand that the grants committee is focusing on small yet impactful investments to bring the next million users. Due to community feedback I believe that setting of a right precedent and relationship with 0x should be the right step to funding bigger projects in Alcancía and earning our wings with the protocol and governance.

Do you think that an integration with a $5K grant target will be good to set off in the right footing followed by support from the respective 0x governance team so we can further grow our project? If so, what support does the treasury/governance team aside from capital provide? This would be cool to know in the sense of support from the team at 0x.

We think that we can start doing the rebase swap with the 0x tech stack and then start working on more complex things, still I am looking to get the right amount of feedback to push this forward and let us show you that Alcancía can hold its ground :slight_smile:


The protocol is currently in a transition period for governance and the treasury that will take some time to play out, so it is hard to give specifics regarding other types of support that might be available down the road. However, if you do integrate the 0x API, one thing I might suggest is contacting the 0x team (link) to inquire about their ‘Powered by 0x’ series on youtube and ‘Powered by 0x’ section on the 0x blog in the content hub.

Thanks @Juandi. Quick question on this. If you’re already using Squid for the cross-chain component, what would be the reason for a 0x grant as well? Squid also functions as a router to go from mcUSD → cUSD → axlUSDC → Polygon and I believe uses the same pathways as what 0x would use. I’m asking because this would overall reduce the use of 0x from your grant request, since Squid would end up being potentially the primary router.