Para Para

Humanitarian aid collected on-chain and delivered directly to verified humans who meet each relief fund's targeting criteria. Anybody can start a relief fund with targeting parameters based on geolocation, HRMI (human rights measurement index) e.g. right to housing, housing and work, and 11 other internationally recognized human rights, targeting up to 41 at-risk groups (e.g. elderly, disabled, refugees) or based on forecasted climate factors such as risk of flood, drought or famine in next N years.

Verified-humans (via worldcoin) self-attest to targeting information upon enrollment and then get access to applicable relief funds as they become available. By layering as much anonymous data as possible, it provides fund organizers with the ability to provide aid as specifically ("low-income, low-right to work locations at risk of drought in the next 5 years who have been worldcoin orb-verified") or broadly as they like ("anybody in Zimbabwe who is worldcoin phone-verified").

My research on this issue over the weekend has shown a clear need for a broadly-applicable direct aid solution. Three simple examples: 1.) the emergent solution of airbnb as a vehicle for direct aid (rent a "house" (fake listings) on airbnb from areas affected by the war but don't actually go there in order to provide money directly to people that need it) 2.) the successful implementation of a similar model in Togo in 2021 where money was delivered to enrolled phone numbers based on targeting generated by AI models trained on mobile phone data and 3.) the incredibly opaque collection & delivery of aid by AFAD in Turkey in response to the 2023 earthquakes.

Para Para has implemented a functional proof of concept to demonstrate the flow from end-to-end. Primarily those steps are: human enrollment, fund creation & organization, on-chain aid dispersement.

Future integrations would bring the targeting on-chain, provide off-ramp partner integrations (such as digital public good https://kotanipay.com) that are particularly focused on emerging nations as well as implementing a protocol for community-based attestations (resist fraud, increase trust).

Something else that would be interesting to implement in the future, would be funds that can collect aid for certain criteria that may not necessarily be present, but could be automatically claimed when the targeting criteria occurs. It could be incredibly specific such as "Aid for humans who have contracted Ebola, attested by redcross.eth, in areas where WHO has declared a disease outbreak emergency".

• Contracted Ebola attested by the Red Cross organization (identified by their ENS).
• Certain geographic locations (we could validate this with phone app and/or phone number)
• When WHO has declared... by creating an oracle that can provide this information on-chain

This kind of complex layering is a natural fit for the Para Para Protocol, and possible to implement with existing technologies.

Para Para is a dApp, written from scratch by a single developer. The main contract is deployed to Optimism Goerli (testnet). The ParaParaController contract manages enrollments (verify proof of humanity + enroll), fund management actions (create, pause, resume, stop), accept donations to a fund, claim relief tranche, start a new tranche.

Enrollees are notified via Push Protocol when an event has occurred that is relevant to them, such as a fund which they are eligible for being created, or when a new tranche for an eligible fund has started.

Tranches are an important concept for our fund dispersement: When a fund is created, the organizer needs to set how many USDC each tranche will be. Since humans will be able to enroll after the fund has been started, and they won't know how many donations will come, then there is a chance for everybody to claim an equal amount of money. If the organizer decides that enough people have claimed their aid, and there is enough donation money left over, then they can start another tranche, allowing people who need it to claim another round of tranches. It's a lot like sharing cake - wait until everybody gets a slice before going back for a second.

The contract is written in solidity, deployed with Foundry.

To prevent people from enrolling multiple times, we enforce a worldcoin verification. One verified human = one enrollment. Technically this is implemented by including the <IDKitWidget> react component from Worldcoin on page which wraps the enrollment button. The user clicks enroll, follows the worldcoin verification flow and our code gets back the proof and other data needed for verification. We provide all of this data in a call to our verifyAndEnroll function on the contract which first checks that the human hasn't enrolled before, that the proof is valid (worldcoin on-chain validation) and then record them in our map of enrollments.

The website is written in nextjs, typescript, react and deployed to vercel. Notable web3 libraries in use are wagmi, ethers, rainbowkit and viem - there is some unnecessary overlap due to certain incompatibilities from some protocols' documentation with the 1.x version of wagmi that I encountered during development.

The UI has fully implemented enrollment actions (get, verify and enroll), donating USDC to any fund, and for enrollees to claim tranches from funds which are targeting the country they have attested to belonging to. The other parts of fund management are fully implemented in the contract but not exposed in the UI.