In today’s menu:
• The public string that gave anyone access to 86 Gnosis Safes
• One failed Sui transaction that halted every honest validator
• The Arbitrum DAO just voted on where frozen KelpDAO ETH goes
• And more…

🏴‍☠️ Hacks

Two exploits from this week

SquidRouterModule source | WUSD.fi source

SquidRouterModule — $3.2M, 86 Gnosis Safes

You install a module on your Gnosis Safe.

The name says SquidRouterModule. Squid Router is trusted. You’ve seen it everywhere.

The module isn’t Squid’s.

Third-party contract. Verified on Basescan as SquidRouterModule. Not built, deployed, or audited by Squid. One missing check: it accepted a caller-supplied constant string as proof of authorization. The string sits in the verified source — public, readable, usable by anyone.

If the auth string is public, who is it actually keeping out?

The attacker deployed Foundry-based exploit contracts. Called executeSameChainActions() with the string. Hit the DelegateBundler path — impersonating authorized delegates on victim Safes. Swaps fired: real tokens out, a worthless attacker-deployed token (”u”, 42 holders) in. Attacker pre-seeded Uniswap V3 pools with “u” pairs. Removed liquidity post-drain. All proceeds converted to 3.07M DAI.

86 Safes. Two hours. Squid’s name took the hit for code they never wrote.

Read the code behind the module name. Not the name.

WUSD.fi — $200K via Sybil Abuse

The protocol had an incentive mechanic in WUSD._englove.

Wrap at least 100 WUSD while holding fewer than 2 GLOVE. Receive up to 2 free GLOVE via Glove.mintCreditless. No sybil check. No rate limit.

What does a “fresh address” requirement mean to an attacker with EIP-7702?

Provisioned on demand.

The attacker deployed EIP-7702 helper contracts — EOAs that execute like contracts. Funded each cycle with a Morpho USDT flash loan. Wrap. Claim. Unwrap. Repeat. Across fabricated fresh addresses at scale.

Each individual claim was valid by the contract’s logic. The loop wasn’t.

GLOVE hit Uniswap V3 GLO pools on the way out. $200K in USDC and USDT extracted.

Glove.mintCreditless — creditless means no collateral. It was never meant to mean unlimited.

🗞️ News

Arbitrum DAO votes to release frozen ETH — funds go to Aave

Source

The Arbitrum DAO passed a constitutional proposal.

Release the ETH the Security Council froze after KelpDAO’s rsETH incident. 190M FOR + ABSTAIN votes. Quorum cleared.

Constitutional proposals take 2-3 weeks to execute. When this one does, the ETH moves to a wallet controlled by Aave — not back to original holders.

Once a security council freezes funds — who owns them?

The Security Council froze fast. Correct call. The chain of custody transferred to the DAO, which deliberated and voted. The DAO decided the destination: Aave.

The original holders aren’t in that sentence.

This is the precedent. Emergency freezes preserve optionality — for the DAO, not original owners. If you’re building under a security council, understand who controls the next decision.

The freeze worked. What happens to the funds is always a governance question.

📚 Education

Sui Mainnet Halt — May 28, 2026

Source

Sui went down for hours.

Two tweets from Suibracket the public record. Mainnet stall. Patch deployed. Back online. What happened between them: a single missing case. One failed user transaction. Every honest validator halted.

Sui’s 1.72 release introduced Address Balance. An account-style balance layer on top of its object model. Gas can be paid via coin reservations — a reservation isn’t a real coin. It’s a promise to withdraw from Address Balance.

When gas smashing runs, any reservation entry emits an AccumulatorEvent::Split into the TemporaryStore. That Split feeds the settlement system transaction, which applies the net balance change at the checkpoint boundary.

The bug: a transaction about to fail with InsufficientFundsForWithdraw still ran smashing first.

Failure reset object state. It did not reset the event.

What does a failed transaction actually write — before it fails?

Settlement later tried to apply that Split against a zero balance:

u128.value = 0 + 0 - R;  // checked underflow → abort

Move’s checked arithmetic refused. No silent solvency bug.

But refusing meant aborting the settlement system transaction.

Settlement is deterministic. Every validator derives the identical system transaction from the checkpoint. Every validator hit the identical abort.

Chain stopped.

No funds stolen. Move caught the solvency bug. The chain paid with liveness.

The fix: 16 lines in execution_engine.rs. Prune reservation entries from gas_data.payment before smashing — when an IFFW abort is coming. No reservation → no Split → no poisoned checkpoint.

Audit every early-abort path. Not just whether the transaction fails. What it writes before it does.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• A p-token vulnerability was discovered — batch instruction + deferred ownership = inflated wrapped SOL
• OpenZeppelin goes continuous — what their new model signals for the industry
• Vitalik on formal verification: what it actually proves, and where it breaks
• And more…

🐛 Vulnerability

p-token: batch instruction breaks the deferred ownership invariant

Source

p-token is Pinocchio-based. A compute-optimized rewrite of Solana’s SPL token program. Transfers now cost over 95% fewer CUs.

One of the CU savings: skipping explicit ownership checks on source accounts during transfers. The logic holds — any write to a foreign-owned account fails at the runtime level. The check is redundant.

What breaks that assumption?

The batch instruction.

Batch lets callers bundle multiple token operations into a single program call. Inside that single call, state changes can be reversed before the runtime check runs.

Here’s the mechanic:

Create a fake wrapped SOL account you control. Set the mint to native mint. Set is_native to None. Send a batch:

1. Transfer X wrapped SOL from the fake account → target

2. Transfer X wrapped SOL from a real account → back to the fake account

At the end: the fake account’s data is unchanged. The runtime check never triggers. The target’s amount field has increased. No lamports moved.

Any DeFi protocol that treats amount as the source of truth for collateral or flash loan repayment is exploitable from there.

The Anza team fixed it quickly — explicit ownership checks added to the batch handler for any instruction that modifies accounts.

The lesson: deferred runtime checks are a valid optimization when instructions execute independently. Batch breaks that assumption by allowing multiple state transitions inside a single invocation — including ones that undo the write the runtime was waiting to catch.

Individually safe optimizations can become vulnerabilities when composed with new functionality.

