Zero Cipher

Three years ago I submitted my first Web3 contest entry on Code4rena. Found one QA issue. Thought maybe I'd chosen the wrong career path. This year I collected $300,000 from a single critical bug report. This space rewards depth and patience in ways I didn't fully understand when I started.

Everyone thinks they understand flash loan attacks. Most don't. Most people think flash loans are about the money. Borrow millions. Manipulate a price. Return the loan. Pocket the difference. That's the surface. What if the attack isn't related to the capital. What if it utilizes the state manipulation that the capital enables within a single transaction. Beanstalk. April 2022. $182 million. The attacker didn't exploit a price oracle. They used the flash loan to temporarily acquire governance control. Passed a malicious proposal. Drained the treasury. In one transaction. The vulnerability wasn't in the flash loan mechanics. It wasn't even in the price feed. It was in the assumption that governance proposals couldn't be executed within a borrowing window. I found a similar governance timing assumption in a recent audit. The protocol had a 24-hour timelock on proposals. No protection against flash-loan-powered quorum acquisition. The team had reviewed every oracle interaction. They hadn't considered that an attacker could borrow their way into governance power. Never audit flash loan surfaces by just looking at the surface. Audit what the loan temporarily makes possible.

Recently, saw some chatter about how total payouts vary across web3 bug bounty platforms. So I compared the top 10 earners on each: Immunefi: $55.3M HackenProof: $6.3M Cantina: $1.5M Immunefi is ~8.8x HackenProof. HackenProof is ~4.2x Cantina. Curious how much of this is: - platform maturity - deal flow - private vs public payouts - where top researchers choose to spend time (Note some of these numbers could be inaccurate as I calculated these numbers on publically available information in the leaderboards)

Food for thought: Web3 founders are being ripped off by AI tools. These tools are sold to founders as the answer to smart contract security. The protocols buying them are becoming the next “$100M stolen” case studies. In the past eighteen months, multiple protocols launched after AI-assisted security review flagged zero critical findings. Human researchers reviewing the same code post-exploit found the vulnerability in under two hours. The AI did not miss it because the AI was wrong. The AI missed it because the vulnerability lived in the economic assumptions underneath the code. Not in the code itself. AI tools audit what is written. They cannot audit what was assumed. The false confidence created by a clean AI report is not neutral. It is actively dangerous. A team that receives "no critical findings" from an automated tool ships with certainty. No human review scheduled. No invariant testing campaign. The tool already checked it. Except the tool optimized for pattern matching. And the exploit required understanding intent. Now imagine this playing out across an ecosystem where reducing audit cost is a competitive pressure. Where "AI-assisted security review" becomes an industry norm. Where founders can't distinguish between a tool that found nothing dangerous and a tool that couldn't see the danger that existed. AI tool companies are selling "automated security coverage" to protocols. Protocol teams are buying it to ship faster and cheaper. Attackers are actively cataloguing the vulnerability classes these tools consistently miss and building their exploit playbooks around exactly those gaps. Three different actors. Three different incentives. All producing the same outcome. The attack surface AI tools cannot see is the attack surface that will be exploited. The teams purchasing AI audit tools are not solving their security problem. They are paying to feel like they did

I was six days into an audit when I stopped reading the code. The protocol was clean. Good architecture. Solid access controls. Consistent naming. The kind of codebase that makes most auditors write "no critical findings" and move on. I didn't write that. Instead I opened a blank document and wrote one sentence: "How would I steal everything in this contract right now?" Then I spent the next twelve hours answering that question. Most auditors review your code looking for mistakes. I review your code trying to drain it. Different starting point. Completely different findings. When I work through a codebase, I don't start at line one. I start at the withdraw function. The transfer function. The liquidation function. Any function that moves value. Then I ask: what sequence of calls would let an attacker walk away with everything? This approach doesn't catch more bugs. It catches more criticals. Because critical vulnerabilities don't look like bugs. They look like features used in the wrong order. If you're shipping soon and want someone who hunts for the drain before an attacker does, DM us at @VulsightSec

Spent 3 days building a proof of concept for a critical in a bug bounty. Full exploit chain. Exact steps showing how to drain the pool. Marked duplicate. Another researcher submitted the same finding hours before me. 72 hours of work. Zero payout. On to the next one.

The exploit that drains your protocol probably won't be sophisticated. It will be a single missing check. A function that accepts arbitrary token addresses without a whitelist. An attacker deploys a malicious contract that returns inflated price data. Uses it as collateral. Borrows real assets. Drains the pool. The fix is one line of code. A whitelist check on accepted collateral addresses. This exact pattern shows up constantly. In lending protocols. In liquidation functions. In any system that trusts external token inputs without validation. I've caught this pattern in pre-deployment audits. The teams that had it reviewed avoided catastrophic loss. The ones that didn't are the ones you read about. The difference between a multimillion dollar loss and a $0 loss is often just one review by someone who's seen the pattern before. How many protocols are live right now with this same vulnerability

@TheTradMod @fredrik0x High is still same xD

@fredrik0x @zerocipher002 xD

