Superfan One
The Membership Platform for Music
About
The problem it solves ***Superfan One is building the Membership Layer for Music.*** Music fandom lives in moments: a show, a drop, a pop-up, a premiere. But those moments are scattered across ticketing systems, merch stores, social platforms, and DMs. There’s no single place where an artist or label can recognize and reward a fan consistently. Existing “loyalty” solutions in music either feel generic (points with no culture), opaque (data stuck inside third-party platforms), or overly financialized (tokens pitched as investments). Superfan creates the missing membership layer. Each artist, label, or curator runs their own Club, with a Pass that fans can claim with one tap. From there, every interaction (whether scanning a QR at a show, pre-saving a track, or showing up at a pop-up) earns Points and builds Status. Fans climb status, and along the way unlock real perks: presale tickets, line-skip privileges, studio visits, vinyl lotteries, and even allocations for top-tier accredited members. For fans, it’s a **seamless path from casual listener to recognized insider**. For operators, it’s a simple toolkit that turns scattered engagement into a cohesive membership program: complete with CRM, campaign tools, payments, and redemptions. And for the culture, it’s a way to make fandom visible, valued, and rewarded without putting crypto jargon front-and-center. **No wallets, tokens, or jargon exposed to consumers**. Just tap, earn, and unlock. All crypto rails (Base, embedded wallets, USDC, KYC) stay silent under the hood. Smart Contract Address(es) HouseAccountManager (single-contract MVP) **What it does** Custodies USDC per (user, club). Lets operators credit balances (after fiat → USDC settlement) and debit on redemption. Emits clear events for analytics/reconciliation; no fan-facing tokens needed. **Core storage** mapping(address user => mapping(uint256 clubId => uint256 balance)) mapping(uint256 clubId => uint256 liability) (sum of balances) address usdc (allow-listed stable) Roles: PLATFORM_ADMIN, CLUB_OPERATOR[clubId], PROCESSOR (credits) **Key functions** credit(uint256 clubId, address user, uint256 amount, bytes32 topUpId) – Processor moves USDC in via transferFrom and credits balance; marks topUpId. debit(uint256 clubId, address user, uint256 amount, bytes32 reason) – Operator debits on redemption (POS / app), emits receipt event. sweep(uint256 clubId, address to, uint256 amount) – Move recognized revenue to the club payout wallet (post-reconciliation). quarantine(bytes32 topUpId) / release(bytes32 topUpId) – Handle disputes/chargebacks on specific top-ups. setOperator(uint256 clubId, address operator, bool allowed) – Permission who can debit/sweep for that club. **Events** Credited(clubId, user, amount, topUpId) Debited(clubId, user, amount, reason) Swept(clubId, to, amount) Quarantined(topUpId) / Released(topUpId)
How it's made
Challenges we ran into **1) Making crypto invisible for fans** Hurdle: Most Web3 tools push wallet setup and chainspeak up front; that kills conversion at the merch table and on mobile. Solution (expanded): We made “email/phone → Pass” the only fan-facing step. Behind that, Privy spins up an embedded wallet and we map fiat top-ups (Stripe/Apple/Google Pay) to onchain ledger movements in the background. We batch and sponsor gas so no fees or signatures appear for fans. Recovery is handled with seedless flows (device + email/phone), and we avoid any chain UI unless a user explicitly opts in. On the ops side, we built a degraded mode: if Base/rpc blips mid-show, tap-ins buffer locally, generate a signed receipt, and sync to chain when back online. The result: fans just tap and see Points/Status update instantly; the crypto machinery stays silent. **2) Designing a universal points + status system** Hurdle: “Generic loyalty” doesn’t fit music culture, but purely vibes-based systems can’t be measured, tuned, or defended against gaming. Solution (expanded): We defined a scoring function with decay that blends spend, events, referrals, and content interactions: score = 0.8*log(1+spend)*100 + 40*events + 25*referrals + 10*content Logarithmic spend prevents whales from breaking the ladder; decay (1%/day after 30 days inactive) rewards consistent participation. Operators can tweak weights per Club (with guardrails) and run time-boxed boosts (e.g., double points during a premiere window). Anti-gaming: rate limits on tap-ins, replay protection via nonce’d QR payloads, device fingerprint hints, and referral caps. Explainability: fans see progress rings and exactly what actions move the needle; operators get lift charts and cohort views to tune the funnel without guesswork. **3) House Account accounting** Hurdle: Prepaid balances are a liability until redemption; creators need clean books, instant spends at the booth/door, and protection against chargebacks. Solution (expanded): We introduced a HouseAccountManager contract as source of truth for balances and a mirrored ledger (Supabase) for speed and analytics. Top-ups: fiat → USDC → ledger credit; funds earmarked to the Club with clear liability tagging. Redemptions: one-tap spend emits an onchain receipt; the pass shows a pickup code or digital claim link. Reconciliation: nightly jobs compare contract events with the ledger (idempotent replays), flag deltas, and generate journal entries (deferred revenue → recognized). Edge cases: partial refunds/voids, chargeback quarantine for disputed top-ups, per-perk taxes/fees allocation, and multi-collaborator split payouts on redemption. Operators see real-time available balance vs. liabilities; auditors get a clean trail. **4) Compliance around allocations** Hurdle: We wanted top-tier fans to access small insider allocations on select projects—without turning the whole product into a public securities sale. Solution (expanded): Allocations sit inside Unlocks but are double-gated: (1) Status threshold (e.g., Superfan) and (2) KYC + accreditation. The UI only renders allocation cards for eligible, verified users; everyone else just sees culture perks. Allocation flows trigger a separate SPV/SAFT doc set with clear disclosures, and we log a tamper-evident terms checksum onchain. We support both soft-circle pledges and final settlement; no general solicitation is shown to ineligible users. Data handling follows least-privilege—we store only verification proofs/tokens from the KYC provider, not raw PII. This keeps v1 firmly “loyalty/access,” while allowing compliant capital moments for a narrow, vetted subset.