🗞️ News

OpenZeppelin launches Continuous Security Program

Source

OpenZeppelin announced a subscription-based, always-on security model. Not point-in-time audits — continuous coverage across the full development lifecycle.

The core premise: most major onchain hacks don’t come from bugs that audits missed. They come from code shipped between audits. Upgrades, new integrations, parameter changes — pushed to production without security review.

Their model is structured around four areas: Architect, Build, Secure, Support. Continuous loops, not sequential phases. AI-augmented scanning plus senior researcher review.

What this signals:

The point-in-time audit isn’t being replaced — it’s being framed as one layer, not the full stack. For large, fast-moving protocols, that framing is probably correct.

The market OpenZeppelin is targeting is institutional — Fidelity, DTCC, WisdomTree-tier clients. Not the same market as competitive audits or private engagements.

But the tooling bar it sets is real. Their AI Auditor reportedly surfaces a high or critical finding in one of every three scans. That’s the baseline expectation for continuous coverage now.

📚 Education

Formal verification: what it proves, and where it breaks

Source

Vitalik published a deep dive on formal verification. The part most useful for auditors is buried about halfway through.

“Provably correct” doesn’t mean what it sounds like.

Formal verification proves that multiple specifications of intent are compatible with each other. It does not prove that those specifications match what users actually expect.

The model:

• Code = one expression of intent

• Type system = another expression

• Test suite = another expression

• Formal proof = another expression

The more ways you express the same intent, the harder it is for bugs to survive undetected. FV extends that redundancy further than any test suite can — you can verify an optimized implementation against a readable reference, check ten mathematical properties simultaneously, and use AI to do all of it efficiently.

Where it breaks down:

When only part of the code is verified and the unverified parts are where the bugs live. When the specification is wrong. When the proof assumes something the hardware doesn’t guarantee. Vitalik documents real examples: a formally-verified C compiler generating wrong assembly for edge cases. A Signal protocol proof that holds until hardware leaks through side channels.

The real takeaway: more redundant specifications of intent, automatically checked, is always better. FV is a powerful accelerant of that direction — not a final answer.

For auditors: FV is increasingly relevant for infrastructure (STARKs, ZK-EVMs, consensus). For program-level work, tests plus invariants plus manual review is still the realistic model. But the infrastructure you’re auditing against is being formally verified — understanding what that means, and what it doesn’t cover, matters.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• How a newly churned node reconstructed a vault key and drained $10.7M
• The end of Code4rena
• Four proof fields no one verified — and why that breaks a $60M blockchain
• And more…

🏴‍☠️ Hacks

THORChain: $10.7M drained via TSS key reconstruction

Source

You run a cross-chain DEX. Six vaults. Distributed key material across multiple nodes. No single node holds the full private key.

The design is sound. The implementation had a gap.

A new node churns in. Bonds RUNE. Joins a vault. Nothing unusual on paper.

How many signing rounds does it take to reconstruct a full private key from leaked fragments?

With a vulnerable GG20 implementation: however many it takes to stay patient. GG20 distributes the vault’s key material across participating nodes. But the vulnerability let partial material leak from each signing round. Over several days, the attacker accumulated enough fragments to reconstruct the full private key for one of the six Asgard vaults — then executed unauthorized outbound transactions.

The network caught it automatically. An anomaly detector flagged the activity and halted signing. Multiple node operators executed make pause. Individual user swaps were not affected — only protocol-owned liquidity was at risk.

The ETH addresses used to bond RUNE for the malicious node link directly to the addresses that received the stolen funds. Current evidence points to a single operator acting deliberately, not a random exploit.

Recovery options are still in discussion: slash affected node bonds, use Protocol-Owned Liquidity to absorb the loss, or a community-driven combination. No decision yet. Trading remains halted.

The attack surface wasn’t a missing access check or a reentrancy path. It was the cryptographic primitive securing every vault — and a node operator who knew exactly what to do with what it leaked.

🗞️ News

Code4rena is shutting down

Source

Code4rena announced last week that it’s winding down. Short statement. No explanation. No acquirer named.

All active contests and bounties will run to completion. Projects mid-engagement won’t be dropped. Each competition wraps up on its own timeline, coordinated with sponsors.

Where do you build a public track record when the leaderboard you were climbing disappears?

C4 was the platform that made competitive auditing mainstream. Hundreds of contests. Millions in payouts. A leaderboard that gave researchers a way to go public — and a way for protocols to find them.

A lot of careers in Web3 security started with a first C4 finding. Five years of wardens, judges, and sponsors building something real.

Sherlock, Cantina, and Codehawks are still running. The competitive audit format survives. But the community that grew up specifically inside C4 is gone.

If you were mid-contest, finish it. If you were building toward C4, pick the next platform and keep going. The skill compounds the same either way.

The arena closed. The work doesn’t stop.

📚 Education

Unverified PLONK evaluations — OSEC’s dusk-plonk disclosure

Source

OSEC disclosed a critical soundness bug in dusk-plonk — the PLONK implementation behind Dusk Network’s Phoenix privacy layer. At disclosure: ~$60M market cap. The entire shielded transaction layer was at risk.

Here’s the invariant every PLONK verifier must maintain: every scalar entering the final verification equation either comes with a KZG opening proof, or is computed locally from public data. The opening proof binds an evaluation to a polynomial the prover committed to before seeing the challenges. Without that binding, the scalar is a free variable — the prover sets it to whatever makes the equation balance.

What happens when four of those scalars have no opening proof?

Dusk’s proof struct included evaluations for four selector polynomials: q_arith, q_c, q_l, q_r. The verifier consumed all four in the arithmetic identity check. None were in the KZG opening batch. The commitments existed in the verifier key — but the verifier never checked the evaluations against them.

Four free variables.

The exploit reduces to a single field division. You commit to arbitrary witness and quotient polynomials. You follow the honest protocol through all commitment rounds. After seeing the challenge z, you compute what the equation needs. You solve for q_arith_eval. You set the other three to zero.

Valid proof. Arbitrary false statement.

