mybank application

[4his2]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we've successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the application. However, I took a quick look at your repo and some of the code seems to be a simplified/old copy of acala’s implementation without any attribution. For example:
https://github.com/mybank-network/mybank-network/blob/92ac8e956010554286ce31758268dde562eb7c4a/pallets/prices/src/lib.rs#L19
https://github.com/AcalaNetwork/Acala/blob/dae608ad8bd650b772035332eb8a3752ade4951d/modules/prices/src/lib.rs#L57
Could you please clarify this? In general most of your deliverables already exist in the ecosystem. Could you point out what is unique about your deliverables and/or focus only on the parts that don’t already exist in the ecosystem?

[4his2]

Hi @Noc2 , we have updated the milestone chapter to highlight our core functions.

The pallet of oracle and reward are developed base on open-runtime-module-library-oracle and open-runtime-module-library-reward. We do not intend to reinvent the wheel and hope to focus on the development of the core functions of MyBank, so we use the implementation of open-runtime-module-library. We have deleted these two parts in the Deliverable column.

[armatrix]

Hi, @Noc2

As you said, most of the "basic functions" we listed are already in the ecosystem or someone is preparing to do. Although we provide function like "leverage trading", it's just a part of our "basic function". The function such as depositing and withdrawing money is every bank has.

We named ourselves MYBANK so that everyone can set up their bank through their social network. Some people have many friends, and some people are more trusted by others in society. This is based on his "Proof of Work" in real life. We want to transform this part of "trust" into its counterpart in the digital world. The personal bank’s ability to attract deposit and lend money comes from its level of trust in social networks.

On the other hand, there is a phenomenon that building a centralized application on a decentralized platform, which is what we refuse to do. We want to build a collective social-network-bank on a decentralized platform. This should be another important point we want to state. For both the borrower, the lender, and the network maintainer, we want to design a reasonable way to efficiently and cost-effectively complete the game between the interests of the participants.

The core problem we want to solve is: when a person has funds to turn around, such a ledger is transparently recorded in everyone’s social circles, we all know the debt situation of our friends on this network, we can follow Such a piece of data can intuitively see to what extent a person can carry out financial activities at what level.

In the "Basic Features" version, we provide over-collateralization, which is a regular feature. Since we only came into contact with the substrate at the beginning of the year, in the first stage, we want to become more familiar with the substrate by implementing the development of basic functions. What we want to show more is the multi-layer guarantor mortgage, which gives higher system rewards to this part. In this part, anyone can crowdfund funds based on the trust of others in him through his social network. This is a demonstration of the ability to absorb reserves. Similarly, he can choose the degree of trust in another person to lending. Each social network has its deposit and loan interest rate, and everyone can provide bank-like functions through social networks.

This is essentially a transmission of trust.

[Noc2]

Thanks for the quick reply. The updated deliveries look much better to me and generally we would be quite interested in a decentralized reputation/credit score system. To be honest, your second milestone isn’t so interesting to me, since we already have a few teams working on dex implementations, which you might want to reuse. (feel free to remove it for now). I therefore suggest to focus more on milestone 1: For example how to your prevent the following “attacks” with your credit score system: sybil, re-entry/whitewashing or collusion attack? And regarding the UI: Do you have some mock-ups which you could share?

[4his2]

Hi @Noc2 , we updated the Milestone chapter and deleted the DeX part. DeX is not our core function. We found that the existing DeX does not provide leveraged trading. If users need to short or add leverage to make long, they need to switch between multiple platforms. We hope to simplify this step and further improve the credit scoring system through transaction records. According to your suggestion, our energy will focus on the development of the Milestone1 part. We are still in the development stage. Our main focus is on designing products, developing Substrate and React. For the time being, we do not have a complete UI interface.

Regarding sybil attacks or collusion attacks. First of all, transactions that occur in MyBank will charge a certain percentage of handling fees. A minimum balance is set for each account, and accounts below this balance will be destroyed. To prevent users from using the same high-credit-score account, frequently adding friends with new accounts to increase the credit score of new accounts, causing the same user to control multiple high-credit-score sub-accounts. When adding friends, we will ask users to mark a correlation to their friends to indicate the correlation between the user and the friend. The higher the correlation of the friend, the more important the user is to this social relationship.

