Safety & failure handling
Concentrated liquidity fails in specific, well-understood ways: a price moves between quote and mint, a token blocks transfers, a range is placed somewhere the pool's tick grid can't actually represent. Most of what makes a DeFi tool trustworthy isn't that it never hits these · every LP tool does, eventually · it's what happens when it does. Here's exactly what Zenith does in each case.
A failed open costs you nothing
Before any transaction broadcasts, the bot runs a gas estimate against the exact calldata it's about to send. If the estimate says the transaction would fail, it is never broadcast. No gas spent, no funds moved, nothing to undo · the attempt simply doesn't happen, and you're told why.
Zap-ins are atomic
A one-sided deposit (you provide one token, the bot swaps part of it and opens the position) is a single transaction with multiple steps chained together. If any step in that chain fails, the entire transaction reverts · the contract-level guarantee is all-or-nothing. Your tokens never leave your wallet in a state where the swap happened but the mint didn't, because that state can't exist; either every step completed or the chain rolled all of them back.
When price moves faster than the mint
Concentrated liquidity mints are sensitive to price: a range that was valid when quoted can become invalid a block later if the price crossed a boundary. When that happens and it's provably safe to do · meaning nothing was broadcast yet, so there's nothing to double-spend or duplicate · the bot recomputes the mint at the fresh price and retries once, automatically. It does not retry blindly or repeatedly; one safe retry, and if that still doesn't land, you hear about it rather than watching it loop silently.
One-sided ranges never mint silently
Not every price range lines up cleanly with a pool's tick spacing, especially on wider-fee pools. If the tick grid can't place your range edge within 1% of the live price, the bot says so instead of minting a position whose actual range quietly differs from what you asked for · and offers you a finer-fee pool or an in-range zap instead.
MEV, handled per chain because the chains are different
- Robinhood chain has no public mempool. There's nothing for a bot to sandwich because there's no place for one to see your pending transaction before it lands. This isn't Zenith protecting you from something, it's a property of the chain itself.
- BSC has a public mempool, so sandwich risk is real there. Submissions go through private relays (PancakeSwap MEV Guard, with bloXroute as fallback) instead of the public mempool, and slippage is hard-capped at 15% regardless of your settings.
When a token itself is the problem
Occasionally a token's contract is written (or later modified) to block transfers · a rug mechanic that would normally trap a position forever, since neither side can be withdrawn if one side can't move. Rescue close handles this: the bot withdraws the healthy side of the position in full and forfeits the locked side, rather than leaving the whole position stuck. This isn't hypothetical · it was built from a real incident and verified against a real position that would otherwise still be locked today.
What none of this claims
Nothing here is "audited," "insured," or "guaranteed" · those words appear on this site only when a real document backs them, and none currently does. What's above is what the code actually does when things go wrong, described exactly, so you can decide if that's enough for the amount you're depositing.