stanchev

securing web3
core @sherlockdefi

[SHERLOCK @sherlockdefi]

More teams are coming to Sherlock to test the full system their contracts depend on.

Signing flows, frontends, wallets, infra, access control, integrations: this is where clean code still turns into real risk.

Quick writeup below.

[SHERLOCK @sherlockdefi]

Sherlock 2026 so far:

187 high-stakes security engagements completed.

246 critical/high-severity and 781 medium-severity findings surfaced before they could become production risk.

Lending. Stablecoins. Prediction markets. Wallets. Bitcoin infra. L1s. L2s. Perps. ZK. Cross-chain systems. Agentic AI.

Bear market or not, the work does not slow down. We’re going to keep pushing the boundaries of Web3 security.

[SHERLOCK @sherlockdefi]

The @RujiraNetwork bug bounty is live on Sherlock!

If you're a researcher who thrives on complex DeFi primitives, this one's for you.

Orderbook DEX, money market, bRUNE, all running with native cross-chain assets.

Go hunt → https://t.co/rWwBsr86Eh

[SHERLOCK @sherlockdefi]

The next era of Web3 infrastructure deserves a brand new type of security review.

For @0xPolygon's Heimdall v2 upgrade, Sherlock is bringing that model to life.

June 15 to July 6.

[Jack Sanford 🛡️ @jack__sanford]

What makes Sherlock different from other auditors?

Incentive-driven, quantitative researcher selection.

Not only do we work with the top, exclusive researchers from contests, we select the best of the best for your specific codebase.

[SHERLOCK @sherlockdefi]

Sherlock AI keeps finding Highs and Crits. Here's a High from @SatsumaDEX that the team generously let us share.

The defense against this bug already existed in the codebase. It worked correctly and was applied to the claim function. It just wasn't on deposit or withdraw, the two functions where users actually enter and exit the system.

Protocol Context

Satsuma is a Bitcoin-first DEX built on Citrea (a Bitcoin Layer 2 with settlement on Bitcoin L1), powered by a v4 CLAMM via Algebra Integral and automated liquidity pools via Ichi. The protocol uses a token structure of SATS, xSATS (the staking wrapper), and a VoteModule where users deposit xSATS to earn rewards and participate in governance.

The VoteModule operates two independent reward streams: regular rebase rewards from protocol emissions and external revenue rewards from protocol revenue sharing. Both use standard reward-per-token accounting, where a global accumulator grows over time and each user has a checkpoint that records the accumulator's value when their state last changed. The difference between the two determines earned rewards.

The Vulnerability

The deposit function applies a reward update that correctly checkpoints the user's position for regular rebase rewards. But it does not checkpoint the user's position for external revenue rewards. The same omission exists on withdraw.

This means a depositor's external reward checkpoint is never set. It stays at zero. When they later claim rewards (which does apply both checkpoints), the earned calculation subtracts zero from the current accumulator and credits the depositor for the full reward history that occurred before they ever staked. The checkpoint logic exists, works, and is applied in the right place for claims. It's just missing on the two functions that change a user's staking balance.

Attack Steps

Alice (honest staker) deposits 1,000 xSATS into the VoteModule early.

The RevenueManager notifies 1,800 SATS of external revenue, starting a 30-minute distribution window. Alice is the sole staker, so the entire stream accrues to her.

25 minutes pass (~83% of the window). Alice's fair claim at this point is ~1,500 SATS.

Bob (attacker) deposits 1,000 xSATS. His external reward checkpoint stays at zero because deposit never updates it.

The remaining 5 minutes elapse. Rewards during this window split evenly between Alice and Bob.

Bob claims his rewards. The earned calculation sees the full accumulator minus zero, crediting Bob for the entire 30-minute period. He receives ~900 SATS, roughly 50% of total rewards, despite only being staked for the final 17%. His fair share would have been ~150 SATS (~8.3%).

Alice, who was staked the entire time, receives only ~900 SATS instead of the ~1,650 she earned. Bob took ~750 SATS from her in a single cycle.

The attack is repeatable. An attacker can watch for external revenue events, wait until most of the distribution window has elapsed, deposit, claim, withdraw, and repeat every cycle. Over time this drains the external reward pool almost entirely, transferring value from long-term honest stakers to the attacker.

Impact

Theft of external revenue rewards from all honest stakers. Any user can retroactively claim rewards for periods they were not staked, breaking the core accounting invariant of the external revenue stream. Repeated exploitation drains the reward pool and undermines trust in the staking system.

Fix

Add the external reward checkpoint to both deposit and withdraw so the user's position is set whenever their balance changes. The same way regular rewards are already handled.

Acknowledgements

Huge thanks to the @SatsumaDEX team for their transparency and to @KupiaSecurity for the POC.

You can see the original issue as generated by Sherlock AI in the next tweet.

AI auditing is giving teams a security brain that works alongside their developers from day one. Bugs that used to survive internal review and multiple audit rounds are getting caught during development, when they're cheapest to fix and before they ever get close to mainnet. Safer protocols, less spent getting there.

[SHERLOCK @sherlockdefi]

Major Announcement: The XRP Ledger roadmap is getting a $550K audit contest!

In collaboration with @RippleXDev, we’re putting upcoming XRPL features under a two-week, feature-unlock security review.

Contest starts Monday. Prepare yourselves!

[stanchev @stanchev_33]

@nmirchev8 Happy birthday bro! <3

[SHERLOCK @sherlockdefi]

This month, Sherlock crossed a major milestone: $20M in audit contest payouts to our security researcher community.

Huge thank you to the researchers, judges, and protocol teams who helped make this possible. More to come.

[SHERLOCK @sherlockdefi]

https://t.co/tha02ERCFV

[Aave @aave]

