Entscheidungsprotokoll

Das kanonische Register ist doc/DECISIONS.md. Diese Seite fasst die Wendepunkte zusammen.

2026-08-25 — Internes Security-Review

Ein Finding mit hohem Schweregrad: Teilausführungen ließen ETH und USDC in den Routern stranden, voll besteuert. Behoben, indem Teilausführungen abgelehnt werden, statt sie zu behandeln.

2026-08-27 — Die Gebühr steigt von 4 % auf 5 %

Creator-Anteil verdoppelt, von 1 % auf 2 %. Gebührenschema von $STOCKFUN von 2 / 1,5 / 0,5 auf 2 / 2,5 / 0,5. Der Treasury-Anteil bleibt bei 2 %, und das ist die Zahl, die sich nie bewegt.

Akzeptierte Konsequenz: Der Roundtrip steigt von 7,84 % auf 9,75 %. Seit dem 2026-10-05 sind der Satz und seine Aufteilung Einstellungen des Owners, mit diesen Werten als Standardwerten.

2026-08-27 — Der Creator-Buyback

Hebt den Ausschluss „kein Ausstieg“ für einen einzigen Pfad auf, der immer im Burn endet. Die Treasury Ratio kann nun nach Ermessen eines Creators sinken. Am 2026-09-27 abgeschafft, ersetzt durch den Airdrop.

2026-08-29 — Notfallmodus

Der Owner kann die Assets einer Treasury nach 48 öffentlichen Stunden bewegen. Ersetzt das Versprechen „niemand kann die Treasury anfassen“. Das Protokoll wird nicht mehr als trustless beschrieben. Seit dem 2026-10-05 sofort wirksam: Die Wartefrist ist entfallen.

2026-09-11 — Die Rail wechselt zu Robinhood Chain

Der Blocker war die Berechtigung eines Vault-Contracts bei einem Emittenten mit Primary Mint, nie öffentlich dokumentiert. Die Sekundär-Pools von Robinhood Chain verlangen sie nicht. Gezahlter Preis: eine akzeptierte Cross-Chain-Abhängigkeit.

2026-09-12 — Die Bonding Curve verschwindet

Ersetzt durch zwei einseitige Uniswap-v4-Positionen, gesperrt ab der Erstellung. Keine Graduation, keine Migration, keine Graduation-Gebühr.

Die Launch-FDV ändert sich nicht: Sie bleibt die, bei der die Kurve eröffnete, 3,409 ETH. Ein erstes Ticket über 2 ETH nimmt 36,06 % der Supply, gegenüber 36,99 % vorher — der Launch verhält sich wie zuvor, bis auf einen Punkt genau.

Unterwegs verworfen: ein Launch bei 5.000 $ mit einer Obergrenze von 50.000 $, der nur 3,25 ETH Tiefe bot und den ersten Käufer mit 2 ETH 57 % der Supply nehmen ließ. Und die Idee, dass eine niedrigere Obergrenze den Markt beruhigen würde — sie übergibt früher an das unbegrenzte Band, das dünn ist, und verdoppelt die FDV, die nach 50 ETH Ausgaben erreicht wird.

2026-09-12 — Anti-Snipe in drei Blöcken

Nur der Creator in Block 1, 99 % an den Buyback in Block 2 außer für den Creator und die Owner-Whitelist, danach normal. Am 2026-09-28 ersetzt durch das degressive Anti-Snipe.

Getroffen in voller Kenntnis des Einwands: Eine Tax von 99 % bringt nur dann etwas ein, wenn jemand sein Geld verliert, und das Schließen von Block 2 hätte dieselbe abschreckende Wirkung ohne Opfer gehabt. Die Whitelist liegt auf Protokollebene statt auf Creator-Ebene, gerade damit sie nicht Markt für Markt zu einem Insider-Vorteil werden kann.

2026-09-12 — Kein Burn bei Verkäufen

Die Idee, bei jedem Verkauf 10 % der eingehenden Tokens in den Burn zu schicken, wurde fallen gelassen. Vom Verkäufer bezahlt, trieb sie den Roundtrip auf 18,78 %. Vom LP bezahlt, machte sie „Liquidität für immer gesperrt“ falsch und gab jedem einen Hebel von etwa 1:1, um den Float zu verbrennen und den eigenen Bag zu pumpen.

2026-09-27 — Der Airdrop ersetzt den Creator-Buyback

Die Treasury eines Marktes hat nun einen einzigen Zweck: 100 % der Aktien, die sie kauft, werden per Airdrop an die Holder ihres Tokens verteilt, pro rata, in natura, auf Robinhood Chain. Der Creator-Buyback ist abgeschafft, und mit ihm der Rückweg der Bridge. Der Buyback-and-Burn von $STOCKFUN bleibt.

Unterwegs verworfen: den Creator-Buyback beizubehalten, und eine Aufteilung, die 60 % in der Treasury behält und 40 % verteilt, der frühere V2-Plan. Akzeptierte Konsequenzen: Keine Treasury akkumuliert mehr, die Treasury Ratio verliert ihre Bedeutung, und Slogan und Tagline sind zu überarbeiten. Der Mechanismus wurde am 2026-10-04 programmiert: siehe Der Airdrop.

2026-09-27 — Ein Zyklus alle 24 Stunden

Die Kadenz des Airdrops wird am selben Tag festgelegt. Einmal alle 24 Stunden konvertiert der Keeper für jeden Markt, dessen Treasury mindestens 0,1 ETH angesammelt hat, das ETH, schickt es über die Bridge, kauft die Aktien und verteilt sie dann per Airdrop. Unterhalb der Schwelle passiert an diesem Tag nichts; das ETH wartet.

Aktien können nur gekauft werden, solange die US-Börse geöffnet ist, daher gibt es keinen Zyklus am Wochenende oder an NYSE-Feiertagen. Im Code des Keepers lief die Konvertierung bis zum 2026-10-06 während der Handelszeit, beim ersten Durchlauf, bei dem der Vault die Schwelle hielt; seitdem folgt sie dieser Entscheidung, einmal pro Zeitfenster, beim ersten Durchlauf des Keepers nach dem Schließen des Zeitfensters und nur, wenn der Vault die Schwelle dann hält (siehe 2026-10-06 unten); seit der sechsten Audit-Schleife, am selben Tag, folgt auch das USDC, das ein Vault hält, diesem Rhythmus. Die Sendung an den Airdrop läuft seit dem 2026-10-05 einmal pro Zeitfenster, nach der Handelszeit des Tages: siehe Der Keeper.

2026-09-27 — Festhängende Gelder und Messung der Bestände

Die Reste eines unterbrochenen Zyklus werden beim nächsten Zyklus fertig verarbeitet, ob die Schwelle erreicht ist oder nicht. Airdrop-Gelder, die 24 Stunden lang in einem Spiegel-Vault festhängen, kann der Owner ohne vorherige Ankündigung bewegen: die einzige Ausnahme von der öffentlichen Wartefrist von 48 Stunden, bewusst gewählt. Die Bestände werden als durchschnittlicher Saldo über die 24 Stunden vor dem Zyklus gemessen, auch montags. Das Zeitfenster für festhängende Gelder wurde am 2026-09-28 auf 48 Stunden verlängert, und die Regel wurde am 2026-10-05 aufgehoben, ohne je programmiert worden zu sein.

2026-09-28 — Degressives Anti-Snipe

80 % im Eröffnungsblock, minus 8 Prozentpunkte pro Block, 5 % ab dem 11. Block, bei Käufen und Verkäufen. Der Überschuss geht an die Treasury des Marktes, bei $STOCKFUN an die claimbaren Gebühren des Teams. Ausgenommen: der Launch-Kauf des Creators und eine vom Creator festgelegte Whitelist, in der Erstellungstransaktion fixiert, öffentlich, unveränderlich und auf 20 Adressen begrenzt; bei $STOCKFUN legt sie der Owner beim Launch fest. Seit dem 2026-10-05 sind diese Zahlen Einstellungen des Owners, mit den obigen Werten als Standardwerten.

Unterwegs verworfen: die Wallets, die in den ersten Blöcken kaufen, zu kennzeichnen und ihre späteren Verkäufe zu besteuern, auch nach einem Transfer. Ein v4-Pool sieht die Wallet nicht, eine vom Token erhobene Tax lässt den Verkauf fehlschlagen, und gekennzeichnete Wallets außerhalb des StockFun-Routers zu blockieren, würde dazu führen, dass der Token von Scannern geflaggt wird. Akzeptierte Konsequenz: Die Whitelist wandert vom Protokoll zum Creator, was die Entscheidung vom 2026-09-12 ausgeschlossen hatte, um einen Insider-Vorteil zu verhindern.

2026-09-28 — Festhängende Airdrop-Gelder: 48 Stunden

Airdrop-Gelder, die 48 Stunden statt 24 in einem Spiegel-Vault geblieben sind, kann der Owner ohne vorherige Ankündigung bewegen. Bei 24 Stunden entsprach das Zeitfenster dem Abstand zwischen zwei Zyklen, sodass schon ein gewöhnlicher Übertrag auf den nächsten Zyklus ohne vorherige Ankündigung bewegt werden konnte; bei 48 Stunden ist das nicht mehr der Fall. Bei einem Fehlschlag am Freitag können die Gelder dennoch schon am Sonntag bewegt werden, vor dem Zyklus am Montag. Am selben Tag beschlossen: Die Frist wird nie angehalten, weder während einer Pause noch am Wochenende. Am 2026-10-05 aufgehoben, nie programmiert: Der Notfall-Transfer erfolgt überall sofort.

2026-09-28 — Bestände onchain aufgezeichnet

