Machu Picchu

The vision of Machu-Picchu is to make user data a public service, not confiscated by today's platforms like GAFA and the likes. To make it happen, we start by building a distributed system where more than 500M smallholder farmers worldwide can share their crop weather risks and their data. Sharing crop risks is a sore need. For more than 40 years, governments have been using centralised insurance to try and satisfy this need without success. This is because insurance is best to protect big amounts against infrequent damages, while the problem is here the opposite: small amounts and frequent risks. Still, since the dawn of time, farmers have successfully shared risks P2P without insurers, but this is not scalable to address climate change. By combining blockchain and Earth Observation, Machu-Picchu wants to reduce costs drastically while using the ancestral risk-sharing practices. Once the risk-sharing part of Machu-Picchu is successful, its open source thesaurus of farmers and of their history of damages and of contributions can be a public service of data, to promote credit rating, gender equality, sustainable low-carbon best agro practices, health, education etc. The benefit of Machu-Picchu is like Route 66 for the development of the USA High-West: many communities and trades can take benefit of the network but no one can confiscate it.

The precursor of Machu-Picchu, IBISA networks, is focused only on risk-sharing. It has today 310 paying farmers in Tamil Nadu, India, with plans to grow to 5'000 in 2020 and 10'000 in 2021. It is also pre-registering up to 10'000 nomad breeders in Niger, Africa. Machu-Picchu used to be the IBISA Lab. It has been separated and renamed to avoid confusing the public and the investors. There is a cross-feed between Machu-Picchu and IBISA: IBISA brings farmers and users while Machu-Picchu brings open-source development forces, somehow similar to the relation between ConsenSys and the Ethereum Foundation. More in the README of the github...

We BUILD/DEVELOPED the following components for our hack:

Smart Contracts:

1. dApp Smart Contracts: Our main business logic is here only, and includes User Contract, Main Contract and ERC20 Token (1:1 ratio with Indian National Currency Rupees) Contracts. They all are deployed on Kovan Testnet.

2. OTP External Adapter: This is what we used for sending OTP messages. It is developed using a heroku server which uses Twillio SMS Service in the background.

3. OTP Generator&Verifier: We are using Chainlink-vrf for generating the OTPs.

4. OpenGSN Paymaster: We used Open GSN Paymaster capability to allow role-based free gas services.

Front end:

User Interface using React: We developed the User Interface using react, html, css & hosted it on GCP for the demo.

** Technologies we used:**

Chainlink, Portis, OpenGSN, Metamask, Truffle, React, GCP, Git, Earth Observation Assessment Tool developed by IBISA Labs

How are they pieced together?

We have developed our dApp keeping in mind that we have 3 roles personified in our dApp: members (farmers), watchers (those who will stake and assess the crop loss using satellite data) and enablers (heads of village or NGOs who will help farmers using the dApp ). We wanted our dApp to be easy to use for villagers and also to give a chance for usual blockchain users to earn profits by becoming watchers.

So we have user log into our dApp either using Metamask or Portis wallet. On-boarding users has been a challenging part but Portis & OpenGSN made it easy. Portis wallet provides more flexibility as anyone can register just with email and password. And after creating wallets, farmers and enablers need not to have any ETH to pay for the gas. We will have Gas Stations setup for that. Our future plan is to use our own RUP Token to pay for the gas using Paymaster.This is how we are on-boarding users.

After on-boarding, all users will perform their allocated actions. Two of the most important actions are Contribution & Compensation Payout for farmers because we know that enablers will be doing these actions for them and that gives a possibility for malicious activity. But we limited that using OTP authorisation by sending messages on farmer's mobile number containing the following message:

Amount: X Rup Tokens

Action: Contributing/Compensation

Member's address/ENS name: 0x123.../farmer-name.machpicchu.eth

OTP: 6 digit number (eg. 123123)

Now this information is enough for farmers to understand what they are doing, what amount is being contributed/compensated, is this been done for their account and if they agree then they can give their OTP to enabler and proceed. We used OTP External Adapter, Chainklink-VRF for this.

For watchers to do the assessment for farmer's field, we are using Earth Observation Assessment Tool (https://ibisa.users.earthengine.app/view/mcgyver3 ).

We build the front-end on React and hosted it on Google Cloud Platform. Truffle & Git helped us in developing and maintaining the integrity of the application.

Did you do anything particuarly hacky that's notable and worth mentioning

Yes. We developed the OTP external adapter. When we presented our idea in the Idea Evaluation round, we were told that there isn't anything as such to use, so only option was to develop it and we did it.

Summary

We dont just tell,we show

We have developed our dApp and we want you to use it here: https://34.122.69.68/