Sonora Beats: Designing a Royalty Engine for African Artists

The Royalty Problem in African Music

The African music industry is booming. Afrobeats, Amapiano, and Bongo Flava are topping global charts, and streaming numbers are growing at 35% year-over-year. Yet the artists creating this music face a persistent problem: they have no idea how much they're owed, or when they'll get paid.

Traditional royalty systems are opaque, slow, and riddled with intermediaries. An artist might wait 6–9 months to receive streaming royalties, with no visibility into how the final number was calculated. Splits between collaborators (producers, featured artists, songwriters) are tracked in spreadsheets — or worse, verbal agreements — leading to disputes and lost income.

Sonora Beats was built to fix this. Our royalty engine processes streaming data in near real-time, calculates per-stream payouts with full transparency, and distributes earnings to artists within 48 hours of a stream occurring.

Architecture of the Royalty Engine

Data Ingestion

Sonora Beats aggregates streaming data from multiple DSPs (Digital Service Providers): Spotify, Apple Music, Boomplay, Audiomack, YouTube Music, and our own integrated player. Each DSP reports streams in a different format and at a different frequency.

We normalize all incoming data into a common Stream Event schema:

interface StreamEvent {
  eventId: string;          // Idempotency key
  trackId: string;          // Sonora Beats internal track ID
  dspId: string;            // Which platform
  dspTrackId: string;       // Track ID on the DSP
  streamTimestamp: string;  // ISO 8601
  territory: string;        // ISO 3166-1 alpha-2 country code
  streamType: "free" | "premium" | "offline";
  durationMs: number;       // How long the user listened
  userId?: string;          // Anonymized DSP user ID (if available)
}

Events are ingested via a Kafka cluster with per-DSP topics. A Flink job validates, deduplicates (using the idempotency key), and enriches each event before writing it to our analytics data lake (Apache Iceberg on S3).

Royalty Calculation

The calculation engine runs as a scheduled micro-batch job every 4 hours. For each batch, it:

1. Aggregates streams per track per territory per DSP for the batch window
2. Looks up the per-stream rate for each DSP/territory/stream-type combination. These rates are updated monthly based on DSP reports and stored in a versioned rate table
3. Calculates gross revenue per track: streams × per_stream_rate
4. Applies splits according to the track's split sheet (stored immutably on-chain — more on this below)
5. Deducts the Sonora Beats platform fee (a transparent 10%)
6. Credits each stakeholder's wallet in our internal ledger

Gross Revenue = Σ (streams_per_territory × rate_per_territory)

Artist Payout = Gross Revenue × artist_split_percentage × (1 - platform_fee)

Split Sheets on the Blockchain

One of the biggest sources of royalty disputes is disagreement about who owns what percentage of a track. Sonora Beats solves this by requiring all collaborators to sign a digital split sheet before a track is distributed.

The split sheet is stored as a smart contract on the Polygon blockchain. Once all parties have signed (via wallet signature or Sonora Beats account verification), the split is immutable — nobody can change it after the fact, eliminating the most common source of disputes.

// Simplified split sheet contract
contract SplitSheet {
    struct Split {
        address payee;
        uint256 basisPoints; // 10000 = 100%
    }

    Split[] public splits;
    bool public finalized;

    function addSplit(address payee, uint256 basisPoints) external onlyAdmin {
        require(!finalized, "Split sheet is finalized");
        splits.push(Split(payee, basisPoints));
    }

    function finalize() external onlyAdmin {
        uint256 total = 0;
        for (uint256 i = 0; i < splits.length; i++) {
            total += splits[i].basisPoints;
        }
        require(total == 10000, "Splits must sum to 100%");
        finalized = true;
    }
}

The actual payment distribution happens off-chain (for speed and cost reasons), but the split percentages are always verifiable on-chain.

The Artist Dashboard

Transparency is meaningless without accessibility. We invested heavily in the Artist Dashboard — a real-time analytics interface that gives artists unprecedented visibility into their earnings.

Key Features

• Live stream counter: Artists can watch their streams tick up in near real-time (approximately 15-minute delay from actual stream to dashboard update)
• Revenue breakdown: Earnings broken down by DSP, territory, track, and time period. Artists can answer questions like "How much did my latest single earn from Nigerian Spotify Premium users last week?"
• Comparative analytics: See how a new release is performing vs. previous releases at the same point in their lifecycle
• Audience insights: Geographic distribution, listener demographics (age, gender, where available), and playlist placements
• Payout history: Complete ledger of every payout, with links to the on-chain split sheet and the underlying stream data

Design Decisions

We designed the dashboard mobile-first, because 78% of our artist users access it primarily from their phones. Key UX choices:

• Progressive disclosure: The home screen shows a single headline number (total earnings this month) with drill-down capability. We don't overwhelm artists with data they didn't ask for
• Local currency: All monetary values are displayed in the artist's local currency by default, with a toggle to switch to USD. We update exchange rates hourly
• Offline mode: The dashboard caches the last 7 days of data locally, so artists can review their earnings even without connectivity
• Notification system: Configurable alerts for milestones (e.g., "Your track just hit 100K streams!") and payouts

Streaming Analytics Pipeline

Behind the dashboard is a real-time analytics pipeline that processes millions of events per day.

DSP Reports ──> Kafka ──> Flink (validate, dedupe, enrich) ──> Iceberg (data lake)
                                                                     │
                                                     ┌───────────────┼───────────────┐
                                                     ▼               ▼               ▼
                                               Druid (OLAP)   Royalty Engine   ML Models
                                                     │                              │
                                                     ▼                              ▼
                                              Artist Dashboard            Trend Predictions

We use Apache Druid as our OLAP engine for powering dashboard queries. Druid's combination of columnar storage and inverted indexes lets us serve complex analytical queries (e.g., "top 10 tracks by revenue in Ghana this week, broken down by DSP") in under 200 ms even across billions of rows.

Payment Infrastructure

Once earnings are calculated, we need to actually get money to artists — across 30+ African countries with different banking systems, mobile money providers, and regulatory requirements.

We built a payment routing layer that supports:

• Mobile money (M-Pesa, MTN MoMo, Airtel Money, Orange Money) — most popular, used by 64% of artists
• Bank transfer (local and international) — used by labels and established artists
• Cryptocurrency (USDC on Polygon) — growing in popularity, especially among diaspora artists

The minimum payout threshold is $5 (or local currency equivalent), which is deliberately low — we believe artists should have access to their earnings as soon as possible, not be forced to accumulate a large balance.

Impact

Since launching in August 2025, Sonora Beats has:

• Onboarded 14,000 artists across 22 African countries
• Processed 280 million streams
• Distributed $3.2 million in royalties directly to artists
• Reduced average time-to-payment from months to under 48 hours
• Resolved split disputes before they start — zero disputes on tracks with on-chain split sheets

Learn more at sonorabeats.com.