Notfallmodus

Seit dem 2026-08-29 kann der Owner von StockFun die Assets einer Treasury, oder jedes Contracts, der Gelder des Protokolls hält, an eine beliebige Adresse bewegen. Seit dem 2026-10-05 erfolgt der Transfer sofort: ohne vorherige Ankündigung, ohne Wartefrist, und keine Einstellung kann eine hinzufügen. Es ist die folgenreichste Änderung des Projekts, und sie hat verändert, was das Produkt sagen darf.

Was er erlaubt

emergencyTransfer(asset, amount, to), aufgerufen auf dem Contract, der das Asset hält, bewegt diesen Betrag eines beliebigen Assets — ETH, USDC, USDG, tokenisierte Aktien, Markt-Tokens — sofort an to. Fünf Contracts verfügen darüber: der TreasuryVault, der BridgeHub und, seit dem 2026-10-04, der Airdrop-Contract, AirdropDistributor, auf Ethereum; der RemoteHub und die Spiegel-Vaults auf Robinhood Chain. Nur ihr Notfall-Admin kann die Funktion aufrufen: der Owner der Factory auf Ethereum und, auf Robinhood Chain, dieselbe Adresse, wie sie der letzte Bridge-Batch übermittelt hat. Der Owner kann sie auf jedem dieser Contracts einsetzen, jederzeit.

Jeder Transfer erhält eine fortlaufende ID und emittiert ein öffentliches Event, EmergencyExecuted, mit dem Asset, dem Betrag und dem Empfänger. Nichts kündigt ihn vorher an.

Bis zum 2026-10-05 plante der Owner die Bewegung: Ein öffentliches Event kündigte sie an, der Owner konnte sie 48 Stunden lang abbrechen, und danach konnte jeder sie ausführen. Diese Planung gibt es nicht mehr, und die Wartefrist ist kein Parameter: Ein Notfall wirkt, sobald der Owner ihn auslöst, nie nach einer Wartezeit. Mit ihr entfällt die Ausnahme, die für Airdrop-Gelder geplant war, die in einem Spiegel-Vault festhängen, und die nie programmiert wurde: Der sofortige Transfer deckt diese Gelder bereits ab.

Daneben: eine Pause für Konvertierungen und Bridging — sofort, ohne Gelder zu bewegen — und der Austausch des Bridge-Adapters für künftige Sendungen, changeAdapter, seit dem 2026-10-05 ebenfalls sofort. Auf dem Airdrop-Contract stoppt die Pause die Sendungen, das Eröffnen von Zyklen (openCycle) und das Zuweisen beiseitegelegter Aktien (assignUnassigned); sie bewegt nichts und stoppt nie einen Claim.

Seit dem 2026-10-01 wendet ein pausierter Remote-Hub die Änderungen von Keeper und Notfall-Admin, die jeder Batch trägt, weiterhin an, sodass ein Wechsel des Owners immer bis nach Robinhood Chain gelangt; das Cash, das er in der Zwischenzeit erhält, wartet dort, pro Markt erfasst, bis zu einem Sweep nach dem Ende der Pause.

Das Security-Audit vom 2026-09-29 hat festgestellt, dass der Austausch des Adapters nicht durchgängig funktionieren kann: Der Remote-Hub akzeptiert nur Batches vom ursprünglichen Adapter, sodass jeder nach einem Austausch gesendete Batch auf dem Remote-Hub warten würde, bis der Notfallmodus ihn zurückholt (M-2). Am 2026-10-05 hat der Owner entschieden, es so zu belassen: Ein Adapter wird per Upgrade an derselben Adresse gewechselt, und eine neue Adresse bräuchte zuerst ein Upgrade des Remote-Hubs, um sie zu akzeptieren.

Bei einem Vault setzt seit der Security-Pipeline vom 2026-10-01 ein Notfall-Transfer, der das Cash unter die Reservierungen der Aktien senkt, diese alle auf null: Was übrig bleibt, und jeder spätere Eingang, wird neu zu den Gewichtungen des Baskets aufgeteilt. Eine Notfall-Recovery, die nur nicht reserviertes Cash oder ein anderes Asset nimmt, lässt sie bestehen. Cash, das herausgenommen und an einen Vault zurückgeschickt wird, wird wie jeder Eingang aufgeteilt und nicht der Aktie zurückgegeben, für die es reserviert war.

