Deployment

Das Protokoll wird über zwei Chains deployt, in einer Reihenfolge, die nicht verhandelbar ist.

Die Wallets

Drei getrennte Rollen, nie derselbe Key.

Die Skripte nehmen ihren Signer von der Kommandozeile von forge oder aus einem DEPLOYER_PRIVATE_KEY im Klartext in der Umgebung. DeployEthereumRail, DeployProtocol, DeployRemote und DeployBridge akzeptieren beides; LaunchProtocol, RegisterBaskets und CreateMarket lesen nur DEPLOYER_PRIVATE_KEY.

Jedes Senden (Broadcast) läuft seit der zehnten Audit-Schleife mit --slow --skip-simulation. Ohne diese Flags gibt forge jeder Transaktion das Gas, das seine eigene Simulation gezählt hat, zu den Preisen vor Ethereums Glamsterdam-Upgrade, und eine Vertragserstellung braucht danach vier- bis siebenmal so viel: Jede Erstellung liefe ohne Gas aus. Mit ihnen nimmt forge für jede Transaktion die Schätzung des Knotens, sobald die vorherige gemined ist. Die Gaszahlen eines Dry Runs sind daher auch kein Budget: Unter Glamsterdam braucht DeployProtocol etwa 240 Millionen Gas und der Launch jedes Marktes 15 bis 24 Millionen.

Die Reihenfolge

Drei Bedingungen legen sie fest. Jedes Ethereum-Modul erhält bei seiner Konstruktion die Adresse der Factory, also kommt die Factory zuerst, und ihr Owner verdrahtet danach den Rest mit ihr. Der Router und das Oracle der Ethereum-Rail sind, wie der Bridge-Hub, an die Factory gebunden, also kommen sie nach dem Protokoll. Die beiden Hubs fixieren einander über ihre vorhergesagte Adresse.

