CrowdFundiee
Empowering Ideas, One Decentralized Contribution at a Time.
Created on 2nd December 2024
•
CrowdFundiee
Empowering Ideas, One Decentralized Contribution at a Time.
The problem CrowdFundiee solves
Raising Funds Transparently
Creators, entrepreneurs, and organizations can raise funds for projects, startups, or social causes.
Blockchain technology ensures transparency, making it easy for backers to verify where their money is being used.
Decentralized Donations
Eliminates the need for intermediaries, reducing transaction fees and delays in fund transfers.
Direct wallet-to-wallet transactions ensure trust and reliability.
Smart Contract-Driven Security
Funds are held in smart contracts, ensuring they are only released when pre-defined milestones or conditions are met.
This makes fundraising safer for backers, reducing the chances of fraud.
Global Accessibility
The platform is accessible to anyone with an internet connection and a crypto wallet, allowing creators to reach global audiences for funding.
Immutable Records
Every transaction is recorded on the blockchain, creating an unchangeable and auditable record of all contributions.
This builds accountability and trust between fundraisers and backers.
Tokenized Rewards
Fundraisers can offer tokenized incentives to backers, such as NFTs or governance tokens, enhancing engagement and providing additional value
Challenges we ran into
Bug Description:
While implementing the smart contract for the crowdfunding platform, I faced an issue with the fund release logic. Specifically, the contract failed to release funds when the milestone condition was met. Instead, the transaction reverted with an "out of gas" error.
Root Cause:
After debugging, I discovered that the issue was due to an infinite loop in the function handling payouts. The function iterated over a list of contributors and attempted to process all payments in a single transaction. For a large number of contributors, the gas limit was exceeded.
Solution:
Optimized Smart Contract Design:
I restructured the logic to process payments in batches rather than in a single transaction.
This reduced the gas usage per transaction.
Used msg.sender for Self-Execution:
I allowed contributors to claim their funds individually by calling the withdrawFunds() function, shifting execution responsibility to them.
Testing and Gas Optimization:
Ran multiple test cases using tools like Hardhat and Remix to identify and optimize other high-gas functions.
Tracks Applied (1)
Consumer Track
Base