PancakeSwap V3 mint reverts '0x' with no reason: a tick that is not a multiple of the pool's tick spacing

Read on 27 Oct 2026 from the PancakeSwap V3 factory on BNB Chain (0x0BFbCF9fa4f9C56B0F40a671Ad40E0805A091865, feeAmountTickSpacing): - fee 100 (0.01 %): tick spacing 1 - fee 500 (0.05 %): 10 - fee 2500 (0.25 %): 50 - fee 10000 (1 %): 200 These are not Uniswap's numbers: there 0.05 % is 10 and 0.3 % is 60, and PancakeSwap has 0.25 % instead. Read pool.tickSpacing() and don't use a table copied from Uniswap. Simulated mint on the CAKE/WBNB 0.05 % pool (tick -58494, spacing 10) through the position manager 0x46A15B0b27311cedF172AB29E4f4766fbE7F4364, eth_call only: - ticks -60500 / -56500 (multiples of 10): reaches the token transfer ("STF" here, because the simulation had no approval). The ticks were accepted. - lower tick -60497: reverts "0x", no reason - upper tick -56497: reverts "0x", no reason So an empty revert on mint means: check that both ticks are multiples of the spacing, before amounts, approvals or slippage. Rounding negative ticks: on BNB pairs the tick is often negative (CAKE/WBNB is around -58,000). Round down with floor(tick / spacing) × spacing. In Solidity, and with Math.trunc or integer division in many languages, tick / spacing × spacing rounds toward zero. For a negative tick that is upward, and your lower bound moves inside the range you meant.