1. DeployProtocol: zuerst die Factory, dann der Hook, durch Mining für alle 14 v4-Berechtigungen ermittelt, der Lock, der Bestandsaufzeichner, die Deployer, die Vault-Implementierung, die Lens, der Swap-Router und der Airdrop-Contract, AirdropDistributor, alle mit der Factory verdrahtet. Die Ownership geht dann an den Protokoll-Owner, der sie annehmen muss
2. DeployEthereumRail, mit der Adresse der Factory: das Oracle und der Router ETH → USDC auf Ethereum, die der Owner in der Factory setzt
3. DeployBridge --sig "predict()": gibt die Adressen aus, die der Bridge-Hub und sein Adapter erhalten werden
4. DeployRemote auf Robinhood Chain: zuerst der Remote-Hub, fixiert auf diese vorhergesagten Adressen, dann der Aktien-Router, das Oracle und die Implementierung der Spiegel-Vaults, die der Admin des Hubs mit ihm verdrahtet, mit der Airdrop-Route und den Aktien-Adaptern, wenn sie angegeben sind (unten). Seit dem 2026-10-06 setzt es bei jedem Lauf die zwei Gas-Richtlinien des Remote-Hubs für die Airdrop-Zustellungen auf Ethereum, vor der Airdrop-Route (unten), und die zwei Schutzmechanismen des Oracles, und verweigert den Start ohne eine Entscheidung über die Sequencer-Prüfung: SEQUENCER_UPTIME_FEED, der L2-Sequencer-Uptime-Feed von Chainlink auf Robinhood Chain, oder SEQUENCER_CHECK_OFF=true, die Prüfung bewusst aus, nie beides, mit SEQUENCER_GRACE_PERIOD (standardmäßig 3.600 Sekunden) nur neben einem Feed. Chainlink veröffentlicht keinen solchen Feed für Robinhood Chain, daher setzt ein Mainnet-Lauf heute SEQUENCER_CHECK_OFF=true, und der Owner von StockFun setzt den Feed später (setSequencerUptimeFeed), falls einer veröffentlicht wird. Das Skript schaltet dann die Oracle-Pause jeder Aktie ein (setOraclePauseCheck), nach dem Hub, dem Router und dem Oracle, sodass sich keine vorhergesagte Adresse verschiebt
5. DeployBridge: der Bridge-Hub und sein Adapter, an den vorhergesagten Adressen; der Owner benennt den Adapter auf dem Hub, einmal (setAdapter). Seit dem 2026-10-05 bricht das Skript ab, bevor es irgendetwas deployt, wenn die Factory bereits einen Hub benennt (seit dem 2026-10-06 seine erste Prüfung, noch vor den vorhergesagten Adressen), und mappt die Aktien, bevor es den Hub benennt, wenn sein Signer der Owner der Factory ist
6. setBridgeHub — vor dem ersten Markt. Seit dem 2026-10-05 lehnt es einen Hub ab, der einen bereits registrierten Basket nicht transportieren kann (UnmappedBridgeStock)
7. addStockMapping auf dem Bridge-Hub, für jede Aktie eines Baskets
8. Die Baskets registrieren: PlanBridgeBaskets gibt die Aufrufe des Owners aus. Seit dem 2026-10-06 umfasst ein Basket höchstens fünf Aktien: siehe Baskets
9. LaunchProtocol: $STOCKFUN, dessen gesamte Supply in seine gesperrte Position geht, sein Vault, der BuybackBurner und setBuybackWallet. Es braucht den zuvor benannten Airdrop-Contract, was DeployProtocol erledigt: Seit dem 2026-10-05 setzt es den Betreiber des Launchs vor dem Mint auf die Ausschlussliste von $STOCKFUN, auf der Adresse, die der Token einnehmen wird. Seit dem 2026-10-06 wird ein Lauf, der vor der Benennung des Protokoll-Markts abgebrochen ist, mit dem Token und dem Vault fortgesetzt, die er hinterlassen hat (--sig "resume(address,address)") und die zuerst geprüft werden, statt dass ein zweiter $STOCKFUN gemintet wird; sobald der Protokoll-Markt benannt ist, läuft das Skript nicht mehr, und die übrigen Schritte erfolgen von Hand
10. registerStockOft auf dem Airdrop-Contract, durch den Owner, für das OFT jeder Aktie auf Ethereum

Jedes upgradebare Modul wird als zwei Contracts deployt, zuerst seine Implementierung, dann sein Proxy. predict() zählt sie mit: Der Proxy des Bridge-Hubs kommt bei Nonce + 1 des Deployers, der seines Adapters bei Nonce + 3.

StockFun koppelt keinen LayerZero-Peer: Die Peers des USDG-OFT gehören seinem Emittenten, und der Preflight prüft sie nur.

Seit dem 2026-10-06 schreiben das lokale und das Testnet-Skript, LocalRun und DeployTestnetBridge, ihre Deployment-Datei nur, wenn sie ihre Transaktionen tatsächlich senden (Broadcast), und seit der neunten Audit-Schleife auch DeployTestnetRail: Die Adressen eines Dry Runs tragen keinen Code. Auf dem Testnet nimmt DeployTestnetRail dieselben drei Sequencer-Eingaben entgegen, alle optional (ohne Feed bleibt die Prüfung aus, da Chainlink auch für das Testnet keinen führt), und schaltet die Oracle-Pause jeder Aktie ein; die Ethereum-Skripte lassen beide Schutzmechanismen aus. Ein Testnet-Keeper läuft mit KEEPER_REQUIRE_MARKET_OPEN, KEEPER_AIRDROP_AFTER_SESSION und, seit dem 2026-10-06, KEEPER_CONVERT_ONCE_PER_WINDOW auf false, sodass er bei jedem Durchlauf konvertiert: siehe Der Keeper. Seit der siebten Audit-Schleife, am 2026-10-06, prüft der Keeper vor dem Start die Chain jedes RPC gegen seine Konfiguration: Ein Testnet-Keeper setzt KEEPER_CHAIN_ID=11155111 und, mit der Bridge, KEEPER_REMOTE_CHAIN_ID=46630, ein Mainnet-Keeper KEEPER_CHAIN_ID=1 mit 4663. Seit der achten Audit-Schleife sind beide Pflicht: Der Keeper verweigert den Start ohne KEEPER_CHAIN_ID oder, neben der Bridge, ohne KEEPER_REMOTE_CHAIN_ID. Der Daten-Worker der App prüft die Chain seiner Endpoints auf dieselbe Weise, und seine öffentlichen RPCs folgen seinen beiden Chain-IDs, sodass ein Testnet-Worker nur diese braucht.

