Skip to content
Curve Campaign

About the Curve Campaign Desk

This desk writes the sheet that sits in front of a curve campaign, one block per depth of curve. It does not rank tools, walk through product interfaces, advise on key handling, or take a position on whether a launch should exist.

Curve Campaign is a planning desk for tokens that live on a launchpad bonding curve. It covers one layer: the decisions between owning an execution tool and being able to say afterwards what a run actually did. The distinguishing idea is that those decisions have to be taken four times, because a curve token passes through four states that price a trade differently, and an answer that was correct in the first hour stops being correct once the reserve has multiplied.

What the desk does

Every note here answers a planning question at a stated depth. How large should a trade be against the reserve currently in front of it. How many fills does an allocation buy, and what cadence do they make. How much of the remaining curve capacity is the campaign willing to consume itself. What changes at the moment a pool replaces the curve, and which fields stop describing anything real.

The format is consistent because the method is. Every parameter is written as a trade-off with a named failure at the bottom of its range and a different named failure at the top, since no value is correct independently of the state it executes in. Every worked block is arithmetic chosen to show how a derivation chains together, labelled illustrative where it sits, and describing no real token, curve or pool.

Why the work is organised by phase

Because the mechanism moves. A bonding curve prices fills against a reserve that the campaign itself is changing, so a configuration ages while sitting still. An operator who notices a run producing less effect at hour nine than at hour two is usually not watching a tool degrade; they are watching a size band that was derived against a reserve four times smaller than the one in front of it now.

Splitting the campaign into four blocks makes that ageing explicit. Each block is derived against the depth it will actually execute in, each has a ring-fenced allocation and a written exit condition, and each of the three handovers names the fields that must change at the boundary. It also makes the campaign markable, because four short records against four short intentions can be compared, and one long record against one vague intention cannot.

What the desk leaves alone

  • Ranking tools or comparing vendors. That is a purchasing decision and it is answered elsewhere.
  • Interface walkthroughs. Which control does what is a property of a product, not of a campaign.
  • Key handling, funding routes and incident response. Serious subjects with their own literature.
  • Whether a particular launch or token deserves to exist. Not a question a parameter block answers.

The desk also publishes nothing aimed at concealment. The notes here are about designing a campaign whose record you can account for, and a plan whose value depends on nobody being able to read the record is not a plan this desk knows how to write.

The rules every page is written under

  • No promised outcomes. No page here says a configuration will produce a result.
  • No invented curve thresholds, completion percentages or reserve levels presented as rules.
  • No fabricated statistics, review counts, ratings, testimonials or case studies.
  • No named token, wallet or team used as an example of a real campaign.
  • No backdated publication dates.
  • Every parameter carries the failure it causes at both ends of its range.
  • Every figure inside a worked block is labelled illustrative where it appears.

How numbers are handled here

Three kinds of number appear on this site and nothing else does. Protocol facts, which are properties of Solana and of the programs involved and are linked to primary documentation rather than asserted from memory. Illustrative arithmetic, which exists to show how a calculation chains and is marked as illustrative every time. And values the reader supplies, in templates where the desk provides the structure and the operator provides the inputs.

Curve constants deserve a specific note. The parameters that shape a launchpad curve belong to the program implementing it, they differ between launchpads and between versions, and a number copied from an article and applied to a different program is worse than no number. Where a page needs one, it tells the reader to read it from the mechanism in front of them.

What never appears is a measured result presented as typical, a cost figure presented as a market rate, or a threshold presented as an industry standard. This desk has measured none of those things, and a number with no method behind it is a claim wearing a number's clothes.

Independence and affiliation

Curve Campaign is independent. It is not affiliated with, endorsed by, or operated by any launchpad, exchange or automated market maker discussed on this site, and it uses no third-party logos or branding. Where a page links to a commercial execution console, it does so because the paragraph is about something that console answers, and the link is plainly a link rather than an endorsement of a result.

Who writes this

Notes are published under The Curve Campaign Desk, which is the editorial identity of the site rather than a person. There are no invented author biographies here, no photographs and no credentials attached to anything. The reasoning on each page has to carry itself, and where a claim rests on something external the page links to a stable source so a reader can check it directly.

Corrections

If something here is wrong it gets corrected on the page rather than quietly removed, and the reasoning behind it gets revisited rather than patched. Errors in a phase note usually mean a trade-off was stated in only one direction, or that a number crept in without a derivation behind it, which are the two specific mistakes this format exists to prevent. Corrections and questions go through the contact page.