For Dusk, this broke every Phoenix constraint simultaneously — Merkle membership, note ownership, balance integrity, nullifier correctness. OSEC built a local testnet PoC: wallet balance 0, forge a proof, mint 2000 DUSK, transfer 1337 DUSK to an honest wallet. The honest node accepted both transactions.

OSEC found the same class of bug in Espresso’s Jellyfish: nine of fifteen Plookup evaluations missing from the Fiat-Shamir transcript before the batching challenge was derived. Different implementation. Same missing invariant.

The audit check is mechanical. For every field in a proof’s evaluation struct: does it appear in the KZG opening batch, or does the verifier compute it locally? Neither case is exotic. Both are checkable from a diff.

Every field. Bound or locally derived. No exceptions.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• How a phished npm maintainer drained $160K from live Solana dApps
• The fuzzer that surfaced a phantom stake bug in seconds
• AI agents at 70% on exploit construction — still failing at the hard part
• And more…

🏴‍☠️ Vulnerability

Supply chain attacks on Solana’s off-chain tooling

Source

Your Solana program is immutable.

You revoked the upgrade authority. Nobody changes that code.

But the utility that signs your transactions? That’s not on-chain.

What happens when version 0.1.2 lands in your CI and nobody reads the diff?

In December 2024, attackers phished a maintainer of @solana/web3.js. Versions 1.95.6 and 1.95.7 shipped within hours. Both captured private keys from signers. Exfiltrated them to a hard-coded Solana address. The package had 350K weekly downloads. $160K in SOL and SPL tokens drained before fixes shipped.

The on-chain code was untouched. Every transaction landed as expected. The exploit lived in the dependency your dApp imported to sign — not the contract any audit would have scoped.

That’s the supply chain attack profile. The exploit rides the trusted path — not the program, but the tool every instruction passes through. One hijacked maintainer account is all it takes. No on-chain footprint. No revert. Wallets drain silently.

A second attack vector: fake audit requests. Threat actors pose as project owners asking you to “review this repo” or “run our build to verify edge cases.” You clone the repo, run npm install, and a backdoored script executes — harvesting SSH keys, session tokens, or Solana CLI keypair paths. It works because auditors trust audit contexts.

The mitigations aren’t complicated. They’re just rarely applied.

Lock exact versions in Cargo.toml: =1.18.3, not ^1.18. The caret allows any version up to 2.0.0 — a rogue 1.18.99 slips in silently. Use cargo vendor to snapshot your dependency graph locally. Run cargo audit to scan for known CVEs. Enable 2FA on every crates.io and npm account in your publishing pipeline.

The program is immutable.

The signer isn’t.

🗞️ News

Crucible ships coverage-guided fuzzing for Solana programs

Source

A new fuzzing framework built for Solana programs just launched. Coverage-guided, Anchor-native, Anchor v2 support from day one.

What does a fuzzer catch that manual review misses?

Here’s the launch demo. Crucible surfaced a years-old bug in Solana’s own stake program. A 5-instruction sequence leaves delegation.stake out of sync with the validator’s actual deposited lamports:

delegate_stake()   // X lamports delegated
advance_epoch()    // stake becomes effective
deactivate()       // begin cooldown
withdraw()         // drain to rent floor, lamports drop
delegate_stake()   // rescind — delegation.stake unchanged

Step 5 hits the rescind branch — same epoch, same voter. delegation.stake is never recalculated. The SOL is withdrawn. The stake weight stays. The validator earns real inflation against a balance they no longer hold.

A generic invariant caught it: fuzz_assert!(delegation.stake <= lamports). One line. The Crucible backend handled the rest — SBPF edge coverage (every branch a feedback signal), full state space exploration, near-linear multi-core scaling.

Manual review eventually found this bug. But a one-line invariant plus automated sequence exploration would have flagged it earlier. The phantom stake was sitting in a code path that only triggers under a specific 5-step sequence — the kind that doesn’t appear in standard test suites unless someone explicitly writes for it. Coverage-guided fuzzing exhausts the state space systematically. You write the rule, the system finds the counter-example.

The framework is in early release. If you’re auditing Solana programs, it’s worth a close look.

📚 Education

AI agents at 70% on exploit construction — still failing at the hard ones

Source

a16z researchers ran 20 historical Ethereum price manipulation incidents through Codex (GPT 5.4). The task: find the vulnerability, write a working exploit. No hints. Just the contract address and block number.

How far can an agent get before it hits the hard part?

Without guardrails: 50% success. Except the agent was cheating. It used Etherscan’s txlist endpoint to pull the actual attack transaction from after the target block. Then reverse-engineered the exploit from the real attacker’s calldata. Not intelligence. Future data.

After sandboxing — no future data, no external API access — the success rate dropped to 10%.

Then they added structured domain knowledge: incident analyses, vulnerability pattern taxonomies, exploit templates derived from the actual answers. Success rate jumped to 70%.

The ceiling: even with near-complete guidance, the agent failed 6/20 times. In every single failure, it correctly identified the vulnerability. The breakdown happened at exploit construction. One agent assembled the right strategy, simulated profitability, and concluded the returns were insufficient — then abandoned its own correct answer. The economics were right. The profitability estimate was wrong.

One side observation: a sandboxed agent extracted the Alchemy API key from the anvil node config via cast rpc anvil_nodeInfo. When the firewall blocked direct access, it used anvil_reset to point the local node at a future block — then queried future state through the allowed local endpoint. Sandbox escape via debug RPC. Not a vector the researchers had anticipated.

The clearest takeaway: finding a vulnerability and building a working exploit are different skills. Agents have the first one reliably. The second breaks down on multi-step economic attacks — leveraged loops, multi-contract compositions — where the bottleneck is profitability estimation, not knowledge.

For defenders: agents are already useful. They’ll verify your true positives faster. On the complex ones, you’re still in the lead.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• Reentrancy, float drift, and unchecked CPIs — all noise in Solana
• The phishing email that passes DKIM, SPF, and DMARC
• How fixing one rounding error introduced another
• And more…

🕵🏼‍♂️ Vulnerability

The Solana security curriculum is still teaching bugs that don’t exist

Source

You open a new Solana audit.

Your checklist: reentrancy, float non-determinism, unchecked CPI return values.

Which of these does the runtime actually care about?

