Die Robinhood-Rail

Die tokenisierten Aktien, die die Vaults halten, leben auf Robinhood Chain, einem L2 auf Basis von Arbitrum Orbit. Das Protokoll erreicht sie über LayerZero, mit dem USDG-OFT von Paxos als Cash-Leg.

Warum diese Rail

Die Wahl wurde am 2026-09-11 getroffen, nachdem die vorherige Rail ausgeschlossen worden war.

Auf einer Rail mit Primary Mint muss ein Vault-Contract beim Emittenten berechtigt sein, das Asset zu halten: KYB, Registrierung der Contract-Adresse und eine schriftliche Bestätigung, die der Emittent nie öffentlich dokumentiert hat. Das war der einzige wirklich unumgängliche Blocker des Projekts.

Die Sekundär-Pools von Robinhood Chain erfordern nichts davon: Diese sind für jeden offen. StockFun hat keine Beziehung zum Emittenten und braucht keine.

Der Preis für diese Freiheit ist eine Cross-Chain-Abhängigkeit: eine Bridge, zwei Hubs und ein Stablecoin, der von einem Dritten emittiert wird, der ihn einfrieren kann. Das ist ein akzeptiertes, dokumentiertes Risiko, kein vermiedenes.

Der Kreislauf

Der Rückweg des USDG, von Robinhood Chain nach Ethereum, diente nur dem Creator-Buyback; beide wurden am 2026-09-28 aus dem Code entfernt.

Was permissionless ist und was nicht

Die letzte Zeile ist die härteste Abhängigkeit der Rail, und sie ist real.

Der Spiegel-Vault

Jeder Markt hat einen Spiegel-Vault auf Robinhood Chain, per CREATE2 an einer von Ethereum aus vorhersagbaren Adresse deployt. Der Keeper kann ihn daher vom Remote-Hub vorab deployen lassen, bevor das USDC ankommt, sodass ein Transfer nie auf einer Adresse ohne Code landet. Seit dem 2026-10-05 können das nur der Keeper und der Owner von StockFun (predeploy): Bis dahin konnte das jeder, sogar für einen Markt, der noch nicht existierte, wodurch sein Spiegel-Vault an die Verdrahtung dieses Tages gebunden wurde. Der Remote-Hub erfährt, wer der Keeper ist, aus einem Bridge-Batch, der ihn trägt: Vor dem ersten Batch kennt er keinen Keeper, daher deployt der Owner von StockFun den Spiegel-Vault des ersten Marktes vorab. Seit der zweiten Audit-Schleife vom 2026-10-05 wird ein Markt, dessen Spiegel-Vault der Keeper nicht vorab deployen kann (vor dem ersten Batch oder nach einem Wechsel des Keepers, von dem der Remote-Hub noch nicht erfahren hat), mit einer Warnung aus dem Batch herausgehalten, statt mit zu wenig Gas gesendet zu werden, um seinen Vault zu deployen; die anderen Märkte gehen hinüber, und ihr Batch trägt den neuen Keeper.

Seit dem 2026-10-02 ist jeder Spiegel-Vault ein Proxy, ein MirrorVaultProxy, vor der Vault-Implementierung, die der Remote-Hub benennt, wenn der Vault deployt wird. Der Konstruktor des Proxys nimmt kein Argument, sodass sein Creation Code, und mit ihm die Adresse jedes Spiegel-Vaults, von Ethereum aus vorhersagbar bleibt, unabhängig von der Implementierung. Der Basket des Vaults kommt mit dem ersten Batch an, der seit dem 2026-10-05 auch den Aktien-Router und das Oracle des Vaults auf diejenigen umstellt, die der Remote-Hub dann benennt: Ein Vault, der deployt wurde, bevor eine Aktie gelistet war, akzeptiert einen Basket mit dieser Aktie. Der Owner von StockFun, wie ihn der Remote-Hub spiegelt, upgradet die Spiegel-Vaults einzeln, Markt für Markt, mit sofortiger Wirkung.