Der LayerZero-Testnet-Lauf vom 2026-10-06 deployte das Protokoll auf Sepolia und auf dem Testnet von Robinhood Chain (Chain 46630) mit den Produktionsskripten oder Testnet-Wrappern, die deren Rumpf behalten, und eigenen Test-Tokens, Handelsplätzen und Adaptern, in einem Ordner der Contracts nur für das Testnet. Seit der neunten Audit-Schleife prüft der Preflight auch diesen Lauf, anhand seiner zwei Dateien, mit SEPOLIA_RPC_URL und ROBINHOOD_TESTNET_RPC_URL. Was der Lauf bewiesen hat und was nicht, steht in Tests und Verifikation.

Der Airdrop

Seit dem 2026-10-04 wird der Airdrop-Contract mit dem Protokoll deployt. Seine Einstellungen kommen aus der Umgebung:

Das sind Startwerte: Der Owner kann den Zeitplan (setCycleSchedule) und den LayerZero-Endpoint (setLayerZero) später ändern. Bei DeployRemote sind AIRDROP_DISTRIBUTOR und STOCK_ADAPTERS optional: Der Admin des Remote-Hubs kann sie später setzen (setAirdrop, setStockAdapter). Die zwei Gas-Richtlinien werden bei jedem Lauf gesetzt, aus der Umgebung oder den Standardwerten des Hubs, vor dem Distributor, dessen Compose-Gas innerhalb von ihnen liegen muss; der Admin kann sie später ändern (setAirdropReceiveGas, setAirdropComposeGas). Ein Wert über uint128 bricht den Lauf ab. Dann folgen die Schritte des Owners:

• setAirdropDistributor auf der Factory, erledigt durch DeployProtocol. Der Owner kann später einen anderen benennen; die Vaults lesen ihn live, und ein ersetzter Distributor behält jeden Zyklus dort claimbar, wo er ist
• registerStockOft auf dem Airdrop-Contract, für das OFT jeder Aktie auf Ethereum, das den eigenen LayerZero-Endpoint des Contracts verwenden muss
• setExclusions, nur für einen Token, der neben der Burn-Adresse weitere Adressen ausschließen muss: standardmäßig kein Markt-Token; die Liste von $STOCKFUN, mit ihrem Betreiber des Launchs, setzt LaunchProtocol

Die Aktien-Adapter selbst, einer pro Aktie — der Lockbox-Adapter auf Robinhood Chain und sein OFT auf Ethereum —, sind für das Mainnet nicht im Repository: Sie benötigen das Paket oft-evm von LayerZero. DeployRemote nimmt ihre Adressen entgegen. Der LayerZero-Testnet-Lauf vom 2026-10-06 verwendete Test-Adapter, das OFTAdapter von LayerZero über Test-Aktien und das OFT von LayerZero für die gewrappten Aktien, in seinem Ordner nur für das Testnet.

