Help-A-Fren

Problem: In the building process, we used 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 that there was a large amount of people wanting to help (monetarily) with no designated place to direct them to. Also, 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. To start off, you would only need to activate the fund instance once, and any all donations and requests for funds would go through a singular channel. Thereby, eliminating the restrictions, fees, and duplication that comes with platforms like GoFund Me or Instagram Fundraiser.

Our Vision: In this project, we wanted to mimic DAO governance while applying account abstraction and incorporating geolocation for a simplified user experience. We are pretending that mass adoption was achieved and that every community in every county has a designated wallet that can be 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 our 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 an 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 fully functional 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. Also at the moment our app components are all displaying on a single page. In the next iteration these would be routed and not scroll through.

Account Abstraction

• Magic - https://magic.link/ 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 - https://docs.biconomy.io/ 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 https://github.com/csalvador58/help-a-fren/blob/6abfd56060764173d9831fde0be437c1f4c737e2/app/packages/nextjs/pages/helpafren/haf-proposal-test.tsx Proposers are generated a smart account that is linked to their email login when initially signing in during the proposal submittal process.

• Voting https://github.com/csalvador58/help-a-fren/blob/a37c722722e257e399814e7b986155ba65202782/app/packages/nextjs/pages/helpafren/haf-vote-test.tsx 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

• Open Zeppelin Governor v.5.0 - https://github.com/csalvador58/help-a-fren/blob/dd328d9ce621ef551198a3870aa57221628a8740/app/packages/hardhat/contracts/HelpAFrenGov.sol An OpenZeppelin Governor contract was used follow the industry's best practices on creating an on-chain governance protocol. The recently released 5.0 version was used in our project.

  • Deployed on Polygon Mumbai Testnet https://mumbai.polygonscan.com/address/0x169732B7AB77575e073C56Ec5493110e2b817108
  • Address: 0x169732B7AB77575e073C56Ec5493110e2b817108

• Open Zeppelin ERC721 Token v.5.0 https://github.com/csalvador58/help-a-fren/blob/dd328d9ce621ef551198a3870aa57221628a8740/app/packages/hardhat/contracts/HelpAFrenVoteToken.sol Another OpenZeppelin ERC721 contract was used to provide the voting utility for the users.

  • Deployed on Polygon Mumbai Testnet https://mumbai.polygonscan.com/address/0x8B453FFA294F91e4bd1858eDD3cF860A483fF3e4
  • View Help-A-Fren NFT's on OpenSea Testnets https://testnets.opensea.io/collection/helpafrentoken
  • Address: 0x8B453FFA294F91e4bd1858eDD3cF860A483fF3e4

• Timelock Controller https://github.com/csalvador58/help-a-fren/blob/5482880a33309d266cdfc62207cdb466a6a8e66c/app/packages/hardhat/contracts/HelpAFrenTimelock.sol A Timelock controller was used with the Governor contract for setting various roles to allow for a decentralized governance.

  • Deployed on Polygon Mumbai Testnet https://mumbai.polygonscan.com/address/0x3A9b665684cb31925131FC783b501c7e45b9B04c
  • Address: 0x3A9b665684cb31925131FC783b501c7e45b9B04c

• Treasury https://github.com/csalvador58/help-a-fren/blob/6c2791c5b339da8ed709846d3cfdffb79c3fe759/app/packages/hardhat/contracts/HelpAFrenTreasury.sol A treasury wallet used to receive donations. During deployement, the Timelock contract was assigned the owner of the treasury to control withdrawals from the fund based on the successful proposals.

  • Deployed on Polygon Mumbai Testnet https://mumbai.polygonscan.com/address/0x522989F0585c4Bc2eb02d27EF8Eb62Ea0ae0C4b1
  • Address: 0x522989F0585c4Bc2eb02d27EF8Eb62Ea0ae0C4b1

• Proposal Registry https://github.com/csalvador58/help-a-fren/blob/2db73a65c5b02dbcfe184753fa61608d8c5a2ab2/app/packages/hardhat/contracts/HelpAFrenProposalRegistry.sol A registry was used to track the submitted proposal details. Proposal details are uploaded to IPFS and linked to the proposal details when added to the registry.

  • Deployed on Polygon Mumbai Testnet https://mumbai.polygonscan.com/address/0xb842805e618f401fDDd836308234E8fC5231b534
  • Address: 0xb842805e618f401fDDd836308234E8fC5231b534

Scripts, Testing, and others

• Deploy Script https://github.com/csalvador58/help-a-fren/blob/384f18d68ef5713ff8de44fdcee09b5b8fed5979/app/packages/hardhat/deploy/00_deployContracts.ts All smart contracts were deployed using Scaffold-ETH-2.

• Testing Script https://github.com/csalvador58/help-a-fren/blob/384f18d68ef5713ff8de44fdcee09b5b8fed5979/app/packages/hardhat/test/app_tests.ts

• Smart contract testing performed within the Hardhat environment.

• Create Proposal and Mint https://github.com/csalvador58/help-a-fren/blob/69b4b35b4c64d4789b5664e902b88435e1637eee/app/packages/hardhat/scripts/createProposalAndMint.ts
  Additional testing was performed on proposal creations and minting/delegating vote tokens live on Polygon Mumbai Testnet.

• Scaffold-ETH-2 - https://docs.scaffoldeth.io/ Toolkit used for debugging and testing.

• Remix - https://remix.ethereum.org/ Toolkit used for debugging and testing.

• Pinata - https://www.pinata.cloud/ Used for IPFS Pinning during NFT Vote token minting and proposal registry.

Frontend/UI

• Scaffold-ETH-2 - https://docs.scaffoldeth.io/
• Next JS - https://nextjs.org/
• Daisy UI - https://daisyui.com/
• Tailwind - https://tailwindcss.com/