緊急モード

2026-08-29以降、StockFunのオーナーは、トレジャリーの資産、またはプロトコルの資金を保有するあらゆるコントラクトの資産を、任意のアドレスへ移動できます。2026-10-05以降、この移転は即時です。事前告知も遅延期間もなく、どの設定によっても遅延期間を加えることはできません。これはプロジェクトで最も影響の大きい変更であり、プロダクトが言ってよいことを変えました。

可能になること

emergencyTransfer(asset, amount, to)は、資産を保有しているコントラクト上で呼び出され、あらゆる資産（ETH、USDC、USDG、トークン化株式、マーケットのトークン）のその量を、ただちにtoへ移動させます。この関数を持つコントラクトは5つあります。Ethereum上のTreasuryVault、BridgeHub、そして2026-10-04以降はエアドロップのコントラクトであるAirdropDistributor、さらにRobinhood Chain上のRemoteHubとミラーボールトです。これを呼び出せるのは、それらの緊急管理者だけです。Ethereumではファクトリーのオーナー、Robinhood Chainでは、直近のブリッジバッチが運んできた同じアドレスです。オーナーは、これらのどのコントラクトに対しても、いつでもこれを使えます。

各移転には連番のIDが付き、資産、量、受取人を含む公開イベントEmergencyExecutedが発行されます。事前に告知するものは何もありません。

2026-10-05までは、オーナーが移動をスケジュールしていました。公開イベントがそれを告知し、オーナーは48時間の間それをキャンセルでき、その後は誰でも実行できました。このスケジュールはなくなり、遅延期間はパラメータではありません。緊急モードは、オーナーがそれを使った時点で作動し、待機を経ることは決してありません。これとともに、ミラーボールトに滞留したエアドロップ資金のために予定されていた例外もなくなりました。この例外はコード化されたことがなく、即時の移転がすでにそれらの資金をカバーしています。

これに加えて、変換とブリッジの一時停止（即時で、資金は一切動かさない）と、今後の送金に使うブリッジアダプターの差し替え（changeAdapter。2026-10-05以降はこれも即時）があります。エアドロップのコントラクトでは、一時停止は、送付、サイクルの開始（openCycle）、保留された株式の割り当て（assignUnassigned）を止めます。何も移動させず、請求を止めることは決してありません。

2026-10-01以降、一時停止中のリモートハブも、各バッチが運ぶキーパーと緊急管理者の変更を適用するため、オーナーの変更は必ずRobinhood Chainに届きます。その間にハブが受け取った資金は、マーケットごとに記録され、一時停止の解除後にスイープされるまでそこで待機します。

2026-09-29のセキュリティ監査は、アダプターの差し替えがエンドツーエンドでは機能しえないことを明らかにしました。リモートハブは元のアダプターからのバッチしか受け付けないため、差し替え後に送られたバッチはすべて、緊急モードで回収されるまでリモートハブで待機することになります（M-2）。2026-10-05、オーナーはこれを現状のまま維持することを決定しました。アダプターは、同じアドレスのままその場でアップグレードすることで変更され、新しいアドレスにするには、まずそれを受け入れるようにリモートハブをアップグレードする必要があります。

ボールトでは、2026-10-01のセキュリティパイプライン以降、資金を株式の確保分より少なくする緊急移転が行われると、確保分はすべてゼロになります。残った分と、その後のすべての流入は、バスケットのウェイトに従って改めて配分されます。確保されていない資金だけ、あるいは別の資産を持ち出す緊急リカバリーでは、確保分はそのまま残ります。持ち出された後でボールトに送り返された資金は、他のあらゆる流入と同じように配分され、それが確保されていた株式には戻りません。

2026-10-01に行われた監査の第2ラウンドは、リモートハブでは、あるマーケットのためにすでに記録された資金を持ち出す緊急リカバリーが、その記録をそのまま残し、その記録が他のマーケットの資金から支払われることになると明らかにしました（R2H-1）。2026-10-05以降、移転の後には清算が行われ（後述）、このケースは、清算の手段と1つの手順によってカバーされます。正規ブリッジのレールでは、StockFunのオーナーが、移転の前にリモートハブを一時停止します。同日の4回目の監査ループ以降は、移転を1つのマーケットの負担とすることもでき、その場合、同じ呼び出しの中でそのマーケットの帳簿が清算されます。

