Can one wallet hold multiple V3 positions in the same pool?

Yes, one address can own multiple ERC-721 position tokens for the same V3 pool. Each token ID keeps its own lower tick, upper tick and liquidity amount, so the ranges and sizes can differ. The dashboard must be filtered to the correct owner and network to display every position.

Does adding tokens later change an existing position’s price range?

No, increasing liquidity on an existing token ID preserves that position’s pool, fee tier and tick bounds. The added amounts are calculated against the same range at the pool’s then-current price. To use different bounds, create a separate position and decide whether to reduce or close the older one.

Is an ERC-20 approval enough to create the position?

An ERC-20 approval isn’t enough to create a position because it only authorizes the designated spender; the position exists after the mint transaction confirms and the position manager issues an ERC-721 token ID, so a completed approval can remain even when no liquidity was minted.

Can accrued V3 fees be collected without decreasing liquidity?

Yes, accrued V3 fees can be collected while the position retains nonzero liquidity. Collection transfers the token0 and token1 amounts owed to the chosen recipient and updates the position’s accounting. It doesn’t change the fee tier or tick bounds, and the position continues participating whenever its range contains the current tick.

Who controls a V3 position after its NFT is transferred?

The current ERC-721 owner, or an account authorized by that owner, controls decrease, collect and burn actions for the V3 position. Transferring the NFT makes the recipient the new owner of the position record and its remaining liquidity. The original wallet no longer owns that token ID after the transfer confirms.

Must withdrawn assets return to the original wallet?

No, the V3 position manager’s collect call accepts a recipient address selected by the authorized caller. A consumer interface may default that recipient to the connected wallet, so the confirmation view is where to check it. Principal released by decreasing liquidity is first accounted as owed before collection sends the assets.

Sushi swap is a V3 position workflow from pool selection to withdrawal

Sushi swap is a concentrated-liquidity workflow that places two tokens into one V3 pool on one chain within a chosen price range. A funded wallet selects the pair, fee tier and bounds, creates the position, checks the resulting ERC-721 record and later decreases liquidity before collecting the two assets.

Selecting the network, pair and pool

A V3 pool selection is a three-part decision: choose one network, one two-token market and the existing pool whose fee tier fits the position.

Network choice comes first because a position and its tokens remain on that chain. Ethereum, Arbitrum, Base and Polygon keep separate pool contracts and balances, even when a pair carries familiar symbols. Select the token contract rather than relying on the ticker, then inspect which fee-tier pools exist for that exact pair. WETH/USDC on Ethereum is one concrete market; the same symbols on another network describe different contracts and a separate liquidity venue.

For a first position, established depth and visible trading activity make an existing pool easier to assess. The selected network, token addresses and fee tier must all match before range selection begins.

Existing pools and new-pool initialization

An existing V3 pool is a deployed market with an initialized price, while a new pool requires the first provider to set that starting price. Joining one lets the interface display its present tick before you choose two bounds. Creating a pool adds responsibility: the initial price must sit inside the range and the first deposit supplies opening liquidity. For a first Sushi swap position, use the existing route when the exact pair and fee tier are available.

Wallet and asset prerequisites

Wallet and asset prerequisites are four resources: a self-custody wallet, the selected pair’s tokens, one chain-native gas balance and access to Sushi on the chosen network.

MetaMask connects directly, while wallets using WalletConnect follow the same on-chain sequence. The connected account must hold the deposit assets on the chosen chain; balances elsewhere won’t fund the transaction. Ethereum, Arbitrum and Base use ETH for gas, separate from the two amounts committed to the pool. Keep enough ETH outside the deposit so approvals, position creation and eventual removal remain signable. Gas is market-priced, so the wallet’s estimate is the relevant amount at confirmation.

The pair’s contract addresses deserve a deliberate check because ERC-20 symbols aren’t unique identifiers. USDC and WETH each have an address that the position preview should display.

Token balance also has to match the proposed range. An in-range position normally calls for both assets, while a range wholly to one side of the current tick creates a single-sided deposit. Sushi calculates the required counterpart from the current pool price and chosen bounds, so the available wallet balance limits the position size.

Hardware-wallet users can connect through a compatible wallet interface and approve the same contract calls. The signing device should show the intended chain and account before any allowance or mint action proceeds.

Which price range should you choose?

A V3 price range is the interval between two tick-aligned bounds where Sushi V3 assigns the position active liquidity and accrues its share of swap fees.

Choose bounds that express the price interval you’re prepared to maintain, not a forecast presented as certainty. A current price inside the interval uses both tokens. A price below or above the interval shifts the position toward one token, with the exact side determined by the pair’s price orientation. The interface offers Full Range plus scaling controls marked ×÷2, ×÷1.2 and ×÷1.01, giving three quick ways to widen or tighten the displayed interval.

A narrower interval concentrates more liquidity near the current tick, while a wider one covers more movement with less concentration. Once the pool price leaves either bound, the position stops accruing new swap fees until the price re-enters. Its assets remain represented by the same position token throughout that state.

Fixed parameters behind the position

A Sushi V3 position is a contract record with fixed identity fields, while balances and the current tick change as swaps move through the selected pool.

Sushi V3 presents four standard pool fee tiers: 0.01%, 0.05%, 0.3% and 1%. The selected tier belongs to the pool itself, so changing it means selecting another pool and creating another position. The five parameters below are worth matching between the preview, wallet request and final record.

Parameter	Fixed value	Security tier
Pair definition	2 ERC-20 token addresses	Token-contract tier
Range definition	Lower tick and upper tick	Core-pool tier
Fee menu	0.01%, 0.05%, 0.3% or 1%	Factory registry tier
Position receipt	1 ERC-721 token ID	Ownership tier
Burn condition	0 liquidity and 0 tokens owed	Position-manager tier

