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, Base, Arbitrum, Ink, Arc, HyperEVM and Unichain have no public mempool. They are sequencer chains: 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 and Ethereum have a public mempool, so sandwich risk is real there. Submissions go through private relays instead of the public mempool, and slippage is hard-capped at 15% regardless of your settings.
• Monad has a public mempool and no private relay yet. The 15% slippage cap applies there too; the relay follows when one exists.

Where the zap is deliberately not offered

The zap (the bot swaps part of your deposit into the other token, then mints) is the one open that can lose money on a bad pool before the mint ever runs, so it carries its own doors. The pool health warning is the first line of every zap screen, not the last. A zap is refused on a pool the bot measures as broken, and on a pool whose fee is above 10%, at the moment it knows the real route, before any transaction is sent.

Two venues refuse it outright, with the reason on screen: Uniswap V4 pools on BNB Chain (transfer tax scam tokens are common there, and a zap buys the token before the mint can find out it cannot settle, leaving you holding it), and Project X on HyperEVM, whose swap router speaks an older interface than the bot's zap leg. Both sides and one side only opens work on both.

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.