Giggo
Freelancing Site and Prediction Markets for People
About
The problem it solves Most freelance marketplaces suffer from the same cold-start problem: **New freelancers can’t get work without reviews, and can’t get reviews without work**. Clients hesitate to trust unknown profiles, and promising talent often gets stuck in this loop. At the same time, platforms rely on centralized ratings and opaque algorithms, which are easily gamed or manipulated. There's little accountability when things go wrong, and even less incentive for communities to actively back trustworthy talent. **Giggo solves this by combining an onchain freelance marketplace with a peer-backed prediction mechanism**. Freelancers can **bootstrap trust** by letting friends, past collaborators, or even strangers vouch for their success with real money. Clients gain an **added layer of safety** — if the freelancer fails, part of the vouched amount is refunded to the client. Vouchers **earn a portion of the payout** if the freelancer delivers, turning **reputation into a prediction market**. All financial interactions (escrow, vouching, slashing) are onchain, ensuring **transparency and minimizing fraud**. Whether you're a developer breaking into the market, a client looking for reliable help, or a community member who believes in someone’s potential — Giggo lets you turn trust into action.
How it's made
Challenges we ran into **Designing for Trust and Incentive Alignment** One of the hardest challenges was figuring out how to align incentives across three very different user types: freelancers, clients, and vouchers. We wanted a system where: Freelancers are rewarded for good work, Clients are protected against bad actors, And vouchers are motivated to back only the most trustworthy talent. **Balancing the reward and slashing mechanisms took a lot of iteration**. We didn’t want the system to be easily gamed by sybil attacks or passive speculation. Our solution was to: - Tie vouching to specific gigs (not general profiles), - Add slashing mechanics that penalize failed bets, - And use offchain + onchain signals to calculate reputation more robustly. **Separating Data Layers** Another hurdle was deciding what goes onchain vs offchain. Putting everything onchain would be transparent but expensive and clunky. Keeping too much offchain risks trust and auditability. We resolved this by: - Using onchain contracts strictly for financial primitives (escrow, vouch, rewards), - Storing profiles, portfolios, and gig listings in a Supabase DB, - Indexing onchain data via The Graph for easy frontend queries and analytics.