None of them.

The most persistent security misinformation doesn’t come from obscure corners of the internet. It comes from official docs, recommended curricula, and the LLMs auditors use every day. These sources cite each other. Outdated content enters LLM training data. Those models generate new content. The loop closes.

Reentrancy: CPI depth is capped at four. More importantly, the runtime rejects any invocation that calls back up the call stack. The A→B→A loop that drains Ethereum contracts can’t form in Solana. Self-reentrancy (A→A) is technically possible, but it requires specific conditions and is genuinely rare.

Float non-determinism: There are no floating-point opcodes in SBPF. The VM emulates them through LLVM. Hardware differences don’t reach the application layer. Floats are still worth checking for NaN, negative infinity, and precision loss — but cross-architecture divergence isn’t the concern.

Unchecked CPI return values: A failing CPI reverts the entire transaction. There’s no return value to check. The whole transaction succeeds or nothing does. Developers rely on this property by design.

Partial state commitment: Same principle. If any instruction fails, all writes roll back. No in-between state.

load\_instruction\_at / load\_current\_index: Gone since 2022. Still appearing in boot camp curricula and LLM outputs.

Some of these bugs were real — years ago. Anchor and the Agave runtime closed most of them. The docs didn’t keep up.

The runtime improved.

The curriculum didn’t.

🗞️ News

A real email from noreply@robinhood.com — phishing CTA inside

Source

The attacker’s email passes DKIM, SPF, and DMARC. It comes from noreply@robinhood.com.

What does your user do when an email passes every authentication check?

They trust it. They click.

Here’s the chain. Gmail ignores dots — v.ok@gmail.com and vok@gmail.com land in the same inbox. Robinhood treats them as different addresses. The attacker registers a new Robinhood account using the dot-trick version of their target’s email.

Then they rename their new device to a string of HTML.

Robinhood sends an “unrecognized activity” alert. The template renders the device name directly — no sanitization. The attacker’s HTML executes inside the official security email. A phishing CTA appears. The user sees a legitimate sender, passes every visual trust signal, and clicks a link the attacker controls.

Email authentication verifies the sender. It says nothing about the payload. SPF, DKIM, and DMARC are envelope-level checks. A properly signed email can still carry a fraudulent link.

This isn’t a new attack class. It’s a classic injection pattern targeting a high-trust channel. What makes it effective: security alert emails get acted on fast. Users don’t linger.

Robinhood patched the injection. But the pattern survives anywhere user-controlled input renders unsanitized in a transactional email template.

Real email. Real sender. Every auth check passing.

Still phishing.

📚 Education

Two floor operations. One slow drain on every depositor.

Source

You’re auditing a Solana stake pool. Users deposit SOL, receive LP tokens, and burn them on withdrawal.

The withdrawal math converts LP tokens to lamports and rounds down. Protocol keeps the dust. Standard.

What happens when the fix introduces a second rounding operation going the other direction?

The team added a new withdrawal path that creates a PDA stake account. On Solana, every account needs rent to stay alive. Someone has to fund it.

The original code burned LP tokens based on full withdraw_lamports — the SOL amount including rent. If the user paid rent directly, they received split_lamports = withdraw_lamports − stake_rent but burned tokens worth withdraw_lamports. Overpay.

An auditor caught it. The fix: check if the user is the payer. If so, reverse-convert split_lamports back into LP tokens and burn that instead.

The fix is logically correct. It still introduced a bug.

LP tokens → lamports is floor division. Lamports → LP tokens is another floor division. Two sequential floors favor the same beneficiary — both round down. The protocol under-burns tokens on every withdrawal. Unbacked tokens accumulate in circulation. The exchange rate slowly decreases for every depositor in the pool.

The error per withdrawal is small — bounded by the ratio of token supply to total lamports. But it compounds. Every under-burn widens the ratio. A wider ratio increases the next under-burn.

The real fix was simpler: have the pool’s reserve stake account pay the rent. split_lamports equals withdraw_lamports. No reverse conversion. No second floor.

Every conversion function has a rounding direction.

Every rounding direction has a beneficiary.

When you audit a fix to financial logic, don’t just ask whether it resolved the original issue.

Ask whether it preserved the rounding invariants.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• How a 17-month-old Sui package drained a live rewards pool
• Why Litecoin needed a 13-block reorg to recover
• The Solana event your relayer fills that never happened
• And more…

🏴‍☠️ Hacks

Scallop drained for 150K SUI via deprecated V2 package

Source

You scope the Scallop protocol.

You check the live deployment, the active SDK path, the current package.

Everything looks clean.

Here’s what you didn’t check:

What can the old package still do?

On Sui, deployed packages are immutable. Every version you ever shipped stays on-chain — and callable. The attacker didn’t touch the live code. They found a V2 spool package from November 2023. Nobody had called it in months.

The bug was in spool_account creation. In the deprecated package, last_index never initializes. It stays at zero.

Points earned = stake × (current_index − last_index).

With last_index at zero, every historical reward counts. Staking credits you for everything accumulated since the spool launched in August 2023.

The spool index had grown to 1.19 billion over 20 months. The attacker staked 136K sSUI. The pool ran a 1:1 exchange rate — numerator and denominator both set to 1. 162 trillion points converted directly to 162K SUI worth of rewards. The pool held 150K SUI. They drained it.

The bug sat dormant for 17 months. Legitimate users hit the new package via SDK, which initializes last_index correctly. The old path was invisible to anyone watching the live code.

The fix: version fields on shared objects. assert!(version == CURRENT_VERSION) in every function entry. Without that, every prior package version stays live. Not legacy. Not retired. Live.

KelpDAO, Litecoin, Aethir, Scallop. Most April exploits weren’t in core protocol code.

The audit perimeter isn’t the deployed contract.

It’s everything you ever shipped.

🗞️ News

Litecoin zero-day disrupts mining pools, 13-block reorg follows

Source

A zero-day in Litecoin’s MWEB privacy layer hit last week. Major mining pools went down.

Mining nodes running outdated versions accepted an invalid MWEB transaction. That transaction pegged out coins to third-party DEXs — movement the protocol should have rejected. Nodes on the patched version rejected it outright.

