DEV Community: PandaSecurity

Sui Bridge Claim Bot Sent $392K to the Cetus Attacker

PandaSecurity — Fri, 16 Oct 2026 23:21:06 +0000

Originally published at Sui Bridge Claim Bot Sent $392K to the Cetus Attacker.

On 16 October 2026, between 04:39 and 04:40 UTC, an automated bot finalized a batch of old, unclaimed Sui Bridge withdrawals on Ethereum. Most of them belonged to ordinary users. Eight of them did not. They had been sent from the Sui address of the Cetus exploiter, and finalizing them delivered 86 ETH, 109,000 USDT and 0.9 WBTC to the attacker's Ethereum wallet, around $392K by the bot operator's own estimate.

No contract was broken. Nobody forged a signature. The bridge did exactly what it was built to do. That is what makes this incident worth studying: a perfectly correct, permissionless code path turned dormant attacker funds into spendable ones, because the off-chain automation around it never asked whose money it was moving.

TL;DR

What happened: a "rescue" bot completed stale Sui Bridge withdrawals in three Ethereum transactions. Eight of the withdrawals had the Cetus attacker's Sui address as sender and its Ethereum address as recipient.
Assets delivered to the attacker: 86 ETH, 109,000 USDT and 0.9 WBTC, which the operator put at roughly $392K.
Root cause: not a contract bug. transferBridgedTokensWithSignatures() lets anyone submit a committee-signed message, and the bot submitted every valid message it found without screening the sender or recipient.
Status at the time of writing: the 109,000 USDT and 0.9 WBTC were still in the attacker's wallet, and USDT's on-chain blacklist did not yet include the address. The operator has asked for help getting the USDT frozen.

Background: Cetus and the Leftover Withdrawals

Cetus, the largest concentrated-liquidity DEX on Sui, was drained of roughly $220 million on 22 May 2025 through an arithmetic overflow in its liquidity math. Sui validators froze about $162 million on the Sui side within the first hour, while part of the haul had already left for Ethereum. Public analyses from several research teams list the attacker's Sui address as 0xe28b50…8ff06 and the Ethereum address that received bridged funds as 0x89012a55…24919b.

The 16 October TokensClaimed events, which we decoded ourselves, show that a set of Sui-to-Ethereum bridge messages from that same Sui address had been signed but never claimed on Ethereum. On a lock-and-claim bridge, that leaves the funds sitting in the Ethereum-side vault indefinitely. We could not find a public explanation of why they were left unclaimed, and we won't guess at one. What matters is that they were still claimable, and that claiming them pays out to the recipient fixed in the message, which here was the attacker.

How the Sui Bridge Claim Works

The Ethereum side of Sui Bridge is open source. A transfer from Sui is finalized on Ethereum by calling transferBridgedTokensWithSignatures() with the message and enough committee signatures. The function checks the signatures, checks that the nonce hasn't been processed, enforces a 24-hour rate limit, and then pays the recipient encoded in the message. It does not care who msg.sender is.

The simplified sketch below is our illustration of that flow, condensed from the public SuiBridge.sol, not a verbatim copy:

// Simplified illustration of a permissionless bridge claim (not verbatim SuiBridge code)
function transferBridgedTokensWithSignatures(
    bytes[] memory signatures,
    Message memory message
) external nonReentrant verifyMessageAndSignatures(message, signatures) {
    require(!isTransferProcessed[message.nonce], "already processed");

    TokenTransferPayload memory p = decodeTokenTransferPayload(message.payload);
    require(p.targetChain == chainID, "wrong chain");

    // Funds always go to the recipient chosen on the source chain.
    // The caller cannot redirect them, and the caller is never checked.
    _transferTokensFromVault(message.chainID, p.tokenID, p.recipientAddress, p.amount);

    isTransferProcessed[message.nonce] = true;
    emit TokensClaimed(message.chainID, message.nonce, chainID, p.tokenID,
                       p.amount, p.senderAddress, p.recipientAddress);
}

This is a sound, common design. Because the caller cannot change where the money goes, letting anyone relay a message is safe for the user, and it is good for liveness: a user who lost interest, or a relayer that went offline, does not leave funds stranded forever. Many bridges work the same way.

The catch is that "safe for the user" assumes the recipient should receive the funds. When the recipient is an exploiter, a permissionless claim is a one-way valve that anyone can open.

What the Bot Did, Step by Step

The three claim transactions came from the same externally owned account, 0x7f2e…6671, each one a batched Multicall3 call that finalized many withdrawals at once. We decoded every TokensClaimed event emitted by the Sui Bridge contract in those transactions. The withdrawals sent to the attacker were:

Tx	Sui nonce	Asset	Amount
`0x89ca33…dde89`	7025, 7027, 7030	ETH	28 ETH each (84 ETH)
`0x89ca33…dde89`	7028	WBTC	0.9 WBTC
`0x89ca33…dde89`	7031	USDT	93,000 USDT
`0xce494e…36ac`	7020, 7022	USDT	8,000 USDT each
`0xe63cb0…1fc8`	7021	ETH	2 ETH

Every one of these events carries the same 32-byte sender, 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06, the Cetus attacker's Sui address, and the same recipient, 0x89012a55cd6b88e407c9d4ae9b3425f55924919b. The two signals that could have stopped the claim were sitting in the event data the whole time.

The same batches also finalized legitimate withdrawals for other users, including one WBTC and two ETH withdrawals on Sui Bridge, plus pending withdrawals on other protocols' contracts. In other words, this was a general-purpose "finish what others left unfinished" bot, and the attacker's messages simply looked like more stale funds.

The on-chain exchange that followed

About half an hour later, a user signing as tanuki42 sent an on-chain message to the bot's address pointing out that roughly $390K had gone to "an address publicly associated with the Cetus exploit" and suggesting it screen recipients before "rescuing" funds. Defimon Alerts relayed the message on X.

The operator, signing as lostandfound.eth, replied on-chain at 05:38 UTC: "you're right, our mistake. We didn't know 0x89012a…919b was the Cetus attacker when our automated run completed those Sui Bridge withdrawals." The reply lists the three claim transactions, estimates the total at about $392K, says the 109,000 USDT had not moved, asks for the case to be routed to Tether and Cetus for a freeze, and says the bot now screens every recipient against known exploit and sanctioned addresses before claiming.

When we checked the wallet after these messages, it still held 109,000 USDT and 0.9 WBTC, and USDT's getBlackListStatus() for the address returned false. The ETH, of course, cannot be frozen by anyone.

Why This Matters Beyond One Bot

It is tempting to file this under "operator error" and move on. We think there are three broader lessons.

1. Dormant is not the same as safe

After an exploit, incident response focuses on funds that are moving. Messages that were signed but never executed get far less attention, yet they are live liabilities. Anyone, at any time, can turn them into spendable assets. The same applies to queued withdrawals, unexecuted governance actions, pending limit orders and approvals that never expire. We made a similar point about stale state in our NEAR Intents exploit analysis, where balances that looked inert turned out to be withdrawable.

2. Permissionless relaying moves the screening burden off-chain

When a protocol lets anyone finalize anything, the protocol itself does no screening, so whatever screening exists lives in the relayers. A careful relayer can be undone by a careless one: it takes one bot, one person running a script, or one MEV searcher looking for gas refunds to complete the transfer. Protocol teams should not assume "nobody will bother" is a control.

3. Recovery tooling is security-sensitive software

Tools that find stuck bridge funds have drawn a lot of attention lately, and the well-known checkers are read-only: they tell users what is claimable and leave the claim to them. A bot that executes claims on others' behalf is a different thing: it is a payment system with no compliance checks. It deserves the same threat model as any contract that moves value.

Mitigations

For bridge and protocol teams

Treat unclaimed attacker messages as part of incident response. After an exploit, list every signed-but-unexecuted outbound message from attacker addresses and decide how to handle it, whether through a governance or committee action, an emergency pause path, or coordination with token issuers, before someone else decides for you.
Consider a sender and recipient hold list on the claim path. A narrowly scoped, governance-controlled list that delays (rather than blocks forever) claims from known exploit addresses keeps permissionless relaying for everyone else. It is a trade-off against censorship resistance and must be governed transparently.
Expose message provenance clearly. Make the source-chain sender easy to read in events and explorer views so relayers and monitors can screen it.

For relayers and recovery bots

Screen both ends of the transfer, cap what can be claimed without human review, and fail closed when a screening source is unavailable. An off-chain check is enough, but a wrapper contract makes the rule enforceable. The following is a simplified illustration:

// Simplified illustration: a relayer wrapper that refuses flagged transfers
contract ScreenedClaimRelayer {
    ISuiBridge public immutable bridge;
    IScreeningList public immutable screening; // maintained off-chain, updated by a multisig
    uint256 public immutable reviewThresholdUsd;

    function claim(bytes[] calldata sigs, Message calldata m, uint256 quotedUsd) external {
        TokenTransferPayload memory p = decodeTokenTransferPayload(m.payload);

        require(!screening.isFlaggedSui(p.senderAddress), "flagged sender");
        require(!screening.isFlaggedEvm(p.recipientAddress), "flagged recipient");
        require(quotedUsd < reviewThresholdUsd, "needs manual review");

        bridge.transferBridgedTokensWithSignatures(sigs, m);
    }
}

For auditors

Map every permissionless finalize, claim, execute or settle function and ask what dormant inputs it can consume. If an exploit happened tomorrow, which of those inputs would belong to the attacker?
Check that incident runbooks cover pending messages, not just pausing contracts. A pause that blocks new deposits but not old claims may leave the most important door open.
Review recovery and keeper bots with the same rigor as on-chain code when they move user funds. Our smart contract security checklist and our overview of top DeFi security risks cover access control and operational risks that apply here as well.

Key Addresses and Transactions

Claim tx 1: 0x89ca33e27e8a8b409a202b2c5710d6e1bb0accd505b6c34e95c24f35a14dde89
Claim tx 2: 0xce494e04a3fe01292c7edb8b1be228c943926e920bdb3737786e6062670d36ac
Claim tx 3: 0xe63cb0903e6784fd2343c1052ba190fe37c85d8b1d9442b9b54c1155b2e41fc8
Claim bot (signed as lostandfound.eth): 0x7f2ee458d58e61345ad61a70e8072511bf9f6671
Cetus attacker, Ethereum: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Cetus attacker, Sui: 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Sui Bridge contract on Ethereum: 0xda3bd1fe1973470312db04551b65f401bc8a92fd

Sources

Ethereum transaction receipts for the three claim transactions above, decoded by our team (TokensClaimed events and token transfers)
Defimon Alerts on X: on-chain message from tanuki42
Defimon Alerts on X: on-chain reply from lostandfound.eth
Telem: bridge operator sent ~$392K USDT to the Cetus attacker
Telem: ~$390K in stale Sui Bridge withdrawals sent to a Cetus-linked address
SuiBridge.sol in the MystenLabs/sui repository
OAK: Cetus Protocol concentrated-liquidity overflow and Blockscope: Cetus exploit analysis: background and attacker addresses

Closing Thoughts

The Sui Bridge contract behaved correctly, and the bot operator acknowledged the mistake within about half an hour of being flagged and changed its process. Still, a well-meaning script handed an exploiter close to $400K that had been sitting unclaimed in the bridge vault. If your protocol has any function that anyone can call to finalize something, your security model has to include the question of who that something belongs to.

Running a bridge, a keeper network or a recovery tool that moves other people's funds? Contact Panda Security for a design and code review, or see our audit pricing.

KolanHook Exploit: Unguarded Uniswap v4 Buyback Drained ETH

PandaSecurity — Fri, 16 Oct 2026 14:38:20 +0000

Originally published at KolanHook Exploit: Unguarded Uniswap v4 Buyback Drained ETH.

On 15 October 2026, an attacker took about 2.31 ETH out of KolanHook, a Uniswap v4 hook on Ethereum mainnet, and kept roughly 1.28 ETH (around $3K) as profit after repaying a flash loan. The dollar amount is small. The pattern is not. A hook that spends its own reserves on a swap, at whatever the pool's spot price happens to be, triggered by a function anyone can call, is an exploit waiting for a caller.

This post-mortem walks through what Kolan does, why the buyback path was exploitable, how the attack was sequenced, and what auditors and hook developers should take away from it.

TL;DR

Protocol: Kolan, a Uniswap v4 "window" protocol. Hook: KolanHook, token: KLN.
Chain: Ethereum mainnet.
Loss: about 2.31 ETH left the hook; attacker net profit about 1.28 ETH.
Root cause: accept(id) lets anyone close an expired window. Closing a window runs a buyback swap with the hook's own ETH, and that swap used a price limit of MIN_SQRT_PRICE + 1, which in practice means no slippage protection at all.
Enabler: a 6.7 WETH flash loan from Balancer to push the KLN spot price up before forcing the buyback.

