Building ProtoForge: A Royalty Engine for Independent Artists

Production music publishing is a strange corner of the music industry. Thousands of tracks get licensed for TV, film, and advertising every day, but the infrastructure behind royalty splits, contract terms, and payment flows is still shockingly manual. Spreadsheets, PDFs, email chains. ProtoForge exists to fix that.

The problem space

When a production music library licenses a track, the revenue needs to be split between the composer, the publisher, and sometimes a dozen other rights holders. Each track can have different split ratios, different territories, different terms. Multiply that across a catalogue of 10,000 tracks and you get a nightmare of complexity.

Most libraries handle this with a combination of spreadsheets and legacy software that was designed for a different era. The result: royalty payments are slow, opaque, and frequently wrong. Artists don't trust the numbers because they can't see how they were calculated.

Why we built it

ProtoForge grew out of work I was doing on Protomuse, the broader music infrastructure platform. We kept running into the same problem: you can't build transparent artist tools on top of opaque financial infrastructure. The plumbing needed to be rebuilt from scratch.

Architecture decisions

The core insight was that royalty contracts are essentially deterministic state machines. Given a set of inputs (revenue, territory, date, rights holders), the output (payment splits) should be completely predictable. No ambiguity, no interpretation.

We built ProtoForge on three pillars:

• Contract-as-code: Every deal is defined as a structured data object, not a PDF. Terms, splits, escalators, and expiry dates are all machine-readable.

• Real-time computation: Built on Convex for reactive queries. When revenue comes in, splits are calculated instantly and everyone sees the same numbers.

• Audit trail: Every calculation is logged. Artists can trace any payment back to its source — which track, which licence, which contract clause.

The Convex decision

We chose Convex as the backend because royalty calculation is inherently reactive. When a new sync licence is reported, affected rights holders need to see updated earnings immediately — not after a nightly batch job. Convex's real-time subscriptions made this natural.

The schema is deliberately rigid. Contracts are validated on write, not read. If a split doesn't add up to 100%, the mutation rejects it. This front-loads complexity into the authoring step, which is exactly where human attention should be.

What we learned

Building financial infrastructure for creative people is a UX challenge as much as a technical one. The artists using ProtoForge don't care about state machines — they care about can I trust this number? and when do I get paid?

A few lessons from the first year:

• Show the math. Transparency isn't a feature — it's the entire value proposition. We render the full calculation chain for every payment.

• Batch vs. real-time is a spectrum. Some operations (monthly statements) are still batch. The key is making the real-time parts feel instant.

• Music rights are global. Territory handling was harder than the core split logic. Different PROs, different rules, different timelines.

What's next

We're working on integrating with collection societies for automated reporting, and building a self-serve onboarding flow so independent publishers can set up their own catalogues. The vision is simple: every artist should be able to see exactly where their money comes from, in real time, with zero ambiguity.

ProtoForge is the engine. Protomuse is the experience layer. Together, they're the stack I wish existed when I started working in music tech.