Swap-Routen sind nicht hartkodiert: Diese kommen in den Calldata an, codiert als abi.encode(uint8 version, bytes payload) — Version 3 für einen gepackten Uniswap-v3-Pfad, Version 4 für ein Array von v4-PathKeys. Der Vault erhält mehrere Kandidaten pro Leg und führt über den ersten Kandidaten aus, der seine Grenze einhält. Seit dem 2026-10-01 schlägt eine Route, die nur einen Teil des Betrags ausführt, fehl, und der nächste Kandidat wird versucht; vorher ließ eine Teilausführung auf einer v3-Route das nicht ausgegebene USDG im Router festhängen.

Seit der Security-Pipeline vom 2026-10-01 läuft eine v3-Route Pool für Pool. Jeder Pool muss seinen gesamten Input aufnehmen, sonst schlägt die Route fehl; sein Output kommt zum Aktien-Router zurück und ist der Input des nächsten Pools, und der letzte Pool zahlt an den Vault, unter Einhaltung des Mindestbetrags des Legs. Ein fehlschlagender Pool macht die früheren Pools desselben Versuchs rückgängig, und der nächste Kandidat wird versucht. Bis dahin sah die Prüfung nur den ersten Pool einer Route: Eine Teilausführung weiter hinten ließ den Zwischen-Token im v3-Router von Uniswap, SwapRouter02, liegen, wo jeder ihn nehmen konnte, während das Leg erfolgreich war. Ein v3-Leg mit mehreren Hops kostet jetzt einen Swap und eine Freigabe pro Pool.

Jedes Leg gibt nur das USDG aus, das für seine Aktie reserviert ist, zu den Gewichtungen des Baskets: siehe Der TreasuryVault. Seine Preisgrenze gegenüber dem Feed der Aktie, standardmäßig 200 Basispunkte, ist eine Einstellung, die der Remote-Hub hält und die jeder Spiegel-Vault live liest (setStockMaxSlippageBps). Seit dem 2026-10-05 wendet der Vault den eigenen Mindestbetrag des Keepers, nie lockerer als diese Grenze, auf das an, was tatsächlich angekommen ist.

Wenn das Oracle einen Preis zurückhält

Seit dem 2026-10-06 hat das Oracle der Spiegel-Vaults zwei Schutzmechanismen, die Robinhoods eigene Dokumentation empfiehlt; jeder kann einen Preis nur zurückhalten, nie ändern.

• Eine Kapitalmaßnahme. Während eine Aktie eine durchläuft (etwa einen Split), sagt ihr Token, dass sein Oracle pausiert ist (oraclePaused()), und ihr Chainlink-Feed hält seinen letzten Wert, der noch frisch aussehen kann, während sich der Multiplikator des Tokens ändert. Das Oracle hält dann den Preis dieser Aktie zurück: Ihr Kauf-Leg schlägt allein fehl (StockOraclePaused), ihr USDG bleibt für sie reserviert, und die anderen Aktien des Baskets werden gekauft. Die Prüfung ist für jede Aktie an; der Owner von StockFun kann sie für eine Aktie abschalten (setOraclePauseCheck), deren Preis dann auf die eigenen Prüfungen ihres Feeds zurückfällt. Ein Token, der nicht antwortet, zählt als nicht pausiert.
• Der Sequencer. Robinhood Chain ist eine Arbitrum-Chain mit einem einzigen Sequencer. Mit gesetztem L2-Sequencer-Uptime-Feed von Chainlink (setSequencerUptimeFeed) hält das Oracle jeden Preis zurück, solange der Feed sagt, dass der Sequencer ausgefallen ist, vor nicht mehr als der Karenzzeit wieder hochkam (standardmäßig eine Stunde) oder nicht gelesen werden kann: Bis dahin kauft kein Leg. Für Robinhood Chain gibt es heute keinen solchen Feed, daher wird die Rail mit dieser Prüfung aus deployt; der Owner von StockFun setzt den Feed, falls Chainlink einen veröffentlicht.

Der Keeper sieht beide, bevor er irgendetwas bepreist (siehe Der Keeper), der Worker sagt, warum der Preis einer Aktie fehlt, und die Dapp zeigt es (siehe Die Dapp).

Die Aktien an den Airdrop senden