The Ethereum Foundation Bug Bounty Program (bounty.ethereum.org) has increased its maximum payout from $250K to $1M.

The biggest shift in my security career wasn't learning a new language. It was learning to stop thinking like a developer. Early on, I reviewed code asking: "Does this work correctly?" Wrong question. Developers build for the expected path. Attackers live in the unexpected. Every input you didn't validate. Every state you didn't consider. Every assumption you made about user behavior. That's where the bugs live. The shift happened when I stopped reading code to understand it and started reading code to break it. Different question. Completely different results. The best auditors don't think like better developers. They think like attackers who understand development.

ZK circuits are the least audited and most dangerous code in crypto right now. Most teams focus on the smart contract layer. The real risk lives underneath, in the constraint system. A ZK circuit defines what a prover must satisfy to generate a valid proof. If a constraint is missing or too loose, a malicious prover can create valid proofs for invalid state transitions. An under-constrained circuit can: Allow forged proofs that bypass validation entirely Enable double-spending through unchecked nullifiers Let attackers mint tokens from nothing with a valid-looking proof The worst parts are these bugs don't show up in testing. The circuit compiles. The proofs verify. Everything looks correct. Until someone crafts an input that satisfies your constraints but violates your intent. Most auditors treat ZK systems as a black box. They audit the Solidity verifier and skip the circuit. That's like auditing the front door while ignoring the open window. If you're building with ZK, your circuit isn't infrastructure, it's your most critical attack surface.

Your protocol had three audits and still got exploited. This happens more often than you think. Audits are point-in-time snapshots. They cover the code as it existed on the day of review. But protocols evolve. New integrations. Upgraded contracts. Modified parameters. Forked dependencies. Every change after an audit creates unreviewed attack surface. I've found criticals in codebases that had been audited twice before. Not because the previous auditors were bad. Because the code changed after their review. Three audits on three versions of your code doesn't mean your current version is safe. It means three old versions were reviewed. Security isn't a certificate. It's a process. If your last audit was before your last deploy, you're running unreviewed code in production.

One of the biggest bounties I've earned came from a vulnerability that most auditors would have never found. Not because it was deeply complex. Because it wasn't where anyone was looking. The vulnerability didn't exist in the GitHub version of the smart contract. It only existed in the on-chain deployed contracts. The code that was actually live, holding real funds. Most auditors only review the GitHub repo. That's the standard scope. But the deployed contract can differ. Different constructor arguments. Post-deployment configurations. State changes after initialization. I found it because I wasn't randomly scrolling through code. I chose one specific impact I wanted to test for: drain of funds. Then I worked backwards. Where does the money flow? Which functions move funds? What checks exist on those paths? I audited both the GitHub repo and the on-chain contracts. The discrepancy between them is where the critical was hiding. The methodology is simple. Pick the worst-case impact. Trace every path that could lead there. Audit both the repo and what's actually deployed. The GitHub repo is a draft. The on-chain contract is what attackers see. Audit both.

The most underestimated bug class in smart contracts isn't flash loan attacks or oracle manipulation. It's broken access control. Missing role checks on admin functions. Unprotected initializers. Public functions that should be internal. Privilege escalation through unvalidated callers. These aren't sophisticated exploits. They're oversights. But they consistently account for some of the largest losses in DeFi. Functions that simply didn't check who was calling. I've found access control bugs in protocols that passed multiple audits. Previous auditors focused on complex DeFi logic and overlooked a public function with no modifier. Every audit I start, I check every external and public function with one question: "Who can call this, and what happens if the wrong person does?"

Formal verification makes your protocol safe. Except when it doesn't. Formal verification proves your code matches your specification. It doesn't prove your specification is correct. I've audited formally verified codebases. Found criticals in two of them. The proofs were mathematically sound. The assumptions behind them weren't. A spec that doesn't model edge cases in liquidation logic won't catch a liquidation exploit. No matter how many theorems you prove. Most teams treat formal verification as the final layer of security. It's not. It's one layer. Verification without adversarial review is expensive false confidence. The math was perfect. The model was incomplete.

@bbl4de_xyz @immunefi Great work brother 🔥

I just found a confirmed bug on @immunefi #immunefitribe immunefi.com/s/ss/?severity…

@0xnirlin @AdevarLabs Million dollar bounty wen 👀

After a great run at @AdevarLabs, I'm going independent. I will be focusing more on Solana security, research, and pursuing other web3 security interests. If you're building on Solana and want your project battle-tested, DMs are open.

@WhiteHatMage @VulsightSec Thank you sir. Always nice to hear appreciation from someone who inspired me to work harder in web3sec :)

Good job @VulsightSec 🫡

@WhiteHatMage Thank you sir. Highly appreciated :)

Bounties are back. Great job @zerocipher002

$300,000 from a single bounty. Also yes, it was Move related. Move helps, but it doesn’t magically make protocols safe. The real bugs still live in assumptions, invariants, and integrations. Proud of what VulSight has been doing too. We’ve cleared over $500k in bounties in the last 2 months. If you’re a founder and you want an audit team that consistently finds criticals, we’re a DM away.