DEV Community: PandaSecurity

Loopscale: Pricing Misconfig and NAV Loan Exploit

PandaSecurity — Fri, 06 Nov 2026 23:13:44 +0000

Originally published at Loopscale: Pricing Misconfig and NAV Loan Exploit

On 5 November 2026, Loopscale — a Solana order-book lending protocol built around fixed-rate, overcollateralized credit markets and Genesis Vaults — paused operations after a week-long campaign of malicious API traffic. The next day the team published a two-path disclosure: a SOL Genesis Vault pricing misconfiguration that enabled an undercollateralized loan of approximately $412K, and a USDC Genesis Vault NAV-inflation attempt that sought a disproportionate redemption of approximately $521K, which Loopscale says their systems halted within 30 seconds of transaction generation.

This post summarizes only what Loopscale and corroborating public reports disclosed. We did not find published Solana transaction signatures for either path in those sources, so the analysis follows the team's disclosed paths rather than independently reconstructed receipts. Treat any illustrative logic as a simplified illustration, not verified Loopscale program source — the team did not publish program snippets in the posts we cite.

TL;DR

Target: Loopscale Genesis Vaults on Solana (SOL and USDC vaults called out).
Window: Week-long campaign of more than 30,000 malicious API requests per day, culminating in a pause on 5 Nov 2026; detailed two-path update on 6 Nov 2026.
Path 1 — SOL Genesis Vault pricing misconfiguration (~$412K): a misconfigured combination of asset-pricing parameters valued deposited collateral as a different asset, enabling an undercollateralized loan of about $412K.
Path 2 — USDC Genesis Vault NAV inflation (~$521K halted): an atomic transaction bundle sold a loan carrying an extreme interest rate into the USDC Genesis Vault, inflating its NAV and enabling a disproportionate redemption of about $521K, which Loopscale says was halted within 30 seconds.
User impact (per Loopscale): affected vaults have been made whole; no user deposits have incurred a loss, and no user deposits will incur a loss.
Restoration status (6 Nov): priority lending restored; collateral top-ups for all loans; repayments for all except USDC Genesis Vault-funded loans; collateral withdraw after full repay OK except for USDC Genesis Vault-funded loans; vault withdrawals still restricted.
On-chain Solana signatures for these paths were not published in the primary sources below — do not invent them.

What Loopscale Disclosed

Loopscale's pause announcement on 5 November 2026 framed the event as the end of a week of coordinated probing. Protocol APIs received more than 30,000 malicious requests per day. Attack attempts targeted the SOL and USDC Genesis Vaults. Both paths involved sophisticated, multi-step transactions aimed at publicly inspectable program logic and private transaction-building APIs.

The 6 November update separated the economic story into two failure modes:

Path	Vault	Mechanism (per Loopscale)	Figure	Outcome
1	SOL Genesis Vault	Misconfigured asset-pricing parameters valued collateral as a different asset	~$412K undercollateralized loan	Vault made whole; no depositor loss per team
2	USDC Genesis Vault	Atomic bundle sold an extreme-rate loan into the vault, inflating NAV	~$521K disproportionate redemption	Halted / intercepted within ~30 seconds; vault made whole; no depositor loss per team

Total exposure framing: roughly $412K of undercollateralized borrowing plus a ~$521K attempted redemption that was stopped — not a permanent ~$933K depositor loss. Loopscale's public position is that vaults were made whole and depositors did not — and will not — take a loss.

Path 1 — SOL Genesis Vault Pricing Misconfiguration

Order-book lending and vault products live or die on whether collateral is priced as the asset the depositor actually posted. Loopscale says an attacker exploited a misconfigured combination of asset-pricing parameters so that collateral deposited in the SOL Genesis Vault was valued as a different asset. With that wrong valuation in place, the protocol allowed an undercollateralized loan of approximately $412K.

That is a configuration / pricing-parameter failure, not a claim that Solana consensus broke. The dangerous property is familiar from EVM vault incidents: if an internal price table or asset-id mapping disagrees with the asset that actually moved, the protocol lends against fiction. Our CoreVault InsurancePool spot-price exploit is a different chain and bug class, but it shares the lesson that any value-moving path that trusts a mis-set or attacker-movable price will under-collateralize itself.

A simplified sketch of the shape of a pricing-parameter mix-up — not Loopscale source:

# Simplified illustration. Not Loopscale verified source.
# Collateral posted: SOL
# Pricing table (misconfigured): maps vault slot -> price feed for asset X != SOL

posted = deposit(SOL_amount)
value  = price_of(configured_asset_id) * posted   # wrong asset priced
loan   = borrow(value * LTV)                      # loan sized off fiction
# Result: undercollateralized exposure until parameters are corrected

Without published program snippets or Solana signatures in the cited sources, we cannot assert function names or the exact parameter that was wrong. The verified claim stops at Loopscale's description: misconfigured pricing parameters → wrong asset valuation → ~$412K undercollateralized loan.

Path 2 — USDC Genesis Vault NAV Inflation (Halted)

The second path targeted vault accounting. Per Loopscale, the attacker used an atomic transaction bundle to sell a loan carrying an extreme interest rate into the USDC Genesis Vault. That sale inflated the vault's NAV, which enabled a disproportionate redemption of approximately $521K.

Critically, Loopscale states that their systems halted the redemption within 30 seconds of transaction generation. The ~$521K figure is therefore an attempted / intercepted redemption size, not a confirmed permanent user loss. Reporting it as "stolen" would contradict the team's disclosure.

Vault products that mark NAV from the loans they hold inherit every extreme parameter those loans can carry. An interest rate that is legal in the program but economically absurd can reprice share value if the vault treats the loan mark as authoritative. Atomic bundles on Solana make the inflate-and-redeem sequence hard to interrupt mid-flight unless monitoring and circuit breakers sit close to the transaction-building path — which appears to be what Loopscale credits for the 30-second halt.

# Simplified illustration. Not Loopscale verified source.
# 1) Sell a loan with an extreme interest rate into the USDC Genesis Vault
# 2) Vault marks the loan into NAV -> share price jumps
# 3) Redeem a disproportionate amount against the inflated NAV
# 4) Loopscale: halt / intercept within ~30s of tx generation

Again: no public Solana transaction signatures for this path appeared in the primary sources we used.

Containment, Addresses, and Restoration

Loopscale linked these addresses in its pause disclosure (roles beyond "linked by Loopscale" were not further specified):

Item	Address
Solana	`247Lk5YNH9URfBBvxVUtDruz8GvGX8gKGuYHVCZThpiR`
Solana	`AzPh2dUV3duK9n8PWV6CxKMwWr9Rk7fxPNBZuv1CiwMr`
EVM	`0xb8959Aca4e4C796A3BaDA66833eAe60b1BC0bfb2`
EVM	`0xB7Ec7eF24FD73f3000C651CA9D0Fa45b61DcF854`

Containment claims (Loopscale): affected vaults made whole; no user deposits have incurred / will incur a loss; priority lending restored on 6 Nov; collateral top-ups for all loans; repayments for all except USDC Genesis Vault-funded loans; collateral withdraw after full repay OK except USDC Genesis Vault-funded; vault withdrawals still restricted.

Brief Historical Context

On 26 April 2025, an earlier Loopscale-related exploit drained roughly 5.7M USDC and ~1,211.4 SOL via RateX principal-token pricing manipulation; funds were later recovered and users took no net loss per contemporaneous reporting. That episode is background only — a different mechanism from the November 2026 Genesis Vault paths — but it underscores why pricing and NAV integrity remain the recurring theme.

Lessons for Builders and Auditors

Treat asset-id and price-feed configuration as security-critical code. A wrong mapping that values SOL collateral as another asset is enough to underwrite an undercollateralized loan.

Bound what a vault may mark into NAV. Extreme interest rates and atomic inflate-then-redeem bundles should fail closed or hit hard caps before share price moves.

Put circuit breakers next to private transaction-building APIs. Rate limits, anomaly detection on request volume (here: >30k malicious requests/day), and automated halts on abnormal redemption size are what turned path 2 into a 30-second intercept.

Assume multi-step, multi-chain follow-through. Publishing both Solana and EVM addresses early helps responders.

Reuse a structured review checklist. Pricing tables, vault NAV marking, and redemption paths are covered in our smart contract security checklist. Atomic funding patterns that amplify a bad mark are cousins of the patterns in our flash loan attack overview, even on Solana.

What Is Still Unknown

Public Solana transaction signatures for path 1 and path 2 were not included in the Loopscale posts or secondary reports cited below.
Loopscale did not publish program snippets in those posts; any code-shaped diagrams above are simplified illustrations.
Exact post-halt accounting (how vaults were made whole) was not detailed in the sources we used.
Aggregators may list a single headline figure; prefer Loopscale's two-path split (~$412K undercollateralized loan + ~$521K halted redemption) over collapsing both into one "lost" number.

Key Addresses and Figures

Item	Value
Protocol	Loopscale (Solana order-book lending / Genesis Vaults)
Chain	Solana
Pause / two-path disclosure	5 Nov 2026 / 6 Nov 2026
Malicious API traffic	>30,000 requests/day over the past week (Loopscale)
Path 1	SOL Genesis Vault pricing misconfig → ~$412K undercollateralized loan
Path 2	USDC Genesis Vault NAV inflation → ~$521K redemption halted within 30s
User deposits	Made whole; no loss incurred / will be incurred (Loopscale)
Solana (linked)	`247Lk5YNH9URfBBvxVUtDruz8GvGX8gKGuYHVCZThpiR`
Solana (linked)	`AzPh2dUV3duK9n8PWV6CxKMwWr9Rk7fxPNBZuv1CiwMr`
EVM (linked)	`0xb8959Aca4e4C796A3BaDA66833eAe60b1BC0bfb2`
EVM (linked)	`0xB7Ec7eF24FD73f3000C651CA9D0Fa45b61DcF854`
Prior incident (background)	26 Apr 2025 — ~5.7M USDC + ~1,211.4 SOL via RateX PT pricing; funds recovered

Sources

Loopscale pause announcement (5 Nov 2026): >30k malicious requests/day; vaults made whole; linked addresses; pause
Loopscale two-path update (6 Nov 2026): SOL pricing misconfig ~$412K; USDC NAV loan ~$521K halted in 30s; restoration status
CryptoBriefing: narrative of the pause and Genesis Vault targeting
crypto.news: API-request volume and halt coverage
ChainCatcher / Lookonchain / GetChain: corroborating ~$412K / ~$521K figures from official announcements
DefiLlama hacks entry for Loopscale Lending, 5 Nov 2026

Closing Thoughts

Loopscale's November 2026 incident is a reminder that Genesis-style vaults inherit every assumption baked into pricing parameters and loan marking. One path under-collateralized a loan because collateral was valued as the wrong asset; the other inflated NAV by selling an extreme-rate loan into a vault and racing a redemption — a race Loopscale says it won inside thirty seconds. If you ship fixed-rate credit markets or vault products that mark NAV from loans, talk to our team or check our audit pricing before those parameters and redemption paths go live against real deposits.

TENDRIL Exploit: Sell-Hook Burn-Sync Drained ~$555K

PandaSecurity — Thu, 05 Nov 2026 23:07:30 +0000

Originally published at TENDRIL Exploit: Sell-Hook Burn-Sync Drained ~$555K

At 16:02:45 UTC on 4 November 2026, one transaction on BNB Smart Chain emptied nearly all of the USDT sitting in the TENDRIL/USDT PancakeSwap V2 pair. Public alerts from CertiK, BlockSec Phalcon, ExVul, ScaleBit and TenArmor put the pool's loss around $550K–$556K. The same transaction repaid a ~30.64M USDT flash loan and sent 308,959.37 USDT to a profit address. There was no compromised admin key and no bug in PancakeSwap itself. The token's own sell-tax path burned TENDRIL out of the pair, called sync() while the seller's remaining tokens were still in flight, and left the pool with a near-zero TENDRIL reserve that a follow-up swap could cash out as USDT.

This is the same family of failure as other BNB Chain tax tokens that rewrite pair balances mid-transfer. The NEM skim-and-burn exploit burned pair inventory through a faked sell counter. TENDRIL's version was simpler: every taxed sell asked a helper contract to burn from the pair and sync before the outer transfer finished.

TL;DR

Target: TENDRIL (0xb1afdfd850da168f2cc9f742e11cdda5273973d2) and its PancakeSwap V2 USDT/TENDRIL pair (0x5de082471f2a9f01a61e467a32837dee830d99e0) on BNB Chain.
Exploit transaction: 0xfdff4fba4327821c204af07944076ecaaee163a994398fdf4063d08712e40059, block 131,653,427, 4 Nov 2026, 16:02:45 UTC.
Operator / caller: 0xb81e4aafa347b27112b7f6f5de6cf7cd516021ff calling exploit contract 0xc8cb6a2aa825a576e1470479046056fe414ee0f8.
Profit address (in-tx): 0xb87cf5ab84d0ab9545358cd30229627305331373 received 308,959.37 USDT.
Flash loan: 30,641,402.47 USDT from PancakeSwap Infinity Vault 0x238a358808379702088667322f80ac48bad5e6c4, repaid in full in the same transaction.
Reported root cause: sell-tax logic → PoolControl.sellToken → controlburn debiting the pair → pair.sync() before the seller's remaining (~70%) transfer arrives, collapsing the recorded TENDRIL reserve to 6,678 wei.

What the Chain Shows

We pulled the receipt and decoded ERC-20 Transfer and pair Sync events from a public BSC node. Token0 of the pair is USDT (0x55d39832...197955); token1 is TENDRIL.

The flash-loan bookends are exact:

Borrow. Vault 0x238a...e6c4 sends 30,641,402.469693 USDT to the exploit contract.
Manipulate and tax. The contract buys into the thin pair, triggers TENDRIL's 30% sell tax, and routes through PoolControl at 0xd00be871eb7a5cb8a69aea41e4c95affc92e54fe. During that path the pair's TENDRIL balance is burned (large transfer to 0xdead) and sync() is called.
Drain. After the burn-sync leaves TENDRIL reserves at 6,678 wei against roughly 4.42M USDT, the seller's remaining TENDRIL arrives and a swap pulls 4,421,023.357469 USDT out of the pair to the exploit contract. The next Sync shows USDT reserves at 2 wei.
Repay and keep. Exactly 30,641,402.469693 USDT goes back to the vault. 308,959.367543 USDT goes to 0xb87c...1373.

That profit figure matches BlockSec Phalcon's published take of about 308.96K USDT. The ~$550K–$556K figures from CertiK, ExVul, ScaleBit and Phalcon's first alert describe the pool-side loss framing, not the single profit transfer above. Different desks also count prior setup buys differently, which is why TenArmor's early alert sat near $309K.

How the Sell Hook Broke the Pair

Fee-on-transfer tokens on BNB Chain often take a cut on sells and push that cut through a helper. According to ExVul's public breakdown (function names as reported there; we did not verify TENDRIL source ourselves):

An ordinary sell of amount A calls PoolControl.sellToken(A).
PoolControl then calls sender-restricted TENDRIL.controlburn(2A), which debits the V2 pair itself.
PoolControl calls pair.sync() before the seller's outer remaining transfer (described as the remaining ~70%) lands in the pair.

msg.sender checks only authenticated the immediate Token and PoolControl contracts. An unprivileged seller still controlled the full Token → PoolControl → Token → Pair path. Once sync() had written a near-zero TENDRIL reserve, Uniswap V2-style math treated the delayed inbound TENDRIL as enough input to justify withdrawing essentially all of the USDT side.

A simplified sketch of that ordering bug, written for illustration only and not TENDRIL's actual source:

// Simplified illustration of the pattern. Not TENDRIL source.
function sellToken(uint256 taxedAmount) external onlyToken {
    // Burns from the pair balance, not from the seller's wallet.
    tendril.controlburn(taxedAmount * 2); // debits pair
    IUniswapV2Pair(pair).sync();          // locks in the burned reserve

    // DANGER: seller's remaining transfer has not arrived yet.
    // A later swapExact... call can drain USDT against the tiny reserve.
}

function _transfer(address from, address to, uint256 amount) internal {
    uint256 tax = amount * 30 / 100;
    uint256 send = amount - tax;
    // Tax path runs (and may sync) before `send` hits the pair.
    if (isSell(from, to)) {
        _poolControl.sellToken(tax);
    }
    _balances[to] += send;
}

A safer ordering finishes every balance update that belongs to the swap before any burn/sync, or better, never lets tax logic burn the pair's own inventory at all:

// Simplified illustration of a fail-closed shape.
function sellToken(uint256 taxedAmount) external onlyToken {
    // Burn from a dedicated tax treasury, never from the pair address.
    tendril.burnFrom(taxTreasury, taxedAmount);
    // If pair accounting must move, do it only after the outer
    // transfer has updated balances, and never mid-swap.
}

