Payments: In-App Banking Component with API

New proposal

In-App Banking Module

*Banking module that includes balances, p2p transfers, statements and payments. *

Project Description

The argument for cutting international transaction fees is pretty compelling. However, it’s even more compelling if you provide a means of balancing accounts in your dapp that doesn’t require going back and forth and saves gas fees. The Math here needs to be spotless and the calculations efficient, so we proposed a component that could live within the app and be interacted with via API like a Payments Gateway. It would provide a range of methods, from simple payments to recurring payments to interest rates, borrowing and other bank-like services.

Value proposition

The component is designed to be used in every marketplace, loyalty program and other user-based systems that need account balancing, cashouts and withdrawals.

How you will use Cartesi, specifically?

We will use SQLite and develop the code on the VM as an installable component with an API. You will be able to interact with the component via calls and develop your Dapp around it if you don’t want to use the source code.


Milestone 1: ERD Design and API design

  • Duration: [1 month]

  • Deliverables:

  1. Database Design,
  2. Complete list of methods
  3. Architecture and Documentation with Use Cases
  • Funds request (USD) for milestone 1: 3 300 USD [60H x 55USD]

Milestone 2: Software Development - Business Logic

  • Duration: [3 months]

  • Deliverables:

  1. Working ledger,
  2. Guides, how-tos
  3. Testing Report, with all test cases
  4. Example dapp with running source code
  • Funds request (USD) for milestone 2: 13 200 USD [240H x 55USD]

Milestone 3: Source Code as Component

  • Duration: [1 month]

  • Deliverables:

  1. Guides on how to use the component
  2. Component Development Guidelines - Proposal for community
  • Funds request (USD) for milestone 3: 4 400 USD [80H x 55USD]

Total funds requested

$20 900 USD

Use of funds (specific breakdown):

  • Design and Documentation: 60H, 3 300 USD
  • Software Development: 240H, 13 200 USD
  • Testing, Examples & Deployment: 80H, 4 400 USD

About your Team

Jakub Olech - Senior Developer/Business Analyst
Dawid Mazur - Software Developer
Maksymilian Zięba - Software Developer

Relevant Experience

Links and resources


ERC-20 Payee address

ERC-20 address: 0xcc425d2f6900d6538cdac895896f2ef2a8c53d1f

NOTE: Designed to be compatible with User Authentication Bridge if funds are granted:


Thank you for the proposal, we will review and invite others to give their feedback.

1 Like

One aspect that is important to consider during development is the possibility of attacks using recurring transactions.

Imagine if Bob creates a large number of recurring transactions of one wei to Alice (as frequently as possible). These will have to be processed regularly and may overwhelm the system.

Some mechanism to limit this type of attacks should be in place. Also other features may be susceptible to similar vulnerabilities.

1 Like

@Augusto thank you for your input! That’s a valid point. If this gets funded we’ll propose some security measures to be introduced and discuss it with the community. Any other concerns/suggestions?

1 Like

This is an interesting proposal!

I think an easy to use payment system that could be included on DApp’s without too much hassle would be super helpful for developers.

I like the list of deliverables, especially the example DApp exercising the features. But I’m missing a little bit more specificity in what this payment module will implement.

Can you add a list of what you’re gonna implement for sure and what are the things that you’ll study if its possible to implement?

Say something like:
Will definitely implement simple and recurring payments, lending, auctions
Will study how to implement: batched payments, dividends paying etc
(these are just examples)

I’d also like to know what types of assets you’re thinking of supporting. And it would be good if the proposal could list some basic use cases. I know those are all promised on the milestone 1, but I think at least a more specific sneak peek would be important for us to evaluate the proposal.

Adding a deliverable on security considerations might be interesting too, like Augusto suggested.

Last question, on the last Milestone (3), what does this mean:

  1. Component Development Guidelines - Proposal for community



Hey there, I have to second Felipe on his comments. It seems like it has the potential to be a neat implementation, but I couldn’t find any explicit mention of how it contributes to community-led development or brings value to the broader Cartesi developer ecosystem by means of delivering reusable modules and the like.

From what I gathered, the project seems to be more focused on a DApp implementation for a specific use case, rather than being a widely applicable tool, reusable infrastructure, or a DApp component. This might go beyond the scope of the Community Grants Program, which typically supports projects aligned with its mandate, but on the other hand, if you can give more details as Felipe has asked, it could have the potential to align.

Thank you!

In addition to the requests above, would you be able to add to your proposal a couple of paragraphs explaining how the module works with an imaginary DApp that would benefit from it?

It would help us to understand the features and interactions with the system.
Perhaps a sequence diagram showing the interactions involving users, DApp, banking module, and the blockchain will be handy.

Hello there! I believe the idea of the proposal makes total sense: many financial DApps could benefit from a reusable module that reliably implements common procedures like recurring payments, interest rates and lending services!

In this context, I believe it is of paramount importance to choose one or two concrete simple use cases to guide you and help define in detail what a minimum implementation for the module should look like. In my opinion, this alone would already be a very interesting scope for a first grant.

That being said, I’d like to also call your attention to how this module could fit into the broader ecosystem. In fact, although many DApps will probably not use features like interest rates and lending, virtually all applications need a wallet of sorts to hold user balances and process deposits, transfers and withdrawals. For that matter, we will soon be putting forth a more general proposal to specify these basic wallet functionalities: the idea is to set some standards to allow front-end UIs and other components to interact with any DApp that follows the same specification. For example, these UIs would be capable of sending inspect requests to query the user’s balance in any such DApp, or of sending an input to request an asset withdrawal.

In the context of your proposal, this would simply mean that your module should adhere to these standards, meaning for instance that the input payload that the DApp expects for requesting a withdrawal would follow that specification.

As a reference, the current plan for that direction is being discussed in this Discord thread. We will soon post there more concrete ideas about the wallet standards specification.