The problem Superfan One 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.

Challenges I 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.8log(1+spend)100 + 40events + 25referrals + 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.

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)