Uniswap V2, V3 and V4 on Robinhood Chain: A Liquidity Provider Guide

Uniswap V2 represents a liquidity provider's share of a pool with a fungible ERC-20 LP token. Each canonical pair is created by a factory, and ownership of LP tokens corresponds to a proportional claim on the pair's reserves. The model is simple to custody because an LP position moves with a standard token transfer.

Uniswap V3 introduced concentrated liquidity. A provider chooses a price range, so positions in the same pool can have different ranges, liquidity and accrued fees. Those unique positions are represented as NFTs. V4 keeps non-fungible position management while moving pools into a singleton PoolManager and adding hooks that can run custom logic around pool actions.

Uniswap's official V2 deployments page lists a Robinhood Chain factory and Router02. The official V4 deployment material lists the Robinhood Chain PoolManager and related periphery. Canonical deployment pages are the starting point for identity; copying an address from a social post or token interface is not sufficient.

Network scope must stay explicit. A mainnet deployment address can have no code on testnet, and an undocumented testnet contract can differ from the mainnet bytecode even when it exposes similar functions. ArchLiquid therefore separates mainnet compatibility research from testnet release support instead of treating a shared address as shared provenance.

A V2 locker can hold LP tokens with ordinary ERC-20 custody. The important security check is not whether the candidate responds like a token; a fake ERC-20 could imitate an LP asset. A canonical locker should read the pair's factory and tokens, then confirm that the configured factory returns that exact pair for those tokens before accepting the transfer.

Wallet discovery also needs discipline. An indexer can identify ERC-20 balances, but the application should reconcile each candidate against the canonical factory and the wallet's current balance. Historical transfer events or token metadata alone are not proof that the user currently holds an official LP position.

A V3 position locker receives an NFT and records the original owner, unlock time and position manager. Fee collection and principal withdrawal are separate operations. The locker must allow the owner to collect earned fees without creating a path to decrease liquidity before maturity.

Position discovery cannot depend on ERC-721 Enumerable because position managers are not required to implement it. A practical interface reads an indexed NFT ownership surface and verifies every token ID with the manager's current ownerOf result. This avoids showing burned, transferred or stale positions.

V4's NFT transfer operations resemble V3, but fee collection does not. The official PositionManager guide explains that there is no standalone collect command. Fees are collected through a zero-liquidity decrease action followed by a take action. A safe locker should compare liquidity before and after the call and revert if principal changed.

Hooks add another boundary. Hookless pools have the most predictable base behavior; hooked pools can execute custom code and should require an explicit approval policy. Transferring a V4 position also removes its existing subscriber, so a custody interface must disclose that state change. These differences are enough to make reusing a V3 locker unsafe even when both positions are NFTs.

ArchLiquid's Robinhood Chain testnet release supports deployed V2 LP-token, V3 position-NFT and V4 position-NFT lockers. V2 uses a pinned upstream Uniswap V2 factory and router fixture with canonical-pair validation. V4 pins one PositionManager, permits hookless pools by default and checks that fee collection preserves position liquidity.

The V2 and V4 transaction controls are enabled from a signed module manifest only after the exact deployed bytecode, immutable wiring, ownership and release signature pass independent live-chain checks. The V4 testnet addresses and runtime hashes are recorded explicitly because Uniswap's public deployment page does not currently list Robinhood testnet and the observed PositionManager bytecode differs from Robinhood mainnet.