移転の後：帳簿の清算

これは2026-10-05以降、同日の一連の監査ループを受けてのものです。移転そのものは変わらず、即時で、条件はありません。しかし、2つのコントラクトが、複数のマーケットが受け取るべきものを裏付ける資産を保有しています。エアドロップのコントラクトとリモートハブです。そのどちらかからの移転の後、帳簿は清算され、別のマーケットから支払われることは決してありません。資産が戻ってくるか、StockFunのオーナーが損失を、それを被ったマーケットの負担として償却するかのどちらかです。

どちらのコントラクトも、数えるのは帳簿を裏付けるものであり、残高では決してありません。残高には、届いたもののまだ計上されていないトークンも含まれます。つまり、Ethereum上の最後のステップがまだ実行されていない株式の配信、またはUSDGのレールでは、Robinhood Chain上の最後のステップがまだ実行されていないバッチの資金です。それらのトークンはまだ何も裏付けておらず、別のマーケットのものである可能性があります。2026-10-05の2回目のループまでは、コントラクトは残高を読み取っていたため、そのようなトークンが、空になったサイクルの請求を再開させ、別のマーケットの株式でそれを支払ってしまうことがありえました。

緊急移転は、まず帳簿を裏付けるものから持ち出します。トークンは互いに区別できず、計上済みのものが先に出ていったものとして数えれば、あるマーケットが別のマーケットの分を負担することには決してなりません。それを超えて持ち出された分は、まだ計上されていないトークンから出たものです。コントラクトはそれを記録し（taken、cashTaken）、その資産の次の配信は、何かを裏付ける前に、まずそれを返済します。
資産はrestoreを通じて戻ってきます。誰でも呼び出すことができ、呼び出し元からトークンを引き取ります。コントラクトへの単なる転送は、何も裏付けません。2026-10-05の3回目の監査ループ以降、restoreは、移転が帳簿を裏付けるものを超えて持ち出した分（taken、cashTaken）をまず返済し、残りで帳簿を裏付けます。まだ待機している配信のトークンが、空になったマーケットへの支払いに使われることは決してありません。
紛れ込んだトークン。誤って送られ、一度も計上されないままエアドロップのコントラクト、またはUSDGのレール上のリモートハブに届いたトークンも、緊急移転がそれらを持ち出せば、帳簿を裏付けるものから差し引かれます。緊急移転がそれらを持ち出すのは、戻し入れるためだけです。そうでなければ、その額は、それが降りかかるサイクルまたはマーケットの負担として償却されるか、アップグレードによって解消されなければなりません。
エアドロップのコントラクトは、自身が負っている額とそれを裏付けるものを株式ごとに管理し、ある株式を支払うのは、それを裏付けるものが負っている額をまかなっている間だけです。ある株式の一部を持ち出した移転の後は、その株式の請求は、それを保有するすべてのマーケットで、その株式がrestoreを通じて戻ってくるまで、またはオーナーが損失を、それを失ったサイクルの負担として（writeDownCycle）、あるいはマーケットが保留している株式の負担として（writeDownUnassigned）償却するまで待機します。そのサイクルからその株式を誰も請求していない間は、オーナーはその任意の一部を償却でき、サイクルのすべてのホルダーが同じ割合を失います。一部のホルダーがすでに支払いを受けた後は、オーナーにできるのは、まだ支払いを受けていないホルダーが失うことになる残りの全量を償却することか、その株式を戻すことだけです。償却の後でそのサイクルに届いたものはすべて、償却された額が初めから存在しなかったかのように、サイクルのすべてのホルダーの間で比例配分されます。他のサイクルがそれを負担することはありません。4回目の監査ループ以降、請求は待機する株式だけを繰り延べ（ClaimDeferred）、同じ呼び出しの中で他の株式を支払います。それまでは、請求全体が失敗していました。エアドロップのコントラクトには、1つのサイクルの負担とする移転はありません。サイズの制限により、その余地が残らなかったためです。帳簿を決して不足させない手順では、まずサイクル、または保留された株式を償却し、その後で株式を移動させます。先に行われた移転は、上記の全体的な待機を保ちます。
USDGのレール上のリモートハブは、自身が負っている額を裏付ける資金を数え、それが不足している間は支払いを拒否します（sweep）。それを超える額を持ち出した移転の後は、次のバッチは、その分を埋め合わせるまで、配信される代わりに記録されます。オーナーは、資金を戻すか（restore）、失われた額、または移転によってマーケットのミラーボールトに手動で届けられた額を償却します（writeOffPending）。4回目の監査ループ以降、オーナーは移転を1つのマーケットの負担とすることもできます。emergencyTransferFromPending(marketId, amount, to)は、ハブがそのマーケットに負っている分を移動させ、同じ呼び出しの中でそれを償却するため、帳簿が不足することはなく、他のマーケットが待つこともありません。
正規ブリッジのレール上のリモートハブは、キューの記録に対する支払いを負っており、そのような集計は行いません。保護は手順によるものです。オーナーは、移転の前にハブを一時停止し、資金を移動させ、その資金が属していた記録を取り除き（writeOffRecord）、その後に一時停止を解除します。こうして、キューがその記録を別のマーケットの資金で二度目に支払うことは決してありません。4回目の監査ループ以降は、1つの記録について、1回の呼び出しでこれを行えます。emergencyTransferRecord(index, to)は、記録の全額を移動させ、その記録を取り除きます。5回目のループ以降、この呼び出しは入金が着地した記録のためのものです。キューの資金はプールされているため、拒否された取り分のために保持されていない資金を超える額は拒否されます（RecordNotCovered）。入金が失われた記録は、writeOffRecordで取り除かれます。ミラーボールトが拒否し、そのマーケットのために別に保持されている取り分（undeliverable）は、emergencyTransferFromPendingで移動され、償却されます。

