Lilith Metaverse · Features

Saraswati Stage: Fan Economy, Voice, Genre & Rights

A focused page within the Lilith Metaverse Features documentation. The full map and every sibling page live in the Features hub.

6sections13 minread2diagrams1table

On this page

Saraswati Stage is V3's virtual-artist tenant — six persistent AI musicians who release catalogs, hold stadium concerts, and run drop days inside the Lilith metaverse — and this page covers the half a fan touches with their wallet and the half that decides who gets paid for it. Where the personas, discography & performance page treats how an artist is authored and how a concert is staged, this page treats the economics around that artist: the tiers of fan participation, the consent-bound voice signature a persona sings with, the genre cell it is anchored to, and the collaboration / remix / sampling rights that govern how its tracks are reused and how disputes over them unwind. The burden of proof here is not "does this render?" but "is this provably attributable and rights-clean?" — a voice may not clone a public figure, a track may not ship without a visible remix-rights mode, a two-persona collaboration's split must total exactly 100% before it can publish, and a confirmed unlicensed-use claim must pause the catalog inside a day. Each of those is a deterministic gate or a fail-loud state machine in real, test-covered TypeScript under libs/v3/saraswati-stage (the @oshun/tenant-saraswati-stage package); the money that flows through them settles on the shared Aje payment substrate, treated in depth on the architecture companion, ../architecture/commerce-and-royalties.md. The takedown-and-unwind side it shares with the other tenants lives in commerce, rights & takedown. For the full feature scope this slots into, start at the hub: ../V3_features.md.

What ships, honestly#