Why PancakeSwap Did Not Protect LPs

PancakeSwap V2 prices from the ratio of the two reserves it last synced. It has no opinion about whether a token burned its own side of the pool. When a custom token can change those balances and force a sync in the middle of a sell, the AMM's invariant becomes a weapon against the remaining liquidity. Auditing the router does not help; the dangerous code lives in the token and its tax helper.

The flash loan only rented size. With ~30.64M USDT of temporary inventory the attacker could push the thin TENDRIL pool around, trigger the taxed sell path on purpose, and still repay inside one transaction. Our flash loan attack overview covers that funding pattern; the novel piece here is the mid-sell burn-sync, not the loan itself.

Loss Figures and Open Questions

Public numbers do not all measure the same thing:

Framing	Figure	Source
Pool / incident loss	~$550K–$556K	CertiK, ExVul, ScaleBit, BlockSec Phalcon first alert
Early monitoring estimate	~$309K	TenArmor Alert
Profit transfer in exploit tx	308,959.37 USDT	on-chain `Transfer` we decoded; matches Phalcon
ExVul campaign-profit upper bound	~181,910 USDT after observed buys/gas	ExVul (excludes unpriced LP basis)
Burn-sync reserve after sync	6,678 wei TENDRIL	ExVul; matches pair `Sync` in the receipt

BlockSec Phalcon later posted an update arguing that most overall campaign profit came from roughly 33.06B TENDRIL acquired cheaply earlier through an attacker-created V3 pool, and that the burn-sync step may have added only on the order of $10K+ of incremental profit on top of that inventory. That does not erase the V2 drain mechanism above; it does mean the attacker's full P&L story may include setup trades outside the single exploit hash. We have not independently reconstructed that earlier V3 activity for this post.

We also did not find a project post-mortem or a patched token implementation at the time of writing. Treat the function names (sellToken, controlburn, _poolControl) as third-party labels from ExVul and BlockSec unless and until verified source is published.

Lessons for Builders and Auditors

Never burn the pair's own balance inside a sell hook. If tokenomics need a burn, burn from a treasury or from the seller's taxed amount after accounting is final. Debiting the LP pair turns every sell into a potential reserve rewrite.

Do not call sync() until inbound transfers that belong to the swap have landed. Ordering bugs are easy to miss in review because each step looks locally correct. Write a fork test that sells while a hook burns and syncs early, and assert that USDT (or the quote asset) cannot leave the pair beyond the fair amount.

Authenticate the whole economic path, not just msg.sender. TENDRIL's checks stopped at Token and PoolControl. The unprivileged seller still drove Token → PoolControl → burn → sync. If a privileged burn exists, the only safe callers are tightly scoped and cannot be reached from arbitrary sells.

Assume fee-on-transfer + flash liquidity. Any tax token paired against a deep quote asset is a candidate for the same shape. Our smart contract security checklist is a practical place to park review items for custom _transfer hooks.

Bound damage even when pricing is wrong. Per-tx withdraw caps and circuit breakers on pair USDT outflows would not fix a bad burn, but they turn a full drain into a partial one and give monitors time to react.

Key Addresses and Figures

Item	Value
Chain	BNB Smart Chain
Exploit transaction	`0xfdff4fba4327821c204af07944076ecaaee163a994398fdf4063d08712e40059`
Block / time	131,653,427 / 4 Nov 2026, 16:02:45 UTC
Operator (tx.from)	`0xb81e4aafa347b27112b7f6f5de6cf7cd516021ff`
Exploit contract	`0xc8cb6a2aa825a576e1470479046056fe414ee0f8`
Profit recipient (in-tx)	`0xb87cf5ab84d0ab9545358cd30229627305331373`
TENDRIL token	`0xb1afdfd850da168f2cc9f742e11cdda5273973d2`
TENDRIL/USDT pair	`0x5de082471f2a9f01a61e467a32837dee830d99e0`
PoolControl	`0xd00be871eb7a5cb8a69aea41e4c95affc92e54fe`
Flash loan	30,641,402.47 USDT (PancakeSwap Infinity Vault)
Final USDT pulled from pair	4,421,023.36 USDT
In-tx profit transfer	308,959.37 USDT
Reported pool loss	~$550K–$556K (multiple alert desks)

Sources

CertiK Alert: sell hook debited pair and synced before remaining input; ~$555K net loss
TenArmor Alert: same attack tx; early ~$309K estimate
ExVul Alert: PoolControl.sellToken / controlburn / early sync; 6,678 wei reserve; addresses
ScaleBit Alert: ~550k USDT drained; pair, token, exploit, attacker addresses
BlockSec Phalcon: ~$556K losses; 30.64M flash loan; ~308.96K profit; sell-tax burn-sync root cause
BlockSec Phalcon update: later note on prior V3 accumulation vs burn-sync incremental profit
0xCERT-2026-0313: advisory summarizing CertiK and TenArmor with the exploit hash
CryptoBriefing: narrative summary citing ExVul / ScaleBit disclosures
BNB Smart Chain receipt, Transfer and Sync events read directly from a public RPC node

Closing Thoughts

TENDRIL did not lose its USDT liquidity because PancakeSwap mispriced a swap. It lost it because a sell hook was allowed to rewrite the pair's own reserves before the sell finished. Any token that taxes, burns or "recycles" against the LP pair needs the same review posture as a vault that pays from an oracle: fail closed on ordering, never let unprivileged callers drive privileged burns, and talk to our team or check our audit pricing before that hook goes live against real liquidity.

CoreVault Exploit: Spot Price Fallback Drained 259 BNB

PandaSecurity — Wed, 04 Nov 2026 23:13:43 +0000

Originally published at panda-security.xyz

At 21:50:20 UTC on 3 November 2026, a single transaction on BNB Smart Chain drained 259.09 BNB from the reserve behind CoreVault, a BNB vault system tied to the OSK token. The attacker kept 160.26 BNB, which CertiK valued at about $112,200. There was no stolen key and no reentrancy. The attacker borrowed about 207,000 WBNB, dumped most of it into PancakeSwap's WBNB/USDT pool, and then asked CoreVault to redeem a position while the pool showed BNB at roughly one percent of its real price. CertiK reported that the redemption came out about 33 times larger than it should have.

The interesting part is not that a spot price can be moved with a flash loan. Everyone knows that. The interesting part is that the protocol reportedly did have a multi-source oracle, and the attack went through the path the oracle used when its safer inputs were not ready yet. This post walks through what the chain shows, where the reported root cause sits, and what to test in any vault that pays out of a reserve.

TL;DR

Target: CoreVault and the InsurancePool that backs its redemptions (OSK ecosystem), BNB Smart Chain.
Transaction: 0x072a10a579e2a8afa26a681205a2aaaa38f74bcb9d1064b12bd9e9ebe2c598b3, block 131,507,810.
Attacker EOA: 0xd3565b191b28b49cc517189b984dacdb1ff05304.
Loss: the reserve contract's BNB balance fell by 259.09 BNB; the attacker's balance rose by 160.26 BNB. The gap is swap fees paid to PancakeSwap.
Method: flash loan of 207,358.41 WBNB from Lista DAO's Moolah, dump 195,000 WBNB into the PancakeSwap v2 WBNB/USDT pair, redeem at the distorted price, swap back, repay.
Reported root cause: the redemption price came from an oracle helper that, according to one public breakdown, falls back to the PancakeSwap spot price when its TWAP and average-price windows are not fully populated.

What the Chain Shows

We pulled the receipt and the surrounding state from public BSC nodes. The transaction is a contract creation: the attacker deployed a helper at 0xc28cfeee...f387e2 and ran the whole attack from its constructor, so there was no separate setup transaction to front-run or flag.

The token transfers in the receipt follow a clean sequence:

Borrow. 0x8f73b65b...e5d8c sends 207,358.410468 WBNB to the attack contract 0x92f521a7...f542. Onchain Lens identified this lender as Lista DAO's Moolah, and its estimate of about $143.6M for the loan matches the amount at roughly $700 per BNB.
Dump. The attack contract sends 195,000 WBNB into the PancakeSwap v2 pair 0x16b9a828...1eb0dae and receives 13,791,474.30 USDT.
Redeem. A long run of OSK transfers and contract events follows between 0xfc1b8abb...159ef5, 0x302f5084...5d674 and several other addresses. These are the vault's own bookkeeping as the redemption is processed.
Unwind. The attack contract sends the same 13,791,474.30 USDT back to the pair and receives 194,901.165115 WBNB.
Repay. Exactly 207,358.410468 WBNB goes back to the lender. We saw no fee transfer to the lender in the receipt.

The native BNB side does not show up as token transfers, so we compared balances one block before and after using an archive node:

Address	Before	After	Change
`0xf40e0d52...53df1` (reserve paying out)	259.1618 BNB	0.0691 BNB	-259.0928 BNB
`0xd3565b19...05304` (attacker EOA)	1.9114 BNB	162.1692 BNB	+160.2578 BNB

The numbers reconcile. The round trip through PancakeSwap cost the attacker 195,000 minus 194,901.165, about 98.83 WBNB in fees and slippage. Take that from the 259.09 BNB that left the reserve and you get 160.26 BNB, which is what landed in the attacker's wallet. Onchain Lens reported a gross withdrawal of 260.21 BNB through CoreVault and a net depletion matching the roughly 259 BNB we see, and Telem's write-up reports the same pair of figures.

How Far the Price Moved

Right before the attack block, the PancakeSwap pair held about 15,345,479 USDT and 21,917 WBNB, a spot price of about $700.15 per BNB. After the 195,000 WBNB dump and the USDT that came out, the reserves were about 1.55M USDT and 216,917 WBNB, which puts the spot price near $7.16. That is roughly a 98x drop, held for the length of one transaction.

CertiK reported the redemption was inflated about 33x, not 98x. We do not have the verified CoreVault source to explain the exact ratio, so treat this as our reading rather than a confirmed fact: a figure between 1x and 98x is what you would expect if the manipulated spot price was blended with other price inputs instead of used alone. Blackpaper's summary says the redemption logic averaged a same-transaction spot price into a short sampling window. Either way, a partial dilution of a 98x move still left a 33x error, which was more than enough to empty the reserve.

The Reported Root Cause

The most detailed public description comes from Telem, and since CoreVault has not published a post-mortem, the function names below are as reported there and not something we have verified against source code.

According to that report, CoreVault's redeemPrincipal pays BNB for a USD-denominated principal. To convert, it uses a value called wbnbPerUsd, how many WBNB one dollar buys. That value comes from an OracleLib helper that takes a median of three sources. When the TWAP or average-price windows are not fully populated, the median falls back to the PancakeSwap spot price. The payout then flows through Treasury.payoutBnb into InsurancePool.withdrawReserve.

Dumping WBNB makes WBNB cheap, so wbnbPerUsd goes up, so a fixed dollar principal is converted into far more BNB. The attacker did not need to fool the oracle forever. It needed one transaction in which the only source that counted was the one it could move.

A simplified sketch of that failure pattern, written for illustration only and not CoreVault's actual code:

// Simplified illustration of the pattern. Not CoreVault's source.
function wbnbPerUsd() public view returns (uint256) {
    uint256 spot = pancakeSpotWbnbPerUsd();      // movable inside one tx
    (uint256 twap, bool twapReady) = twapWbnbPerUsd();
    (uint256 avg, bool avgReady) = avgWbnbPerUsd();

    // The dangerous branch: when safer feeds are not ready,
    // the "median" quietly becomes the spot price.
    if (!twapReady || !avgReady) {
        return spot;
    }
    return median3(spot, twap, avg);
}

function redeemPrincipal(uint256 usdPrincipal) external {
    uint256 bnbAmount = usdPrincipal * wbnbPerUsd() / 1e18;
    treasury.payoutBnb(msg.sender, bnbAmount); // pulls from the insurance reserve
}

A safer shape refuses to price at all when the robust inputs are missing:

// Simplified illustration of a fail-closed version.
function wbnbPerUsd() public view returns (uint256 price) {
    (uint256 twap, bool twapReady) = twapWbnbPerUsd();
    require(twapReady, "oracle: twap not ready");

    uint256 spot = pancakeSpotWbnbPerUsd();
    // Spot may be used as a sanity check, never as the price.
    require(_withinBps(spot, twap, MAX_DEVIATION_BPS), "oracle: spot deviates");
    return twap;
}

Why a Three-Source Median Did Not Help

A median of three sources is a reasonable design. It only works if all three sources are live and independent. The reported fallback breaks both conditions at once: when the windows are empty there is effectively one source, and it is the one an attacker can move with borrowed money.

Fallback paths are easy to miss in review because they look defensive. Someone wrote "if the TWAP is not ready, do not revert, use what we have" so the product would keep working right after deployment or after a quiet period. That is a liveness decision. In a function that sends value out, it turns into a security decision, and the safe default for a payout is to stop, not to guess.

The second design problem is where the money came from. An insurance reserve is supposed to absorb losses. Here it was wired directly into the redemption path, so any pricing error in redemptions was paid from the backstop. That turned a pricing bug into a reserve drain, and there was no per-transaction or per-period limit in the way.

Lessons for Builders and Auditors

Make every oracle fallback fail closed in value-moving paths. If a TWAP, median or external feed is not ready, revert redemptions, withdrawals and liquidations. A paused vault is an annoyance; a vault that prices from spot is a donation.

Test the cold start. Many TWAP implementations need a warm-up period after deployment, after a pool migration, or after a long gap in observations. Write tests that call every payout function in that state and assert that they revert.

Use spot only as a sanity check. Comparing spot to a TWAP and rejecting large deviations is useful. Letting spot set the price, even inside a median, is not.

Bound reserve outflows. Rate limits, per-transaction caps and caps relative to the reserve's size would not fix a bad price, but they turn a full drain into a partial one and buy time for monitoring to react.

Model the flash loan budget. Here roughly $143.6M of WBNB was borrowed against a pool holding about $30.7M of total liquidity. Your threat model should assume an attacker can borrow several times the depth of any pool your contracts read from, for free, within one transaction. Our earlier guide to flash loan attacks covers the general pattern.

Treat "derived from balances" and "derived from spot" as the same smell. The Moonwell MAMO exploit inflated a value through direct token transfers; CoreVault inflated one through a swap. Both read a number an attacker could set. Our smart contract security checklist is a good place to start when reviewing a vault.

What Is Still Unknown

CoreVault has not published a post-mortem that we could find, and the contracts' source was not available to us for verification. The function-level root cause above is third-party analysis.
Loss figures differ by framing. CertiK puts the attacker's take at 160.26 BNB, about $112,200. Onchain Lens and Telem put the reserve's net loss at about 259 BNB, roughly $175K to $181K depending on the BNB price used. Our balance check supports both: 259.09 BNB out of the reserve, 160.26 BNB to the attacker.
We found no public report of recovered funds or of a patch to the oracle fallback.

Key Addresses and Figures

Item	Value
Chain	BNB Smart Chain
Exploit transaction	`0x072a10a579e2a8afa26a681205a2aaaa38f74bcb9d1064b12bd9e9ebe2c598b3`
Block / time	131,507,810 / 3 Nov 2026, 21:50:20 UTC
Attacker EOA	`0xd3565b191b28b49cc517189b984dacdb1ff05304`
Attack contract (created in tx)	`0xc28cfeee046e1421e9dbfb2cf689074bf9f387e2`
Flash loan	207,358.410468 WBNB
WBNB dumped / recovered	195,000 / 194,901.165115 WBNB
PancakeSwap spot before / during	about $700.15 / about $7.16 per BNB
Reserve balance change	-259.0928 BNB
Attacker profit	+160.2578 BNB (about $112,200 per CertiK)

Sources

CertiK alert via TechFlow: 33x redemption inflation, 160.26 BNB, about $112,200
Onchain Lens via KuCoin News: Moolah flash loan, 260.21 BNB withdrawal, attack sequence
Telem: CoreVault insurance pool drained: reported function names and oracle fallback behavior
Blackpaper BP-1387: transaction hash, attacker address, spot-price averaging summary
The Crypto Guardian incident record: SlowMist classification and loss estimate
BNB Smart Chain receipt, block and archive balance data read directly from public RPC nodes

Closing Thoughts

CoreVault did not lose its reserve because it trusted a single DEX price on purpose. It lost it because a fallback written for convenience became the only price that mattered for one transaction. If your protocol pays out from a reserve or converts between assets with an on-chain price, talk to our team or check our audit pricing to have the cold-start and fallback paths reviewed before an attacker finds them.

Moonwell Exploit: A Donation That Skipped the MAMO Cap

PandaSecurity — Tue, 03 Nov 2026 23:08:28 +0000

Originally published at Moonwell Exploit: A Donation That Skipped the MAMO Cap

