How transactions are built
Simulation, approvals, batching, and the refund call that is easy to forget.
Simulate, then sign
Every write is simulated against the live chain before your wallet is opened. If it fails, the revert reason is decoded and shown, and no request reaches the wallet at all.
Revert reasons are unwrapped rather than displayed raw. A short code like STF means a token transfer failed, usually a missing balance or approval; Price slippage check means the guard on minimum amounts refused. Both are more useful than the wrapper they arrive in.
Approvals
Each token that is not paid natively must be approved to the position manager. Otter reads the current allowance for both sides before enabling the mint, and shows a separate approval step for whichever side is short.
Approvals are for the exact amount plus a small buffer. Unlimited approval saves one transaction later and leaves a standing permission forever, which is a poor trade for a product used occasionally.
An earlier version treated "allowance not yet read" and "allowance is enough" as the same state, which let the mint button activate before anything was known. They are now separate states, and the mint stays disabled until both sides have actually been read.
Spreading across steps
Placing liquidity across several sub-ranges in one transaction uses the position manager's own batching function. No contract of ours is involved, which is what keeps the custody claim true.
The refund call
When one side is paid with native currency, the amount sent is fixed for the whole batch, and any unused portion stays in the position manager unless the batch ends with a refund call.
This is not only a concern for multi-step positions. Measured on chain: a single mint sending exactly the amount required still left a residue stranded permanently. With the refund call appended, the residue is zero across every amount tested. A single mint does not obviously need it, which is precisely why it is the sort of thing that ships broken.