How I Built a Real-Time Bounty Marketplace with Supabase and 14-Layer Edge Security

I wanted to build a platform where anyone can post a task (a "bounty"), set a reward, and have people complete it with verifiable proof. Think freelance work, but optimized for quick, composable task completion — with proof submission as the core trust mechanism.

The result is BountyClaimer — a real-time marketplace running on Supabase + Vercel with a security system baked into Edge middleware and scattered across every layer of the stack.

🛠️ The Tech Stack

• Frontend: React + Vite + TypeScript
• Backend: Supabase (PostgreSQL, Realtime, Storage, Auth)
• Payments: Stripe
• Hosting: Vercel (Edge Middleware)
• Security: Custom "Armadillo" system (14 layers)
• Architecture Pattern: Phoenix Architecture for real-time state consistency

🔄 The Core Workflow

1. Post — A user posts a bounty with a reward and description
2. Claim — Others browse and claim available bounties
3. Submit — The claimer completes the work and submits proof (images, video, audio, text, files)
4. Settle — The bounty owner reviews and approves — funds are released
5. Sync — Real-time updates keep both sides in sync instantly

The hardest parts were real-time state sync across multiple users, anti-abuse without hurting legitimate users, and security at the edge.

🏛️ The Phoenix Architecture

One pattern I'm particularly proud of is what I call the Phoenix Architecture — a real-time state management approach that ensures every client sees the same truth without polling.

The core idea: instead of each client fetching data and hoping it's current, database changes (bounty status updates, proof submissions, claim state transitions) are broadcast out via Supabase Realtime. Every connected client receives the same event stream and updates locally.

// The Phoenix pattern — subscribe to changes once, 
// update locally from the event stream
const channel = supabase
  .channel(`entity-${id}`)
  .on(
    'postgres_changes',
    { event: '*', schema: 'public', table: 'updates' },
    (payload) => {
      syncState(payload.new)  // Single source of truth
    }
  )
  .subscribe()

No polling, no stale data, no "refresh to see new submissions." Combined with server-side validation in PostgreSQL functions, this means business rules are enforced at the database level and the UI reflects reality immediately.

🛡️ Security at the Edge (The Armadillo System)

The most interesting engineering challenge was Armadillo — a layered security system that operates at Vercel's Edge network, intercepting every request before it reaches the application. It's designed around defense-in-depth:

What it checks (at the Edge, before a request hits the app):

• Scanner/recon tool detection — blocks known malicious user agents
• SQL injection and XSS scanning with multi-pass URL decoding
• Rate limiting per IP with memory-efficient data structures
• Adaptive proof-of-work challenges for suspicious traffic
• Behavioral analysis and entropy-based bot detection
• Cross-region threat intelligence sharing

The key insight was that security at the Edge catches attacks before they consume any compute resources. Scanner probes, injection attempts, and DDoS patterns are stopped at the network boundary.

There's also a client-side component that runs in the browser — fingerprinting, behavioral analysis, and monitoring that feeds data back to the system. Between the Edge middleware, the database layer, and the client, no request goes unchecked.

🔐 Database Patterns

All critical operations (bounty creation, proof submission, claim settlement) go through PostgreSQL functions. This keeps business logic next to the data and prevents race conditions that could occur with API-layer checks. The pattern is straightforward: validate → execute → return. If validation fails at the database level, no amount of API trickery can bypass it.

🧠 What I'd Do Differently

• Fewer initial proof types — Supporting everything (image, video, audio, text) from day one adds complexity. Start with text, expand later.
• Whitelist static files in middleware early — Static assets like manifest files can accidentally trigger your own security puzzles if you forget to exempt them.
• Supabase type regeneration — After schema changes, regenerate TypeScript types immediately. Don't learn this one the hard way.

📝 Lessons Learned

Building a marketplace with real money involved means security isn't a feature — it's the foundation. The Armadillo system started as a simple rate limiter and grew into something much more comprehensive. The Edge middleware approach means attacks are stopped before they consume resources, and the Phoenix Architecture pattern keeps real-time state consistent without complex client-side logic.

The platform is live at bountyclaimer.com — I'd love feedback on the workflow, the architecture, or anything that stands out. Drop questions in the comments! Thanks for taking the time to read about my project:)