Katana | Stake Your Liquidity Position — LP Rewards Guide
Stake an eligible Sushi liquidity position to participate in Katana incentive distribution while continuing to earn applicable trading fees.
Goal
Stake an eligible LP position so it can participate in Katana gauge-based incentives.
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
Confirm the LP position is on a supported pool.
Check whether the position is in range if it is concentrated liquidity.
Approve the staking contract for the LP/NFT position.
Stake the position and verify it appears in the staking interface.
Monitor both pool fees and incentive rewards.
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.