Emergency mode

Since 2026-08-29, StockFun's owner can move the assets of a treasury, or of any contract holding the protocol's funds, to any address. Since 2026-10-05 the transfer is immediate: no notice, no delay, and no setting can add one. It is the project's most consequential change, and it altered what the product is allowed to say.

What it allows

emergencyTransfer(asset, amount, to), called on the contract that holds the asset, moves that amount of any asset — ETH, USDC, USDG, tokenized stocks, market tokens — to to, at once. Five contracts carry it: the TreasuryVault, the BridgeHub and, since 2026-10-04, the airdrop contract, AirdropDistributor, on Ethereum; the RemoteHub and the mirror vaults on Robinhood Chain. Only their emergency admin can call it: the factory's owner on Ethereum and, on Robinhood Chain, the same address as the last bridge batch carried it. The owner can use it on any of these contracts, at any time.

Each transfer gets a sequential id and emits a public event, EmergencyExecuted, with the asset, the amount and the recipient. Nothing announces it beforehand.

Until 2026-10-05 the owner scheduled the movement: a public event announced it, the owner could cancel it for 48 hours, and anyone could execute it afterwards. That schedule is gone, and the delay is not a parameter: an emergency acts as soon as the owner uses it, never after a wait. Gone with it is the exception planned for airdrop funds stuck in a mirror vault, which was never coded: the immediate transfer already covers them.

Alongside it: a pause on conversions and bridging — immediate, moving no funds — and replacement of the bridge adapter for future sends, changeAdapter, immediate too since 2026-10-05. On the airdrop contract, the pause stops the sends, the opening of cycles (openCycle) and the placing of held-aside stocks (assignUnassigned); it moves nothing and never stops a claim.

Since 2026-10-01 a paused remote hub still applies the keeper and emergency-admin changes each batch carries, so a change of owner always reaches Robinhood Chain; the cash it receives meanwhile waits there, recorded per market, until a sweep after the unpause.

The security audit of 2026-09-29 found that the adapter replacement cannot work end to end: the remote hub only accepts batches from the original adapter, so every batch sent after a replacement would wait on the remote hub until emergency mode recovered it (M-2). On 2026-10-05 the owner decided to keep it as it is: an adapter is changed by upgrading it in place, at the same address, and a new address would first need the remote hub upgraded to accept it.

On a vault, since the security pipeline of 2026-10-01, an emergency transfer that takes the cash below the stocks' reservations zeroes them all: what is left, and every later inflow, is split afresh at the basket's weights. An emergency that takes only unreserved cash, or another asset, keeps them. Cash taken out and sent back to a vault is split like any inflow, not returned to the stock it was reserved for.

The second round of the audit, on 2026-10-01, found that on the remote hub an emergency that takes cash already recorded for a market leaves the record in place, to be paid out of other markets' cash (R2H-1). Since 2026-10-05 a transfer is followed by a settlement, below, and that case is covered by its tools plus a procedure: on the canonical rail, StockFun's owner pauses the remote hub before the transfer. Since the fourth audit loop of that day, a transfer can also be charged to one market, which settles its books in the same call.

After a transfer: settling the books

Since 2026-10-05, after the audit loops of that day. The transfer itself is unchanged: immediate, with no condition. But two contracts hold assets that back what several markets are owed: the airdrop contract and the remote hub. After a transfer out of either, the books are settled, never paid out of another market. Either the assets come back, or StockFun's owner writes the loss off the market that suffered it.