Der Token jedes Marktes zeichnet die Bestände jeder Wallet im Zeitverlauf auf, sodass ein Contract den Durchschnitt über die 24 Stunden vor einem Zyklus und jeden Anteil berechnet; der Keeper liefert sie nie. Verworfen: eine Aufteilung, die der Keeper offchain berechnet und mit einer Einspruchsfrist veröffentlicht. Akzeptierte Kosten: Jeder Transfer des Tokens zahlt zusätzliches Gas.

2026-09-28 — Der Airdrop in gewrappten Aktien, auf Ethereum

Die auf Robinhood Chain gekauften Aktien werden dort in von StockFun deployten LayerZero-Adaptern gesperrt, einem pro Aktie, und als gewrappte Aktien nach Ethereum geschickt. Die Distribution findet auf Ethereum statt, wo der Token und seine Bestände leben, und jeder Holder claimt seinen Anteil auf eigene Kosten. Akzeptierte Konsequenzen: Die gewrappten Aktien sind nur so viel wert wie die gesperrten Aktien und die LayerZero-Konfiguration, sie haben keinen Markt auf Ethereum, und ein Einfrieren der Stock Tokens durch ihren Emittenten würde die gesperrten Aktien blockieren. Am selben Tag beschlossen: Der Owner kontrolliert die LayerZero-Konfiguration der Adapter, ohne Wartefrist und ohne Obergrenze für Abhebungen, wie Paxos beim USDG. Verworfen: eine nach dem Deployment eingefrorene Konfiguration sowie Änderungen mit einer Vorankündigung von 48 Stunden.

2026-09-28 — Der offizielle Router bleibt änderbar

Der Owner kann den offiziellen Swap-Router jederzeit ändern, und der Hook erkennt die Anti-Snipe-Whitelist über diesen Router. Akzeptierte Konsequenz: Indem er einen anderen Router benennt, kann der Owner jeden vom Anti-Snipe ausnehmen.

2026-09-28 — Eine Erstellungsgebühr von 0,001 ETH

Die Erstellungsgebühr beträgt künftig 0,001 ETH, im Code festgeschrieben, statt etwa 3 $: kein Preis-Feed, keine Einstellung durch den Owner. Ihr Dollarwert folgt nun dem ETH-Preis. Seit dem 2026-10-05 eine Einstellung des Owners, standardmäßig 0,001 ETH.

2026-09-28 — Der PoolManager außerhalb der Bestandsaufzeichnung

Der Token zeichnet den PoolManager von Uniswap nicht auf: Er ist an jedem Swap beteiligt, hält die Token aller Pools und erhält nie einen Airdrop. Seine Historie liest sich als null, die des Traders wird weiterhin aufgezeichnet. Gemessene Ersparnis: etwa 24.000 Gas pro Swap, beim Kauf wie beim Verkauf.

2026-09-29 — Keine LP-Gebühr in den StockFun-Pools

Die Pools werden mit einer Uniswap-LP-Gebühr von null statt 0,30 % erstellt: Die Tax des Hooks macht die gesamten Kosten eines Trades aus, 5 % pro Richtung und 9,75 % für einen Roundtrip vor Price Impact. Akzeptierte Kosten: Die Treasury, das Team und der Creator verlieren ihren Anteil an den LP-Gebühren, und der Burn der Token-Seite dieser Gebühren entfällt. Seit dem 2026-10-05 ist die LP-Gebühr eine Launch-Einstellung, standardmäßig null; jeder Pool behält die Gebühr, mit der er erstellt wurde.

2026-10-01 — Korrekturen aus dem Security-Audit vom 2026-09-29

Umgesetzt am 2026-09-30 und am 2026-10-01, nachdem jedes Finding geprüft und seine Korrektur gewählt worden war. Jedes behobene Finding hat Regressionstests, die auf dem auditierten Code fehlschlagen.

Nur der Liquiditäts-Lock kann einem StockFun-Pool Liquidität hinzufügen: Eine Position eines Dritten handelte gegen besteuerte Swaps, ohne die Tax oder das Anti-Snipe zu zahlen. Die neue Berechtigung des Hooks hat seine Adresse verändert, deren Mining wiederholt wurde.

Nur der Treasury-Anteil wird während eines Trades gesendet. Die Anteile von Team und Buyback werden auf dem Hook gutgeschrieben und durch Claims, die jeder aufrufen kann, an die aktuellen Wallets der Factory ausgezahlt; den Escrow gibt es nicht mehr. Der Router und der Lock zahlen den Eingangsbetrag vor dem Swap ein. Bis dahin konnte eine Gebühren-Wallet, die Uniswap erneut aufrief, den Handel auf jedem Pool anhalten.

Jeder Konvertierungsschritt gibt einen Betrag aus, den der Keeper nennt, sodass ein Vault, der größer ist als sein Handelsplatz, in Tranchen konvertiert. Das Cash wird beim Eingang pro Aktie des Baskets reserviert, und eine Aktie, die der Keeper überspringt, behält ihre Reservierung; der Spiegel-Vault arbeitet genauso.

Jeder Token zeichnet seine Supply außerhalb des PoolManager von Uniswap im Zeitverlauf auf, den Nenner des Pro-rata-Anteils des Airdrops. Von den drei Optionen des Audits kostet diese einen zusätzlichen Schreibvorgang pro Swap; den PoolManager wieder aufzuzeichnen, hätte etwa 24.000 Gas pro Swap gekostet. Akzeptierte Konsequenz: Die Zeitfenster des Airdrops beginnen und enden zu einer vollen Stunde.

Auf der Robinhood-Rail blockiert ein abgelehnter Basket die anderen Märkte eines Batches nicht mehr, ein Remote-Token erhält eine einzige Kennung, eine v3-Teilausführung lässt ihre Route fehlschlagen, ein pausierter Remote-Hub wendet Rollenänderungen weiterhin an, und kanonische Einträge werden in der Reihenfolge ausgezahlt, in der sie angekommen sind.

Gemessen: Ein Kauf über den Router kostet 113.529 Gas und ein Verkauf 137.250, gegenüber 125.862 und 150.416 vorher. Noch offen, in Erwartung der Entscheidung des Owners: die Rotation des Bridge-Adapters (M-2, und mit ihm L-8), die Ondo-Attestierungen (M-7) und Router, die sich selbst als Empfänger akzeptieren (L-4). Seit dem 2026-10-05 sind M-7 und L-4 korrigiert, und M-2 bleibt auf Entscheidung des Owners, wie es ist, und L-8 mit ihm.

2026-10-01 — Die Security-Pipeline vervollständigt die Korrekturen

Am selben Tag hat eine zweite Audit-Runde, durchgeführt von zwei unabhängigen Auditoren, mehrere Korrekturen vervollständigt. Jede hat Regressionstests; keine ändert eine Design-Entscheidung oder einen unveränderlichen Parameter.

Auf Robinhood Chain läuft eine v3-Route Pool für Pool, und jeder Pool muss seinen gesamten Input aufnehmen: Die bisherige Prüfung sah nur den ersten Pool, und eine Teilausführung weiter hinten ließ den Zwischen-Token dort liegen, wo jeder ihn nehmen konnte. Ein kanonisches Abrechnungsticket zahlt höchstens so viele Einträge aus, wie es der Warteschlange hinzugefügt hat, die ältesten zuerst, sodass ein Rückstau es nicht mehr über das Gas seiner automatischen Ausführung hinaustreibt; der Sweep zahlt den Rest aus.

Eine ausgeführte Notfall-Recovery, die das Cash eines Vaults unter seine Reservierungen senkt, setzt diese alle auf null, in beiden Vaults: Was übrig bleibt, und jeder spätere Eingang, wird neu zu den Gewichtungen aufgeteilt. Bis dahin existierte das Zurücksetzen nur beim Auslesen, und die alten Reservierungen kehrten mit dem nächsten Eingang zurück.

Der Keeper hält bei jedem Kauf n−1 Einheiten vom Anteil der letzten Aktie eines Baskets zurück: Der Rundungsrest geht an diese Aktie, und ein Dust-Transfer konnte den Kauf fehlschlagen lassen. Er halbiert außerdem eine Burn-Tranche, die der $STOCKFUN-Pool nicht vollständig ausführen kann. Jeder Token zeichnet seine erste Stundenmarke beim Deployment auf, was nur bei einer Uhr eine Rolle spielte, die in Stunde 0 beginnt, etwa der einer Test-Chain. Der Aktien-Router auf Ethereum synchronisiert, bevor er in ETH zahlt, und die Lens lehnt eine leere Seite ab.

Gemessen: Der erste Swap eines Tokens in jeder Stunde kostet als eigene Transaktion etwa 28.000 bis 30.000 Gas mehr, nicht etwa 23.000.

In Erwartung der Entscheidung des Owners, nicht entschieden: eine Notfall-Recovery, die erfasstes Cash des Remote-Hubs betrifft, dessen Einträge dann aus dem Cash anderer Märkte ausgezahlt werden (R2H-1); ein Cash-Token, der einen einzelnen Spiegel-Vault ablehnt, was die kanonische Warteschlange anhält und die mit diesem Markt gebündelten Batches fehlschlagen lässt (R2H-2); die Contract-Seite der Marge bei der letzten Aktie, welche die dokumentierte Allokationsregel ändert (R2T-1); die Tax auf Käufe als PoolManager-Claims zu erheben, sodass jeder Router kaufen kann (R2F-1, option b); den Vault von $STOCKFUN von der Factory selbst deployen zu lassen (R2F-2); und drei informative Punkte (R2H-4, R2H-6, R2H-7). Eine Aktie, die nie wieder gekauft werden kann, erhält weiterhin ihren gewichteten Anteil an jedem Eingang: Das ist beabsichtigt, da das Stilllegen eines Legs die festen Gewichtungen des Baskets ändern würde. Seit dem 2026-10-05 ist R2H-1 durch die Bereinigungswerkzeuge der Audit-Schleifen dieses Tages plus ein Verfahren abgedeckt, bei dem der Owner den Remote-Hub vor dem Transfer pausiert; R2H-2 ist durch die nicht blockierenden Zustellungen der vierten Schleife geschlossen; Option b von R2F-1 ist abgelehnt, die Tax bleibt so erhoben, wie sie ist; und ein Vault, der ETH ablehnt, legt seinen Markt nicht mehr still, der von R2F-2 beschriebene Stillstand: siehe die Einträge vom 2026-10-05 unten.