Token amounts in the preview

A position preview is the final parameter sheet for the two desired token amounts, two range bounds, selected fee tier, recipient account and transaction limits.

Entering one token amount lets Sushi calculate the counterpart required at the pool’s present price and within the chosen range. The ratio isn’t fixed at 50/50 by token count or displayed units. It follows the V3 liquidity formula and moves as the current tick moves. Decimal formatting matters as well: WETH uses 18 decimal places, while native USDC uses 6. Review the human-readable amounts and token addresses together because a short decimal display can hide the contract’s exact base-unit value, as covered in Sushi swap walkthrough.

The preview also carries two minimum token amounts and a deadline into the position-manager call. Those fields protect the submitted terms if the pool moves before inclusion. Confirm that the wallet shows the expected network and position manager, then treat the preview as expired if material inputs have changed before signing.

Approvals and position creation

Position creation is an ERC-20 authorization sequence followed by a mint call that deposits the accepted token amounts and assigns the new position to the recipient account.

For two ERC-20 inputs with no usable allowances, the position manager needs one allowance decision for each token. That produces two authorization steps, although a wallet or interface may package the requests differently. An existing sufficient allowance removes the matching preliminary step. MetaMask displays the spender and allowance cap; compare both with the request you intended before confirming.

At contract level, the mint request contains 11 fields: two token addresses, one fee value, two ticks, two desired amounts, two minimum amounts, one recipient and one deadline. The interface assembles them from the pool and preview. The primary action is Add Liquidity, which submits the mint after the necessary authorizations exist.

Wait for the selected chain to confirm the mint before starting another position action. A submitted wallet request isn’t the finished position record.

How do you confirm the position was created?

A created V3 position is an on-chain ERC-721 record whose token ID, owner, pool identity, tick bounds and nonzero liquidity agree with the submitted preview.

The V3 position manager represents each minted position as one transferable ERC-721 token with a unique token ID. Sushi’s My Positions view should show that token under the connected account on the same chain. Its contract query returns 12 values, including token0, token1, fee, lower tick, upper tick, liquidity and two owed-token balances. On Ethereum, Etherscan can show the confirmed transaction and token ID; Arbiscan serves the same verification role on Arbitrum.

Match the owner address first, then compare both token contracts, the fee tier and the two bounds. A dashboard delay doesn’t change an already confirmed record, but the wallet and network filters must point to its actual owner and chain.

Reading the first position after minting

An active-position view is a status panel for current tick placement, liquidity, token composition and uncollected amounts tied to one position ID. “In range” means the current tick sits between the two selected bounds and the position participates in swaps. “Out of range” means new fee accrual pauses while the position remains open, increasingly represented by one asset. Owed token0 and token1 are accounting balances; they reach the wallet only through collection.

A clean partial or full withdrawal

A V3 withdrawal is a decrease-liquidity action followed by collection of the released principal and any token amounts already owed to the position.

Open the position on the correct chain, choose Decrease Liquidity and set the removal share. A partial reduction leaves liquidity under the same ERC-721 token and preserves its original fee tier and tick bounds. A full exit selects 100%, reducing active liquidity to 0. The contract first accounts the released token0 and token1 amounts to the position; collection transfers those balances to the chosen recipient. The interface may combine closely related calls into one wallet transaction, so review the final recipient and amounts rather than assuming a fixed transaction count.

After confirmation, compare the wallet’s two received assets with the position’s remaining liquidity and owed balances. Token quantities reflect the position’s final composition, not the original deposit ratio.

An empty position NFT can be burned only after its liquidity equals 0 and both owed-token balances are cleared to 0. Keeping the empty NFT alone neither restores liquidity nor collects anything. A clean exit therefore finishes with both assets in the wallet and no uncollected balance attached to the token ID.

Sushi swap: what people ask

Can one wallet hold multiple V3 positions in the same pool?: Yes, one address can own multiple ERC-721 position tokens for the same V3 pool. Each token ID keeps its own lower tick, upper tick and liquidity amount, so the ranges and sizes can differ. The dashboard must be filtered to the correct owner and network to display every position.
Does adding tokens later change an existing position’s price range?: No, increasing liquidity on an existing token ID preserves that position’s pool, fee tier and tick bounds. The added amounts are calculated against the same range at the pool’s then-current price. To use different bounds, create a separate position and decide whether to reduce or close the older one.
Is an ERC-20 approval enough to create the position?: An ERC-20 approval isn’t enough to create a position because it only authorizes the designated spender; the position exists after the mint transaction confirms and the position manager issues an ERC-721 token ID, so a completed approval can remain even when no liquidity was minted.
Can accrued V3 fees be collected without decreasing liquidity?: Yes, accrued V3 fees can be collected while the position retains nonzero liquidity. Collection transfers the token0 and token1 amounts owed to the chosen recipient and updates the position’s accounting. It doesn’t change the fee tier or tick bounds, and the position continues participating whenever its range contains the current tick.
Who controls a V3 position after its NFT is transferred?: The current ERC-721 owner, or an account authorized by that owner, controls decrease, collect and burn actions for the V3 position. Transferring the NFT makes the recipient the new owner of the position record and its remaining liquidity. The original wallet no longer owns that token ID after the transfer confirms.
Must withdrawn assets return to the original wallet?: No, the V3 position manager’s collect call accepts a recipient address selected by the authorized caller. A consumer interface may default that recipient to the connected wallet, so the confirmation view is where to check it. Principal released by decreasing liquidity is first accounted as owed before collection sends the assets.