Der Launch mit zwei Positionen
Seit der Änderung vom 2026-09-12 gibt es keine Bonding Curve mehr. Die gesamte Supply geht in
gesperrte Uniswap-v4-Liquidität, schon ab der Erstellungstransaktion selbst. Seit dem
2026-09-28 im Code: LiquidityLock.launchMarket erledigt all das innerhalb der
Erstellungstransaktion des Marktes, und die Tests fixieren den von der Lens ausgelesenen
Eröffnungspreis, 3.401.582.525 wei pro Token.
Warum die Kurve verschwand
Die alte Kurve war ein konstantes Produkt über virtuellen Reserven:
x = VIRTUAL_ETH + netReserve (3.75 ETH + was hereinkam)
y = TOKEN_RESERVE - tokensSold (1.1 B − was hinausging)
Genau das ist eine Position mit konzentrierter Liquidität: Die virtuellen Reserven von v3/v4 sind dieser Offset. Die Entsprechung ist keine Näherung, sondern dieselbe Gleichung, anders geschrieben.
Was ihre Abschaffung bringt: keine Migration — der riskanteste Moment des Protokolls —, keine Graduation-Gebühr, die abgeschöpft wird, ein Gebührenpfad statt zwei, und Märkte, die ab ihrem ersten Block von Aggregatoren geroutet werden können.
Die zwei Bänder
Tick 195000
Eröffnung"] -->|Band 1 · 700M Tokens · 7,535 ETH| B["FDV 34,091 ETH
Tick 171960
10x"] B -->|Band 2 · 300M Tokens · unbegrenzt| C["Tick −887220
Preisobergrenze"]
| Band 1 | Band 2 | |
|---|---|---|
| Tokens | 700.000.000 | 300.000.000 |
| Ticks | [171960, 195000] |
[−887220, 171960] |
| Tiefe | 7,535 ETH zum Durchqueren | 14,5 ETH bei 2× · 45,7 ETH bei 20× · 144,6 ETH bei 200× |
tickSpacing 60, und keine LP-Gebühr.
Das sind die Standardeinstellungen des Launchs. Seit dem 2026-10-05 bilden die Supply, die
Tokens in Band 1 (Band 2 erhält den Rest), der Launch-Tick, die unteren Ticks beider Bänder,
das Tick-Spacing und die LP-Gebühr eine einzige Einstellung des Owners von StockFun,
setLaunchConfig auf der Factory, die für die danach erstellten Märkte gilt. Sie lehnt eine
Form ab, die kein Pool aufnehmen könnte: ein leeres Band, Ticks, die kein Vielfaches des
Spacings sind oder in falscher Reihenfolge liegen, ein Tick-Spacing oder eine LP-Gebühr
außerhalb des zulässigen Bereichs, Bänder, deren Liquidität ein einzelner Tick nicht tragen
kann. Jeder Pool behält die Form, die LP-Gebühr und das Tick-Spacing, mit denen er erstellt
wurde: Der Lock hält seine Ticks fest, und die Lens gibt die LP-Gebühr und das Tick-Spacing
jedes Marktes an.
Der heikle Teil: der Eröffnungspreis
Beide Positionen halten beim Launch nur Tokens. Das erlaubt dem Protokoll, kein ETH vorzuschießen: Jedes ETH, das der Pool jemals halten wird, kommt von Käufern.
Damit eine Position nur Tokens enthält, muss der aktuelle Preis am oder über dem oberen Ende ihres Bereichs liegen. Daher:
sqrtStartX96 = TickMath.getSqrtPriceAtTick(BAND1_UPPER); // not sqrt(raw FDV)
Der exakte Tick der Launch-FDV ist 194.977,95, und der nächste nutzbare Tick darüber ist
195.000. sqrtStart aus der rohen FDV abzuleiten, würde den Preis innerhalb von Band 1
platzieren, und die Prüfung NotSingleSided des LiquidityLock würde die Einzahlung
ablehnen.
Die Quantisierung ergibt eine effektive FDV von 3,4016 ETH statt 3,409, eine Abweichung von −0,22 %.
Wie das in der Praxis aussieht
Aufeinanderfolgende Käufe über je 2 ETH ab dem Launch, mit den Standardeinstellungen:
| Ausgegeben | FDV | Gehaltene Supply |
|---|---|---|
| 2 ETH | ~27.600 $ | 36,1 % |
| 4 ETH | ~50.400 $ | 53,3 % |
| 10 ETH | ~164.000 $ | 74,8 % |
| 50 ETH | ~2,78 Mio. $ | 93,9 % |
Das erste Ticket nimmt 36,1 % der Supply — gegenüber 36,99 % auf der alten Kurve. Der Launch verhält sich wie zuvor, bis auf einen Punkt genau, und das war das Kriterium, nach dem die Parameter gewählt wurden.
Die strukturelle Obergrenze eines Bandes
Das ETH, das ein Band aufnehmen kann, wenn 100 % der Supply darin lägen, ist genau das geometrische Mittel seiner beiden FDVs:
$$ E{\max} = \sqrt{\text{FDV}{\text{Start}} \times \text{FDV}_{\text{Ende}}}
$$
Das ist es, was die Parameter einschränkt: Man kann den Launch-Preis, das obere Ende des Bandes und die Tiefe nicht frei wählen — die Anzahl der Tokens schließt das System.
Der Endmodus
Wie die Tokens ist der Lock nicht upgradebar: Sein Code ist das, was die Liquidität in den Pools hält. Seit dem 2026-10-02 hat er einen einzigen Ausgang, den Endmodus, für den Fall, dass das Projekt eingestellt wird.
- Die Ankündigung. Der Owner von StockFun ruft
end()auf, und der Lock hält öffentlich das Datum 30 Tage später fest. Ab dann kann kein neuer Markt mehr gelauncht und auch die$STOCKFUN-Position nicht mehr erstellt werden, sodass kein Markt weniger als die volle Vorankündigung erhält. Handel und Einsammeln der Gebühren gehen weiter - Die Vorankündigung. 30 Tage lang wird auf jedem Pool weiter gehandelt. Der Owner kann
jederzeit mit
cancelEnd()abbrechen, und die Launches werden fortgesetzt - Die Recovery. Sobald die 30 Tage abgelaufen sind, kann der Owner jede Position eines
Pools herausnehmen — beide Bänder eines Marktes, die einzelne
$STOCKFUN-Position — und sein ETH und seine Tokens, nicht eingesammelte Spenden eingeschlossen, an eine beliebige Adresse senden (recoverLiquidity). Ein Pool, dessen Liquidität zurückgeholt wurde, sammelt nichts mehr ein und gilt nicht mehr als gesperrt; ein späterer Abbruch lässt ihn leer
Die 30 Tage sind die Vorankündigung für die Holder. Sie sind eine Konstante des Locks,
END_DELAY, keine Einstellung: die einzige feste Wartefrist des Protokolls.
Außerhalb des Endmodus erreicht nichts die Positionen. Seit dem 2026-10-05 behält der Lock
den Anteil einer Gebühreneinsammlung, den sein Empfänger abgelehnt hat, für diesen Empfänger,
bis jemand ihn auszahlt (payOwed); und der Owner von StockFun kann herausholen, was
versehentlich an den Lock gesendet wurde (rescue, rescueClaims, rescueNft): jeden
Token, ETH über den Anteilen, die er behält, v4-Claims, ein NFT. Der Lock hat keinen
generischen Aufruf: Über den PoolManager könnte man die Recovery des Endmodus ohne ihre 30
Tage erreichen.