Zenith assembles auditors with proven track records to secure your project. We find the critical bugs now—freeing you to launch this week—not next month.
As 2025 comes to a close, here's a look back at what our team accomplished this year at Zenith.
1.) Nearly half of our 243 audits found High's and Crit's. In total, we found 292 High and 96 Critical-severity vulnerabilities.
2.) Starting audits under 24 hours' notice. Clients raved about this. Thank you to every Zenith auditor who made this possible. Your dedication, expertise, and clear communication were the key.
3.) We worked with leading protocols including Bridge, Zama, and Jupiter. We spanned 21 ecosystems, including Ethereum, Monad, Base, Solana, Move, and Starknet.
2025 was Zenith’s inaugural year, and we’re excited for what’s ahead in 2026. A huge thanks goes to our clients, partners, and team for making this possible.
Interested in a Zenith audit in 2026? Link in bio!
We are very lucky to have an esteemed researcher like @marioponeder on the Zenith roster.
If you want an audit from the industry's top security researchers, handpicked for your specific codebase and security needs, we'd love to talk: https://t.co/gBBMLQ3EyA
The Tetris Effect: when you've done something so long, it starts leaking into your dreams.
For @marioponeder, that means dreaming about the codebases he’s auditing.
This is the story of how a former engineering physicist (and powerlifter) became a Zenith auditor.
The above steps are processed in separate transactions (not atomic) and step 2 requires the OFTs to be already transferred to the ASDRouter contract.
Furthermore, due to the permissionless nature of the execution step, the lzCompose(…) method does not enforce any constraints on the msg.sender; therefore, allows anyone to invoke it.
Attack path:
An adversary can monitor the ASDRouter contract for whitelisted incoming USDC-like OFTs and immediately use those on their own (redeem asD) by crafting & invoking a call to lzCompose(…) before an executor does. As a consequence, user funds are directly stolen.
Similarly, if lzCompose(…) fails for any reason, an adversary can re-try before the user to use the OFTs.
It‘s been a pleasure being one of the main reviewers for the meteora audits done by zenith. 17 so far and hopefully many more to go.
The team is honestly A+, extremely clean code and one of my favorite customers 💪
We want to give a huge shoutout to the @meteoraAG team for not only trusting in Zenith audit after audit, but for being so dedicated to ongoing security across their product suite.
If you want to check out any of the Meteora audit reports or any reports from Zenith, read the full reports below: https://t.co/Na0vmP1qFw
Meteora Zap Program (November 2025): Incorrect rounding on `get_price_change_bps` will lead to slippage not working
When calling the `zap_in_damm_v2` instruction, the user can provide the `max_sqrt_price_change_bps` value.
This value limits how much the price can move on the swap during the zap process.
This is then checked at the end of the instruction:
Meteora DBC (April 2025): Migration can be DoS as the curve completion check in `swap()` fails to account for locked vesting amount
When a `swap()` leads to a completed curve, it will perform a check to ensure that there are enough base tokens for the migration and fees as shown in the code below.
However, it fails to check that there are sufficient base tokens for the locked vesting, which will require transferring them to the locker.
An attacker can DoS the migration by performing a final swap for a significant amount of base tokens from the virtual pool. This will consume the base tokens that are meant for the locked vesting and then leave insufficient tokens for the migration. That prevents the migration, causing all the tokens to be stuck in the virtual pool.
And with every single audit, Zenith auditors provide the same level of attention and care in reviewing Meteora’s code, no matter the size or scope.
Here are two bugs that Zenith found in Meteora’s code over the past year.