Die zweite Runde des Audits, am 2026-10-01, hat festgestellt, dass auf dem Remote-Hub eine Notfall-Recovery, die bereits für einen Markt erfasstes Cash nimmt, den Eintrag bestehen lässt, der dann aus dem Cash anderer Märkte ausgezahlt wird (R2H-1). Seit dem 2026-10-05 folgt auf einen Transfer eine Bereinigung, siehe unten, und dieser Fall ist durch ihre Werkzeuge plus ein Verfahren abgedeckt: Auf der kanonischen Rail pausiert der Owner von StockFun den Remote-Hub vor dem Transfer. Seit der vierten Audit-Schleife dieses Tages kann ein Transfer auch einem einzelnen Markt angelastet werden, wodurch dessen Bücher im selben Aufruf bereinigt werden.

Nach einem Transfer: die Bücher bereinigen

Seit dem 2026-10-05, nach den Audit-Schleifen dieses Tages. Der Transfer selbst ist unverändert: sofort, ohne Bedingung. Aber zwei Contracts halten Assets, die decken, was mehreren Märkten geschuldet wird: der Airdrop-Contract und der Remote-Hub. Nach einem Transfer aus einem der beiden werden die Bücher bereinigt, nie aus einem anderen Markt bezahlt. Entweder kommen die Assets zurück, oder der Owner von StockFun schreibt den Verlust zulasten des Marktes ab, der ihn erlitten hat.

