Mana

A system trade guarantees of future UBI payments in a trustless manner, effectively banking the unbanked.

Comment

TODO:: fix this.

Inspiration

What it does

How I built it

Challenges I ran into

Accomplishments that I'm proud of

What I learned

What's next for bps-financial-inclusion

The idea is based on a combination of ideas taken from: The Circles project The use of a Zero Sum Accounting system Betbot built for the Status.im hackathon

It takes as a premise that there is some kind of system of welfare (or UBI) where a central authority is responsible for the distribution of Ether (or another cryptocurrency) to a registered set of people. The intended beneficiaries of this Dapp are therefore low income populations with low access to financial services as well as recipients of monetary aid (such as GiveDirectly or other government programs such as in India)

Every entity (recipient of welfare/ubi) has their own contract through which they receive Ether. Each of these contracts maintains the ZeroSum balance sheet for the person/a global balance sheet for all the participants.

Entities can then trade in the following ways:

  1. Directly with Ether
  2. By converting Ether to an external currency/converting an external currency to Ether
  3. With promises of future payments (i.e. buying on credit)
  4. With other entities’ promises of future payments (Person X owes me R...)

The mechanism that enables this trade with promises of future payments is an append only queue called the FuturePaymentQueue (FPQ). If one wants to trade with a promise of future payment, the transaction is added to one’s FPQ (after permission from both parties is obtained). Creditors are then paid according to their order in the FPQ (by means of smart contracts). The FPQ will be completely transparent, in terms of the nature of a person’s debt commitments and when they will be repaid (how far down the que they are.)

In order for this system to function participants need to have access to smart phones, the internet and an app such as Status so participants can interact with the Dapp. (This concept is designed for low income areas, such as informal settlements or townships in Africa, so until smartphones become more ubiquitous this project may be futuristic).

Further concepts can be included such as an automated tax collection on every transaction in the system. This can then automatically be re-distributed fairly among participants in a perpetual economic cycle. If this is successful the need for external input into the system will no longer be present and the system will be self sufficient.

In conclusion: The system largely automates the distribution of UBI/welfare and encourages trade and thus economic growth. Although the system remains trustless, it has an effective mechanism for buying on credit.

Built With

Share this project:

Updates

posted an update —

Hey guys, great to chat with you all yesterday. I'm excited to see how this shapes up!

After reading the main idea above, I have two general comments regarding the Main Problem(s) we intended to solve, and also one regarding Internet access.

Focus on Main Problems:

In this context, we’ve essentially named two parties the Sender (Central Gov’t, NGO, Charity) and the Beneficiary (intended population). Let’s call them S and B, and for this exercise let’s use an S, a Gov’t, that wants to distribute a fixed monthly amount of Mana (M), to an economically poor group of 10,000 people. Let’s choose a developing world context because by solving the greater problem, we may be able to handle the smaller ones in turn. There are a couple of main problems that exist in this space, let’s review them chronologically.

  1. Qualification. What characterizes a person from a larger population of 100,000 to be chosen in this group of 10,000 to become a B.
  2. Identification. Once I have identified a B, how can I ensure that this specific B receives the intended 100 Mana on a monthly basis.
  3. Fraud. How can I be sure that this B has only received 100 M and has not created a new B account, nor coerced another B to give them their 100 M.
  4. Usage. Every S has a set of goals for which they intend that 100 M is spent on. These are usually the essentials: Food, Water, Electricity, Healthcare, Education.
  5. Dependency. An S wants to serve the intended group of B’s, and desires that they improve their livelihood. What happens, when they actually improve? Can we ensure that a qualified B isn’t forever dependent on our transfer of M?

*Any one of these can be a specific application or a use case.

Do we want to refine our scope to just pick one of these or focus on another main problem?

Internet:

Kenya, since 2007, has been using M-Pesa, a successful P2P mobile payment system via “dumb” phones, it is just an SMS text service, and is fully integrated with businesses and I believe governments. Cell towers cover most of the service area, and data plans are not used.

Getting inexpensive smartphones to intended populations is not a problem. Internet access is.

There are small contained network solutions that include Bluetooth or NFC. Is this an option?

Log in or sign up for Devpost to join the conversation.