2026-10-02 — Jedes Modul upgradebar

Bis dahin konnte kein Contract des Protokolls upgegradet werden. Jedes Modul außer den Tokens und dem Liquiditäts-Lock wird durch den Owner von StockFun upgradebar, mit sofortiger Wirkung: kein Timelock. Jedes ist ein Proxy, der per UUPS upgegradet wird, und fragt seine Upgrade-Autorität, wer es upgraden darf: die Factory auf Ethereum, den Remote-Hub auf Robinhood Chain. Die Vaults sind auf beiden Chains ein Proxy pro Markt und werden Markt für Markt upgegradet. Der Proxy des Hooks wird durch Mining mit allen 14 v4-Berechtigungen ermittelt, sodass eine spätere Implementierung jeden Callback nutzen kann, ohne die Adresse zu ändern.

Die Tokens tragen keine eigene Logik: ein einfacher ERC-20 mit fester Supply und einem einzigen Setter, setRecorder, für den Owner. Die Bestandsaufzeichnung verlässt sie zugunsten eines neuen Moduls, des Bestandsaufzeichners, den jeder Token bei jedem Transfer aufruft; schlägt der Aufruf fehl, schlägt der Transfer fehl. Seit dem 2026-10-05 haben die Tokens außerdem Rescues für das, was an ihre eigene Adresse gesendet wird, und dieser blockierende Aufruf ist die einzige bewusste Ausnahme von der Isolationsregel des Gründers (siehe unten).

Der Liquiditäts-Lock bleibt nicht upgradebar und erhält einen Endmodus: Der Owner kündigt ihn an und kann 30 Tage später die gesamte Liquidität jedes Pools, die von $STOCKFUN eingeschlossen, an eine beliebige Adresse zurückholen. Der Owner kann abbrechen; während der 30 Tage geht der Handel weiter, und solange ein Ende aussteht, kann kein neuer Markt gelauncht werden. Er existiert für den Fall, dass das Projekt eingestellt wird; die 30 Tage sind die Vorankündigung für die Holder. Der Deployer der Spiegel-Vaults auf Robinhood Chain ist ebenfalls nicht upgradebar: Die Adresse jedes Spiegel-Vaults wird aus seiner abgeleitet.

Was sich ändert: Ein Upgrade wartet nicht die 48 Stunden des Notfallmodus ab, der bestehen bleibt; die Regeln, die dieses Buch fest nennt, von den Grenzen der Vaults bis zum Burn und zum Satz von 5 %, gelten, solange der Owner das Modul, das sie trägt, nicht upgradet; die Factory wird zuerst deployt und vom Owner verdrahtet, was die Deployment-Reihenfolge ändert. Ein Swap kostet etwa 27.000 Gas mehr, isoliert gemessen: ein Kauf 237.190 Gas statt 210.105, ein Verkauf 285.031 statt 258.278 — der Preis der Proxys auf seinem Pfad und des Aufrufs an den Bestandsaufzeichner. Seit dem 2026-10-05 hat auch der Notfallmodus keine Wartefrist mehr, und die Grenzen der Vaults und der Satz von 5 % sind Einstellungen des Owners.

2026-10-04 — Der Airdrop-Contract

Programmiert und getestet, nicht deployt. AirdropDistributor, ein upgradebares Modul auf Ethereum, an die Factory gebunden, verteilt die Aktien jedes Marktes in täglichen Zyklen. Das Zeitfenster eines Zyklus schließt um 13:00 UTC, das ganze Jahr über vor der Eröffnung der US-Börse; seine Käufe und Sendungen laufen in der folgenden Handelszeit. Ein Zyklus wird mit seiner ersten Sendung eröffnet, oder vorher, und friert seine Zahlen ein: den Bestandsaufzeichner, die Ausschlussliste, die beim Schließen des Zeitfensters galt, und die berechtigten Bestände. Zwei Wege speisen ihn, sendToAirdrop auf dem Spiegel-Vault, über den LayerZero-Adapter jeder Aktie, und auf dem Vault auf Ethereum für die lokale Rail; nichts anderes schreibt einem Zyklus etwas gut.

Am selben Tag entschieden: kein Push durch den Keeper, nur der Holder claimt, auf eigene Kosten (TBD 5); keine Obergrenze pro Wallet, kein Minimum, keine Frist (TBD 7); eine Ausschlussliste pro Token, vom Owner festgelegt, höchstens 16 Adressen, immer mit der Burn-Adresse und mit dem Vesting-Contract bei $STOCKFUN (TBD 8). Eine Sendung für ein Zeitfenster ohne berechtigte Bestände wird für das erste Zeitfenster beiseitegelegt, das welche hat, wer auch immer aufruft und wann auch immer, solange sich die Zyklus-Uhrzeit in der Zwischenzeit nicht ändert und der Bestandsaufzeichner des Tokens nicht ersetzt wird.

Akzeptiert und dokumentiert: Der Keeper wählt, wann, sodass eine Sendung, die nach dem nächsten 13:00 UTC ankommt, über das Zeitfenster des nächsten Tages gemessen wird; eine Verschiebung der Zyklus-Uhrzeit schneidet die noch nicht eröffneten Zeitfenster neu, einschließlich derer, die beiseitegelegte Aktien noch prüfen müssen; der Bestandsaufzeichner eines Tokens wird per Upgrade aktualisiert, nie bei einem laufenden Token ersetzt. Nicht Teil dieser Änderung: die 48-Stunden-Regel für festhängende Gelder, die Aktien-Adapter, der Airdrop-Schritt des Keepers und die Claim-Ansicht der Dapp. Seit dem 2026-10-05 gibt es keinen Vesting-Contract mehr, der auszuschließen wäre, die 48-Stunden-Regel ist aufgehoben, und die Zyklus-Uhrzeit gehört zu einem Zeitplan, den der Owner festlegt, Länge und Schließzeitpunkt der Zeitfenster (setCycleSchedule); ein Bestandsaufzeichner, der bei einem laufenden Token benannt wird, startet mit der Supply des Tokens außerhalb des PoolManager (siehe den Eintrag zur Audit-Schleife unten).

2026-10-05 — Keine Team-Allokation, ein sofortiger Notfallmodus, jede Zahl eine Einstellung

Drei Entscheidungen, am selben Tag programmiert und getestet, nicht deployt.

Die Team-Allokation entfällt. Der Vesting-Contract des Teams, TeamVesting, ist gelöscht, und kein $STOCKFUN ist für das Team reserviert: Die gesamte Supply, standardmäßig 1.000.000.000 Tokens, geht in die einseitige gesperrte Position, so wie die gesamte Supply eines Marktes in seine zwei Positionen geht. Bis dahin gingen 10 % über 12 Monate an den Vesting-Contract, und der Airdrop schloss diesen Contract aus den Zyklen von $STOCKFUN aus; jetzt ist nur noch die Burn-Adresse ausgeschlossen, dazu, seit der dritten Audit-Schleife dieses Tages, der Betreiber des Launchs (siehe unten).

Der Notfallmodus wird sofort wirksam. emergencyTransfer bewegt ein Asset aus einem Vault, einem Bridge-Hub oder dem Airdrop-Contract an eine beliebige Adresse, sofort; jeder Transfer hat eine fortlaufende ID und ein öffentliches Event. Die 48-Stunden-Planung vom 2026-08-29 gibt es nicht mehr, ebenso wenig ihr Zeitfenster zum Abbrechen, und die Wartefrist ist kein Parameter: Ein Notfall wirkt, sobald der Owner ihn auslöst, nie nach einer Wartezeit. Der Austausch des Bridge-Adapters, changeAdapter, erfolgt ebenfalls sofort, unter denselben Fixierungen. Die Regel für festhängende Airdrop-Gelder, beschlossen am 2026-09-27 und am 2026-09-28 und nie programmiert, ist aufgehoben: Der sofortige Transfer deckt sie ab, auf jedem Contract, jederzeit.

Jede Zahl wird eine Einstellung. Die Zahlen des Protokolls sind jetzt Onchain-Einstellungen des Owners, auf beiden Chains, mit den heutigen Werten als Standardwerten: die Tax, ihre Aufteilung und das Anti-Snipe; die Erstellungsgebühr und die Längengrenzen der Textfelder eines neuen Marktes; die Form neuer Märkte, LP-Gebühr und Tick-Spacing eingeschlossen, und die Anteile an dem, was die gesperrten Positionen einsammeln; die Konvertierungsschwelle und die Preisgrenzen der Vaults; der Zeitplan und die Limits des Airdrops; die Heartbeats der Oracles; Gas und Slippage der Bridge. Jede wirkt sofort und lehnt unmögliche Werte ab. Eine Änderung der Tax gilt ab dem nächsten Swap auf jedem Pool, auch auf einem, der sich noch in seinen Anti-Snipe-Blöcken befindet; eine Änderung der Form gilt für die danach erstellten Märkte, und jeder Pool behält die LP-Gebühr und das Tick-Spacing, mit denen er erstellt wurde.

