Der Hook und Anti-Snipe

Ein Uniswap-v4-Hook ist ein Contract, den der PoolManager zu genau definierten Zeitpunkten eines Swaps aufruft. Die aktuelle Implementierung von StockFunHook nutzt sechs Berechtigungen: beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap und die zwei Delta-Berechtigungen, die es ihm erlauben, einen Anteil einzubehalten. Seit dem 2026-10-02 trägt seine Adresse alle 14 v4-Berechtigungen; die Callbacks, die er nicht nutzt, laufen wirkungslos durch.

Die Adresse codiert die Berechtigungen

v4 liest die niederwertigen Adressbits eines Hooks, um zu wissen, wann es ihn aufrufen muss. Die Adresse wird daher nicht gewählt: Sie wird per CREATE2 durch Mining ermittelt, bis ein Wert auftaucht, dessen Bits zu den deklarierten Berechtigungen passen.

Seit dem 2026-10-02 ist die durch Mining ermittelte Adresse die eines Proxys, mit allen 14 gesetzten Berechtigungsbits. Ein Upgrade ersetzt die Implementierung hinter dieser Adresse, ohne sie zu ändern, sodass nie ein neues Mining nötig ist, und eine spätere Implementierung kann jeden Callback nutzen. Die aktuelle lässt die Callbacks, die sie nicht nutzt, wirkungslos durchlaufen: Sie geben ihren Selektor zurück und, wo ein Delta erwartet wird, null. Die Initialisierung des Proxys prüft, dass seine Adresse jedes Bit trägt.

Praktische Konsequenz: Die durch Mining ermittelte Adresse hängt vom Bytecode des Proxys und von seinen Konstruktorargumenten ab, die die Adresse der Implementierung enthalten. Bei einem neuen Deployment muss das Mining wiederholt werden. Deshalb setzt foundry.toml auch bytecode_hash = "none" — ohne diese Einstellung passt die durch Mining ermittelte Adresse nicht mehr zum deployten Contract.

Die Berechtigung beforeAddLiquidity, am 2026-10-01 hinzugefügt, hat die Bits selbst verändert: Das Mining der Adresse wurde wiederholt, und jedes vor diesem Datum erfolgte Deployment ist veraltet. Der Proxy vom 2026-10-02 hat sie erneut verändert: Jedes vor diesem Datum erfolgte Deployment ist ebenfalls veraltet.

Die Erhebung der Gebühr

Bei einem Kauf wird die Gebühr in beforeSwap erhoben, aus dem eingehenden ETH, bevor der Swap stattfindet. Der Hook entnimmt seinen Anteil dem PoolManager und gibt ein Delta zurück, das ihn dem Käufer belastet. Der StockFun-Router und der Liquiditäts-Lock zahlen das ETH des Käufers vor dem Swap in den PoolManager ein, sodass ihre Käufe nie auf das ETH zurückgreifen, das der PoolManager bereits hält.

Jeder andere v4-Router zahlt denselben Tax-Satz. Bei einem Router aber, der das ETH des Käufers nach dem Swap begleicht, wie es der V4Router von v4-periphery mit seiner Standard-Codierung tut, wird die Tax aus dem ETH erhoben, das der PoolManager bereits hält, und sein Kauf schlägt fehl, wenn die Tax größer ist. Das kann bei einem PoolManager passieren, der wenig ETH hält, etwa dem eines Testnets. Ein Integrator sollte das ETH des Käufers vor dem Swap einzahlen, wie es der offizielle Router tut. Verkäufe sind nicht betroffen. Die Security-Pipeline vom 2026-10-01 hat diese Einschränkung dokumentiert. Die Tax stattdessen als PoolManager-Claims zu erheben, würde diese Einschränkung für jeden Router aufheben, würde aber die 2 % der Treasury von einer Zahlung während des Trades zu einer Gutschrift mit späterer Auszahlung verschieben: Am 2026-10-05 hat der Owner entschieden, die Tax so zu belassen, wie sie heute erhoben wird.

Bei einem Verkauf wird sie in afterSwap erhoben, aus dem ausgehenden ETH, sobald der Betrag bekannt ist.

In beiden Fällen teilt der Hook sofort auf: Treasury, Creator, Team, Buyback. Nur der Treasury-Posten fließt während des Trades ab, an den Vault des Marktes gesendet. Die drei anderen Posten werden auf dem Hook gutgeschrieben und außerhalb jedes Trades ausgezahlt.