On 27 August 2026, an attacker borrowed $11,028,762 of cbBTC, WETH, USDC and wstETH from Moonwell, a Compound v2 style lending market on Base. The collateral behind those loans was MAMO, a thinly traded token that the attacker had formally deposited for only about $160K. Around 8.73M USDC of the proceeds left Base through Circle's CCTP within the hour, which is where the "$8.7M exploit" headline comes from.

The case is back in the news because on 2 November 2026 Certora published a formal verification write-up of the bug, and it is worth studying closely. The market had a supply cap that was meant to stop exactly this kind of oversized collateral position. The cap was set correctly and it measured the right number. It simply never ran, because the attacker added most of the collateral with a plain ERC-20 transfer instead of a deposit.

This post explains how the attack worked, why the cap did not fire, why this is the third Compound fork hit by the same pattern in 2026, and what we check for in lending code during an audit.

TL;DR

Protocol: Moonwell, MAMO market (mMAMO) on Base.
Date: 27 August 2026, roughly 06:09 to 09:46 UTC. Post-mortem by Anthias Labs, Moonwell's risk manager, on 28 August; Certora's formal analysis on 2 November.
Borrowed: $11.03M across 18 borrows. 8,729,454 USDC was burned on Base via CCTP and arrived on Ethereum, where it was swapped to DAI.
Residual debt: about $9.13M of borrower obligations remained at Anthias's evidence cutoff, its best estimate of potential bad debt.
Root cause: the market's cash is read from balanceOf(address(this)), so tokens sent directly to the contract raise the mToken exchange rate. The 20M MAMO supply cap was only checked inside mintAllowed, which a direct transfer never calls.
Amplifier: the attacker pushed the MAMO/USD feed from about $0.0106 to $0.4313 by buying on thin DEX liquidity.

What Moonwell's MAMO Market Looked Like

Moonwell listed MAMO through proposal MIP-B48 on 15 October 2025 with a 50% collateral factor, a 20,000,000 MAMO supply cap, a 3,000,000 MAMO borrow cap and a 30% reserve factor. According to Certora, the listing note from Anthias said roughly $200K of MAMO could be sold instantly while keeping slippage below the 7% liquidation bonus. In other words, the cap existed to keep MAMO collateral close to what liquidators could actually sell. On the morning of the attack, 20M MAMO was worth about $212K.

Like every Compound v2 fork, Moonwell gives suppliers a receipt token. One mMAMO is redeemable for an amount of MAMO set by the exchange rate:

exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply

Moonwell's own functions update totalBorrows, totalReserves and totalSupply. The fourth input, totalCash, is not stored. It is read live from the token, as Certora quotes from MErc20.sol:

function getCashPrior() internal view virtual override returns (uint) {
    EIP20Interface token = EIP20Interface(underlying);
    return token.balanceOf(address(this));
}

That single line is the whole vulnerability. Anything that increases the contract's MAMO balance increases what every existing mMAMO is worth, whether or not it came through Moonwell.

How the Attack Unfolded

Anthias Labs' post-mortem traces the funding back to 800.098 ETH withdrawn from Tornado Cash on 21 and 23 August. A linked account sold 799 ETH for 1,947,391 USDC through CoW Swap, bridged it to Base and handed MAMO, USDC and gas to the principal account (0x719e...919D, shown truncated in the post-mortem). From there, all times are UTC on 27 August:

Time	Event
06:09:45	Linked account funds the principal account with gas
07:04:11	First `mMAMO` mint; three mints supply 15,089,595 MAMO in total
08:43:13	First borrow: 0.50071233 cbBTC
09:19:59	34,910,397 MAMO sent directly to `mMAMO`, no mint
09:21:09	18,482,894 MAMO sent directly to `mMAMO`, no mint
09:28:49	MAMO/USD source feed peaks at $0.43127363
09:29:31	Moonwell accepts $0.40248571; 368 wstETH borrowed
09:30:13	Final borrow: 990,000 USDC
09:30:45	First liquidation, 32 seconds later
09:41:43 and 09:42:43	Two CCTP burns of 4,364,726.91 USDC each
10:53:43	Borrow caps cut to 1 wei
11:09:43	MAMO supply cap cut to 1 wei

Step 1: a legitimate looking deposit

The formal deposit of 15.09M MAMO stayed below the 20M cap, so every mint passed. It gave the attacker roughly 735.6M mMAMO, about three quarters of all mMAMO in existence. That share matters: whoever owns most of the receipts captures most of any increase in the exchange rate.

Step 2: the donation

The two direct transfers added 53,393,290 MAMO to the market. No Mint event was emitted and mMAMO total supply did not change, but cash did. Anthias measured the exchange rate rising from about 0.020513 to 0.075460 MAMO per mMAMO, a factor of 3.68. The attacker's receipts now represented about 55.51M MAMO, almost three times the cap on their own.

Step 3: the price push

In parallel, the attacker's accounts bought about 94.31M MAMO on DEXs, including Aerodrome's MAMO/USDC pool, for about $7.5M of gross volume. Much of that was recycled borrowed money. The oracle feed climbed from $0.0106 at 09:06 to $0.4313 at 09:28 and was back near $0.014 by 09:45.

At Moonwell's highest accepted price, 55.51M MAMO was worth about $22.34M, which at a 50% collateral factor allowed about $11.17M of borrowing. The attacker took $11.03M. Certora makes the point that both halves were needed: without the donation the position stays at 15M MAMO, and without the pump 55M MAMO at $0.0106 is only worth about $590K.

Step 4: borrow, bridge, walk away

Liquidators seized essentially all of the attacker's mMAMO across 595 liquidation events, but the MAMO price was already collapsing, so the seized collateral could not cover the debt. The attacker never needed to redeem the donated MAMO. Borrowing against it and leaving the debt behind was the whole plan.

Why the Supply Cap Did Not Stop It

Moonwell's cap lives in the Comptroller's mintAllowed hook. Certora quotes the check:

uint totalSupplies = sub_(add_(totalCash, totalBorrows), totalReserves);
uint nextTotalSupplies = add_(totalSupplies, mintAmount);
require(nextTotalSupplies < supplyCap, "market supply cap reached");

The formula is correct: it measures everything the market owes its suppliers, including donated cash. The problem is when it runs. It only runs on mint. A MAMO transfer executes inside the MAMO token contract and never calls Moonwell, so no Moonwell code can object. As Anthias put it, "the 20 million MAMO supply cap checked formal mint inputs." After the two transfers, the market would have refused any new deposit, but there was nothing left to refuse.

A cap enforced at one entry point only limits that entry point. If a quantity can also change through a path you do not control, the cap is a speed bump, not a limit.

The Same Bug, Three Times in 2026

Donation attacks on Compound forks are not new. Certora notes that Moonwell's own repository has carried a test since 2023 that reproduces the Hundred Finance exploit: it sends tokens directly to a market, and a comment says the attacker "can now borrow everything in the markets due to the massively inflated exchange rate." The tests then check that the donation cannot be pulled back out through redeemUnderlying. That protects one exit, but the MAMO attacker used a different one: borrowing.

In 2026 alone, Certora lists three Compound v2 forks hit by direct transfers combined with a pumped, thin collateral token: Venus on 15 March (where, per Rekt, a position reached 367% of the cap), Moonwell on 27 August and Tectonic on Cronos on 30 August. We touched on Tectonic's price manipulation in our roundup of recent blockchain hack lessons. The pattern is close to what happened in the Premia v3 vault exploit: the code did what it was written to do, but an accounting assumption about where balances come from did not hold.

The Fix: Count Only What You Received

The robust fix is to stop deriving cash from balanceOf. Certora proposes tracking cash in an internal ledger that only the market's own transfer functions move. A simplified version of their patch:

// Simplified for illustration, based on Certora's proposed fix.
contract MErc20DelegateInternalCash is MErc20Delegate {
    uint256 internal internalCash;

    function getCashPrior() internal view override returns (uint256) {
        return internalCash; // ignore unsolicited transfers
    }

    function doTransferIn(address from, uint256 amount)
        internal override returns (uint256)
    {
        uint256 received = super.doTransferIn(from, amount);
        internalCash += received;
        return received;
    }

    function doTransferOut(address payable to, uint256 amount)
        internal override
    {
        internalCash -= amount;
        super.doTransferOut(to, amount);
    }
}

A live market would also need a one-time admin call to initialise the ledger to the current balance. Certora's AutoProver, run after the attack against commit 3b32d53 (the last before the attack), wrote a rule stating that a donation must not change the supplier claim the cap is checked against. The Certora Prover reports that rule violated on the deployed contract and verified with the ledger, assuming MAMO is a standard ERC-20 with no callbacks. Moonwell, for its part, has not changed how markets count cash; it set the MAMO supply and borrow caps to 1 wei, used about $246K of reserves to repay bad debt in the USDC market (MIP-X66), and set MAMO's collateral factor to 0% from 17 October (MIP-X69).

Lessons for Builders and Auditors

1. Never price shares from balanceOf(address(this)). Vault shares, lending receipts and LP tokens should all be valued from internal accounting. If you must read the balance, treat any excess as a donation that does not change share value. This belongs on every smart contract security checklist.

2. Enforce invariants on state, not on entry points. Ask "what can change this number?" rather than "which function should check it?". If a transfer can move it, the check has to live where the number is read, or the number has to stop depending on transfers.

3. Treat low-liquidity collateral as an oracle problem and a cap problem together. A cap sized to liquidation depth is only meaningful if nothing can grow positions past it. Pair caps with price feeds that resist minute-scale manipulation, such as TWAPs or circuit breakers on sudden moves.

4. Test the exits you did not think of. Moonwell tested that a donation could not be redeemed. It did not test that a donation could not be borrowed against. For each attack class, enumerate every way value can leave: redeem, borrow, liquidate, transfer receipts.

5. Monitor for unsolicited transfers. A 35M token transfer into a market contract with no Mint event is a loud, cheap signal. An alert on that would have given Moonwell about ten minutes before the final borrows.

Key Addresses and Figures

Item	Value
Chain	Base
Principal account (truncated in post-mortem)	`0x719e...919D`
Linked operational account (truncated)	`0xD71d...C384`
Formal MAMO supplied	15,089,595 MAMO
Direct MAMO transfers	53,393,290 MAMO
Exchange rate change	0.020513 to 0.075460 MAMO per mMAMO
Total borrowed	$11,028,762 (18 borrows)
USDC burned via CCTP	8,729,453.83 USDC
Residual debt at evidence cutoff	about $9,131,342

Sources

Anthias Labs: Post-Mortem, MAMO Market Incident on Base (Moonwell forum): timeline, amounts, exchange rate, borrows, liquidations and fund flows
Certora: The Moonwell Exploit, an $8.7M Supply Cap Bypass Attack: code paths, cap logic, prior donation attacks, AutoProver results and status as of 28 October
Olympix: Moonwell $8.7M exploit analysis: independent summary of the borrowed total and timing
QuillAudits: Moonwell mMAMO exchange rate inflation exploit: independent description of the direct-transfer path

Closing Thoughts

The Moonwell exploit is a reminder that a correct check in the wrong place is not a control. The supply cap measured the right number, and the attack class had even been tested for years earlier, yet $11M walked out through a path nobody had pinned down. If your protocol values shares, receipts or collateral from token balances, talk to our team or see our audit pricing to have those accounting assumptions reviewed before someone tests them on mainnet.

b14g Exploit: Withdrawing Zero CORE Drained 97M CORE

PandaSecurity — Mon, 02 Nov 2026 23:07:16 +0000

Originally published at panda-security.xyz

At 09:29:51 UTC on 31 October 2026, a single transaction on the Core blockchain emptied 91 staking orders held by b14g, a Bitcoin dual-staking protocol. The attacker did not steal a key, deploy a new contract or bend a price oracle. They sent b14g a list of 99 withdrawal requests, each for 0 CORE. Core's staking layer reads a zero amount as "withdraw everything", so every order paid out in full: 97,045,563 CORE, worth about $1.47M at the pre-attack price according to Bitquery.

Two days later the story took an unusual turn. On 2 November, a Core network hard fork moved 68,146,177.22 CORE out of three attacker-controlled addresses into a recovery address. That is roughly 70% of the loss, clawed back by changing the chain's rules rather than by any transaction the attacker signed.

This post walks through the bug, the on-chain evidence, and the lessons for anyone building on top of somebody else's staking or vault interface.

What b14g Does

b14g matches two kinds of users on Core. Bitcoin holders lock BTC in a time lock on the Bitcoin chain, and CORE holders stake CORE alongside them so both sides earn Core's higher "dual staking" yield. On the Core side, b14g represents each arrangement as an order: a small contract that holds CORE and keeps it delegated to a Core validator.

To withdraw, a user calls b14g's main contract with three pieces of data per entry: the order, the validator it delegates to, and how much CORE to take out. b14g forwards the request to Core's system staking contract, which releases the coins. According to Bitquery, six wallets made eight ordinary withdrawals through this path between 28 October and the attack, each asking for a specific amount and receiving exactly that.

The BTC side was not touched. b14g says Bitcoin staked through it stays time-locked on Bitcoin and was not affected; only CORE was drained.

The Attack Transaction

We read the attack transaction directly from Core's public RPC to check the reported figures:

Transaction: 0xe1947f325e1f0bc22290ea97dc5b2ce44827fbb56e1cc40abaeda1d2ed04f62c
Block: 40,042,125, timestamp 2026-10-31 09:29:51 UTC
Sender: 0xc556ed208285406d71705927f92d4f4eaea579f1
Called contract: 0x04ea61c431f7934d51fed2acb2c5f942213f8967 (b14g's proxy)
Status: success, 11,464,357 gas, 327 event logs

The calldata is a single dynamic array with 99 entries. Each entry is a tuple of (order address, validator address, amount). Decoding it, we found that every amount is zero, the entries point at 91 distinct orders, and those orders are spread across 23 validators. The receipt also contains exactly 99 events from b14g's contract and 99 matching events from Core's system contract at 0x...1011, which lines up with one forwarded request per entry.

There are no ERC-20 Transfer events in the receipt. CORE is the chain's native asset, so the 97 million moved as native value through internal calls. Monitoring that only watches token Transfer logs would have seen nothing.

The sender wallet was fresh. Bitquery reports that its only funding was 615.62 CORE for gas, sent 29 minutes before the drain, and that the attack call was its first interaction with b14g.

Root Cause: A Sentinel Value Meets a Missing Ownership Check

Two separate design decisions combined into one exploit.

Zero means "all" in Core's staking layer

Core's staking code treats a withdrawal amount of 0 as a request to withdraw the delegator's entire stake with that validator. Each b14g order is the delegator from Core's point of view. So when b14g forwarded amount = 0 on behalf of an order, Core released that order's full balance. Core DAO said its consensus, validators and staking contracts kept working normally, and Bitquery's reading of the chain agrees: the system contract paid out exactly what it was asked to pay out.

Using 0 (or type(uint256).max) as "everything" is a common convenience in DeFi interfaces. On its own it is harmless. It becomes dangerous the moment another contract passes user-controlled amounts straight into it.

b14g did not check who was asking

The second half is on b14g's side. The attacker's wallet had funded none of the 91 orders, yet b14g accepted withdrawal requests against all of them and sent the proceeds to the caller. Bitquery notes it has not read b14g's source and cannot point to the exact line; b14g has promised a full post-mortem. What the chain does show is that a wallet with no stake asked for nothing, against orders it did not own, and was paid everything.

Bitquery also found that the logic running at the time had been b14g's standing implementation for about 17 months, so this was not a fresh, rushed upgrade.

What the pattern looks like (simplified)

The Solidity below is simplified and illustrative. It is not b14g's or Core's code. It shows how the two halves interact.

// Simplified illustration only - not the real b14g or Core contracts.
interface IStakeHub {
    // amount == 0 means "withdraw the full stake"
    function undelegate(address validator, uint256 amount) external;
}

contract VulnerableRouter {
    struct Req { address order; address validator; uint256 amount; }

    function batchWithdraw(Req[] calldata reqs) external {
        for (uint256 i; i < reqs.length; ++i) {
            // BUG 1: no check that msg.sender owns reqs[i].order
            // BUG 2: amount 0 is forwarded unchanged and becomes "all"
            uint256 got = IOrder(reqs[i].order).withdraw(
                reqs[i].validator, reqs[i].amount
            );
            payable(msg.sender).transfer(got);
        }
    }
}

A fixed version closes both doors:

// Simplified illustration only.
function batchWithdraw(Req[] calldata reqs) external {
    for (uint256 i; i < reqs.length; ++i) {
        Req calldata r = reqs[i];
        require(orderOwner[r.order] == msg.sender, "not owner");
        require(r.amount > 0, "zero amount");
        require(r.amount <= stakeOf[r.order], "exceeds stake");

        uint256 before = address(this).balance;
        IOrder(r.order).withdraw(r.validator, r.amount);
        uint256 got = address(this).balance - before;
        require(got == r.amount, "unexpected payout");

        stakeOf[r.order] -= got;
        (bool ok, ) = msg.sender.call{value: got}("");
        require(ok, "send failed");
    }
}

The ownership check is the real fix. Rejecting zero and asserting the received amount are defence in depth, so that a misunderstood downstream convention cannot silently turn into "send everything".

Timeline

All times UTC, from Bitquery's reconstruction, ChainClarity's trace and b14g's posts:

Time	Event
31 Oct 09:00:42	Attacker wallet receives 615.62 CORE for gas
31 Oct 09:29:51	Drain transaction: 99 zero-amount requests, 91 orders, 97,045,563 CORE
31 Oct 09:37 to 10:20	About 23.4M CORE moved out through single-use relay addresses
31 Oct 10:35:51	b14g multisig pauses the contract (about 66 minutes after the drain)
31 Oct 10:36:33	Attacker moves 73,646,178 CORE to a second wallet, `0x27758c30f8e424fbd8ca605bf31e9496c26ce92c`
31 Oct 16:38	b14g posts its security update on X
2 Nov 04:00 (scheduled)	Core hard fork activates and moves 68,146,177.22 CORE to a recovery address
2 Nov 07:23	b14g publishes "Recovery Update #1"

b14g says it paused the contracts as soon as it discovered the problem, and the chain cannot show when that was. What the chain does show is that the pause landed 66 minutes after the drain. By then about 23M CORE had already left the first wallet. Some of it reached exchange deposit addresses, and b14g says exchange partners froze about 9M CORE.

The Hard-Fork Recovery

According to b14g's recovery update and reporting by The Defiant, Core's Fermi upgrade included a one-time state change: it set the balances of three attacker addresses to zero and credited the combined amount, 68,146,177.22 CORE, to a designated recovery address. b14g describes this as made "without reversing transactions, minting new tokens, or changing the total CORE supply". When we queried Core's RPC late on 2 November (UTC), the second attacker wallet held 0 CORE, which matches that account.

As of b14g's update, the recovered CORE has not been distributed, no official claims process exists, and the exchange-frozen funds have not been returned. The Defiant estimates that around 19.9M CORE sits outside both the fork recovery and the reported freezes, while noting the figure is provisional.

For users this is good news. For protocol designers it is a reminder of something else: the recovery depended on a chain-level intervention that most applications cannot count on. On Ethereum or a major L2, there would be no fork. Treat a hard fork as a rare outcome, not as a plan.

Lessons for Builders and Auditors

1. Map every sentinel value in the interfaces you call. Zero-means-all, max-uint-means-all, address(0)-means-default: list them for each external dependency and decide, explicitly, whether your contract rejects them or authorises them. Our smart contract security checklist has a section on external call assumptions that fits here.

2. Ownership checks belong on every path that moves user funds. The missing control was not input sanitisation; it was "whose position is this?". The same family of failure showed up when a retired rebalancer kept vault permissions at Troves, and in the WAX bridge, where one unchecked number drained the contract.

3. Assert what you received, not what you asked for. Measuring the balance delta and comparing it with the requested amount turns a silent overpayment into a revert.

4. Batch functions multiply blast radius. A batch withdraw is convenient for users and for attackers. Here one call emptied 91 positions. Per-call or per-block outflow limits would have capped the damage.

5. Watch native-asset flows, and rehearse the pause. Native transfers emit no ERC-20 events, so monitoring has to track balances and internal calls. And 66 minutes from drain to pause is a measurable number; incident playbooks should aim to make it minutes.

6. Time in production is not proof of safety. The vulnerable logic ran for roughly 17 months. That measures how long nobody looked, not whether it was correct.

Key Addresses and Transactions

Item	Value
Drain transaction (block 40,042,125)	`0xe1947f325e1f0bc22290ea97dc5b2ce44827fbb56e1cc40abaeda1d2ed04f62c`
Attacker wallet A (sender)	`0xc556ed208285406d71705927f92d4f4eaea579f1`
Attacker wallet B	`0x27758c30f8e424fbd8ca605bf31e9496c26ce92c`
b14g contract (proxy)	`0x04ea61c431f7934d51fed2acb2c5f942213f8967`
b14g multisig	`0xff2a4d8f696991d5350b28fd6fbcf3c7b7f94233`

Sources

b14g Security Update on X: ~97M CORE withdrawn at 09:29 UTC, contracts paused
b14g Recovery Update #1 on X: 68,146,177.22 CORE recovered via hard fork, 97,045,563 CORE affected
Bitquery: b14g Hack, 97M CORE Taken by Asking to Withdraw Zero: mechanism, timeline, 66-minute pause, fund flows and addresses
ChainClarity: zero-CORE withdrawal emptied 91 b14g positions: transaction receipt details and relay trace
The Defiant via Cryptonews.net: Core fork recovers 68.15M CORE: Fermi upgrade details and remaining shortfall
Core public RPC (rpc.coredao.org): transaction, receipt, calldata decoding, block timestamp and current balances, read by PandaSecurity

Closing Thoughts

The b14g exploit is a clean example of a composability bug. Core's staking contract kept its documented promise, and b14g's withdrawal path had worked for months. The loss came from the seam between them, where a harmless convenience in one contract became a wildcard in another because nobody asked who owned the position. If your protocol wraps staking, vaults or any external system with "magic" inputs, talk to our team or check our audit pricing to get those integration boundaries reviewed before someone else reviews them for you.

Premia Exploit: Empty Option Pools Drained Six Vaults

PandaSecurity — Sun, 01 Nov 2026 23:07:43 +0000

Originally published at Premia Exploit: Empty Option Pools Drained Six Vaults

On 1 November 2026, an attacker emptied six Premia v3 underwriter vaults on Arbitrum in two transactions sent one second apart. The vaults lost 3.644 WBTC, 43.47 WETH, 48,479 USDC.e and 46,215 ARB, which The Defiant valued at about $437,000. Blockaid flagged the attack while it was still running and described the method in one sentence: the attacker created empty option pools, flash-loaned capital, bought options so that vault collateral was locked into those pools, and then withdrew that collateral as liquidity.

No key was stolen and no oracle was bent. The vaults did what their code allowed: they underwrote options in markets that the attacker had created a minute earlier. This post walks through what Premia's vaults do, what the chain shows, what is still unknown, and what builders and auditors of options and structured-product vaults should take from it.

TL;DR

Protocol: Premia v3, an options protocol. Affected contracts: six "Short Volatility" underwriter vaults (WBTC, WETH and ARB calls and puts).
Chain: Arbitrum One.
Loss: 3.64410382 WBTC, about 43.47 WETH, 48,479.36 USDC.e and 46,215.43 ARB in net outflows, about $437K (The Defiant). Blockaid's mid-attack estimate was about $400.5K; PeckShield reported about $464.6K.
Method (as reported by Blockaid): permissionlessly create empty option pools, borrow working capital from Balancer, buy options from the vaults so their collateral moves into those pools, then take the collateral out as liquidity.
Root cause: not yet confirmed by Premia. The evidence points at the trust boundary between the vaults and pools that anyone can deploy.
Funds: PeckShield reported the proceeds were bridged to Ethereum and swapped to BTC through Chainflip and NEAR Intents.

What Premia v3 Vaults Do

Premia v3 splits options trading into two layers. Pools are per-series markets: one pool per base/quote pair, strike, maturity and call/put flag, deployed through a factory. Anyone can create a new series. Underwriter vaults sit above the pools. Depositors put a single asset into a vault, and the vault uses it as collateral to sell (write) options to buyers, collecting premiums in return. A call vault holds the base asset (WBTC, WETH or ARB); a put vault holds USDC.e.

When a buyer trades with a vault, the vault writes options into the matching pool. Writing an option means locking collateral in that pool so the buyer can be paid if the option ends in the money. That collateral leaves the vault's balance sheet and sits in the pool until the series settles.

This design is common. It is also exactly where an attacker would look first: the vault holds real deposits, and it will move them into a pool contract on request, provided the trade passes the vault's checks. If those checks treat every factory-deployed pool as a legitimate market, the security of depositors' money depends on how a brand-new, empty pool behaves.

What Happened On-Chain

We read the blocks and receipts directly from a public Arbitrum node. The sequence is short.

Setup, 03:14:37 UTC, block 520,166,285. The attacker address 0xbeBa8CEfD0D75d747C5AD966Dc17C0Bb60D84dBd called its contract 0x577168C8c6fA937495C3D6961f1d7D734b2d785f (transaction 0xe3c263fc...31f5). Reporting relayed by KuCoin News says this transaction created the six option-pool contracts used later.
First drain, 03:15:39 UTC, block 520,166,479 (0x64602cbb...41ac). The attack contract borrowed tokens from the Balancer Vault, including 0.9 WBTC, 11 WETH and 6,000 USDC.e. Option tokens with names such as WBTC-USDC-06NOV2026-78000-C and WETH-USDC-06NOV2026-2200-P were minted and burned, collateral moved from the vaults into the new pools and then on to the attack contract, and Balancer was repaid.
Second drain, 03:15:40 UTC, block 520,166,483 (0xd7e8086d...44ff). Same sender, same contract, same selector. This one borrowed 12,000 ARB and 9,500 USDC.e and repeated the pattern against the ARB vaults.

Both drain transactions succeeded, and each produced close to 400 log entries. Summing only the ERC-20 transfers into and out of the six vault addresses across both transactions gives these net outflows:

Vault	Asset	Net outflow
WBTC call	WBTC	3.644104
WETH call	WETH	43.472546
ARB call	ARB	46,215.428616
WBTC put	USDC.e	20,215.067131
WETH put	USDC.e	21,333.613826
ARB put	USDC.e	6,930.677768

The three put vaults together lost 48,479.36 USDC.e, which matches The Defiant's figure exactly. After the attack, the WBTC call vault held about 0.00087 WBTC and the put vaults between about 45 and 126 USDC.e. By TVL, that is most of what Premia v3 had on Arbitrum: DefiLlama showed roughly $533K just before the attack.

The flash loans were only working capital. They were repaid inside the same transactions. The profit came entirely from depositor collateral.

Coindaro also found ten smaller outflows from the same vaults over the next two hours, worth about $16K in total, from other addresses. Who sent them is not known; they may be copycats, the same actor or a rescue effort. They are not included in the figures above.

Root Cause: Vaults That Trust Any Pool

Premia has not published a post-mortem, so the precise vulnerable function is not confirmed. What is public is enough to describe the shape of the bug.

The key ingredients are:

Permissionless markets. The attacker deployed the six fresh pools, all with a 6 November 2026 expiry.
A vault willing to underwrite into them. The vaults accepted trades against those new series and locked their own collateral there.
A pool that let that collateral leave. Once inside a pool that only the attacker had touched, the collateral came back out to the attacker's contract as if it were the attacker's own liquidity.

In other words, the vault's assumption was "a pool deployed by our factory is a safe place for our collateral". That only holds if every state a pool can be in, including empty, first-trade and single-participant states, keeps the vault's collateral attributed to the vault. An empty pool is the most extreme edge case there is: the attacker is the only other counterparty, sets the opening conditions, and can sequence every step inside one transaction.

The snippet below is a simplified, hypothetical illustration of that trust pattern. It is not Premia's code.

// SIMPLIFIED ILLUSTRATION - not Premia's actual implementation
function trade(PoolKey calldata key, uint256 size, uint256 maxPremium) external {
    // Any pool the factory can derive is treated as a valid market
    address pool = factory.getPoolAddress(key);
    require(pool != address(0), "no pool");
    require(_isValidListing(key), "bad strike or maturity");

    uint256 premium = _quote(key, size);
    require(premium <= maxPremium, "slippage");
    asset.safeTransferFrom(msg.sender, address(this), premium);

    // Vault collateral leaves the vault and is locked in the pool
    uint256 collateral = _collateralFor(key, size);
    asset.approve(pool, collateral);
    IPool(pool).writeFrom(address(this), msg.sender, size);

    // From here on, the vault relies entirely on the pool's accounting
    // to keep that collateral attributed to the vault.
}

Nothing in this sketch is obviously wrong in isolation. Strike and maturity are checked, the premium has a slippage bound, and the pool is a genuine factory deployment. The problem is the last comment. If pool-side accounting can be steered by whoever created the pool, especially when the pool has no other liquidity, a vault-level check that only asks "is this a real pool?" offers no protection.

Why Brand-New Markets Are Dangerous

The Premia case joins a long list of exploits where the first moments of a contract's life were the weak point. Empty ERC-4626 vaults are vulnerable to share inflation. Fresh lending markets have been drained through rounding on the first deposit. And a flash loan let an attacker dictate a thin pool's spot price for one transaction in the KolanHook exploit.

Empty markets are dangerous for three reasons:

The attacker is the whole market. No other liquidity providers or traders constrain prices, balances or ordering.
Edge-case arithmetic is live. Zero totals, first-position branches and division by small numbers are paths that normal tests rarely exercise with hostile inputs.
Atomicity removes risk. With a flash loan, the attacker can create conditions, extract value and repay inside one transaction, so failure costs only gas.

There is also an operational angle. Premia's team now builds Kyan, its newer platform, but the v3 contracts were still live and still held deposits. As we saw last week with the Troves legacy rebalancer, code a team has stopped watching keeps running for as long as it holds funds.

Lessons for Builders and Auditors

1. Allowlist the markets a vault may underwrite. Composability is great for traders and dangerous for pooled collateral. A vault that holds depositors' assets should only write into pools that governance or a curator has approved, or at minimum into pools that meet liquidity, age and parameter requirements. "Deployed by our factory" is not a risk check.

2. Treat pool creation as an attacker capability. In threat models for permissionless factories, assume the attacker deploys the pool, chooses its parameters and is the only counterparty. Every function a vault calls on a pool should be reviewed under that assumption.

3. Verify collateral attribution end to end. After a vault writes into a pool, write invariant tests that check the vault's claim on that collateral cannot fall unless an option is exercised against it. Fuzz the sequences create pool, trade, add or remove liquidity, settle, all from one actor and inside one transaction.

4. Cap per-market and per-block exposure. Six vaults lost almost everything within one second. Limits on how much collateral can enter a single new series, or how much a vault can underwrite per block, would have bounded the damage even with the underlying bug present.

5. Sunset old deployments deliberately. When a protocol moves to a new version, either wind down the old vaults, pause new underwriting, or keep monitoring and bug-bounty coverage in place. Our smart contract security checklist covers the monitoring side of this.

6. Monitor for the pattern, not just the loss. A single address creating several pools and then trading against vaults in the next minute is an unusual sequence. Alerts on new-series creation followed by large vault trades can buy time for a pause.

What Is Still Unknown

The exact vulnerable function. Blockaid's description fits either a vault-side or a pool-side flaw; no one has publicly pinned it to a specific line of code.
The final loss figure. $400.5K (Blockaid, during the attack), about $437K (The Defiant, net collateral at prices around 04:16 UTC) and $464.6K (PeckShield) measure different things and should not be added together.
Premia's response. At the time of writing we found no official statement, post-mortem, pause notice or bounty offer.
The later outflows. The ten smaller withdrawals reported by Coindaro are not attributed.

Key Addresses and Transactions

Item	Value
Attacker address (tx sender)	`0xbeBa8CEfD0D75d747C5AD966Dc17C0Bb60D84dBd`
Attack contract	`0x577168C8c6fA937495C3D6961f1d7D734b2d785f`
Setup tx (block 520,166,285)	`0xe3c263fcae544954367998e48e13112875cfd38a3b9a240e7818bb96313831f5`
Drain tx 1 (block 520,166,479)	`0x64602cbbeba5d3c7a5e2cff4f98cc118886fc6051c56fa50458abec2c90441ac`
Drain tx 2 (block 520,166,483)	`0xd7e8086df0570c5389ca27eb9bcdff290e810c094155b410a42e5bad2b3244ff`
WBTC call vault	`0x45dF5EA836A15B561937Ae8373ab9eE984aea531`
WETH call vault	`0xbae43c546DFADC69576aE73C68e0694A54F08e1B`
ARB call vault	`0xDC631d88dbB5eb39f5c4Bf8B4e5298d098912fFf`
WBTC put vault	`0x6A1FC0E1c60BA6564CDe4910A425F1F1a1d18C1F`
WETH put vault	`0xD46993F25D298ebbCD31E941156C66f7e628A52a`
ARB put vault	`0xBe3E229319f86f5ee96ee1dc0b6d55e8b68a439e`

Sources

Blockaid on X: live exploit alert: method description and the ~$400.5K mid-attack estimate
Arbiscan: first drain transaction and second drain transaction
The Defiant via Cryptonews.net: attacker drains about $437,000 from Premia vaults: per-asset net outflows and post-attack balances
Coindaro: six Arbitrum vaults lose about $437,000: block numbers, vault addresses, flash-loan amounts and later outflows
0xCERT-2026-0297 advisory: PeckShield's $464.6K figure and the Chainflip / NEAR Intents exit route
TSN: Premia exploit drains six Arbitrum options vaults
Arbitrum blocks and transaction receipts read from the public Arbitrum One RPC: timestamps, senders, status and ERC-20 transfer totals

Closing Thoughts

The Premia exploit did not need a price oracle, a stolen key or a novel cryptographic trick. It needed a vault that would put real collateral into a market nobody else had ever used. If your protocol lets anyone create markets and lets pooled capital flow into them, the empty-market case is your threat model, not an edge case. If you are building vaults, options or any permissionless market factory, talk to our team or see our audit pricing to have those trust boundaries reviewed before an attacker reviews them for you.

Troves Exploit: A Retired Rebalancer Drained 8.57 WBTC

PandaSecurity — Sat, 31 Oct 2026 23:10:37 +0000

Originally published at Troves Exploit: A Retired Rebalancer Drained 8.57 WBTC

On 31 October 2026, an attacker removed about 8.57 WBTC-equivalent from the Troves xWBTC/WBTC vault on Starknet. Community estimates put the loss at roughly $660K. The incident landed in the same week as the Binance hot wallet theft and got far less attention, but for anyone who builds or audits upgradeable DeFi systems it is arguably the more instructive of the two. Troves says the attack went through a legacy rebalancing contract that kept its permissions after it had been replaced.

No novel cryptography, no compromised key, no oracle failure. Just an old contract that was supposed to be retired and was still trusted.

This post walks through what the vault does, what the on-chain transaction shows, why stale permissions are such a common failure, and what teams should change in their deployment and decommissioning process.

TL;DR

Protocol: Troves (formerly STRKFarm), a vault-based yield platform on Starknet.
Affected vault: the Ekubo xWBTC/WBTC vault (on-chain name tEkubo xWBTC/WBTC). Troves says no other vault was affected.
Chain: Starknet mainnet.
Loss: about 8.57 WBTC-equivalent per Troves' on-chain message; Troves' first public update said about 8.6 BTC.
Root cause (per Troves): a legacy rebalancing contract retained permissions over the vault after being replaced.
Response: Troves revoked the contract permissions, paused affected and potentially exposed vaults, and offered a 1 WBTC whitehat bounty open until 3 November 2026, 23:59 UTC.

What Troves Is

Troves is a Starknet yield platform that packages multi-step DeFi strategies into vaults. Users deposit once, and the vault handles lending, liquidity provision and rebalancing for them. According to Troves' own documentation, the vault owners are access control contracts with separate roles for operations such as rebalancing, deposits and withdrawals, and the super admin of that access control is a timelock.

The affected product was a concentrated liquidity vault that provides liquidity to the Ekubo xWBTC/WBTC pool. xWBTC is Endur's liquid staked BTC token, and WBTC is wrapped bitcoin. Because the two assets should trade close to a fixed ratio, the vault concentrates liquidity in a narrow range and needs periodic rebalancing to stay in range. That rebalancing is the job of a privileged contract.

Rebalancing logic tends to change over time. Teams ship a new strategy, a new router or a new rebalancer, point the vault at it, and move on. The question that matters for this incident is what happens to the old one.

What Happened On-Chain

Troves' on-chain message to the attacker names the exploit transaction:

0x0634307777205294f636d481808a7b9a9e208415a26dd19c8ada269b9332e330

We pulled the receipt from a public Starknet RPC. The transaction was included in block 17,220,375 with a block timestamp of 31 October 2026, 08:25:21 UTC, and it executed successfully. Its sender is the account 0x42dc2ebccae3e55ce3747d2974c801fb3e0facf8d7f4810012a0986a89da5e3, which made a single call into a helper contract at 0x13705ea5f9e591ff6ffe3926bf22fceb19317c049838de09750a60259d38c72.

Reading the token transfer events in order gives a clear outline of the attack, even before Troves publishes a full post-mortem:

Flash loan. The helper contract receives exactly 10 WBTC from 0x3976cac2...d24124 at the start of the transaction, and sends exactly 10 WBTC back to the same address near the end. That is the shape of a flash loan.
Swaps through Ekubo and a routing contract. The borrowed WBTC is pushed through the Ekubo core contract via a router that skims a 0.1% fee on each leg, and an Ekubo position NFT is minted to the helper.
Vault funds move. The vault contract (tEkubo xWBTC/WBTC, 0x2ea99b49...4380a) receives about 9.43 WBTC out of Ekubo, which looks like its liquidity being pulled from the position, and then sends about 9.38 WBTC to a separate contract at 0x2e0af295...184067, which forwards almost all of it straight back into Ekubo. Shortly after, a similar amount of WBTC leaves Ekubo towards the attacker's route. Depositors' liquidity is being moved and traded inside a transaction the attacker controls.
Exit. The helper ends up with more WBTC than it borrowed, repays the 10 WBTC loan, and transfers about 6.32 WBTC to the attacker's account.

We are deliberately careful here. Troves has not yet published which function the legacy contract exposed, or confirmed which address in the trace is the legacy rebalancer, so we do not assert it. The difference between the 6.32 WBTC that reached the sender in this one transaction and the 8.57 WBTC-equivalent Troves reports may come from other assets, other transactions or price conversion, and should be read against Troves' post-mortem when it is released.

Troves' founder said on X that the exploit was contained within about 40 minutes. Troves' first public statement followed at 14:45 UTC the same day.

Root Cause: Permissions That Outlived Their Contract

The one-line root cause Troves gave is the most important part of the story: the legacy rebalancing contract retained permissions after being replaced.

In a role-based setup, a vault trusts certain addresses to call sensitive functions such as "move liquidity", "swap", "withdraw from position" or "deposit into position". When a team upgrades its rebalancing logic by deploying a new contract and granting it the role, the old contract keeps that role unless someone explicitly revokes it. Nothing breaks. Monitoring sees a healthy vault. The new rebalancer works. And the old one sits there, still trusted, running code that nobody is reviewing any more.

The danger depends on what the old contract exposes. If it has any function that:

can be called by anyone, or by any address that passes a weak check,
triggers privileged vault actions, and
lets the caller influence prices, amounts or destinations,

then whoever finds it can make the vault act against its own depositors.

Here is a simplified, illustrative Solidity sketch of the pattern. It is not Troves' code, which is written in Cairo, and it is not the exploited function:

// Simplified illustration only. Not the Troves contract.
contract LegacyRebalancer {
    IVault public immutable vault;

    // Originally assumed to be called only by a keeper bot,
    // but never restricted on-chain.
    function rebalance(uint256 amount, bytes calldata swapData) external {
        // The vault trusts this contract via REBALANCER_ROLE.
        vault.withdrawLiquidity(amount);
        _swap(swapData);              // caller-controlled route and limits
        vault.depositLiquidity();
    }
}

// Upgrade day:
// accessControl.grantRole(REBALANCER_ROLE, address(newRebalancer));
// Missing:
// accessControl.revokeRole(REBALANCER_ROLE, address(legacyRebalancer));

If rebalance lets the caller pick the swap route or the slippage limit, a flash loan is enough to move the pool price, have the vault rebalance at that bad price, and capture the difference. We saw a close relative of this pattern in the KolanHook Uniswap v4 exploit, where a permissionless trigger forced a buyback with no meaningful price limit.

Why This Keeps Happening

Stale permissions are one of the most common findings we see in real audits, and they are one of the hardest to catch with a code review alone, because the bug is not in the code that is in scope. It is in the deployment state.

A few recurring reasons:

Audits are scoped to new code. The new rebalancer is reviewed. The old one was reviewed months ago under different assumptions, and nobody re-checks what it can still do.
Roles are additive. Granting a role is part of the upgrade script. Revoking the old one is a separate step that is easy to forget, especially if revocation must go through a timelock.
"Legacy" is not a state on-chain. A contract that a team considers retired is, from the chain's point of view, identical to an active one until its rights are removed.
Off-chain assumptions decay. A function that was "only ever called by our keeper" was safe while the keeper was the only caller that knew about it. That is not access control.

We covered a near-identical failure on Avalanche, where a Safe kept a stale approval to an address that later had code deployed to it. The asset and chain were different, the lesson was the same: trust that is never revoked eventually gets used by someone else.

Lessons for Builders and Auditors

Treat decommissioning as a deployment

Every upgrade script that grants a role to a new contract should revoke it from the old contract in the same governance action, and tests should assert that the old address no longer holds the role. If the revocation needs a timelock, queue it together with the grant.

Keep an on-chain inventory of privileged addresses

Maintain a list of every address holding each role, generated from chain state rather than from documentation. Review it on every release. Role enumeration is cheap; an unexplained entry is a finding.

Audit the permission graph, not only the contracts

When you scope an audit, include every contract that currently holds a privileged role on the in-scope system, even if it is "old". Our smart contract security checklist includes access control and role management items that apply directly here.

Never let a caller choose price limits on vault funds

Any path that swaps or rebalances vault liquidity should enforce slippage bounds derived from a trusted price source, not from caller input or the current spot price alone. That single control turns a flash loan attack from profitable into pointless.

Make retired contracts inert

Where possible, give contracts an explicit kill switch that a guardian can trip on retirement, so that even if a role is forgotten the code path reverts.

Monitor for unusual privileged calls

Alert on any call into a privileged vault function from a contract other than the current, expected one. In this incident the trigger was a contract the team had already moved away from, which is exactly the kind of caller an allowlist-based alert would flag.

Key Addresses and Transactions

Item	Value
Exploit tx (Starknet block 17,220,375)	`0x0634307777205294f636d481808a7b9a9e208415a26dd19c8ada269b9332e330`
Attacker account (tx sender)	`0x42dc2ebccae3e55ce3747d2974c801fb3e0facf8d7f4810012a0986a89da5e3`
Attacker helper contract	`0x13705ea5f9e591ff6ffe3926bf22fceb19317c049838de09750a60259d38c72`
Troves xWBTC/WBTC vault (`tEkubo xWBTC/WBTC`)	`0x2ea99b4971d3c277fa4a9b4beb7d4d7d169e683393a29eef263d5d57b4380a`
WBTC on Starknet	`0x3fe2b97c1fd336e750087d68b9b867997fd64a2661ff3ca5a7c771641e8e7ac`
Troves recovery address (Ethereum)	`0x91926046e148c66869d71B9Fa37306e82DDc8934`

Sources

Troves on X: incident statement: loss of about 8.6 BTC, legacy rebalancing contract, permissions revoked, vaults paused
Defimon Alerts on X: Troves on-chain message to the attacker: 8.57 WBTC-equivalent, exploit transaction hash, 1 WBTC bounty and deadline
Troves founder on X: containment within about 40 minutes
Telem News: Troves xWBTC/WBTC vault exploited for 8.57 WBTC
Troves docs: Vesu Fusion rebalancing vaults: role-based access control and timelocked super admin
Starknet transaction receipt for 0x0634...e330, read from a public Starknet RPC node: block number, timestamp and transfer events

Closing Thoughts

The Troves incident is small next to this week's headline losses, but its root cause is one almost every protocol carries in some form: a contract the team stopped thinking about that the chain still trusts. Upgrades are not finished when the new code works; they are finished when the old code can no longer do anything. If you are planning an upgrade, a migration or a vault launch, talk to our team or check our audit pricing to have the full permission graph reviewed, not just the new files.

Binance Hack: How EIP-7702 Delegation Emptied a Hot Wallet

PandaSecurity — Fri, 30 Oct 2026 23:55:53 +0000

Originally published at Binance Hack: How EIP-7702 Delegation Emptied a Hot Wallet

On 29 October 2026, hot wallets belonging to Binance paid out to an attacker across several blockchains within roughly half an hour. Binance puts the total impact at about $6.3 billion; Chainalysis counts about $6.4 billion, which would make it the largest theft in crypto history. Most legs of the attack were ordinary signed transfers. The Ethereum leg was different: the attacker used EIP-7702 to make one of Binance's busiest Ethereum hot wallets, labelled Binance 14 on Etherscan, run the attacker's own contract code. Less than four minutes later, about 167,464 ETH and 63 tokens left that wallet in a single transaction.

No smart contract bug was exploited and no signature was forged. That is exactly why this incident matters to anyone who builds wallets, custody systems or contracts that interact with EOAs. This post walks through what happened on-chain, why EIP-7702 changes the blast radius of a signing compromise, and what to take away from it.

TL;DR

Victim: Binance hot wallets on multiple chains; on Ethereum, Binance 14 (0x28C6c062...1d60) was delegated, while Binance 16 sent plain transfers.
Total impact: about $6.3B according to Binance, about $6.4B according to Chainalysis. Around $3B has been frozen by stablecoin issuers and partners.
Ethereum mechanism: one type-4 transaction carried 50 valid EIP-7702 authorizations, all signed by Binance 14, all pointing the wallet at an attacker-deployed sweeper contract.
Root cause (per Binance's initial investigation): a compromised DevOps engineer's laptop gave the attacker access to a service container that could submit withdrawal transactions. Binance says it found no evidence of a private key leak, and co-CEO Richard Teng later said the delegation did not pass through the exchange's normal approval controls.
Duration: the malicious delegation stayed active for nearly four hours, until Binance 14 cleared it at 00:10:35 UTC on 30 October.

A Quick Refresher on EIP-7702

EIP-7702 went live on Ethereum mainnet with the Pectra upgrade in May 2025. It adds a new transaction type (type 4, "set code") with an authorizationList. Each entry is a tuple of (chainId, address, nonce) signed by an EOA. When the transaction is processed, the EOA's code is set to a small delegation designator, 0xef0100 followed by the target address. From then on, any call to the EOA executes the target contract's code in the context of the EOA: its balance, its storage, its token holdings and every permission it holds elsewhere.

Three properties are important here:

Anyone can submit the authorization. The signer does not need to send the type-4 transaction itself. A third party can carry a signed tuple on-chain and pay the gas.
The authorization is bound to the account nonce. A tuple only applies if its nonce equals the authority's current nonce at processing time.
The authorization carries no amount and no recipient. It does not say "send X to Y". It says "run this code", which can mean "send everything to whoever asks".

In other words, signing a 7702 authorization is closer to handing over the account than to approving a payment.

What Happened on Ethereum

All times below are block timestamps in UTC. Transaction details were checked against an Ethereum RPC node and matched against independent write-ups listed in the Sources section.

Preparation: Tooling Deployed Hours Earlier

The attacker's operator account, 0x7c8601d4...5ca0, was reportedly funded through Tornado Cash. On-chain analyses by Tibane Labs and an IMD incident report show it deploying a first sweeper version early on 29 October and testing it on fresh EOAs it controlled. At about 16:00 UTC it deployed the sweeper used against Binance, 0x63e842b0...6fae, and ran a final test delegation and sweep on another of its own wallets. In other words, the tooling was rehearsed and ready hours before the attack.

According to Tibane Labs' decompilation, every function in the sweeper checks that the caller is the hard-coded operator address. Its main entry points are a sweep(to, tokens[]) function that sends all ETH and the full balance of each listed token, and an execute(target, value, data) function that makes an arbitrary call.

20:20:59: Fifty Authorizations in One Transaction

At block 26,300,753, the operator sent type-4 transaction 0xad99264d...298b to Binance 14. Its authorization list contains 50 tuples, all delegating to the sweeper 0x63e842b0...6fae, with consecutive nonces from 18,914,775 to 18,914,824. Independent analysts recovered the signer of every tuple and found that all 50 were signed by Binance 14's own key.

Why fifty? Binance 14 is an extremely busy withdrawal wallet that sends transactions almost every block, so its nonce never sits still. A single authorization would very likely be stale by the time it landed. By obtaining signatures for a whole window of upcoming nonces, the attacker made sure exactly one of them would match whatever nonce the wallet had when the transaction was included. The rest were simply skipped as invalid, which EIP-7702 allows without reverting the transaction.

Tibane Labs notes that Binance 14 itself used nonce 18,914,775 about three minutes before the delegation landed. Nobody signs an authorization for a nonce that is already spent, so the batch appears to have been produced live, on demand, rather than taken from an old leak.

20:24:23: One Call Sweeps the Wallet

At block 26,300,770, the operator called Binance 14 directly with transaction 0x53bd38b8...e2f3. Because Binance 14 was now delegated, the call ran the sweeper's sweep function (selector 0x8a179be4) as Binance 14. The recipient argument in the calldata is 0x5227f603...2f8c. In that single transaction, about 167,464 ETH and 63 tokens, including roughly 1.6 billion USDT according to CoinDesk, moved to the attacker.

Twenty-four seconds later, Binance 16 sent the same attacker address 28,005.6 ETH and several tokens through ordinary signed transfers, with no delegation involved. Together, the two wallets lost roughly 200,000 ETH.

The execute() Path: More Than a Balance

A delegated EOA does not only expose its own balance. It exposes every role, allowance and admin right that address holds. According to TRM Labs (via CoinDesk) and Tibane Labs, Binance 14 also had control over a separate Binance smart-contract wallet holding USDC, an EIP-1967 proxy. Through the sweeper's execute function, the attacker made Binance 14 instruct that contract to release 823 million USDC (780M and 43M in two calls) to the attacker. Circle later froze those funds.

Nearly Four Hours of Live Delegation

The delegation did not expire by itself. Binance's normal systems kept routing deposits and rebalancing flows into Binance 14, and the attacker swept them again at around 21:04 and 21:44 UTC, according to CoinDesk. Only at 00:10:35 UTC on 30 October (block 26,301,896) did Binance 14 send itself a type-4 transaction, 0xafbf94c9...7209, with a single authorization to the zero address. That clears the delegation designator, and the wallet's code returned to empty.

Clearing the code removes the attacker's program, but it does not rotate the key. Anyone who can still sign for the account at its current nonce could install a new delegation.

Root Cause: A Signing Compromise, Amplified by 7702

It is tempting to call this an "EIP-7702 exploit", but the chain data does not show a flaw in EIP-7702 itself. Binance's announcement states that the incident may involve a compromised DevOps engineer's laptop that let the attacker reach a service container and submit unauthorized withdrawal transactions, and that it found no evidence of a wallet private key leak. In a later video update, Teng said investigators had found additional points of breach and that the EIP-7702 delegation did not pass through Binance's normal approval controls.

That combination explains the on-chain picture. Hot wallets on many chains signed for the attacker within the same half hour, some with plain transfers and one with a batch of 7702 authorizations. The common factor is the signing layer. A service that is trusted to produce signatures will sign whatever reaches it in a shape it accepts.

What 7702 changed is the shape of what could be signed. A withdrawal policy that inspects recipients and amounts has nothing to inspect in an authorization tuple: there is no recipient and no amount, only a code address. If the signing pipeline treated a type-4 authorization as just another message, the controls built for transfers never had a chance to fire.

A Simplified Version of the Pattern

The snippet below is simplified and illustrative. It is not the attacker's bytecode; it shows why a delegated EOA is fully exposed once an attacker-controlled contract becomes its code.

// SIMPLIFIED, illustrative only
interface IERC20 {
    function balanceOf(address) external view returns (uint256);
    function transfer(address, uint256) external returns (bool);
}

contract Sweeper {
    address immutable operator; // stored in code, not in the EOA's storage

    constructor(address op) { operator = op; }

    // Runs with address(this) == the delegated EOA
    function sweep(address to, address[] calldata tokens) external {
        require(msg.sender == operator, "not operator");
        for (uint256 i; i < tokens.length; i++) {
            if (tokens[i] == address(0)) {
                payable(to).transfer(address(this).balance);
            } else {
                IERC20 t = IERC20(tokens[i]);
                t.transfer(to, t.balanceOf(address(this)));
            }
        }
    }

    // Anything the EOA is allowed to do elsewhere, the operator can now do
    function execute(address target, uint256 value, bytes calldata data) external {
        require(msg.sender == operator, "not operator");
        (bool ok, ) = target.call{value: value}(data);
        require(ok, "call failed");
    }
}

The key line is the comment on sweep: once delegated, address(this) is the victim wallet, so balanceOf(address(this)) and msg.sender checks in downstream contracts all see the victim.

Lessons for Builders and Auditors

For Custody and Signing Infrastructure

Treat 7702 authorizations as a separate, highest-risk signing class. They should never share a code path with withdrawals. If a hot wallet has no business delegating, the signer should refuse type-4 authorizations outright.
Allowlist delegation targets. If delegation is needed, only sign tuples whose address is a known, audited implementation, and require multi-party approval for that list.
Watch for nonce windows. A request to sign many authorizations for consecutive future nonces is a strong anomaly signal on its own.
Monitor code on hot wallets. An alert on eth_getCode(hotWallet) != 0x would have flagged this within one block instead of nearly four hours later.
Stop routing funds into a wallet you are investigating. Automated deposit and rebalancing flows kept feeding Binance 14 while it was compromised.

For Smart Contract Developers

Do not assume an EOA is "just a key". After Pectra, any EOA can carry code. Checks such as tx.origin == msg.sender or extcodesize == 0 no longer prove a caller is a simple wallet.
Minimise privileges held by hot EOAs. Binance 14's control over a separate USDC wallet turned one compromise into a second, $823M loss. Admin roles and large allowances belong to cold, multi-signature accounts, not to withdrawal wallets.
Review delegation targets like any other contract. If your product asks users to sign 7702 authorizations, the delegate contract is now part of your attack surface and deserves a full audit.

We covered related signing and approval failures in our analyses of the Argent-style wallet recovery replay and the Avalanche Safe stale approval exploit. Our smart contract security checklist includes items on privileged roles and caller assumptions that apply directly here.

Response and Current Status

Binance suspended withdrawals, revoked the affected address authorization, engaged law enforcement, and says it will cover all losses from its SAFU fund and company funds. Teng said Binance has reserved more than $6.34 billion and aims to reopen withdrawals by Sunday, 1 November, with a full proof-of-reserves report targeted for Monday, 2 November. Tether, Circle and other issuers froze a large share of the stolen stablecoins. Chainalysis and TRM Labs attribute the theft to the North Korea-linked group TraderTraitor; Binance has not published a final post-mortem yet, so details of the initial access may still change.

Key Addresses and Transactions

Item	Value
Binance 14 (victim, delegated)	`0x28C6c06298d514Db089934071355E5743bf21d60`
Attacker operator	`0x7c8601d4645b93cea45f71e118a729332e6b5ca0`
Sweeper contract	`0x63e842b054bd624a465454d533c33f573e9c6fae`
Attacker receiving address	`0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c`
Delegation tx (block 26,300,753)	`0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b`
First sweep tx (block 26,300,770)	`0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3`
Revocation tx (block 26,301,896)	`0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209`

Sources

Binance: Security Incident Update (2026-10-30): initial findings, impact estimate, response
CoinDesk: How one Ethereum permission let an attacker drain $2.5 billion from Binance: timeline, nonce window, amounts
CoinDesk: Binance discovers multiple breach points: Teng's update on approval controls
Decrypt: Binance sets aside $6.34B to cover hack losses: reimbursement and attribution
Chainalysis: Binance hack findings: total, freezes and attribution
Tibane Labs: Binance hack on-chain analysis: signer recovery, sweeper functions, multi-chain timeline
Maborak: Binance 14's EIP-7702 revocation, checked on-chain: revocation transaction
EIP-7702 specification

Closing Thoughts

The Binance theft is a reminder that the most powerful thing a key can sign is no longer a transfer. Since Pectra, one signature can replace an account's behaviour entirely, and every system that signs on behalf of an EOA needs controls that understand that. If you are building custody flows, smart accounts or contracts that rely on caller assumptions, talk to our team or check our audit pricing to get a review before an attacker does it for you.

zkLink Nova Exploit: A Stale Transient Hash Forged a Root

PandaSecurity — Thu, 29 Oct 2026 23:05:39 +0000

Originally published at zkLink Nova Exploit: A Stale Transient Hash Forged a Root

At 22:21:35 UTC on 28 October 2026 (Ethereum block 26,294,188), a single transaction emptied the Ethereum escrows of zkLink Nova, an aggregated rollup. The attacker walked away with 22.43 ETH plus 11 ERC-20 tokens, led by about 245.74 pufETH. Security firms priced the haul at roughly $743K to $805K depending on the pricing source; BlockSec Phalcon put it at about $780K and SlowMist at about $783.1K.

No key was stolen and no signature was forged. The attacker wrote their own Merkle root into the bridge and then withdrew against proofs they had built themselves. Two small design decisions in one contract made that possible: a transient-storage hash that was never cleared, and a privileged function that called whatever target its caller supplied.

TL;DR

Protocol: zkLink Nova, an aggregated rollup with escrows on Ethereum and several other chains.
Chain: Ethereum mainnet. Follow-on attacks were reported on other chains (see below).
Loss on Ethereum: 22.43 ETH and 11 ERC-20 tokens, roughly $780K by most estimates.
Root cause: Arbitrator.claimMessage() checked a transient finalizeMessageHash that it never reset, and it executed a caller-supplied target and calldata under the Arbitrator's own trusted identity.
Entry point: SyncL2TxHashRelayer, a whitelisted relayer contract that anyone can call.
Response: zkLink suspended block production on Nova, emergency-patched the affected contracts and temporarily disabled withdrawals.

How zkLink Nova Moves Batch Roots

Each zkLink Nova escrow stores Merkle roots of L2-to-L1 message logs, one per batch. A withdrawal on L1 is valid if its Merkle proof matches the stored root for that batch. In other words, whoever can write a root can approve any withdrawal they like.

Roots do not arrive directly. They travel through a relay chain that looks like this on Ethereum:

A relayer calls the Arbitrator, a cross-chain message router gated by onlyRelayer.
The Arbitrator claims a message from a source chain's canonical message service (for Nova, Linea's L1MessageService).
During that claim, the source chain's gateway calls back into Arbitrator.receiveMessage(), which records a hash of what was genuinely delivered.
The Arbitrator checks that hash and forwards the message to destination gateways, such as the EthereumGateway.
The EthereumGateway, gated by onlyArbitrator, calls ZkLink.syncBatchRoot(), gated by onlyGateway, which writes the root.

Every hop trusts the hop before it purely by msg.sender. That chain of trust is only as strong as the Arbitrator's guarantee that it forwards nothing it did not genuinely receive.

Root Cause: Two Flaws in claimMessage

The relevant code is public in zkLink's zklink-evm-contracts repository. The function signature makes the first problem visible:

function claimMessage(
    address _sourceChainCanonicalMessageService, // chosen by the relayer
    bytes calldata _sourceChainClaimCallData,    // chosen by the relayer
    IL1Gateway _sourceChainL1Gateway,
    uint256 _receiveValue,
    bytes calldata _receiveCallData,
    bytes calldata _forwardParams
) external payable nonReentrant onlyRelayer whenNotPaused

Flaw 1: An Arbitrary Call With a Trusted Identity

claimMessage performs Address.functionCall(_sourceChainCanonicalMessageService, _sourceChainClaimCallData). Both the target and the calldata come from the caller. Because the call originates from the Arbitrator, the callee sees msg.sender == Arbitrator, which is exactly the identity that every gateway's onlyArbitrator modifier trusts.

So if the "canonical message service" is set to the EthereumGateway itself, and the calldata is sendMessage(...) wrapping syncBatchRoot(...), both access checks pass. The gateway believes the Arbitrator asked it to forward a root, and ZkLink believes its gateway delivered one.

Flaw 2: A Validation Hash That Outlives Its Claim

The only thing standing between that arbitrary call and a forged root is a check that runs after it:

bytes32 _finalizeMessageHash;
assembly { _finalizeMessageHash := tload(finalizeMessageHash.slot) }
require(
    _finalizeMessageHash ==
        keccak256(abi.encode(_sourceChainL1Gateway, _receiveValue, _receiveCallData)),
    "Incorrect finalize data"
);

finalizeMessageHash lives in EIP-1153 transient storage. It is written by receiveMessage() when a registered gateway delivers a real message. Transient storage is scoped to the whole transaction, not to a single call. The Arbitrator never reset the slot after the check.

That turns the check into a much weaker statement. It no longer says "a genuine delivery happened during this claim". It says "a genuine delivery with these parameters happened at some point earlier in this transaction". Once one real claim arms the slot, any later claim in the same transaction that repeats the same gateway, value and calldata passes, even if its external call delivered nothing.

Note that nonReentrant does not help here. The two claims are sequential calls from the attacker's contract, not nested ones.

The Attack, Step by Step

BlockSec Phalcon and SlowMist describe the same sequence, and the token transfers we read from the transaction receipt match it. All steps ran inside one transaction sent from the attacker EOA to a purpose-built attack contract.

Step 1: Arm the Hash With a Genuine Message

The attacker called the public SyncL2TxHashRelayer to claim a real, pending Linea message that synchronised two L2 transaction hashes. The Linea bridge verified the proof, the Linea gateway called back into the Arbitrator, and finalizeMessageHash was set to the hash of that genuine message. The legitimate message was forwarded as normal. The slot stayed armed.

Step 2: Smuggle a Root Update Through the Same Function

The attacker called the relayer a second time in the same transaction. This time the "canonical message service" was the EthereumGateway, and the claim calldata was a sendMessage call wrapping syncBatchRoot(116409, attackerChosenRoot, 0). The gateway accepted it because the caller was the Arbitrator, and ZkLink stored the attacker's root for batch 116409 because the caller was its gateway.

Step 3: Pass Validation With the Stale Hash

The EthereumGateway never calls back into receiveMessage, so nothing overwrote the slot. The attacker supplied the same gateway, value and calldata as in Step 1, so the recomputed hash matched the stale one. The forged root survived.

Step 4: Withdraw Against the Forged Root

Finalising a withdrawal on zkLink is permissionless and relies only on the stored root. The attacker submitted 12 withdrawal proofs built against their own root: one ETH withdrawal from the ZkLink escrow and eleven token withdrawals from the L1ERC20Bridge. Every receiver was the attacker's address.

From the transaction receipt we read the following transfers out of the L1ERC20Bridge to the attacker EOA:

Asset	Amount
pufETH	245.7379
USDC	18,113.45
ezETH	12.5693
rsETH	6.8665
STONE	6.2998
USDT	3,360.90
mstETH	2.6372
mswETH	2.4826
rswETH	0.5000
wstETH	0.4660
WBTC	0.1736

On top of these, 22.43 ETH came out of the ZkLink escrow itself. Liquid restaking tokens made up most of the value, with pufETH alone accounting for the bulk of the loss.

A Simplified Version of the Bug

The snippet below is a simplified, illustrative model of the pattern, not zkLink's production code.

// Simplified illustration only
contract Router {
    bytes32 transient lastDelivered; // armed by trusted callbacks

    function onDelivered(bytes32 h) external onlyGateway {
        lastDelivered = h;
    }

    function claim(address target, bytes calldata data, bytes32 expected) external {
        (bool ok, ) = target.call(data);     // caller picks target and data
        require(ok);
        require(lastDelivered == expected);  // stale value still passes
        // BUG: lastDelivered is never cleared
    }
}

A safer shape pins the target and consumes the evidence:

// Simplified illustration only
function claim(bytes calldata data, bytes32 expected) external {
    (bool ok, ) = canonicalService[msg.sender].call(data); // fixed target
    require(ok);
    require(lastDelivered == expected);
    lastDelivered = bytes32(0);                            // one claim, one use
}

Parapet Labs, which replayed the attack on a mainnet fork, reports that either change alone makes the forged claim revert, and that both belong in a fix.

Follow-On Attacks and Response

BlockSec Phalcon later reported similar attack transactions against zkLink Nova on several L2 chains, and zkLink's own statement at 09:06 UTC on 29 October referred to an ongoing exploit of the Arbitrator on Ethereum and Optimism. Parapet Labs attributes this second wave, at about 07:16 UTC on 29 October, to a different actor and reports roughly 24.76 ETH plus token balances taken from escrows on Optimism, Base, Blast and Mantle. We have not independently verified those second-wave figures.

zkLink offered a 20% white-hat bounty for returned funds. At 13:08 UTC on 29 October it said block production on Nova had been suspended, the affected contracts emergency-patched and withdrawals temporarily disabled. Parapet also notes that pauses applied to secondary chains in 2025 blocked deposits but not withdrawal finalisation, which is why those paused escrows could still be drained.

Cross-chain message routers keep failing in similar ways. Our analyses of the Initia MoveVM bridge exploit and the WAX bridge negative fee exploit show the same theme: a bridge is only as safe as the weakest check on what it is told to release.

Lessons for Builders and Auditors

1. Consume transient flags after use. EIP-1153 slots persist for the whole transaction. If a value represents "this specific claim was authenticated", clear it with tstore(slot, 0) immediately after the check. Do the same for session flags such as claiming.

2. Never make arbitrary calls from a privileged identity. If other contracts authorise by msg.sender == address(this), then any caller-chosen target and calldata is a privilege escalation path. Pin the canonical service per gateway or keep an explicit allowlist of call targets and selectors.

3. Check before you act, not after. Here the privileged call ran first and validation came second. Ordering validation before effects is the same discipline that prevents reentrancy, and it removes whole classes of bugs.

4. Treat permissionless relayers as public entry points. An onlyRelayer modifier means little if one of the whitelisted relayers forwards any caller's arguments unchanged.

5. Make pauses cover withdrawals. An emergency stop that blocks deposits but leaves finalizeWithdrawal open does not protect escrowed funds.

6. Test multi-call transactions. Fuzz harnesses should call the same entry point several times within one transaction with mixed genuine and malicious inputs. Single-call unit tests will never catch a stale transient value. Our smart contract security checklist covers these test patterns.

Key Addresses and Transactions

Exploit transaction: 0x4f3c23e7...297462c
Related transaction listed by SlowMist: 0x8a7e38b9...f8848ae9
Attacker EOA: 0xaca0655a11200a80d33d0e48786317304cde5718
Attack contract: 0xd5f162b68a0281686e8dc76db8d67d2f3e6aff07
Second address listed by SlowMist: 0xdab137f390df77caa97fd492540e973fd5e2f8c8
Arbitrator (proxy): 0x1ee09a2caa0813a5183f90f5a6d0e4871f4c6002
ZkLink escrow: 0x5fd9f73286b7e8683bab45019c94553b93e015cf
L1ERC20Bridge: 0xad16edcf7deb7e90096a259c81269d811544b6b6

Sources

BlockSec Phalcon alert on X: root cause, five-step breakdown, batch number and asset amounts
SlowMist TI Alert on X: root cause, attacker, victim and vulnerable contract addresses, transactions
Defimon alert on X: per-asset breakdown and loss estimate
zkLink statement on X and follow-up: confirmation, bounty offer and emergency measures
Parapet Labs post-mortem: fork replay, fix isolation and second-wave tracing
zkLink Arbitrator.sol on GitHub: claimMessage source
Transaction receipt, block timestamp and token transfers, read by us from a public Ethereum RPC node

Closing Thoughts

Transient storage is a useful tool, but it changes what "temporary" means. A flag that lasts for a transaction is not a flag that lasts for a call, and in a contract that can be called many times per transaction, that difference is the whole security model. Pair that with a privileged contract that will call anything it is told to, and one honest message becomes a key to every escrow.

Building a bridge, rollup or cross-chain messaging layer? Contact Panda Security for a review of your message authentication and access-control paths, or see our audit pricing.

TranchePool Exploit: A Midnight Rollover Drained $1.01M

PandaSecurity — Wed, 28 Oct 2026 23:06:45 +0000

Originally published at TranchePool Exploit: A Midnight Rollover Drained $1.01M

Shortly after midnight UTC on 28 October 2026, an attacker drained 1,013,353.61 USDC from a TranchePool on Avalanche C-Chain that SlowMist reports is associated with Valinor Digital, Oatfi and Fence Finance. The pool lost its entire USDC balance. There was no oracle manipulation and no reentrancy. The bug was a piece of credit accounting: when the calendar turned to a new UTC day, the pool treated a scheduled principal repayment as if it had actually been paid, even though no USDC arrived. That single bookkeeping step gave the attacker a fresh line of draw capacity, and the attacker used it three seconds after midnight.

This post walks through what the chain shows, why the root cause is so easy to miss in a review, and what teams building tokenized credit or vault products should test for.

What Happened

The attack used two transactions from the same externally owned account, 0x6ff1c3ff...2b1246, both calling a helper contract at 0xf09dcf4e...a57805 that the attacker had deployed about fifteen minutes earlier.

Transaction 1: the setup (27 October, 23:56:41 UTC). The attacker's contract took a flash loan of 1,013,353.611686 USDC through Aave v3. That figure is exactly the pool's USDC balance. We read the receipt from a public Avalanche RPC node: the full amount went from the attacker contract into the TranchePool at 0xe25cb545...47621a, the same amount came straight back out of the pool, and 1,013,860.288492 USDC was returned to Aave, a premium of roughly 506.68 USDC. After this transaction, the pool still held all of its USDC. Nothing had been stolen yet.

Transaction 2: the drain (28 October, 00:00:03 UTC). Three seconds into the new UTC day, the attacker's contract called the pool's draw path again. This time the pool sent 1,013,353.611686 USDC of its own funds to the attacker contract, which forwarded it to the attacker's wallet. The pool's balance went to zero.

Within minutes the attacker moved the funds off Avalanche. Two calls to Circle's CCTP depositForBurnWithHook at 00:03:41 and 00:05:22 UTC burned about 250,000 USDC and 763,375 USDC with destination domain 5, which is Solana in CCTP's domain numbering.

Blockaid was among the first to flag the incident and initially described it as a flash loan used to mint inflated tranche shares. SlowMist's follow-up analysis pointed to the settlement logic instead, and an independent fork replay published by Sentinelleai supports that reading. CertiK Alert summarised it the same way: a scheduled accounting update reopened draw capacity that had already been used.

Root Cause: A Due Date Was Booked as a Payment

According to SlowMist, the vulnerable pool tracks two numbers for a tranche: funded principal and outstanding principal. The draw function (selector 0x8e27c105) lets a borrower take out up to the difference:

available = fundedPrincipal - outstandingPrincipal

That check is reasonable on its own. Outstanding principal goes up when money is drawn and should only go down when money is repaid.

The flaw was in the settlement step that runs at the UTC day rollover. When a new day began, the pool processed the scheduled principal payment for that date and subtracted it from outstanding principal without confirming that any USDC had actually been received. On paper the loan had been paid down. On-chain, nothing had moved.

Put the two pieces together:

Before midnight, the attacker used flash-loaned USDC to set up a position with the pool, drew the full amount back and repaid Aave. Per Sentinelleai's decode of the calldata, one of the setup calls carried the amount of the pool's balance and a timestamp of 0x6ae13b00, which is 00:00:00 UTC on 28 October. The attacker scheduled a repayment for the very next second.
At midnight, the rollover booked that scheduled payment as received. Outstanding principal dropped by about 1.013M USDC.
The draw check now saw roughly 1.013M USDC of capacity again, so the same draw, with the same calldata, succeeded a second time and paid out real funds.

The flash loan only made the setup capital-free. The theft itself was the rollover.

The Clock Was the Only Variable

Sentinelleai forked Avalanche just before midnight and replayed the second transaction's exact calldata with different block timestamps. At 23:59:59 UTC the draw reverted. At 00:00:00 UTC it succeeded and emptied the pool. With the same state and the same input, the only thing that changed the outcome was the block time. That is the signature of a time-dependent accounting bug, not a share-pricing bug.

One caveat matters here: the pool's source code is not verified on the public explorers. The analyses above, including ours, rest on calldata, events, token transfers, balances and fork replays rather than on reading the original Solidity.

A Simplified Model of the Bug

The code below is simplified and illustrative. It is not the pool's real source, which is unverified. It shows the shape of the mistake.

// SIMPLIFIED, ILLUSTRATIVE ONLY - not the victim contract's code
contract TranchePoolSketch {
    IERC20 public immutable usdc;
    uint256 public fundedPrincipal;
    uint256 public outstandingPrincipal;

    struct Scheduled { uint64 dueAt; uint256 amount; bool settled; }
    Scheduled[] public schedule;

    function draw(uint256 amount) external {
        _rollover();
        require(amount <= fundedPrincipal - outstandingPrincipal, "no capacity");
        outstandingPrincipal += amount;
        usdc.transfer(msg.sender, amount);
    }

    // BUG: runs when a new UTC day starts and treats "due" as "paid".
    function _rollover() internal {
        for (uint256 i; i < schedule.length; i++) {
            Scheduled storage s = schedule[i];
            if (!s.settled && block.timestamp >= s.dueAt) {
                s.settled = true;
                outstandingPrincipal -= s.amount; // no USDC was received
            }
        }
    }
}

A safer design separates "an amount is due" from "an amount has arrived." Outstanding principal should only decrease inside a repayment function that pulls the tokens and measures the balance change:

// SIMPLIFIED, ILLUSTRATIVE ONLY
function repay(uint256 amount) external {
    uint256 before = usdc.balanceOf(address(this));
    usdc.transferFrom(msg.sender, address(this), amount);
    uint256 received = usdc.balanceOf(address(this)) - before;
    outstandingPrincipal -= received;
}

Scheduled payments that come due without funds should move the position into a "late" or "default" state, which reduces capacity rather than restoring it.

Why Reviews Miss This Class of Bug

Real-world credit brings real-world conventions on-chain: due dates, day counts, payment waterfalls, senior and junior tranches. Each convention adds a place where state changes without money moving. In traditional finance, a back office reconciles the ledger against the bank account. On-chain, the contract is both the ledger and the account, so any line that updates the ledger without checking the token balance becomes an attack surface.

Three things made this one easy to overlook:

It only triggers at a boundary. Tests that run at a fixed timestamp, or that never cross midnight UTC, will never reach the buggy branch.
The attacker controlled the schedule. A due date one second in the future is legal input in most credit systems. Few test suites ask what happens when the borrower picks the due date.
Events looked normal. Monitoring that watches for unusual mints or price moves would see a routine draw. The dangerous transition was a scheduled state update, which produces no obvious alert. That is also why the first public explanation was a share-inflation theory.

We saw a related theme in the X100 governance flash loan exploit, where a flash loan made an attack free rather than being the vulnerability itself. And just a day earlier, the Avalanche Safe stale approval incident showed how an assumption made at one moment can be cashed in later by whoever arrives first.

Lessons for Teams and Auditors

1. Write down the money invariant and enforce it. For any lending or credit pool the core rule is short: draw capacity can never exceed assets the contract has actually received. Encode it as an assertion or an invariant test, not just a comment.

2. Never reduce debt on a schedule. Outstanding principal should decrease only when tokens arrive, measured by balance deltas. A payment that comes due without funds is a missed payment, and it should tighten the position.

3. Fuzz across time boundaries. Property tests should warp across the UTC day rollover, test due dates equal to block.timestamp, test due dates set to the next second, and test due dates supplied by the caller. Foundry's vm.warp makes this cheap.

4. Treat user-chosen dates as adversarial input. If a borrower can set the schedule, assume they will pick the value that makes your accounting worst. Enforce minimum intervals or require repayments to be prefunded.

5. Make draws idempotent. Replaying identical calldata should not succeed twice unless the state genuinely justifies it. Per-draw nonces or explicit drawdown records make double draws visible.

6. Verify your source code. An unverified contract slows down every responder during an incident and hides the logic from independent reviewers before one. Our smart contract security checklist covers this alongside the testing items above.

Recovery Status

At 03:16:23 UTC on 28 October, an address sent the attacker's wallet an on-chain message on behalf of Fence. The message offers a 10% recovery bounty in exchange for returning 90% of the verified affected funds and lists recovery@fence.finance as a contact. As of this writing we have not seen a confirmed return of funds or a full statement on depositor losses.

Key Addresses and Transactions

Vulnerable TranchePool: 0xe25cb545bdd47a8ec2d08001cb5661b00d47621a
Attacker wallet: 0x6ff1c3ffa622e1062168f3497a275be9cc2b1246
Attacker contract: 0xf09dcf4ede2a88bd316ff355dfc333a281a57805
Setup transaction (flash loan): 0x19ab145e...9769899fd
Drain transaction: 0x3f6b2329...1de058c77
CCTP burn, ~250,000 USDC: 0x0e974743...92c2218b
CCTP burn, ~763,375 USDC: 0x51bb85e1...ee3b9f397
Bounty message: 0xaf19a8a6...b2f4894

Sources

SlowMist TI Alert on X: root cause, draw selector, attacker and vulnerable contract addresses, transaction links
Blockaid alert on X: first detection and the initial share-inflation reading
CertiK Alert on X: independent summary of the reopened draw capacity
Sentinelleai fork replay: calldata decode, timestamp analysis and fork replay
SlowMist Hacked database: incident entry for 28 October 2026
Transaction receipts, token transfers, CCTP calls and the bounty message, read by us from a public Avalanche C-Chain RPC node

Closing Thoughts

The pool did exactly what its ledger told it to do. The ledger was wrong for one second, at a boundary nobody tested, on a date the attacker chose. When on-chain credit borrows TradFi conventions, every scheduled state change needs the same question: did the money actually arrive?

Building a lending, RWA or tranche-based protocol? Contact Panda Security for a review of your accounting invariants and time-dependent logic, or see our audit pricing.

Avalanche Safe: A Stale Approval to an Empty Address

PandaSecurity — Tue, 27 Oct 2026 23:06:39 +0000

Originally published at Avalanche Safe: A Stale Approval to an Empty Address

On 26 October 2026, a 2-of-7 Safe multisig on Avalanche C-Chain holding roughly $7.45M of trading inventory was emptied in a single block. No signer key was stolen, no signer was phished, and the Safe contracts did exactly what they were built to do. The money left through four token approvals the Safe itself had signed seven months earlier, pointing at an address that, on Avalanche, had no code at all.

The original attacker never got the funds. An MEV bot copied the attack and landed first in the same block, then returned most of the assets the next day in exchange for a bounty. The outcome was lucky. The bug class is not, and it is one every team that deploys to several EVM chains should understand.

What Happened

According to the security monitor Defimon, which first reported the incident, and an on-chain reconstruction published by BlockintAI, the sequence was:

7 March 2026, 16:10 UTC. The Safe executed a batch transaction that granted unlimited allowances for WAVAX, USDC, WETH.e and BTC.b to 0x3725bd4d175283108156c3f15f86e1c51266155d.
On Ethereum, Base and Arbitrum, that address hosts the operator's own pool contract. On Avalanche, the address was empty. The approvals were never revoked.
26 October 2026, 12:56 UTC, block 98,605,391. A fresh wallet, 0x4c48b79b97516719444056d2bf0dc9564138fa0a, funded about 27 minutes earlier with 6.77 AVAX, sent one Multicall3 transaction designed to claim the empty address and sweep the Safe.
In the same block, at position 0, MEV bot 0x36b112875f921e51f5ea8ff39b374960694d21b3 ran a copy of that transaction. It succeeded. The attacker's transaction, at position 2, reverted.

We confirmed both receipts against a public Avalanche RPC node: the bot's transaction has status success at index 0 in block 98,605,391, and the attacker's transaction has status failed at index 2 in the same block.

Per BlockintAI's reading of the logs, the bot's transaction moved these balances out of the Safe:

Token	Amount
USDC	3,090,123.58
WAVAX	350,375.86
WETH.e	181.98
BTC.b	10.79

Root Cause: An Approval Is a Promise to an Address

ERC-20 approve does not know or care whether the spender is a contract, which contract it is, or whether anything exists there yet. It writes a number into a mapping keyed by an address. Whoever later controls code at that address can call transferFrom up to the allowance.

On most days an approval to an empty address is inert, because nothing can call from it. It turns into a live liability the moment someone can deploy code to that exact address. Here, someone could.

Why the Address Was Claimable

Contracts created with the CREATE opcode get an address derived only from the deployer's address and the deployer's nonce:

address = keccak256(rlp([deployer, nonce]))[12:]

That is the property teams rely on to get "the same address on every chain": use the same deployer, make the same number of deployments, and the results line up. It is also the weakness. If the deployer exists on a new chain but its nonce has not reached the right value, anyone who can push transactions through that deployer can reach it first.

Both Defimon and BlockintAI identify the deployer behind 0x3725bd…155d on the other chains as Safe's public CreateCall helper (0xb22d635d552ec95142e2abe3ffb859ea7d7c0316), a contract that deploys whatever bytecode the caller hands it. CreateCall itself is installed at a deterministic address through the Safe singleton factory, so anyone can put it on a chain where it does not yet exist. BlockintAI computed that CreateCall's 13th deployment lands at 0x3725bd…155d.

Before 26 October, CreateCall had never been deployed on Avalanche. So the path to the Safe's allowances was open to anyone who would:

Deploy CreateCall on Avalanche through the singleton factory.
Make 12 throwaway deployments through it to advance its nonce.
Deploy a sweeper contract as the 13th, landing at 0x3725bd…155d.
Have the sweeper call transferFrom on all four tokens, pulling the Safe's full balances.

All of that fits in one transaction, which is exactly what the attacker's Multicall3 batch tried to do. The allowance had been waiting for a caller for about 233 days.

A Simplified Model of the Sweep

The code below is a simplified illustration of the mechanism, not the attacker's or the bot's actual bytecode.

// SPDX-License-Identifier: MIT
// Simplified illustration only.
pragma solidity ^0.8.20;

interface IERC20 {
    function balanceOf(address) external view returns (uint256);
    function allowance(address, address) external view returns (uint256);
    function transferFrom(address, address, uint256) external returns (bool);
}

interface ICreateCall {
    function performCreate(uint256 value, bytes memory code) external returns (address);
}

contract Sweeper {
    // Deployed as CreateCall's 13th contract, so address(this) equals
    // the address the victim Safe approved months earlier.
    constructor(address victim, address receiver, IERC20[] memory tokens) {
        for (uint256 i; i < tokens.length; i++) {
            uint256 bal = tokens[i].balanceOf(victim);
            uint256 allowed = tokens[i].allowance(victim, address(this));
            uint256 amt = bal < allowed ? bal : allowed;
            if (amt > 0) tokens[i].transferFrom(victim, receiver, amt);
        }
    }
}

contract Claimer {
    function run(ICreateCall createCall, bytes calldata dummy, bytes calldata sweeper) external {
        // Burn nonces 1..12 with throwaway contracts.
        for (uint256 i; i < 12; i++) createCall.performCreate(0, dummy);
        // Nonce 13 lands on the approved address.
        createCall.performCreate(0, sweeper);
    }
}

Nothing in this flow requires a signature from the Safe. The Safe's earlier signatures are already on-chain, in the form of allowances.

The Front-Run and the Bounty

Because the attacker's transaction was fully self-contained and profitable, a bot that simulates pending transactions and replays profitable ones with its own address could copy it. That is what happened. BlockintAI reports the bot later moved the funds to a holding wallet, 0x11eb9b677510e2594857f4d137fd12a7fef39bc5, and posted an on-chain message pointing to the original attack and promising to return the assets to 0x35c6aa248e9495E0572598fBfE0528aCbAC2807C, asking for a 5 to 10% bounty.

On 27 October, one of the Safe's owner addresses agreed on-chain to let the bot keep 42,500 WAVAX (about $371K, per Defimon). BlockintAI then observed the return of all of the USDC, WETH.e and BTC.b, plus 307,834.86 WAVAX, with the 42,500 WAVAX bounty remaining in the holding wallet. CryptoTimes, writing earlier the same day, described the negotiation as still in progress, so treat the final settlement figures as BlockintAI's reading of the chain at the time of its report.

Two side notes from the reports:

The operator moved funds on other chains. Defimon reports that from 13:48 UTC on 26 October, the same operator's signers consolidated assets from Safes on HyperEVM, Base, Robinhood Chain, BNB Chain and Ethereum into 0x70d54baf9ffa48b8fe4e843774a44e24ff452099, which it puts at about $38.7M. That is a sensible move: if one chain had an orphaned approval, others might too.
Address poisoning followed immediately. BlockintAI saw fake "USDC" and "BTC.b" tokens emitting transfers toward a lookalike of the return address. Anyone copying addresses from wallet history during an incident is a target.

The bot giving the money back was a choice, not a control. If the attacker had used a private transaction route, or the bot had decided to keep the funds, the loss would have been the full $7.45M.

Why This Pattern Keeps Coming Back

We have written before about how cross-chain assumptions break, for example in the WAX bridge negative fee exploit, and how wallet-level logic can be replayed in ways its authors never expected in the Argent-style wallet recovery replay. This incident is a cleaner version of the same lesson: an assumption that holds on one chain was carried to another chain where it did not hold.

The same shape shows up in several places:

Pre-approving "future" deployments on a chain where the contract has not been deployed yet, so the deployment script can run later.
Copy-pasting multisig transaction batches between chains and only changing the chain ID.
Counterfactual addresses derived from CREATE with a factory anyone can call, rather than CREATE2 with a salt and init code hash that only the intended bytecode can reach.
Treasury allowances that outlive the integration they were made for.

Lessons for Teams and Auditors

1. Verify spender code before every approval, on that chain. Before a Safe signs an approve, check that the spender has code on the target chain and that its code hash matches what you expect. A Safe transaction guard or a pre-sign checklist can enforce "no approvals to addresses without code."

2. Do not rely on CREATE nonce alignment across chains. If you need the same address everywhere, deploy with CREATE2 (or CREATE3) from a factory where the salt is bound to your deployer, so nobody else can land a different contract at your address.

3. Deploy first, approve second. Approvals should be the last step of a rollout on a chain, after the contract is live and verified, never part of a batch that anticipates a later deployment.

4. Make allowances exact and short-lived. Unlimited allowances from treasuries and trading Safes turn every mistake into a full-balance loss. Approve the amount needed, or use flows like Permit2 with expiries.

5. Audit allowances periodically, across every chain. An allowance inventory per Safe, per chain, with an owner and an expiry, would have flagged this one months ago. Our smart contract security checklist covers operational controls like this alongside code review.

6. Treat multisig operations as code. A batch transaction is a deployment. It deserves review, simulation on the target chain and a diff against what was intended.

Key Addresses and Transactions

Victim Safe (Avalanche): 0x631fca…b9b8 (shortened as in BlockintAI's report)
Approved address: 0x3725bd4d175283108156c3f15f86e1c51266155d
Attacker wallet: 0x4c48b79b97516719444056d2bf0dc9564138fa0a
MEV bot: 0x36b112875f921e51f5ea8ff39b374960694d21b3
Bot holding wallet: 0x11eb9b677510e2594857f4d137fd12a7fef39bc5
CreateCall: 0xb22d635d552ec95142e2abe3ffb859ea7d7c0316
March 7 approvals: 0x6952f80b...42d3829e
Failed attacker transaction: 0xf1f87d37...4a331289
MEV bot transaction: 0xf88a7960...3c007ed5
Bounty agreement message: 0xd2916fec...76911afc

Sources

Defimon Alerts on X: first report, the approved address, the 2-of-7 setup and the $7.45M figure
Defimon Alerts on X, bot's on-chain message: the bot's offer to return funds
BlockintAI research post: on-chain reconstruction, token amounts, CreateCall nonce analysis and return transfers
CryptoTimes report: independent summary of the approvals, the front-run and the bounty negotiation
Transaction receipts for the attacker and bot transactions, read by us from a public Avalanche C-Chain RPC node

Closing Thoughts

This Safe was not hacked in the usual sense. It kept a promise it had made months earlier to an address it never checked. On multichain deployments, "same address" is an assumption you have to prove on every chain, every time you sign.

Running treasuries or contracts across several EVM chains? Contact Panda Security for a review of your deployment scripts, multisig operations and allowance hygiene, or see our audit pricing.

Initia Exploit: A MoveVM Cache Bug Emptied Its Bridges

PandaSecurity — Mon, 26 Oct 2026 23:12:53 +0000

Originally published at panda-security.xyz

On 23 October 2026 at 14:59 UTC, an attacker used a flaw in the script cache of Initia's MoveVM to credit itself with unbacked WETH, iUSD and USDC on the Initia L1. Within about seven minutes, real assets started leaving Ethereum-side bridge reserves. By the time validators halted the L1 and every rollup at 15:41:30 UTC, roughly $2.7M had been bridged out and swapped into 1,135.52 ETH.

No token contract on Ethereum was hacked, and no bridge signature was forged. The bridges did exactly what they were designed to do: they burned a token on Initia and released the matching asset on Ethereum. The problem is that the token on Initia was never backed. This post walks through what is confirmed, what is still unknown, and what bridge and L1 teams should take from it.

TL;DR

Victim: Initia, a Cosmos SDK L1 that runs MoveVM and hosts a network of rollups.
Root cause (per Initia): a bug in MoveVM's script caching let malicious code "bypass security checks" and spoof VM state, crediting balances without changing the recorded total supply. Initia has not yet published the technical post-mortem.
Cash-out: about 105 WETH and ~1.4M AUSD0 over LayerZero, plus ~1.08M USDC through Noble and Circle's CCTP.
Proceeds: swapped to ETH and parked in 0x358ef013...41cac8, which still held 1,135.52 ETH and had never sent a transaction when we checked it on 27 October.
Who pays: the reserves behind bridged assets. Bitquery measured Noble's USDC reserve for Initia falling from $1.09M to $63, the ETH adapter losing about 96% and the AUSD adapter about 71%.
Native INIT: not minted, and Initia says its supply is unaffected.

What Initia Is and Why Bridged Tokens Matter

Initia is a layer 1 built on the Cosmos SDK, with MoveVM as its smart contract engine and a family of rollups that settle to it. Most of the dollar and ether liquidity on the chain is not native. It arrives through bridges:

ETH and AUSD come from Ethereum through LayerZero OFT adapters. An adapter locks the real asset on Ethereum, and an omnichain token is credited on Initia. AUSD's Initia-side copy is called AUSD0.
USDC comes from Noble, the Cosmos chain that issues Circle's USDC, and leaves for Ethereum through CCTP.
iUSD is Initia's own dollar token, issued one-for-one against AUSD0.

The security of every one of these copies reduces to a single invariant: the balances on Initia must never exceed what is locked behind them. If the destination chain can be convinced that someone owns tokens they never deposited, the reserve on the home chain will pay the difference to whoever burns them first.

What Initia Has Confirmed

Initia's official statement on 24 October says an attacker "exploited a bug in Initia MoveVM's script caching that allowed malicious code to bypass security checks." It adds that the attacker "artificially spoofed the MoveVM state," receiving unbacked WETH, iUSD and USDC "without changing the corresponding token's total supply." Co-founder Zon described it as a day-zero bug in Initia's MoveVM on the Cosmos SDK.

That last detail matters for monitoring. The forged balances did not appear in each token's recorded supply. A dashboard that watched only total_supply on Initia would have shown nothing unusual while millions of dollars in balances appeared.

Initia has not said which cache, which check, or which code path was involved. A fix and audit were promised "in a few days," and the L1 and rollups were still halted at the time of writing.

What the Chain Shows

Two independent on-chain write-ups, from D2 Finance (relayed by 0xCERT) and from Bitquery, line up on the shape of the attack.

Preparation

Bitquery reports that the attacker's Ethereum wallet, 0xdd922c84...f6edfa, received 0.098 ETH from Tornado Cash the same morning, sent small test transfers toward Osmosis, and bridged a little ETH to Initia. It then received 141 INIT for gas from an Osmosis wallet and uploaded its own program. The first attempt failed. The second worked.

The forged balances

D2 Finance pointed to a single mint transaction at 14:59:26 UTC that called one Move function to credit 2,000,000 AUSD0, with the same pattern for USDC and ETH. Bitquery counted four runs of the attacker's program within 13 seconds, producing about $7.48M of iUSD, USDC, AUSD0 and WETH at face value. Both agree that nothing was locked anywhere to back it.

Face value overstates the damage. About 3M of that was iUSD, which exists only on Initia and had no bridge to drain. Only the copies of real assets could be redeemed.

The cash-out

We checked the Ethereum side ourselves against a public RPC node:

In block 26,256,091, the AUSD OFT adapter 0x38b8b7ca...f200c844 transferred exactly 1,400,000 AUSD to the attacker.
In block 26,256,115, the ETH OFT adapter 0x66a503a1...0babbc1bde released exactly 105 ETH.
About 1.08M USDC was minted to Ethereum via CCTP after leaving Noble's reserve.

Each batch was swapped to ETH within minutes, mostly through 1inch according to Bitquery. Then, at 15:41:35 UTC, five seconds after the halt, the wallet sent 1,135.52 ETH to a fresh address, 0x358ef013...41cac8. That address had a transaction count of zero and the same balance when we read it on 27 October.

What did not get out

Bitquery found that three USDC withdrawals bounced because Noble's reserve no longer held enough. A final 200,000 AUSD0 message stalled because LayerZero Labs' own verifier did not sign it, and the AUSD adapter blocked it later that day. Roughly $1.55M of copies of real assets, plus the unsellable iUSD, were still on Initia when the chain stopped.

Ordinary users paid as well. After the attacker's withdrawals, eleven normal USDC redemptions drained most of what remained in Noble's reserve, and Bitquery counted 55 later withdrawals that failed before the halt.

Why a Cache Bug Becomes a Mint

Initia has not published the mechanism, so we will not guess at its code. The general failure class is well known to anyone who audits VMs, and it is worth stating plainly.

A Move VM does expensive work before it runs a script: it deserializes the bytecode, runs the bytecode verifier, and checks type and resource-safety rules. Those rules are what stop a script from creating a Coin or FungibleAsset value out of thin air or writing to storage it does not own. Caching the result is a reasonable optimisation. It becomes dangerous when the cache key does not fully bind what was verified. If the key misses the exact bytes, the dependency set, or the context the check depended on, a later execution can reuse a "verified" result for code that was never verified.

In a resource-oriented VM, skipping verification is close to the worst case. Resource safety is the mint authority. Bypass it, and a balance can exist without the module that controls supply ever being asked. That is consistent with Initia's description of balances that appeared while recorded supply did not move.

The lesson for auditors: in VM and runtime reviews, every cache in front of a security check is itself a security boundary. Review what the key contains, when entries are invalidated, and whether a cache hit can ever skip a check that a miss would run.

The Bridge Side: Trust Without Limits

The VM bug created the forged balances. The bridges turned them into $2.7M. A bridge cannot tell a forged balance from a real one if the source chain's state says it is real, so the last line of defense is how much it will release, and how fast.

Here is a simplified, illustrative Solidity sketch of an outflow limit on a lockbox adapter. It is not LayerZero's or Initia's code:

// Simplified illustration only. Not production code.
contract RateLimitedLockbox {
    uint256 public constant WINDOW = 1 hours;
    uint256 public maxOutflowPerWindow;   // e.g. 10% of locked reserves
    uint256 public windowStart;
    uint256 public outflowInWindow;

    function _release(address to, uint256 amount) internal {
        if (block.timestamp >= windowStart + WINDOW) {
            windowStart = block.timestamp;
            outflowInWindow = 0;
        }
        outflowInWindow += amount;
        require(outflowInWindow <= maxOutflowPerWindow, "outflow limit");
        token.transfer(to, amount);
    }
}

With a cap of, say, 10% of reserves per hour, a 1.4M AUSD release out of a larger pool, plus a 105 ETH release out of a reserve that ended 96% drained, would have hit the limit and paused. That would have bought the 42 minutes Initia needed to halt the chain.

It is worth noting what did work. LayerZero's verifier set includes a LayerZero Labs verifier, and the final AUSD message stalled when it did not sign. Noble's reserve could only pay what it held, which capped the USDC loss. Earlier we covered a negative fee that drained the WAX bridge and a Sui bridge claim bot that paid the Cetus attacker. The bugs differ, but each raises the same audit question about a bridge: how much can leave before anyone is able to react?

How to Prevent This

Treat VM caches as part of the trusted computing base

Any cache that stores a verification, type-check or permission result must be keyed by everything the result depended on: the full code hash, dependency versions, and the execution context. Add tests that try to reach execution through a cache hit with code the verifier would reject.

Monitor balances against supply, not just supply

Initia's forged balances left recorded supply untouched. An invariant check that sums balances for bridged assets, or reconciles each bridged token against its remote lockbox, would have flagged the attack in its first block.

Rate-limit bridge releases

Per-asset, per-window outflow caps on lockboxes and mint limits on the destination side turn an unlimited drain into a bounded one. Pair them with an automated pause when a cap is hit.

Require independent verifiers

The one AUSD message that stalled was the one that lacked a signature from an independent verifier. Bridges should require more than one independent party to approve a release, and those parties should be allowed to refuse when the amount looks wrong.

Rehearse the halt

Initia stopped the chain 42 minutes after the first forged balance appeared. That is fast for a full L1 halt, and still long enough to lose $2.7M. Chains with bridge exposure should know exactly who can pause which bridge, and practice doing it.

For a broader pre-launch list, see our smart contract security checklist.

Key Addresses and Transactions

Attacker wallet on Ethereum: 0xdd922c841d85e12dac2dc2eef5a5e29cfff6edfa
Proceeds wallet (1,135.52 ETH): 0x358ef0130f7a5aa516dcd81bdc80b18cde41cac8
1.4M AUSD release: 0x034c1076...be17f3b6
105 ETH release: 0x5cd422fd...0887d7e9
Transfer to the proceeds wallet: 0x60f15b7e...1043e06
AUSD OFT adapter on Ethereum: 0x38b8b7ca28e672018a299b20565aca8cf200c844
ETH OFT adapter on Ethereum: 0x66a503a1060ab3f2b1aaabed613fe30babbc1bde
Initia mint transaction (per D2 Finance): 67423E84815CEC63632BD4676CA22D33567F3E02C3187281C9B6BFD593CBA7AF

Sources

Initia's official statement on X: root cause description, amounts and proceeds address
0xCERT advisory 0xCERT-2026-0267: summary of D2 Finance's on-chain analysis, Agora's clarification and indicators of compromise
Bitquery investigation: preparation timeline, $7.48M face value, reserve drawdowns and blocked messages
Le Coin report: independent confirmation of the proceeds wallet balance
TokenPost report: independent summary of Initia's statement
Transaction receipts, block timestamps and the proceeds wallet's balance and nonce, read by us from a public Ethereum RPC node

Closing Thoughts

The Initia exploit is a reminder that a bridge is only as sound as the state of the chain it trusts. A single cache bug in the VM was enough to fake balances, and bridges with no outflow limits converted them into real ETH within minutes. When the full post-mortem lands, we will be watching for exactly what the cache key missed.

Building on Move, running a bridge, or launching an appchain? Contact Panda Security for a review of your VM integration and bridge controls, or see our audit pricing.