Payments: In-App Banking Component with API

Cartesi Grants Program CGP Pilot
1

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.

Milestones

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

Website: https://webchefs.tech/
Social: https://www.instagram.com/wearewebchefs/
LinkedIn: Webchefs Software Company | LinkedIn

ERC-20 Payee address

ERC-20 address: 0xcc425d2f6900d6538cdac895896f2ef2a8c53d1f

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

2 Likes
2

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

1 Like
3

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
4

@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
5

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

Cheers!

2 Likes
6

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.

7

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.

1 Like
8

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.

Cheers!

9

This is a derivative to what I believe Milton is referring to here:

We would like to work out a proposal for standardized component development. Since we are going to be building a component without any specific technical guidelines, we thought that we could prepare a set of rules while at it and open discussion in the community.

@joe-cartesi
in my opinion the above adds to the developer ecosystem, re:

I also feel like I have to disagree with your statement:

Maybe the banking word is misleading. When I think of components, I go for something more abstract and reusable. The component would have generic methods that could fit many use cases. How about “In-dapp accounts and balancing module”. Does this sound more reusable?. This would cover p2p payments, and settling scores, and whereas the module could indeed evolve into:

This component would also cover simpler use cases, like marketplaces, for example.
That being said, @erick.demoura please find those two sequence diagrams as a starting point.

  1. Setting up an account with a deposit:

    image
    image817×641 14.8 KB

  2. Interaction between 2 accounts. Please notice the loop and the concept of withdrawal via voucher. A voucher can be a summary of multiple transactions between accounts.

    image
    image1032×746 23.2 KB

Any marketplace example:

  1. You make one deposit into your community marketplace (clothing for instance),
  2. You make multiple transactions, back and forth, i.e. selling, buying, exchanging
  3. You make only 1 withdrawal

The implementation above could also be used for a shopping cart, for instance. Moreover, many current web2 applications use similar balancing for, i.e. marketing campaigns. You can top up an account with a i.e. money transfer or via a voucher from a marketing campaign, for instance. This voucher enables you to trade and exchange goods without actually adding the funds. You can also use means from your account to, i.e. boost your items (if we are in a marketplace context).

Redefining proposal in the spirit of the lean approach:

Milestone 1: Poc of account transactions

  • Duration: [2 months]
  • Deliverables:
  1. Database Design,
  2. Complete list of methods
  3. Architecture and Documentation with Use Cases
  4. Working ledger,
  5. Guides, how-tos
  6. Testing Report, with all test cases
  7. Example dapp with running source code
  • Funds request (USD) for milestone 2: 11 550 [210H x 55USD]

The dapp would implement the sequence diagrams with a simple GUI as proof of concept. Depending on how development goes, we would prepare 1 - 3 use cases of the component in different settings, possibly different methods.

  1. Marketplace,
  2. Simple Banking,
  3. Game (points scoring)

PS. can only mention two users per post since I’m a new user

1 Like
10

Hello there!

We would like to work out a proposal for standardized component development. Since we are going to be building a component without any specific technical guidelines, we thought that we could prepare a set of rules while at it and open discussion in the community.

Yes, we should have standards both for wallet operations and components in general! We have put forth some ideas in the Discord thread mentioned before, and the current proposed specs are in this Git repository. It would be great if you would be interested in discussing, criticizing, and evolving these ideas, and using them in some experimental applications. If that is in line with what you are proposing, then we are on the same page here!

Btw, the current spec is already being partially exercised in this experimental DApp, written in Typescript. Some additional details, such as the routing issue, can be found in the Discord thread.

So, just to be clear, I see different “levels” of work here:

  1. To discuss and refine wallet standards in the context of a more general framework, which would allow us to boost reusage of DApp components (e.g., a front-end wallet component that can be used to manage funds in any compliant DApp).

  2. To implement compliant DApp components, both in the front-end and in the back-end. For the back-end, this would involve an implementation to store account balances, for instance in a database. For the front-end, this could involve the implementation of a JS component for wallet operations. These components would naturally be already a bit more opinionated, implemented in a specific language, etc.

  3. To write some experimental applications to exercise (2), as you suggested

Do you agree with this view? Please feel free to interact on Discord too!

One more thing: for items (2) and (3) above, do you have any specific language that you would prefer to use for the back-end software?

Cheers!

1 Like