Fest bleiben: die Vorankündigung des Endmodus von 30 Tagen, END_DELAY, im Lock, der nicht upgradebar ist; die Einheiten und Kodierungen, vom Basispunkt bis zur Stunde der Bestandsaufzeichnung; und die Verdrahtung, von den Preis-Feeds bis zu den Endpoints der Bridge, die nur ein Upgrade anderswohin verweisen lassen kann.

Akzeptierte Konsequenz: Die Zahlen, die dieses Buch für die Tax, den Launch, die Vaults und den Airdrop nennt, sind Standardwerte, keine Garantien; der Owner kann jede davon jederzeit ändern, ohne vorherige Ankündigung. Gemessen: Das Lesen der Tax-Einstellungen kostet einen Swap etwa 1.200 Gas mehr, bei warmem Storage. Siehe Vertrauensmodell.

2026-10-05 — Die Korrekturen der Audit-Schleife

Am selben Tag führte eine Review-Schleife über den gesamten Code zu Korrekturen an den Contracts, jede mit einem Regressionstest, nicht deployt. Vier davon ändern das Verhalten.

Nach einem Notfall-Transfer werden die Bücher bereinigt, nie aus einem anderen Markt bezahlt. Der Airdrop-Contract und der Remote-Hub halten Assets, die mehreren Märkten geschuldet werden. Nach einem Transfer aus einem der beiden warten die Auszahlungen, die von dem abhängen, was fehlt — die Claims dieser Aktie beim Airdrop, die Auszahlungen des Remote-Hubs auf der USDG-Rail —, bis die Assets zurückkommen oder der Owner von StockFun den Verlust zulasten des Zyklus oder des Marktes abschreibt, der ihn erlitten hat; auf der kanonischen Rail streicht der Owner den Eintrag, dessen Cash der Transfer genommen hat, bevor die nächste Einzahlung ankommt. Eine teilweise Abschreibung zulasten eines Zyklus ist nur möglich, solange niemand die Aktie aus ihm geclaimt hat, wobei dann jeder Holder denselben Anteil verliert; sobald einige Holder ausgezahlt worden sind, nur noch die Abschreibung seines gesamten Rests, den die noch nicht ausgezahlten Holder verlieren. Der Transfer selbst erfolgt weiterhin sofort und ohne Bedingung. Siehe Notfallmodus.

Nur der Keeper bridgt. Bis dahin konnte jeder einen Bridge-Batch senden: Ein Dritter konnte einen zum lockersten Mindestbetrag des Adapters zwischen zwei eigene Trades auf dem Curve-Pool einschieben oder den Batch des Keepers fehlschlagen lassen, indem er zuerst einen der Vaults dieses Batches bridgte.

Nur der Keeper und der Owner von StockFun deployen einen Spiegel-Vault auf Robinhood Chain vorab. Bis dahin konnte das jeder, sogar für einen Markt, der noch nicht existierte, gebunden an die Verdrahtung dieses Tages. Ein vorab deployter Vault übernimmt jetzt bei seinem ersten Batch den Aktien-Router und das Oracle des Remote-Hubs.

Ein Bestandsaufzeichner, der bei einem laufenden Token benannt wird, startet mit der Supply des Tokens außerhalb des PoolManager, und ein Bestandsaufzeichner, der den Token schon einmal aufgezeichnet hat, lehnt ihn ab. Bis dahin startete ein neuer Bestandsaufzeichner bei null: Jeder Verkauf schlug fehl, und die Airdrop-Anteile der danach eröffneten Zyklen waren endgültig gebrochen. Jetzt geht der Handel weiter, und die Holder, bei denen der neue Bestandsaufzeichner keine Bewegung gesehen hat, lesen sich bis zu ihrer nächsten Bewegung so, als hätten sie nichts gehalten. Den Bestandsaufzeichner per Upgrade zu aktualisieren, bleibt die Regel.

Kleinere Korrekturen: Die Vaults wenden den eigenen Mindestbetrag des Keepers auf das an, was tatsächlich ankommt, nicht nur ihre eigene Grenze; das Abrechnungsticket der kanonischen Bridge zahlt für die Größe des Batches; die Einstellungen verweigern einen Launch-Tick, bei dem kein Pool eröffnet werden kann, eine leere Längengrenze für den Namen sowie einen Hook und einen Lock auf verschiedenen PoolManagers; eine Umstellung auf längere Airdrop-Zeitfenster blockiert einen Markt mit beiseitegelegten Aktien nicht mehr. Siehe Vertrauensmodell.

2026-10-05 — Der zweite Durchgang der Audit-Schleife

Am selben Tag führte eine zweite Review-Schleife über die Korrekturen zu weiteren Korrekturen an den Contracts, jede mit einem Test, nicht deployt, und zu Änderungen am Keeper.

Die Bücher zählen, was sie deckt, nie den Saldo. Der Saldo des Airdrop-Contracts, und der des Remote-Hubs auf der USDG-Rail, umfasst auch Tokens, die angekommen, aber noch nicht gutgeschrieben sind: eine Zustellung, deren letzter Schritt noch nicht gelaufen ist. Nach einem Notfall konnten solche Tokens die Claims eines geleerten Zyklus wieder öffnen und sie mit den Aktien eines anderen Marktes bezahlen. Beide Contracts zählen jetzt selbst, was ihre Bücher deckt. Ein Notfall-Transfer nimmt zuerst davon; was er darüber hinaus nimmt, stammt aus noch nicht gutgeschriebenen Tokens, und die nächsten Zustellungen tilgen es, bevor sie irgendetwas decken, wobei der Remote-Hub diese Batches erfasst, statt sie zuzustellen. Assets kommen über restore zurück, das jeder aufrufen kann; ein einfacher Transfer deckt nichts, daher werden verirrte Tokens nur gerettet, um zurückgebracht zu werden. Siehe Notfallmodus.

Nach einer Abschreibung des gesamten Rests eines Zyklus, die auf einen Claim folgt, wird alles, was diesen Zyklus danach erreicht, pro rata zwischen allen seinen Holdern aufgeteilt, als wäre der abgeschriebene Betrag nie da gewesen; bis dahin ging es zuerst an die noch nicht ausgezahlten Holder, in der Reihenfolge, in der sie geclaimt haben. Eine Abschreibung, die einem Markt nichts Beiseitegelegtes übrig lässt, beendet seine Suche nach einem Zeitfenster.

Ein Token lehnt einen Bestandsaufzeichner ab, der an einen anderen PoolManager von Uniswap gebunden ist als den seines Pools, wodurch der Pool als Holder gezählt und jedem Holder ein Bruchteil seines Anteils ausgezahlt würde. Und ein Bestandsaufzeichner, der bei einem laufenden Token benannt wird, führt eine aufgezeichnete Supply, die mindestens so groß ist wie der Gesamtbestand der Holder, nicht gleich groß, bis sich jeder Holder bewegt hat.

Auf der kanonischen Bridge wird die Gebühr bei einer Basisgebühr abgefragt, die der Keeper nennt, dem Doppelten der letzten, wobei der Überschuss erstattet wird: Eine Preisabfrage, die ohne Gaspreis ausgelesen wurde, sah eine Basisgebühr von null, und ein langer Batch schlug fehl. Der Remote-Hub erfährt nur aus einem Batch, wer der Keeper ist: Vor dem ersten deployt der Owner von StockFun den Spiegel-Vault des ersten Marktes vorab, und ein Markt, dessen Vault der Keeper nicht vorab deployen kann, wird mit einer Warnung aus seinem Batch herausgehalten. Der Keeper zählt die Fehlschläge eines Vaults auf Ethereum und auf Robinhood Chain getrennt.

Aus der zweiten Runde vom 2026-10-01: R2H-1 ist durch die Bereinigungswerkzeuge plus ein Verfahren abgedeckt, bei dem der Owner den Remote-Hub vor dem Transfer pausiert; R2H-2 ist entschärft, noch offen: Ein eingefrorener Spiegel-Vault hält die kanonische Warteschlange nicht mehr endgültig an, und nur der Keeper stellt einen Batch zusammen, aber eine Zustellung an diesen Vault schlägt weiterhin als Ganzes fehl, sodass der Keeper diesen Markt heraushalten muss. Siehe Vertrauensmodell. Am selben Tag geschlossen durch den vierten Durchgang: siehe unten.

2026-10-05 — Ein Fehler blockiert nie den Rest

Die Designregel des Gründers, am selben Tag festgelegt: Wenn etwas eine Funktion fehlschlagen lässt, dürfen die anderen Funktionen nicht dafür zahlen; alles muss weiterlaufen, und alles muss einen Hebel haben, um verlorene Gelder zurückzuholen und die Korrektur aufzunehmen. Sie hat zwei Teile. Isolation: Ein Fehler in einer Funktion, einem Markt, einer Aktie, einem Zyklus, einem Eintrag oder bei einem Empfänger blockiert nie die anderen; das Element wird übersprungen, als geschuldet behalten oder zurückgestellt, mit einem Event, und der Rest läuft weiter. Hebel: Jeder Contract, der ETH oder Tokens halten kann, auch nur vorübergehend oder versehentlich, hat einen Hebel, um herauszuholen, was feststeckt, und jedes Modul kann eine Korrektur aufnehmen, ein Upgrade oder einen Setter, der es austauscht. Ab der vierten Audit-Schleife zählen die Schleifen jeden Verstoß als Defekt.