Beide Contracts zählen, was ihre Bücher deckt, nie ihren Saldo. Der Saldo umfasst auch Tokens, die angekommen, aber noch nicht gutgeschrieben sind: eine Zustellung von Aktien, deren letzter Schritt auf Ethereum noch nicht gelaufen ist, oder, auf der USDG-Rail, das Cash eines Batches, dessen letzter Schritt auf Robinhood Chain noch nicht gelaufen ist. Diese Tokens decken noch nichts und gehören möglicherweise einem anderen Markt. Bis zur zweiten Schleife vom 2026-10-05 lasen die Contracts den Saldo, sodass solche Tokens die Claims eines geleerten Zyklus wieder öffnen und sie mit den Aktien eines anderen Marktes bezahlen konnten.

  • Ein Notfall-Transfer nimmt zuerst von dem, was die Bücher deckt. Die Tokens lassen sich nicht auseinanderhalten, und die gutgeschriebenen zuerst als verschwunden zu zählen, lässt nie einen Markt für einen anderen zahlen. Was er darüber hinaus nimmt, stammt aus noch nicht gutgeschriebenen Tokens: Der Contract erfasst es (taken, cashTaken), und die nächsten Zustellungen dieses Assets tilgen es, bevor sie irgendetwas decken.
  • Assets kommen über restore zurück. Jeder kann es aufrufen; es zieht die Tokens vom Aufrufer ein. Ein einfacher Transfer an den Contract deckt nichts. Seit der dritten Audit-Schleife vom 2026-10-05 zahlt restore zuerst zurück, was ein Transfer über das hinaus genommen hat, was die Bücher deckt (taken, cashTaken), und deckt die Bücher mit dem Rest: Die Tokens einer noch wartenden Zustellung zahlen nie einen geleerten Markt aus.

  • Verirrte Tokens. Tokens, die den Airdrop-Contract oder den Remote-Hub auf der USDG-Rail erreicht haben, ohne je gutgeschrieben worden zu sein, versehentlich dorthin gesendet, gehen ebenfalls zulasten dessen, was die Bücher deckt, wenn ein Notfall-Transfer sie herausnimmt. Ein Notfall-Transfer nimmt sie nur heraus, um sie zurückzubringen; andernfalls muss ihr Betrag zulasten des Zyklus oder des Marktes abgeschrieben werden, bei dem er landet, oder durch ein Upgrade beseitigt werden.

  • Der Airdrop-Contract hält Aktie für Aktie fest, was er schuldet und was dies deckt, und zahlt eine Aktie nur aus, solange diese Deckung für das ausreicht, was er schuldet. Nach einem Transfer, der einen Teil einer Aktie genommen hat, warten die Claims dieser Aktie, in jedem Markt, der sie hält, bis die Aktie über restore zurückkommt oder bis der Owner den Verlust zulasten des Zyklus abschreibt, der sie verloren hat (writeDownCycle), oder zulasten der Aktien, die ein Markt beiseitegelegt hat (writeDownUnassigned). Solange niemand diese Aktie aus dem Zyklus geclaimt hat, kann der Owner einen beliebigen Teil davon abschreiben, und jeder Holder des Zyklus verliert denselben Anteil; sobald einige Holder ausgezahlt worden sind, kann der Owner nur noch den gesamten Rest abschreiben, den die noch nicht ausgezahlten Holder verlieren, oder die Aktie zurückbringen. Alles, was diesen Zyklus danach erreicht, wird pro rata zwischen allen seinen Holdern aufgeteilt, als wäre der abgeschriebene Betrag nie da gewesen. Kein anderer Zyklus zahlt dafür. Seit der vierten Audit-Schleife stellt ein Claim nur die wartende Aktie zurück (ClaimDeferred) und zahlt die anderen im selben Aufruf aus; bis dahin schlug er als Ganzes fehl. Der Airdrop-Contract hat keinen einem einzelnen Zyklus angelasteten Transfer: Seine Größengrenze ließ keinen Platz dafür. Das Verfahren, das seine Bücher nie in eine Unterdeckung geraten lässt, schreibt zuerst den Zyklus oder die beiseitegelegten Aktien ab und bewegt dann die Aktie; ein zuerst ausgeführter Transfer behält die allgemeine Wartezeit oben.

  • Der Remote-Hub, auf der USDG-Rail, zählt das Cash, das deckt, was er schuldet, und verweigert die Auszahlung (sweep), solange dieses nicht ausreicht. Nach einem Transfer, der mehr als das genommen hat, werden die nächsten Batches erfasst statt zugestellt, bis sie das ausgeglichen haben. Der Owner bringt das Cash zurück (restore) oder schreibt einen Betrag ab, der verloren ist oder den der Transfer von Hand an den Spiegel-Vault des Marktes zugestellt hat (writeOffPending). Seit der vierten Audit-Schleife kann der Owner einen Transfer auch einem einzelnen Markt anlasten: emergencyTransferFromPending(marketId, amount, to) bewegt, was der Hub diesem Markt schuldet, und schreibt es im selben Aufruf ab, sodass die Bücher nie in eine Unterdeckung geraten und kein anderer Markt wartet.
  • Der Remote-Hub, auf der kanonischen Rail, schuldet die Einträge seiner Warteschlange und führt keine solche Zählung: Der Schutz ist ein Verfahren. Der Owner pausiert den Hub vor dem Transfer, bewegt das Cash, streicht den Eintrag, dessen Cash es war (writeOffRecord), und hebt dann die Pause auf, sodass die Warteschlange diesen Eintrag nie ein zweites Mal mit dem Cash eines anderen Marktes auszahlt. Seit der vierten Audit-Schleife erledigt das ein einziger Aufruf für einen Eintrag: emergencyTransferRecord(index, to) bewegt den ganzen Betrag des Eintrags und streicht ihn. Seit der fünften ist dieser Aufruf für einen Eintrag gedacht, dessen Einzahlung angekommen ist: Das Cash der Warteschlange ist gemeinsam, daher lehnt er einen Betrag ab, der über das Cash hinausgeht, das nicht für abgelehnte Anteile zurückgehalten wird (RecordNotCovered); ein Eintrag, dessen Einzahlung verloren ist, wird mit writeOffRecord gestrichen. Ein Anteil, den ein Spiegel-Vault abgelehnt hat und der für seinen Markt gesondert gehalten wird (undeliverable), wird mit emergencyTransferFromPending bewegt und abgeschrieben.