Seit dem 2026-10-04 verlassen die Aktien den Spiegel-Vault, sobald sie gekauft sind, auf einem einzigen Weg: sendToAirdrop. Der Keeper ruft es mit der Liste der zu sendenden Aktien auf und zahlt die LayerZero-Gebühren; was er zu viel zahlt, wird ihm erstattet. Für jede Aktie sendet der Vault seinen gesamten Saldo über den Adapter dieser Aktie an den Airdrop-Contract auf Ethereum, mit der Kennung des Marktes als Payload. Der Keeper nennt weder den Betrag noch das Ziel: Der Adapter jeder Aktie (setStockAdapter, das prüft, dass der Adapter genau diesen Token trägt) und der Airdrop-Contract (setAirdrop) werden auf dem Remote-Hub von seinem Admin benannt, dem Owner von StockFun. Eine Aktie, die doppelt oder außerhalb des Baskets gelistet ist, lässt den Aufruf fehlschlagen.

Seit dem 2026-10-06 nennt der Keeper das Gas, das jede Zustellung auf Ethereum erhält: sendToAirdrop(stocks, receiveGas, composeGas), das lzReceive des Aktien-OFT zusätzlich zu dem, was dieses OFT erzwingt, und das Compose des Airdrop-Contracts. Der Remote-Hub hält jeden Wert zwischen der Unter- und der Obergrenze, die sein Admin setzt, wobei null den Standardwert nimmt (airdropGas), und der Vault baut die Sendung und ihre Preisabfrage mit dem, was der Hub gewährt; der Aufruf nur mit den Aktien nimmt beide Standardwerte. Der Keeper wählt die Werte aus Simulationen der Zustellung auf Ethereum (siehe Der Keeper): Das Glamsterdam-Upgrade von Ethereum, auf Sepolia seit dem 2026-10-06 aktiv, hat einen neuen Storage-Slot etwa fünfmal so teuer gemacht, und die einzige Compose-Zahl von früher, 600.000 Gas, ließ jeder Zustellung des ersten Zyklus des LayerZero-Testnet-Laufs das Gas ausgehen. Ein Remote-Hub, der von einer Version ohne die Richtlinien upgegradet wurde, lehnt jede Sendung und jede Preisabfrage ab (AirdropGasNotSet), bis beide gesetzt sind.

Seit dem 2026-10-05 geht jede Aktie für sich. Eine Aktie ohne Adapter, eine, deren Saldo nicht gelesen werden kann, und eine, deren Sendung fehlschlägt — ein Einfrieren durch den Emittenten, ein fehlender Peer, eine Gebühr, die die Zahlung des Keepers nicht abdeckt —, bleiben mit einem Event (AirdropSendFailed) im Vault, und die anderen gehen; geht nichts, schlägt der Aufruf fehl und nennt den Grund. Die Preisabfrage, quoteSendToAirdrop, lässt aus, was sie nicht bepreisen kann, statt fehlzuschlagen.

LayerZero transportiert sechs Dezimalstellen: Weniger als 10^12 Einheiten einer Aktie mit 18 Dezimalstellen, ein Millionstel eines Tokens, können nicht übertragen werden und bleiben für eine spätere Sendung im Vault.

Auf Ethereum mintet das OFT der Aktie die gewrappte Aktie an den Airdrop-Contract, dann ruft der Endpoint von LayerZero ihn mit der Payload auf. Der Contract schreibt die Zustellung nur gut, wenn sie von seinem Endpoint kommt, von einem Aktien-OFT, das der Owner registriert hat, von Robinhood Chain, und vom Spiegel-Vault gesendet wurde, den der Bridge-Hub für den Markt ableitet, den die Payload nennt. Diese Zustellung läuft mit dem Gas, das die Sendung mitgebracht hat (oben); eine Zustellung, der das Gas ausgeht, schlägt fehl, ohne dass etwas verloren geht, gespeichert auf dem Endpoint von LayerZero, die gewrappten Aktien bereits auf dem Airdrop-Contract, wenn nur das Compose fehlgeschlagen ist, und jeder kann sie mit mehr Gas erneut ausführen. Seit dem 2026-10-06 tut das der Keeper, von seinem eigenen Key aus, innerhalb einer Grenze, und meldet einen zweiten Fehlschlag. Details und Messungen in Deployment und Der Airdrop.

