Show HN: Gauntlet–Challenge friends to Strava activities with real money (USDC)(gauntlet.bet)

1 pointsby lucidlogicvor 5 Monaten1 comments

Show HN: Gauntlet–Challenge friends to Strava activities with real money (USDC)

https://gauntlet.bet

Hey HN,

  I built Gauntlet (gauntlet.bet) — a platform where you challenge friends to fitness activities on Strava with real money on the line. Stakes are held in USDC on Base L2, so payouts are instant and transparent. No
   internal ledger — everything is on-chain.

  How it works:
  - Create a challenge (e.g. "Run 10K before March 1st — $25 stake")
  - Invite friends or make it open
  - Everyone stakes USDC via an embedded wallet (Privy)
  - Strava verifies completion automatically
  - Winners split the pot, losers lose their stake

  Tech stack: Laravel 12, React 19, Inertia.js, Tailwind, MySQL. Blockchain side is a Node.js sidecar using viem for USDC transfers on Base. WebSockets via Laravel Reverb for real-time challenge updates.

  Why on-chain? I didn't want to deal with holding user funds or building a ledger. USDC on Base means ~$0.01 transaction fees, near-instant finality, and users can verify everything. The embedded wallet (Privy)
  means nobody needs to know what a wallet is — they just sign in with email or Google.

  What I learned:
  - Nonce management for sequential blockchain transactions is painful — ended up using cache locks to serialize payouts
  - fake() doesn't work in production (learned this the hard way today)
  - Strava's webhook API is solid but their rate limits are aggressive

  Solo project, built over ~2 weeks. Would love feedback on the concept and any thoughts on the staking mechanics.

1 comments

Sem_prevor 4 Monaten

The nonce serialization problem is real — cache locks work but get hairy at scale, especially if you need concurrent payouts.

For the verification side (confirming stakes arrived), you might consider separating that from your sidecar entirely. Watching the chain for a specific USDC amount + matching it to an intent is a well-defined problem that doesn't need to live in your app logic.

I'm building something in this space (PayWatcher — verification-only, non-custodial, $0.05 flat on Base). Would have saved you the transfer event parsing at least. Curious how you handle confirmation edge cases like reorgs.