A user has up to m friends, and users can update friend correlation at any time, but the sum of the correlation that a user can assign is equal to 1. For example, if a user assigns 0.2 to a friend, the others can only get 0.8 at most. When the social network factor is included in the credit score calculation, the system will only take the user profile of the top n friends (ranked according to the friend correlation), or the weight of the friends ranked behind will be lower. It is not that the more friends a person has, the more friends with high credit scores, the higher his credit score will be.

On the other hand, we will judge the value of the user's deposit according to the time factor. The weight of the deposit in the account for one year and one day is completely different when calculating the credit score.

Our ultimate goal is not only to use the data generated inside the MyBank platform to generate the corresponding score (User Profile), we hope that the data generated by users in the Social Network Bank and Private Pool will also be connected to the credit system by a certain weight. Digital assets on the chain are only a part of personal assets, and in the future we hope to be able to cooperate with third-party institutions to introduce users' off-chain assets and transaction records on other platforms into MyBank by generating corresponding vouchers, as a reference factor for credit system scoring, the more data accessed, the more perfect the credit subsystem will be and more referential.

However, when the first phase of the project was just started, the credit score generated due to too little data did not have much reference value. In the early stage, we wanted to attract more users to participate by developing related DeFi modules, and actively cooperate with third-party organizations under the chain to support users to introduce off-chain assets to MyBank. When the user scale reaches a certain level and the governance organization is gradually improved, the entire ecology will enter a stage of rapid development.

[Noc2]

Sorry for the late response and thanks for the update. I have a few follow-up questions: What kind of anonymity do you use? I guess everything will be transparent on-chain. Regarding the social network aspect. Did you take a look at the Identity Module or subsocial? And regarding the interface it would still be nice if you could integrate some kind of mockups and initial drafts of the UI.

[armatrix]

Hi @Noc2

I'm sorry that I didn't reply to you for so long. I really need some time to think about the feasibility of the credit system and how to implement it specifically.
Frankly, I'm a back-end programmer and we didn't have UI, so it took me a few days to build the basic website, and now my colleagues and I have finished the development of SWAP and Liquidity. To some extent, we are already familiar with the use of Substrate and PolkadotJS.

Back to the reputation System, it built on three premises:

1. First, the particularity of social networks is different from other networks
2. Second, we refer to the previous design in this area, such as EigenTrust, etc.
3. Third, MyBank itself wants to be similar to Grameen Bank on the blockchain. We believe that blockchain technology should serve more people's credit sub-system or the whole of MyBank, and we position it to use the blockchain technology to achieve inclusive finance.

It's based on a vote of friendship, I've abstracted social relationships into a Graph. When calculating the voting score, it will randomly select acyclic networks to participate in the calculation. ( Paillier and VRF will solve my problem？)

Another is the Burn mechanism of Coindays, I use it as another credit rating factor. Those should soften the effect of the Sybil Attack.

What's left is how many friends do you have, how many assets do your friends have, are they willing to vouch for you, etc. Of course, there are certain conditions for each valid friend. This is also associated with the Burn mechanism of Coindays.
We intend to correlate voting behavior with incentives to ensure continued voting.
Maybe you can give us some suggestions from a more professional perspective.

UI: homepage

UI: social networks

Different colors represent different relationships, Friends or not, vouch or not, one-way vote, obligatory relationships, etc.

[Noc2]

Thanks again for the updates. Could you integrate this information into the application? I also took another look at your code and realised that you are still using acala’s code without any reference as far as I can see it:

• https://github.com/mybank-network/mybank-network/blob/cdce27521011cb1226df1ceb2288a4dcb3c6f407/pallets/dex/src/lib.rs
• https://github.com/AcalaNetwork/Acala/blob/dcfecd20b3fddb037c7667c0d227cc6a5e56a021/modules/dex/src/lib.rs

This is something we strongly discourage via the grants program. It’s fine to use code developed by others, but you should at least reference it and add proper attribution.

[armatrix]

Hi @Noc2, I am so sorry for the ref problem. We have updated the grant application and added the Acala reference link in the substrate repo code. BTW they did a great job, as a beginner, we learned a lot from them.

[Noc2]

Thanks for updating. In general I’m willing to go ahead with it and share it with the rest of the team. Please make sure in the future to add proper attribution to other projects, if you are using their code. Otherwise, we would terminate the grant.

[mmagician]

Could you elaborate on the part "Homomorphic encryption provides the technical foundation" [Anonymous Vote section] please?
I don't see how this ties in to any of your current deliverables. Also, what techniques and tech stack are you planning to use for homomorphic encryption? (e.g. do you have any implementation already in mind, as I assume you won't be coding it up from scratch).

When reading your proposal (most of it very well explained, btw!) I also asked myself how the following attack can be prevented (I think that's the re-entry attack that @Noc2 mentioned already), I'm referring to the below excerpt:

Repayment of a loan will leave a record on the chain. Borrowers will have a greater chance to obtain larger loans in the future, indirectly encouraging users to gradually accumulate their credit history

What's to stop me from borrowing & re-paying over and over again, thus constantly improving my credit history?
Is there any particular curve that will govern the relationship, or would I continue to linearly increase my score? I don't know if the fees alone are enough to stop this (depending on the fee, of course).
I'm not an expert on the topic, but perhaps a cool-down period (maybe exponential?) after each repay could be triggered, or some mechanism to detect such behaviour.

[4his2]

Hi @mmagician, we plan to use Paillier to realize anonymous voting. Using paillier to realize anonymous voting has been applied in many scenarios. Here we should not encounter technical problems that cannot be solved (rust-paillier), but more is how to design a reasonable system. In the last few days, we have invited some friends to discuss some possible problems. We hope to achieve anonymity in more fields in the future , but this year is our first year in the substrate/polkadot community. As beginners, we are still looking for better solutions, therefore some contents have not been put on milestones for the time being. We hope to wait for the completion of the first milestone before considering more general solutions.

Anonymity is also related to the friend-correlation(trust score) we commented on before. The degree of relationship between users is very important to the system. The use of social network weights when calculating credit scores will refer to this part of the data. The total correlation of a certain user is limited. For some social purposes, users don't want their reviews of their friends to be seen by the parties concerned. At the same time, the system also needs to get real correlation data. Everyone has their own social networks. Even if A and B are friends, the social networks of A and B cannot be completely intersected. If A wants to guarantee B, A needs more information about B's social networks. If B has more powerful(high score) friends, A will be more confident for guarantee loans. In the future, with the development of blockchain, when the assets and certificates under the chain begin to enter the blockchain, these real social network data will bring a broader application scenario.

Regarding the issue of increasing credit scores through repeated borrowing & repaying, here we have introduced other evaluation factors in addition to handling fees. Too frequent borrowing is abnormal behavior. First, a maximum number of lending times will be set on the system. Too frequent borrowing will reduce the user's credit score instead. In social network bank, collective governance and social constraints are also a kind of suppression of this behavior. The social network itself can be used as a governance tool. (Similar to Grameen Bank-community development bank) On the other hand, we will judge the value of the user's deposit according to the time factor. The weight of the deposit in the account for one year and one day is completely different when calculating the credit score.

[mmagician]

I see, it makes sense that you want to start small and expand your codebase as you gain experience. Good luck with the first milestone then!

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[alxs]

@4his2 @armatrix care to share a quick status update, along with an ETA if possible? Your repositories look inactive and we were hoping to receive your first delivery a bit over a month ago now.

As long as you're actively working on the project, delays aren't a big problem, but we'd appreciate it if you could keep us in the loop. Note that if we don't hear from you soon, we will assume you're no longer interested and terminate the agreement.

[alxs]

This grant is being terminated due to inactivity. Feel free to apply again if you're still interested.