March 31, April 1st, April 2nd 2023
Organizers: Think and Dev
Location: Cordoba, Argentina
- Luciano Martin Garriga
- Franco Cerino
- Federico Rascon
- Benjamin Juarez
- Neri Bocchi (Ripio)
- Juan Ignacio Bocchi
The Hackaton begins with a time limit of developing an idea in a little less than 3 consecutive days, and sets the agenda that teams can develop whatever they want as long as the concept is useful and makes good use of the properties that a web3 environment can provide. Additional criteria is that the development is expected to be original, complete and delivered with clean code and complete functionality.
The group that is proposing the current project firstly brainstormed ideas and came to four main contesting ideas to counter weight each against the other. To evaluate each of the possible ideas to develop, the group members built an evaluation system that would comply with the hackaton context.
The first two criteria to test ideas were originality(1), and viability(2). So for each of the four ideas, the group assigned a value for these 2 categories in a score from 1 to 10. The competing ideas at the top had similar scores. So in a second instance, the group adopted a third criteria: willingness(3) to develop.
In the end, came the winner, only leaving behind a very original idea that seemed complex to develop in the assigned time, and with a potential promise to develop in the future. The scores for the winner idea, from the point of view of the group was:
- Originality: 8
- Viability: 10
- Willingness: 10
- Total Score: 28
Services that have intermediaries always have an additional cost. So some payment systems entail a process in which, one party (User A) pays to another party (User B), who then pays to the end party (User C). In summary, in a traditional linking relationship to make payments, there are three figures:
- A: is the user who wishes to pay for any service.
- B: is the traditional intermediary that charges a commission for the intermediation between two parties.
- C: is the end user of the destination of the money.
The workaround in web3 is that sometimes not all parties are required. So payer A can send assets directly to C without intermediary B. This allows for quicker processes and less expensive ones.
In the local context of this project, the development aims to comply with legal regulations, which may require that the intermediary party still exists. This project is a web3 solution where we provide more transparency and traceability to the process, showing in real time how funds move and the total balance of funds that go in and out of the smart contract.
A new user comes in place, which is User D, who is the Contract Owner. User D, in real life, is the person that creates and updates users to the system, can send payments to User C (even though User C can still claim salairies by their own.)
The proposed development here is a payment system, that includes custody and distribution, aiming to simplify payments for the end users (A and C) and make the process more efficient. The dApp (decentralized Application) could do without centralized intermediaries. The Contract Owner, User D, can overview transactions and add and modify users.
Reduce costs and speed up and secure financial transactions. Operations become transparent and public, and every payment shows its traceability with the origin and destiny of funds.
The context and use case described above is only a fraction of what this analysis can tackle. The pain point is generic, and the use case for payments can be found in a wide array of situations.
The dApp can be used in any field in which payers and receivers coexist: employees, partners, collaborators, etc. The dApp can be used in environments such as:
- corporations
- collaborations
- businesses
- transitional partnerships
- crowdfunding
- NGOs
A very common use case is the control of communal expenses that are handed into a fund and then used to pay expenses of the building, services, and employee salaries.
The idea from the project kick-off is to give a web3 solution that can be useful to a massive audience. Between the 1st party A, and the end user C the ideal plan would be to have FIAT payments and FIAT cashouts.
Everything that happens in the middle should be fueled on the blockchain with Smart Contracts which make the flow secure, traceable, and simple.
The system is aimed to be used with FIAT users with no knowledge of web3:
- Tenants
- Employees
- Admins
The user experience is expected to be as seamless as any web2 application, with the gains of working with web3 in the background.
What happens if:
- a tenant doesn't pay enough to cover the costs of the fund: salaries, or destination accounts? There could be a penalty such as a partial claim. Such tenants should also cover the fees for the transaction costs of activating the smart contract.
- a tenant changes? or a tenant leaves and no one replaces them for a period of time?
The spirit of the brand is to convey a serious tone in which users can rely on a system without thinking about how the technicalities workaround in the background. Blue is a cold color that represents objectivity, and calmness and does not raise alarms. The tones that aim to represent this perspective is a palette that is at the same time: simple, quick, effective, and most importantly secure and transparent.
- Color Palette from coolors.co: LINK here
- Admin (User D, here Contract Owner of an account on Trust Pay) adds other Users:
- Tenant. (User A)
- Name
- Wallet Address
- Expenses Amount
- Employee. (User C)
- Name
- Wallet Address
- Salary Amount
On-Ramping
- Tenant (User A) pays
- Tenant accesses the Ripio Portal
- Tenant pays $ARS and converts them to MATIC
Off-Ramping
- Employee (User C) receives payment (Standard flow)
- Admin (User D) pays salary through third party Wallet
- Ripio
- Lemon
- Belo
- Employee (User C) receives payment (Alternative flow)
- If Admin does nothing, employee (User C) claims salary. Claiming is available on two environments
- $ARS through Trust Pay Portal (Standard Recommended)
- MATIC through Metamask Browser Extension, or Mobile App
- Employee (User C) uses payment received
- Uses Debit Card for Payments
- Electronic Deposit Transfer $ARS to Bank Account
- FrontEnd: React / WAGMI Web3 Library
- EVM Compatible Language: Solidity
- OnRamp/OffRamp: Ripio Portal
- Control Version System: GitHub
- Blockchain: Ethereum
- Blockchain Network: Polygon
- Idea Concept
- Branding
- Product Naming
- Logo
- Color Palette
- Readme Documentation version 2
- SmartContract: Smart contract deployed en Testent Polygon
- Research Frontend: libraries, examples, etc. Build the Dapp and connect Wallet
- Business Rules: Review case scenarios in which the tenants, and representative/leader of the community, may need to consider special situations such as extraordinary expenses.
- Installation and Deploy Guide
- Bug acknowledgment and possible error corrections
- Frequently Asked Questions (FAQ)
- Copyrights, licenses, and legal considerations
We had a conversation with one of the Founding Members of the Cardano RealFi Consortium @RealfiCardano. Darius Golkar suggested 2 ideas, that we could:
- Make use of a built tool that serves to receive payments and allows integration with several platforms such as Venmo, Paypal and Stripe: https://github.com/NFT-DAO/EZ-Pay---Backend
- Present our pitch deck for Catalyst Funding: Catalyst Fund 10. (Proposals are not open yet.)