Upgrades und Verdrahtung

Seit dem 2026-10-02 ist jeder StockFun-Contract der Rail upgradebar, außer dem Deployer der Spiegel-Vaults, aus dessen Adresse die Adresse jedes Spiegel-Vaults abgeleitet wird. Auf Ethereum unterstehen der Bridge-Hub und seine Adapter dem Owner der Factory. Auf Robinhood Chain ist der Remote-Hub die Upgrade-Autorität: Er antwortet mit seinem Notfall-Admin, dem Ethereum-Owner, wie ihn der letzte Batch übermittelt hat, sodass der Remote-Hub, die Spiegel-Vaults, der Aktien-Router und das Oracle vom Owner von StockFun upgegradet werden, mit sofortiger Wirkung.

Der Remote-Hub wird zuerst auf seiner Chain deployt, mit einem initialen Admin, der danach den Aktien-Router, das Oracle und die Implementierung der künftigen Spiegel-Vaults benennt und, wenn sie angegeben sind, die Airdrop-Route und die Aktien-Adapter. Der erste Batch ersetzt diesen Admin durch den Owner von StockFun.

Derselbe Admin hält seit dem 2026-10-05 die Einstellungen des Remote-Hubs: die Einträge, die ein Sweep auszahlt, standardmäßig 64 (setMaxRecordsPerSweep, nie null), die Preisgrenze der Käufe der Spiegel-Vaults und das Gas jeder Airdrop-Zustellung (setAirdrop); und seit dem 2026-10-06 die zwei Schutzmechanismen des Oracles und die zwei Gas-Richtlinien der Airdrop-Zustellungen auf Ethereum, jede mit einem Standardwert, einer Untergrenze und einer Obergrenze (setAirdropReceiveGas, 650.000 zwischen 200.000 und 1.500.000; setAirdropComposeGas, 1.250.000 zwischen 600.000 und 4.000.000; eine Untergrenze von null, eine Untergrenze über der Obergrenze und ein Standardwert außerhalb von ihnen werden abgelehnt). Der Remote-Hub setzt beide bei der Initialisierung, und DeployRemote setzt sie erneut aus seiner Umgebung. Ein Ersatz-Oracle, das der Admin benennt (setOracle), startet mit beiden Schutzmechanismen aus, daher schaltet der Admin sie für es wieder ein; die bereits initialisierten Spiegel-Vaults behalten das Oracle, mit dem sie initialisiert wurden.

Auf Ethereum deployt der Bridge-Hub seinen Adapter nicht mehr: Der Adapter wird gegen den Hub deployt und dann einmal vom Owner von StockFun benannt (setAdapter), wobei seine Fixierungen geprüft werden. Ein späterer Austausch, changeAdapter, erfolgt seit dem 2026-10-05 sofort. Er akzeptiert nur einen Adapter, dessen Fixierungen exakt denen des aktuellen entsprechen: derselbe Hub, dieselbe Factory, dieselben Cash-Tokens, derselbe Remote-Hub, dieselbe Ziel-Chain und derselbe Transport. Er kann Gas-Werte, Optionen oder den Curve-Pool ändern, nie ein Ziel; der Remote-Hub akzeptiert weiterhin nur Batches von dem Adapter, für den er gebaut wurde (M-2, siehe Notfallmodus). Ein Adapter wird daher geändert, indem man ihn per Upgrade aktualisiert, an derselben Adresse; eine neue Adresse würde zuerst ein Upgrade des Remote-Hubs erfordern, damit dieser sie akzeptiert. Am 2026-10-05 hat der Owner entschieden, es dabei zu belassen.