Jede Abschreibung emittiert ein öffentliches Event (WrittenDown, PendingWrittenOff), ebenso jede Rückführung (Restored) und jeder zurückgestellte Claim (ClaimDeferred).

Rescues: was ein Modul versehentlich hält

Seit dem 2026-10-05 haben die Contracts ohne Notfallmodus, nach der Regel des Gründers, dass alles, was Gelder halten kann, einen Hebel hat (siehe Architektur), ein eigenes Rescue für das, was versehentlich an sie gesendet oder von einer fehlgeschlagenen Operation zurückgelassen wurde. Nur der Owner von StockFun ruft es auf: der Owner der Factory auf Ethereum, der Admin des Remote-Hubs auf Robinhood Chain, dieselbe Adresse, die die Module upgradet. Jedes Rescue emittiert ein öffentliches Event.

  • Die Module, die zwischen Transaktionen nichts von irgendwem behalten — die Factory, die Lens, die Oracles, der Bestandsaufzeichner, die Aktien-Router, der offizielle Swap-Router und die Bridge-Adapter —, haben rescue(asset, amount, to), für ETH (die Nulladresse) oder jeden Token
  • Der Hook holt nur verirrte Beträge heraus: höchstens das ETH, das ihm jemand anderes als der PoolManager gesendet hat (strayEth), und jeden Token, da er nie einen hält. Die Guthaben der Creator, des Teams und des Buybacks und die Schulden gegenüber den Vaults fließen nie auf diesem Weg ab. Ohne Aufruf hineingezwungenes ETH wird nicht gezählt und wartet auf ein Upgrade
  • Der Liquiditäts-Lock, der nicht upgradebar ist, holt jeden Token heraus und ETH über den Anteilen, die er für Vaults und Creator behält (totalOwed), die nie auf diesem Weg abfließen; seit der fünften Audit-Schleife auch v4-Claims, die ihm im PoolManager gutgeschrieben sind (rescueClaims), und ein NFT, das ihm per einfachem Transfer gesendet wurde (rescueNft). Er hat keinen generischen Aufruf: Über den PoolManager könnte man die Recovery des Endmodus ohne ihre 30 Tage erreichen. Seine Positionen bleiben nur über den Endmodus erreichbar
  • Der BuybackBurner holt einen Token jederzeit heraus und sein ETH erst, wenn kein Burn es mehr ausgeben könnte: bevor der Protokoll-Markt benannt ist oder sobald der Endmodus den $STOCKFUN-Pool zurückgeholt hat. Solange dieser Pool gesperrt ist, verlässt sein ETH ihn nur über Burns
  • Die Tokens, die nicht upgradebar sind, holen heraus, was an ihre eigene Adresse gesendet wurde: ihre eigenen Tokens, die wie jeder Transfer dem Bestandsaufzeichner gemeldet werden, jeden anderen Token, hineingezwungenes ETH und, seit der fünften Audit-Schleife, v4-Claims und NFTs (rescue, rescueClaims, rescueNft). Kein Saldo eines Holders kann sich auf diesem Weg bewegen
  • Die Implementierungs-Contracts hinter den Proxys werden nie direkt verwendet. Auf denen der Factory und des Remote-Hubs, die ihren Admin im Storage des Proxys halten, ist der Hebel für das, was an ihre eigene Adresse gesendet wird, die Adresse, die sie deployt hat; jede andere Implementierung liest ihren Admin über ihre Autorität, den Protokoll-Owner

Die Vaults, die beiden Hubs und der Airdrop-Contract behalten stattdessen den Notfallmodus, da sie eigene Bücher führen. Die beiden Deployer auf Ethereum und der Deployer der Spiegel-Vaults halten keinen Zustand, nehmen kein ETH an und haben keinen Owner: Sie brauchen keinen Hebel.

Was er nicht erlaubt