Eine bewusste Ausnahme: Die Meldung eines Tokens an seinen Bestandsaufzeichner bleibt blockierend, eine fehlschlagende Meldung lässt den Transfer fehlschlagen. Eine Meldung, die fehlschlagen dürfte, ließe einen Holder ihr bei seinem eigenen Transfer das Gas entziehen, sodass die Aufzeichnung die Bewegung überspringt und sein Airdrop-Anteil wächst. Der Hebel wirkt sofort: setRecorder(0) auf dem Token oder ein Upgrade des Bestandsaufzeichners an derselben Adresse, je eine Transaktion.

Akzeptierte Folgen: Ein abgelehnter Anteil wartet auf seinen Empfänger, statt den Rest anzuhalten; ein Notfall-Transfer, der keinem Markt angelastet ist, lässt die Auszahlungen dieses Assets warten, bis er bereinigt ist; und solange ein Token keinen Bestandsaufzeichner hat, eröffnet der Airdrop keinen Zyklus für ihn und legt seine Aktien beiseite. Siehe Architektur.

2026-10-05 — Der dritte Durchgang der Audit-Schleife

Am selben Tag eine dritte Schleife, über Abfolgen: Operationen, die einzeln korrekt sind und in einer bestimmten Reihenfolge oder zu einem bestimmten Zeitpunkt schiefgehen. Jede Korrektur hat einen Test, nicht deployt.

restore zahlt zuerst zurück, was ein Notfall-Transfer über das hinaus genommen hat, was die Bücher deckt, auf dem Airdrop-Contract und auf der USDG-Rail des Remote-Hubs, und deckt die Bücher mit dem Rest: Die Rückgabe der Tokens einer wartenden Zustellung zahlt mit ihnen nicht mehr den geleerten Markt aus. Eine Aktie, die als Ganzes aus einem Zyklus abgeschrieben wurde, bevor jemand sie geclaimt hat, verlässt die Liste dieses Zyklus.

Ein auf einem laufenden Token benannter Bestandsaufzeichner beginnt beim Wechsel eine neue Aufzeichnung: Der Airdrop misst kein Zeitfenster, das vor dem Wechsel begann, dessen Aktien, beiseitegelegt, auf das erste Zeitfenster warten, das er vollständig abdeckt, und der Token meldet den Saldo der Burn-Adresse beim Wechsel. Bis dahin zahlte ein solches Zeitfenster, nur ab dem Wechsel gemessen, demjenigen zu viel aus, der sich danach bewegte. Verfahren: zuerst die Zyklen der bereits geschlossenen Zeitfenster eröffnen, dann direkt nach dem Ende eines Zeitfensters wechseln; das Upgrade des Bestandsaufzeichners an derselben Adresse bleibt die Regel.

Das Launch-Skript von $STOCKFUN schließt den Betreiber des Launchs vom Airdrop aus, dessen erster Zyklus diesen Bestand bis dahin auszahlte. Die Bridge-Skripte brechen vor dem Deployment ab, wenn die Factory bereits einen anderen Hub benennt, und mappen die Aktien, bevor sie den Hub benennen; setBridgeHub lehnt einen Hub ab, der einen registrierten Basket nicht transportieren kann. Offchain: Eine Transaktion, deren Receipt nicht gelesen werden kann, wird über ihren Hash verfolgt und nie zweimal gesendet; die Notfall-Überwachung liest ihre Events in Abschnitten und meldet einmal, wenn sie fehlschlägt, und einmal, wenn sie sich erholt; ein Markt, dessen Batch-Eintrag nicht gebaut werden kann, bleibt außen vor, mit einem Alert. In der App behält eine unbestätigte Transaktion ihren Hash (seit der zehnten Audit-Schleife wird sie bis zu dem verfolgt, was an ihrer Nonce gemint wird, und ein Abbruch in der Wallet wird nie als erledigt gelesen: unten), und ein Pool, den der Endmodus zurückgeholt hat, zeigt weder Preis noch Handel.

2026-10-05 — Der vierte Durchgang der Audit-Schleife: die Regel im Code

Am selben Tag hat die vierte Schleife die Regel des Gründers in den Code gebracht. Jede Korrektur hat einen Regressionstest, nicht deployt.

Bridge-Zustellungen blockieren nie einen anderen Markt, die Entscheidung des Owners zu R2H-2: Ein Anteil, den der Cash-Token einem Spiegel-Vault verweigert, bleibt auf dem Remote-Hub, seinem Markt geschuldet, und die anderen werden ausgezahlt; auf der kanonischen Rail verlässt er die Warteschlange, sodass die Einträge dahinter ausgezahlt werden. Jeder zahlt ihn später mit sweep aus. Ein Notfall-Transfer auf dem Remote-Hub kann einem einzelnen Markt angelastet werden, dessen Bücher im selben Aufruf bereinigt werden. Claims zahlen, was sie können: Eine Aktie, für die die Bücher nicht ausreichen oder deren Transfer abgelehnt wird, wird zurückgestellt und bleibt geschuldet, und claimMany überspringt einen Zyklus, der den Aufrufer ausschließt. Jedes Kauf-Leg, jede Aktie einer Sendung an den Airdrop und jeder Markt eines Bridge-Batches geht für sich. Ein Vault, der ETH ablehnt, legt seinen Markt nicht mehr still: Der Hook behält, was er nicht auszahlen konnte, als Schuld gegenüber diesem Vault, der Lock behält einen abgelehnten Anteil einer Gebühreneinsammlung für seinen Empfänger, und jeder zahlt sie aus; ein Creator-Contract, der kein ETH annehmen kann, claimt an eine andere Adresse. Die Lens liest einen Vault nach dem anderen.

Hebel überall: ein Rescue dessen, was ein Modul versehentlich hält, auf jedem Modul, das nichts von irgendwem behält, auf dem Hook nur für verirrte Beträge, auf dem Lock nie für die Anteile, die er behält, auf dem Burner für sein ETH erst, wenn kein Burn es mehr ausgeben könnte, und auf beiden Tokens; die Vaults, die Hubs und der Airdrop-Contract behalten den Notfallmodus.

Außerdem: Der Ondo-Router bedient nur die Vaults seiner Factory (M-7), und jeder Router lehnt sich selbst als Empfänger ab (L-4); das Einzahlungsticket der kanonischen Rail wird bei der Basisgebühr bepreist; das Launch-Skript von $STOCKFUN setzt den Betreiber vor dem Mint auf die Liste; die Storage-Prüfung vergleicht jede Ebene jedes Structs. Am selben Tag entschieden: M-2 und R2F-1 bleiben, wie sie sind. Siehe Notfallmodus und Vertrauensmodell.

2026-10-05 — Der Airdrop-Schritt des Keepers und die Claim-Ansicht

Am selben Tag geschrieben, auf Wunsch des Gründers, ohne neue Entscheidung; nicht deployt. Der Keeper sendet die Aktien jedes Marktes einmal pro Zeitfenster, standardmäßig nach der US-Handelszeit: zuerst die beiseitegelegten Aktien zugewiesen, dann der Zyklus eröffnet, dann die Sendung, jede Aktie und jeder Markt für sich, und jede Zustellung von Robinhood Chain verfolgt, bis sie gutgeschrieben ist, mit einem Alert, der den Befehl enthält, um eine verspätete erneut auszuführen. Die Claim-Ansicht der Dapp listet, was eine Wallet claimen kann, Zeitfenster für Zeitfenster, und claimt bis zu zehn Zeitfenster pro Transaktion, etwa 3,4 bis 3,5 Millionen Gas, kalt gemessen. Weggelassen: den letzten Schritt einer fehlgeschlagenen Zustellung automatisch auszuführen; der Alert nennt stattdessen den Befehl.

Der Offchain-Durchgang der vierten Schleife gab dem Keeper dann seine neuen Aufgaben: die Schulden auszahlen, die der Hook und der Lock behalten, fehlgeschlagene Legs, wiederholt ausgelassene Märkte und abgelehnte Zustellungen melden, jedes Aktien-Leg für sich planen, eine Zustandsdatei über Neustarts hinweg und die tägliche Einsammlung der LP-Gebühren. Die App zeigt „Figures unavailable“ für einen Vault, der nicht antworten kann. Siehe Der Keeper und Die Dapp.

2026-10-05 — Der fünfte Durchgang der Audit-Schleife

Am selben Tag fand eine fünfte Schleife sieben Probleme geringen Schweregrads, jedes mit einem Test korrigiert, nicht deployt. Der einem kanonischen Eintrag angelastete Transfer des Remote-Hubs ist für einen Eintrag gedacht, dessen Einzahlung angekommen ist: Er lehnt einen Betrag ab, der über das Cash hinausgeht, das nicht für abgelehnte Anteile zurückgehalten wird, und ein Eintrag, dessen Einzahlung verloren ist, wird abgeschrieben. Eine Aktie, deren Saldo nicht gelesen werden kann, stoppt weder eine Sendung an den Airdrop noch deren Preisabfrage, und ein Adapter ohne Code stoppt die Preisabfrage ebenso wenig. Die Implementierungs-Contracts der Factory und des Remote-Hubs, die ihren Admin im Storage des Proxys halten, haben ihren Deployer als Hebel für das, was an sie gesendet wird. Der Lock und beide Tokens erhalten Rescues für v4-Claims und NFTs, die versehentlich an sie gesendet wurden; der Lock hat weiterhin keinen generischen Aufruf. Ein Bridge-Batch lässt einen Markt aus, dessen Vault noch keinen Code hat. Ein Kommentar, der falsch beschrieb, wie ein Kauf Gelder bewegt, wurde korrigiert. Siehe Notfallmodus.

2026-10-06 — Der Offchain-Durchgang der fünften Schleife

