Premia on Arbitrum: six source outflows, two ETH payouts, and an unresolved cross-chain exit

On 1 November 2026, a wallet called the same execution contract twice, one second apart. In those transactions, collateral moved out of six source contracts, passed through option pools, and was partly converted into ETH. The execution contract then paid ETH to the wallet that submitted the calls. This review follows that Arbitrum sequence and the sender’s next nine ETH payments. It keeps the reported Bitcoin exit separate from the route directly observed here.

Premia is an options protocol. An option gives its buyer a right to trade an asset on agreed terms; a vault can place depositors’ assets behind those obligations. An option pool is the contract in which the associated positions and collateral are recorded. The distinction matters: collateral leaving a vault, leaving a pool, changing asset and reaching a wallet are different stages of the same movement, rather than losses to add together.

Blockaid’s original alert described newly created empty pools, flash loans and options purchases that directed vault collateral into those pools before a liquidity withdrawal. That is the security firm’s mechanism assessment. The records below support a transaction sequence, but this review does not independently establish the precise code defect. Blockaid’s alert.

1. The actors and the limits of the route

The transaction sender signs the call and pays its fee. The execution contract receives the call and performs the contract interactions. The source contracts hold the collateral that later appears in the pools. These are roles in the records; they do not identify people or prove who controlled a destination.

The directly reviewed route is source contracts → option pools → execution contract → transaction sender → nine Arbitrum recipients. A separate public claim extends the trail to Ethereum and Bitcoin. No solid arrow in the diagrams below represents that unconfirmed cross-chain extension.

2. Preparation came before the two calls

What was already in place when the collateral moved? At 03:14:37 UTC, the sender called the execution contract in a successful transaction that the explorer records as creating six contracts. The same record shows small transfers into those newly created addresses and option-position mint and burn entries. A mint creates a token record; a burn removes one. Neither entry alone proves that a separate person deposited or received assets.

The setup predates the first reviewed outflow by 62 seconds. The two later calls are four Arbitrum blocks apart and one second apart by their displayed UTC timestamps. The wallet listing displays the same selector, 0xbcea0a12, for both later calls. A selector is the first four bytes used to indicate a contract function; it is not a decoded explanation of what that function does. Timing connects the sequence, but it does not by itself explain which condition in the vault or pool code permitted the withdrawal.

3. What left the source contracts

Which amount measures the collateral movement without counting it again at each step? For this question, the table uses each source address’s net ERC-20 outflow inside its relevant attack transaction. “Net” means transfers out minus transfers back to that same address in the same record. It is not a complete balance reconciliation or a final depositor-loss calculation.

The three USDC.e rows sum to 48,479.358725 USDC.e. USDC.e denotes the bridged token contract in these records; it is not silently substituted with native USDC. WBTC and WETH are token representations of Bitcoin and ether. Their token outflows should remain separate by asset, and the explorer’s changing dollar display should not be used to manufacture a single historical loss price.

Read Figure 1 from the source group into the central execution contract, then down to the transaction sender. Solid arrows summarize transfers within the reviewed Arbitrum records; arrow width is not proportional to amount. The key observation is that different collateral assets converge into two ETH payments. The next question is how those payments relate to later outgoing ETH.

Figure 1. The reviewed Arbitrum route. Source amounts are net outflows; the two ETH payments describe a later stage and are not added to them. Exact quantities and source links appear in the adjacent tables.

4. Working capital is different from proceeds

The first transaction shows the Balancer-labelled vault sending 0.9 WBTC, 11 WETH and 6,000 USDC.e to the execution contract, with matching token repayments in that same transaction. A flash loan supplies temporary working capital that is borrowed and repaid within one transaction. The matching round trips support that description; they are not separate victim losses.

After the first call, the explorer’s net-transfer view shows 3.62484902 WBTC and 21,223.508226 USDC.e retained by the execution contract. Its second-call net view shows those same quantities leaving it, with swap counterparties receiving those tokens and sending WETH. The second record includes WETH receipts of 124.023037246690632576, 21.175933432587279601 and 3.338052413673076108. Their sum is the 148.537023092950988285 WETH unwrapped in that call. Second call: transfer and unwrap record. This supports the asset-conversion sequence without treating the retained tokens and resulting ETH as two losses.

