SIGNAL

1What Signal Is

Signal is a launchpad where anyone can publish a small, running sound-generation process by writing the rule, launching it with its own token in a single transaction, and letting the pool that people trade and farm pay for it to keep composing. The project has two halves that depend on each other. On the composition side, a specification defines the state and step function of whatever is generating sound, a provenance document separates what was actually sourced from a published technique from what the creator simply decided, listenability bounds are declared and checked before anything launches, and checkpoints let anyone replay the execution later and challenge it if the recorded state does not match. On the funding side, the token itself, its trading pool, farming positions taken against that pool, and a runtime escrow together form a loop in which swaps produce both LP fees for liquidity providers and the escrow share that actually pays for each tick of computation.

In practice, launching a frequency follows a fixed sequence. A creator writes a small generative process; a coupled-oscillator drone field, a granular synthesis cloud, a physical-modeling resonator network, or one of the other classes described in Section 3 ; and gives a concrete account of how it executes and what it is expected to sound like. They then complete a provenance document covering what the frequency is not, every dataset or sample source it draws on along with its origin and license, a real citation, and an explicit line between sourced material and their own engineering decisions, and they declare listenability bounds covering scale, root, tempo range, maximum simultaneous voices, and envelope ranges. All of this is submitted as a single transaction that deploys the token with a fixed supply, records the provenance, listenability, and sample-clearance hashes on-chain, creates the trading pool, and locks the liquidity; if any step in that sequence reverts, the entire launch reverts with it. From there, trading fees are split by the locker into a majority share that funds a runtime escrow, a bounded share paid to the creator, and a fixed share paid to the protocol, and as long as that escrow holds a balance the frequency keeps composing and its page shows its current state. When the escrow runs dry, the frequency pauses visibly and says so rather than quietly going silent.

Because there is no single runtime architecture behind every frequency, a creator has to say plainly what kind of process theirs actually is. It might be a client-rendered browser process, an on-chain state machine advanced by public calls, or an off-chain worker posting checkpoints, and whichever it is, the description has to name what advances a step in terms a reader can actually check. A phrase like "an AI composes it" fails validation in the launch flow for the same reason "an AI runs it" fails on comparable launchpads: it names no S, no f, and no τ, so there is nothing in it a third party could verify.

The token contract itself has no mint function, so the supply entered at launch is the entire supply that will ever exist, and because there is no minting path there is nothing resembling a team unlock schedule that would need to be disclosed later. Underneath all of the presentation, Signal really only enforces three things, and everything else on the site exists to explain or display them. Liquidity cannot be pulled, because the locker contract exposes no withdraw path to anyone at all. Provenance cannot be skipped, because the launch form simply will not submit without it. And listenability bounds cannot be skipped either: a launch with no declared scale, envelope range, or voice cap does not pass validation, full stop.

2The Frequency Specification

A Signal frequency is a bounded dynamical system whose state and execution can be inspected and replayed by a third party.

Definition
Freq = ⟨ S, f, σ, τ, L ⟩

S is the state space, the complete set of values that may exist at one tick; f is the step function, the complete rule that maps the current state and seed to the next state; σ is the launch seed, the fixed input that makes any seeded choices replayable; τ is the tick trigger, the observable event that authorises and advances one step; and L is the listenability bounds; scale or mode, root note or root progression, tempo range, maximum simultaneous voices, and attack and release envelope ranges. L is the one part of this tuple with no analogue in a generic dynamical-system specification, and it exists for a fairly practical reason: sound is far less forgiving of surprising output than a visual pattern is. An unpleasant visual pattern can still be interesting to look at, but an unpleasant sound is simply unpleasant to hear, so a frequency cannot launch without L specified any more than it can launch without a provenance document.

State space S

S must be finite and serialisable, and a checkpoint has to contain enough information to reconstruct one complete state without relying on any hidden memory. A coupled-oscillator drone field, for instance, stores 64 float64 phase values, or 512 bytes. A granular synthesis field keeps 64 grain slots, each with four float32 parameters covering position, pitch, duration, and age, for exactly 1 KiB. A physical-modeling resonator network tracks 12 coupled resonators, each with two float64 values for displacement and velocity, or 192 bytes. A cellular-automaton composition can run on a 64-by-64 binary lattice, or 512 bytes, and a stochastic process needs little more than its PRNG state, 32 bytes, plus a rolling window of the last 64 sampled values.