The monolith describes a four-tier fan economy and a rich rights framework; the code implements the rights, voice, genre, and collaboration contracts and leaves the money rails to the shared commerce substrate. This page follows the code and says which is which.

  • Real and test-covered. @oshun/tenant-saraswati-stage is substantive, domain-specific TypeScript — fourteen source modules and a 15-entry capability descriptor (v3SaraswatiStageDescriptor, src/index.ts:17), persisted through a Prisma layer. The voice-signature builder, the genre-cell registry and binding, the cross-persona collaboration flow, the remix-rights catalog, and the Themis rights adjudication state machine are all genuine and deterministic. All 55 tests across six spec suites pass green (npx vitest runTests 55 passed (55), verified on box); the collaboration, voice, remix, and Themis modules are exercised through the consolidated index.spec.ts (34 of those 55), which asserts computed basis-point totals and blocked-status outcomes, not shape.
  • "Fan economy" here is a capability label, not a money engine. The descriptor advertises a fan-economy capability with an fan-economy:24ms-budget operational metric (src/index.ts:94), but there is no fan-economy.ts module in this library — the four participation tiers (free, club pass, signed editions, tips) are real, tested Rust in apps/v3/lilith-commerce-service (saraswati_free_tier.rs, saraswati_club_pass.rs, saraswati_signed_edition.rs, saraswati_concert_tips.rs, lilith_fan_token_boundaries.rs) settling through the shared @oshun/payments-bridge and libs/aje/*. What this library contributes to the fan economy is the catalog fans browse, the remix-rights catalog they buy from, the collaboration tracks they hear, and the rights adjudication that unwinds a purchase — plus the Prisma persistence for those records.
  • Voice scoring is a deterministic gate, not a live voiceprint model. reviewSaraswatiVoiceSignatureBuild decides build/block from injected similarity probe scores and a consent ledger; the acoustic voiceprint comparison that produces those scores is an upstream Lilith-Rights seam. The threshold logic (≥86% similarity blocks, ≤1% false-positive rate required) is real and tested.
  • Genre cells gate dossiers, not the composition pass. This library publishes the genre-cell registry, binds the six GA personas to distinct cells, and routes any cell-drift attempt to editorial review. The monolith's "a prompt that pulls the draft outside the cell is rejected at the composition pass" is the generation pipeline's job (libs/v3/isis-music), not this contract.
  • Remix tooling and watermarking are product surfaces. The three rights modes and their purchase-flow resolution are code here; the in-Studio remix editor and the personal-use-only watermark on a locked track are the Lilith Studio surface and policy, labeled as such below.

The fan economy#

The monolith defines four tiers of fan participation, "all built on Lilith-Commerce and Aje" (features§"Fan Economy"). The phrasing is exact: they are built on the commerce service, not on this tenant library. Mapping each tier to where it actually lives:

Tier What it grants Where it ships
Free Follow artists, browse the catalog, crowd-band Stadium seats, light-emoji saraswati_free_tier.rs (a first-class no-charge commerce state)
Club pass Monthly per-artist sub: club concerts (V3Mode_SaraswatiClub), pre-release listens, signed-edition raffles saraswati_club_pass.rs + lilith_subscription_billing.rs
Signed editions Limited-supply on-chain drops, resalable with secondary royalties saraswati_signed_edition.rs (editions of 250, 10% secondary royalty)
Tips Per-artist concert tips net of platform split saraswati_concert_tips.rs (10% platform / 90% artist)

What the TypeScript tenant owns is the content those tiers transact over, and its persistence layer makes that explicit. The Prisma schema (libs/v3/saraswati-stage/prisma/schema.prisma) carries three fan-economy models, each with a payloadHash integrity column that makes the shipped JSON provable against its row: V3FanInteraction (fanId, concertId, interactionType, amount — the tip/emoji/raffle record), V3SignedEdition (ajeTokenRef, editionNumber, supplyCap, resaleRoyaltyConfig, ownerV1UserId — the named, capped, resale-royalty-bearing edition), and V3RemixRights (mode, licenseTerms, secondaryRoyaltyConfig, trackId — the per-track rights record). The discography that the free tier browses is the same 12-track debut catalog this library publishes into the in-world store within 60 seconds (SARASWATI_IN_WORLD_CATALOG_MAX_PROPAGATION_SECONDS = 60, discography-release-flow.ts:86).

The honest seam is worth stating plainly: a fan's money — ticket, tip, subscription, edition mint, remix-license purchase — is computed and settled by the Rust commerce ledger and the Aje rails, and the deep treatment of the split math, anti-scalp ticketing, the 90-day credit ledger, and quarterly on-chain settlement is the commerce & royalties architecture page. A fan's entitlement to remix, the lineage credit on a collaboration, and the adjudication when a right is contested are what this library decides. Minor accounts (Saraswati Stage is 16+ at GA) cannot purchase signed editions or remix licenses — an age gate enforced at the commerce surface, not here.

Voice signatures and genre cells#

A Saraswati artist is not a model checkpoint; it is a persona dossier, a consent-bound voice signature, and a genre anchor. The persona-and-dossier side is the personas page; the parts that bear on rights and economics are the voice and the genre cell.

The voice signature and the public-figure block#

voice-signature-build.ts builds a persona's TTS voice signature only from consent-ledger source material, and it fails loud on every boundary the monolith's voice-cloning policy promises. reviewSaraswatiVoiceSignatureBuild (voice-signature-build.ts:215) requires a persona-saraswati-* id, a voice-sig:consent-ledger: reference, and at least 60 clean consented source minutes summed across grants (SARASWATI_VOICE_SIGNATURE_MIN_CLEAN_SOURCE_MINUTES = 60); it rejects any grant whose scope is not saraswati-persona-only or that carries a revokedAtIso. The safety-critical check is findPublicFigureMatch (:524): a probe scoring at or above SARASWATI_VOICE_SIMILARITY_MATCH_THRESHOLD_BASIS_POINTS = 8600 (86%) against a public-figure registry entry is a blocking issue, and the validation corpus's false-positive rate — computed as falsePositiveMatchCount / nonPublicFigureSampleCount in basis points — must stay at or under SARASWATI_VOICE_SIMILARITY_MAX_FALSE_POSITIVE_BASIS_POINTS = 100 (1%). buildSaraswatiVoiceSignature (:287) throws unless the review status is ready, so no model artifact is minted past a block.

signOffSaraswatiGAVoiceSignatures (:369) is the GA gate over all six personas (Raga Devi, Laila Qadri, Mira Sol, Amara Chen, Zahra Nile, Ines Vale). It first runs an adversarial probe — a 91.2%-similar public-figure voice (similarityBasisPoints: 9120, SARASWATI_GA_VOICE_CLONING_ADVERSARIAL_PUBLIC_FIGURE_PROBE, :198) — and asserts it resolves blocked before any signature builds; only then does it build all six from consent-recorded-only dossiers that bake in fanVoiceUploadsAccepted: false, each requiring a Lilith-Rights sign-off. The test bar is exact: passed is true only when all six built, the adversarial probe was rejected against the right identity, every dossier is complete with ≥60 total clean minutes, and every similarity check passed.

Two honest qualifications. The voiceprint similarity scoring itself is an injected input (registryProbeScores) — the acoustic comparison runs upstream in Lilith-Rights; this module owns the threshold and decision logic, not the DSP. And the code's ≥60-minute floor is the build gate, lower than the monolith's per-contributor ≥4-hour sourcing target — the richer "3–5 named human voice artists under signed contributor agreements" sourcing and the 12% contributor royalty pool are the Lilith-Rights operational contract and the Aje waterfall, not this gate.

flowchart TD in["voice-signature build input"] --> consent{"≥60 clean consented min?<br/>scope = persona-only?<br/>none revoked?"} consent -->|no| block1["blocked — consent gate"] consent -->|yes| pf{"public-figure probe ≥ 8600 bps?"} pf -->|yes| block2["blocked — public-figure match"] pf -->|no| fpr{"false-positive rate ≤ 1%?"} fpr -->|no| block3["blocked — FPR gate"] fpr -->|yes| built["ready → build signature + Lilith-Rights sign-off"]

Genre cells and style boundaries#

A genre cell is an operator-curated positioning vector, and genre-cell-registry.ts publishes the canonical six: electronic, indie-folk, hip-hop, classical-crossover, ambient, devotional (SARASWATI_GENRE_CELL_REGISTRY, :111). Each cell carries a six-dimension positioning vector (energy, acoustic-density, rhythmic-complexity, vocal-prominence, cultural-specificity, experimental-texture — integer scores 0–1000) and at least three editorial guardrails, each tagged policy, rights, or editorial severity and routed to a named review queue (lilith-rights, saraswati-editorial, or sophia-cultural-review). The guardrails are domain-specific, not boilerplate: the devotional cell forbids a persona from implying "religious initiation, lineage authority, or blessing power" (devotional-no-initiation-claims, a policy guardrail); hip-hop routes sampled interpolations to Lilith-Rights for explicit license refs (hip-hop-sample-license, rights); ambient blocks medical or sleep-cure copy. validateSaraswatiGenreCellRegistry (:282) is all-or-nothing — a missing cell, a wrong-length vector, an out-of-range score, or fewer than three guardrails is a blocking issue, and publishSaraswatiGenreCellRegistry throws on any.

genre-cell-binding.ts then anchors each of the six GA personas to exactly one distinct cell (createSaraswatiGAPersonaGenreCellBindings, :84 — Raga Devi to classical-crossover, Zahra Nile to hip-hop, and so on), each binding locked: true and inheriting its cell's guardrail ids. validateSaraswatiGAPersonaGenreCellBindings (:115) requires all six personas, all distinct cells, all locked. The teeth are in reviewSaraswatiGenreCellDriftAttempt (:226): when a proposed cell differs from the persona's anchor it returns status: 'editorial-review', blockedRuntimeRebinding: true, and routes to the saraswati-editorial-genre-boundary queue with an audit event — a persona cannot cross a cell boundary at runtime; it can only be re-anchored through a recorded editorial change. runSaraswatiGenreCellBindingDriftDrill (:263) proves it by stress-testing an accidental Raga Devi classical-crossover → hip-hop reassignment and asserting it lands in review, never silently rebinds.

Collaborations, remix, and sampling rights#

Every Saraswati track ships with a remix-rights setting, and disputes over rights route to Themis. All three mechanics — collaboration, remix catalog, adjudication — are real state machines in this library.

Cross-persona collaborations#

cross-persona-collaboration.ts lets two Saraswati personas co-release a track with their lineage credit and royalty split fixed before publish, not negotiated after. publishSaraswatiCrossPersonaCollaborationTrack (:113) throws unless the collaboration is editorially approved, the approval timestamp precedes release, and both the lineage-credit total and the royalty-share total equal exactly SARASWATI_COLLABORATION_SPLIT_TOTAL_BPS = 10_000 (100%) across exactly SARASWATI_COLLABORATION_REQUIRED_PERSONA_COUNT = 2 unique personas (validateCollaborationPersonas, :254). The royalty waterfall is validated route-by-route: every persona must have a matching aje:royalty:saraswati:collab: route whose share equals their persona share (validateRoyaltyWaterfall, :274), and every voice signature reference must be a voice-sig:consent-ledger:saraswati- ref — a collaboration cannot borrow an un-consented voice. The worked fixture is Raga Devi × Laila Qadri's "First Light Drift" (a 5,500 / 4,500 bps split, SARASWATI_RAGA_DEVI_LAILA_QADRI_COLLABORATION, :68); the tests prove a split that doesn't total 10,000 bps, or a waterfall missing a persona's route, is blocked.

The remix-rights catalog#

remix-rights-catalog.ts publishes one of three modes per track — open, licensed, or none — and resolves each to a purchase flow (resolveSaraswatiRemixRightsPurchaseFlow, :126):

  • Openopen-no-purchase-required: any fan may remix with attribution; a secondary royalty flows back on monetized use.
  • Licensedpurchase-enabled: a paid remix license is required before distribution. A licensed entry must require attribution, allow commercial use, and expose a stems:saraswati: stems-manifest reference, or normalizeRemixRightsEntry (:151) throws.
  • Nonepurchase-blocked: the track is locked; no purchasable license exists. A none entry that claims commercial use is rejected.

The whole catalog is gated: publishSaraswatiRemixRightsCatalog (:64) requires all 12 tracks, each with its rights mode visible on the catalog (visibleOnCatalog), and evaluateSaraswatiRemixRightsCatalogPublish asserts the purchase-flow status matches the mode for every entry. The actual remix editor and the personal-use-only watermark on a none track are the Lilith Studio music-authoring surface and policy — the contract this library enforces is that a fan can always see the rights mode and can never buy a license that the mode forbids.

Themis rights adjudication#

When a right is contested, themis-rights-adjudication.ts runs a three-stage state machine — file → decide → enforce — across four dispute kinds: remix-priority-claim, ownership-challenge, sample-use-claim, and independent-rights-holder-takedown. fileSaraswatiThemisRightsDispute (:145) requires namespaced ids and at least one piece of evidence on each side, and enforces a temporal invariant: every piece of evidence must be captured before the filing. issueSaraswatiThemisRightsDecision (:187) must reference the filed dispute and case, be final, and not predate the filing; its outcome (credit-claimant, uphold-original-rights, or pause-release) maps to a required enforcement-action set — a credit-claimant ruling must carry rights-record-updated and royalty-waterfall-updated; a pause-release must carry catalog-license-paused. enforceSaraswatiThemisRightsDecision (:232) closes the loop within a hard SLA: enforcement cannot predate the decision and cannot exceed SARASWATI_THEMIS_RIGHTS_MAX_ENFORCEMENT_MS = 86_400_000 (24 hours), and an action that updates a rights record, royalty waterfall, or catalog hold must carry the correctly-namespaced reference (rights-record:aje:saraswati:remix:, aje:royalty:saraswati:, catalog-hold:saraswati:).

Two fixtures encode the monolith's adversarial cases precisely. A fan (user:fan:amira-sen) files a remix-priority-claim with a timestamped remix master predating release; Themis rules credit-claimant, and enforcement updates the rights record and royalty waterfall. An independent rights-holder (nalin-music-estate) files an independent-rights-holder-takedown asserting an uncleared melodic source; Themis rules pause-release, and evaluateSaraswatiIndependentRightsHolderTakedownFlow (:325) asserts the catalog license is paused with a real catalog-hold ref inside the 24-hour SLA — the confirmed unlicensed-use claim that triggers a track unrelease in the monolith's music-rights-compliance promise. Themis itself is the upstream V1 adjudication service; this is the Saraswati-side contract that files into it and enforces its rulings, all V1-audited.

flowchart LR file["dispute filed<br/>(evidence captured pre-filing)"] --> decide{"Themis decision<br/>(final, ≥ filing)"} decide -->|credit-claimant| a1["rights-record + royalty-waterfall updated"] decide -->|pause-release| a2["catalog-license-paused"] decide -->|uphold-original-rights| a3["claim-denial-audited"] a1 --> enf["enforced ≤ 24 h, namespaced refs"] a2 --> enf a3 --> enf

Edge cases and failure modes#

  • A public-figure voice never builds. A probe ≥ 86% similar is a blocking issue, and buildSaraswatiVoiceSignature throws before any model artifact is produced; the GA signoff runs a 91.2% adversarial probe and asserts it blocks first.
  • Fan voices are not accepted at GA. Every GA consent dossier bakes in fanVoiceUploadsAccepted: false and contributionPolicy: 'consent-recorded-only'.
  • A genre persona can't drift at runtime. Any proposed cell change is blockedRuntimeRebinding and routed to editorial review — re-anchoring is a recorded operator action, not a runtime toggle.
  • A collaboration can't publish off-balance. Lineage credits or royalty shares that don't total exactly 10,000 bps, a missing persona route, or release before editorial approval each throw.
  • A remix mode is always visible, and a locked track is never purchasable. A catalog entry with a hidden mode fails publish; a none entry resolves purchase-blocked.
  • Rights enforcement is bounded and provable. Evidence must predate filing, a decision can't predate filing, enforcement can't predate the decision or exceed 24 hours, and each action carries a correctly-namespaced Aje/catalog reference.
  • The fan-economy money rails are elsewhere. Tickets, tips, club passes, signed editions, and the free tier are the Rust commerce service and the Aje substrate, not this library — reading @oshun/tenant-saraswati-stage expecting a checkout engine will mislead.

Where this connects#

  • Saraswati personas, discography & performance — the persona dossiers, the discography release flow, and the concert pipeline the voices and genres on this page belong to.
  • Commerce, rights & takedown — the ticket / tip / subscription primitives, the signed-edition drops, and the takedown cascade that the Themis rulings and remix rights feed into.
  • ../architecture/commerce-and-royalties.md — the architecture-side treatment of the Rust lilith-commerce-service, the royalty waterfall encoded at generation, the 10% signed-edition secondary royalty, and settlement through the shared @oshun/payments-bridge and libs/aje/* rails.
  • ../architecture/saraswati-stage-pipeline.md — the engine-agnostic generation gate chain, the persona policy lock, and the C2PA provenance that stamp a track before it ever reaches the fan economy.
  • The feature hub: ../V3_features.md.