Die eigenen Zahlen der Adapter sind ebenfalls Einstellungen des Owners von StockFun: auf der USDG-Rail der schlechteste akzeptierte Kurs USDG pro USDC auf Curve, standardmäßig 30 Basispunkte, und das Gas des letzten Schritts der Zustellung auf Robinhood Chain (setSettings); seit der zehnten Audit-Schleife, am 2026-10-06, ist dieses Gas ein Grundbetrag, den jeder Batch braucht, standardmäßig 200.000, plus ein Anteil für jeden Markt des Batches, standardmäßig 400.000, und ein Batch trägt höchstens 17 Märkte (setBatchGas; siehe „Das Compose-Gas eines Batches“ unten). Bis dahin bezahlte eine einzige Zahl, standardmäßig 1.200.000, jeden Batch, was immer er trug. Auf der kanonischen Rail das Gas beider Tickets (setTicketGas). Seit dem 2026-10-05 zahlt das Abrechnungsticket der kanonischen Rail, was die Inbox der Bridge für die Größe des Batches bei der aktuellen Basisgebühr verlangt, wobei die Einstellung die Untergrenze bildet. Eine offchain ausgelesene Preisabfrage, ohne Gaspreis, sah eine Basisgebühr von null und bepreiste dieses Ticket allein mit der Untergrenze, sodass ein langer Batch bei der echten Basisgebühr fehlschlug; seit der zweiten Audit-Schleife dieses Tages stellt der Keeper die Preisabfrage bei einer Basisgebühr, die er nennt (quoteBridgeAt), dem Doppelten der letzten, und erhält den Überschuss zurück. Seit der vierten Schleife wird das Einzahlungsticket auf dieselbe Weise bepreist: was die Inbox für depositCalldataLength() Bytes bei der Basisgebühr verlangt, wobei die Einstellung tokenSubmissionCost die Untergrenze bildet. Diese Länge ist ebenfalls eine Einstellung des Owners (setDepositCalldataLength, nie null): standardmäßig 1.024 Bytes, über den 740 Bytes der Einzahlung des Gateways für USDC. Bis dahin waren die Submission-Kosten der Einzahlung eine feste Einstellung, und eine Basisgebühr, die über sie hinauswuchs, ließ jeden Batch fehlschlagen.

Fehler, die eingegrenzt bleiben

Seit dem 2026-10-01, nach dem Security-Audit vom 2026-09-29:

• Ein abgelehnter Basket blockiert nur seinen eigenen Markt. Lehnt Robinhood Chain den Basket eines Marktes ab, etwa wegen einer Aktie, die der Router oder das Oracle dort nicht unterstützt, bleibt der Spiegel-Vault dieses Marktes nicht initialisiert und behält sein Cash, das der Notfallmodus zurückholen kann. Die anderen Märkte desselben Bridge-Batches gehen durch. Vorher schlug der ganze Batch fehl, und jeder konnte gesunde Märkte mit einem abgelehnten bündeln.
• Ein Remote-Token, eine Kennung. Der Bridge-Hub weigert sich, einem bereits zugeordneten Token auf Robinhood Chain eine zweite Basket-Kennung zuzuordnen.
• Ein pausierter Remote-Hub wendet die Rollen weiterhin an. Jeder Batch trägt den aktuellen Keeper und Notfall-Admin. Ein pausierter Hub wendet sie trotzdem an, sodass ein Wechsel des Owners von StockFun immer bis nach Robinhood Chain gelangt. Das Cash wird pro Markt erfasst und nach dem Ende der Pause per Sweep an die Spiegel-Vaults ausgezahlt.
• Kanonische Einträge werden der Reihe nach ausgezahlt. Auf der kanonischen Orbit-Bridge, die im Testnet und als Fallback genutzt wird, kommen Tokens und Abrechnung als zwei getrennte Tickets an. Der Hub zahlt wartende Einträge vollständig aus, in der Reihenfolge, in der ihre Nachrichten angekommen sind, wer auch immer den Sweep auslöst. Seit der Security-Pipeline vom 2026-10-01 zahlt ein Abrechnungsticket höchstens so viele Einträge aus, wie es der Warteschlange hinzugefügt hat, die ältesten zuerst, und sie können zu früheren Batches gehören; der Sweep zahlt den Rest aus, standardmäßig bis zu 64 Einträge pro Aufruf. Vorher konnte ein Rückstau, den eine Pause oder eine verspätete Einzahlung hinterlassen hatte, ein Ticket über das feste Gas seiner automatischen Ausführung hinaustreiben, und der Batch blieb unerfasst, sofern niemand das Ticket innerhalb von sieben Tagen von Hand erneut ausführte.