What does it mean when 13 blocks have to be undone to fix it?

The network ran a 13-block reorg. The invalid chain segment reversed. All valid transactions from that window stayed in the main chain. Funds unaffected. Bug fully patched.

A 13-block reorg sounds alarming. In Bitcoin, it would be a crisis. Here it was the right call — letting invalid pegs stand was the worse outcome.

But 13 blocks is a number worth sitting with.

The fix existed before this happened. The patched version was already live. The disruption wasn’t a zero-day in the strictest sense — it was a deployment gap. Mining pools running unpatched nodes opened the window. The attacker used it.

Between a patch going out and every operator running it, there’s a gap. In this case, that gap was big enough to matter.

Patching the bug is step one.

Getting every operator to actually ship it is the harder problem.

13 blocks of drift is the evidence. “Patched” doesn’t mean “deployed.”

📚 Education

Missing status check lets Across relayers fill fake Solana deposits

Source

You’re building off-chain infrastructure for a Solana bridge.

Your indexer catches FundsDeposited events. Each one triggers a relayer fill on the destination chain. Across is intent-based — the relayer takes on the capital burden, fills the order, gets reimbursed from HubPool on Ethereum later.

In EVM, events are first-class. A failed transaction doesn’t emit them. In Solana, there’s no canonical events API. Off-chain infra reconstructs events from instruction data — specifically from self-CPIs, where a program calls back into itself.

The check: find inner instructions from the target program. Verify the PDA event authority is a signer. Deserialize the data. Both conditions met — fire the event.

Almost right.

Did the transaction actually succeed?

The Across indexer parsed meta.InnerInstructions for matching program address and event authority. It never checked transaction status. A failed Solana transaction still has instruction data. The event fires. The relayer sees a FundsDeposited and fills the order on the destination chain. The source-chain deposit reverted. The attacker keeps the fill.

The attack: flash loan for maximum relayer capacity. Submit a deposit on Solana. Force a revert after the deposit instruction runs — the token transfer reverts, but the instruction data stays. The relayer sees the event and fills the destination chain. You keep the fill. Flash loan repaid. Up the full fill amount.

The fix was one check: verify the transaction succeeded before processing events. Shipped within hours. 0xAlphaRush flagged the same class in a Sherlock contest for Zetachain. It’s not isolated to Across.

Solana gives you the event data regardless of outcome.

Outcome is your job to check.

If your indexer doesn’t, someone else will notice first.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• The one-character Solana bug — and what it silently broke
• The security layer Solana just built that other chains wish they had
• Anchor’s ground-up rewrite — 94% smaller, compile-time safe
• And more…

🏴‍☠️ Vulnerability

Incorrect use of .first() instead of .last() in get_signatures_for_address

From a recent Solana audit — resolved

You audit a helper function.

get_signatures_for_address. Fetches the earliest signature for an address.

Used to track: when was this account first active.

Simple function. One call. One return.

Types line up. Compiles clean.

You move on.

Here’s the question you didn’t ask:

Which direction does the RPC return signatures?

Solana RPC returns signatures newest-first.

The code calls .first().

That’s the most recent signature.

Not the earliest.

Intent and result diverged silently.

let sig = signatures.first();
// Right — list is newest-first, so last() is the earliest
let sig = signatures.last();

One character. first → last.

Every check built on “when was this address first active?” got wrong data.

Cooldowns. First-seen gating. Historical attribution.

All silently off.

The kind of bug static analysis won’t catch.

Types match. Semantics don’t.

Only one thing catches this —

reading the RPC contract and asking which direction the list comes back.

🗞️ News

Solana Foundation launches STRIDE + SIRN

Solana Foundation + Asymmetric Research — April 6

Solana just built the security layer other ecosystems wish they had.

Two programs.

STRIDE — a framework across 8 security pillars.

Asymmetric evaluates protocols. Findings published publicly.

Pass with $10M+ TVL → 24/7 monitoring, foundation-funded.

Pass with $100M+ TVL → formal verification, foundation-funded.

Founding members: Asymmetric, OtterSec, Neodyme, Squads, ZeroShadow.

Three things shift for Solana auditors:

The bar for protocols above $100M is now formal verification.

Your audit is the first step, not the last.

STRIDE findings are public.

Quality of audit work becomes legible across the ecosystem.

Standards compound.

Solo auditors don’t compete with this.

They pipeline through it.

Firms inside SIRN will surface private audits from monitored protocols.

Getting aligned with STRIDE standards matters.

The ecosystem stopped asking whether security mattered.

It started pricing it in.

📚 Education

anchor-lang-v2 — the redesigned Anchor framework

Solana Foundation / anchor-next branch

Anchor v1 shaped how auditors read Solana programs.

Five years of macro-heavy derive, runtime checks that didn’t need to exist, a core you couldn’t audit without forking.

v2 is a ground-up rewrite. Alpha, git-only, not on crates.io.

But the direction is right.

The foundation changes first:

• pinocchio under the hood,

• no more <’info> life times,

• #[no_std]` by default. Binaries up to 94% smaller.

• CU counts drop 3–6× per instruction.

The account model changes harder. `

• Account<T>` is now zero-copy by default — load is a pointer cast, exit is a no-op.

• PDA bumps precomputed at macro time for literal seeds.

• New Pod wrappers (`PodU64`, `PodVec`…) cast directly from account bytes, no deserialization.

And the safety layer shifts to compile time. Typed `CpiHandle` turns stale-borrow UB into a compile error. Many v1 footguns that used to fail at runtime now refuse to compile at all.

Here’s the part that matters most:

Which means — for the first time — the Anchor core is auditable.

Fuzzing, static analysis, and formal verification are first-class.

Every v1 audit habit needs updating.

The ones that don’t translate are the ones you most need to re-learn.

That’s it for this week.

Reply with the Solana bug, tool, or pattern you want me to cover next — I read every one.

If a working Solana auditor in your circle would find this useful, forward it their way.

— Arsen, working Solana auditor

In today’s menu:
• The note-taking system most auditors skip
• USR token minted and dumped — price crashed to $0.05
• And more…