Der Notfallmodus berührt das Feed-Register nicht. Er bewegt Assets; er ändert keine Ausführungsgrenzen, die gesonderte Einstellungen des Owners sind. Er kann einen Vault nicht dazu bringen, irgendetwas zu irgendeinem Preis zu kaufen; er kann sofort nehmen, was in einem Vault liegt.

Ebenso wenig kann er die gesperrte Liquidität oder die Tokens der Holder anfassen. Dasselbe gilt für den Airdrop: Der Notfallmodus kann die Aktien des Airdrop-Contracts bewegen, aber er kann nicht ändern, wie ein Zyklus zwischen seinen Holdern aufgeteilt wird. Die Anteile bleiben, wie sie sind; seit dem 2026-10-05 wird ein Claim nur ausgezahlt, solange das, was die Bücher des Contracts deckt, für alles ausreicht, was er in dieser Aktie schuldet, und ein Verlust, der nicht mehr zurückkommt, geht zulasten des Zyklus, der ihn erlitten hat, nie zulasten eines anderen (siehe oben).

Er ist allerdings nicht der einzige Weg des Owners zu einem Vault. Seit dem 2026-10-02 kann der Owner von StockFun außerdem einen Vault upgraden, oder das Oracle, das dieser liest, mit sofortiger Wirkung. Die gesperrte Liquidität hat ihren eigenen Ausgang, den Endmodus, der 30 Tage im Voraus angekündigt wird: die einzige feste Wartefrist des Protokolls. Siehe Vertrauensmodell.

Warum es ihn gibt

Das Review der Cross-Chain-Fehlermodi stellte eine einfache Frage: Was passiert, wenn eine Route fehlschlägt, eine Bridge-Nachricht verloren geht oder ein Contract einen Bug hat?

Ohne Recovery-Pfad lautet die Antwort „die Gelder sind verloren, dauerhaft“. Das Protokoll hat einen kontrollierten Recovery-Pfad, den sein Owner hält und der onchain aufgezeichnet wird, der Eleganz eines Systems vorgezogen, das nichts reparieren kann. Seit dem 2026-10-05 wirkt dieser Pfad, sobald er genutzt wird.

Seit dem 2026-10-01 ist er außerdem der Weg, auf dem das Cash eines Marktes, dessen Basket Robinhood Chain abgelehnt hat, den Spiegel-Vault dieses Marktes verlässt, der nicht initialisiert bleibt: siehe Die Robinhood-Rail.

Was er kostet

Der Owner kann die Assets einer Treasury an eine beliebige Adresse bewegen, sofort und ohne vorherige Ankündigung. Das steht im Vertrauensmodell des Projekts.

Vor allem ersetzt die validierte Formulierung jedes frühere Versprechen.

Die Assets werden vom Vault des Marktes gehalten und unterliegen seinen Regeln. Das StockFun-Team kann die Assets einer Treasury in einem Notfall bewegen, nach einer öffentlichen Wartefrist von 48 Stunden.

Seit dem 2026-10-05 gibt es die Wartefrist in diesem Satz nicht mehr: Der Transfer erfolgt sofort. Der Satz ist zu überarbeiten und seine neue Formulierung zu validieren. Seit dem 2026-10-02 deckt er auch die Upgrades der Vaults nicht ab, die sofort wirken.

Das Produkt kann nicht mehr non-custodial, trustless, unveränderliche Treasury oder niemand kann die Treasury anfassen sagen. Diese Begriffe sind durch die Branding-Regeln verbannt; das automatische Copy-Audit prüft sie nicht, das Review schon.

Der Notfallmodus wird nie als Schutz oder als Garantie gegen Verluste beschrieben. Er ist eine Befugnis des Teams, die sofort wirkt. Nicht mehr.

Was der Nutzer sieht

Bis zum 2026-10-05 sollte ein Banner auf jeder betroffenen Oberfläche eine geplante Recovery ankündigen, mit ihrem Ausführungsdatum. Ein Transfer erfolgt jetzt sofort, sodass es vorab nichts anzukündigen gibt: Er wird erst im Nachhinein sichtbar, im Event EmergencyExecuted des Contracts, aus dem er erfolgt ist.