Katana | Rebalance Staked LP — Sushi V3 Position Guide
Rebalance a staked Sushi V3 liquidity position by unstaking, removing liquidity, choosing a new range, minting and restaking.
Goal
Move a concentrated LP position back around the active market price after it goes out of range.
Before you begin
Confirm that your wallet is connected to Katana, that you have enough ETH for gas, and that token addresses or positions match the intended network. Review approvals before signing and avoid copying addresses from unverified sources.
Step-by-step workflow
Unstake the existing LP position if it is currently staked.
Remove liquidity and collect available fees.
Choose a new price range around the current market price.
Mint the replacement V3 position.
Restake the new position if it is eligible for incentives.
What changes onchain
The transaction updates a Katana smart-contract position rather than only changing the interface. Wallet prompts should therefore be checked for contract address, token amount, approvals and network before signing.
Risk and troubleshooting
Cross-chain, liquidity, smart-contract and configuration risks depend on the specific workflow. Always validate network, contract, token and expected output before signing.
- Wrong network or token address.
- Insufficient gas or token balance.
- Stale interface state after a transaction.
- Unexpected approval scope.
- Market, liquidity or exit conditions changing after entry.
Verification after completion
Check the transaction on Katana’s explorer, refresh balances from the chain and confirm that the expected position or token amount changed. For multi-step workflows, verify each transaction before continuing.
Frequently Asked Questions
What is the first safety check?
Verify the active Katana network and the exact contract or token address involved.
Should approvals be unlimited?
Use the smallest practical approval scope unless the application clearly requires a different pattern.
How do I verify completion?
Check the confirmed transaction and resulting onchain state, not only the interface message.
What if the UI disagrees with the explorer?
Treat onchain explorer/RPC state as authoritative and investigate caching or indexing lag in the interface.