Aave V4's second security audit has been published by @sherlockdefi.

Review their findings below.

[stanchev @stanchev_33]

@Fav_Truffle @sherlockdefi Wish you all the health in the world to you and your family baba! 💕

[SHERLOCK @sherlockdefi]

Security is a top priority at @ZentraFinance. Before their formal audit phase ahead of launch, the team also ran Sherlock AI across the staking and rewards contracts to catch issues early. It surfaced a High-severity bug in the rewards accounting. Zentra gave us permission to share it publicly so other teams can learn from the pattern.

Here’s how the vulnerability worked.

Zentra is a decentralized, non-custodial, over-collateralized money market with staking mechanics. The issue lives in StakedZNTDistributor, where rewards are tracked using a global shareIndex and a per-user lastShareIndex so users only accrue rewards for periods when they actually hold shares.

The invariant is simple: only outstanding shares should earn rewards.

The failure point is cancelWithdrawal(). On requestWithdrawal(), the contract syncs accounting (updates lastShareIndex to the current shareIndex) and then burns the user’s receipt tokens, leaving them with zero shares during the pending window. Rewards can still be added during that window via addReward, increasing shareIndex.

If the user then calls cancelWithdrawal(), the contract remints the burned shares — but does not sync lastShareIndex at the moment of remint. The next time rewards are accounted (e.g., claimAllRewards(), stake(), or another requestWithdrawal()), _updateCredit computes (shareIndex - lastShareIndex) * remintedBalance, which incorrectly credits rewards for the entire pending-withdrawal interval when the user’s balance was actually zero.

In practice, it becomes a timing loop around reward events: stake → request withdrawal (burn) → wait for addReward → cancel withdrawal (remint, no sync) → claim. Repeating that cycle around meaningful reward additions siphons rewards from honest stakers.

The PoC demonstrates this by setting up an honest staker (Alice) and an attacker (Bob). Bob requests withdrawal, rewards are added during the pending period, Bob cancels, then claims and ends up receiving all the reward for a time that Bob didn’t hold any shares.

Impact is reward dilution and value leakage from the reward pool, because users can claim rewards for time they did not have shares outstanding, breaking the core reward-accounting invariant. Impact is not only limited by rewards dilution. The vulnerability allows the attacker to drain staking tokens too since staked token is also used as reward token. Therefore, insolvency is yet another impact of the vulnerability.

Fix direction is straightforward: treat cancelWithdrawal() as an accounting sync point. When shares are reminted, lastShareIndex must be brought current (or an equivalent sync performed) so the burn interval never gets included in later _updateCredit calculations.

Special thanks to @demorextess for helping triage the issue and assisting with the PoC.

Zentra caught and fixed this during development by running Sherlock AI early. That’s where AI auditing is most helpful: it finds edge cases before reward logic gets locked in, so the formal audit phase starts from a cleaner baseline and incentives go live on math that’s already been pressure tested.

Note: Sherlock completed a security audit of Zentra’s minimal deployment (launch) contracts at branch main, commit 4be344d6f47355063dcf758359ac5682d87a370e. This statement applies only to the contracts and versions referenced by that commit. Security reviews reduce risk, but do not eliminate it.

[SHERLOCK @sherlockdefi]

https://t.co/QT7TtEUYZX

[SHERLOCK @sherlockdefi]

The @flyingtulip_ contest is now live!

Guaranteed rewards of $100,000 and a @blackthornxyz invitation for the contest winner.

Auditors, your time is now.

[SHERLOCK @sherlockdefi]

Sherlock AI V2.1

We've shipped another upgrade to Sherlock AI, bringing our model even closer to how experienced human auditors think and work.

This release introduces a new scope-aware research architecture, deeper security methodologies, and improved prompt design that together deliver a major leap in vulnerability detection: now finding 72% of known issues in our benchmarks, up from 40-50% in previous versions.

What's New:

1. Scope-Aware Analysis
The system now clusters related code flows and state variables before analysis, giving the AI better context and improving detection across complex contracts.

2. Two-Phase Audit Architecture
Audits now run in two stages: exploratory analysis to surface potential issues naturally, followed by methodology-guided checks for systematic, comprehensive coverage. This reflects how real auditors reason, not just rule checks.

3. Deep Security Methodologies
We introduced a universal set of security focus areas covering access control, arithmetic correctness, reentrancy, DeFi economic invariants, cross-chain interactions, and more - each with clear principles, audit steps, and common bug patterns.

4. Better Cross-Contract Visibility
External contract calls are now surfaced and analyzed, enabling stronger detection of vulnerabilities that span multiple contracts.

Why It Matters For Our Users
Fewer false positives. Advanced coverage of interconnected contracts, without slowing down your development. More actionable findings with stronger fix suggestions.

[SHERLOCK @sherlockdefi]

Ready to help secure one of the most trusted protocols in DeFi?

The @aave V4 Contest starts Monday, December 1st, with rewards up to $300k.

V4 introduces a Hub and Spoke architecture, bringing new design paradigms to Aave, each with its own set of benefits.

Just audit Aave.

[CharlesWang @0xCharlesWang]

The best way to find all bugs in a codebase is to simply make notes for every little detail which seems to smell just not right.

Then once you got full understanding, revisit these notes and validate the details.

[BailSec @bailsecurity]

We are proud to announce our Security Partnership with @alto_money.

We look forward to supporting their growth with trusted, high-quality security expertise.

[CharlesWang @0xCharlesWang]

Creativity is one of the most important traits if you want to become a great auditor.

I did a small training session with two of our auditors on a very small, trivial scope.

It was clear from the beginning that the attack vectors are limited and the task was to find all issues in itself and incorporate creativity to find very hidden issues.

If you do something like that regularly, I believe you will level up quickly.