What Kolan Is

According to Kolan's own documentation, the system is two contracts: KolanHook, which holds the pool liquidity and the "windows", and KolanToken, a fixed-supply ERC-20 (1,000,000 KLN) minted once to the hook. There is no owner, no proxy and no pause, and the hook refuses outside liquidity. The docs also state plainly that the contracts are tested but not audited.

A "window" is attached to a purchase. A buyer pays a premium on top of the ETH they spend, and for a period of time they can undo the purchase. Once a window expires it can no longer be undone, only kept, and the docs describe closing it as something anyone can do after expiry. When a window is closed, the hook uses ETH it holds to buy back KLN and burn it.

That design gives the hook two jobs at once: it is the market's liquidity and it is a trader that periodically buys from that market. Whenever a contract trades on its own behalf, the question an auditor must ask is simple: who decides when it trades, and at what price?

Root Cause: A Permissionless Trigger Meets an Unbounded Swap

Two properties, each defensible on its own, combined into the bug.

1. Anyone can close an expired window

Making accept() permissionless after expiry is a reasonable liveness choice. Nobody wants windows stuck open because the buyer went offline. But it also means the timing of the buyback is chosen by whoever calls it, including someone who has just moved the price.

2. The buyback accepts any price

Per Defimon's analysis, the call chain is accept → _closeWindow → _buyBack(), and the buyback swaps the hook's ETH into the pool with sqrtPriceLimitX96 = MIN_SQRT_PRICE + 1. In Uniswap v4 that limit is the furthest price the swap is allowed to move to. Setting it to the extreme bound tells the PoolManager "fill me at any price".

The simplified sketch below is our own illustration of the pattern, not Kolan's verified source:

// Simplified illustration of the vulnerable pattern (not verbatim Kolan code)
function accept(uint256 id) external {
    Window storage w = windows[id];
    require(block.timestamp >= w.expiry || msg.sender == w.owner, "WindowStillOpen");
    _closeWindow(id);
}

function _closeWindow(uint256 id) internal {
    uint256 ethForBuyback = windows[id].premium / 2;
    delete windows[id];
    _buyBack(ethForBuyback);
}

function _buyBack(uint256 ethIn) internal {
    // ETH -> KLN, exact input, burn the output
    BalanceDelta delta = poolManager.swap(
        key,
        IPoolManager.SwapParams({
            zeroForOne: true,
            amountSpecified: -int256(ethIn),
            sqrtPriceLimitX96: TickMath.MIN_SQRT_PRICE + 1 // no real limit
        }),
        ""
    );
    _settleAndBurn(delta);
}

Nothing in this path compares the current spot price with a reference price, a TWAP or a minimum output. The amount of KLN the hook receives is whatever the pool gives it at that moment.

The Attack, Step by Step

The figures below come from Defimon's alert and the transaction breakdown published by ChainBounty; we have rounded them.

Flash loan. The attacker borrows 6.7 WETH from Balancer.
Pump the spot price. The borrowed ETH buys KLN, pushing the KLN price in the pool up sharply. The attacker now holds a pile of KLN bought before the buyback.
Force the buyback. The attacker calls accept(10) and accept(42) on two expired windows. Each one closes a window and triggers _buyBack(), which spends the hook's ETH buying KLN at the inflated price and burns it. In total about 2.31 ETH leaves the hook.
Dump into the richer pool. The pool now holds the attacker's ETH plus the hook's buyback ETH. The attacker sells the KLN from step 2 back into it.
Repay and keep the difference. The flash loan is repaid inside the same transaction, and roughly 1.28 ETH is left over as profit.

The gap between the hook's 2.31 ETH outflow and the 1.28 ETH profit is worth spelling out. ChainBounty's write-up rightly separates the two: one is what the hook lost, the other is what the attacker kept. The rest went to swap fees, the token's 1% tax and price impact. Reporting "2.31 ETH stolen" or "1.28 ETH lost" alone would both be misleading.

This is the classic sandwich of a protocol-owned trade. Usually MEV bots sandwich users; here the victim was the protocol's own treasury logic, and the attacker didn't even need to wait for it to trade. They could make it trade on demand.

Why This Keeps Happening in Uniswap v4 Hooks

We covered how hooks work in Uniswap v4 Hooks: How They Work and Where They Break, and two recent incidents on this blog, the GoldPesa GPXHooks rebalance drain and the one-wei share vault exploit, point at the same theme: once a hook holds value and acts on its own, it inherits every risk of an on-chain trader.

Hooks make this easy to get wrong for three reasons:

Spot price is one call away. getSlot0() and an unbounded swap are the path of least resistance. A safe price needs extra work.
Flash loans are cheap on Ethereum. Moving a thin pool costs only the fees, and a new token pool is almost always thin.
"Permissionless" is treated as a feature, without checking what the permissionless caller can make the contract do at that moment.

Impact

Direct loss: about 2.31 ETH of hook reserves, roughly $5.4K at the time per Defimon.
Attacker profit: about 1.28 ETH, roughly $3.0K.
Scope: the hook is ownerless and immutable, so there is no admin fix. Any remaining expired window can be closed the same way as long as reserves and a manipulable pool remain. At the time of writing we found no public remediation statement from Kolan.

Mitigations and Audit Lessons

For hook developers

Never let protocol-owned swaps run at an unbounded price. Derive sqrtPriceLimitX96 from a reference price (a TWAP, an oracle, or the price recorded when the window opened) and revert if the spot price is too far away.
Enforce a minimum output. Compute the expected KLN for the ETH spent and require the swap to return at least, say, 98% of it.
Separate "close" from "spend". Let anyone mark a window as expired, but queue the buyback and execute it in batches, or only when the spot price is close to the TWAP.
Check for same-block manipulation. If the pool price has moved more than a set threshold in the current block, skip or defer the buyback.

A hardened version of the buyback could look like this (again illustrative):

function _buyBack(uint256 ethIn) internal {
    uint160 ref = _twapSqrtPrice(30 minutes);              // manipulation-resistant reference
    uint160 limit = uint160(uint256(ref) * 9_900 / 10_000); // allow ~1% adverse move
    (uint160 spot,,,) = poolManager.getSlot0(key.toId());
    if (spot < limit) {
        pendingBuyback += ethIn; // defer instead of trading into a manipulated pool
        return;
    }
    BalanceDelta delta = poolManager.swap(
        key,
        IPoolManager.SwapParams({
            zeroForOne: true,
            amountSpecified: -int256(ethIn),
            sqrtPriceLimitX96: limit
        }),
        ""
    );
    require(uint128(delta.amount1()) >= _minOut(ethIn, ref), "Slippage");
    _settleAndBurn(delta);
}

For auditors

List every place the contract trades its own funds and, for each one, write down who can trigger it and what price it accepts. If the answers are "anyone" and "any", it is a finding.
Grep for extreme price limits. MIN_SQRT_PRICE + 1, MAX_SQRT_PRICE - 1 and amountOutMin = 0 are fine in tests and in user-facing routers where the user sets the bound. Inside protocol logic they are red flags.
Write the flash-loan test. A Foundry test that borrows, moves the pool, calls the permissionless function and checks the hook's balance takes under an hour and would have caught this.

Our smart contract security checklist includes these slippage and price-source checks for any contract that swaps.

Key Addresses

Attack transaction: 0x7b131926e6f06491ae1aead3e419b208c8aa70ed7898e8c5a33d9f52e40915a9
Attacker: 0x8df735014eab81905e76b87ef0c069bd8e0ae382
Victim hook (KolanHook): 0x0136feCf49E0217BFd2D9551E8e7b05f174Ba8eC
Token (KLN): 0x2CADc4F2660Bb77a118b0e74fC9E48E935b3a1bF

Sources

Defimon Alerts on X: loss figures, call chain and transaction
ChainBounty: KolanHook transaction breakdown: exact ETH flows
Telem incident summary
Kolan contract reference and technical FAQ: contract design and addresses

Closing Thoughts

KolanHook lost a few thousand dollars, but its design is not unusual. Plenty of new hooks buy back, rebalance or compound with their own funds, and many of them let anyone trigger it. If your hook trades, the price it accepts is part of your security model, not a gas optimization you can skip.

Building a Uniswap v4 hook or a token with automated buybacks? Contact Panda Security for a review before launch, or see our audit pricing.

Smart Contract Security Checklist for Web3 Developers

PandaSecurity — Fri, 16 Oct 2026 01:32:36 +0000

Originally published at Smart Contract Security Checklist for Web3 Developers.

A smart contract can look simple in a code editor and still hold millions of dollars in user funds.

That is one of the uncomfortable realities of Web3 development. A function may only be 20 lines long, but a small mistake in accounting, permissions, token handling, or price calculations can become an exploitable path once the contract is deployed.

The numbers make the risk difficult to ignore.

Immunefi reported more than $1.46 billion lost to hacks across 192 incidents in 2024. CertiK reported $3.35 billion in losses across Web3 security incidents in 2025, although the 2025 figure was heavily affected by several exceptionally large attacks.

This does not mean every smart contract needs an enormous security team.

It does mean that security should be considered during development rather than added immediately before deployment.

This checklist covers the areas Web3 developers should review before putting a smart contract into production.

Smart Contract Security Checklist

Before deployment, make sure you can answer "yes" to the following questions:

[ ] Are all privileged functions properly protected?
[ ] Can an attacker manipulate an oracle or price source?
[ ] Are external calls handled safely?
[ ] Have reentrancy paths been considered?
[ ] Are token balances and accounting calculated correctly?
[ ] Are ERC-20 edge cases handled?
[ ] Are flash-loan-assisted attacks possible?
[ ] Are upgrade and initialization functions protected?
[ ] Are signatures and replay protection implemented correctly?
[ ] Are emergency functions restricted and tested?
[ ] Have important invariants been tested?
[ ] Has the contract been tested with malicious inputs?
[ ] Have dependencies and compiler versions been reviewed?
[ ] Is the deployment configuration secure?
[ ] Is there a monitoring and incident-response plan?

The sections below explain why each item matters.

1. Review Access Control First

Access control is one of the highest-impact areas in smart contract security.

OWASP's 2025 Smart Contract Top 10 places Access Control Vulnerabilities at #1. Its analysis of 2024 incidents attributed approximately $953.2 million in losses to access-control vulnerabilities.

That makes permission checks one of the first things developers should review.

Start by identifying every function that can change important protocol state.

For example:

function mint(address to, uint256 amount) external {
    _mint(to, amount);
}

This may look harmless, but if mint() is supposed to be an administrative operation, anyone can call it.

A safer implementation might be:

function mint(address to, uint256 amount)
    external
    onlyRole(MINTER_ROLE)
{
    _mint(to, amount);
}

But adding onlyRole() is not the end of the review.

You also need to understand:

Who receives the role?
Who can grant the role?
Who can revoke it?
Can the role administrator be changed?
Can the owner replace the role manager?
Can an upgrade bypass the access-control system?
Is the privileged account an EOA or multisig?

Ethereum's security documentation recommends carefully designing access control and notes that role-based access control and multisig administration can reduce single points of failure.

Access-control checklist

Review every function that can:

Mint or burn tokens
Transfer protocol-owned funds
Change fees
Change oracle addresses
Change implementation contracts
Pause or unpause the protocol
Change collateral parameters
Change liquidation parameters
Modify trusted contracts
Withdraw accumulated fees
Upgrade contracts

A useful audit question is:

"What happens if an attacker obtains this role?"

If the answer is "the attacker can drain the protocol", that role deserves particularly strong protection.

2. Check Upgradeability Carefully

Upgradeable contracts introduce another layer of security assumptions.

A proxy system may separate:

User
  ↓
Proxy
  ↓
Implementation

That means the security of the application depends not only on the implementation contract but also on the proxy and upgrade mechanism.

Check:

Who controls the proxy?
Who can upgrade the implementation?
Is the upgrade authority a multisig?
Is there a timelock?
Can the implementation be initialized again?
Can an attacker call initialization directly?
Are storage layouts compatible?
Can an upgrade change critical permissions?
Is there an emergency upgrade mechanism?

A common mistake is focusing only on the business logic while ignoring the upgrade path.

For example:

function upgradeTo(address newImplementation)
    external
{
    implementation = newImplementation;
}

If this function is not properly protected, the entire security model of the protocol can collapse.

OpenZeppelin specifically recommends treating upgrade mechanisms and administrative privileges as important parts of the security architecture.

3. Protect Initializers

Upgradeable contracts often use an initializer instead of a constructor.

For example:

function initialize(address admin) external {
    owner = admin;
}

If this function can be called more than once, an attacker may be able to take control of the contract.

A common pattern is:

function initialize(address admin)
    external
    initializer
{
    owner = admin;
}

But developers should still verify the complete initialization flow.

Check:

Can initialization happen twice?
Can an attacker initialize an implementation contract?
Is the proxy initialized immediately after deployment?
Are all inherited contracts initialized?
Can initialization be front-run?
Are initialization parameters validated?

Initialization bugs are especially dangerous because they can effectively turn deployment into an ownership race.

4. Review Reentrancy

Reentrancy is one of the classic smart contract vulnerabilities, and it remains relevant today.

The basic problem occurs when a contract makes an external call before updating its own state.

Consider:

function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount);

    payable(msg.sender).call{value: amount}("");

    balance[msg.sender] -= amount;
}

An attacker-controlled contract can potentially call withdraw() again before the balance is updated.

The safer pattern is generally:

function withdraw(uint256 amount) external {
    require(balance[msg.sender] >= amount);

    balance[msg.sender] -= amount;

    (bool success, ) =
        payable(msg.sender).call{value: amount}("");

    require(success);
}

This follows the Checks-Effects-Interactions pattern.

Ethereum's official security documentation still recommends this approach when dealing with external calls and reentrancy.

But don't only search for `call()`

Modern reentrancy reviews should also consider:

ERC-777 hooks
ERC-721 callbacks
ERC-1155 callbacks
ERC-4626 interactions
Flash-loan callbacks
DEX callbacks
Cross-contract calls
Read-only reentrancy

A contract does not need to explicitly call:

msg.sender.call(...)

to have a reentrancy problem.

The important question is:

"Can control flow leave the current contract before critical state is finalized?"

5. Review External Calls

External calls are trust boundaries.

Whenever your contract interacts with another contract, ask:

What contract am I calling?
Who controls it?
What can it call back?
What assumptions am I making about its return value?
Can it revert?
Can it consume excessive gas?
Can it manipulate state before returning?

For example:

token.transfer(user, amount);

is not necessarily equivalent to:

SafeERC20.safeTransfer(token, user, amount);

ERC-20 implementations are not always perfectly consistent.

Some tokens return false.

Some return no value.

Some have unusual transfer behavior.

Using battle-tested libraries reduces the amount of token-specific behavior your protocol needs to handle itself. Ethereum's security guidance recommends using well-tested libraries rather than repeatedly implementing common primitives from scratch.

6. Don't Assume Every ERC-20 Behaves the Same

One of the most common mistakes in DeFi development is treating ERC-20 as if every token follows exactly the same behavior.

Your contract may interact with tokens that have:

Fee-on-transfer mechanics
Rebasing
Transfer restrictions
Blacklists
Pausable transfers
Non-standard return values
Decimals other than 18
Upgradeable implementations
Callback-like behavior

Consider:

uint256 before = token.balanceOf(address(this));

token.transferFrom(
    msg.sender,
    address(this),
    amount
);

uint256 received = amount;

The contract assumes it received exactly amount.

That assumption may not always hold.

A safer accounting model may measure the actual balance difference:

uint256 before = token.balanceOf(address(this));

token.safeTransferFrom(
    msg.sender,
    address(this),
    amount
);

uint256 received =
    token.balanceOf(address(this)) - before;

Whether this approach is appropriate depends on the protocol's intended token model, but the important point is to make the assumption explicit.

7. Check Oracle Security

Oracle manipulation has become one of the most important DeFi attack surfaces.

OWASP's 2025 Smart Contract Top 10 ranks Price Oracle Manipulation #2.

Any protocol using prices should answer:

Where does the price come from?
Can users influence the price?
Is the source based on a single pool?
What liquidity does the pool have?
Is the price based on spot or historical data?
Is a TWAP being used?
What happens when the oracle becomes stale?
What happens if the oracle returns zero?
What happens if the price moves significantly in one block?

A dangerous pattern is relying directly on a low-liquidity AMM spot price.

For example:

uint256 price =
    reserve1 * 1e18 / reserve0;

If an attacker can temporarily move the reserves, the protocol may use a manipulated price.

The problem becomes much more serious when the manipulated price controls:

Borrowing capacity
Liquidation prices
Collateral valuation
Share minting
Redemption amounts
LP token valuation

8. Review Flash-Loan Attack Paths

Flash loans do not create vulnerabilities by themselves.

They make existing vulnerabilities much easier to exploit.

An attacker can borrow a large amount of capital, manipulate temporary protocol state, execute an exploit, and repay the loan within the same transaction.

When reviewing a DeFi protocol, ask:

"What can an attacker do if they temporarily have $100 million?"

Then test:

Price manipulation
Governance voting
Collateral deposits
Liquidations
Reward calculations
Share-price manipulation
LP token pricing
Reserve manipulation
Temporary liquidity attacks

OWASP includes Flash Loan Attacks in its 2025 Smart Contract Top 10.

The important thing is not simply checking whether the protocol supports flash loans.

The real question is whether protocol logic incorrectly assumes that capital must come from the attacker's own wallet.

9. Check Accounting Invariants

Many serious DeFi vulnerabilities are not obvious "Solidity bugs".

They are accounting bugs.

For example:

shares = assets * totalShares / totalAssets;

may look mathematically correct.

But what happens when:

totalAssets = 0

or:

totalShares = 0

or:

assets * totalShares

overflows?

Even when Solidity prevents arithmetic overflow, incorrect ordering and rounding can still create exploitable economic behavior.

For every financial function, define the invariant first.

For example:

Total user balances <= protocol assets

or:

Shares minted <= proportional contribution

or:

Debt cannot become negative

Then test whether an attacker can violate the invariant.

This approach is often more productive than simply searching for known vulnerability patterns.

10. Pay Special Attention to ERC-4626 Vaults

ERC-4626 vaults deserve their own checklist.

Review:

deposit()
mint()
withdraw()
redeem()
previewDeposit()
previewMint()
previewWithdraw()
previewRedeem()
convertToShares()
convertToAssets()

Then compare the accounting between these functions.

Important questions include:

Can the first depositor manipulate the share price?
Can donations change the exchange rate?
Are previews consistent with execution?
Are rounding directions correct?
Can assets be lost due to rounding?
Are fees included consistently?
Can totalAssets() be manipulated?
Can external yield change the accounting unexpectedly?
Are pending withdrawals handled correctly?

For vaults, it is often useful to test sequences rather than individual calls:

deposit
→ donate
→ deposit
→ withdraw
→ redeem

Many accounting vulnerabilities only appear after several state transitions.

11. Validate All User Inputs

Never assume users will provide reasonable parameters.

Check:

require(amount > 0);
require(receiver != address(0));
require(deadline >= block.timestamp);
require(price > 0);

depending on the application.

Look for:

Zero addresses
Zero amounts
Extremely large values
Duplicate IDs
Invalid enum values
Expired deadlines
Invalid signatures
Invalid array lengths
Unexpected array ordering
Unsupported tokens
Unsupported chains

OWASP's 2025 ranking places Lack of Input Validation at #4.

A good rule is:

Validate assumptions at the boundary where the value enters the system.

Don't allow invalid state to propagate through several contracts and only fail later.

12. Check Signature Verification

Protocols using off-chain signatures should review:

Who signed?
What exactly was signed?
Which chain?
Which contract?
What nonce?
What deadline?
Can the signature be replayed?

For example, a signed message should generally bind itself to the intended domain.

Important parameters often include:

chainId
verifyingContract
nonce
deadline

Without replay protection, a valid signature can potentially be reused.

Also review:

EIP-712 domain separation
ERC-1271 contract signatures
Signature malleability
Nonce management
Deadline handling
Cross-chain replay

Do not assume:

ecrecover(...)

alone provides a complete signature-security model.

13. Be Careful With `tx.origin`

Avoid using:

require(tx.origin == owner);

for authorization.

tx.origin represents the original transaction initiator, not necessarily the contract directly interacting with your contract.

For access control, msg.sender is normally the appropriate primitive:

require(msg.sender == owner);

Even then, the overall permission architecture still needs to be reviewed.

14. Review Denial-of-Service Risks

Security is not only about stealing money.

An attacker may also make an important function unusable.

Common examples include:

for (uint256 i = 0; i < users.length; i++) {
    ...
}

If users.length can grow without bounds, eventually the function may exceed the block gas limit.

Review:

Unbounded loops
Large arrays
User-controlled iteration
Failed external calls
DoS through reverting receivers
Forced ETH
Storage growth
Queue processing

OWASP includes Denial of Service in its smart contract security categories.

15. Don't Ignore `selfdestruct`, ETH Transfers, and Forced ETH

Developers sometimes assume:

address(this).balance

exactly represents the ETH deposited through the protocol.

That assumption can be wrong.

ETH can be forced into a contract through mechanisms outside the normal deposit flow.

Therefore, accounting should generally not depend blindly on:

address(this).balance

when exact internal accounting is required.

Instead, distinguish between:

Protocol accounting

and:

Actual blockchain balance

and explicitly decide how unexpected funds should be handled.

16. Review Compiler and Dependency Versions

The Solidity version matters.

Before deployment, check:

Solidity version
OpenZeppelin version
External libraries
Compiler settings
Optimizer settings
Proxy tooling
Build configuration

Do not blindly copy an old contract and change:

pragma solidity ...

without understanding the differences between compiler versions.

Also avoid unnecessary custom implementations of common primitives.

For example, if a well-tested library already provides:

ERC20
AccessControl
SafeERC20
ReentrancyGuard
ECDSA
Math

there is usually little value in rewriting them unless there is a specific reason.

Ethereum's security guidance similarly recommends well-tested libraries and dependency management.

17. Write Tests for Attackers, Not Just Users

A normal unit test might look like:

Alice deposits 100 ETH
Alice withdraws 100 ETH

That proves the happy path works.

Security tests should look more like:

Attacker deposits 1 wei
Attacker manipulates price
Attacker calls function twice
Attacker uses a flash loan
Attacker passes address(0)
Attacker reenters callback
Attacker uses an expired signature
Attacker calls function from an unauthorized account

The difference is important.

A good security test suite should deliberately try to break the protocol.

18. Test Invariants and Properties

Unit tests answer:

"Does this example work?"

Invariant tests answer:

"Can this important property ever become false?"

For example:

sum(userBalances) <= totalAssets

or:

totalSupply cannot decrease unexpectedly

or:

only authorized addresses can modify protocol parameters

Tools such as fuzzing and invariant testing can explore many combinations that manually written test cases will never cover.

Ethereum's security guidance specifically recommends extensive testing and tools such as Slither, Echidna, and Manticore as part of the security process.

19. Run Static Analysis — But Don't Stop There

Static analyzers are useful for catching common patterns.

For example:

slither .

can identify issues involving:

Reentrancy
Dangerous calls
Access control
Unused return values
Shadowing
Incorrect Solidity patterns
Uninitialized variables

But a clean Slither report does not mean the protocol is secure.

Static analysis is much better at finding:

known code patterns

than:

incorrect business logic

A contract can pass static analysis and still have a critical economic vulnerability.

20. Perform Manual State-Transition Analysis

This is where experienced security review becomes especially valuable.

Instead of reading functions independently, follow how state changes.

For example:

deposit()
    ↓
mint shares
    ↓
accrue yield
    ↓
borrow()
    ↓
liquidate()
    ↓
repay()
    ↓
withdraw()

Ask:

"Can I reach an unexpected state by combining these functions?"

Many vulnerabilities exist not inside one function, but in the interaction between several apparently safe functions.

This is especially important for:

Lending protocols
Staking systems
Vaults
AMMs
Restaking protocols
Governance systems
Cross-chain bridges

21. Review Deployment Configuration

A secure contract can still be deployed insecurely.

Before mainnet deployment, verify:

Correct chain ID
Correct token addresses
Correct oracle addresses
Correct admin address
Correct proxy implementation
Correct initialization parameters
Correct fee configuration
Correct multisig
Correct ownership transfer
Correct pause configuration

A surprisingly common failure mode is deploying correct code with incorrect parameters.

Create a deployment checklist and verify every address before sending the transaction.

22. Verify Contracts on the Block Explorer

After deployment:

Deploy
↓
Initialize
↓
Verify source
↓
Check ownership
↓
Check implementation
↓
Check roles
↓
Check configuration

Source verification makes the deployed bytecode easier to inspect and allows other researchers to review the actual production contract.

Do not assume the deployment script succeeded simply because the transaction succeeded.

Verify the resulting state on-chain.

23. Monitor the Contract After Deployment

Security does not end when the contract is deployed.

Monitor events and important state changes such as:

OwnershipTransferred
RoleGranted
RoleRevoked
Upgraded
Paused
Unpaused
OracleUpdated
FeeUpdated
Large withdrawals
Large deposits
Unexpected transfers

