What reached users, operators or an upstream project — the outcome, not just the code.
- Live baseFM station and public listener experience at basefm.space
TECHNICAL CASE STUDY / ONCHAIN MEDIA · LIVE STREAMING
baseFM
A radio and event platform built around the culture, not just the stream.
A community radio and event system combining DJ broadcasting, live audience features, direct wallet support, token-gated access and promoter tooling. The current station experience also uses Agentbot as its live-state and operator control layer.
Project artwork
DELIVERY EVIDENCE / ENGINEERING MATURITY
What reached the real world.
Delivered outcomes come first. The remaining categories show what is implemented, what has test evidence, what is deployed and what is still staged or planned.
Capabilities evidenced in source code or project documentation.
- Next.js application with Supabase/PostgreSQL and realtime integrations
- Mux RTMP-to-HLS streaming dependencies and documented broadcast workflow
- Base wallet tipping configuration for ETH, USDC, BASEFM and cbBTC
- Ticket UI offers USDC wallet transfer, card-payment link and door-payment choices
Automated test coverage or documented test evidence; not a blanket passing-build guarantee.
- README documents a Vitest suite of 55+ unit tests; a current passing CI run has not been independently verified for this case study
Live product surfaces or historically operated deployments, with scope stated.
- Public station is available at basefm.space
Known release boundaries, future work or areas not claimed as complete.
- No roadmap item is promoted to an implemented capability here; current operating details should be checked against the live station
THE PROBLEM
Why this needed
to be engineered.
Independent radio and event communities need more than a media player. They need reliable broadcast operations, artist discovery, audience participation, payments and event workflows that can coexist without forcing the culture into a generic streaming product.
Develop the radio, community and event surfaces as a connected web product. Use specialist streaming infrastructure for ingest and playback, a relational backend for profiles and realtime features, and wallet integrations for direct support and access control.
SYSTEM ARCHITECTURE
How the pieces fit together.
01
DJ broadcast ingest through RTMP with HLS playback and CDN delivery, with Mux dependencies and streaming workflows documented in the repository
02
Next.js web application for listeners, DJs and promoters
03
Supabase/PostgreSQL for profiles, schedules, chat and community data
04
Base wallet connection and token integrations for listener support and access
05
Ticket purchase UI with Base USDC wallet transfers, card-payment links and a door-payment option; the inspected client records an on-chain purchase after transaction confirmation
06
Event tools for tickets, check-in, crew and point-of-sale workflows
07
Agentbot control plane for current live state, relay status and broadcast operations
TECHNOLOGY CHOICES
Tools chosen for the job.
Separate broadcast transport from product logic
Mux handles the RTMP-to-HLS media path while the application focuses on users, schedules, access and event workflows.
Wallet-native participation
The wallet configuration supports ETH, USDC, BASEFM and cbBTC tipping on Base. The ticket purchase component also supports USDC transfers directly to a promoter wallet, with the client waiting for transaction confirmation before submitting the purchase record.
Realtime where it matters
Supabase realtime capabilities support audience chat and community interaction without turning every product surface into a polling loop.
Operational truth for live state
The current public station describes Agentbot as the canonical source for live state, relay truth and operator tooling.
ENGINEERING CHALLENGES
Problems solved along the way.
Reliable live broadcasts
A radio product needs to handle encoder workflows, stream state, playback and archive behaviour as one operational system.
Multiple user roles
Listeners, DJs and promoters need different controls and views while sharing a coherent product and identity layer.
Payments across rails
The platform connects wallet-native tips and ticket payments with conventional subscription/payment infrastructure where needed.
SOURCE & VERIFICATION
Inspect the work.
Current baseFM product↗Private source repository (access restricted)↗Ticket purchase flow and payment methods↗Supported Base tipping tokens and transfer ABI↗Project stack and feature overview↗Streaming and platform documentation↗
The baseFM GitHub repository is private, so the source links are evidence for authorised reviewers rather than public source access. The inspected ticket component exposes USDC, card and door payment choices; the wallet path transfers USDC directly to the configured promoter wallet and then submits a purchase record after the client observes transaction confirmation. This client-side flow is not described as a fully audited payment settlement or inventory-reservation system. The repository README and package manifest document the application stack and integrations. The public station's current operating model has evolved; the case study distinguishes the application stack from the live control-plane role.
NEXT / START A PROJECT
Have a similar challenge?
Tell me what you are trying to build. We can scope the right next step.