Ein Fehler war nur teilweise eingegrenzt. Die zweite Runde des Audits, am 2026-10-01, hat festgestellt: Lehnt der Cash-Token einen einzelnen Spiegel-Vault ab, etwa weil sein Emittent diese Adresse eingefroren hat, hält die kanonische Warteschlange an, und auf beiden Rails schlägt jeder mit diesem Markt gebündelte Batch fehl (R2H-2). Die zweite Audit-Schleife vom 2026-10-05 hat ihn entschärft, und die vierte hat ihn am selben Tag geschlossen: Eine solche Zustellung wartet jetzt für sich, und der Batch läuft weiter (unten).

Seit dem 2026-10-05, nach der Audit-Schleife dieses Tages:

• Nur der Keeper bridgt. Der Bridge-Batch, bridgeReady, ist allein dem Keeper vorbehalten. Bis dahin konnte jeder einen senden: Ein Dritter konnte einen Batch 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.
• Ein Notfall auf dem Remote-Hub wird bereinigt, nicht von einem anderen Markt bezahlt. Auf der USDG-Rail verweigert der Hub die Auszahlung dessen, was er schuldet, solange das Cash, das dies deckt, nicht ausreicht, eine Zählung, die er seit der zweiten Audit-Schleife dieses Tages selbst führt, nie sein Saldo, der auch das Cash von Batches umfasst, die noch unterwegs sind; Cash kommt über restore zurück. Auf der kanonischen Rail pausiert der Owner von StockFun den Hub vor dem Transfer, streicht den Eintrag, dessen Cash der Notfall genommen hat, und hebt dann die Pause auf. Siehe Notfallmodus.

Seit der vierten Audit-Schleife vom 2026-10-05, die die Regel des Gründers anwendet, dass ein Fehler nie den Rest blockiert (siehe Architektur):

• Eine abgelehnte Zustellung wartet für sich. Auf der USDG-Rail bleibt der Anteil eines Spiegel-Vaults, den der Cash-Token ablehnt, auf dem Remote-Hub, diesem Markt geschuldet und gedeckt (DeliveryRefused), und die anderen Märkte des Batches werden ausgezahlt. Auf der kanonischen Rail verlässt ein solcher Eintrag die Warteschlange und wird für seinen Markt gesondert gehalten (undeliverable), sodass die Einträge dahinter und die nächsten Tickets ausgezahlt werden. Auf beiden zahlt ihn jeder mit sweep(marketId) aus, sobald der Vault das Cash wieder annimmt. Seit dem 2026-10-06 schließt der Keeper auf der kanonischen Rail außerdem die Transfers ab, deren abgelehnte Einträge ein einziger Sweep auf einmal ausgezahlt hat oder die der Owner von StockFun dem Markt angelastet hat, sodass keiner dauerhaft verfolgt bleibt.
• Jeder Markt eines Batches geht für sich. bridgeReady lässt einen gelisteten Markt aus, dessen Vault sein Cash nicht freigeben kann — pausiert, leer, vom Emittenten abgelehnt oder, seit der fünften Schleife, ein Vault noch ohne Code, wie der des Protokoll-Marktes, bevor er benannt ist —, einen unbekannten Markt oder einen, dessen Payload der Adapter nicht bauen kann (MarketSkipped), und die anderen gehen. Der Mindestbetrag des Keepers deckt den Batch wie gelistet ab und wird im Verhältnis zu dem herunterskaliert, was tatsächlich abging; Bridged listet nur die Märkte, die abgingen. Ein Batch, aus dem nichts abgeht, schlägt fehl, mit dem Grund des ersten Marktes.
• Jedes Kauf-Leg geht für sich, auf dem Spiegel-Vault wie auf dem Vault auf Ethereum (LegFailed): siehe Der TreasuryVault.
• Ein Notfall-Transfer kann einem einzelnen Markt angelastet werden. Der Owner von StockFun bewegt das Cash eines Marktes und bereinigt dessen Bücher im selben Aufruf, sodass kein anderer Markt wartet: emergencyTransferFromPending nimmt, was der Hub diesem Markt auf der USDG-Rail schuldet, oder seinen abgelehnten Anteil auf der kanonischen Rail, und emergencyTransferRecord einen kanonischen Eintrag in der Warteschlange, ganz. Seit der fünften Schleife ist Letzterer 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 abgeschrieben (writeOffRecord). Auf der USDG-Rail behält ein Transfer, der keinem Markt angelastet ist, bewusst seine allgemeine Wartezeit: Die Bücher zeigen eine Unterdeckung, bis das Cash zurückgebracht oder abgeschrieben ist.
• Ein zurückgehaltener Preis hält nur seine eigenen Legs zurück (seit dem 2026-10-06): Eine Aktie in einer Kapitalmaßnahme lässt nur ihr eigenes Leg fehlschlagen, in jedem Spiegel-Vault; mit gesetzter Sequencer-Prüfung hält ein Sequencer-Ausfall jedes Leg zurück, bis er seit der Karenzzeit wieder läuft, und das Cash wartet in den Vaults (oben, „Wenn das Oracle einen Preis zurückhält“).

