Superfan One
Superfan is a launchpad and toolkit for artists.
Created on 30th April 2025
•
Superfan One
Superfan is a launchpad and toolkit for artists.
The problem Superfan One solves
Superfan is a financing launchpad and operating system that helps artists fund, manage, and release music with their team: no label needed.
In today’s music industry, artists often rely on outdated systems: advances from labels that act like loans, backroom splits tracked in spreadsheets, and delayed royalty payments filtered through intermediaries. We bring structure and clarity upfront in an industry built on handshakes and vague promises. Everyone involved, from producers to engineers to curators, knows their role, their cut, and their value from day one
Each project on Superfan starts with a pitch. Artists and their teams set a funding goal, agree on how profits will be shared, and invite fans, curators, or investors to support the release. Once the presale target is hit, the project is officially greenlit.
Under the hood, Superfan includes everything artists need to run a release: split tracking, deal terms, file sharing, payment rails, and a live dashboard for every stakeholder. It’s the business layer of music, streamlined and under the artist’s control.
Challenges I ran into
Authentication
Privy authentication & UUID mapping: We faced issues connecting Privy authentication to our internal user records, especially around mapping Privy IDs to UUIDs in our system. This caused problems with correctly assigning edit and update permissions for projects, which we had to resolve to ensure creators could manage their drafted and published deals without errors.
Wallet Funding and Onboarding
We set out to enable users to fund their Privy-embedded wallets with USDC on Base via Coinbase Onramp, but the integration proved far more complex and under-documented than expected, taking several hours to debug. Our initial attempt relied on outdated widgets and backend API methods from Coinbase’s legacy documentation, many of which were deprecated or returned 404 errors. After identifying that the recommended approach now requires @coinbase/onchainkit, we installed it but immediately ran into a TypeError: getOnrampBuyUrl is not a function due to an incorrect import path and an outdated version of the package. Once we upgraded and imported correctly from @coinbase/onchainkit/fund, we encountered persistent 400 Bad Request responses when attempting to generate the onramp URL. These errors were caused by multiple overlapping issues: missing or malformed parameters (like projectId, wallet address, or network), domain mismatch due to our local environment not being whitelisted in the Coinbase dashboard, and the "Enforce Secure Initialization" toggle silently rejecting requests without meaningful error output. We spent hours discovering that OnchainKit was required, debugging silent failures from domain restrictions, missing params, and incorrect network values.
Privy compounded the problem, wallet addresses weren’t reliably accessible at the time of onramp initialization due to delayed authentication callbacks, and user metadata like UUIDs didn’t propagate cleanly between Privy and Coinbase, leading to runtime crashes (e.g., Cannot read properties of undefined (reading 'uuid')). Additionally, the network passed to getOnrampBuyUrl was incorrectly set to 'ethereum' instead of 'base', causing funding sessions to open on the wrong chain. We resolved the integration by using only the essential config (projectId and addresses), logging and validating wallet addresses post-auth, disabling secure initialization, and confirming our environment was whitelisted in the Coinbase dashboard. The final working flow now successfully opens the Coinbase Onramp with the user’s Privy-linked Base wallet pre-filled and ready to receive USDC.
Splits
During development, we faced a wide range of technical issues integrating 0xSplits, Privy, Supabase, and Coinbase Onramp into a unified onchain launchpad experience. The 0xSplits SDK lacked full withdrawal support and had missing methods in SplitV2Client, forcing us to manually manage contract interactions while also working around a broken subgraph by reading USDC balances directly from chain. We had to switch from ethers.js to viem for better type safety, fix wallet authorization issues (especially between MetaMask and Privy’s embedded provider), and explicitly manage account access to create splits. On the backend, Supabase caused errors due to misconfigured environment variables, missing schema columns, and strict RLS policies, which we resolved by rewriting policies and adjusting column types (e.g., casting creator_id from UUID to text).
The project publishing flow originally failed to deploy split contracts, requiring a full rewrite to inject contract deployment and persist the resulting addresses. We added wallet validation and required collaborator addresses to ensure onchain compatibility. I also had issues withdrawing funds from the 0xSplits warehouse contract using the SDK: withdraw wasn’t exposed in the version I was using, and attempts through SplitV2Client failed. I ultimately had to bypass the SDK and interact directly with the contract to enable withdrawal functionality.
Backend
Supabase integration issues: We ran into significant challenges with Supabase, particularly around file uploads, syncing collaborator data, and properly updating collaborator types and tags in both the database and front end. Naming issues with uploaded files were the bulk of the problem and we had to write scripts to rename all upload files.
Tracks Applied (2)
Stablecoins
Consumer
Technologies used
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.