Pitchwhitepaper

Pitch 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 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 show it wrong if the recorded state does not match. On the funding side, the token, its pool and a runtime escrow form a loop in which swaps produce the fees that pay 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 in Section 3) and gives a concrete account of how it executes and what it is expected to sound like. They complete a provenance document covering what the frequency is not, every dataset or sample source it draws on with its origin and licence, 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 specification, provenance and listenability hashes on-chain, creates the pool against WETH, locks the whole supply in it and makes the creator's first buy; if any step reverts, the entire launch reverts with it. From there, trading fees are split by the launchpad into a share that funds a runtime escrow, a fixed share paid to the creator, a fixed share paid to the Pitch team and the platform's share. As long as the escrow holds a balance, the frequency keeps composing and its page shows its current state. When the escrow runs dry, the frequency stalls 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 is: a client-rendered browser process, an on-chain state machine advanced by public calls, or an off-chain worker posting checkpoints. Whichever it is, the description has to name what advances a step in terms a reader can check. A phrase like "an AI composes it" fails validation, because it names no S, no f and no τ, so there is nothing in it a third party could verify.

The token contract has no mint and no burn function, so the supply created at launch (1,000,000,000) is the entire supply that will ever exist, and there is no team unlock schedule to disclose. Underneath the presentation, Pitch enforces three things, and everything else on the site exists to explain or display them. Liquidity cannot be pulled, because the launchpad that owns the positions has no function to decrease them. Provenance cannot be skipped, because the launch 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.

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

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 has no analogue in a generic dynamical-system specification, and it exists for a 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 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. Floating-point reproducibility requires the creator to state the arithmetic in use (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 part of the specification whose hash is recorded on-chain at launch. For a seeded-stochastic frequency, the runtime description names the pseudorandom number generator in use, such as xoshiro256** or PCG32, and defines 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

f operates only on S and never touches raw audio. What a listener 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. The render is a view of state rather than the authority itself, and this is what keeps the checkpoint chain small, discrete and bisectable, even though what it ultimately produces is continuous audio.

H_t = SHA-256( serialise(s_t) )

Equation 2 is the simple form; the implemented form chains every checkpoint to the previous one (Section 10). The launch specification declares a checkpoint cadence, and each checkpoint hash is published on-chain by tick. If a checkpoint's hash does not match what replay produces, the recorded execution has been publicly falsified. Nothing about the frequency is removed or hidden when that happens: the launch, the specification and the mismatch all remain inspectable.

None of this guarantees a frequency is any good. A correct specification can just as easily describe an uninteresting or unpleasant frequency as an interesting one. It makes claims checkable, not true, and a creator choosing a boring scale within valid bounds is not a specification failure of any kind.

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

Coupled-oscillator drone field

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 [6].

Granular synthesis field

A cloud of grains sampled from a licensed or public-domain corpus, evolving under a stochastic field.

Physical-modeling resonator network

Waveguide synthesis driving a small network of coupled resonators, in the tradition established by Karplus and Strong [1].

Cellular-automaton composition

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

CA states mapped onto a pitch and rhythm lattice, following Miranda [2].

Stochastic and formalized process

Distributions in the tradition of formalized music [3] (Poisson processes, Markov chains, sieve theory) generating pitch and rhythm sequences.

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

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

A creator can still declare parameters outside these defaults, but doing so surfaces a visible, permanent [experimental, unquantized] tag rather than being blocked outright. The default templates for each class in Section 3 ship with bounds that are known to work, so a creator can launch without hand-tuning synthesis parameters. None of this proves a frequency is 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.

Launching on Pitch requires a structured provenance document, and it is not a disclaimer field tucked away somewhere: the launch 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 about whether the money behind that claim stays where it was put. Pitch treats those as two separate requirements.

The document has to cover several distinct things. It needs at least two specific statements, written by the creator, about what the frequency does not claim to be (not a licensed derivative of a named artist's style, not a human performance unless disclosed as one, not claiming any therapeutic or emotional effect beyond what is stated), and generic disclaimers are rejected by the form. It has to name every dataset or sample corpus in use, with its origin, its licence as the source states it, and a SHA-256 of any bundled file. The whole document is hashed and that hash is written on-chain at launch, so the file behind a claim cannot be quietly swapped out afterward. Where a grain source or corpus includes copyrighted recordings, its licence status has to be stated and the file's hash included, which targets a real and recurring problem in generative audio: uncleared samples swapped in after release.

Beyond sourcing, the document needs a real citation (a paper, DOI, book or dataset reference for the underlying technique; vague prose about "published research" does not pass) and a structured table separating what comes from the cited technique or data from what the creator decided. This last part is what stops overstatement in practice: it is the difference between "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 a sentence that quietly blurs the two. Finally, the frequency's own code needs a stated licence.

The finished document renders in full on the frequency's own page, never collapsed or summarised down to nothing, and the one-line summary shown on cards is pulled from it rather than from a separate marketing field, because a separate marketing field is exactly where overstatement creeps in.

Pitch checks that a citation is well formed and that a hash is a valid SHA-256. It cannot confirm that a paper says what a creator claims, that a hashed file contains the corpus it is labelled with, or that a licence claim is accurate. The requirement makes claims specific, attributable and fixed in place, so public scrutiny has something concrete to check against. It is not verification.

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 [7]. 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 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 publishing that fixed result under a name. This act of selection and arrangement is the kind of human contribution current guidance treats as independently protectable, even though the generative rule underneath it is not.

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 happen rather than reconstructed afterwards:

H_R = SHA-256( serialise(edits) )

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

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

Once published, a Release is immutable, 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 claim.

Two separate assets are worth keeping in mind. The step function f is ordinary software and copyrightable on its own terms regardless of whether any audio output is, so a commercial structure can license access to run f and, separately, license specific Releases, rather than staking everything on output copyrightability. And the sample-clearance hashing of Section 5 already addresses the risk most licensees care about in practice, using something with unclear rights.

None of this should be overstated. A frequency's continuous output is not, on its own, eligible for copyright protection under current guidance. A curated Release may be independently protectable, but this is not legal advice, and copyright status can vary by output and jurisdiction.

Launchpad.create deploys the token, registers the frequency in the escrow, initialises the Uniswap v4 pool against WETH, mints the whole supply into two positions the launchpad owns, and makes the creator's first buy, all in one transaction. There is no window in which a pool exists unlocked: a launch that fails at any step reverts entirely. The curve position holds 725,000,000 tokens from the opening tick to a cap 6.96× above it; the reserve holds the remaining 275,000,000 from the cap to the top of the usable range. There is no bonding-curve contract and no migration.

The common pattern elsewhere is a timelock: liquidity locked until a date, after which the creator takes it back. That is a delay, not a guarantee. The launchpad implements no function that decreases a position, in any form, and because that code does not exist, no key, multisig, vote or future decision can call it. The launchpad does have an owner, for platform operations only: pausing new launches, moving the opening price of future launches by at most 2× per step, and changing the treasury, team and runtime addresses behind a 48-hour public timelock. None of those reaches an existing position or a launched frequency's parameters.

Locking a position does not stop it earning fees, and collectFees routes those fees to fixed destinations: the runtime escrow, the creator, the team and the platform, as described in Section 8. Collecting never touches principal.

A lock prevents exactly one failure, the removal of the pool. It does nothing to stabilise the price, does not stop a holder from selling, does not guarantee the frequency is pleasant or interesting, and does not prove the creator's sample sources are authentic. It does not remove smart contract risk either: a bug in the launchpad or the token is still a bug. Section 18 goes into that risk.

The same swaps that produce a pool's fees also refill the escrow that pays for its generative execution. Trading produces fees, the launchpad splits them so that a runtime share enters escrow E, and the escrow pays a cost c, plus a keeper fee c_k, for each tick as the frequency steps forward.

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

The cost per tick c and the keeper fee c_k are declared at launch in WETH and fixed thereafter, so anyone can calculate runway and reproduce deductions. The split is fixed by the protocol for every frequency: of a 2% trading fee, 1% goes to the Pitch platform and 1% is the frequency's share, split 70% to the runtime escrow, 25% to the creator and 5% to the Pitch team. With fee_rate = 2% and φ = 35% of the fee, the escrow receives 0.70% of WETH-side volume.

Any address may also top up E directly, with ETH or WETH. Top-ups sit outside the fee_rate · V(t) term of equation 3; they are never refunded and confer nothing.

Holders may also provide their own liquidity to a frequency's pool and earn the LP share of swap fees on their position through ordinary v4 mechanics; the protocol's split applies only to the launchpad's locked positions. Deeper liquidity lowers slippage, which may raise volume V and therefore dE/dt, but none of this is a promised yield, a guarantee that V stays above V*, or a claim about price.

E < c + c_k   →   status = stalled
E ≥ h · (c + c_k)   →   status = running

When the escrow cannot pay one more tick, the trace freezes at s_t and H_t stays public. Execution resumes from the last checkpoint once E clears the resume threshold (Section 12), rather than inventing the states that were missed. No APR, APY or projected yield is shown anywhere on this site.

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

• the token address and its fixed supply,
• the pool and both locked positions,
• specHash, the keccak-256 of the full specification, which contains σ, S, f's commit and the render settings,
• provenanceHash, which covers each data or sample-file SHA-256,
• listenabilityHash, the hash of L, and
• c, c_k, h and the tick interval; the fee split is a protocol constant.

Replaying a frequency follows a fixed procedure: fetch the specification and confirm its hash matches specHash; fetch f at the recorded commit, with its pinned arithmetic and dependencies; apply f from s₀ forward through the latest checkpoint t using the recorded trigger events in order; then compute the chain head and compare it to the H_t recorded by the latest tick.

s_t = f^t(s_0, σ)
H_t = chain( s_0 … s_t, τ_1 … τ_t )      (eq. 6)

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 can all be published together. The launch record is permanent, and a falsification is handled in public rather than as a takedown. Pitch 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 says what its creator claims, that a file is the corpus it is labelled as, or that a frequency is pleasant to listen to.

Reproducibility has real pitfalls. Floating-point addition is not associative, so reduction order, GPU versus CPU execution and library drift can all change low-order bits. Audio adds a further one: sample-rate and audio-engine drift can alter a render even when the state chain has not moved, which is why Section 2 separates state from render. Integer or fixed-point stepping is preferred wherever bit-exact replay matters, and where floating point cannot be avoided, a pinned build should be used with its arithmetic, ordering, compiler and library versions published.

A checkpoint hash is only useful if two honest parties serialise the same state to the same bytes, so the specification declares serialise(s) exactly: field order, widths, endianness and encoding. The reference implementation writes a header (u8 format version, u8 class id, u8 variant, u32 tick), then each model's fields in a fixed order, with integers unsigned big-endian and floats as IEEE-754 float64 big-endian. Integer or fixed-point representations, Q32.32 in particular, are preferred wherever possible because they replay bit-exactly on any machine.

Randomness is treated as state rather than as a hidden input. A seeded-stochastic frequency names its PRNG, seeds it from σ, and includes the generator's state inside S, so a replayer who has s_t has the generator's state too. Checkpoints form a chain rather than hashing each tick independently:

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

where σ is encoded as a u64 big-endian and τ_t is the encoded trigger event that authorised tick t; for the fixed-clock trigger it is the tick index as a u64 big-endian, and an on-chain trigger may pass its own bytes (for example, block number and block hash). Because each H_t commits to every prior state and trigger, a replayer who reproduces one H_t has verified the entire execution up to that point. WebAssembly specifies IEEE-754 semantics without fast-math or fused-multiply-add contraction, which is why a pinned .wasm binary is the preferred form for f whenever floating point cannot be avoided.

A checkpoint is not final the instant it is posted, since a reorg could still remove it. Verifiers should treat it as final once N blocks have passed, N = 20 by convention. The contracts do not enforce N; it is a rule for whoever reads the record. A reorg deeper than N is a failure of the chain, not of this mechanism.

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 block.number ≥ lastTickBlock + tickInterval. On Robinhood Chain, an Arbitrum Orbit chain, block.number inside the EVM is the parent chain's block number (about 12 seconds), so the interval is counted in those blocks; the default is 5. Whoever submits the call is the keeper for that tick. The call first sweeps the pool's accrued fees into the escrow (a failed sweep never blocks a funded tick), then pays c to the runtime account and c_k to the keeper, and records H_t. Like c, the keeper fee c_k is declared at launch in WETH and fixed, so a keeper can calculate their return before submitting. Because keepers need no permission, anyone holding the reference build can keep a frequency running, and get paid for it, even if its creator has walked away.

Per-tick entropy may also be derived from the chain rather than the operator:

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

with b_t the block in which the tick was triggered. A blockhash is only available for the most recent 256 blocks, so a frequency unticked past that window records a gap rather than inventing the entropy it missed. The reference models shipped today draw entropy only from their σ-seeded generator.

Two idle states are distinct and named on a frequency's page. A frequency whose escrow is funded but which nobody has ticked is simply waiting for a keeper. A stalled frequency has an escrow below the cost of one tick. Only the second is a funding failure. A third state, paused, is the creator's deliberate halt.

In discrete form, with F_n the WETH-side fees collected at step n, φ the runtime share and T_n any top-up:

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

Swap fees accrue on both the token side and the WETH side of the pool, but the runtime share is only ever taken from the WETH side. Token-side fees go to the platform, creator and team in the proportions 50 : 12.5 : 2.5, so the escrow never holds or sells the frequency's own token and funding the frequency creates no sell pressure on it. A tick debits exactly c + c_k and only when E ≥ c + c_k, so E can never go negative.

Stalling the instant E dips below c + c_k and resuming the moment it crosses back would make the frequency flap on every small swap. Instead the stall is latched: a frequency that has ticked stalls when E < c + c_k and resumes only once E ≥ h · (c + c_k), where h is declared at launch (default 24, bounded 1 to 1,000). A resume therefore always carries at least h ticks of funded runway. A frequency that has never ticked does not stall; it waits for its first c + c_k. Direct top-ups are accepted from any address, never repaid, and confer nothing.

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

The dispute is resolved by bisection. The two parties hold an agreed checkpoint H_a, initially H_0, and a disputed checkpoint H_b. 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 the parties agree on H_(k−1) and disagree only on H_k, and the dispute has narrowed to one tick.

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

[FALSIFIED at tick k, challenge open]

Nothing is deleted, and the frequency may keep running with the tag attached. Bisection resolves disagreements about the state chain itself, whether f(s_(k−1), σ) produces s_k. It does not resolve whether a published audio render faithfully reflects s_t; that is a claim about the pinned synthesis engine, settled by comparing against the reference build, because conflating the two would make ordinary engine drift look like a falsified checkpoint.

A falsification bounty would go to the first challenger whose challenge resolves against the runtime; a challenger's bond is forfeited if their proposed s_k fails to hash to their own claim.

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

o_t = g(s_t)

where g is published alongside f, so observables are always recomputable by anyone who has s_t. Each class has its own canonical set:

These are the same vocabulary the underlying technique's literature uses to report behaviour, and displaying them alongside the waveform, rather than leaving a listener with audio alone, is what lets someone compare a frequency to the technique it cites.

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

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 tick. Dependencies form a directed graph, and cycles are permitted, because every port reads a previous checkpoint rather than the current step (a Jacobi-style update). Two drone fields coupled through each other's order parameter is the simplest example.

Replaying A then requires B's checkpoint history too, so a composed frequency is only as verifiable as its least verifiable input. If B stalls, o_B freezes and A continues on stale input, and A's page says so. A cannot fund B: their escrows are fully independent. Input ports are part of the design and are not yet offered at launch.

These are the properties every conforming deployment satisfies, each checkable by reading contract code or public records.

They are stated precisely so that any deployment can be checked against them directly rather than taken on trust.

The token, launchpad, hook and escrow are code, and code has bugs. A flaw in any of them could cause a loss of funds, a stuck position, or a frequency that cannot be funded. The contracts have not been audited beyond their own adversarial tests, and the immutability that makes the lock trustworthy also means a discovered bug cannot be patched in place. Robinhood Chain is infrastructure Pitch does not control, so reorgs, outages and changes at the chain or explorer level affect this application directly.

The locked-liquidity guarantee proves exactly one thing: the launchpad's positions cannot be decreased by anyone. It cannot verify that a creator's sample sources are authentic; Pitch checks that a citation is well formed and that a hash is valid, but it does not read the paper or listen to the sample. A lock says nothing about price either: holders can sell, volume can fall to zero, and a token with permanently locked liquidity can still drift to near zero.

Frequencies are funded by trading fees and voluntary top-ups, and when both slow down, the escrow empties. This is the normal, expected end state for most frequencies. When it happens the frequency stalls, its page says so, and the trace freezes at the last recorded state without anything being deleted. A frequency is a small computational model, and even a well-sourced one is a simplification, which is why the sourced-versus-designed table exists. A creator can be wrong or dishonest in that document, so unchecked claims should be treated as unchecked.

On copyright, current U.S. Copyright Office guidance treats human authorship as a requirement for protection, evaluated case by case [7]. The Release mechanism of Section 6 would support an authorship claim through documented selection and arrangement, but would not guarantee it; 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. Nothing here is financial, investment, legal or tax advice, or an offer or solicitation to buy or sell any asset. Frequencies are created by third parties, and Pitch 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 possible.

The ideas below are proposals rather than shipped features, and none of them is a commitment or a timeline.

One is a death record: when a frequency stalls for good, publishing a final checkpoint hash and a one-line permanent record of tick count, seed and last state. Another is a spec-first launch flow, where tuning a frequency in an interactive sandbox generates its ⟨S, f, σ, τ, L⟩ specification automatically. A third is a cleared-corpus library: a launch template referencing a curated catalogue of pre-cleared sample corpora by ID, so provenance and licensing for the granular class come from the catalogue and only density, pitch range and seed remain the creator's choice.

A fourth is reference-build attestation: f submitted as a .wasm binary whose hash the launchpad records, so the site runs the attested binary itself rather than a JavaScript port, and what listeners hear is the replay authority rather than a reimplementation. The last, frequency-to-Release funding, asks whether an escrow might pay toward Release editing or hosting; it is not designed, because it would make escrow accounting depend on Release activity and complicate invariant I7.

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, in WETH

c, c_k

cost per tick; keeper fee per tick

φ

runtime share of trading fees (35% of the fee)

V(t)

trading volume; V* = (c + c_k) · r / (φ · fee_rate), breakeven

r

tick rate

h

resume factor (§12)

N

checkpoint finality depth, in blocks (§10)

1. 1Karplus, K., Strong, A. (1983). Digital synthesis of plucked-string and drum timbres. Computer Music Journal 7(2), 43-55. doi:10.2307/3680062
2. 2Miranda, E. R. (1993). Cellular automata music: An interdisciplinary project. Interface 22(1), 3-21. doi:10.1080/09298219308570616
3. 3Xenakis, I. (1971). Formalized Music: Thought and Mathematics in Composition. Bloomington: Indiana University Press. ISBN 978-0-253-32378-1
4. 4Kuramoto, 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. 5Strogatz, 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-400094-4)
6. 6Eno, B. (1996). Generative Music. Talk delivered at the Imagination Conference, San Francisco, June 8, 1996. In Motion Magazine. inmotionmagazine.com/eno1.html
7. 7U.S. Copyright Office (2025). Copyright and Artificial Intelligence, Part 2: Copyrightability. January 29, 2025. copyright.gov/ai