Das Compose-Gas eines Batches

Seit der zehnten Audit-Schleife, am 2026-10-06. Der letzte Schritt eines Bridge-Batches auf Robinhood Chain, das Compose des Remote-Hubs, initialisiert und finanziert den Spiegel-Vault jedes Marktes, sodass sein Gas mit dem Batch wächst. Früher bekam er eine einzige feste Zahl, standardmäßig 1.200.000, was immer der Batch enthielt: Vier neue Märkte auf Baskets mit fünf Aktien ließen ihm das Gas ausgehen. Ihr USDG lag dann ohne jeden Eintrag auf dem Remote-Hub, jeder spätere Batch mit denselben Märkten schlug auf dieselbe Weise fehl, und erst ein Lauf von Hand am Endpoint von Robinhood Chain bewegte es. Nichts ging verloren, aber kein Markt des Batches wurde in der Zwischenzeit gekauft oder per Airdrop verteilt.

• Ein Grundbetrag und ein Anteil pro Markt. Der USDG-Adapter gibt einem Batch mit n Märkten composeGas + n × composeGasPerMarket Compose-Gas, standardmäßig 200.000 plus 400.000 pro Markt, für die Sendung wie für jede Preisabfrage. Der erste Batch eines Marktes mit fünf Aktien braucht etwa 294.000 Gas (hochgerechnet aus den gemessenen ein bis drei Aktien) und ein bereits eingerichteter Markt 21.000 bis 39.000, auf einem Fork des Testnets von Robinhood Chain über den eigenen Endpoint von LayerZero
• Höchstens 17 Märkte pro Batch. LayerZero lehnt eine Nachricht über der Größengrenze des Pfads ab, standardmäßig 10.000 Bytes, und jeder Markt mit fünf Aktien fügt der des Batches höchstens 544 Bytes hinzu: 17 Märkte passen, 18 nicht. Ein größerer Batch wird als Ganzes abgelehnt, bevor sich etwas bewegt, und jeder Vault behält sein USDC. Der Keeper sendet höchstens so viele, die am längsten wartenden Märkte zuerst, und die anderen gehen bei seinem nächsten Durchlauf, sodass keiner auf Dauer wartet. Die kanonische Rail hat keine solche Obergrenze
• Innerhalb der Grenzen von Robinhood Chain. Das Compose-Gas des größten Batches beträgt höchstens 24.000.000, unter den 32.000.000 Gas, die Robinhood Chain in einer Transaktion ausführt; die Einstellungen des Owners können darüber nicht hinausgehen. Vor dem Mainnet liest der Owner die Größengrenze des Pfads, den das USDG von Paxos nimmt, und setzt die Obergrenze passend, falls sie abweicht
• Es kostet wenig. Der Executor von LayerZero berechnet das zusätzliche Gas zum Gaspreis von Robinhood Chain: Auf dem Testnet wächst die Gebühr eines Batches um 0,00001 ETH pro Million Gas
• Ein Adapter von vorher lehnt jeden Batch ab, bis der Owner die zwei neuen Einstellungen setzt, was sein Upgrade in derselben Transaktion tut. Der Adapter des Testnets wurde am 2026-10-06 auf diese Weise upgegradet, und das Compose seines nächsten Batches führte der Executor von LayerZero mit seiner neuen Option aus, 600.000 Gas für einen Markt, davon 115.990 verbraucht
• Ein festhängendes Compose sagt es. Der Alert des Keepers für einen nicht rechtzeitig gutgeschriebenen Transfer liest jetzt die Nachricht des Batches am Endpoint von Robinhood Chain: dort noch nicht zugestellt; Compose ausgeführt, die Gutschrift folgt; oder gespeichert, ihr USDG auf dem Remote-Hub, wartend darauf, von Hand mit mehr Gas erneut ausgeführt zu werden, was jeder tun kann, wobei der Alert den Hash der gespeicherten Nachricht nennt. Der Keeper führt ein Bridge-Compose weiterhin nicht selbst aus

