V3 Position Activity Checks for Integrators

For a V3 integration, a position is active only when its NFT exists, its liquidity is nonzero and the pool’s current tick falls inside its range. These checks answer different questions: whether a position is valid, whether it can provide liquidity, and whether that liquidity is currently available to swaps. Treating an NFT transfer or a liquidity event as proof of activity can leave an indexer, dashboard or reward flow with stale state.

Biswap documents its V3 liquidity positions as NFT LPs, with each token ID identifying a position. That differs from V2’s fungible pool tokens, where a balance represents a share of pooled liquidity. For the broader mechanics behind that distinction, the biswap comparison is useful context. An integrator still needs to query the relevant position manager and pool state directly; a token ID alone does not say whether liquidity is active.

What should an integrator check to identify a V3 position?

Check NFT existence and ownership at the position manager, then read the position’s liquidity and tick boundaries. The owner is the address currently entitled to control the NFT, subject to the contract’s approval rules. The position data identifies the token pair, fee tier, lower and upper ticks, and liquidity amount. A position with zero liquidity can still have an NFT and may have tokens owed, so NFT existence is not an activity test.

Use the position manager’s own state as the canonical record for position-level data. In common V3 periphery designs, a read such as positions(tokenId) returns the position fields, while the ERC-721 interface supplies ownership. The exact ABI and deployed manager address must come from the target chain’s deployment configuration. Biswap’s public material describes NFT LPs but does not, by itself, establish every contract address or ABI an integrator should use.

Do not infer ownership from the original mint recipient. The NFT can transfer after minting, and a marketplace, vault or staking contract may hold it. An application that attributes activity or rewards to a wallet must follow the NFT’s current owner or the protocol’s custody and staking records. Approval grants an operator permission to act; it does not transfer ownership.

How do you determine whether liquidity is active?

Compare the pool’s current tick with the position’s lower and upper ticks. Under the standard V3 range convention, liquidity is active when the current tick is at least the lower tick and below the upper tick. A position can have positive liquidity while the current tick is outside that interval. In that state the liquidity remains in the position, but it is not available to current swaps and does not accrue swap fees for that out-of-range interval.

This distinction matters for labels and downstream logic. “Open” can mean the NFT still exists. “Funded” can mean its liquidity is greater than zero. “In range” means the current pool tick lies in the position interval. “Earning” is a stronger claim: fees must have accrued to the position, and a view of current range alone cannot establish that. Fee growth and tokens owed may require position-manager or pool accounting to be updated by a transaction before the latest amount is reflected.

A pool’s current tick is dynamic. Swaps can move it across either boundary without changing the NFT or its stored liquidity. An indexer that computes activity from events should therefore also track pool tick changes, or refresh the relevant pool state when serving a current-status query. A snapshot taken at one block can become stale at the next swap.

Which events should an indexer follow?

Track position-manager events for position changes and ERC-721 transfers for custody changes, then reconcile them against contract state. In standard V3 position managers, IncreaseLiquidity and DecreaseLiquidity report changes to a position’s liquidity; Collect records amounts collected. Minting also creates the position NFT, while burning can remove it after the position is cleared. Pool-level mint and burn events describe changes to pool liquidity, but they do not replace position-manager events for identifying a specific NFT.

A practical indexer can process these records in order and maintain a position record containing owner, pool, tick boundaries, liquidity and last observed block. It should apply transfers independently from liquidity updates. When an event is missing, reordered in an upstream feed or rolled back during a chain reorganization, a state query at a finalized block can repair the record. For a live interface, label the block or freshness of the observation so users can distinguish current state from indexed history.

• Validate that the token ID exists before presenting position fields.
• Read current ownership rather than assuming the mint recipient remains the owner.
• Test nonzero liquidity separately from the in-range condition.
• Reconcile event-derived records against manager and pool state after reorganization or indexing gaps.

What can these checks confirm, and what remains uncertain?

The checks confirm whether a position NFT exists, who currently owns it, whether its liquidity is nonzero, and whether the current pool tick is inside its configured range. They do not prove that a position has earned a particular fee amount, that a reward program recognizes it, or that an application can safely act on it. Those outcomes depend on fee accounting, farm or vault rules, approvals and the deployed contracts’ actual interfaces.

For integrators, the sound default is to expose these states separately instead of compressing them into one “active” boolean. The available Biswap documentation supports the NFT-position model and concentrated ranges. It does not confirm a new activity-check contract, consensus rule or upgrade. Verify the target deployment’s manager ABI and any staking or reward contract before treating a generic V3 check as a Biswap-specific entitlement.