The problem Giggo 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.

Challenges I 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.