Seit dem 2026-10-05 lässt ein Vault, der den Treasury-Posten ablehnt, den Trade nicht mehr fehlschlagen: Der Hook behält den Betrag als Schuld gegenüber diesem Vault (treasuryOwed, Event TreasuryOwed), und jeder Kauf und Verkauf läuft weiter. Jeder zahlt die Schuld mit payTreasury an diesen Vault aus; der Aufruf schlägt fehl und behält die Schuld, solange der Vault weiter ablehnt; der Keeper versucht es in jedem Zyklus. Der Anti-Snipe-Überschuss folgt derselben Regel. Bis dahin schlug die Übertragung laut fehl: Ein Vault, der nicht empfangen konnte, etwa nach einem fehlerhaften Upgrade, ließ jeden Trade seines Marktes fehlschlagen, Verkäufe eingeschlossen.

Der Creator-Anteil ist pull-basiert: Er sammelt sich auf dem Hook an, Markt für Markt, und der Creator claimt ihn, wann er will, eine Transaktion pro Markt (claimCreatorFees). Seit dem 2026-10-05 claimt ein Creator, der selbst kein ETH annehmen kann, etwa ein Contract ohne Möglichkeit, es zu empfangen, an eine andere Adresse (claimCreatorFeesTo); nur der Creator kann das.

Seit dem 2026-10-01 werden die Anteile von Team und Buyback auf dieselbe Weise gutgeschrieben, je ein Guthaben, und durch claimTeamFees() und claimBuybackFees() ausgezahlt. Jeder kann sie aufrufen; sie zahlen nur an die Team- und Buyback-Wallets, die die Factory zum Zeitpunkt des Claims nennt. Der BuybackBurner holt sein Guthaben zu Beginn jedes Burns selbst ab. Eine Wallet, die ETH verweigert, verzögert nur ihre eigene Auszahlung: Ihr Claim schlägt fehl, und das Guthaben bleibt auf dem Hook.

Bis dahin wurden diese beiden Anteile während des Trades gesendet, mit einem Escrow-Fallback, wenn die Übertragung fehlschlug. Das Security-Audit vom 2026-09-29 hat gezeigt, dass eine Wallet, die die Übertragung annahm und dann den PoolManager aufrief, den Handel auf jedem Pool anhalten konnte. Den Escrow gibt es nicht mehr.

Was der Hook zwischen den Trades hält, ist jemandem geschuldet: die Guthaben der Creator, die des Teams und des Buybacks und die Schulden gegenüber den Vaults. ETH, das ihm jemand anderes als der PoolManager sendet, wird gesondert gezählt, als verirrtes ETH (strayEth). Seit dem 2026-10-05 kann der Owner von StockFun verirrte Beträge herausholen (rescue): höchstens diesen ETH-Betrag, und jeden Token, da der Hook nie einen hält. Nichts, was der Hook schuldet, kann auf diesem Weg abfließen. Ohne Aufruf hineingezwungenes ETH wird nicht gezählt und wartet auf ein Upgrade.

Nur der Lock fügt Liquidität hinzu

Seit dem 2026-10-01 verweigert beforeAddLiquidity jedes Hinzufügen von Liquidität zu einem StockFun-Pool außer dem des Liquiditäts-Locks.

Eine Position, die direkt neben dem aktuellen Preis platziert ist, wirkt wie eine Limit-Order: Der Swap eines Traders durchläuft sie und wandelt sie um, und der Trader zahlt die Tax, während der Inhaber der Position sie hinzufügt und entfernt, ohne je die 5 % oder, in den ersten zehn Blöcken, die Anti-Snipe-Tax zu zahlen. Das Security-Audit vom 2026-09-29 hat das reproduziert. Die Pools erheben standardmäßig keine LP-Gebühr, daher braucht keine legitime Nutzung eine Position eines Dritten.

Das Einsammeln der eigenen Gebühren des Locks, mit einem Liquiditätsdelta von null, läuft über den Pfad zum Entfernen von Liquidität, den die aktuelle Implementierung durchlässt: Es ist nicht betroffen. Ebenso wenig die Recovery des Endmodus, die die Positionen über denselben Pfad herausnimmt: siehe Der Launch mit zwei Positionen.

Degressives Anti-Snipe

Ein v4-Pool ist live, sobald er initialisiert ist. Ohne Schutz würden die ersten Blöcke nach der Erstellung von Bots eingenommen. Seit dem 2026-09-28 zahlen diese Blöcke eine höhere Tax, die bei jedem Block sinkt, bei Käufen wie bei Verkäufen. Mit den Standardeinstellungen:

Ein Bot, der im Eröffnungsblock kauft, zahlt sofort 80 %: Sniping ist ein Verlustgeschäft.

Drei Dinge verdienen eine Erklärung.

Der Launch-Kauf des Creators braucht keine Identitätsprüfung. Der einzige Swap, den der LiquidityLock jemals ausführt, ist der optionale Kauf des Creators, innerhalb seines eigenen Erstellungs-Callbacks. Aus „der Aufrufer ist der Lock“ folgt daher „wir sind in der Erstellungstransaktion“, und dieser Kauf zahlt die normalen 5 %.

Der Überschuss hat sein eigenes Ziel. Die normalen 5 % behalten ihre übliche Aufteilung. Der Teil darüber geht an die Treasury des Marktes und damit beim nächsten Airdrop an die Holder. Auf dem $STOCKFUN-Markt geht er an das Guthaben des Teams auf dem Hook, ausgezahlt durch claimTeamFees().

Die Whitelist braucht Identität, und das ist der subtile Teil. Der Hook sieht den Router, nicht den Käufer. Der StockFun-Router trägt daher die Adresse seines Aufrufers in den Hook-Daten, und der Hook vertraut diesem Feld nur, wenn der Aufrufer der offizielle Router ist, also der in der Factory hinterlegte, den der Owner jederzeit ändern kann (akzeptiert am 2026-09-28). Nirgendwo in diesem Protokoll wird tx.origin verwendet.

Dokumentierte Einschränkung: Eine Adresse auf der Whitelist, die während der ersten zehn Blöcke über einen Aggregator eines Drittanbieters routet, ist nicht ausgenommen.

Die Whitelist

Vom Creator des Marktes festgelegt. Die Adressen darauf zahlen während der Anti-Snipe-Blöcke die normalen 5 %. Bis zum 2026-09-28 wurde die Liste vom Owner geführt und von allen Märkten geteilt, gerade damit sie nicht zu einem Insider-Vorteil werden konnte; ein Creator kann nun seine eigenen Wallets ausnehmen. Validiert am 2026-09-28: Die Liste wird in der Erstellungstransaktion festgelegt, ist öffentlich, unveränderlich und standardmäßig auf 20 Adressen begrenzt.

Der $STOCKFUN-Markt

Die degressive Tax gilt auch hier. $STOCKFUN hat keinen externen Creator: Sein Überschuss geht an die claimbaren Gebühren des Teams, und seine Whitelist wird beim Launch vom Owner festgelegt.

Die Einstellungen

Seit dem 2026-10-05 ist jede Zahl auf dieser Seite eine Einstellung des Owners von StockFun, geändert auf dem Hook mit setTaxSettings: die Tax, standardmäßig 5 %; ihre Posten, 2 / 2 / 0,5 auf einem gelaunchten Markt und 2 / 2,5 auf $STOCKFUN, wobei der Buyback den Rest erhält; die Tax des Anti-Snipe im Eröffnungsblock, 80 %; ihre Abnahme pro Block, 8 Prozentpunkte; die Anzahl der Blöcke, die es dauert, den Erstellungsblock eingeschlossen, 10; und die größte Whitelist, 20 Adressen.

Eine Änderung gilt ab dem nächsten Swap, auf jedem Pool, auch auf einem Pool, der sich noch in seinen Anti-Snipe-Blöcken befindet: Die Degression wird mit den geltenden Einstellungen berechnet, ab dem Launch-Block des Pools. Was auch immer die Einstellungen sind, das Anti-Snipe verlangt nie weniger als die Tax. Der Setter lehnt einen Satz über 100 % ab und ebenso ein Gebührenschema, dessen Posten die Tax übersteigen. Die Obergrenze der Whitelist wird geprüft, wenn ein Markt erstellt wird: Eine bereits festgelegte Liste bleibt, wie sie ist.

Upgrades

Seit dem 2026-10-02 kann der Owner von StockFun den Hook upgraden, mit sofortiger Wirkung. Die Tax, ihre Aufteilung, das Anti-Snipe und die Whitelists, die diese Seite beschreibt, sind die der aktuellen Implementierung. Ein Upgrade behält die Adresse des Hooks und muss denselben PoolManager behalten; die Factory, die der Hook liest und die entscheidet, wer ihn upgraden darf, ist in der Implementierung festgelegt.