Ethereum's security guidance also recommends monitoring deployed contracts and having an incident-response plan.

A vulnerability discovered quickly is much easier to contain than one discovered after an attacker has drained the protocol.

24. Keep an Emergency Response Plan

Every protocol handling meaningful value should know what happens after an exploit.

For example:

Suspicious transaction
        ↓
Alert
        ↓
Security team investigation
        ↓
Pause if appropriate
        ↓
Identify affected contracts
        ↓
Assess attacker access
        ↓
Contact infrastructure / exchanges / security teams
        ↓
Prepare remediation

The exact process depends on the protocol.

The important thing is to decide before the incident happens.

A Practical Pre-Deployment Checklist

Here is a shorter version you can keep next to your codebase.

Architecture

[ ] Attack surface documented
[ ] Trust assumptions documented
[ ] External dependencies identified
[ ] Upgrade architecture reviewed
[ ] Admin architecture reviewed

Access Control

[ ] All privileged functions identified
[ ] onlyOwner / roles verified
[ ] Role administrators reviewed
[ ] Ownership transfer tested
[ ] Multisig configuration verified
[ ] Timelock considered for sensitive operations

DeFi Logic

[ ] Oracle manipulation tested
[ ] Flash-loan attack paths tested
[ ] Liquidation logic tested
[ ] Interest calculations tested
[ ] Share accounting tested
[ ] Rounding reviewed
[ ] Donation attacks considered

Token Handling

[ ] ERC-20 return values handled
[ ] Fee-on-transfer behavior considered
[ ] Rebasing tokens considered
[ ] Decimals handled correctly
[ ] Zero address checks implemented
[ ] Token approval flow reviewed

External Calls

[ ] Reentrancy reviewed
[ ] Callbacks reviewed
[ ] Return values checked
[ ] Untrusted contracts identified
[ ] DoS through external calls considered

Upgradeability

[ ] Proxy admin secured
[ ] Implementation verified
[ ] Initializer protected
[ ] Storage layout checked
[ ] Upgrade authorization tested
[ ] Upgrade events monitored

Testing

[ ] Unit tests
[ ] Fuzz tests
[ ] Invariant tests
[ ] Negative tests
[ ] Access-control tests
[ ] Reentrancy tests
[ ] Economic attack tests
[ ] Static analysis

Deployment

[ ] Correct chain
[ ] Correct addresses
[ ] Correct oracle
[ ] Correct admin
[ ] Correct initialization
[ ] Contract verified
[ ] Roles verified
[ ] Monitoring enabled
[ ] Incident response prepared

The Most Important Part of Smart Contract Security

A checklist is useful, but it should not become a substitute for understanding the protocol.

The most dangerous bugs are often not obvious Solidity mistakes.

They are usually assumptions such as:

"This price cannot be manipulated."

"This function can only be called by the frontend."

"The token always transfers exactly the requested amount."

"Nobody can borrow enough money to do this."

"The owner would never abuse this function."

"This callback cannot reenter."

"This value can never be zero."

"This contract will always be initialized correctly."

An attacker does not need to respect these assumptions.

They only need to find one that the code fails to enforce.

That is why a strong smart contract security review combines automated analysis, adversarial testing, economic reasoning, and manual code review.

Final Thoughts

Smart contract security is not a single step at the end of development.

It starts with architecture, continues through implementation and testing, and remains important after deployment.

The current security data makes that clear. OWASP's 2025 Smart Contract Top 10 puts access control, oracle manipulation, logic errors, input validation, and reentrancy among the major smart contract risks.

For developers, the practical approach is straightforward:

Define the security assumptions.

Turn those assumptions into invariants.

Try to break those invariants.

Then verify the implementation and deployment configuration.

A smart contract should not be considered secure simply because it compiles, passes unit tests, or has no obvious static-analysis warnings.

The real question is much harder:

Can an untrusted user make the protocol enter a state that its designers never intended?

That is the question a good security review should answer.

References

OWASP Smart Contract Top 10 — 2025
Ethereum Foundation — Smart Contract Security
OpenZeppelin Contracts — Access Control
Immunefi — Crypto Losses 2024 Report
CertiK — Hack3d Web3 Security Report 2025

Inside the Likwid Exploit: One Missing pairDelta, 74 BNB Gone

PandaSecurity — Fri, 16 Oct 2026 01:32:01 +0000

Originally published at Inside the Likwid Exploit: One Missing pairDelta, 74 BNB Gone.

Another day, another nine-figure headline — except this one wasn't nine figures. Likwid lost 74.31 BNB, which is small by exploit standards, and that's exactly what makes it worth studying. This wasn't a flash-loan-oracle masterpiece or a governance takeover. It was one struct field that nobody assigned.

At Panda Security, we keep saying the same thing: the most expensive bugs are rarely the cleverest ones. They're the boring ones that sit in plain sight because everyone assumes someone else already checked. Likwid is case in point.

Let's break it down.

What Likwid Actually Is

Before we talk about the bug, it helps to understand the machine. Likwid runs a leveraged margin trading system on BNB Chain, split into two core contracts:

LikwidVault — the central ledger. It custodies all tokens and tracks several different "reserves" per pool:
- realReserves — the actual tokens held.
- pairReserves — the AMM pair reserves, used for pricing swaps.
- mirrorReserves — the borrow/demand side.
- lendReserves — the lend/collateral supply side.
- truncatedReserves — a smoothed baseline for price movement.
LikwidMarginPosition — the user-facing position manager. Users open leverage, borrow, repay, close, and liquidate here. It doesn't hold funds; it computes a set of deltas and hands them to the vault.

The key architectural detail: the vault doesn't calculate anything about a margin operation on its own. The position manager computes a MarginBalanceDelta and passes it in. The vault applies it. That's a clean separation of concerns — and, as we'll see, a sharp knife.

struct MarginBalanceDelta {
    MarginActions action;
    bool marginForOne;
    uint128 marginTotal;
    uint256 marginFeeAmount;
    uint256 swapFeeAmount;
    BalanceDelta marginDelta;
    BalanceDelta mirrorDelta;
    BalanceDelta pairDelta;   // <- the field that matters
    BalanceDelta lendDelta;
    BalanceDelta fundsDelta;
}

If you've audited anything in this style — Uniswap v4 hooks, AMM accounting engines, delta-based vaults — alarm bells should already be ringing. When a caller supplies the price-moving deltas, every single one of them has to be present on every path. Miss one and you've built an arbitrage printer.

Likwid missed one.

The Attack Path, Short Version

The attacker repeatedly called LikwidMarginPosition.margin, forcing the leverage=0 (collateral + borrow) branch.
That branch caps the borrow amount with SwapMath.getAmountOut(pairReserves, ...).
But the borrow never updates pairReserves — the swap's price impact is never written back to the pool.
Every one of the 14 cycles received the same fixed quote (4.7857 BNB): borrowing at the first trade's marginal price, with zero price impact.
Roughly 211.8M TOKEN was settled at that stale price, draining BNB out of realReserves.
Profit: 74.31 BNB.

The vault's reserve consistency check passed the entire time. Collateral flowed into lendReserves, debt flowed into mirrorReserves, and the pair reserves sat flat. On paper, the books balanced.

Root Cause: The Leverage=0 Branch Forgot pairDelta

Here is the vulnerable function, essentially verbatim from src/LikwidMarginPosition.sol:

function _executeAddCollateralAndBorrow(
    IMarginPositionManager.MarginParams memory params,
    PoolState memory poolState,
    MarginPosition.State storage position,
    MarginBalanceDelta memory delta,
    uint256 minBorrowLevel
) internal returns (uint256 borrowAmount) {
    (uint256 borrowMaxAmount,) = SwapMath.getAmountOut(
        poolState.pairReserves, poolState.lpFee, !position.marginForOne, params.marginAmount
    );
    if (minBorrowLevel > PerLibrary.ONE_MILLION) {
        borrowMaxAmount = Math.mulDiv(borrowMaxAmount, PerLibrary.ONE_MILLION, minBorrowLevel);
    }
    uint256 borrowRealReserves = poolState.realReserves.reserve01(!position.marginForOne);
    borrowMaxAmount = Math.min(borrowMaxAmount, borrowRealReserves * 20 / 100);
    if (params.borrowAmount == type(uint256).max) params.borrowAmount = borrowMaxAmount.toUint128();
    if (params.borrowAmount > borrowMaxAmount) BorrowTooMuch.selector.revertWith();
    borrowAmount = params.borrowAmount;

    // ... cumulative values, mirror ratio checks, position.update ...

    int128 amount = -params.marginAmount.toInt128();

    if (position.marginForOne) {
        amount1Delta = amount;
        amount0Delta = borrowAmount.toInt128();
        delta.lendDelta = toBalanceDelta(0, amount);
        delta.mirrorDelta = toBalanceDelta(-borrowAmount.toInt128(), 0);
    } else {
        amount0Delta = amount;
        amount1Delta = borrowAmount.toInt128();
        delta.lendDelta = toBalanceDelta(amount, 0);
        delta.mirrorDelta = toBalanceDelta(0, -borrowAmount.toInt128());
    }
    delta.marginDelta = toBalanceDelta(amount0Delta, amount1Delta);
    // NOTE: delta.pairDelta is never assigned here.
}

Notice what's set: lendDelta, mirrorDelta, marginDelta. Notice what's missing: pairDelta.

Because MarginBalanceDelta is a memory struct, pairDelta defaults to zero. And the vault does exactly what it's told:

// LikwidVault -> Pool.margin
ReservesLibrary.UpdateParam[] memory deltaParams = new ReservesLibrary.UpdateParam[](4);
deltaParams[0] = ReservesLibrary.UpdateParam(ReservesType.REAL, marginDelta + protocolDelta);
deltaParams[1] = ReservesLibrary.UpdateParam(ReservesType.PAIR, params.pairDelta + protocolDelta);
deltaParams[2] = ReservesLibrary.UpdateParam(ReservesType.LEND, params.lendDelta);
deltaParams[3] = ReservesLibrary.UpdateParam(ReservesType.MIRROR, params.mirrorDelta);

With pairDelta == 0, the pair reserves never move. The next call to getAmountOut(pairReserves, ...) reads the exact same reserves and returns the exact same quote. Repeat 14 times. That's the whole exploit.

The Tell: Asymmetric Assignment Across Branches

This is the part that makes the bug almost embarrassing — and genuinely instructive.

Look at the leverage > 0 branch in the same file:

if (position.marginForOne) {
    delta.marginDelta = toBalanceDelta(0, amount);
    delta.pairDelta = toBalanceDelta(-borrowAmount.toInt128(), marginWithoutFee.toInt128());
    delta.lendDelta = toBalanceDelta(0, lendAmount);
    delta.mirrorDelta = toBalanceDelta(-borrowAmount.toInt128(), 0);
} else {
    delta.marginDelta = toBalanceDelta(amount, 0);
    delta.pairDelta = toBalanceDelta(marginWithoutFee.toInt128(), -borrowAmount.toInt128());
    delta.lendDelta = toBalanceDelta(lendAmount, 0);
    delta.mirrorDelta = toBalanceDelta(0, -borrowAmount.toInt128());
}

_executeAddLeverage sets pairDelta. The close, repay, and liquidateBurn paths set pairDelta. Only _executeAddCollateralAndBorrow — the leverage=0 case — does not.

We checked the repository history: this omission existed from at least October 2025 through the latest main (January 2026). It was never a regression or a merge conflict. It was simply never written.

Our honest take: this is what happens when a codebase grows branch by branch. Each new path copies its neighbors, and the one field that isn't required by the compiler to be set gets silently dropped. Solidity won't warn you. Tests won't warn you unless someone wrote the exact assertion for this exact path. And a delta struct has no invariant baked in that says "if you borrow against pair pricing, you must move pair reserves."

Why the Vault's Safety Check Didn't Save It

Likwid's vault does have a consistency check. _updateReservesConsistent enforces:

realReserves + mirrorReserves == pairReserves + lendReserves - insuranceFunds

So why didn't it revert? Because the leverage=0 deltas happen to satisfy it. Let's verify the change form for marginForOne == false:

marginDelta = (-marginAmount, +borrowAmount)
mirrorDelta = (0, -borrowAmount)
lendDelta = (-marginAmount, 0)
pairDelta = 0

The required identity reduces to marginDelta + mirrorDelta == lendDelta, and:

(-marginAmount, +borrowAmount) + (0, -borrowAmount) = (-marginAmount, 0) = lendDelta  ✓

The books balance. The check is doing its job — it's just checking the wrong thing. It verifies that the totals reconcile, not that the AMM that determines price was updated. Those are different invariants, and conflating them is a common, dangerous shortcut in delta-based designs.

Lessons for Auditors and Builders