Each payout is visible as an internal ETH transfer from the execution contract to the sender. The same transaction also shows the corresponding WETH unwrap. Unwrapping changes the form of ether; it is not another independent theft. These payouts also differ from the source-contract net outflow amounts because trading, premiums and other transfers intervene. They are not a gas-adjusted profit statement.

5. Nine onward payments, not nine proven cash-outs

What happened to the sender’s ETH next? Nine selected transaction details show successful outgoing ETH payments between 03:18:09 and 03:30:58 UTC. The timestamps below are normalized from Blockscout’s explicitly displayed +09:00 offset; the original display is retained in the evidence files. These transactions total 191.823 ETH.

The outgoing total exceeds the two reviewed attack payouts by 0.047479229733843730 ETH. This arithmetic difference does not establish a second theft, a service fee or a missing bridge payment. A pre-event internal-transfer listing also records 0.05946476252970877 ETH entering the sender at block 520146086 from an address labelled “Across Protocol: Spoke Pool.” The listing establishes an earlier inflow lead, not the identity of a depositor or a verified cross-chain origin. Its parent transaction has not been independently decoded in this review. Internal-transfer listing.

Read Figure 2 from the two payout boxes into the sender, then outward to the onward-payment group. Solid arrows describe observed Arbitrum movements; the dashed boundary marks the reported cross-chain continuation. The larger outgoing total warns against assigning every outgoing wei to this incident. Finding which service request corresponds to each recipient is the next evidentiary step.

Figure 2. Payouts and onward payments use separate denominators. The earlier funding listing prevents a claim that the entire later total is a directly measured incident loss. Dashed links represent a public report, not verified bridge delivery.

Blockscout’s transaction details include “Sent to Ethereum Mainnet” and a commitment transaction as part of the L1 status of these Arbitrum transactions. That is rollup publication and confirmation information. It is not evidence that the recipient received the payment on Ethereum or that a bridge delivered the stolen assets there.

6. Where the reported Bitcoin exit remains open

PeckShield’s original post gives an estimate of $464.6K and reports movement from Arbitrum to Ethereum followed by conversion into BTC through Chainflip and NEAR Intents. This is an attributed security-firm finding, not a route independently completed by the records reviewed here. PeckShield’s original post.

A payment to a deposit address does not by itself prove service completion. A payment may be a deposit attempt, a transfer to another wallet, or a step in a service route. Those alternatives remain open unless a request or payout record identifies its role. An independently established cross-chain route needs the source deposit, its service request or message identifier, and a matching destination payout. A Bitcoin destination also requires its actual address and payout transaction. Matching amounts, close times, explorer labels or the same hexadecimal address on two chains cannot replace those records.

The $400.5K alert and $464.6K later estimate therefore remain separate source claims. This article does not average them, add them or imply that their difference is a newly discovered loss. No price-at-block conversion, definitive vulnerable function, patch verification, recovery or compensation is established here.

7. Incident-specific response points

For protocol operators, the question raised by the sequence is how an option-writing vault accounts for collateral when a newly created pool has little or no independent liquidity. A meaningful review would reproduce the full first-trade and withdrawal sequence against the deployed implementation, test whether collateral ownership is preserved, and compare any proposed fix against that same sequence. This is an analysis priority, not a verified diagnosis of a particular function.

For investigators and relevant services, the useful handoff is the exact sender, execution contract, source transactions and nine recipient payments below. A service-specific deposit or request record could connect a payment to its eventual payout. Until that connection is obtained, recipient ownership, common control, completed Bitcoin swaps and recoverable balances remain open.

8. Evidence appendix

The pre-event funding listing names 0xe35e9842fceaCA96570B734083f4a58e8F7C5f2A as the sending contract and 0xd07a31b62136d22c461b1d2aa383bd530b6ccc01f7c03d0108be3270b01cde04 as the parent transaction. This is a listing-level observation; its original depositor and cross-chain source remain unconfirmed.

All addresses below are on Arbitrum One and link to that chain’s address detail pages. Full transaction hashes are preserved above and in the anchor register below. Explorer labels are descriptions of displayed roles, not independent identity evidence. The nine onward recipients are not labelled as accomplices or proven service wallets.

Attack transaction anchors

The direct checks cover the displayed explorer records and exact arithmetic described in this article. They are not an execution replay or an independent RPC receipt verification. The precise contract defect, service-request mappings, destination-chain transactions and Bitcoin receipt remain outside the verified route. No conclusion about the identity of an operator follows from the observed flow alone.