Wonderful - in regards to auditing - we had one concern that we’d love for you to shed some light on.
The concern is in regards to how private keys are handled, considering the app’s direct transaction capabilities. Given the industry’s history of private key leaks, could you shed light on the security measures in place for storing private keys within the application?
Community members are keen on ensuring the safety of their funds, and providing reassurance on this front would be appreciated.
Key management is an area we are really looking into and as I had said earlier
“Our biggest challenge so far has been how best we can help the user stay in control while keeping the UX as simple as just using PINs for transactions.
Our approach is for the current project is to try and employ industry standard encryptions during transactions and not store users keys anywhere in our platform. Later we plan to source or build an MPC key management solution.”
For this demo, and for our mvp, we are encrypting the key and storing this on the users device. The encryption takes the users passcode/PIN as a parameter hence each key is encrypted uniquely. During a transaction, we generate a token form the users PIN, then use this token to decrypt the key. We will also do an audit of this process so that we check for potential leaks.
We will also add a confirmation modal that would require the users passcode in order to complete the transaction.
I checked whole platform again and just one thing: It’s a very clean work. Can you share the programming languages you used and so on? I’m asking to better understand the working logic, Best of luck in advance
The app is a React-Native app (on Expo), using TronWeb to interact with the contracts.
We wrote the contracts in Solidity (using hardhat for development) then used the TronIDE for deployment.
There isn’t a backend as such, but we use firebase for authentication. Everything else is stored on the device or on-chain.
Our backend will remain to be firebase with some form of API built with expressjs (Nodejs) later when we see the need to have some more info. For instance we don’t have a dashboard yet, where we can track some metrics.
Rem the project is opensource and you can look and contribute to it too.
Okay! Thank you for providing the information I have asked from you. I can see you’re planning on building your own solution in later time, wishing you the best of luck throughout the journey.
Thats a very great question. In our school we had this system, we called it “Mary Go round”
The person who took the first round of payment intentionally decided not to pay the next rounds and it resulted in alot of chaos and a final collapse of the whole thing.
Thank you for sharing. I can see a lot of love in this product.
I am reviewing based on the demonstration, presentation and the notes at top of this post. A also tried to use the Expo Go / iOS app, but the COUNTRY drop down box did not work for me so I could not get past the first page.
The use case is well understood and facilitated through this project. For example, see how there is a focus on food sellers and delivery persons. The loan types and business savings are geared towards this kind of person. Loans and savings for a period of months–not hours or years.
The most important part of a good finance product is encouraging people to make good decisions. Outre specifically supports this by using something I learned as a kid called “the envelope method”. They call it “spaces”. You name a specific savings goal and allocate assets directly into that fund.
These kinds of practical improvements, tied into a functional product, are what can make TRON sucessful in Africa and it’s great to see it executed like this.
The pools last as long as the groups or individuals wish. You can set different deadlines for savings but for the RoSCA we like to look at as a long-term thing for the members, may be with membership cap to make them more practical.
This is actually one of the biggest challenges we found out during the research of the project. However we found that in the informal setup, people fail to make payments since they is no way of holding them accountable apart from them loosing credibility withing their community. At Outre we believe by making this a formalized financial product one will be exposed to standardized “financial consequences” upon default. Like having their credit score affected. However, control is till with the group and a worse case is the member being kicked out of the rosca. We also intend to experiment with some form of insurance from the roscas in the fine prints in order to cover this defaults. The implementation of this will be interesting to see as some might choose to abuse this system.
Someone leaving the pot early is not really a problem as members could prioritize to contribute to this members pot to the amount that he had already put in. Basically just reimbursing this persons contributions so far.
I appreciate the response! I believe the 2nd question / issue will be the hardest to handle but I am happy to see the team aware and making suggestions
Hi @SerpentWhisperer
This November we will be carrying out an audit of our contracts before deploying to mainnet and launching the MVP We think this will be able to show us where we might have security issues on the contract.
On handling user information, we do intend to look at and implement the necessary requirements for Data Privacy as stipulated in the Kenya’s Data Privacy Act - since we are starting with the Kenyan Market. Also user specific information will not be stored on chain.
Yes, there was a bug in the prototype, esp during submission of the info to the blockchain. where we miss the response and the app appears to loading infinitely even though the tx already when through.
We have fixed this and this will be updated on the actual mvp.