Both contracts count what backs their books, never their balance. The balance also holds tokens that have arrived but are not credited yet: a delivery of stocks whose last step on Ethereum has not run, or, on the USDG rail, a batch's cash whose last step on Robinhood Chain has not run. Those tokens back nothing yet, and may belong to another market. Until the second loop of 2026-10-05 the contracts read the balance, so such tokens could reopen the claims of a drained cycle and pay them with another market's stocks.

  • An emergency transfer takes from what backs the books first. The tokens cannot be told apart, and counting the credited ones as gone first never makes one market pay for another. What it takes beyond that came from tokens not credited yet: the contract records it (taken, cashTaken), and the next deliveries of that asset pay it off before they back anything.
  • Assets come back through restore. Anyone can call it; it pulls the tokens from the caller. A plain transfer to the contract backs nothing. Since the third audit loop of 2026-10-05, restore first pays back what a transfer took beyond what backs the books (taken, cashTaken), and backs the books with the rest: the tokens of a delivery still waiting never pay a drained market.

  • Stray tokens. Tokens that reached the airdrop contract, or the remote hub on the USDG rail, without ever being credited, sent there by mistake, also count against what backs the books if an emergency transfer takes them out. An emergency transfer takes them out only to restore them; otherwise their amount has to be written off the cycle or the market it lands on, or cleared by an upgrade.

  • The airdrop contract keeps, stock by stock, what it owes and what backs it, and pays a stock only while what backs it covers what it owes. After a transfer that took part of a stock, claims of that stock wait, in every market that holds it, until the stock comes back through restore or until the owner writes the loss off the cycle that lost it (writeDownCycle), or off the stocks a market holds aside (writeDownUnassigned). While nobody has claimed that stock from the cycle, the owner can write off any part of it, and every holder of the cycle loses the same share; once some holders have been paid, the owner can only write off the whole remainder, which the holders not yet paid lose, or bring the stock back. Whatever reaches that cycle afterwards is shared pro rata among all its holders, as if the written-off amount had never been there. No other cycle pays for it. Since the fourth audit loop a claim defers only the stock that waits (ClaimDeferred) and pays the others in the same call; until then it failed whole. The airdrop contract has no transfer charged to one cycle: its size limit left no room. The procedure that never lets its books go short writes the cycle, or the held-aside stocks, down first, then moves the stock; a transfer made first keeps the general wait above.

  • The remote hub, on the USDG rail, counts the cash that backs what it owes and refuses to pay out (sweep) while that falls short. After a transfer that took more than that, the next batches are recorded instead of delivered until they have made up for it. The owner brings the cash back (restore), or writes off an amount that is lost, or that the transfer delivered by hand to the market's mirror vault (writeOffPending). Since the fourth audit loop the owner can also charge a transfer to one market: emergencyTransferFromPending(marketId, amount, to) moves what the hub owes that market and writes it off in the same call, so the books never go short and no other market waits.
  • The remote hub, on the canonical rail, owes its queue's records and keeps no such count: the protection is a procedure. The owner pauses the hub before the transfer, moves the cash, drops the record whose cash it was (writeOffRecord), then unpauses, so the queue never pays that record a second time with another market's cash. Since the fourth audit loop one call does it for a record: emergencyTransferRecord(index, to) moves the record's whole amount and drops it. Since the fifth, that call is for a record whose deposit has landed: the queue's cash is pooled, so it refuses an amount beyond the cash not held for refused shares (RecordNotCovered); a record whose deposit is lost is dropped with writeOffRecord. A share a mirror vault refused, held apart for its market (undeliverable), is moved and written off with emergencyTransferFromPending.

Each write-off emits a public event (WrittenDown, PendingWrittenOff), and so does each return (Restored) and each deferred claim (ClaimDeferred).

Rescues: what a module holds by mistake