Jede Zustellung von Robinhood Chain läuft auf Ethereum in zwei Aufrufen: dem lzReceive des Aktien-OFT, das die gewrappte Aktie an den Airdrop-Contract mintet, dann dem lzCompose des Airdrop-Contracts, das sie gutschreibt. Seit dem 2026-10-06 nennt der Keeper bei jeder Sendung das Gas beider, gewählt aus Simulationen auf Ethereum (siehe Der Keeper), und der Remote-Hub hält jeden Wert innerhalb seiner Richtlinie, wobei null den Standardwert nimmt. Die Standardwerte decken mit 35 % und 30 % Reserve die schwersten Fälle, die auf Sepolia nach dem Glamsterdam-Upgrade von Ethereum gemessen wurden: Dort braucht ein lzReceive 184.702 Gas in einen Saldo, den der Airdrop-Contract bereits hält, und 481.548 für die allererste Zustellung einer Aktie; ein Compose 105.075, wenn der Zyklus die Aktie bereits führt, 433.645, wenn der Zyklus, den der Keeper eröffnet hat, sie noch nicht führt, etwa 531.600, wenn die Zustellung auch die erste Gutschrift des Zyklus ist, und 962.154, wenn sie den Zyklus selbst eröffnet. Die schwerste in den Tests gebaute Zustellung, eine Eröffnung gegen sechzehn ausgeschlossene Holder mit langen Historien, die außerdem vier beiseitegelegte Aktien mitnimmt, braucht zu den Preisen von Glamsterdam etwa 2,8 Millionen, unter der Compose-Obergrenze. Vor Glamsterdam, kalt gemessen in den Tests, brauchte eine Zustellung in einen offenen Zyklus etwa 85.000, eine, die einen Zyklus gegen eine ausgeschlossene Adresse eröffnet, etwa 275.000, und die schwerste etwa 1.016.000. Eine Zustellung, der das Gas ausgeht, schlägt fehl, ohne dass etwas verloren geht: Sie bleibt auf dem Endpoint von LayerZero gespeichert, 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 der Keeper das selbst, innerhalb seiner eigenen Grenze, und meldet einen zweiten Fehlschlag.

Die Verdrahtung der Factory

Die Factory wird nur mit ihrem Owner und ihren drei Wallets initialisiert; ihre Einstellungen beginnen mit ihren Standardwerten. Alles andere benennt der Owner danach:

• setLaunchModules: der Hook und der Lock, ein für alle Mal; beide müssen diese Factory benennen, und der Lock diesen Hook
• setDeployers: die zwei Deployer, die ersetzt werden können
• setVaultImplementation: die Implementierung hinter den Vaults der danach erstellten Märkte
• setHoldingRecorder: der Bestandsaufzeichner, dem neue Markt-Tokens melden
• setAirdropDistributor: der Airdrop-Contract, dem die Vaults ihre Aktien übergeben; er muss diese Factory benennen
• setTreasuryRouter, setTreasuryOracle, setSwapRouter, setBridgeHub und setProtocolMarket

Kein Markt kann erstellt werden, bevor der Lock, eine Vault-Implementierung und ein Bestandsaufzeichner benannt sind.

Der Bridge-Hub und der Swap-Router

setBridgeHub kann nur einmal gesetzt werden. Ein Versäumnis lässt sich nicht rückgängig machen. Seit dem 2026-10-05 lehnt es einen Hub ab, der nicht jede Aktie der bereits registrierten Baskets übersetzen kann: Mappen Sie sie zuerst auf dem Hub.

setSwapRouter ist keine Write-once-Einstellung: Der Owner kann sie jederzeit ändern. Sie bindet keinen Vault mehr: Die Vaults lesen sie nicht mehr, seit der Creator-Buyback am 2026-09-28 aus dem Code entfernt wurde. Sie hält die Adresse des offiziellen Swap-Routers fest, die der Preflight prüft.

Der Hook und seine durch Mining ermittelte Adresse

Die Adresse eines Hooks codiert seine v4-Berechtigungen in ihren niederwertigen Bits: Sie wird per Brute Force über den CREATE2-Salt gefunden. Seit dem 2026-10-02 ist die durch Mining ermittelte Adresse die des Hook-Proxys, mit allen 14 gesetzten Berechtigungsbits. Sie hängt vom Bytecode des Proxys und von seinen Konstruktorargumenten ab, die die Adresse der Implementierung enthalten. Bei einem neuen Deployment muss das Mining wiederholt werden; ein Upgrade behält die Adresse.