We'll say it plainly because it's the whole point of this post:

Every delta field needs a per-path checklist. If a struct field influences price, enumerate every function that should set it and diff them against every function that does. This is mechanical, boring, and exactly how you'd have caught Likwid.
Asymmetric branches are red flags. When if (leverage > 0) and the else branch set different subsets of fields, that asymmetry deserves a written justification. There wasn't one here.
Conservation checks are not price checks. A vault that balances to the wei can still be drained if the oracle or AMM reserves it reads are stale. Validate both.
Pricing reserves and custody must move atomically. Likwid used pairReserves to quote while letting the actual transfer flow through realReserves. The moment those decouple, you have an infinite-arbitrage primitive.
Don't trust caller-supplied deltas blindly — or, if you must, make them provably complete. The vault is only as safe as the weakest manager that can call it.

How Panda Security Thinks About This

At Panda Security, our reviews don't stop at "does the accounting balance." We build invariant maps for delta-based systems: for each state-changing entry point, we list which reserves must move, then we fuzz the paths that shouldn't move them and watch for profitable divergence. A single missing assignment like Likwid's is precisely the kind of bug that falls straight out of that process — no exotic tooling, just disciplined enumeration plus a fuzzer pointed at the right invariant.

We also like to state the uncomfortable truth: audits reduce risk, they don't delete it. Likwid had remediations and audit fixes in its commit history, and this path still slipped through. That's not a reason to skip audits — it's a reason to demand continuous review and on-chain monitoring, not a one-time PDF.

Timeline of Addresses

Attacker EOA: 0x90bde1e0bb16b3deeb9d638acf8d01f19fd2f31e
Attack Contract: 0xc63fb27f52ed8d06673c60c3075b2d3bd26cf4aa
Vulnerable Contract (LikwidMarginPosition): 0x6bec0c1dc4898484b7f094566ddf8bc82ed7abe8
Victim Contract (LikwidVault): 0x065d449ec9d139740343990b7e1cf05fa830e4ba

Closing Thoughts

74 BNB is a rounding error to most funds. But the bug behind it is a masterclass in why "it compiles" and "the books balance" are not security arguments. A struct field defaulted to zero, a branch that forgot to fill it in, and an AMM that priced every borrow off reserves nobody updated. That's it.

If your protocol moves value with caller-supplied deltas, sit down with a spreadsheet today and map every field to every code path. The alternative is writing this exact post-mortem about your own contract — and Panda Security would rather help you before that happens than after.

Found this useful? Follow Panda Security for more Web3 incident breakdowns and practical smart contract audit write-ups.

Uniswap v4 Hooks: How They Work and Where They Break

PandaSecurity — Fri, 16 Oct 2026 01:31:28 +0000

Originally published at Uniswap v4 Hooks: How They Work and Where They Break.

Uniswap v4 went live on January 31, 2025. Nine independent audits covered the core and periphery contracts, and a bug bounty of up to $15.5 million sat on top of that. Four months later, a protocol built on v4 hooks lost roughly $11 million in one exploit chain.

That gap is the whole story of v4. The core was built carefully. The extension surface was handed to everyone, and nobody was forced to build it carefully.

This article walks through how v4 and hooks work from the user's click to final settlement, why the PoolManager exists, what actually changed since v3, and why hook security deserves its own discipline. We'll use the Cork and Bunni exploits as the case studies, because they show two very different ways a hook can fail. At PandaSecurity we've spent a lot of time on this class of bugs, so we'll also say where we think the industry's habits are wrong.

How Uniswap v4 and hooks work, end to end

Start from the user's side. You sign one transaction, and it doesn't go to a pool. It goes to a router. That contract calls PoolManager.unlock(data), and the PoolManager immediately calls back into unlockCallback(data) on the same contract. Everything interesting happens inside that callback.

Inside the callback, the router does roughly this:

Decodes what the user asked for.
Runs one or more liquidity-accessing operations: swap, modifyLiquidity, or donate. Each one moves pool state and creates a delta.
If the pool was created with a hook, the PoolManager calls that hook before and after the operation, depending on which callbacks the hook opted into.
Runs delta-resolving operations: settle, take, mint, burn, clear. These are how the router pays what it owes or collects what it's owed.
Loops back to step 2 as many times as it wants.

When the callback returns, the PoolManager looks at every delta. If any of them is non-zero, the whole transaction reverts with CurrencyNotSettled. Otherwise everyone has paid or been paid correctly, and the result goes back to the user.

Deltas follow a simple sign convention from Uniswap's own docs: a negative delta means the PoolManager is owed tokens, a positive one means the PoolManager owes tokens to someone. A swap typically leaves you negative on the token you sold and positive on the token you bought. Adding liquidity leaves you negative on both sides.

Hooks sit inside this loop at fixed points.

For a swap, beforeSwap runs against pre-swap state and can return a delta of its own plus a fee override. afterSwap runs against post-swap state and can return an adjustment too. Liquidity changes follow the same shape with before and after callbacks for add and remove, and initialize and donate get their own pairs. Whatever deltas the hook returns are folded into the same ledger and have to net to zero by the end, like everything else.

One detail that matters later: which callbacks a hook implements isn't configured in a settings file. It's encoded in the bits of the hook's deployed address. The PoolManager reads those bits to decide what to call. Keep that in mind, because it's a recurring source of bugs.

Why the PoolManager exists, and what really changed from v3

In Uniswap v3, every pool is its own contract, deployed by a factory. A swap that routes through three pools touches three contracts, and tokens physically move between them along the way. Every hop costs gas, and every integration has to reason about which contract holds what at which moment.

v4 replaces that with a singleton. One contract, the PoolManager, holds the state for every pool. A "pool" is no longer a deployment; it's an entry in the PoolManager's storage, keyed by the two currencies, the fee, the tick spacing and the hook address. Creating a pool becomes a storage write instead of a contract deployment, which is why Uniswap Labs says pool creation is up to 99.99% cheaper than before.

The PoolManager also does something a pile of separate pool contracts never could: it keeps a running ledger. That's flash accounting. Every balance-changing operation updates a net delta per currency and per address, and the deltas live in transient storage (the EIP-1153 feature that arrived with the Dencun upgrade). Real token transfers only happen for the net result at the end. According to Uniswap's docs, a multi-hop swap needs just two transfers regardless of how many hops it has, the input token in and the output token out.

Here's our opinion, and we'll defend it: the biggest difference between v3 and v4 is not hooks. It's that v4 changed who you talk to and when money moves. In v3 you talk to a pool and tokens move on every call. In v4 you talk to a ledger, and tokens move once. Hooks are the feature people tweet about, but they're only practical because of this accounting model. If every hook had to move real tokens at every step across many pools, nobody would be able to afford using them, and the reentrancy surface would be unmanageable.

The tradeoff is real, though. All pools now share one vault. That makes the core's correctness more valuable, and it makes every hook that touches the ledger a little more dangerous, because it speaks directly to the same shared accounting.

What v4 actually innovates

Strip away the marketing and v4 brings six genuinely new things:

Hooks. Contracts that run at defined points in a pool's lifecycle. There are 14 permission flags in a hook address, covering before and after callbacks for initialize, add and remove liquidity, swap and donate, plus return-delta flags.
Flash accounting. Net deltas in transient storage, settled once per unlock.
Custom accounting. A hook can return deltas that change what the swap or liquidity change costs. A BeforeSwapDelta that consumes the whole specified amount turns the swap into a no-op against the pool's own curve, so the hook becomes the AMM. This is how people build custom curves on top of v4.
Native ETH. ETH pairs without wrapping, which saves gas on a very common path.
ERC-6909 claims. mint and burn let you hold balances inside the PoolManager instead of transferring tokens out, which helps when the same funds will be used again soon.
Dynamic fees. Hooks can override the LP fee, which opens up volatility-aware and time-aware pricing.

The periphery adds a subscriber mechanism too: a position owner can register a contract that gets notified when liquidity or ownership changes, so staking or incentive programs don't require handing over the position NFT.

What does it add up to? Our reading is that Uniswap stopped being a product and became a platform. The liquidity layer is the protocol. The strategy layer is yours. That's a powerful idea, and Uniswap Labs said more than 150 hooks already existed at launch, across ten chains.

It's also a transfer of risk. Uniswap audited the platform. It can't audit what people build on it.

The security bill for all that flexibility

Let's be precise about where the losses have landed. As far as public incident reports go, the large v4-related losses so far came from hooks and integrations, not from the PoolManager itself. That's a credit to the core. It's also an uncomfortable fact for anyone who thinks "built on audited v4" is a security statement. It isn't. It's a statement about the floor of the building, not the rooms people built on top.

Case 1: Cork Protocol, May 28, 2025 (about $11 million)

Dedaub's write-up and BlockSec's analysis give the clearest picture. Reported figures range from about $11 million to $12 million of wstETH depending on who's counting.

Cork's hook had a beforeSwap function with no check on who was calling it. In normal operation only the PoolManager should call a hook callback. Here, anyone could call it directly, with any parameters they liked, including a pool ID of their own choosing and crafted hookData. The hook also didn't maintain an allowlist of pools it was supposed to serve.

The attacker used that to steer the hook into a path that credited a deposit that never happened, minting tokens out of nothing. A second weakness, a manipulable price ratio near expiry, let them turn those tokens into real wstETH. BlockSec describes it as two independent flaws that combined into one chain.

According to Dedaub, four audit firms worked on Cork, but three of them didn't cover the hook contracts. The fourth likely had the hook in scope and made suggestions that weren't enough to prevent the exploit.

What stands out to us isn't how clever the exploit was. It's how basic the root cause was. "Only the PoolManager may call hook callbacks" is the first thing you write on the whiteboard when you design a hook, and a missing modifier turned it into an eight-figure loss. The audit scoping story is equally telling: the hook was the highest-risk code in the system and got the least attention.

Case 2: Bunni v2, September 2, 2025 (about $8.4 million)

The Bunni incident is the opposite lesson. There was no missing access control and no forged call. Every transaction settled cleanly, every delta netted to zero, and the PoolManager had no objection to anything. The books inside the hook were simply wrong.

BlockSec's breakdown is the best public analysis we've seen. Bunni v2 is an AMM built as a v4 hook that adds rebalancing and rehypothecation on top of concentrated liquidity. It tracks an "idle balance" for each pool. When liquidity is withdrawn, the idle-balance update used a rounding direction that overstated the idle amount. That made the pool's computed available balance of a nearly empty token too small, and the liquidity function then reported less effective liquidity than the pool really had, which makes swaps move the price much further.

The attacker first pushed the pool into a state where one token's active balance was down to 28 wei. They then made 44 tiny withdrawals that dragged it to 4 wei, an 85.7% drop, while burning a negligible share of LP tokens. After that, a pair of swaps in opposite directions exploited the undervalued liquidity and drained value from two pools, a USDC/USDT pool on Ethereum and a weETH/ETH pool on Unichain.

This is the lesson we most want builders to absorb: delta settlement proves that the hook didn't print tokens at the PoolManager boundary. It says nothing about whether the hook's internal accounting is correct. Trail of Bits makes the same point in their guide to building secure v4 hooks: settlement checks that deltas net to zero, not that your sign conventions, rounding or balance buckets are right. A hook with a rounding bug will settle perfectly, right up to the moment it bleeds.

The other failure patterns

Cork and Bunni are the big ones, but the same Trail of Bits write-up lists patterns that keep showing up in reviews:

Permission bits that don't match the code. Because callbacks are encoded in the address, a hook can implement a function whose bit isn't set (never called) or set a bit with no implementation (every call reverts). A missing return-delta bit makes the PoolManager treat the hook's returned delta as zero. One real example in their list: a missing afterSwapReturnDelta bit made every swap revert with CurrencyNotSettled once a dynamic protocol fee was switched on.
User-supplied PoolKey. Pool creation is permissionless, so an attacker can attach your hook to a pool they control, with tokens that run malicious code. A points-farming hook in their examples let deposits route through a malicious pool because it accepted a caller-specified key.
Logic in the wrong callback. beforeSwap sees pre-swap state and afterSwap sees post-swap state. A just-in-time liquidity penalty hook was bypassed because the penalty was computed after the user had already collected fees through a tiny separate liquidity increase.
Shared state and reentrancy. One hook serves many pools, and callbacks run inside a swap. Scratch storage that isn't keyed per pool and caller is an invitation.
Upgradeable hooks. The permission bits are fixed in the address but the implementation behind a proxy can change. Your upgrade admin is part of the trust model.
Denial of service. A revert in optional logic, like reward distribution in afterRemoveLiquidity, can lock users in.

What we check first when we review a v4 hook

Our review of a hook-based system doesn't start with the swap math. It starts with the boundaries:

Who can call each callback? Every one must be restricted to the PoolManager, and unlockCallback must verify the caller too.
Which pools does this hook serve? If the answer is "any pool that points at it", that's a finding.
Do the address permission bits match what the contract implements? Both directions, including return-delta flags.
What are the conservation invariants? No output the accounting didn't charge for, no value from a same-transaction round trip, internal books equal to real balances, and rounding that always favors the pool.
Is every input hostile? PoolKey, hookData, fee inputs and token behavior, including fee-on-transfer and rebasing tokens.
What happens at the extremes? Near-empty balances, dust-size operations repeated many times (Bunni's trick), and manipulated prices.
Who can change the code? Proxies, admin keys and timelocks.

Fuzzing against adversarial pools and tokens belongs on that list too, because several of these bugs are only reachable through sequences no unit test would try.

One more opinion. Teams often ask whether their hook is "safe because Uniswap is audited". We tell them to flip the question. Treat the hook as a standalone protocol that happens to be wired into an AMM. It holds funds, it has an admin, it has its own accounting, and it faces an attacker who can create pools, choose tokens and send dust. That's a full protocol audit scope, and the Cork story shows what happens when it's treated as an appendix.

Key takeaways

v4's real shift is architectural: one PoolManager ledger and flash accounting, with hooks built on top.
The core has held up in public reports so far. Losses have come from hooks.
Cork was a basic access-control failure in code that was under-scoped in audits.
Bunni was an accounting failure that settled perfectly, which is why zero deltas can't be treated as correctness.
Hook security is protocol security. Scope it that way.

If you're building on v4 and want a second pair of eyes on your hook before it holds real money, that's what the PandaSecurity team does. Bring us in before launch, not after the post-mortem.

FAQ

What is the PoolManager in Uniswap v4?
It's the singleton contract that stores the state of every v4 pool and keeps the ledger of what each address owes or is owed during an unlock session. It replaces the one-contract-per-pool design of v3.

What is the biggest difference between Uniswap v3 and v4?
Architecture. v4 uses a single PoolManager and flash accounting, so tokens move once per unlock instead of at every step. Hooks, native ETH and custom accounting build on that foundation.

Are Uniswap v4 hooks safe?
Not automatically. The core contracts were heavily audited, but each hook is separate code with its own accounting and access control. The Cork and Bunni exploits both came from hook-level flaws, not from the PoolManager.

Sources

MCN Labs Exploit Analysis: How a Reward Accounting Bug Led to a $92.6K Loss

PandaSecurity — Fri, 16 Oct 2026 01:30:37 +0000

Originally published at MCN Labs Exploit Analysis: How a Reward Accounting Bug Led to a $92.6K Loss.

MCN Labs reportedly suffered a loss of approximately $92.6K due to an accounting flaw in its LPBonus reward contract.

The vulnerability came from a subtle inconsistency:

The contract used one MSN reserve value when creating the FIST reward index, but another reserve value when calculating how much reward a user could claim.

By manipulating the reserve between these two operations, the attacker was able to receive more FIST than the amount that should have been distributed.

Incident Overview

Protocol: MCN Labs
Estimated Loss: ~$92.6K
Vulnerable Contract: 0x52272524a22f941f5489c1233732797314bb054b
Attacker: 0xb6fff29dd2b5423a159e50877fc4af7a54e76f7a
Root Cause: Inconsistent reserve values in LP reward accounting

According to the reported attack data, the attacker reduced the MSN reserve to approximately:

89.327788899759978606 MSN

during reward accrual.

Before triggering LP removal, the reserve was increased to approximately:

491.113095162589329323 MSN

This difference allowed one LP holder to claim approximately:

1,442,165.713011 FIST

even though the relevant reward increment was funded by only approximately:

940,041.612768 FIST

The Vulnerable Code

The main issue can be found in the way oneshareFIST is updated.

Inside AddFistFee, the contract swaps MSN into FIST and calculates the newly received FIST:

uint256 balanebefore = IBEP20(fist).balanceOf(address(this));

router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
    amountofmsn,
    0,
    path,
    address(this),
    1e40
);

uint256 balanceafter = IBEP20(fist).balanceOf(address(this));

uint256 amount = balanceafter.sub2(balanebefore);

It then updates the global reward index:

oneshareFIST += amount.mul(1e18).div(reservethis);

In simplified form:

Reward Index Increase = FIST Reward / MSN Reserve

This means that when the MSN reserve becomes smaller, the increase in oneshareFIST becomes larger.

The problem appears when rewards are later calculated.

Reward Calculation

CalcPendingUser calculates a user's LP weight using the current reserve:

uint256 newLpbalance = IBEP20(lpaddress).balanceOf(user);
uint256 totalsupplylp = IBEP20(lpaddress).totalSupply();

uint256 poolshare = userAddAmount[user];

if(reserverthis > 0 && totalsupplylp > 0)
    poolshare = newLpbalance.mul(reserverthis).div(totalsupplylp);

The pending reward is then calculated as:

return oneshareFIST
    .sub2(takedFIST[user])
    .mul(poolshare)
    .div(1e18);

The issue is that these two calculations do not necessarily use the same reserve.

During reward accrual:

oneshareFIST ∝ 1 / Reserve_A

During reward claiming:

poolshare ∝ Reserve_B

So the final reward effectively contains:

Reserve_B / Reserve_A

If an attacker can make:

Reserve_A small

and later make:

Reserve_B large

the calculated reward can be amplified.

Attack Flow

The attack can be simplified into five steps.

1. Establish an LP Position

The attacker creates or controls an LP position that participates in the LPBonus reward system.

2. Reduce the MSN Reserve

The attacker manipulates the liquidity state and reduces the relevant MSN reserve.

The reported reserve reached approximately:

89.3278 MSN

3. Trigger Reward Accrual

The protocol receives FIST rewards and updates:

oneshareFIST += amount * 1e18 / reservethis;

Because the reserve is small, the resulting increase in oneshareFIST becomes unusually large.

4. Increase the Reserve

The attacker then changes the liquidity state again.

The reserve reportedly increased to approximately:

491.1131 MSN

5. Trigger LP Removal

When UserRemoveLp is executed, the protocol calculates the user's reward weight using the new, larger reserve.

The previously inflated oneshareFIST is now multiplied by a larger poolshare.

The contract therefore calculates a FIST reward significantly larger than what should have been distributed.

Root Cause

The root cause is not simply "AMM reserve manipulation."

AMM reserves naturally change as users trade and liquidity moves.

The real problem is that the protocol used different reserve snapshots for different parts of the same reward calculation.

The reward index was created using:

Reserve at reward accrual

while the user's reward weight was calculated using:

Reserve at reward settlement

There was no guarantee that these values would remain consistent.

This created an attacker-controlled multiplier inside the reward calculation.

Why This Matters

This is a good example of why DeFi audits need to look beyond individual Solidity functions.

AddFistFee alone does not immediately look catastrophic.

CalcPendingUser alone also looks relatively simple.

The vulnerability only becomes obvious when we follow the complete accounting flow:

Manipulate Reserve
        ↓
Accumulate FIST Reward
        ↓
Update oneshareFIST
        ↓
Change Reserve Again
        ↓
Trigger UserRemoveLp
        ↓
Calculate Reward Using New Reserve
        ↓
Receive Excess FIST

The problem exists across multiple state transitions.

How It Could Be Fixed

The reward system should avoid using independently changing AMM reserve values for reward accrual and settlement.

A more robust design would distribute rewards using a consistent accounting unit such as LP shares:

rewardPerShare +=
    rewardAmount * 1e18 / totalEligibleShares;

User rewards could then be calculated as:

pending =
    userShares
    * (rewardPerShare - userRewardDebt)
    / 1e18;

The important principle is simple:

The denominator used when rewards are distributed and the unit used when rewards are claimed should represent the same accounting quantity.

If reserve-based accounting is required, the protocol should use consistent snapshots rather than reading mutable reserve values at different stages.

Security Lesson

One useful invariant for reward contracts is:

Total newly created reward claims
<=
Total rewards funded

If depositing 940,000 FIST into a reward system can create more than 1.4 million FIST of new claims, something is fundamentally wrong with the accounting.

When auditing DeFi protocols, special attention should be paid whenever reward calculations depend on mutable external state such as:

AMM reserves
token balances
LP total supply
vault share prices
exchange rates
oracle prices

The important question is not only:

Can this value be manipulated?

It is also:

Can the protocol use different versions of this value when creating and later settling the same accounting obligation?

That distinction is exactly what made this vulnerability dangerous.

Conclusion

The MCN Labs incident demonstrates how a relatively small accounting inconsistency can turn into a real loss.

The protocol calculated its FIST reward index using one MSN reserve value and later calculated the user's reward weight using another.

By reducing the reserve during reward accrual and increasing it before settlement, the attacker was able to amplify the reward calculation and extract excess FIST.

At PandaSecurity, we believe these bugs are particularly important because they often do not look dangerous when individual functions are reviewed in isolation.

The Solidity code may execute exactly as intended.

The problem is that the economic equation itself is wrong.

PandaSecurity Team — Smart Contract Security, DeFi Exploit Research, and On-Chain Incident Analysis.

How One Wei of Shares Drained 14,838 DAI: A Uniswap V4 Vault Exploit

PandaSecurity — Fri, 16 Oct 2026 01:30:34 +0000

Originally published at How One Wei of Shares Drained 14,838 DAI: A Uniswap V4 Vault Exploit.

On October 9, 2026, a transaction on Polygon exposed a simple but dangerous accounting flaw in a liquidity vault. The attacker held only one minimal share unit, yet withdrew approximately 14,838.47 DAI from the contract.

This was not a reentrancy exploit, nor did it depend on an obscure arithmetic trick. The failure sat inside what looked like a harmless fallback branch: whenever the strategy reported zero liquidity, the vault transferred its entire token balance to the current redeemer.

Panda Security’s review of the transaction and source code found a clean four-step path. The attacker acquired one share unit, manipulated the pool so that reposition() produced zero liquidity, then called withdraw(). Instead of calculating a proportional payout, the vault emptied its DAI and USDC balances into the attacker’s contract.

Incident overview

Item	Details
Network	Polygon PoS
Exploit time	October 9, 2026, 02:23:42 UTC
Attacker EOA	`0x59Ae3c8d...B64e9884B`
Affected vault	`0x048E8831...e2AF2e5A0`
Exploit contract	`0xc2C6F4F7E1425bE1DCB996175Cf7852bF53c23E2`
Key transaction	`0x5b795dc5...e04a7ff2`
Amount sent by the vault	14,838.466608989135865711 DAI
Final transfer to attacker EOA	Approximately 14,813.548248 USDC

The amount removed from the vault and the attacker’s final proceeds are not identical. The vault paid out roughly 14,838.47 DAI. After swaps, repayment of temporary liquidity, and execution costs, approximately 14,813.55 USDC reached the attacker’s EOA.

The vulnerable code

The flaw is located in the zero-liquidity branch of _withdraw():

function _withdraw(
    uint256 shareAmount,
    address recipient,
    bool addDust
) internal {
    if (liquidity == 0) {
        uint256 daiBal = DAI.balanceOf(address(this));
        uint256 usdcBal = USDC.balanceOf(address(this));

        if (daiBal > 0) DAI.transfer(recipient, daiBal);
        if (usdcBal > 0) USDC.transfer(recipient, usdcBal);

        emit Withdrawn(recipient, shareAmount, daiBal, usdcBal);
        return;
    }

    // The normal path calculates a proportional withdrawal.
}

Under normal conditions, the vault calculates how much liquidity belongs to the redeemer:

uint256 currentTotalShares = totalShares + shareAmount;

uint128 toRemove = uint128(
    uint256(liquidity) * shareAmount / currentTotalShares
);

That proportional calculation disappears when liquidity == 0. The vault simply reads its DAI and USDC balances and transfers everything to the caller.

The code incorrectly treats these two states as equivalent:

No capital is currently deployed as liquidity
                    !=
The current redeemer owns every idle asset

That mistaken assumption is the root cause of the loss.

How the attack worked

Step 1: Acquire one share with one wei of DAI

The transaction’s Deposited event records:

daiAmount    = 1
sharesIssued = 1

DAI uses 18 decimals. The value 1 therefore means one wei of DAI, not one full DAI.

The economic cost was negligible, but this was enough to satisfy the withdrawal checks:

if (shareAmount == 0) revert ZeroAmount();
if (shares[msg.sender] < shareAmount) revert InsufficientShares();

Step 2: Move the pool price and unlock permissionless repositioning

The vault allows an ordinary account to call reposition() when the current tick has moved outside the active range:

if (msg.sender != minter) {
    int24 ct = _getCurrentTick();
    if (ct >= tickLower && ct < tickUpper) {
        revert PositionInRange();
    }
}

