The problem StarkGuild solves

Donating & Quadratic Funding

In each matching round, there will be a a Total Match of which this represents the total amount of funds donated from various sponsors. This sponsored amount will be shared across all projects in the pool in a Quadratic Funding manner.

During the voting period, all registered users are able to donate any amount to their project that they like and a portion of the matched amount will be allocated to the project.

Quadratic funding ensures a 'fair' way of distributed the total sponsored amount as a single large contribution by an individual will amount to less weightage compared to many many small donations by many different individuals.

User Registration

To reduce the risk of donars gaming the quadratic funding mechanism by creating many accounts and donating smalls amounts through the different accounts, we have also implemented a User registration mechanism of which each address can only be registered to a unique github account id.

Claiming

After the voting period ends, project owners will be able to claim their donations in a streamed fashion. The total amount will be distributed gradually over time. On top of that, from time to time, project owners will be required to submit a project report through IPFS, to allow admin to verify if actual progress has been made. The admin will be able to limit how much of the final amount the project should have gotten in the case where the progress has not reached the milestone

Challenges we ran into

Backend Challenges

• Unfamiliarity with Cairo syntaxes causes development time to take longer than usual.
  • Release important features first to be integrated instead of having a readied backend. Avoid waterfall management.
• Lack of sync with frontend integration side led to initially created api to be too hard to integrate within a short timespan.
  • Revamp core.cairo to coreV2.cairo to provide better apis for easier integration.
• Overly focused on writing 100% test coverage led to longer than expected development time. Though this have helped us to find bugs. There are functions which can be tested less rigorously given that the time is constraint.
  • Managed to overcome this with grinding. Proper test planning should be carried out next time.

Frontend Challenges

• Working directly on the code instead of design first, causing the need to make multiple changes in style that took more time off our limited time.
  • On the second day of hackathon, we drew a wireframe which takes some time but we could save more time in the end.
• Reliance on getting the smart contract abis first instead of discussing and conforming to an agreed upon API for integration, pushing most integration work (which is more challenging work) at the end of development
  • Proper discussion and agreeing upon API for integration should be carried out next time.
• Task distribution between team members as most of us are working with each other for the first time, and don't yet have full understanding of each other's strength.
  • There isn't much issues, but is definitely something that'll help us work together even more effectively in the future after this