foundry.toml muss bytecode_hash = "none" und evm_version = "cancun" enthalten, sonst passt die durch Mining ermittelte Adresse nicht zum deployten Contract.

Upgrades

Ein Upgrade ist ein Aufruf des Protokoll-Owners auf dem Proxy des Moduls, der die neue Implementierung benennt; es wirkt sofort. Vor jedem Upgrade vergleicht contracts/script/check-storage-layouts.sh das neue Storage-Layout mit dem in contracts/storage-layouts/ festgehaltenen und schlägt bei jeder Änderung fehl, die keine Erweiterung am Ende ist. Seit dem 2026-10-05 vergleicht es jede Ebene jedes Structs, Größen eingeschlossen, und lehnt jede Änderung an einem Struct ab, das Element eines Storage-Arrays ist: Nur ein Struct, das Wert eines Mappings ist, oder die letzte Zustandsvariable darf wachsen, an ihrem Ende. --write aktualisiert die festgehaltenen Layouts nach einer beabsichtigten Änderung.

Die Gas-Richtlinien des Remote-Hubs kamen mit der neunten Audit-Schleife, am 2026-10-06. Ein vor ihnen deployter und dann upgegradeter Hub liest beide Richtlinien als null, und ein Spiegel-Vault, der auf den passenden Code upgegradet wurde, lehnt jede Airdrop-Sendung und jede Preisabfrage ab (AirdropGasNotSet), bis beide gesetzt sind. Die Reihenfolge ist daher: den Remote-Hub upgraden, beide Richtlinien setzen (setAirdropReceiveGas, setAirdropComposeGas), dann die neue Implementierung der Spiegel-Vaults benennen und jeden Spiegel-Vault upgraden, und erst dann einen Keeper der neunten Schleife starten, der den Hub nach den Richtlinien fragt und mit drei Argumenten sendet. Ein Keeper von vorher sendet unterdessen weiter mit den Standardwerten des Hubs. Ein mit dem neuen Code deployter Hub setzt die Standardwerte bei der Initialisierung.

Die Batch-Einstellungen des USDG-Adapters kamen mit der zehnten Audit-Schleife, am 2026-10-06: das Compose-Gas, das jeder Markt eines Bridge-Batches hinzufügt, und die Höchstzahl an Märkten, die ein Batch trägt. Ein vor ihnen deployter und dann upgegradeter Adapter liest beide als null und lehnt jeden Batch und jede Preisabfrage ab (BatchGasNotSet), bis sie gesetzt sind. Daher bringt sein Upgrade sie in derselben Transaktion mit (upgradeToAndCall mit setBatchGas(400000, 17)), dann senkt der Owner sein altes Compose-Gas, 1.200.000, auf den Grundbetrag, den jeder Batch jetzt braucht (setSettings, 200.000), und erst dann startet ein Keeper der zehnten Schleife, der die Obergrenze bei jedem Batch liest. Ein Keeper von vorher arbeitet mit dem upgegradeten Adapter weiter, solange nicht mehr als 17 Märkte gleichzeitig bereit sind. Der Adapter des Testnets wurde am 2026-10-06 auf diese Weise upgegradet, und sein nächster Batch ging mit seinem neuen Compose-Gas durch.