Was verifiziert wurde, und was nicht

Zuerst der aktuelle Stand. Es hat kein Mainnet-Deployment und keinen Transfer echter Gelder gegeben. Lokale Tests simulieren die Zustellung; sie beweisen keine echte LayerZero-Zustellung. Die Sendungen des Airdrops, programmiert am 2026-10-04, werden gegen Mocks von LayerZero und der Aktien-Adapter getestet.

Der LayerZero-Testnet-Lauf, 2026-10-06. Das Protokoll wurde auf Sepolia und auf dem Testnet von Robinhood Chain deployt (167 Deployment-Transaktionen, alle erfolgreich) und lief durchgängig über die echten Testnet-Endpoints, das DVN und den Executor von LayerZero, von 13:50 bis 19:07 UTC, durch den Keeper, in sieben stündlichen Zeitfenstern: Das ETH jedes Zeitfensters wurde einmal konvertiert, in einem LayerZero-Batch gebridgt, auf dem Remote-Hub per Compose in den Spiegel-Vault gebracht und für die drei Test-Aktien ausgegeben. Sechs Airdrop-Zyklen wurden eröffnet, über LayerZero zurückgesendet und per Compose auf dem Airdrop-Contract verbucht; die ersten vier wurden von den fünf Holdern vollständig geclaimt, der fünfte teilweise, der sechste blieb zum Claimen offen, jede Auszahlung genau der unabhängig aus dem Bestandsaufzeichner berechnete Anteil. Die Incident-Übungen (Pausen, Notfall-Transfers und restore, rescue, ein Keeper, der mit einer ausstehenden Transaktion beendet wurde, ein von Hand ausgeführtes Compose, ein veralteter Feed, eine pausierte Aktie, der Sequencer-Schutzmechanismus, eine Zustellung, die der Cash-Token ablehnt) wurden auf echten Nachrichten gespielt und wie dokumentiert behoben, bis auf zwei Hälften: die Pause des Bridge-Hubs auf Sepolia und ein von Hand ausgeführtes Bridge-Compose. Sepolia hat während des Laufs das Glamsterdam-Upgrade von Ethereum aktiviert: Den ersten Airdrop-Zustellungen ging beim Executor von LayerZero das Gas aus, sie wurden von Hand ausgeführt, und die Korrektur des Zustellungs-Gases (oben) wurde per Upgrade angewendet und trug die folgenden Zyklen. Der Keeper wurde um 18:25 mit dem Code der neunten Audit-Schleife neu gestartet und lief das letzte Zeitfenster sauber, mit dem Gas, das er aus seinen Simulationen wählte.

Was dieser Lauf nicht beweist: Paxos' USDG, dessen Testnet-Token auf diesen Testnets keine OFT-Funktion hat, sodass ein Test-USDG unter LayerZeros MintBurnOFTAdapter, geformt wie das Mainnet-Paar, an seine Stelle trat, und weder die DVNs des Paares noch sein Einfrieren noch seine Pause wurden ausgeübt; die Aktien von Robinhood und ihre Adapter, für die Test-Aktien unter LayerZeros OFTAdapter einsprangen; echte Preis-Feeds und echte Liquidität; Gas, Gebühren und Finalität des Mainnets. Ein Mainnet-Versuch bleibt, ein erster kleiner Zyklus auf einem Verifikations-Vault.

Die älteren Sepolia-Skripte nutzen die kanonische Orbit-Bridge und validieren LayerZero nicht. Ein Erfolg auf einem Fork, oder im Testnet, ist kein Beleg für eine Live-Zustellung auf dem Mainnet.