Step function f

Given a state and a seed, f has to be pure and deterministic: the same inputs must always produce the same next state, with no undeclared clock, network response, or local randomness sneaking in. Floating-point reproducibility in particular requires the creator to state the arithmetic they are using; float32, float64, fixed-point, or integer; along with the summation order and the platform, whenever any of those could affect the result. Integer or fixed-point models are preferred wherever possible, since they replay bit-exactly across machines in a way floating-point rarely does.

Seed σ

σ is recorded on-chain at launch, and for a seeded-stochastic frequency the runtime description has to name the actual pseudorandom number generator in use, such as xoshiro256** or PCG32, and define exactly how its state advances from one tick to the next.

Tick trigger τ

A tick trigger is accepted if it is observable by a third party; an operator-only timer or a private event stream does not qualify. The accepted forms are:

• · a new block being observed,
• · an explicit public call,
• · a wall-clock interval anchored to a block hash, or
• · user input logged as an event.

State versus render

It is worth being precise here, because the distinction matters later: f operates only on S and never touches raw audio. What a listener actually hears is a deterministic render of s_t, produced through a separately specified and versioned synthesis step, ideally a pinned WASM audio engine, for the same reason a step function's build is pinned whenever floating point is unavoidable. That rendering stage is a view of state rather than the authority itself, in much the same way a canvas is a view of state on a comparable visual launchpad, and this is exactly what keeps the checkpoint chain in Section 13 small, discrete, and bisectable, even though what it ultimately produces on the other end is continuous audio.

Checkpoint hash
H_t = SHA-256(serialise(s_t))

The launch specification declares a minimum checkpoint cadence and states where each checkpoint hash will be published. A runtime is free to publish more often than that, but it cannot silently fall below the declared cadence, and if a checkpoint's hash does not match what replay produces, that mismatch means the recorded execution has been publicly falsified. Nothing about the frequency itself gets removed or hidden when that happens; the launch, the specification, and the mismatch all remain fully inspectable.

None of this, on its own, guarantees a frequency is any good. A correct specification can just as easily describe an uninteresting or genuinely unpleasant frequency as an interesting one; it makes claims checkable, not true; and satisfying it does not automatically mean L has been honored either, since listenability bounds are checked at launch, but a creator choosing a boring scale within otherwise valid bounds is not a specification failure of any kind.

3Frequency Classes

A class describes the mechanics a specification must expose. It grants no musical meaning and no aesthetic validity on its own.

dθ_i/dt = ω_i + (K/N) Σ_j A_ij sin(θ_j − θ_i)

The order parameter r = |(1/N) Σ_j e^(iθ_j)| drives both the audible consonance of the field and the visual coherence of whatever accompanies it on screen. This general approach, building music out of specified materials and processes without pinning down their combination in advance, has real precedent in Eno's own account of generative systems (Eno 1996).

a_(t+1)(x) = R({ a_t(x + δ) : δ ∈ N })

Other classes are welcome as long as S, f, σ, τ, and L are all concrete and the provenance gate passes.

4Listenability Guarantees

These are enforced across the whole platform rather than left up to individual creators, because sound is much less forgiving of surprising output than a visual pattern tends to be. Every frequency's audio is quantized to a fixed scale before it ever reaches the listener, never left as raw frequency output, and every frequency shares a single slow-moving drone root or short chord progression, with individual voices pitched as consonant intervals above it. Attack and release envelopes have an enforced multi-second floor so nothing produces sharp transients, and the number of simultaneous voices is hard-capped. Timbres default to soft waveforms; sine, triangle, filtered saw; while raw square waves and unfiltered aliasing are excluded from the default synthesis engine altogether, and any parameter that drives a filter or an amplitude moves through smoothed interpolation rather than stepping abruptly. A single shared algorithmic reverb runs across all voices to hold the whole thing together.

A creator can still declare parameters outside these defaults if they want to, but doing so surfaces a visible, permanent tag reading [experimental; unquantized] rather than being blocked outright, and the default templates tied to each class in Section 3 already ship pre-configured with bounds that are known to work, so a creator can launch confidently without hand-tuning synthesis parameters themselves. None of this, though, proves a frequency is actually good. Satisfying L keeps a frequency out of the range that reliably reads as noise; it says nothing about whether the result is interesting, original, or well made.