Using temporary liquidity, the attacker executed a large swap in the Uniswap V4 pool and pushed the current tick outside the vault’s existing range. That made the public reposition() path available.

Price manipulation was only the trigger. The deeper problem was that an externally influenced strategy operation could place the vault into a state that its withdrawal accounting did not handle safely.

Step 3: Make `reposition()` store zero liquidity

The internal _reposition() function removes the old position, leaves the withdrawn assets in the vault, and calculates the liquidity for a new position:

uint128 newLiquidity;

if (required1 <= amount1) {
    newLiquidity = liq0;
} else {
    newLiquidity = LiquidityAmounts.getLiquidityForAmount1(
        s.sqrtPriceLower,
        s.sqrtPriceX96,
        amount1
    );
}

if (newLiquidity > 0) {
    _modifyLiquidity(
        s.newTickLower,
        s.newTickUpper,
        int128(newLiquidity)
    );
}

liquidity = newLiquidity;

In the exploit transaction, the Repositioned event recorded:

newTickLower = 276324
newTickUpper = 276327
newLiquidity = 0

The old position had already been removed, leaving roughly 14,838 DAI at the vault address. No replacement position was created. The vault was now in the exact state required by the vulnerable branch:

liquidity == 0
vault DAI balance > 14,838 DAI
attacker shares == 1

Step 4: Redeem one share and empty the vault

The exploit contract immediately redeemed the single minimal share unit.

Because liquidity was zero, _withdraw() transferred the entire DAI balance to the exploit contract. The on-chain Withdrawn event shows:

sharesBurned = 1
daiOut       = 14838466608989135865711
usdcOut      = 0

With DAI’s 18 decimals, that is:

14,838.466608989135865711 DAI

The attacker paid one wei of DAI for the vault share and received idle assets that belonged collectively to all shareholders.

Why this bug is easy to miss

Read in isolation, the branch looks like a sensible convenience: if no LP position exists, return the tokens held by the vault.

The flaw appears only when the full state transition is considered:

reposition() can remove all liquidity from the old position.
The new-liquidity calculation can return zero.
The withdrawn assets remain at the vault address.
Existing user shares remain valid.
_withdraw() treats zero strategy liquidity as permission to pay one user the entire balance.

At Panda Security, we view this as a state-accounting failure rather than a single bad if statement. Vault reviews must track whether assets, shares, and deployed positions preserve the same ownership relationship across every state transition.

This vault effectively maintained three ledgers:

the shareholder ledger: shares and totalShares;
the asset ledger: idle DAI and USDC balances;
the strategy ledger: liquidity deployed in Uniswap V4.

During the exploit, the strategy ledger fell to zero while both the asset ledger and shareholder ledger remained non-zero. The withdrawal function selected its payout logic using only the strategy ledger, allowing the three ledgers to diverge.

How to fix it properly

1. Always distribute idle assets proportionally

The minimum repair is to preserve the total supply before burning shares and use it to calculate the redeemer’s portion of every idle balance:

function _withdrawIdleAssets(
    uint256 shareAmount,
    uint256 totalSharesBefore,
    address recipient
) internal {
    uint256 daiBal = DAI.balanceOf(address(this));
    uint256 usdcBal = USDC.balanceOf(address(this));

    uint256 daiOut = daiBal * shareAmount / totalSharesBefore;
    uint256 usdcOut = usdcBal * shareAmount / totalSharesBefore;

    if (daiOut > 0) DAI.safeTransfer(recipient, daiOut);
    if (usdcOut > 0) USDC.safeTransfer(recipient, usdcOut);
}

Only a user burning all outstanding shares should be able to receive the vault’s entire balance.

2. Do not allow repositioning to silently produce zero liquidity

If the old position contained assets but the new calculation produces zero liquidity, the transaction should revert:

if (newLiquidity == 0 && totalShares > 0) {
    revert ZeroLiquidityAfterReposition();
}

A stronger design should also enforce minimum deployed liquidity and minimum capital utilization. Checking only for a non-zero result can still permit economically meaningless values near rounding boundaries.

3. Separate asset accounting from strategy state

Withdrawal rights must be derived from assets and shares, not from whether an LP position happens to exist:

userAssets = totalManagedAssets * userShares / totalShares

totalManagedAssets should account for at least:

DAI and USDC held in the Uniswap V4 position;
idle DAI and USDC held by the vault;
collected assets waiting to be reinvested;
any reliably measurable principal or fees pending collection.

The strategy layer decides where capital is deployed. The accounting layer decides who owns it. A single liquidity variable cannot safely answer both questions.

4. Harden `reposition()` against price manipulation

Checking only the current tick is not sufficient for a publicly callable vault rebalance. Practical defenses include:

validating the price against a TWAP or trusted oracle;
enforcing a minimum post-reposition asset value;
requiring minLiquidityOut or minAssetsDeployed;
limiting single-block price movement;
restricting execution to approved keepers or using delayed execution;
testing zero-liquidity, one-sided balance, and rounding-boundary cases explicitly.

Panda Security’s vault audit checklist

For vaults connected to LP, lending, or compounding strategies, we recommend testing the following invariants:

1. A user can never receive more assets than their proportional ownership.
2. A partial redemption can never withdraw the vault's entire balance.
3. Failed strategy migration cannot alter asset ownership while shares exist.
4. liquidity == 0 does not imply totalAssets == 0.
5. Asset value before and after repositioning stays within an explicit limit.
6. Minimal share amounts cannot bypass proportional accounting.
7. An externally controlled price cannot select an unsafe payout branch.

Happy-path tests covering “deposit, earn fees, withdraw” are not enough. The most valuable cases often combine unusual states:

a one-wei deposit followed by a one-wei redemption;
a position moving completely out of range;
removal of an old position followed by a zero new-liquidity result;
token balances remaining while LP liquidity is zero;
withdrawals by the final shareholder and by a non-final shareholder;
price manipulation combined with permissionless keeper actions.

Final thoughts

The attacker did not break Uniswap and did not need a sophisticated reentrancy chain. They moved the vault into a state where asset ownership had never been properly defined, then called a public withdrawal function.

liquidity == 0 is a strategy condition, not proof of ownership. As long as multiple shares exist, every withdrawal path must return to the same basic rule: the user’s payout is determined by their ownership percentage, regardless of whether the assets are currently inside an LP position or sitting idle in the vault.

That distinction is central to Panda Security’s approach to vault reviews: verify asset conservation and share invariants before reviewing yield logic. A yield bug reduces returns; an ownership bug empties the vault.

Vaults, AMM strategies, auto-compounding systems, and Uniswap V4 integrations should undergo source review, state-machine testing, and mainnet-fork attack simulation before deployment. Panda Security will continue turning real-world exploit paths into concrete audit checks that teams can apply before attackers do.

Audit H/M report Summary from Ondo code4rena

PandaSecurity — Fri, 13 Oct 2023 06:07:27 +0000

1.Chain support chain cannot be removed or cleared in bridge contracts.

Contracts provide a way to add support for a chain; however, they do not provide a way to delete it.
When a contract offers an addition method, it's important to consider whether it should also provide a deletion method

2.Contract use msg.sender as remote chain receiver when bridge token.

AA wallet like safe has different wallet address on different chains.
This vulnerability requires us to be familiar with some commonly used third-party tools in order to discover it

3.Two different transactions can result in the same txnHash value, thus breaking the approval process of transaction minting

txnHashToTransaction[txnHash] = Transaction(srcSender, amt);

Consider whether the keys in similar mappings are always unique?

4.Admin can’t burn tokens from blocklisted addresses because of a check in _beforeTokenTransfer

The burn operation prematurely calls the beforeTransfer function, but beforeTransfer needs to check if the address is blocked, which hinders the successful execution of the burn

origin

https://blog.coffiasd.cn/23-10-13.html

contact me for SC private review

Twitter:https://twitter.com/coffiasse
Github:https://github.com/coffiasd
TG:@coffiasd

All you need to know about openzeppelin access control

PandaSecurity — Thu, 27 Jul 2023 04:57:34 +0000

what is access control

Basiclly,access control means "who is allowed to do this thing".It's quite important for smart contract to specify a particular address who can totally control the whole system.Therefor it's critical to fully understand how to use access control before using it in your project or just copy some example code from somewhere.
In openzeppelin there are mainly two ways to implementing access control.

Single onlyOwner role
Role-Based Access Control (RBAC)

Let's dive into how to master this 2 ways.

master how to use it by practice

OnlyOwner

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    function normalThing() public {
        // anyone can call this normalThing()
    }

    function specialThing() public onlyOwner {
        // only the owner can call specialThing()!
    }
}

let's create two user for our test.

owner address
arbitrary address

    address owner = address(0x100);
    address arbitrary = address(0x101);

and the we use owner address to create the smart contract,it's quite simple you don't even need to pass any parameters.openzeppelin Ownable would set msg.sender as it's owner as default.we use foundry for testing,if you're not familiar with foundry,go and learn it first before proceeding further.

Firstly,we use owner address create our smart contract above in foundry test contract setUp function.

//let's set address owner to msg.sender.
vm.prank(owner);

//create the contract.
myContract = new MyContract();

And then we use the arbitrary address to invoke the specialThing function which is protected by onlyOwner modifier.As expect the invoke revert because of access control.Here goes the code:

//use arbitrary address invoke specialThing() function.
vm.prank(arbitrary);
vm.expectRevert("Ownable: caller is not the owner");
myContract.specialThing();

Finally,we use our owner who master the contract invoke the specialThing function.As you see the owne succeed.

//switch to owner.
vm.prank(owner);
myContract.specialThing();

If you want the whole example codes go for:https://gist.github.com/coffiasd/84552b5a33845fa567bfc3aa5204d460
If you have any questions, you can also reach me through the contact information below.

Role-Based Access Control

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken2 is ERC20, AccessControl {
    // Create a new role identifier for the minter role
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    constructor(address minter) ERC20("MyToken", "TKN") {
        _grantRole(DEFAULT_ADMIN_ROLE, minter);
        // Grant the minter role to a specified account
        _grantRole(MINTER_ROLE, minter);
    }

    function mint(address to, uint256 amount) public {
        // Check that the calling account has the minter role
        require(hasRole(MINTER_ROLE, msg.sender), "Caller is not a minter");
        _mint(to, amount);
    }
}

We can create whatever role we want in Role-Based Access Control (RBAC) contract.Let's say we want create a minter role who can mint some ERC20 token.We can use a special constant bytes32 as the name of the role like this:

// Create a new role identifier for the minter role
bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

Firstly,we use owner address as our minter to create our access control contract.

 myToken = new MyToken2(owner);

And then we use the arbitrary user to mint some ERC20 token:

//use arbitrary address invoke mint() function.
vm.prank(arbitrary);
vm.expectRevert("Caller is not a minter");
myToken.mint(address(this), 1);

the above invoke would be revert because of arbitrary don't hold the minter role.

//switch to owner.
vm.prank(owner);
myToken.mint(address(this), 1);

If we switch msg.sender to owner the call would successed.

What's more? we can use owner address to grant a minter role whoever we want.Let's say we grant the minter role to the arbitrary address:

vm.prank(owner);
myToken.grantRole(keccak256("MINTER_ROLE"), arbitrary);

vm.prank(arbitrary);
myToken.mint(address(this), 1);

After invoke the grantRole function the arbitrary has the right to mint token.

At the same time,arbitrary address don't has the right to grant role to another address:

vm.prank(arbitrary);
vm.expectRevert();
myToken.grantRole(keccak256("MINTER_ROLE"), address(0x1001));

As the owner we also have the right to revoke role we grant before:

vm.prank(owner);
myToken.revokeRole(keccak256("MINTER_ROLE"), arbitrary);

vm.prank(arbitrary);
vm.expectRevert("Caller is not a minter");
myToken.mint(address(this), 1);

After we invoke role of arbitrary,he can't mint ERC20 token anymore.

If you want the whole example codes go for:https://gist.github.com/coffiasd/340241d63980dc9d423e4ece2f9b20db
If you have any questions, you can also reach me through the contact information below.

Origin:https://blog.coffiasd.cn/03-07-26.html

let's connect

Twitter:https://twitter.com/coffiasse
Github:https://github.com/coffiasd
TG:@coffiasd

How to use solidity CREATE and CREATE2

PandaSecurity — Thu, 27 Jul 2023 04:55:33 +0000

Overview

There are 2 major ways to deploy smart contract CREATE and CREATE2. They look quite similar, but there are still some differences.CREATE2 and CREATE are one of solidity opcode which give us the ability to predict the address where a contract will be deployed before we deploy a smart contract.You might be curious about what opcode is.Opcodes are the fundamental building blocks of EVM bytecode, and each opcode represents a specific operation that the EVM can perform. For example, there are opcodes for arithmetic operations, logical operations, storage access, memory manipulation, conditional branching, and more.