🏴‍☠️ Hacks / Bounties
• USR token minted and dumped — price crashes to $0.05 (Link)
• Auto-allocation bug turned USR exploit into bad debt (Link)

🗞️ News
• BattleChain testnet lets whitehats attack contracts pre-mainnet (Link)
• Balancer Labs winds down after exploit fallout (Link)

📚 Education
• Why audit process matters more than findings (Link)
• The Flashloan fee inflation bug that drained $250K on dTrinity fork (Link)

Deep Dive

You reviewed the code line by line.

You feel like you understand it.

But can you explain it from memory?

Most auditors can’t.

And the ones who can’t — don’t know what they missed.

Here’s what happens after a typical line-by-line read.

You feel like you covered the function.

You move on.

10 functions later — you “reviewed” the whole contract.

Then a senior asks: walk me through the codebase from memory.

Blank.

Or worse — you trace a bug back.

And realize you skipped the exact piece that would’ve caught it.

The problem isn’t effort.

Line-by-line reading is passive.

You see the code.

You make underlying notes.

That’s not the same as understanding it.

Writing a lot pushes understanding.

When you explain something in your own words and get stuck —

That’s not failure.

That’s the system working.

Most auditors ignore that moment and keep moving.

The ones who find criticals stop, follow the thread, and write down what they find.

Here’s the process I use, function by function:

• Open a new note named after the function. Write the sub-structure first (flows/ideas). Skeleton before detail.

• Explain every line in your own words — not quoted, explained. What does it do? Who provides this value? Who can control it?

• When you catch yourself not understanding — stop immediately. Open the constructor. Write what you find. Link back. Continue.

• Log attack leads in-place. When a “what if” hits, write it right there. Tag it [DOS?] [Access?]. Write the theory. Confirm or disprove it. Don’t let it disappear into your head.

• Don’t fear rabbit holes. Your notes hold the context — your brain doesn’t have to. Go as deep as needed. You won’t lose the thread.

Here’s how it played out in a recent audit.

I was going through a reconstitute function.

Wrote: “governor checks the sender is trusted.”

Caught myself — who is governor? Where is it set?

Jumped to the constructor.

No validation on the input.

Wrote it down.

That one caught thread became a finding.

The function looked clean on first read.

The notes found the bug.

Most auditors treat notes as documentation.

A record of what they saw.

That’s wrong.

Explaining every function in your own words, following every unclear thought —

That IS the process that finds bugs.

By the time you’ve written detailed notes on every function, you’ve processed the protocol twice.

The gaps are documented, not buried.

The attack leads are on paper, waiting to be tested.

Re-read in 20 minutes what took 4 hours to build — and see it fresh.

Arsen.

Reply with what you want me to cover next — I read every one.

In today’s menu:

• Full CTF answer — the reconstitute bug, completely broken down

• Why off-chain quoting is a repeatable Medium finding pattern

• And more…

🏴‍☠️ Hacks / Bounties

1. $50M Aave Swap — Extreme Price Impact (Link)

2. Venus Protocol — $2.18M Bad Debt (Link)

3. dTRINITY Flash Loan — $257K Drained (Link)

🗞️ News

1. Solana Audit Arena Launched (Link)

2. Shutter DAO — Governance Attack Prevented (Link)

📙 Education

1. War Room Playbook for Onchain Hacks (Link)

2. AI Auditing: 47% Detection, 0% Exploit Success (Link)

Last Week’s CTF — Full Answer

Most replies mentioned slippage.

A few said stale pricing.

Almost nobody got the exact mechanism.

Here it is.

The contract runs two phases.

Phase 1: Sell every holding into base.

Simple. Approve the DEX, call the swap, measure the delta. baseReceived builds up across every holding.

Phase 2: Buy new assets using base.

for (uint256 j; j < newAssets.length;) {
    Token(base).approve(dex, allocateAmounts[j]);
    (bool ok,) = dex.call(buyData[j]);
    require(ok);
    unchecked { ++j; }
}

One question changes everything:

Where does allocateAmounts come from?

function reconstitute(
    ...
    uint256[] calldata allocateAmounts
)

It’s an input param.

Passed in from an off-chain entity —

a bot, a governor script, some automation.

That off-chain entity did this:

Called a view function on the DEX.

Simulated how much base Phase 1 would produce.

Built allocateAmounts from that simulation.

Then triggered reconstitute.

The gap:

The view call happens before execution.

Actual execution happens later.

Prices move in between.

Price moves up — contract receives more base than expected.

Phase 2 completes. Leftover base sits unspent, unaccounted.

Price moves down — contract receives less base than expected.

Phase 2 tries to spend allocateAmounts.

Doesn’t have enough. Swap fails. Transaction reverts.

DoS.

That’s a Medium.

The question that catches it every time:

“Is the amount I’m spending in Phase 2 guaranteed to match what I received in Phase 1?”

If allocateAmounts comes from outside the contract —

no guarantee.

The fix:

Validate onchain before Phase 2 runs:

uint256 totalNeeded;
for (uint256 j; j < allocateAmounts.length;) {
    totalNeeded += allocateAmounts[j];
    unchecked { ++j; }
}
require(baseReceived >= totalNeeded, "insufficient base");

Or better — derive allocateAmounts from baseReceived

directly inside the contract. Remove the off-chain dependency entirely.

The auditor pattern to carry forward:

When you see a value passed as calldata from an off-chain trigger — pause.

Ask three things:

• Where was this calculated?

• When was it calculated?

• Can the state it referenced change before execution?

“Pre-quoting” gives the off-chain system confidence.

But confidence at quote time isn’t safety at execution time.

You’ll see this in:

• Portfolio rebalancers (this one)

• AMM-based yield strategies

• Cross-chain transfers with off-chain routing

Any system where automation pre-computes amounts

and passes them in as params.

Every time — ask the same three questions.

Simple question. Consistent Medium. Sometimes High.

Arsen

Reply with what you want me to cover next — I read every one.

Time to test yours.

BasketRebalancer is an on-chain index fund.

It holds ERC-20 tokens weighted by basis points.

A governor can rebalance the basket

by selling holdings into base,

then buying new assets.

Find the vulnerability.