Das Review des Offchain-Codes in der fünften Schleife fand drei Probleme mittlerer und sechzehn geringer Schwere, jedes am selben Tag mit einem Test behoben, nicht deployt. Der Keeper hält sich jetzt an den Rhythmus vom 2026-09-27: Das ETH eines Vaults wird einmal pro Airdrop-Zeitfenster konvertiert, wenn der Vault beim ersten Durchlauf des Keepers nach dem Schließen des Zeitfensters die Schwelle hält; darunter wartet das ETH auf das nächste Zeitfenster. Bis dahin konvertierte der Keeper es bei jedem Durchlauf der Handelszeit, sobald der Vault die Schwelle hielt. Jede Transaktion, die der Keeper sendet, wird mit ihrer Nonce in seine Zustandsdatei geschrieben, bevor auf ihr Receipt gewartet wird, sodass ein Keeper, der während des Wartens beendet wird, sie nicht erneut sendet; eine, die kein Node mehr kennt, wird nach einer Frist aufgegeben; ein Zustandsordner wird jeweils nur von einem Keeper benutzt. Auf der Ondo-Rail wird ein Kauf, den Ondo unter der Grenze des Vaults bepreist, nicht mehr gesendet, um fehlzuschlagen, und keine Attestierung mehr dafür bezahlt. Eine Aktie, deren Adapter nicht antwortet, bleibt für sich allein aus einer Airdrop-Sendung heraus.

Ein Basket umfasst höchstens fünf Aktien, eine technische Grenze, die der Owner von StockFun per Upgrade ändern kann: Alle Kosten, die mit einem Basket wachsen, sind bis zu dieser Größe gemessen, und die drei Launch-Baskets umfassen drei, drei und zwei. Die Lens enthält den Zustand jedes Vaults und das, was der Hook und der Lock ihm schulden, und ihr Upgrade geht vor dem Worker und der App, die sie lesen, live. Das Launch-Skript von $STOCKFUN setzt einen Lauf fort, der vor der Benennung des Protokoll-Markts abgebrochen ist, statt einen zweiten Token zu minten. Die App zählt das einem Vault geschuldete ETH zu seiner Treasury, lässt in einem Claim Spielraum für eine Aktie, die gutgeschrieben wird, bevor er gemined ist, merkt sich eine Aktie, die ihr Token abgelehnt hat, und zeigt eine Zahl, die sie nicht lesen konnte, nie als nichts an. Siehe Der Keeper, Baskets und Die Dapp.

2026-10-06 — Die sechste Audit-Schleife

Die sechste Schleife fand ein Problem hoher und fünf geringer Schwere, jedes am selben Tag mit einem Test behoben, nicht deployt. Auf der kanonischen Bridge, die auf dem Testnet und als Fallback genutzt wird, hörte der Keeper auf, die Tickets eines Batches erneut auszuführen, sobald dessen Märkten gutgeschrieben war, und einem Markt konnte das Cash eines anderen Batches gutgeschrieben werden, sodass eine Einzahlung, die ihre automatische Ausführung verpasst hatte, verfallen konnte. Der Keeper verfolgt jetzt jedes Ticket, bis er weiß, dass es ausgeführt wurde, unabhängig von der Gutschrift seines Transfers, führt eines, das noch lebt, erneut aus und meldet, wenn eines nach standardmäßig sechs Stunden nicht als ausgeführt bekannt ist oder verloren ist; er schreibt einen kanonischen Transfer nur anhand der eigenen Events des Remote-Hubs gut, nie anhand eines Saldos.

Mit den Korrekturen kam eine Entscheidung, vom Audit als dessen empfohlener Standard getroffen: Der Rhythmus vom 2026-09-27 erstreckt sich auf das USDC. Das USDC eines Vaults, ob auf Ethereum in Aktien umgesetzt oder über die Bridge gesendet, geht einmal nach jeder Konvertierung seines ETH und sonst höchstens einmal pro Zeitfenster; bis dahin brachten ein paar Einheiten USDC, die an einen Vault gesendet wurden, den Keeper dazu, bei jedem Durchlauf eine Transaktion oder einen ganzen Bridge-Batch zu senden. Die Käufe auf Robinhood Chain laufen weiterhin bei jedem Durchlauf: Der Saldo eines Spiegel-Vaults kann eine Zustellung nicht von einem Geschenk unterscheiden, und die Obergrenzen jedes Kaufs verteilen eine große Zustellung absichtlich auf mehrere Durchläufe. Lokale und Testnet-Läufe schalten beide Rhythmen mit demselben Schalter ab.

Ebenfalls behoben: Eine Suche nach beiseitegelegten Aktien, die nichts zuweisen würde, für einen Vault, der nichts zu senden hat, wird nicht mehr jeden Tag gesendet; ein Vault unter der Schwelle wird anhand eines nach dem Schließen des Zeitfensters gelesenen Saldos geprüft; früher am selben Tag wurde die lokale Deployment-Datei vor der Verwendung gegen die Chain geprüft; die App markiert den Preis von $STOCKFUN mit „(last read)“, solange die Lens seine Treasury nicht lesen kann, und der Worker zeichnet in dieser Zeit keinen Preis für ihn auf. Die nächste Schleife, am selben Tag begonnen, stellte fest, dass der Keeper jeden Vault auf einem einzigen Router bepreiste, während jeder Vault den Router behält, mit dem er erstellt wurde: Jeder Vault wird jetzt auf seinem eigenen bepreist. Siehe Der Keeper.

Seit der siebten Schleife, unten, bedeutet „nichts zu senden“ nichts, was das Senden wert ist, und der Keeper liest jedes Ticket zuerst aus dem Receipt seiner Erstellung.

2026-10-06 — Die siebte Audit-Schleife

Die siebte Schleife fand ein Problem mittlerer und vierzehn geringer Schwere, jedes am selben Tag mit einem Test behoben, nicht deployt; die Contracts waren sauber. Auf der kanonischen Bridge las der Keeper, ob ein Ticket noch existierte, bevor er das Receipt seiner Erstellung las: Eine Einzahlung, die zwischen den beiden Lesevorgängen erstellt oder von zwei Nodes mit einem Block Abstand gesehen wurde, konnte als ausgeführt gelten, während sie noch lebte, und ohne erneute Ausführung und ohne Alert verfallen. Er liest sie jetzt in der Reihenfolge, in der das Arbitrum SDK es tut: zuerst das Receipt, dann die automatische Ausführung, dann das Ticket an einem Block, der nicht vor seiner Erstellung liegt.

Mit den Korrekturen kam eine Entscheidung, vom Audit als dessen empfohlener Standard getroffen: Der Keeper sendet an den Airdrop nur, was so viel wert ist, wie sein Senden kostet. Eine Aktie über dem Dust, den die LayerZero-Bridge nicht transportieren kann, bewertet mit dem eigenen Oracle ihres Vaults zur letzten Antwort ihres Preis-Feeds, muss ihre eigene LayerZero-Gebühr wert sein, oder ihren Anteil am Gas der Sendung auf Ethereum, und die Aktien, die bestehen, müssen zusammen die ganze Sendung wert sein, plus die Eröffnung des Zyklus des Zeitfensters, wenn er noch nicht eröffnet ist; sonst warten sie im Vault auf ein späteres Zeitfenster, mit dem, was sich ansammelt. Ein Wert, den der Keeper nicht lesen kann, lässt die Sendung gehen, wie zuvor. Das Vielfache ist eine Einstellung des Keepers, KEEPER_AIRDROP_MIN_VALUE_BPS: standardmäßig einmal die Kosten, 0 schaltet die Regel ab. Sie entscheidet nur, wann eine Aktie geht, nie wie viel, was oder wohin. Bis dahin brachte ein Geschenk von Aktien knapp über dem Dust an den Vault eines Marktes, den niemand handelt, den Keeper dazu, den Zyklus dieses Zeitfensters zu eröffnen und jeden Tag eine LayerZero-Nachricht zu bezahlen; und derselbe Dust zählte als „etwas zu senden“, sodass die Grenze für Suchen nach beiseitegelegten Aktien aus der sechsten Schleife auf der Bridge nicht griff.

Ebenfalls behoben: Jede Log-Suche des Keepers hält einige Blöcke unter dem neuesten Block der Chain an, sodass ein Event nie hinter einem Node verpasst wird, der einen oder zwei Blöcke zurückliegt; der Keeper prüft, dass jeder RPC die Chain bedient, die seine Konfiguration nennt, und verweigert sonst den Start; sein Alert-Webhook hat ein Zeitlimit, und seine Antwort wird gelesen, wobei ein Alert, den er nicht annimmt, behalten und erneut gesendet wird; eine leere Einstellung nimmt ihren Standardwert. Der Daten-Worker der App liest jeden upgradebaren Contract für sich, sodass einer, der nach einem kaputten Upgrade fehlschlägt, die Zahlen des $STOCKFUN-Tokens nicht mehr leert; er zeigt das 24-Stunden-Volumen als unbekannt, solange seine Lesevorgänge der Trade-Logs weiter fehlschlagen, prüft, dass jeder seiner Endpoints seine Chain bedient, und der Preis-Chart setzt jeden Punkt auf seine Zeit. Weder die Lens noch das Datenschema des Workers ändern sich. Siehe Der Keeper und Die Dapp.

Seit der achten Schleife, unten, wird eine Aktie, deren eigene Preisabfrage null ist, bei ihrem Adapter nachgefragt, die Eröffnung des Zeitfensters auf der lokalen Rail einmal gezählt, das Ticket einige Blöcke unter dem neuesten gelesen, und der Keeper nimmt keine Chain-Kennung mehr an, wenn keine gesetzt ist.

2026-10-06 — Preisfeed-Schutzmechanismen auf Robinhood Chain