5Why Provenance Is Required

Launching on Signal requires a structured provenance document, and it is not a disclaimer field tucked away somewhere; the launch transaction simply cannot be submitted until the document is complete. Good documentation answers one narrow question, whether a claim is specific enough for someone else to check, and it answers nothing at all about whether the money behind that claim stays where it was put. Signal treats those as two genuinely separate requirements, the same posture a comparable launchpad's own provenance mechanism takes.

The document itself has to cover several distinct things. It needs at least two specific statements, written by the creator, about what their frequency does not claim to be; not a licensed derivative of a named artist's style, not a human performance unless it is disclosed as one, not claiming any therapeutic or emotional effect beyond what is stated ; and generic disclaimers are rejected by the form outright. It also has to name every dataset or sample corpus in use, along with its origin, its license as the source states it, and a SHA-256 of any bundled file, and wherever a hash is given, it gets written on-chain at launch, so the file behind the claim cannot be quietly swapped out afterward. Where a grain source or training corpus includes copyrighted recordings, its license status has to be stated and the bundled file hashed on-chain as well, which is aimed squarely at a real and recurring problem in the existing generative-audio market: uncleared samples swapped in after release, something that becomes discoverable once the source is pinned at launch instead of merely asserted in prose.

Beyond sourcing, the document needs a real citation; a paper, DOI, book, or dataset repository reference for whatever underlying technique is in use, since vague prose about "published research" does not pass; and a structured table separating what actually comes from the cited technique or data from what the creator simply decided. This last part is the field that stops overstatement in practice: it is the difference between a sentence like "the coupling graph is from a published dataset; the phase-to-pitch mapping is a design choice, not a claim about the underlying system's audible properties" and one that quietly blurs the two together. Finally, the frequency's own code needs a stated license.

The finished document renders in full on the frequency's own page, never collapsed, hidden behind a link, or summarised down to nothing. It is linked from the token page too, and the one-line summary that appears on cards and in the explore list is pulled from it rather than from any separate marketing field, because a separate marketing field is exactly where overstatement tends to creep in.

It is worth being honest about what this requirement can and cannot actually do. Signal checks that a citation is well-formed and that a hash is a valid SHA-256; it cannot confirm that a paper actually says what a creator claims it says, that a hashed file truly contains the corpus it is labeled with, or that a license claim is accurate. What the requirement does is make claims specific, attributable, and fixed in place, so that public scrutiny has something concrete to check against. It is not verification.

6The Release Mechanism

Current U.S. Copyright Office guidance treats a work as ineligible for copyright protection if it has no meaningful human authorship, and prompts or parameter declarations alone do not establish that authorship (U.S. Copyright Office 2025). A frequency running continuously and unattended falls on the wrong side of that line simply by existing in that form.

A Release is how a human creator actually claims authorship over a specific piece of a running frequency: selecting a tick range, making editorial decisions such as trims, layering, sequencing, and mix or EQ choices, and then publishing that specific, fixed result under a name. This act of selection and arrangement is the kind of human creative contribution current guidance treats as independently protectable, even though the generative rule that produced the raw material underneath it is not.

Definition

R = ⟨ freq, [t_a, t_b], edits, att ⟩

Here, edits is an ordered, timestamped log of actions; trim, layer, automation, sequence, mix adjustment; recorded as they actually happen during editing rather than reconstructed after the fact:

H_R = SHA-256(serialise(edits))

and att is the creator's signature over a message that binds the source frequency, the tick range, and the edit-log hash together:

"Signal release
frequency: {freq}
ticks: {t_a}-{t_b}
edit_log: {H_R}"

Once a Release is published it becomes immutable, the same guarantee a provenance hash carries elsewhere in this document, which gives a creator a timestamped, tamper-evident authorship record rather than a story assembled after the fact; exactly the kind of documentation current guidance points to as strengthening a copyright claim.

It helps to keep two separate assets in mind here. The step function f is ordinary software and is copyrightable on its own terms regardless of whether any given audio output is, so a commercial structure can license access to run f and, separately, license specific curated Releases, rather than staking everything on the harder question of output-copyrightability. And whatever happens with that harder question, the sample-clearance hashing described in Section 5 already resolves the risk most licensees actually care about in practice, using something with unclear rights, entirely independently of it.

