The problem Helping Hands solves

Today’s crowdfunding platforms (like GoFundMe) are centralized and often require extensive traditional KYC, which excludes many users without easy access to banking or government-issued documents. Additionally, donors have to trust a centralized entity to manage their funds, and there’s limited transparency on whether the campaign owner is truly who they claim to be.

Helping Hands solves these problems by:

-Integrating Humanity Protocol for trustless, on-chain identity verification (no storing personal data on a central server).

• Accepting USDC donations that are lent on Aave to generate additional yield for the fundraiser.

• Providing a fully decentralized experience—no single party can freeze funds or reject cross-border donations.

This approach democratizes crowdfunding, enabling anyone with a Web3 wallet to start or donate to a fundraiser, no matter their location or banking status, while retaining trust through on-chain identity verification.

User Interaction and Data Flow

1. Visit Helping Hands: Users open the dApp in their browser and connect their MetaMask wallet.

2. Create a Fundraiser:

• Click “Start your fundraiser”.
• Provide a title, goal, story, and image.
• Humanity Protocol ensures the user’s identity is verified on-chain, but personal details aren’t revealed.
• Submit the transaction, paying gas to deploy a new fundraiser on the Ethereum testnet.

3. Browse Fundraisers:

• Anyone can explore active campaigns by clicking “Explore fundraisers.”
• Filter by active or completed campaigns, or search by keywords.

4. Donate:

• Choose a fundraiser and click “Donate.”
• Enter the USDC amount, confirm the transaction, and the contract automatically approves & transfers USDC, which is then deposited into Aave for yield generation.

5. Withdrawal:

• Campaign owners can withdraw their USDC plus any accrued yield at any time. The on-chain identity (via Humanity Protocol) ensures that only the verified owner can withdraw.

All data—campaign details, donations, user addresses, and yield info—are recorded on-chain. This ensures transparency and immutability. Humanity Protocol handles identity verification, preventing fraudulent campaigns without a centralized KYC process.

The project architecture and development process

Front End: Built with Next.js and Tailwind CSS for a clean, responsive UI. The user connects via MetaMask.
Smart Contracts: Written in Solidity and deployed on Ethereum testnet (Sepolia). The main contract:
Stores fundraiser details on-chain.
Manages USDC donations, deposits them into Aave, and tracks yield.
Withdrawals can only be done by the verified fundraiser owner.
Humanity Protocol: Provides on-chain identity verification (trustless KYC). Our UI checks the user’s Humanity ID to ensure they’re verified, but no private data is revealed.
Aave Integration: Donated USDC is automatically deposited into Aave, generating yield until the owner withdraws.
APIs & Services: We used Alchemy/Infura for Ethereum node access, and integrated Humanity Protocol testnet endpoints for verifying identity claims.
During development, we iterated rapidly using Git for version control and overcame complexities around ERC20 approvals, Aave’s deposit logic, and batch loading fundraiser data from the contract.

Product Integrations

Humanity Protocol: On-chain identity verification, ensuring fundraisers are launched by real, verified individuals without exposing their private data.
Aave: Lends donated USDC to generate additional yield for each fundraiser.
Infura / Alchemy: Ethereum node providers used to deploy and interact with contracts.
Metamask: Used by donors and campaign creators to sign transactions and hold USDC.

Key differentiators and uniqueness of the project

Trustless KYC: Fundraiser owners are verified via Humanity Protocol, ensuring authenticity without a centralized KYC system.

Yield Generation: Donations are not idle; they’re automatically deposited into Aave for extra growth.

Global, Permissionless Access: Anyone with an Ethereum wallet can start or donate, crossing traditional banking or national barriers.

Transparent & Immutable: All campaign data and donation records are stored on-chain for public audit, building donor trust.

No Central Censorship: Unlike centralized platforms, there’s no single entity to freeze or block campaigns.

Trade-offs and shortcuts while building

Single Token: We only accept USDC for simplicity. In the future, we’d integrate Chainlink oracles to support multiple tokens and stablecoins.

No Subgraph: We currently load fundraiser data by calling the contract directly (batchGetFundraisers). A custom subgraph or The Graph integration could improve performance.

Limited NFT/Gamification: While we plan to offer donor NFTs or other gamification, we didn’t implement them fully in this hackathon version.

Manual Image Array: Images aren’t stored on-chain or IPFS yet; we rely on a local array or external URLs for demonstration.

Additional Features

All essential code—smart contracts, frontend (Next.js + Tailwind), and Aave/Humanity integrations—were built specifically for this hackathon.

We had no existing codebase before the event.

The features we’d like to add post-hackathon include NFT donation rewards, multi-token support, a subgraph for real-time data indexing, and more robust social sharing tools.