Approvals and transaction safety
What you are signing, and what SquirtFi refuses to do on your behalf.
An approval is not a deposit
Approving a token grants a specific contract permission to move up to a specific amount of that token from your wallet. It does not move anything. Nothing leaves your wallet until a second transaction actually spends it.
The spender is always shown before you sign. For a manual mint it is Uniswap’s position manager; for a zap it is SwapRouter02. SquirtFi is never a spender, because SquirtFi has no contract in the path.
Exact allowances by default
SquirtFi defaults to approving the exact amount the operation needs, and refuses to request an unlimited allowance automatically. If you want a larger allowance you have to set it yourself.
The one place an unlimited approval appears is protocol-internal: the router’s own allowance to Uniswap’s position manager, if that is ever insufficient. That is one contract approving another, and never your wallet approving an unbounded spender.
Deadlines and stale quotes
Every plan carries a deadline and the block it was quoted at. Before signing, the chain, the connected account, price freshness and the deadline are all re-checked. If anything has moved, the plan is rebuilt and re-previewed instead of being signed on old numbers.
Transaction states
| State | Meaning |
|---|---|
| Blocked | A pre-flight check failed. Nothing was sent. |
| Awaiting signature | The wallet has the request. Still nothing sent. |
| Pending | Broadcast, waiting for a receipt. |
| Confirmed | Receipt present and the expected events were found in it. |
| Rejected | You declined in the wallet. |
| Reverted | Mined, but the call failed. Gas was spent. |
| Cancelled | Replaced by a cancellation transaction from your wallet. |
| Failed | Something else went wrong; the message says what. |
Pre-flight refusals are specific rather than generic: wrong chain, changed account, stale quote, expired deadline, insufficient gas, insufficient balance, not the owner, not burnable, or a failed simulation.
No automatic retries
Once a transaction hash exists, SquirtFi will not resend it. If the outcome is uncertain, the honest response is to go and look at the hash, not to broadcast a second one that might also succeed.
The same rule covers replacements. A wallet-side cancellation cannot advance a multi-step sequence, even when the cancellation itself confirms successfully, and an error while reconciling Portfolio afterwards does not make an already-confirmed transaction retryable.