I stopped asking AI to find bugs. I've built an AI workflow that runs semi-automatically and consistently finds Critical issues.
I used this system alone in the @immunefi audit competition for @QuantusNetwork. It found a Critical issue nobody else did, and I finished 2nd out of 98 researchers.
Then, with two days left in the @Firelightfi Audit Competition, I ran it and found a paid High.
Same for the ENS Audit Comp. I launched it in the last two days and found me a Critical.
Honestly, I’m very proud of this AI workflow I've built. And I'm still improving it to work for Bug Bounties even more autonomously.
I already knew the system worked because it constantly finds issues in private client repos. But seeing it work in a public contest, with everyone looking at the same code, is different.
And yes, I genuinely need to start doing bug bounties.
I wrote an article explaining exactly how I did it, which models I used, what worked, and also what failed.
Btw, screenshot with proof below.
If all five signers on your 4 of 5 multisig work at the same company, it isn't much safer than a 2 of 5.
Yesterday I was looking at a map of the multisigs behind admin, upgrade, mint and pause at 15 big stablecoin and RWA issuers: from 2-of-32 to 4-of-5. I asked someone who maps these too if you can even tell who the signers are. Honest answer: not definitively.
If you issue a token other people hold, publish who holds each role, at least by role, and keep it matching onchain. "Two of five are outside the company" tells a holder more than the threshold.
@TheJaFung@chainlink@Anchorage same feed on both sides fixes the LTV mismatch, nice. the part I'd want to see is the liquidation path: when the DeFi side liquidates, how fast can the custodian actually release the asset? if that takes hours, price keeps moving and someone eats the gap
@Deepusleepy 'please don't sue me theo' is the most honest launch copy I've seen all year xD the 'only bring up what needs you' bit is the real product though, that filter is where these bots win or lose
@rsquare@safe policies are the part I'd love every team to turn on. the big multisig losses of the last couple years weren't a weak threshold, signers approved a tx they couldn't read. a rule like 'only these targets, no delegatecall' still holds when everyone clicks sign
@fbsloXBT 550 files that probably all look fine one by one, that's the scary part. for PRs like that I'd want a short list of what changed in behaviour before anyone reads a single diff, otherwise you review lines and miss the logic
@yeluacaM yeah that's the honest answer. matching the docs to on-chain is already more than most people do. even listing signers by role would help a lot, 'two of five are outside the company' tells you more than the threshold does
I keep running into agent payment projects lately, and they mostly get the payment flow right and the trust wrong.
The one that stuck with me was an x402 facilitator live on Celo. The operator, not the merchant, set where a vault's first payments go. You only see that in the vault code, not in the docs. The dev took the feedback really well and is fixing it.
A swap API for agents and an x402 test suite had the same kind of gap, and both fixed it within days.
@zaryab_eth fair, it's more a context problem than an AI problem. the catch is nobody knows which context is missing until someone asks the team 'what if this oracle lags?'. getting that written down is still mostly humans asking annoying questions xD
Three indicators that a feature carries design risk:
It changes a ratio between shares and underlying assets.
Its behaviour changes when called with flash-loaned capital.
It relies on an external price feed for a critical calculation.
Unchecked arithmetic and a missing modifier are NOT on that list. Those are code bugs. A linter finds them. This class needs a different read.
There is a four-line clamp in Uniswap V3 that only ever matters by a single wei.
getNextSqrtPriceFromOutput rounds the price far enough to guarantee AT LEAST the requested output. Recomputing from that price can come back a wei over.
Without the clamp, the pool pays out more than it was asked for. It exists because someone found the case where that wei was free money.
When I audit an upgrade, I compare storage layouts—not just functions.
A V2 contract can compile, deploy, and still corrupt live state because one variable moved slots. The safest review starts by proving that every existing slot keeps the same meaning.
Today I built a marketing system that does not create content or contact anyone.
It listens.
Eight alerts now watch for funded DeFi protocols, new testnets, audit grants, security partnerships, accelerators, Zealynx mentions and fresh incidents.
Forum alerts also catch people actively asking about audits.
Everything gets classified as a lead, partnership, mention, incident or noise.
The system never contacts anyone automatically. It only puts the right conversations in front of me while they are still fresh.
That feels like a much safer place to start than automating outreach.
@immunefi 18 criticals in contracts in one month is a lot. how many were in code that had already been audited? that's the number I'd really like to see
@charlesdhaussy I hope you're right man. contracts did get a lot better, but the big losses lately were keys and signing flows, Bybit was a tampered Safe UI. that's where I'd expect AI attacks first, and there the culture is still pretty weak
@nisedo_ facts! same with invariant fuzzing. write the invariants from the code and they'll pass forever. they have to come from what the protocol promises, otherwise you're just testing the code against itself
@HughKarp makes sense. the input I'd weight most is code that changed after the audit. 'audited: yes' says little if the contracts got upgraded since the report, and that part is easy to track onchain
@cryptoreine@CoinDesk agree, and it's not just optics. without the issuer, every dividend, split or vote has to be mirrored by whoever runs the wrapper. that's one more party holders have to trust to get it right