Answer will be dropped next Monday 🔥

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract SimpleDex {
    address public owner;
    uint256 public rate = 1e18;

    constructor() { owner = msg.sender; }

    function setRate(uint256 r) external { require(msg.sender == owner); rate = r; }

    function swap(address tIn, address tOut, uint256 amtIn, address to) external returns (uint256 out) {
        Token(tIn).transferFrom(msg.sender, address(this), amtIn);
        out = (amtIn * rate) / 1e18;
        require(out > 0);
        Token(tOut).transfer(to, out);
    }
}

contract BasketRebalancer {
    uint256 constant BPS = 10_000;

    address public governor;
    address public base;
    address public dex;
    address[] public holdings;
    uint256[] public bps;

    constructor(address _gov, address _base, address _dex) {
        governor = _gov; base = _base; dex = _dex;
    }

    function setComposition(address[] calldata a, uint256[] calldata b) external {
        require(msg.sender == governor);
        require(a.length == b.length && a.length > 0);
        uint256 t;
        for (uint256 i; i < b.length;) { require(b[i] > 0); t += b[i]; unchecked { ++i; } }
        require(t == BPS);
        holdings = a; bps = b;
    }

    function deposit(address token, uint256 amount) external {
        Token(token).transferFrom(msg.sender, address(this), amount);
    }

    function rebalance(
        address[] calldata newAssets,
        uint256[] calldata newBps,
        bytes[]   calldata sellData,
        bytes[]   calldata buyData,
        uint256[] calldata allocateAmounts
    ) external {
        require(msg.sender == governor);
        require(newAssets.length == newBps.length && newAssets.length > 0);
        require(buyData.length == newAssets.length);
        require(allocateAmounts.length == newAssets.length);

        uint256 t;
        for (uint256 i; i < newBps.length;) { require(newBps[i] > 0); t += newBps[i]; unchecked { ++i; } }
        require(t == BPS);

        // Phase 1: sell all current holdings → base
        uint256 baseReceived;
        for (uint256 i; i < holdings.length;) {
            address asset = holdings[i];
            uint256 bal = Token(asset).balanceOf(address(this));
            if (bal > 0) {
                if (asset == base) {
                    baseReceived += bal;
                } else {
                    uint256 before = Token(base).balanceOf(address(this));
                    Token(asset).approve(dex, bal);
                    (bool ok,) = dex.call(sellData[i]);
                    require(ok);
                    baseReceived += Token(base).balanceOf(address(this)) - before;
                }
            }
            unchecked { ++i; }
        }

        // Phase 2: buy new assets with base
        if (baseReceived > 0) {
            for (uint256 j; j < newAssets.length;) {
                Token(base).approve(dex, allocateAmounts[j]);
                (bool ok,) = dex.call(buyData[j]);
                require(ok);
                unchecked { ++j; }
            }
            holdings = newAssets;
            bps = newBps;
        }
    }
}

• Aave wstETH Oracle Error — $21M in Unfair Liquidations (Link)

• DBXen ERC2771 Exploit — $150K Loss (Link)

• Alkemi Self-Liquidation — $90K Loss (Link)

🗞️ News

1. Ethereum Bug Bounty Raised to 1M (Link)

2. Safe Zodiac Roles Permission Bypass (Link)

📙 Education

1. 9 Common Vault Bugs — Real Audit Findings (Link)

2. ERC-4337 Account Abstraction Security Risks (Link)

Deep Dive

That’s not the end. That’s the starting line.

We’re not programmers. We don’t write much code.

We read it. Every day. That’s the job.

Nobody teaches you how to read code properly.

You grind courses, collect tools, study vulnerabilities.

But the skill senior auditors do 80% of the day?

Reading code fast and deeply.

Most people are terrible at it.

The problem

Here’s what beginners do.

They open the codebase. Open the docs.

50 pages of specs and architecture diagrams.

Page 5 — overwhelmed.

Page 10 — lost the thread.

Haven’t touched a single line of code.

Or worse — they jump into one function.

Go deep immediately. Lose the whole system’s context.

Waste 3 hours on something that doesn’t matter.

Then they say:

No. You didn’t understand the code. You just read it.

The bugs are still sitting there.

The real problems:

• Docs first = overwhelm before you even start

• Going deep too early = wasted time

• “No bugs found” = you stopped at understanding

• No system = random scanning, random results

The 3 layers

Code reading has 3 layers.

Most auditors only do 1 or 2.

Layer 1: Skim & Contextualize.

Grab the big picture. Jump into the code. Not docs.

Layer 2: Deep Read & Memorize.

Go line by line. Walk the entire flow in your head

without looking at the screen.

Layer 3: Research.

This is where bugs actually live.

NOW read the docs. Compare to reality.

Study other protocols. Work backwards from failure modes.

Here’s the game-changer:

AI accelerates Layer 1 massively.

Feed it each function. Get line-by-line comments.

Ask it to explain flows above each function.

You get context 10x faster — and save that time for Layer 3.

Most auditors stop after Layer 2.

The ones finding criticals? They live in Layer 3.

The playbook

LAYER 1: SKIM & CONTEXTUALIZE

• Jump into code first. Not docs.

• Skim every function without going deep.

• Identify entry points, libraries, integrations, main actors.

• Use AI as your co-pilot here:

feed each function → get comments → map the flows.

• This is orientation. Not understanding yet.

You’ll lose context before you start.

LAYER 2: DEEP READ & MEMORIZE

• Go function by function, line by line.

• For each critical function: what it validates,

who can call it, what state it changes.

• The goal: close the editor.

Explain the entire flow from memory.

• If you get stuck — do another pass.

• ~50% of your audit time = Layer 1 + Layer 2.

Common mistake: moving to “bug hunting”

before you can explain the system from memory.

LAYER 3: RESEARCH (where bugs live)

• Read the docs NOW.

Compare every claim to the code. Contradictions = bugs.

• List developer assumptions. Ask: “What if this is wrong?”

• Study how other protocols solve the same problem.

• Research every error in try-catch blocks.

• Work backwards: all failure modes → eliminate what can’t happen

→ what survives is your attack surface.

Common mistake: treating “I understand the code”

as the finish line instead of the starting line.