Since 2026-10-05, under the founder's rule that everything able to hold funds has a lever (see Architecture), the contracts without emergency mode have a rescue of their own, for what was sent to them by mistake or left by a failed operation. Only StockFun's owner calls it: the factory's owner on Ethereum, the remote hub's admin on Robinhood Chain, the same address that upgrades the modules. Each rescue emits a public event.

  • The modules that keep nothing of anyone's between transactions — the factory, the Lens, the oracles, the holding recorder, the stock routers, the official swap router and the bridge adapters — have rescue(asset, amount, to), for ETH (the zero address) or any token
  • The hook rescues strays only: at most the ETH sent to it by anyone but the PoolManager (strayEth), and any token, since it never holds one. The creators', the team's and the buyback's balances and the vaults' debts never leave that way. ETH forced in without a call is not counted, and waits for an upgrade
  • The liquidity lock, which cannot be upgraded, rescues any token, and ETH beyond the shares it keeps for vaults and creators (totalOwed), which never leave that way; since the fifth audit loop also v4 claims credited to it in the PoolManager (rescueClaims) and an NFT sent to it by a plain transfer (rescueNft). It has no generic call: through the PoolManager, one could reach the end mode's recovery without its 30 days. Its positions stay reachable only through the end mode
  • The BuybackBurner rescues a token at any time, and its ETH only once no burn could spend it: before the protocol market is named, or once the end mode has recovered the $STOCKFUN pool. While that pool is locked, its ETH leaves only through burns
  • The tokens, which cannot be upgraded, rescue what was sent to their own address: their own tokens, reported to the holding recorder like any transfer, any other token, ETH forced in, and, since the fifth audit loop, v4 claims and NFTs (rescue, rescueClaims, rescueNft). No holder's balance can move that way
  • The implementation contracts behind the proxies are never used directly. On the factory's and the remote hub's, which keep their admin in the proxy's storage, the lever for what is sent to their own address is the address that deployed them; every other implementation reads its admin through its authority, the protocol owner

The vaults, the two hubs and the airdrop contract keep emergency mode instead, since they keep books of their own. The two deployers on Ethereum and the remote vault deployer hold no state, accept no ETH and have no owner: they need no lever.

What it does not allow

Emergency mode does not touch the feed registry. It moves assets; it does not change execution bounds, which are separate settings of the owner. It cannot make a vault buy anything at any price; it can take, at once, what is in a vault.

Nor can it touch locked liquidity or holders' tokens. The same goes for the airdrop: emergency mode can move the airdrop contract's stocks, but it cannot change how a cycle is split between its holders. The shares stay as they are; since 2026-10-05 a claim is paid only while what backs the contract's books covers everything it owes in that stock, and a loss that will not come back is taken off the cycle that suffered it, never off another (above).

It is not the owner's only path to a vault, though. Since 2026-10-02 StockFun's owner can also upgrade a vault, or the oracle it reads, with immediate effect. Locked liquidity has its own exit, the end mode, announced 30 days ahead: the one fixed delay of the protocol. See Trust model.

Why it exists

The cross-chain failure-mode review asked a simple question: what happens when a route fails, a bridge message is lost, or a contract has a bug?

With no recovery path the answer is "the funds are lost, permanently". The protocol chose a controlled recovery path, held by its owner and recorded onchain, over the elegance of a system that can repair nothing. Since 2026-10-05 that path acts as soon as it is used.

Since 2026-10-01 it is also how the cash of a market whose basket Robinhood Chain refused leaves that market's mirror vault, which stays uninitialized: see The Robinhood rail.

What it costs

The owner can move a treasury's assets to any address, at once and without notice. That is written into the project's trust model.

Above all, the validated wording replaces every earlier promise.

Assets are held by the market's vault and governed by its rules. The StockFun team can move a treasury's assets in an emergency, after a public 48-hour delay.

Since 2026-10-05 the delay in this sentence no longer exists: the transfer is immediate. The sentence is to be revised, and its new wording validated. Since 2026-10-02 it does not cover the vaults' upgrades either, which take effect at once.

The product can no longer say non-custodial, trustless, immutable treasury, or no one can touch the treasury. Those phrases are banned by the branding rules; the automated copy audit does not check them, review does.

Emergency mode is never described as a protection or a guarantee against loss. It is a power held by the team, effective at once. Nothing more.

What the user sees

Until 2026-10-05 a banner was to announce a scheduled recovery on every affected surface, with its execution date. A transfer is now immediate, so there is nothing to announce ahead: it becomes visible after the fact, in the EmergencyExecuted event of the contract it left.