Der Launch-Plan führte zwei Schutzmechanismen auf, die das Oracle noch nicht hatte, beide von der Dokumentation von Robinhood empfohlen. Sie sind gebaut, nicht deployt, als Einstellungen des Owners von StockFun, die aus starten; jeder kann einen Preis nur zurückhalten, nie ändern.

• Eine Kapitalmaßnahme. Während eine Aktie eine durchläuft, sagt ihr Token, dass sein Oracle pausiert ist, und ihr Preis-Feed hält seinen letzten Wert, der noch frisch aussehen kann, während sich der Multiplikator des Tokens ändert. Das Oracle hält den Preis dieser Aktie jetzt zurück: Ihr Kauf-Leg schlägt allein fehl, ihr Cash bleibt für sie behalten, und die anderen Aktien des Baskets werden gekauft. Die Prüfung ist für jede Aktie der Robinhood-Rail an, pro Aktie, sodass ein Token, dessen Antwort nicht verwendet werden kann oder dessen Flag gesetzt bleibt, allein abgeschaltet werden kann. Ein Token, der nicht antwortet, zählt als nicht pausiert: Robinhood bezeichnet das Flag als unverbindlich, und die eigene Aktualitätsprüfung des Feeds bleibt der wichtigste Schutz.
• Der Sequencer. Robinhood Chain ist eine Arbitrum-Chain mit einem einzigen Sequencer. Mit dem L2-Sequencer-Uptime-Feed von Chainlink hält das Oracle jeden Preis zurück, solange der Sequencer ausgefallen ist, innerhalb der Karenzzeit (standardmäßig eine Stunde) wieder hochgekommen ist oder der Feed nicht gelesen werden kann. Für Robinhood Chain gibt es keinen solchen Feed, und Chainlink fügt solche Feeds neuen Netzwerken nicht mehr hinzu: Die Rail wird mit dieser Prüfung aus deployt, durch eine ausdrückliche Wahl, die das Deployment-Skript verlangt, und der Owner von StockFun setzt den Feed, falls je einer veröffentlicht wird.

Auf Ethereum bleiben beide aus. Siehe Die Robinhood-Rail.

2026-10-06 — Die achte Audit-Schleife

Die achte Schleife fand ein Problem mittlerer und acht geringer Schwere, jedes am selben Tag mit einem Test behoben, nicht deployt; die Contracts und die Preisfeed-Schutzmechanismen waren sauber. Bevor die App das Basket-Register der Chain gelesen hatte, bot ihr Launch-Formular die konfigurierten Baskets unter ihren konfigurierten Nummern an: Auf einem Deployment, das seine Baskets anders nummeriert, konnte ein Creator einen Markt unumkehrbar auf einem anderen Basket als dem angezeigten launchen. Das Formular bietet jetzt nur die von der Chain gelesenen Baskets an und liest den gewählten kurz vor dem Senden erneut von der Factory, was es verweigert, wenn der Name oder die Aktien abweichen.

Ebenfalls behoben: Der Keeper verfolgt einen Bridge-Batch erst, wenn der Block, der ihn enthält, einige Blöcke tief liegt, sodass eine Reorganisation der neuesten Blöcke von Ethereum ihn nicht mehr Kennungen beobachten lassen kann, die nie existieren; er unterscheidet den Dust, den die Bridge nicht transportieren kann, von einer Aktie, deren eigene LayerZero-Gebühr nicht abgefragt werden kann, die er jetzt mit einem Alert auslässt, statt sie stillschweigend fallen zu lassen; er behält einen wartenden Alert pro unterschiedlichem Alert, mit der Anzahl und dem Zeitpunkt seines Auslösens, sodass Alerts, die bei jedem Zyklus wiederholt werden, einen einmaligen Alert nicht mehr verdrängen; er legt eine für eine andere Chain geschriebene Zustandsdatei nicht mehr beiseite, bevor er geprüft hat, welche Chain sein RPC bedient, und verlangt beide Chain-Kennungen; er liest ein Ticket einige Blöcke unter dem neuesten, den jeder Node eines Endpoints hat; und auf der lokalen Rail zählt er die Eröffnung des Zeitfensters einmal. Der Keeper, sein Preflight und sein Inspektor kennen jetzt die Preisfeed-Schutzmechanismen: Die Käufe auf Robinhood Chain warten, solange das Oracle die Preise wegen des Sequencers zurückhält, mit einem Alert, und eine Aktie in einer Kapitalmaßnahme wartet allein, nie als Fehlschlag gezählt. Der Daten-Worker der App bewegt sein Trade-Fenster nie zurück, sodass ein Node einige Blöcke dahinter das 24-Stunden-Volumen nicht mehr Blöcke doppelt zählen lässt; sein RPC-Proxy lehnt alles ab, was keine Adresse ist; er veröffentlicht, warum der Preis einer Aktie fehlt (Datenschema 8), was die App anzeigt; und das Trade-Panel berechnet einer Wallet auf der Whitelist während des Anti-Snipe-Fensters die normale Tax, wie es der Hook tut. Die Lens ändert sich nicht, und Worker und App lassen sich weiterhin in beliebiger Reihenfolge deployen. Siehe Der Keeper und Die Dapp.

2026-10-06 — Das Gas der Airdrop-Zustellung unter Glamsterdam

Sepolia hat das Glamsterdam-Upgrade von Ethereum am 2026-10-06 aktiviert, während des LayerZero-Testnet-Laufs (unten); Hoodi und das Mainnet hatten noch kein Datum. Es bepreist das Wachstum des States neu: Ein kalt geschriebener neuer Storage-Slot kostet 110.020 Gas, gegenüber 22.100 vorher. Jede feste Gas-Zahl der Contracts und der Skripte wurde auf Sepolia erneut gemessen, und alle halten bis auf ein Paar, das Gas, das eine Airdrop-Zustellung auf Ethereum erhält: Die Sendung des Spiegel-Vaults trug eine einzige Compose-Zahl, 600.000, und das lzReceive des Aktien-OFT bekam nur, was dieses OFT erzwingt. Jeder Zustellung des ersten Zyklus des Laufs ging beim Executor von LayerZero das Gas aus, und sie wurde von Hand ausgeführt. Die zehnte Audit-Schleife fand danach zwei weitere: das eigene Gas der Deployment-Skripte und das des Bridge-Compose für einen Batch (unten).

Die Entscheidung des Gründers, am selben Tag: Der Keeper simuliert jede Zustellung und wählt ihr Gas, gehalten in Grenzen, die der Owner von StockFun auf dem Remote-Hub festlegt; eine weiterhin festhängende Zustellung wird vom Keeper erneut ausgeführt und bei einem zweiten Fehlschlag gemeldet. Im Code, nicht auf dem Mainnet deployt:

• Der Remote-Hub hält zwei Gas-Richtlinien, jede mit einem Standardwert, einer Untergrenze und einer Obergrenze: das lzReceive-Gas zusätzlich zu dem, was das OFT der Aktie erzwingt, 650.000 zwischen 200.000 und 1.500.000 (setAirdropReceiveGas), und das Compose-Gas, 1.250.000 zwischen 600.000 und 4.000.000 (setAirdropComposeGas). Das sendToAirdrop(stocks, receiveGas, composeGas) des Spiegel-Vaults sendet, was der Hub für das gewährt, was der Keeper verlangt, wobei null den Standardwert nimmt; der Aufruf nur mit den Aktien nimmt beide Standardwerte. Ein Hub, der von vor den Richtlinien upgegradet wurde, lehnt jede Sendung ab, bis beide gesetzt sind
• Der Keeper simuliert das lzReceive und das Compose jeder Aktie auf Ethereum, von der Adresse des Endpoints aus, und verlangt den Bedarf plus 25 %; wenn eine Simulation nicht laufen kann, nimmt er, was die letzten Zustellungen des Marktes verbraucht haben, dann die Standardwerte des Hubs. Eine Zustellung, die auf dem Endpoint gespeichert bleibt, sobald der Executor von LayerZero sie fehlschlagen ließ oder nach zehn Minuten, wird vom eigenen Key des Keepers erneut ausgeführt, mit ihrem simulierten Bedarf plus 25 %, standardmäßig höchstens 4.000.000 Gas; eine, die nicht gehen kann, wird mit dem Befehl gemeldet, sie von Hand auszuführen, und ein zweiter Fehlschlag wird gemeldet und nie erneut gesendet
• Die App claimt fünf Zeitfenster pro Transaktion statt zehn, lässt 400.000 Gas pro Aktie, die ein Zeitfenster noch erhalten kann, und schlug auf die Schätzung jedes Schreibvorgangs 150.000 Gas auf, was die neunte Audit-Schleife durch das eigene Limit jedes Schreibvorgangs ersetzt hat (unten)

Die Korrektur wurde per Upgrade auf den Remote-Hub und den Spiegel-Vault des Testnet-Laufs angewendet und trug dessen spätere Zyklen. Siehe Der Keeper und Die Robinhood-Rail.

2026-10-06 — Der LayerZero-Testnet-Lauf

Das Protokoll wurde auf Sepolia und auf dem Testnet von Robinhood Chain deployt, durch die Produktionsskripte oder Testnet-Wrapper, die deren Rumpf behalten, in 167 Transaktionen, alle erfolgreich, mit Test-Aktien, Test-Adaptern, einem Test-USDG und Mock-Feeds, und lief von 13:50 bis 19:07 UTC: sieben stündliche Zeitfenster, das ETH jedes einzelnen konvertiert, über LayerZero gebridgt und für die Test-Aktien ausgegeben; sechs Airdrop-Zyklen über LayerZero zurückgesendet, die ersten vier von fünf Holdern vollständig geclaimt, jede Auszahlung genau der aus dem Bestandsaufzeichner berechnete Anteil; die Incident-Übungen auf echten Nachrichten gespielt und wie dokumentiert behoben, bis auf zwei Hälften. Der Lauf beweist den Code von StockFun über die echten Endpoints, das DVN und den Executor von LayerZero. Er beweist weder das USDG-Paar von Paxos noch die Aktien von Robinhood und ihre Adapter, noch echte Feeds oder Liquidität, noch Gas, Gebühren und Finalität des Mainnets: Ein Mainnet-Versuch bleibt. Was er im Produktionscode fand, ist die Neubepreisung durch Glamsterdam (oben) und ein Teil der neunten Audit-Schleife (unten). Siehe Die Robinhood-Rail.