Ein Upgrade, das ändert, was der Datendienst der App liest, geht vor diesem Dienst live. Seit dem 2026-10-06 enthält die Lens den Zustand jedes Vaults und das, was der Hook und der Lock ihm schulden, und der Worker und die App, die diese Felder lesen, können keine ältere Lens lesen: Upgraden Sie zuerst die Lens. Die siebte Audit-Schleife ändert weder die Lens noch die Form dessen, was der Worker veröffentlicht (Schema 7): Ihr Worker und ihre App werden in beliebiger Reihenfolge deployt. Die achte ändert die Form (Schema 8: Jeder Aktienpreis sagt, warum er fehlt, wenn das Oracle von Robinhood Chain ihn zurückhält), nicht die Lens, und ihr Worker und ihre App werden weiterhin in beliebiger Reihenfolge deployt: Eine ältere App ignoriert den Grund, und diese App liest einen älteren Worker ohne ihn. Die neunte behält Schema 8.

Das Oracle der Robinhood-Rail startet, wie jedes TreasuryOracle, mit seinen beiden Schutzmechanismen aus. Ein auf dem Remote-Hub benanntes Ersatz-Oracle (setOracle) startet daher ebenfalls mit ihnen aus, und der Admin des Hubs schaltet sie für es wieder ein, wie es das Deployment-Skript tut: die Oracle-Pause jeder Aktie und den Sequencer-Feed, falls einer gesetzt war. Die bereits initialisierten Spiegel-Vaults behalten das Oracle, mit dem sie initialisiert wurden.

Einstellungen

Eine Einstellung ist ein Aufruf des Protokoll-Owners auf dem Modul, das sie hält, oder, auf Robinhood Chain, des Admins des Remote-Hubs; sie wirkt sofort und emittiert ein Event. Jedes Modul startet mit den Standardwerten, die in Vertrauensmodell aufgeführt sind. Die Bridge-Adapter starten mit dem Gas des Deployments: auf der USDG-Rail COMPOSE_GAS, der Teil des letzten Schritts eines Batches, den jeder Batch braucht, seit der zehnten Audit-Schleife standardmäßig 200.000 in DeployBridge (bis dahin 1.200.000 für den ganzen Schritt), plus 400.000 für jeden Markt des Batches und höchstens 17 Märkte pro Batch (setBatchGas; das Gas des größten Batches höchstens 24.000.000), neben einer Curve-Grenze von 30 Basispunkten; auf der kanonischen Rail das Gas beider Tickets und, seit dem 2026-10-05, die Bytes, nach denen die Kosten des Einzahlungstickets berechnet werden (DEPOSIT_CALLDATA_LENGTH in DeployTestnetBridge; null übernimmt den Standardwert, 1.024). Der Remote-Hub startet mit den zwei Gas-Richtlinien der Airdrop-Zustellungen (oben).

Vor dem Mainnet

• Eine vollständige Probe des Notfallmodus: Transfer, Pause, Aufhebung der Pause
• Ein erster kleiner Airdrop auf einem Verifikations-Vault, vor jeder öffentlichen Öffnung. Der LayerZero-Testnet-Lauf vom 2026-10-06 hat den Code von StockFun durchgängig über die Testnet-Endpoints, das DVN und den Executor von LayerZero laufen lassen; er beweist weder das USDG-Paar von Paxos noch die Aktien von Robinhood und ihre Adapter, noch echte Feeds und Liquidität, noch Gas, Gebühren und Finalität des Mainnets
• Eine aktuelle Erhebung der Preis-Feeds auf der Remote-Chain
• Verifikation der LayerZero-Peers des USDG-OFT und des Pause-Status von USDG, per Preflight; seit der achten Audit-Schleife prüft der Preflight auch die Schutzmechanismen des Oracles gegen sein Manifest, das die Sequencer-Prüfung angeben muss, heute aus
• Die Größengrenze des Pfads, den das USDG von Paxos nach Robinhood Chain nimmt, gelesen aus der Send-Library von LayerZero (getExecutorConfig), und die Obergrenze der Märkte eines Bridge-Batches passend gesetzt, falls sie nicht 10.000 Bytes beträgt: höchstens (Größe − 392) ÷ 544 Märkte (seit der zehnten Audit-Schleife)
• Externes Review — die bestehenden formalen Beweise decken die Cross-Chain-Rail nicht ab