各償却は公開イベントを発行し（WrittenDown、PendingWrittenOff）、各返還（Restored）と、繰り延べられた各請求（ClaimDeferred）も同様に発行します。

レスキュー：モジュールが誤って保有しているもの

2026-10-05以降、資金を保有しうるものにはすべてレバーがあるというファウンダーのルール（アーキテクチャを参照してください）のもとで、緊急モードを持たないコントラクトには、誤って送られたもの、または失敗した操作によって残されたもののための、独自のレスキューがあります。これを呼び出せるのはStockFunのオーナーだけです。Ethereumではファクトリーのオーナー、Robinhood Chainではリモートハブの管理者で、モジュールをアップグレードするのと同じアドレスです。各レスキューは公開イベントを発行します。

トランザクションとトランザクションの間に誰のものも保持しないモジュール（ファクトリー、Lens、オラクル、保有量レコーダー、株式ルーター、公式のスワップルーター、ブリッジアダプター）には、ETH（ゼロアドレス）または任意のトークンのためのrescue(asset, amount, to)があります
フックがレスキューで取り出せるのは、紛れ込んだ資金だけです。PoolManager以外の誰かが送ったETH（strayEth）をその額まで、そしてトークンはどれでも取り出せます。フックがトークンを保有することは決してないからです。クリエイター、チーム、バイバックの残高とボールトへの債務が、この方法で出ていくことは決してありません。呼び出しなしに強制的に送り込まれたETHは数えられず、アップグレードを待ちます
アップグレードできない流動性のロックは、任意のトークンと、ボールトとクリエイターのために保持している取り分（totalOwed）を超えるETHをレスキューで取り出せます。その取り分がこの方法で出ていくことは決してありません。5回目の監査ループ以降は、PoolManager内でロックに計上されたv4のクレーム（rescueClaims）と、単なる転送でロックに送られたNFT（rescueNft）も取り出せます。ロックには汎用の呼び出しはありません。PoolManagerを通じて、30日を経ずに終了モードの回収に到達できてしまうからです。ポジションに届くのは、引き続き終了モードだけです
BuybackBurnerは、トークンはいつでも、そのETHは、もはやどのバーンもそれを使えなくなった後にだけ、レスキューで取り出せます。つまり、プロトコルのマーケットが指定される前か、終了モードが$STOCKFUNのプールを回収した後です。そのプールがロックされている間、そのETHはバーンを通じてしか出ていきません
アップグレードできないトークンは、自身のアドレスに送られたものをレスキューで取り出せます。他のあらゆる転送と同じく保有量レコーダーに報告される自身のトークン、その他の任意のトークン、強制的に送り込まれたETH、そして5回目の監査ループ以降は、v4のクレームとNFTです（rescue、rescueClaims、rescueNft）。この方法で、ホルダーの残高が動くことはありえません
プロキシの背後にある実装コントラクトが直接使われることは決してありません。管理者をプロキシのストレージに保持するファクトリーとリモートハブの実装では、自身のアドレスに送られたもののためのレバーは、それらをデプロイしたアドレスです。それ以外のすべての実装は、権限の管理元を通じて、管理者としてプロトコルオーナーを読み取ります

