N

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.