2026-10-06 — Die neunte Audit-Schleife und das Verifier-Gate

Die neunte Schleife prüfte die Korrekturen der achten und übernahm die Befunde des Betreibers des LayerZero-Testnet-Laufs. Sie fand zwei Probleme mittlerer Schwere, das Gas der Airdrop-Zustellung (oben) und den Daten-Worker der App, der sein RPC-Failover bei jeder Verdrängung seines Cloudflare-Objekts neu aufbaute, was ihm während eines Ausfalls des primären RPC 37 Anfragen in unter sieben Minuten schickte, wo jetzt 8 rausgehen; und Probleme geringer Schwere im Keeper, im Worker und in einem Testnet-Skript, jedes am selben Tag mit einem Test behoben. Eine Minute lang nach einer seiner eigenen Transaktionen liest der Keeper, was sie geändert hat, und schätzt das Gas dessen, was er als Nächstes sendet, am Block dieser Transaktion, sodass ein Node, der einen Block zurückliegt, den direkt nach einer Konvertierung gesendeten Bridge-Batch nicht mehr in einen falschen Fehlschlag verwandelt; jede seiner Transaktionen geht mit ihrem geschätzten Gas plus 25 % raus; die Alerts, die er nicht zustellen konnte, gehen in der Reihenfolge raus, in der sie zuletzt ausgelöst wurden; ein Ticket, das seine eigene erneute Ausführung gelöscht hat, wird nicht mehr als lebend gemeldet; eine Chain-Zeit, die kein Datum fassen kann, liest sich als „an unknown time“; er dekodiert die Fehler des Oracles; und sein Preflight läuft auf dem Deployment des Testnet-Laufs. Der Worker zeichnet die eigene Blocknummer von Robinhood Chain auf.

Seit dieser Schleife prüft ein zweiter Agent die Änderung jeder Korrektur, bevor sie gepusht wird, gegen die Fehlerklassen, die die früheren Schleifen gefunden haben, die meisten davon in den Korrekturen der jeweils vorherigen Schleife: das Verifier-Gate. Was es findet, wird wie ein Review-Befund behoben, und diese Korrektur geht erneut durch das Gate. In dieser Schleife fand es Defekte geringer Schwere in mehreren Korrekturen, darunter eine erneute Ausführung, die einem Alert glaubte, den jeder emittieren kann, und ihm jetzt nur noch glaubt, wenn er vom Executor von LayerZero kommt, und eine, die einen fehlgeschlagenen Lauf am eigenen Block dieses Laufs entschied, was eine Reorganisation des Blocks in einen falschen zweiten Fehlschlag hätte verwandeln können: Sie wartet jetzt, bis der Block einige Blöcke tief liegt. Alle sind behoben.

Die Review des Workers und der App derselben Schleife fand danach ein weiteres Problem mittlerer Schwere, die 150.000 Gas, die die App auf die Schätzung eines Schreibvorgangs aufschlug und die nicht reichten, wenn ein Trade auf mehr neuen Storage trifft als die Supply-Marke der Stunde, am selben Tag behoben: Jeder Schreibvorgang bekommt jetzt seine Schätzung plus 50.000 Gas, und ein Trade außerdem das Gas jedes Schreibvorgangs, den seine Schätzung nicht sehen kann und der noch geschehen kann, gelesen am Block der Schätzung; ein Schreibvorgang, dessen Schätzung fehlschlägt, geht mit einem festen Limit raus, und ein Launch wartet dann. Ihre zwei Befunde geringer Schwere wurden ebenfalls behoben: Ein Topf, der eine Schätzung ist, wird überall, wo er erscheint, mit „+“ markiert, und eine Freigabe, die nicht gelesen werden kann, wird nie für keine gehalten. Die Schleife ist nicht sauber, und die Zahl der sauberen Schleifen bleibt bei null. Siehe Der Keeper und Die Dapp.

2026-10-06 — Die zehnte Audit-Schleife

Die zehnte Schleife prüfte die Korrekturen der neunten und die Arbeit am Glamsterdam-Upgrade von Ethereum, jeden Bereich aus einem eigenen Blickwinkel: die Contracts unter den neuen Gaspreisen, jede Cross-Chain-Nachricht, die an ihrem Ziel fehlschlägt, den Keeper über Monate, die App mit echten Wallets und die Dokumente gegen den Code. Sie fand drei Probleme mittlerer Schwere und sechs geringer Schwere, jedes am selben Tag mit einem Test behoben, jede Korrektur vom Verifier-Gate geprüft, nicht auf dem Mainnet deployt. Die Contracts waren unter dem Gas-Blickwinkel unter beiden Preistabellen sauber.

• Das Deployment-Verfahren unter Glamsterdam. Das dokumentierte Ethereum-Deployment konnte nicht gelingen: Das Deployment-Tool gab jeder Transaktion das Gas seiner eigenen lokalen Simulation, zu den alten Preisen, während eine Vertragserstellung jetzt das Vier- bis Siebenfache davon braucht. Jedes Senden fragt jetzt den Node nach dem Gas jeder Transaktion, sobald die vorherige gemint ist; auf Sepolia durchgespielt
• Das Compose-Gas eines Bridge-Batches. Der letzte Schritt eines Bridge-Batches auf Robinhood Chain bekam eine feste Gas-Zahl, 1.200.000, was immer der Batch enthielt: Vier neue Märkte mit fünf Aktien ließen ihm das Gas ausgehen, ihr USDG lag dann ohne jeden Eintrag auf dem Remote-Hub, und jeder spätere Batch mit denselben Märkten schlug auf dieselbe Weise fehl. Jetzt ist das Gas ein Grundbetrag plus ein Anteil pro Markt, standardmäßig 200.000 und 400.000, beides Einstellungen des Owners von StockFun, und ein Batch trägt höchstens 17 Märkte, was seine Nachricht unter der Größengrenze von LayerZero und sein Gas unter der Grenze von Robinhood Chain pro Transaktion hält; der Keeper sendet höchstens so viele und lässt den Rest für seinen nächsten Durchlauf, die am längsten wartenden Märkte zuerst. Das zusätzliche Gas kostet wenig: Der Executor von LayerZero berechnet es zum Gaspreis von Robinhood Chain, 0,00001 ETH pro Million Gas auf dem Testnet. Der Alert des Keepers für einen festhängenden Transfer sagt jetzt, wo die Nachricht des Batches steht. Der Adapter des Testnets wurde am selben Tag upgegradet, und sein nächster Batch ging mit dem neuen Gas durch
• Die Notfall-Überwachung. Der Keeper nannte jeden überwachten Vault in einer einzigen Log-Anfrage, die ein Endpoint jenseits seiner Grenze ablehnt: Sobald das Register darüber hinausgewachsen wäre, wäre kein Notfall-Transfer mehr weitergeleitet worden. Er nennt sie jetzt in Gruppen, begrenzt durch eine neue Variable
• Kleinere Korrekturen. Die Fehlertexte des Keepers behalten von einer RPC-Adresse nur den Host; seine Lesevorgänge für jeden Markt laufen über Multicall3, hundert Märkte pro Aufruf, statt einzeln bei jedem Durchlauf; die App verfolgt eine Transaktion, die die Wallet abbricht oder ersetzt, zeigt einen Abbruch nie als erledigt an und liest eine Minute lang nach ihrer eigenen Transaktion an einem Block, der nicht vor dem dieser Transaktion liegt, sodass ein Verkauf direkt nach seiner Freigabe nicht mehr von einem Node abgelehnt wird, der einen Block zurückliegt; und zwei Dokumente wurden auf den Stand des Codes gebracht

Mit seinem Standard, nach der US-Handelszeit zu senden, liest der Keeper einen Vault, der nach Handelsschluss nichts zu senden hat, jetzt erst in der nächsten Handelszeit wieder. Eine Folge dieser Einsparung und keine neue Regel: Eine Aktie, die einem Vault nach Handelsschluss außerhalb eines Kaufs gegeben wird, geht mit der Sendung der nächsten Handelszeit in ein späteres Zeitfenster; was die eigenen Käufe des Vaults bringen, geht weiterhin in das an diesem Tag beendete Zeitfenster.

Das Audit wog auch eine Empfehlung ab, keinen Defekt: Claims, die in jedem der Gebühren-Akkumulatoren des Hooks ein Wei belassen, damit der nächste Trade nie dafür bezahlt, diese Storage-Slots von null an zu schreiben. Sie wird vorerst nicht übernommen. Das zusätzliche Gas fällt auf den ersten Trade nach jedem Claim, etwa 104.000 pro Slot, und die Marge der App dafür hebt das Limit eines Trades an, nicht das, was er bezahlt; die Änderung würde Claim-Code berühren, dessen formale Regeln ohne einen Prover-Lauf nicht erneut bewiesen werden könnten; und der Hook und der Burner können sie später per Upgrade übernehmen, ohne Migration. Die Schleife ist nicht sauber, und die Zahl der sauberen Schleifen bleibt bei null. Siehe Der Keeper, Die Robinhood-Rail und Die Dapp.