ボールト、2つのハブ、エアドロップのコントラクトは、独自の帳簿を持つため、代わりに緊急モードを保持します。Ethereum上の2つのデプロイヤーとミラーボールトのデプロイヤーは、状態を持たず、ETHを受け付けず、オーナーもいません。レバーは必要ありません。

できないこと

緊急モードは、フィードのレジストリには触れません。資産を移動させるものであり、約定の許容幅を変更するものではありません。許容幅は、オーナーの別の設定です。緊急モードで、ボールトに何かを任意の価格で購入させることはできません。できるのは、ボールトの中身をただちに持ち出すことです。

また、ロックされた流動性やホルダーのトークンに触れることもできません。エアドロップについても同様です。緊急モードは、エアドロップのコントラクトの株式を移動できますが、サイクルがそのホルダーの間でどう配分されるかを変更することはできません。取り分はそのまま残ります。2026-10-05以降、請求が支払われるのは、コントラクトの帳簿を裏付けるものが、その株式でコントラクトが負っている額をすべてまかなっている間だけであり、戻ってこない損失は、それを被ったサイクルが負担し、他のサイクルが負担することは決してありません（上記）。

ただし、緊急モードは、オーナーがボールトに手を出せる唯一の経路ではありません。2026-10-02以降、StockFunのオーナーは、ボールトや、ボールトが読み取るオラクルを、同じく即時発効でアップグレードすることもできます。ロックされた流動性には独自の出口があり、それは30日前に告知される終了モードです。これが、プロトコルで唯一の固定された遅延期間です。信頼モデルを参照してください。

なぜ存在するのか

クロスチェーンの障害モードのレビューでは、単純な問いが立てられました。ルートが失敗したとき、ブリッジのメッセージが失われたとき、あるいはコントラクトにバグがあったとき、何が起きるのか？

リカバリー手段がなければ、答えは「資金は永久に失われる」です。プロトコルは、何も修復できないシステムの美しさよりも、オーナーが保持し、オンチェーンに記録される、管理されたリカバリー手段を選びました。2026-10-05以降、この手段は使われた時点で作動します。

2026-10-01以降、緊急モードは、Robinhood Chainがバスケットを拒否したマーケットの資金を、初期化されないままのそのマーケットのミラーボールトから出すための手段でもあります。Robinhoodレールを参照してください。

その代償

オーナーは、トレジャリーの資産を、ただちに、事前告知なしに、任意のアドレスへ移動できます。 これは、プロジェクトの信頼モデルに明記されています。

そして何より、承認済みの文言が、それ以前のすべての約束に取って代わります。

資産はマーケットのボールトが保有し、そのルールに従って管理されます。StockFunチームは緊急時に、公開された48時間の遅延期間の後、トレジャリーの資産を移動できます。

2026-10-05以降、この文にある遅延期間はもう存在しません。移転は即時です。この文は改訂が予定されており、新しい文言は承認を経ることになります。2026-10-02以降、この文は、ただちに発効するボールトのアップグレードもカバーしていません。

プロダクトはもはや、non-custodial、trustless、イミュータブルなトレジャリー、誰もトレジャリーに触れることはできないとは言えません。これらの表現はブランディングのルールによって禁止されています。自動の文言監査はこれらをチェックせず、チェックするのはレビューです。

緊急モードが、損失に対する保護や保証として説明されることは決してありません。これはチームが保持する、ただちに作動する権限です。それ以上のものではありません。

ユーザーに表示されるもの

2026-10-05までは、影響を受けるすべての画面に、スケジュールされたリカバリーとその実行日を告知するバナーが表示される予定でした。現在では移転は即時であるため、事前に告知するものは何もありません。移転は事後に、資産が出ていったコントラクトのEmergencyExecutedイベントとして確認できるようになります。