Josselin Feist retweeted
We’re aware of reports of a potential incident affecting Binance-affiliated wallets.
Aave’s contracts are unaffected, and positions remain overcollateralized. As a precaution, all DAO-operated markets across V3 and V4 have been frozen.
The freeze pauses new deposits and borrows, and users can still withdraw and repay their existing positions.
Aave’s contracts are unaffected, and positions remain overcollateralized. As a precaution, all DAO-operated markets across V3 and V4 have been frozen.
The freeze pauses new deposits and borrows, and users can still withdraw and repay their existing positions.
104
155
1,268
260,138
After the week we’ve just had, DeFi and blockchain protocols need internal security more than ever
This was just a preview. We are going to see a lot more vulnerabilities and incidents in the coming months
Time to build your in-house security expertise
This was just a preview. We are going to see a lot more vulnerabilities and incidents in the coming months
Time to build your in-house security expertise
Most protocols spend a lot on audits and bug bounties but have zero internal security
Launching whohassecurity.com to highlight the ones that do
Having an internal security team should be in every protocol's New Year's resolutions for 2026
5
3
47
2,016
Tldr: if you want to find bugs in your codebase, use the latest frontier models
You don’t need a security-specific model outside of a few cases, like doing offensive work (building exploits), working on something sensitive, or running a business that depends on cheap inference
You don’t need a security-specific model outside of a few cases, like doing offensive work (building exploits), working on something sensitive, or running a business that depends on cheap inference
At HackerOne, we benchmarked 18 frontier LLMs against 62 fairly complex vulnerabilities
See which model stands where
(link in the thread)
8
2
57
3,839
A good reminder that keeping your code closed-source for security purpose is a bad strategy
If you distribute a binary, treat it as if attackers have the source code
If you distribute a binary, treat it as if attackers have the source code
1/ As someone who have worked on reverse engineering for 10+ years, I've never seen this much excitement around it. Great work, @morluto and @reatools!
Since RE is having such a moment 🔥, I figured I'd share some updates from sre-bench.lol to help you pick the right model.
3
3
37
1,877
Josselin Feist retweeted
it seems you peeps need a nudge! Many roles are open at @aave right now:
- BE eng: 5+ yrs Rust, DeFi or payments (fiat on/off-ramps)
- Protocol sec researcher: 4+ yrs in vaults, lending, DeFi
- FE eng: 5+ yrs, performance-minded
DMs as always open 👀
- BE eng: 5+ yrs Rust, DeFi or payments (fiat on/off-ramps)
- Protocol sec researcher: 4+ yrs in vaults, lending, DeFi
- FE eng: 5+ yrs, performance-minded
DMs as always open 👀
17
15
193
36,725
Josselin Feist retweeted
DMs open for flooding 🌊🌊
We are also hiring a smart contract engineer: aave.com/careers/staff-…
The team is building some really cool stuff. If you want to help build what comes next for DeFi, join us
0
1
40
4,153
We are also hiring a smart contract engineer: aave.com/careers/staff-…
The team is building some really cool stuff. If you want to help build what comes next for DeFi, join us
The team is building some really cool stuff. If you want to help build what comes next for DeFi, join us
We are hiring a security researcher at @aave
Join us to review our smart contracts, build our AI-assisted tools, and help secure the ecosystem
You will work directly with me, have room to experiment, and develop new approaches as our industry evolves
aave.com/careers/protoc…
8
9
80
15,244
We are hiring a security researcher at @aave
Join us to review our smart contracts, build our AI-assisted tools, and help secure the ecosystem
You will work directly with me, have room to experiment, and develop new approaches as our industry evolves
aave.com/careers/protoc…
Join us to review our smart contracts, build our AI-assisted tools, and help secure the ecosystem
You will work directly with me, have room to experiment, and develop new approaches as our industry evolves
aave.com/careers/protoc…
16
21
241
46,222
Josselin Feist retweeted
We're hiring developers to work on Hegel (property-based testing for ~every language) in London with me, and are struggling a bit to source candidates, so I wrote a less professional post about why this is the coolest job ever and you should apply.
drmaciver.com/2026/09/come-w…
drmaciver.com/2026/09/come-w…
32
58
425
55,282
GPT-6 is out, yet so many companies are still hiring. I thought we were all doomed?
- Security Engineer, Product, at @AptosLabs: job-boards.greenhouse.io/aptoslabs/jobs…
- Smart Contract Security Engineer at @binance: jobs.lever.co/binance/0477fd…
- Senior Security Engineer at @chainlink: chainlinklabs.com/open-roles?ash…
- Product Security Engineer at @coinbase: coinbase.com/careers/positi…
- Protocol Security Researcher at @ethereumfndn: jobs.ashbyhq.com/ethereum-found…
- Security Engineer at @ether_fi: jobs.ashbyhq.com/ether.fi/64b9a…
- Blockchain Security Lead at @galaxyhq: job-boards.greenhouse.io/galaxydigitals…
- Staff Security Operations Engineer at @Ledger: jobs.ashbyhq.com/ledger/6584957…
- SecOps Engineer at @LidoFinance: lido.fi/opportunities/…
- Head of Security at @Morpho: morpho.org/jobs/ashby-hea…
- Senior Application Security Engineer @MetaMask: consensys.io/open-roles/774…
- Security Engineer at @Offchain jobs.lever.co/offchainlabs/d…
- Senior Security Engineer - Product Security at @Ondo : job-boards.greenhouse.io/ondofinance/jo…
- Protocol Security Engineer at @the_matter_labs: jobs.ashbyhq.com/matter-labs/88…
- Senior/Staff Mobile Security Engineer at @tfh_technology: jobs.ashbyhq.com/Tools%20for%20…
- Security Engineer at @tempo: jobs.ashbyhq.com/tempo-xyz/361e…
- Security Engineer, Product, at @AptosLabs: job-boards.greenhouse.io/aptoslabs/jobs…
- Smart Contract Security Engineer at @binance: jobs.lever.co/binance/0477fd…
- Senior Security Engineer at @chainlink: chainlinklabs.com/open-roles?ash…
- Product Security Engineer at @coinbase: coinbase.com/careers/positi…
- Protocol Security Researcher at @ethereumfndn: jobs.ashbyhq.com/ethereum-found…
- Security Engineer at @ether_fi: jobs.ashbyhq.com/ether.fi/64b9a…
- Blockchain Security Lead at @galaxyhq: job-boards.greenhouse.io/galaxydigitals…
- Staff Security Operations Engineer at @Ledger: jobs.ashbyhq.com/ledger/6584957…
- SecOps Engineer at @LidoFinance: lido.fi/opportunities/…
- Head of Security at @Morpho: morpho.org/jobs/ashby-hea…
- Senior Application Security Engineer @MetaMask: consensys.io/open-roles/774…
- Security Engineer at @Offchain jobs.lever.co/offchainlabs/d…
- Senior Security Engineer - Product Security at @Ondo : job-boards.greenhouse.io/ondofinance/jo…
- Protocol Security Engineer at @the_matter_labs: jobs.ashbyhq.com/matter-labs/88…
- Senior/Staff Mobile Security Engineer at @tfh_technology: jobs.ashbyhq.com/Tools%20for%20…
- Security Engineer at @tempo: jobs.ashbyhq.com/tempo-xyz/361e…
Most protocols spend a lot on audits and bug bounties but have zero internal security
Launching whohassecurity.com to highlight the ones that do
Having an internal security team should be in every protocol's New Year's resolutions for 2026
6
8
96
8,752
Almost five months since this tweet, but enough has changed that I think it is worth revisiting a few points
> "The real question is: do LLMs get another capability jump, or just steady iteration?”
The first observation is that models did improve, but so far it has looked more like steady iteration than a significant step change. We will see where we are with astra and anthropic’s equivalent, and whether that continues to be the trend
> "My current bet is that within a few months, tools like Codex or Claude Security will be great at finding blockchain issues.”
I think it is pretty clear today that foundation models, and their baseline harnesses, can find cool blockchain vulns on their own. And they are good at it
Open models are also becoming interesting. There is still a gap with the best closed models, but the gap is now small enough that they are worth paying attention to
Interestingly, I see fewer of what I would call "traditional" false positives from codex/claude. The noise comes more from incorrect assumptions. The model shows a real path, and the reasoning might be correct, but it is based on a wrong assumption (e.g. incorrect config, impact that does not matter, an action no one would do, etc). So improving the results might become less about "can the model reason about this code?" and more about "does the model have the right assumptions?". And we are moving from "adding intelligence" to "adding the right context"
Specialized harnesses still have an edge today, but it is unclear to me how durable that edge is. Something like /goal with the right prompt is already powerful
That said, I have been experimenting a bit with harness self-improvement / customization. It is still experimental, but I could see a world where every team has its own customized harness, built from past audit reports, bug bounties, known assumptions, previous findings, etc. That could become a direct feature from codex/claude
If you build your own product, being better than claude/codex is not enough. You need to be better by enough to justify the friction of adopting another product. Maintaining that margin at low cost while the baseline improves every few months is challenging. That said, if a team manages to keep a lead, there is a lot of opportunity for them
But I think we are also past being impressed by claims like "our AI made $X million in bug bounties". Finding bugs is, ironically, the easy part. Finding useful bugs at low cost, with low noise and little human intervention is the hard part. That was true before LLMs, and it is still true now
So if you see a benchmark that only focuses on bugs found, without tokens spent and number of findings generated, you won’t know much. Similarly, a company saying its tool generated millions in bug bounties without saying how much it spends on inference per months and human review might not be that impressive
On the manual review side, I have now integrated LLMs pretty deeply into my own audit process. Building an LLM-wiki of a codebase on the fly is great. But there are downsides, and you might end up creating blind spots by not building your own proper intuition. I have tried different prompting strategies to reduce that. For example, explaining my understanding of a component to the LLM and asking it to challenge me, instead of asking it to explain the component directly. But nothing is perfect in my experience yet, so I have not found the right balance
That said, even if there are downsides to that approach, I do think LLM-assisted manual review is becoming the norm. So if you think LLMs do not create blind spots during audits, you are probably missing bugs. But if you think the solution is not to use them, you will probably get outperformed
Another area I am starting to look at more is LLM-generated code itself. I would not be surprised if we see new classes of bugs emerge from it. Sometimes models make mistakes that no human would make. Maybe models will improve enough that this disappears. But if not, there might be some interesting new attacks to consider
> "The real question is: do LLMs get another capability jump, or just steady iteration?”
The first observation is that models did improve, but so far it has looked more like steady iteration than a significant step change. We will see where we are with astra and anthropic’s equivalent, and whether that continues to be the trend
> "My current bet is that within a few months, tools like Codex or Claude Security will be great at finding blockchain issues.”
I think it is pretty clear today that foundation models, and their baseline harnesses, can find cool blockchain vulns on their own. And they are good at it
Open models are also becoming interesting. There is still a gap with the best closed models, but the gap is now small enough that they are worth paying attention to
Interestingly, I see fewer of what I would call "traditional" false positives from codex/claude. The noise comes more from incorrect assumptions. The model shows a real path, and the reasoning might be correct, but it is based on a wrong assumption (e.g. incorrect config, impact that does not matter, an action no one would do, etc). So improving the results might become less about "can the model reason about this code?" and more about "does the model have the right assumptions?". And we are moving from "adding intelligence" to "adding the right context"
Specialized harnesses still have an edge today, but it is unclear to me how durable that edge is. Something like /goal with the right prompt is already powerful
That said, I have been experimenting a bit with harness self-improvement / customization. It is still experimental, but I could see a world where every team has its own customized harness, built from past audit reports, bug bounties, known assumptions, previous findings, etc. That could become a direct feature from codex/claude
If you build your own product, being better than claude/codex is not enough. You need to be better by enough to justify the friction of adopting another product. Maintaining that margin at low cost while the baseline improves every few months is challenging. That said, if a team manages to keep a lead, there is a lot of opportunity for them
But I think we are also past being impressed by claims like "our AI made $X million in bug bounties". Finding bugs is, ironically, the easy part. Finding useful bugs at low cost, with low noise and little human intervention is the hard part. That was true before LLMs, and it is still true now
So if you see a benchmark that only focuses on bugs found, without tokens spent and number of findings generated, you won’t know much. Similarly, a company saying its tool generated millions in bug bounties without saying how much it spends on inference per months and human review might not be that impressive
On the manual review side, I have now integrated LLMs pretty deeply into my own audit process. Building an LLM-wiki of a codebase on the fly is great. But there are downsides, and you might end up creating blind spots by not building your own proper intuition. I have tried different prompting strategies to reduce that. For example, explaining my understanding of a component to the LLM and asking it to challenge me, instead of asking it to explain the component directly. But nothing is perfect in my experience yet, so I have not found the right balance
That said, even if there are downsides to that approach, I do think LLM-assisted manual review is becoming the norm. So if you think LLMs do not create blind spots during audits, you are probably missing bugs. But if you think the solution is not to use them, you will probably get outperformed
Another area I am starting to look at more is LLM-generated code itself. I would not be surprised if we see new classes of bugs emerge from it. Sometimes models make mistakes that no human would make. Maybe models will improve enough that this disappears. But if not, there might be some interesting new attacks to consider
These days, in almost all my discussions I get asked what I think about AI and the future of security, so I figured I should share it here
Short version: I try not to have a strong opinion yet. We are clearly in a transition phase, and outside of people working directly on foundation models, no one really has a solid view of where this is going
Over the past months, LLMs improved a lot. The releases at the end of 2025 were a real step change. In practice, most people I know (myself included) have barely written code in the past 2-3 months. For security, we went from "this is fun" to "this is actually useful"
Right now, the best mental model I have is that we effectively jumped from having no tooling to having an advanced static analyzer or fuzzer. A lot of bugs that used to take time to find can now be surfaced quickly
Does that mean security researchers disappear in 2 years? Based on today’s tech, I do not think so. There are a lot of bugs to be found. Some are found by humans, some by traditional techniques, and now some by LLMs. But it does not mean all bugs get found. If anything, history suggests there are always more bugs than anyone expects, and that gap does not go away easily
The real question is: do LLMs get another capability jump, or just steady iteration? There are reasonable arguments both ways. To be honest, I do not have enough understanding of how these models evolve to have a confident answer. And anyone giving a very definite answer is probably overconfident, unless they are working directly on the models
Depending on that, the role of security researchers could change a lot, including the way we work. The demand could decrease if models get very strong at finding bugs. But it could also increase if the amount of code grows faster than the models’ ability to reason about it. We could even end up with a shortage of experienced researchers in a few years if fewer juniors enter the field while seniors move elsewhere. It is hard to predict because everything depends on how model capabilities evolve
On the business side, I am skeptical about "AI audit as a service". If models keep improving, it is hard to see how these companies compete with native offerings from OpenAI or Anthropic. Especially if those providers stop exposing raw capabilities and push everyone into their own products. I tried codex security, and while it is not perfect, it is clear where this is going. Mythos / Capybara seem to be around the corner, and it will be interesting to see how far it goes
My current bet is that within a few months, tools like codex or claude security will be great at finding blockchain issues, and they will integrate directly into most dev pipelines. At that point, the marginal value of an extra "AI audit SaaS" becomes limited
So what to do as a security researcher? Be adaptive. This is a transition period, and things will likely move fast in 2026. Stay curious, and keep working on skills that give you an edge. Regularly reassess where you are strong or weak, and where AI helps you versus where it replaces you. If you like challenges, see AI as one that pushes you to improve
Also, be careful with what people call "cognitive debt" or "brain rot". I was skeptical at first, but I do see it now. The more I rely on LLMs during an audit, the more I lose part of the intuition that I normally build while going deep into code. That intuition is still critical to find complex bugs. I have not found the right balance yet, but it is something to watch
It probably makes sense to revisit your view on LLMs every 3-6 months. I have already been wrong a few times on this, and I am fine with that, as long as I don’t get locked into a fixed view
Finally, a lot of people focus on the downside for security researchers. But there are also upsides. I can explore codebases much faster, build custom tooling easily, and spend less time on boring tasks. Maybe it’s my last few years/months as a security researcher, maybe not. But at least LLMs let me have some fun before doomsday 😅
5
7
86
6,639
Imagine spending a year with multiple engineers, countless tokens, to build an AI auditing agent, and being outperformed by:
/goal Follow threat_model.md to find bugs. You can do it. I believe in you.
/goal Follow threat_model.md to find bugs. You can do it. I believe in you.
14
11
308
45,826
I would not be surprised to see the first Morris/WannaCry level worm driven by AI soon
The next few months are going to be interesting
The next few months are going to be interesting
7
0
28
1,855
Josselin Feist retweeted
DSS 2026 Call for Speakers deadline extended to August 15.
We’re giving researchers, auditors, protocol engineers, and security teams more time to submit talks, tools, and technical work for Mumbai.
Apply to speak: defisecuritysummit.org/apply-to-speak
DSS 2026 | Edition #5 | Mumbai, India
We’re giving researchers, auditors, protocol engineers, and security teams more time to submit talks, tools, and technical work for Mumbai.
Apply to speak: defisecuritysummit.org/apply-to-speak
DSS 2026 | Edition #5 | Mumbai, India
1
8
21
4,471