None of this should be overstated. A frequency's continuous, unattended output is not, on its own, eligible for copyright protection under current U.S. Copyright Office guidance. A creator's curated selection and arrangement of specific output into a named Release may be independently protectable, and Signal logs those edits specifically to support that claim, but this is not legal advice, and copyright status can vary by output and by jurisdiction.

7The Liquidity Lock

The factory deploys the token, creates the pool, deposits the initial liquidity, and calls lock() all within a single transaction. The locker's lock function accepts exactly one call per token, and only from the factory, so a launch that fails to lock reverts entirely rather than leaving any window in which a pool exists unlocked.

The more common pattern elsewhere is a timelock, where liquidity is locked until a given date and the creator can then take it back, but that is a delay rather than a guarantee. The locker described here implements no withdraw, unlock, release, emergency, migrate, or sweep function in any form, and because that code simply does not exist, no key, multisig, governance vote, or future decision could ever call it. The contract also has no owner and no admin role, and it is not deployed behind a proxy, so the bytecode at its address is final; there is no selfdestruct either.

Locking the position does not stop it from earning trading fees, and collectFees routes those fees to fixed destinations set back at deploy time: the runtime escrow, the creator's claim balance, and the protocol share described in Section 8. Collecting fees never touches the underlying principal, and none of those destinations can be edited once the frequency has launched.

It is worth being clear-eyed about how far this actually goes. A lock prevents exactly one specific failure, the creator removing the pool; it does nothing to stabilise the token's price, does not stop a holder from selling into your bid, does not guarantee the frequency is pleasant or even interesting, and does not prove the creator's sample sources are authentic. It also does not eliminate smart contract risk generally, since a bug in the locker or the token is still a bug regardless of how the liquidity underneath it is handled. Section 19 goes into that risk in more detail.

8Runtime Funding and Farming

The same swaps on a frequency's pool that produce LP fees also refill the escrow that pays for its generative execution. Trading produces fees, the locker splits them so that a runtime share enters escrow E, a bounded creator share becomes claimable, and a fixed protocol share is routed off separately, and escrow then pays a cost c for each tick as the frequency steps forward.

Runtime economics

ticks_remaining = floor(E / c)
runway          = ticks_remaining / r
dE/dt           = φ · fee_rate · V(t) − c · r
V*              = c · r / (φ · fee_rate)

The cost per tick, c, is declared at launch in units of the pool's quote asset per tick, and it has to be concrete and public so that anyone can calculate runway, reproduce deductions, and tell execution cost apart from whatever an operator might otherwise claim; c is fixed once the frequency has launched. The split itself sends the residual majority of trading fees to the runtime escrow, allows the creator a bounded share of up to 20 percent chosen at launch, and fixes the protocol's share at 10 percent.

Unlike a comparable model that has no curated-release mechanism, escrow here can also receive a second, independent kind of inflow: direct payments when a licensee unlocks a Release's stems, as described in Section 6, split 90 percent to the creator and 10 percent to the protocol, entirely separate from the trading-fee split above. This does not change equation 3; it is simply an additional deposit to E sitting outside the fee_rate · V(t) term, in the same category as a direct top-up.

Farming, in this context, means holders provide liquidity to a frequency's pool and receive the LP share of swap fees on their position through ordinary AMM mechanics. Deeper liquidity lowers slippage, which tends to raise trading volume V, which in turn raises dE/dt, but none of this amounts to a promised yield, a guarantee that V stays above V*, or any claim about where the token's price is headed.

Pause regime

dE/dt < 0   →   E reaches 0   →   status = paused

When escrow reaches zero, the trace simply freezes at s_t and H_t stays public. Once E climbs back above c, execution resumes from the last checkpoint rather than inventing whatever states were missed in between, and while direct top-ups to escrow are allowed from any address, nobody is ever obliged to provide one. No APR, APY, or projected yield is shown anywhere on this site, and none will be until a pool actually exists; any figure claiming to be one did not come from us.

9Verification and Replay

Replayability is what lets a third party actually test a runtime's published state without having to trust its operator. At launch, the following gets recorded on-chain:

• · the token address and its fixed supply,
• · σ and the hash of s₀,
• · the provenance document hash and each data or sample-file SHA-256,
• · the listenability bounds L, hashed,
• · the code repository URL and commit hash, and
• · c and the complete fee split.

Replaying a frequency then follows a fixed procedure: fetch s₀ and σ from the launch transaction and confirm that serialised s₀ matches its recorded hash; fetch f from the stated code repository at the recorded commit, including the pinned arithmetic and runtime dependencies; apply f from s₀ forward through the latest checkpoint t using the recorded trigger events in order; and finally serialise the recomputed s_t, calculate SHA-256(s_t), and compare the result to the H_t recorded on-chain.

Public check
s_t = f^t(s_0, σ)
H_t = SHA-256(serialise(s_t))

recomputed H_t = recorded H_t    match
recomputed H_t ≠ recorded H_t    public falsification

When the hashes mismatch, the input state, commit, execution environment, recomputed state, and both hashes all get published together. The launch record itself is permanent, and a falsification is handled as something public rather than as a takedown. Signal can check that citations are well-formed, that SHA-256 values are valid, and that a specification is complete, but it cannot establish that a paper really says what its creator claims, that a file is the corpus it is labelled as, or that a frequency is pleasant or interesting to listen to. The posture here matches the provenance document exactly: make every claim specific and durable enough that someone else could actually challenge it.

Reproducibility has a few real pitfalls worth naming. Floating-point addition is not associative, so SIMD reduction order, GPU versus CPU execution, and library-version drift can all produce different low-order bits even when a frequency otherwise looks equivalent, and audio introduces a further pitfall that visual systems do not have to deal with: sample-rate and audio-engine version drift can alter a render even when the underlying state chain has not moved at all, which is precisely why Section 2 separates state from render and pins the rendering step on its own. Integer or fixed-point stepping is preferred wherever bit-exact replay of state matters, and when floating point genuinely cannot be avoided, a pinned WASM build should be used with its arithmetic, ordering, compiler, and library versions all published alongside it.

10Determinism, Serialisation, and the Hash Chain

A checkpoint hash is only useful if two honest parties serialise the same state down to the same bytes, so the specification has to declare serialise(s) exactly: field order, field widths, endianness, and the encoding of every value in S. Floating-point values cannot appear in serialised state unless the arithmetic behind them is fully declared, and integer or fixed-point representations, Q32.32 in particular, are preferred wherever possible because they replay bit-exactly on any machine.

Randomness here is treated as state rather than as some hidden input sitting outside the system. A seeded-stochastic frequency names its PRNG, whether that is xoshiro256**, PCG32, or another published generator, seeds it from σ, and includes the generator's own state inside S, so that a replayer who already has s_t automatically has the generator's state too. Rather than hashing each tick independently, checkpoints form a chain instead:

H_0 = SHA-256(σ || serialise(s_0))
H_t = SHA-256(H_(t−1) || serialise(s_t) || τ_t)

where τ_t is the encoded trigger event that authorised tick t. Because each H_t commits to every prior state and every prior trigger, a replayer who reproduces a single H_t has actually verified the entire execution up to that point, not just one frame of it. WebAssembly specifies IEEE-754 semantics without fast-math or fused-multiply-add contraction, which is why a pinned .wasm binary, identified by its SHA-256 in the launch record, is the preferred form for f whenever floating point cannot be avoided; the reference build is what replayers actually run against, while the audio render described in Section 2 remains a downstream view of its output rather than the authority itself.

A checkpoint is not treated as permanent the instant it is posted, since a chain reorg could still invalidate it. It becomes final once N blocks have passed since it was posted, with N declared at launch alongside c, c_k, and h, defaulting to 20 blocks. A reorg deeper than N is a failure of the underlying chain, not of Signal's own mechanism, and sits outside what any of the guarantees in this document can address.

11Tick Authorisation and Keepers

A tick is meant to be an observable event rather than an operator's private decision, so the trigger τ is realised on-chain as a call:

tick(frequencyId, H_t)

which anyone may submit once the trigger condition holds, for example block.number ≥ lastTickBlock + delta; whoever submits it becomes the keeper for that tick. The escrow pays c to the runtime account and a separate keeper fee c_k to whoever called it. Like c, the keeper fee c_k is declared at launch in units of the pool's quote asset per tick and is fixed thereafter, so a prospective keeper can calculate their own return before ever submitting a tick, rather than discovering it after the fact. Because keepers need no special permission, anyone holding the reference build can keep a frequency running, and get paid for doing so, even if its original creator has stopped touching it.

