Superfan One
The onchain music launchpad, powered by Base.
Created on 30th April 2025
•
Superfan One
The onchain music launchpad, powered by Base.
The problem Superfan One solves
The Problem
Releasing music still feels like gambling in the dark. Artists spend months crafting songs, pulling favors, paying out of pocket, only to face delays, unclear splits, and messy backend deals once the music is ready. Curators and early supporters, the ones who often spark a track’s momentum, are rarely part of the process in a meaningful way.
How We Help
Superfan One is an onchain launchpad for music releases. Artists, musicians, engineers, contributors, labels, and curators can launch a new project, set revenue splits, raise funding, and generate royalties for post-release payouts; all through a simple, creator-first interface. This all happens on Base using USDC and a splits contract without the user ever knowing it
Breakdown
Each launch creates a project backed by its 0xsplits smart contract [Example Proof of Deployment via Basescan shown in the Projects Page]. Curators and fans can syndicate support for these projects using USDbC and receive splits of future royalties. Right now, this part is done manually for demo purposes. Each deal is isolated with transparent terms, automated distributions, and Base-native infrastructure.
The platform gives artists and curators a modern music capital stack, letting them figure out splits and financing without giving up rights, and automating their royalty distributions. Superfan One is the capital stack for the culture layer, giving music creators the tools to structure and fund their releases without middlemen.
What I Plan to Build Next:
Next, I plan to implement native withdrawal functionality directly within the app, so collaborators can off-ramp their USDC earnings without ever needing to interact with a wallet. I aim to integrate instant fiat offramping, enabling automatic payouts to users' connected bank accounts or cards. The entire flow, from revenue collection to fiat disbursement, will be abstracted from the user. They won’t need to manage a wallet or understand stablecoins; they’ll simply receive their share of royalties, on time and in the currency they use.
In addition, I plan to integrate with partner distributors, TooLost and Revelator Labs, so that royalty payouts can be sent directly to each project’s Base split contract, eliminating any need for manual deposits or intermediaries. This would make the system fully onchain, automated, and seamless from DSP to collaborator.
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.