Trader joe is a Decentralized Exchange Protocol for Liquidity Book Pool Strategies

Trader joe is a Liquidity Book pool workflow in which a provider selects one token pair and bin-step market, deposits assets across chosen price bins, confirms the resulting LBToken balances and later burns those balances to receive withdrawn assets. The essential sequence is select, shape, approve, supply and verify.

The short version: It is a Liquidity Book pool workflow for first-time providers to select a pair, add liquidity, verify bin positions, and withdraw liquidity.

From pool search to receipt in five actions

Five actions carry a Trader joe position from an empty wallet view to a recorded Liquidity Book balance without leaving the selected pool screen.

1. Connect the wallet. Select the intended network before entering token amounts.
2. Open the market. Search the pair, then choose its Liquidity Book market and displayed bin step.
3. Enter the assets. Set the two deposit amounts while retaining the network's native asset for gas.
4. Define the distribution. Choose Spot, Curve or Bid-Ask, then place the price bounds around the intended bins.
5. Approve and supply. Confirm any required token allowances, submit the deposit and wait for settlement.

After the final confirmation, compare the settled transaction with the position panel. The wallet address, chain, token pair, bin step and selected price bounds should match the submitted form. The graph should highlight funded bins, while the position panel should show balances for those bins. Record the transaction hash and LBPair address. Those two identifiers let the provider return to the exact market even when another pool uses the same token symbols. A coherent receipt closes the entry phase; missing data sends the user back to network and market selection.

Four prerequisites keep the transaction inputs coherent

Four prerequisites define a coherent Liquidity Book deposit: the correct EVM network, one compatible wallet, spendable pool tokens and native gas for confirmation.

Network and asset checks

Network selection

Use chain ID 43114 for Avalanche C-Chain and chain ID 42161 for Arbitrum One. MetaMask, Rabby and Core can present the same EVM address on both networks, so the address alone does not prove the selected chain. Keep AVAX for Avalanche confirmations or ETH for Arbitrum confirmations. A zero native-token balance leaves an otherwise complete deposit unable to reach LBRouter.

Token identity

Token identity starts at the contract address.

An EVM address contains 20 bytes, written as 40 hexadecimal digits and commonly displayed as 42 characters after the 0x prefix. Match each ERC-20 contract to the intended network before entering an amount; USDC on Avalanche C-Chain and USDC on Arbitrum One are separate deployments. The pool screen should name both token contracts, the Liquidity Book version and the bin step. Those three identifiers define the actual LBPair, while a familiar ticker alone cannot distinguish assets that share the same symbol. Record all three beside the transaction hash so later checks use the identical market and token contracts.

Fixed contract encodings behind the form

The interface turns four visible choices into fixed contract encodings that remain stable after the position settles.

The bin step belongs to the LBPair, so changing that value selects another market rather than modifying an existing position.

How should a first range and shape be chosen?

Three basic Liquidity Book shapes cover first-position choices, while a wide Spot distribution offers the clearest starting view of range behavior across moving bins.

Spot spreads the deposit uniformly across the chosen bins, so every bar begins with the same allocation. Curve concentrates more liquidity near the center. Bid-Ask weights the outer portions and expects movement through the selected prices. For a two-sided AVAX-USDC deposit, place the active bin inside the bounds so both assets enter the live range. The interface recalculates required token mix as the bounds move.

Bin step controls price spacing, while the chosen bounds control the number of bins. A 1-basis-point step changes the price by 0.01% between adjacent bins. Liquidity Book guidance describes a wide Spot range as about 20 to 50 bins; its concentrated form uses only 1 to 3 bins. The wider choice spreads the deposit across more price points and reduces how quickly one ordinary price move crosses the entire range. Confirm the previewed token mix after every adjustment because moving either bound changes the amounts that LBRouter can place.

Approval and supply create two distinct wallet records

Two wallet events commonly precede the first position: an ERC-20 allowance update and the LBRouter supply transaction that consumes the approved amount.

For a two-ERC-20 deposit with zero allowances, two approval transactions come before one supply transaction, so the wallet records three confirmations. A native AVAX input skips the ERC-20 approval for that side; WAVAX requires one because it is a token contract. Read each wallet request before signing. An approval names a token and spender, while the supply request calls LBRouter with token amounts, bin distribution, recipient and deadline data. The first changes spending permission. The second transfers assets into LBPair and mints LBToken balances to the recipient. Confirming only the approval leaves every asset in the wallet.

The active bin can change between range selection and block inclusion. Refresh the preview after a delay, then confirm that its bounds and token amounts still express the intended position. LBRouter applies the submitted safety parameters and rejects a deposit that falls outside them. A successful receipt therefore records one complete distribution across the accepted bin IDs.

Position verification uses balances, bins and the active marker

Three checks verify a Liquidity Book position after settlement: the transaction status, the deposited bin range and the wallet's LBToken balances per bin.

Reading the on-chain receipt

The transaction receipt should point to the same LBPair and wallet address selected before supply.

Liquidity Book represents bin IDs with 24 bits, creating exactly 16,777,216 possible identifiers from 0 through 16,777,215. Each populated bin gives the provider a separate fungible receipt balance inside the same LBPair. The LBToken design resembles ERC-1155 batch accounting, yet it omits NFT-oriented receiver callbacks and metadata. A position spread across several bins therefore appears as several token IDs rather than one indivisible NFT. The interface should map those IDs back to bars on the range chart and mark the active bin where swaps currently settle.

Verifying the asset claim in one bin requires three on-chain values: that bin's reserves, the wallet's LBToken balance and the LBToken total supply. Multiply the reserve by the wallet balance, then divide by total supply for the proportional token amount. Repeat the calculation for token X and token Y across every occupied ID. The displayed position should reconcile to those per-bin claims, subject only to normal integer rounding in token units.

What happens when the active bin leaves the range?

One move beyond the selected Liquidity Book range changes the position's status: no selected bin sits at the active price until price returns.

Below the active bin, a settled bin holds token Y; above it, a settled bin holds token X; only the active bin can hold both at once. As swaps move the active ID through the range, the position's asset composition changes bin by bin. Once the price moves beyond every selected bin, the graph marks the position outside the active range. The LBToken balances still represent the underlying pool share, and a later price return brings those bins back into the active path.

Two operational choices remain: keep the existing range or withdraw and deploy a new one around the active bin. Rebalancing is a two-stage operation because the first transaction burns the selected LBToken balances and the later transaction supplies a new distribution. Compare the assets returned by the exit with the amounts required by the new preview before confirming the replacement position.

A clean withdrawal burns the selected LBToken balances

Four removal paths support a clean Liquidity Book exit: receive both tokens, target token X, target token Y or withdraw selected bins.

A full exit selects 100% of every occupied bin, while a partial exit chooses a smaller share or specific price bins. LBRouter receives two parallel arrays: bin IDs and LBToken amounts. Their lengths must match one-to-one, and each amount tells LBPair how much receipt balance to burn at that ID. The pool then returns the corresponding token X and token Y reserves to the chosen recipient. Direct contract users must also match versions: the V2.2 router is not backward compatible with V2.1 LBPairs, and the V2.1 router is not backward compatible with V2.0 LBPairs.

After settlement, compare the transaction status with wallet balances and the position panel. A 100% exit should leave zero LBToken balance in every removed ID; a partial exit should preserve only the unburned balances.

Record the returned token amounts and transaction hash. That final check closes the Trader joe workflow with assets back under the wallet address that received them.

Questions and answers about Trader joe