Per-tick entropy for a seeded-stochastic frequency is derived from the chain itself rather than from the operator:

ε_t = keccak256( σ || blockhash(b_t) )

with b_t the block in which the tick was triggered. Because a blockhash is only available for the most recent 256 blocks, a frequency that goes unticked past that window simply records a gap rather than inventing the entropy it missed. This produces two genuinely distinct idle states, which a frequency's page names explicitly: a stalled frequency has a funded escrow but no keeper has submitted a tick, while a paused frequency has an escrow below the actual tick cost. Only the second one is a funding failure.

12Escrow Accounting

In discrete form, with F_n the fees collected at step n and φ the runtime share:

E_(n+1) = E_n + φ · F_n − (c + c_k) · 1[tick_n]
runway  = floor( E / (c + c_k) )   ticks

Release-licensing payments, described in Sections 6 and 8, are additional deposits to E_n sitting outside F_n; they change the inputs to this recurrence without changing its form. Swap fees themselves accrue on both the frequency-token side and the quote-asset side of the pool, but the runtime share is only ever taken from the quote side, while frequency-token fees go to the creator and protocol shares instead, which means the escrow never sells the frequency's own token into its own pool and funding the frequency creates no sell pressure on it whatsoever.

Pausing the instant E dips below c + c_k and resuming the moment it crosses back over would cause the frequency to flap on every small swap, so instead a frequency pauses when E < c + c_k and resumes only once E ≥ h · (c + c_k), where h is declared at launch with a default of 24. A resume therefore always implies at least h ticks of funded runway. Direct top-ups to escrow are accepted from any address, but they are never repaid and confer nothing in return.

13Challenge Protocol

Checkpoints are posted optimistically: the runtime submits H_t and it is presumed correct until proven otherwise. Anyone who replays a frequency and arrives at a different H'_t can open a formal challenge by posting a bond.

The dispute is resolved through bisection. The two parties hold an agreed checkpoint H_a, initially H_0, and a disputed checkpoint H_b, and at each round both commit to a hash at the midpoint tick m; if they agree on it, a becomes m, and if not, b becomes m. After log₂(b − a) rounds of this, the two parties agree on H_(k−1) and disagree only on H_k, at which point the dispute has narrowed to exactly one tick.

At that point both parties publish serialise(s_(k−1)), which must hash into the already-agreed H_(k−1) or that party is slashed immediately, along with their own serialise(s_k). Anyone holding the reference build can then recompute the single step f(s_(k−1), σ, τ_k) directly. Where f is small enough to run on-chain within a gas bound declared at launch, the contract simply adjudicates the result itself; where it is not, resolution becomes social instead, and the launch page permanently shows the disputed tick, both candidate states, and both hashes, tagging the frequency:

[FALSIFIED at tick k; challenge open]

Nothing gets deleted when this happens, and the frequency is free to keep running with the tag attached permanently. It is worth separating this from a different kind of dispute entirely: bisection resolves disagreements about the state chain itself, whether f(s_(k−1), σ) genuinely produces s_k, but it does not resolve a dispute over whether a published audio render faithfully reflects s_t. That second question is really a claim about the pinned synthesis engine described in Sections 2 and 10, and it gets adjudicated by comparing a render directly against the pinned reference build's output rather than through bisection at all, since conflating the two would make ordinary rendering-engine version drift look indistinguishable from an actually falsified checkpoint, which it is not.

A falsification bounty, funded from the protocol share, goes to whichever challenger first has their challenge resolve against the runtime, though a challenger's own bond is forfeited if their proposed s_k fails to hash to their own claim.

14Observables

What actually appears on a frequency's page is a derived quantity rather than the raw state itself:

o_t = g(s_t)

where g is published right alongside f, so observables are always recomputable by anyone who has s_t and are never simply taken on trust from the operator. Each class has its own canonical set:

These observables are the same vocabulary the underlying technique's own literature uses to report behaviour, and displaying them, alongside the oscilloscope or waveform trace described in Section 3, rather than leaving a listener with audio alone, is what actually lets someone compare a frequency to the technique it cites.