What is CREATE

Smart contracts can be created both by other contracts and regular EOA.They both compute the new address the same way:

new_address = keccak256(sender, nonce)

So each created address is associated with a nonce value.Nonce increased on every transaction.It is related to the number of transactions we make and is unpredictable. That's why we need CREATE2.

What is CREATE2 ?

The whole idea behind this opcode is to make the resulting address independent of future events. Regardless of what may happen on the blockchain, it will always be possible to deploy the contract at the precomputed address.There are four parameters in CREATE2 function:

0xFF
the address of sender
A salt (random value from sender)
bytecode (the code of the new contract)

new_address = keccak256(0xFF, sender, salt, bytecode)

Why we need CREATE2 ?

Imagine a scenario where you need to deploy a contract to multiple networks, and precisely at that moment, you need to store the addresses of the yet-to-be-deployed contracts as storage parameters within the currently deployed contract. In such cases, you would require knowing the future addresses of the contracts to be deployed in advance.

How to use it

Use hash function to calculate address.

    uint256 _salt = 1;
    bytes32 hash = keccak256(
        abi.encodePacked(
            bytes1(0xff),
            address(this),
            _salt,
            keccak256(type(TokenTemplate).creationCode)
        )
    );

Use deploy to get the deployed address.

    function deploy(
        bytes memory bytecode,
        uint _salt
    ) public payable returns (address) {
        address addr;

        assembly {
            addr := create2(
                callvalue(), // wei sent with current call
                // Actual code starts after skipping the first 32 bytes
                add(bytecode, 0x20),
                mload(bytecode), // Load the size of code contained in the first 32 bytes
                _salt // Salt from function arguments
            )

            if iszero(extcodesize(addr)) {
                revert(0, 0)
            }
        }

        return addr;
    }

you can find the whole code on github:
https://gist.github.com/coffiasd/c2ff1a2d718d286b9064873be2fe079a

Origin: https://blog.coffiasd.cn/03-07-24.html
Follow my twitter:https://twitter.com/coffiasse
TG:@coffiasd

Merkle树的逻辑和证明

PandaSecurity — Mon, 17 Jul 2023 05:29:43 +0000

什么是Merkle树

定义

Merkle Tree，也叫默克尔树或哈希树，是区块链的底层加密技术，被比特币和以太坊区块链广泛采用。Merkle Tree是一种自下而上构建的加密树，每个叶子是对应数据的哈希，而每个非叶子为它的2个子节点的哈希。

如何生成Merkle树的数据

在solidity中我们通过keccak256算法计算hash值:

keccak256(abi.encodePacked(toHashValue)

e.g.:
hash前
0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2

hash后
0x999bf57501565dbd2fdcea36efa2b9aef8340a8901e3459f4a4c926275d36cdb

在对叶子节点的值进行hash运算之后，再把相邻的节点再进行hash运算，直到只剩下一个根节点。
假设存在两个相邻的节点A和B,那么在进行hash运算的时候到地址是hash(A+B)呢？还是hash(B+A)呢？其实这是由A和B的大小决定的，在openzeppelin对应的merkle代码中我们可以找到这么一段代码:

    function _hashPair(bytes32 a, bytes32 b) private pure returns (bytes32) {
        return a < b ? _efficientHash(a, b) : _efficientHash(b, a);
    }

总结来说就是把相对小的数值放到前面去这么来排序计算hash值。这个地方在自己动手实际运算的时候可能会有些许困惑。
在实际的项目中一般只需要把计算的最后结果的根hash值存储到合约中，如果大量的地址都需要存到合约中的话会消耗大量的gas费。经过merkle树计算之后，大大的减少了需要存储的数据。
通过一段foundry的setUp演示下如何计算和存储root hash值:


    bytes32 public root;
    bytes32[] public leafs;
    bytes32[] public l2;

    function setUp() public {
        address[] memory addrss = new address[](4);
        addrss[0] = 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2;
        addrss[1] = 0x2d886570A0dA04885bfD6eb48eD8b8ff01A0eb7e;
        addrss[2] = 0xed857ac80A9cc7ca07a1C213e79683A1883df07B;
        addrss[3] = 0x690B9A9E9aa1C9dB991C7721a92d351Db4FaC990;

        //通过地址列表计算叶子节点的hash值
        leafs.push(keccak256(abi.encodePacked(addrss[0])));
        leafs.push(keccak256(abi.encodePacked(addrss[1])));
        leafs.push(keccak256(abi.encodePacked(addrss[2])));
        leafs.push(keccak256(abi.encodePacked(addrss[3])));

        //计算第二层的hash值
        l2.push(keccak256(abi.encodePacked(leafs[0], leafs[1])));
        l2.push(keccak256(abi.encodePacked(leafs[2], leafs[3])));

        //计算根的hash值
        root = keccak256(abi.encodePacked(l2[1], l2[0]));
    }

为了演示方便我们值写了4个地址，实际项目中可能地址数量非常大。

如何来验证Merkle树

在合约中存储到root hash值之后我们如何去验证由客户端发过来的地址是否是有效地址或者说在白名单中的地址呢？
首先我们需要将地址进行hash运算，作为第三个参数，然后将地址相邻的hash值作为proof传到验证函数中。
proof列表对应下面图片中的红色标记区域

测试的验证方法:

    function testVerify() public {
        address proofAddress = 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2;

        bytes32[] memory proof = new bytes32[](2);
        proof[0] = leafs[1];
        proof[1] = l2[1];

        assert(
            MerkleProof.verify(
                proof,
                root,
                keccak256(abi.encodePacked(proofAddress))
            )
        );
    }

完整的foundry测试代码:https://gist.github.com/coffiasd/96022abd7f9a8a2189bda14bf9e755dc

在实际项目中的应用场景

发放空投
NFT的白名单

在合约审计中的常见漏洞

function parentHash(bytes32 a, bytes32 b) public pure returns (bytes32) {
        if (a < b) {
            return keccak256(abi.encode(a, b));
        } else {
            return keccak256(abi.encode(b, a));
        }
    }

abi.encode(address, uint)将会输出64字节。由于abi.encode(bytes32, bytes32)也是64字节，因此在叶子节点和父节点之间可能会发生哈希碰撞。

Follow我的推进行交流学习:https://twitter.com/nifty12111
TG:@coffiasd

Solidity Assembly的基础用法

PandaSecurity — Sat, 15 Jul 2023 02:23:06 +0000

什么是Assembly

在编写Solidity代码时，我们可以使用assembly{}关键字开始编写Yul代码，它是一种简化且扩展了的汇编语言。通过使用assembly，我们可以直接访问堆栈，并优化代码以提高内存效率，从而减少执行交易所需的燃气量。这最终降低了用户的交易成本。

然而，在可读性方面存在一些妥协。许多前端开发人员可以阅读Solidity智能合约并理解正在执行的功能以及如何将其应用到他们的web3查询中。相比之下，汇编可能会让人感到有些困惑，如果你不熟悉低级编程，可能很难理解其逻辑和流程。

操作码列表

操作码	描述
add(x, y)	将栈中的前两个值相加，并用结果替换它们
sub(x, y)	减法操作
mul(x, y)	乘法操作
div(x, y)	除法操作
mod(x, y)	取模操作
lt(x, y)	小于。如果 x 小于 y，则返回 1
gt(x, y)	大于
eq(x, y)	等于。如果 x 等于 y，则返回 1
not(x)	按位取反 (1010 > 0101)
and(x, y)	按位与 (1000 AND 1100 > 1000)
or(x, y)	按位或 (1000 AND 1100 > 1100)
xor(x, y)	按位异或 (1000 XOR 1100 > 0100)
byte(n, x)	X 的第 N 个字节
keccak256(pos, n)	本地哈希算法
pop(x)	从栈中弹出 X
mload(pos)	加载存储在位置 pos 的内存数据
mstore(pos, value)	在位置 pos 的memory中存储值 value
sload(pos)	加载存储在位置 pos 的存储数据
sstore(pos, value)	在位置 pos 的storage中存储值 value
balance(address)	以 wei 为单位返回地址的以太币余额
call(gas, address, value, in, insize, out, outsize)	调用外部合约，也可用于发送资金，成功时返回 1
delegatecall(gas, address, value, in, insize, out, outsize)	与上述相同，但由用户而不是合约进行调用
revert(p, s)	撤销事务和任何状态更改
return(p, s)	结束执行并返回数据

这里需要注意的是mstore和sstore的区别，主要存储的位置的不一致，一种是存储在memory中，另一种是存储在storage中。

使用案例

读写

下面我们通过一个例子展示下如何使用Assembly把数据存储到storage中，然后通过函数读取的方式读出来。

    function testAssembly() public {
        //定义一个存储的值方便测试.
        uint256 x = 123;
        bool res;

        //将x存储到storage中。
        assembly {
            sstore(0, x)
        }

        //在storage中读取x的值,其中0是pos
        assembly {
            let readX := sload(0)
            //将readX的值存储到memory,pos == 0x80的位置。
            mstore(0x80, readX)
        }

        //将0x80中的值取出来.
        assembly {
            let v := mload(0x80)
            if eq(v, x) {
                res := true
            }
        }

        //判断最终取出来的v == x?
        assert(res);
    }

上诉的例子在实际项目中不太可能出现，只是为了展示读写的过程。

基础运算

    function testAssembly() public {
        //定义一个存储的值方便测试.
        uint256 x = 123;
        uint256 r = 345;

        //将x存储到storage中。
        assembly {
            x := add(x, 300)
            x := sub(x, 78)
        }

        //判断最终取出来的r == x?
        assert(r == x);
    }

Follow我的推进行交流学习:https://twitter.com/nifty12111
TG:@coffiasd

DEV Community: PandaSecurity

Sui Bridge Claim Bot Sent $392K to the Cetus Attacker

TL;DR

Background: Cetus and the Leftover Withdrawals

How the Sui Bridge Claim Works

What the Bot Did, Step by Step

The on-chain exchange that followed

Why This Matters Beyond One Bot

1. Dormant is not the same as safe

2. Permissionless relaying moves the screening burden off-chain

3. Recovery tooling is security-sensitive software

Mitigations

For bridge and protocol teams

For relayers and recovery bots

For auditors

Key Addresses and Transactions

Sources

Closing Thoughts

KolanHook Exploit: Unguarded Uniswap v4 Buyback Drained ETH

TL;DR

What Kolan Is

Root Cause: A Permissionless Trigger Meets an Unbounded Swap

1. Anyone can close an expired window

2. The buyback accepts any price

The Attack, Step by Step

Why This Keeps Happening in Uniswap v4 Hooks

Impact

Mitigations and Audit Lessons

For hook developers

For auditors

Key Addresses

Sources

Closing Thoughts

Smart Contract Security Checklist for Web3 Developers

Smart Contract Security Checklist

1. Review Access Control First

Access-control checklist

2. Check Upgradeability Carefully

3. Protect Initializers

4. Review Reentrancy

But don't only search for call()

5. Review External Calls

6. Don't Assume Every ERC-20 Behaves the Same

7. Check Oracle Security

8. Review Flash-Loan Attack Paths

9. Check Accounting Invariants

10. Pay Special Attention to ERC-4626 Vaults

11. Validate All User Inputs

12. Check Signature Verification

13. Be Careful With tx.origin

14. Review Denial-of-Service Risks

15. Don't Ignore selfdestruct, ETH Transfers, and Forced ETH

16. Review Compiler and Dependency Versions

17. Write Tests for Attackers, Not Just Users

18. Test Invariants and Properties

19. Run Static Analysis — But Don't Stop There

20. Perform Manual State-Transition Analysis

21. Review Deployment Configuration

22. Verify Contracts on the Block Explorer

23. Monitor the Contract After Deployment

24. Keep an Emergency Response Plan

A Practical Pre-Deployment Checklist

Architecture

Access Control

DeFi Logic

Token Handling

External Calls

Upgradeability

Testing

Deployment

The Most Important Part of Smart Contract Security

Final Thoughts

That is the question a good security review should answer.

References

Inside the Likwid Exploit: One Missing pairDelta, 74 BNB Gone

What Likwid Actually Is

The Attack Path, Short Version

Root Cause: The Leverage=0 Branch Forgot pairDelta

The Tell: Asymmetric Assignment Across Branches

Why the Vault's Safety Check Didn't Save It

But don't only search for `call()`

13. Be Careful With `tx.origin`

15. Don't Ignore `selfdestruct`, ETH Transfers, and Forced ETH

Step 3: Make `reposition()` store zero liquidity

4. Harden `reposition()` against price manipulation