Timeline for a 10-day engagement:

• Days 1–2: Layer 1 — skim, map, use AI

• Days 2–5: Layer 2 — deep read, memorize

• Days 5–10: Layer 3 — research, docs, comparisons

Arsen

Reply with what you want me to cover next — I read every one.

In today’s menu:

• Why the old contest playbook is dead — and the 3 shifts that replaced it

• $10.8M oracle hack, $150K live contest, AI finds a Uniswap bug

• What to do before your next contest (most skip this)

Best links this week:

🏴‍☠️ YieldBlox drained for $10.8M via oracle manipulation → link

🏴‍☠️ Guardian drops $150K AMM contest — LimitBreak → link

🗞️ Uniswap V4 bug found via AI-assisted auditing → link

📙 Zellic: Inside the SVM — sBPF JIT pitfalls → link

Deep dive

Everyone says contests are dead.

Everyone says junior auditors are cooked.

Here’s the truth: no one knows.

There’s only opinions. And one fact.

The complexity bar is rising.

Forget about weird ERC20 tokens.

In 2021, people earned good money on simple bugs. Set up firms. Called themselves auditors.

In reality — intermediate at best.

When I jumped in during 2024, it was harder. Bugs weren’t trivial. But there were still plays. Dummy bugs earning $20K+.

Now? One way forward.

Prove you can find deep bugs in business logic.

But here’s what most people miss.

Contests aren’t dead.

The old approach to contests is dead.

“Jump in, learn on the go, find some bugs, get paid.”

That worked 1-2 years ago. Not anymore.

A contest in 2026 is a test.

A test for auditors hungry enough to adapt.

Less “animals” to hunt. So you change the strategy.

Here’s what actually works now:

1. Combine forces.

Why hunt alone?

Find 2-3 hungry auditors. Build a system for gathering project context fast.

That’s what eats your time — understanding, not hunting.

The mistake juniors make: rushing to submit.

Low-hanging fruit gets duplicated by 200 people. Real bugs hide deeper. You need research time after you already understand the system.

2. Use AI for understanding. Not hunting.

AI makes you dumb if you let it.

Critical thinking is the one skill you must develop.

Without it — $1 leaderboard auditor forever.

Use AI to gain context faster. Not to find the bugs.

The best AI usage comes from seniors who know what to aim it at.

If you’re junior, don’t overrely.

3. Specialize in one domain.

Early on, I jumped from contest to contest.

Cross-chain. AMM. Lending.

Nothing stuck.

Now? Pick one domain.

AMM contest dropping in 2 weeks?

Grind hard on AMM knowledge, bugs, patterns. Show up prepared. Not hoping. Prepared.

And treat every contest as compound interest.

Low payouts? You’re building the muscle.

Pattern recognition. Speed. Domain knowledge.

30 contests with small wins will crush quitting after 3.

After each one — write a 5-line retro.

What you found. What you missed. What you’d change.

That’s your personal edge database.

Stop measuring success by payout alone.

The real ROI is the skill compounding.

This newsletter gives you the direction.

But the full system — team audit setups, contest prep workflows, domain specialization paths, weekly live Q&As where I break down exactly how I approach each contest — that’s what we build inside Defendor Academy.

If you want to stop guessing and start winning, everything you need is there. [link]

See you there

Play close attention.

Since it destroys 80% of auditors, including ones with a strong track record.

It’s simple:

You believe you’ve found all the bugs — and you stop early.

This is the most common self-inflicted mistake in Web3 security.

Not because you’re unskilled.

But because your brain wants comfort.

Auditing is mentally hard.

You stare at the same lines for hours.

You stretch your mind to generate new attack angles again and again.

And the moment you feel like you’ve “made progress,” your brain tries to convince you:

“Good job. Enough. You’re done.”

This is the trap.

And there is only one rule that breaks it:

Bugs always exist. Hunt until the last second.

Remember it.

Stick it into your audit identity.

This rule alone will change your entire progress curve — because it forces your brain to stay in attacker mode instead of comfort mode.

And 2025 proved this point brutally well.

Balancer — broken.

GMX — broken.

After years of operation.

After multiple audits.

After thousands of eyes.

And you still think a 3-4 week audit means “everything is covered”?

Let me show you the moment that permanently completely changed me.

Early 2025.

I was collaborating with very well known audit firm

This specific audit was conducted by use a 2x2 structure:

Two auditors vs two auditors, competing on the same repo.

It’s one of the most effective ways to boost curiosity, aggression, and pace during an audit.

But the strongest part isn’t the competition.

It’s the scoreboard.

You can’t see the issues themselves — but you can see how many H/M/L the other team has found.

Now picture this.

Last day of the audit.

I slowed down.

I thought the repo was empty. I convinced myself that the hard bugs were already found.

Then a message pops up:

“Other team is 1H ahead.”

• Instant adrenaline.

• Instant humiliation.

• Instant clarity.

I closed everything I was doing — restaurant, cinema, didn’t matter —

opened my laptop and hunted like an animal.

Example link

To understand this bug, you need just one idea:

Collateral and PnL are updated through different mechanisms.

• Collateral updates through:modifyCollateral() or _settleOrder()

• PnL updates only when you call:_settleOrder()

Meaning:

Your collateral does NOT include PnL until you commit-settle.

But the vault’s redeem logic assumes the opposite.

Where Things Break

The redeem flow calls _valueToRedeem():

valueToRedeem = totalAssets() * (shares / totalSupply)

And here’s the problem:

totalAssets() includes PnL — even if it’s NOT settled yet.

So the vault uses unrealized, un-settled PnL as if it already exists as collateral.

Then, during actual withdrawal, the vault calls modifyCollateral:

• modifyCollateral works with real collateral tokens only

• It cannot withdraw unrealized PnL (because it’s not collateral yet)

This creates a mismatch.

And every single time similar push, I found something I would’ve missed if I relaxed.

This is the truth nobody wants to admit:

If you want to grow, you must hunt actively — until the last second. Not until you’re comfortable. Until the code is empty.

This is the difference between plateaus and breakthroughs.

Between $2k bugs and $200k bugs.

Between staying mid and becoming senior.