Skip to content

Latest commit

 

History

History
134 lines (87 loc) · 12.4 KB

README.md

File metadata and controls

134 lines (87 loc) · 12.4 KB
Raw

Alt text

Help-A-Fren

Help-A-Fren is a solution for direct monetary donations with fair and unbiased distribution practices. In times of disaster, there is a scramble of a large number of people wanting to help. This application aims to solve this problem.

Problem:

In the building process, we are using the recent Maui Fires as inspiration to inform the direction of our application. Through the first moments of the ordeal, we noticed that part of the initial chaos was there being a large number of people wanting to help (monetarily) without a designated place to direct them to. As well as a desire to cover many bases with a singular donation, especially those with limited funds to give.

Objective:

In theory, this application would become the go-to for instances like these. Furthermore, you would only need one activation launch, eliminating the restrictions, fees, and duplication that come with platforms like GoFund Me or Instagram Fundraiser.

Our Vision:

In this project, we mimic a DAO governance while applying account abstraction and incorporate geolocation for a simplified user experience. For demo purposes, our backstory is that this is indeed the case throughout the world. Every community in every county has a designated wallet that is indicated on and easily found on each government website respectively. As the wallets belong to a specific geolocation, Digital Identities (DIDs) and verifiable credentials (VCs) would be used to ensure that only verified members of each community are given the ability to have a say in what and how donation funds are distributed. In this scenario, a Maui official or leader would take up the organizer role. To initiate Help-A-Fren, an organizer must first submit a Plea For Help. Once submitted, any member of the affected community can request aid through the Proposal form. Using a account abstraction toolkit like Magic that supports DIDs, we can ensure that only proposals submitted by community members are accepted. To vote, one must login through Magic to verify that they are authorized via geolocation to participate in voting. The voting portal has listed all of the approved and active proposals submitted by community members in need of assistance. It provides a description of why they are requesting help, how they will use the funds they receive, and their requested amount of funds. Voters must select for, against, or to abstain from the proposal. Once a proposal reaches the required voting count threshold, the proposal can be executed on to release requested funds to the address the proposer provided in their request form. Results and statuses of each proposal, as well as the addresses for each transaction can be viewed on the Results page, which can be viewed by anyone in the world.

Our Progress:

In this version we were able to produce a DAO governance application with account abstraction. A proposer user is able to submit a proposal on-chain without the need for a soft/hard wallet with the use of Magic and Biconomy toolkits. Additionally, voters have the same UX experience to submit votes on-chain. We were not able to fully implement a DID trust triangle (Issuer, Holder, Verifier) as planned and look forward to adding in Polygon ID in the next iteration. The use of DIDs and verifiable credentials would also allow for a geolocation feature we initially planned to only allow authorized members of a community based on residence to affect the proposals and governance in our protocol.

Walkthrough

  1. An organizer can start a Please for Help for any cause, community, or individual in need of help.

Plea for help

  1. Donors will search for any Plea for Help and make donations into the designated treasury fund wallet.

Making a Donation

  1. A Proposer will fill out a form to submit a proposal to make use of available funds. After a determined time, the voting period will begin.

Submitting a Proposal

  1. Authorization is require via a Magic sign-in link forcing a user to receive and respond with the emailed One-Time-Password.

Magic Login

  1. A voter will view proposals and select a vote (For, Against, Abstain) on the proposal during the voting period.

Voting

  1. During the vote submittal process, a voting NFT token is minted for the voter and delegated to enable a voting power. The NFT token is transferred to a Smart Account that was generated with Magic/Biconomy authorization process. The token ID is created by with last 7 characters of a hash created from the voter's smart account address and proposal ID. The NFT meta data also includes the proposal details uploaded to IPFS.

Vote Token

  1. If a proposal receives a sufficient amount of votes and the voting period has ended, the proposal will be available to execute and send the proposed funds to the intended recipient's wallet address.

Results

Demo

https://github.com/csalvador58/help-a-fren/blob/d628f2555d9f85514ac1c4330e7e665a630fc438/app/packages/nextjs/public/assets/helpafren.mp4

How it's Made

✅ Account Abstraction

  • Magic - The developer SDK was used to provide a passwordless authentication and Web3 onboarding. Magic was selected for our app to provide various login methods (i.e. Email/Social/SMS) and a feature allowing for Fiat On-Ramps to streamline non-Web3 users to donate with traditional methods. Our project currently only uses Magic's email authentication and as the Web3 signer. Magic's authentication is required for submitting a proposal, viewing/placing a vote, and final execution to release funds from the treasury to a designated recipient.

  • Biconomy - This account abstraction toolkit was used to apply ERC 4337 solution to our on-chain governance protocol and also allowing any donor a simple user experience eliminating the need for software/hardware wallets. Every user authenticating on the application via the Magic email link will initialize Biconomy's Smart Account platform to generate a smart account for the user. Our application makes use of NFT Voting tokens which are sent to these smart accounts and authenticated for voting. Additionally, Biconomy's paymaster service was applied to sponsor all gas payments for all smart contract interactions.

    • Creating Proposals - Proposers are generated a smart account that is linked to their email login when initially signing in during the proposal submittal process.
    • Voting - Voters are also generated a smart account in same process. For voters, an NFT vote token is also minted and sent to the voter's smart account for record tracking purposes that also contains the IPFS has of the proposal details that was voted on.

✅ Smart Contracts

✅ Scripts, Testing, and others

  • Deploy Script - All smart contracts were deployed using Scaffold-ETH-2.
  • Testing Script - Smart contract testing performed within the Hardhat environment.
  • Create Proposal and Mint - Additional testing was performed on proposal creations and minting/delegating vote tokens live on Polygon Mumbai Testnet.
  • Scaffold-ETH-2 - Toolkit used for debugging and testing.
  • Remix - Toolkit used for debugging and testing.
  • Pinata - Used for IPFS Pinning during NFT Vote token minting and proposal registry.

✅ Frontend/UX/Design

✅ Setup

# Clone repo and install dependencies

cd app
yarn install

# Terminal 1 - Run Scaffold-ETH

cd app
yarn chain

# Terminal 2 - Deploying contracts on Polygon Mumbai Testnet

cd app
yarn deploy

# Terminal 3 - Defaults to http://localhost:3000/

cd app
yarn start

✨ Project Members 👩‍💻👨‍💻

Created for ETHGlobal Online 2023 by: