SponsorHub
Performance-based creator marketing infrastructure
Confidentiality Note
Code is private during active development. This case study covers architecture, system invariants, and engineering decisions — not implementation details. Happy to walk through architecture and modules live.
A platform where brands fund campaigns, creators drive verified conversions, and payouts happen only when performance is proven. Every dollar is tracked from deposit to payout through an append-only ledger.
Problem
Creator marketing lacks accountability. Brands pay upfront with no proof of performance. Creators get stiffed when brands dispute results. No platform enforces funding, attribution, and verification end-to-end.
Solution
SponsorHub enforces three invariants in code: (1) campaigns cannot go live without confirmed funds in escrow, (2) every conversion is verified through platform-owned attribution artifacts before entering the ledger, and (3) payouts are computed strictly from the append-only ledger — no verification, no payout.
Architecture
- Client → /r redirect (HMAC-signed attribution link) → /v verification ingestion → Append-only event ledger
- Rollup jobs (BullMQ) → Payout computation → Stripe Connect disbursement
- State machines with guards enforce campaign lifecycle: Draft → Funded → Live → Completed → Paid Out
- Each transition requires explicit preconditions — Live requires escrow confirmation from Stripe webhook
- Platform-owned attribution artifacts carry HMAC-signed payloads with campaign/creator identifiers
- Verification events deduplicated by composite key and checked against replay windows
Security & Reliability
- HMAC-signed attribution artifacts — tamper-evident redirect links and promo codes
- Replay protection — events deduplicated by composite key + time window
- Append-only ledger — no UPDATE/DELETE on conversion events; corrections via compensating entries
- Idempotent Stripe payouts — retry-safe disbursement with idempotency keys
- Role-gated access — Clerk RBAC enforces brand/creator/admin boundaries
- Hashed identifiers — PII never stored in plain text in event payloads
- Funding gate — state machine rejects Live transition without escrow confirmation
- Budget cap enforcement at the ledger rollup layer
Results
- MVP backend complete with state machine enforcement and append-only ledger
- Stripe Connect integration with idempotent payout processing
- Hybrid payout model (base + performance) for creator fairness
- Fraud/risk scoring pipeline architected for conversion validation
Tech Stack
Artifacts
Architecture Diagram
[placeholder — to be added]
Threat Model
[placeholder — to be added]