15Composition

A frequency can declare an input port that reads another frequency's observable directly:

s_A(t+1) = f_A( s_A(t), σ_A, o_B(t') )

where o_B(t') is B's observable at B's most recent checkpoint at or before A's own tick. Dependencies form a directed graph, and cycles are permitted within it, because every port only ever reads a previous checkpoint rather than the current step, a Jacobi-style update. Two coupled-oscillator drone fields coupled through each other's order parameter is the simplest possible example of this.

The consequences are worth stating plainly: replaying A requires B's checkpoint history too, so a composed frequency is only ever as verifiable as its least verifiable input. If B pauses, o_B simply freezes and A continues operating on stale input, and A's own page states this explicitly. A cannot fund B under any circumstance, since their escrows remain fully independent of each other.

16Threat Model

17Protocol Invariants

These are the properties every conforming deployment has to satisfy, and each one is checkable simply by reading contract code or public records.

These are the properties the token, factory, locker, and escrow contracts, along with the Release mechanism, must satisfy. They are stated here precisely so that any deployment can be checked against them directly, by reading contract code or public records, rather than taken on trust.

18The $SIGNAL Token

$SIGNAL is the protocol token, and it launches on Pons v2, the dominant launchpad on Robinhood Chain. Its utility stays narrow: it does not extend into verification, replay, or provenance, all of which remain free and open regardless of who holds the token, the same posture a comparable launchpad takes with its own protocol token.

Supply is fixed at 1,000,000,000, with no mint function, matching Pons v2's own fixed-mint convention for every token launched through it, so that $SIGNAL fits the chain's existing norms instead of standing out as an inconsistency. Launching a frequency requires burning 50,000 $SIGNAL, 0.005 percent of total supply per launch, executed as an on-chain transfer to 0x000000000000000000000000000000000dEaD. A transfer to that address is irreversible and works regardless of the token contract's specific implementation, which is why it is the mechanism used here rather than a contract-specific burn(uint256) call. The figure itself is fixed in tokens rather than tied to market price, and it is revisited only under a published process, never quietly.

The two fee splits described earlier in this document apply here directly: trading fees on any frequency's own pool send the residual majority to runtime escrow, up to 20 percent to the creator, and 10 percent fixed to the protocol, as described in Section 8, while payments to unlock a Release's stems split 90 percent to the creator and 10 percent to the protocol, as described in Sections 6 and 8.

19Risk Disclosure[SUMMARY]

The factory, token, locker, and runtime escrow are all just code, and code has bugs. A flaw in any of them could cause a loss of funds, a stuck position, or a frequency that simply cannot be funded, and while audits and public review reduce that risk, they never remove it entirely; the same immutability that makes the lock trustworthy also means a discovered bug cannot be patched in place once it ships. Robinhood Chain itself is infrastructure Signal does not control, so reorgs, outages, or changes at the chain or explorer level all affect this application directly.

It is worth being precise about what the locked-liquidity guarantee can and cannot actually prove. It proves exactly one thing: the initial liquidity position cannot be removed by anyone, because the locker contract exposes no path to remove it. It cannot independently verify that a creator's claimed sample sources are authentic; Signal checks that a citation is well-formed and that a submitted hash is a valid SHA-256 pinned on-chain, but it does not read the paper or listen to the sample itself, and it cannot confirm that a hashed file is really the corpus it claims to be. A lock says nothing at all about price either: holders can sell, volume can fall to zero, and a token with permanently locked liquidity can still drift down to near-zero regardless.

Frequencies are funded by trading fees and, where applicable, Release-licensing payments, and when both of those slow down, the escrow simply empties. This is the normal, expected end state for most frequencies rather than some kind of anomaly, and when it happens the frequency pauses, its page says so, its status changes, and the trace freezes at the last recorded state without anything being deleted; the provenance document stays public throughout. A frequency itself is only ever a small computational model of sound generation, and even a well-sourced one is still a simplification, which is exactly why the sourced-versus-designed section of each provenance document exists, so a reader can see how large that simplification actually is. A creator can also simply be wrong, or dishonest, in that document, so unchecked claims should be treated as unchecked.

On the copyright side, current U.S. Copyright Office guidance treats human authorship as a requirement for protection, evaluated case by case (U.S. Copyright Office 2025). The Release mechanism described in Section 6 supports a genuine authorship claim through documented human selection and arrangement, but it does not guarantee that any specific Release will actually be found copyrightable, and copyright status can vary by output and by jurisdiction; none of this is legal advice.

This document and its contracts are provided as-is, without warranty of any kind, express or implied, including merchantability and fitness for a particular purpose, and nothing here constitutes financial, investment, legal, or tax advice, or an offer or solicitation to buy or sell any asset. Frequencies launched on Signal are created by third parties, and Signal does not endorse, vet, or take responsibility for any frequency, its creator, or its claims. Anyone putting money into a launched token should assume total loss is genuinely possible: that amount can go to zero and stay there, including for reasons no guarantee in this document addresses.

20Under Consideration[NOT BUILT]

The ideas below are proposals rather than shipped features, and none of them should be read as a commitment or a timeline.

One is a death record: when a frequency's escrow reaches zero, publishing a final checkpoint hash and a one-line permanent record covering tick count, seed, and last state, rather than leaving only an inline paused status behind. Another is a spec-first launch flow, embedding an interactive sandbox directly into the launch process so that tuning a frequency's parameters generates its ⟨S, f, σ, τ, L⟩ specification automatically instead of requiring a creator to type it out separately. A third is a cleared-corpus library: a launch template referencing a curated catalogue of pre-cleared sample corpora by ID, so that provenance and licensing for the granular synthesis class come directly from the catalogue entry itself and only density, pitch range, and seed remain the creator's choice.

A fourth idea is reference-build attestation, a launch option where f is submitted as a .wasm binary and the factory records its hash, so the site runs the attested binary itself rather than a JavaScript port, meaning what listeners actually hear is the replay authority rather than a reimplementation of it. The last, frequency-to-Release funding, asks whether a frequency's escrow might pay toward Release editing or hosting costs directly; it is not currently designed, because doing so would make escrow accounting depend on Release activity and would complicate invariant I7, so it is recorded here only as an open question.

21Notation

S, f, σ, τ, L; state space, step function, seed, tick trigger, listenability bounds
Freq - the frequency tuple, Freq = ⟨S, f, σ, τ, L⟩
s_t - state at tick t; s_t = f^t(s_0, σ)
H_t - chained checkpoint hash (§10)
o_t = g(s_t) - observable
R - a Release, R = ⟨freq, [t_a, t_b], edits, att⟩
H_R - edit-log hash of a Release
E - runtime escrow balance (quote asset)
c, c_k - cost per tick; keeper fee per tick
φ - runtime share of trading fees
V(t) - trading volume; V* = (c + c_k) · r / φ, breakeven
r - tick rate
h - resume hysteresis multiple (§12)
N - checkpoint finality depth, in blocks (§10)

22References

1. [1] Karplus, K., Strong, A. (1983). Digital synthesis of plucked-string and drum timbres. Computer Music Journal 7(2), 43-55. doi:10.2307/3680062
2. [2] Miranda, E. R. (1993). Cellular automata music: An interdisciplinary project. Interface 22(1), 3-21. doi:10.1080/09298219308570616
3. [3] Xenakis, I. (1971). Formalized Music: Thought and Mathematics in Composition. Bloomington: Indiana University Press. ISBN 978-0-253-32378-1
4. [4] Kuramoto, Y. (1975). Self-entrainment of a population of coupled non-linear oscillators. International Symposium on Mathematical Problems in Theoretical Physics. doi:10.1007/BFb0013365
5. [5] Strogatz, S. H. (2000). From Kuramoto to Crawford: exploring the onset of synchronization in populations of coupled oscillators. Physica D 143, 1-20. doi:10.1016/S0167-2789(00)00094-4
6. [6] Eno, B. (1996). Generative Music. Talk delivered at the Imagination Conference, San Francisco, June 8, 1996. In Motion Magazine. inmotionmagazine.com/eno1.html
7. [7] U.S. Copyright Office (2025). Copyright and Artificial Intelligence, Part 2: Copyrightability. January 29, 2025. copyright.gov/ai

Nothing in this document is financial advice. No figure describing live activity, holders, or funding for any frequency should be treated as current beyond the date this document was generated, and as of this writing none exists to describe. Verify all current state against the live site and the Robinhood Chain explorer when both exist.