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.