3 new security reviews starting out tomorrow, all longer ones (>1 week in duration), big teams of security experts. Expecting lots of vulnerabilities uncovered.
As security researchers, stay active at all times, audit every day. It's a muscle - use it or lose it, choose right🫡
`solidity-auditor` v3 from pashov/skills has found countless Critical/High vulnerabilities for Solidity devs & security researchers
v4 is coming this week. Better recall than ever. Fully Open Source, MIT License, built to serve everyone in the Solidity community. Get ready🫡
Security Researchers must serve builders and never to act adversarially. Always be patient, calm and helpful. That's the essence of the job.
Many builders don't understand the importance & depth of our security work - don't get into conflicts but educate them with patience🫡
A project that manages upgradeable ERC20 assets portfolios with mint/redeem and dutch auction mechanisms.
This is what we start to audit tomorrow, luckily we've audited similar code logic tens of times. Let's do this🫡
🚨Seems a Critical Vulnerability was discovered in the Bitcoin Core Lightning Network - take your nodes offline
Hidden source code (with the idea of patches not being reverse-engineerable) binaries, holding a fix, will be published in <48hrs
Discussion:
https://t.co/510e8FzOkJ
One invariant neutralizes inflation & donation attacks — the vector behind most vault drains
Checkpoint the rate. Revert + auto-pause on >X% deviation per block
A vault's share rate (totalAssets/totalSupply) moves in bps per day. Exploits move it 10–1000x in one tx
🚨 New bug bounty alert! 🚨
@strata_markets has joined the Immunefi security ecosystem with a bug bounty program rewarding up to $250,000 USD for finding vulnerabilities in their risk-tranching protocol.
🔒 Security researchers: help harden DeFi and earn rewards. Start hunting now: https://t.co/x46IdEmt56
🚨Solidity devs: single command in your AI prompt now gets you to ~80% stateful fuzz-testing coverage.
Introducing Fizz, fully open source. From repo to invariants, tests, runs and coverage report.
Help more people - like & retweet. Stay safe🫡
https://t.co/DFtNcwpAYo
We’ve worked with billion-dollar protocols and organised ~200 security audits over the past ~4 years.
🚨Here are 5 rules every Web3 project MUST live by in 2026:
(BOOKMARK AND RETWEET)
1. Don’t rely on AI security alone before mainnet
We are not there yet. AI should be leverage for auditors, a tool that helps them deliver better results, not a substitute at this point. Dev teams running automated tools and calling it an audit is absurd. That’s how you start getting hacked. Security can be expensive, but it’s mandatory and existential. If you had $50M stored in your house, wouldn’t you invest heavily in protecting it?
2. High-paid devs ≠ secure code
I’ve spoken to many founders who believe that because they hired expensive developers, mistakes won’t happen. They will. Everyone is biased toward their own code. Security requires an unbiased, professional opinion from a dedicated audit firm. Never assume your devs can’t make mistakes, because that assumption can cost you everything.
3. Clear documentation reflects a clear threat model
This is extremely important for auditors. The clearer your documentation, the faster and more accurately they can understand your protocol and its intended behavior. If it improves the auditor’s work, it directly improves your security, so there’s no reason to neglect it. Messy or incomplete documentation increases risk and frustrates both auditors and users.
You also need well-structured contracts and proper NatSpec reduce audit blind spots.
Good structure makes complex systems easier to reason about and reduces the chance of missing critical issues. Follow the official Solidity guidelines and keep your code clean and consistent. Poor structure hides vulnerabilities and slows down the entire audit process.
4. Too many Crits and Highs? Don’t deploy
If you have lots of Critical and High findings in your first audit, that’s a clear signal there are likely more bugs in the codebase. An audit is a time-restricted engagement, and if the system is full of issues, not everything may be uncovered within scope. That’s not the auditor’s fault. In this case, you need a second audit before even considering mainnet.
5. Have a detailed incident response plan
You may think it can never happen to your protocol, but no one is 100% safe. There is always a real chance something goes wrong, and you need to be prepared. You need:
- Clear communication strategy
- Defined roles and responsibilities
- Precise steps in case of a hack
- Pre-made decisions such as pausing contracts or freezing assets
Everything should be prepared in advance, down to the last detail.