Trader joe is a Decentralized Exchange Protocol with Liquidity Book Pools

Trader joe is the familiar search name for the LFJ Liquidity Book position workflow: connect an EVM wallet, select the correct network and LB pool, choose a bin range and distribution shape, approve each ERC-20 asset when required, supply liquidity, confirm the minted LBToken balances and withdraw by burning all or part of those balances. The workflow is self-custodial, and every state change settles through a wallet transaction. This handbook follows one position from preparation through execution, onchain verification, range monitoring and exit, with attention to protocol versions and bin identifiers that must remain consistent from deposit to removal.

The short version: It is a Liquidity Book DEX for LPs to connect a wallet, choose a pool and bins, add assets, verify the position, and withdraw liquidity.

LFJ branding changes the interface, not the position model

LFJ is the current interface brand for the decentralized exchange that many users still search for as Trader joe.

The Liquidity Book contracts still organize liquidity by pair, bin step and bin ID. An existing position remains tied to the protocol generation in which it was minted. LBRouter v2.2 is not backward compatible with v2.1 pairs, while the v2.1 router does not manage v2.0 pairs. The interface selects the matched route when it recognizes the position. Anyone reading the contract directly must preserve the pair address, version and network together because those three identifiers determine the router path.

Network and wallet preparation determines whether the deposit settles

A Liquidity Book deposit requires an EVM wallet, the selected network's native gas asset and the two pool assets.

Established Liquidity Book deployments include Avalanche C-Chain with chain ID 43114 and AVAX for gas, Arbitrum One with chain ID 42161 and ETH and BNB Smart Chain with chain ID 56 and BNB. MetaMask, Rabby and Core all expose these EVM network fields. The wallet must hold the deposited ERC-20 tokens on the same chain as the chosen LBPair; a USDC balance on Avalanche does not fund an Arbitrum position. Keep enough native gas asset outside the proposed deposit so approval, supply and later withdrawal calls remain signable.

Token precision is part of the preparation. Native USDC on Avalanche uses 6 decimal places, while WAVAX uses 18. The interface handles unit conversion, but the wallet preview should still show the intended human-readable amounts and recipient address.

Pool version, token pair and bin step define the market

A Liquidity Book market is fixed by its token pair, protocol generation and bin step, so matching all three prevents routing errors.

Liquidity Book may expose several markets for the same two token addresses because different bin steps create separate LBPairs. One basis point equals 1/10,000 of a price ratio, or 0.01%. A bin step of 20 therefore makes each adjacent bin price 1.002 times the preceding price, a 0.2% increment. Smaller steps create finer price spacing; larger steps cover more price distance per bin. Match the contract addresses, generation and bin step shown by the position before supplying assets.

A Liquidity Book bin ID is a 24-bit unsigned integer from 0 through 16,777,215, with 8,388,608 serving as the reference exponent. A delta ID of 0 denotes the active bin, so a selected range remains interpretable even if the absolute active ID moves before confirmation.

Range and shape selection determine where assets sit

A Liquidity Book range maps deposit amounts across discrete price bins, while its shape sets the allocation weight in each bin.

The active bin represents the live pool price and is the only bin that holds both token X and token Y. Bins above it hold only X; bins below it hold only Y. As swaps move the active point, the deposited composition changes without rewriting the chosen bin IDs.

Shape controls how much each bin receives

LFJ exposes three core distribution shapes: Spot, Curve and Bid-Ask. Spot distributes liquidity uniformly; Curve concentrates more weight near a chosen center; Bid-Ask places more weight toward range edges. Shape selection changes allocation, while the start and end bins determine coverage. A wide Spot range spreads the same deposit over more bins, reducing the amount assigned to each one.

Range placement controls asset composition

Range placement decides whether the deposit starts with two assets or only one.

Two-sided placement

A two-sided range crosses the active bin and supplies amounts of X and Y. The active bin accepts both assets, positive delta IDs receive X and negative delta IDs receive Y. That arrangement begins with marketable liquidity around the current price and remains active while the price stays inside the selected bins.

One-sided placement

A one-sided range sits entirely above or below the active bin and starts with one asset. If the active price enters and crosses those bins, swaps convert that deposited side into the paired asset. This placement suits a deliberate entry or exit target, and its outcome changes with the direction in which the active bin travels.

Approvals and supply create the position onchain

The LBRouter supply flow authorizes token movement, checks minimum inputs and mints balances for the bins that receive liquidity.

A standard two-token ERC-20 deposit has one supply call plus zero, one or two approval calls, determined by existing allowances. A native-token route uses the router's native variant. In either path, review the network, pair address, input amounts, range and recipient before signing each required approval and the final Supply transaction.

The router's LiquidityParameters payload carries 15 fields: two token addresses, the bin step, desired and minimum token amounts, expected active ID, allowed ID movement, relative bin IDs, two distribution arrays, recipient, refund recipient and deadline. Distribution values for each asset sum to 100% when all input is allocated, or less when the unused remainder should return to the refund address. Read the wallet's final asset movements, then sign the supply call once; the transaction either mints the requested bin balances or reverts as one atomic state change.

After confirmation, reopen the pool instead of repeating Supply. A second successful supply creates additional LBToken balances and changes the same wallet's position state.

The receipt and bin balances prove the position exists

An LFJ position is verifiable through the confirmed transaction, pair contract and LBToken balance attached to each occupied bin.

Begin with the 32-byte transaction hash, displayed as 64 hexadecimal characters after its 0x prefix. It should show a successful call to the intended LBRouter on the selected network and token movements into the LBPair. An EVM contract address is 20 bytes, or 40 hexadecimal characters after 0x, so compare full addresses when inspecting the pair. The add-liquidity call returns six outputs: X added, Y added, X left, Y left, deposit IDs and liquidity minted. Those values connect the wallet action to the bins now owned.

LBToken provides the durable receipt. Its multi-token design resembles ERC-1155, but it omits the receiver callback and URI function. Each bin ID maps to a fungible balance, letting the same address hold shares in several bins of one LBPair. The interface graph is useful, but the transaction receipt and nonzero LBToken balances establish the onchain position.

Verification ends when the chain, pair, bin IDs, deposited amounts, remainder amounts and recipient all agree with the signed intent.

Active-bin movement changes composition before withdrawal

Active-bin movement changes which asset each occupied bin contains, so position composition shifts before any withdrawal takes place.

Only the active bin accrues swap charges, and a prior active bin stops accruing once price advances elsewhere. Liquidity remains fixed in its chosen bins until the owner adds, removes or redeploys it. An out-of-range position therefore still exists, although it sits entirely in one asset and no longer intersects the live trading bin. Monitoring means comparing the current active ID with the lowest and highest occupied IDs.

Worked example: proportional removal

The following inputs are all hypothetical: a position holding 120 USDC and 0.40 AVAX across five occupied bins, with a 25% removal applied to every bin.

Burning one quarter of each selected LBToken balance returns 30 USDC and 0.10 AVAX before token-unit rounding: 120 × 0.25 equals 30, while 0.40 × 0.25 equals 0.10. The remaining onchain position retains 90 USDC and 0.30 AVAX across the same selected bins. If only some bin IDs are included, the asset mix follows those bins instead of the portfolio-wide ratio.

Removal choices produce a clean wallet-level exit

Liquidity Book withdrawal burns selected LBToken balances and sends the corresponding pool assets to the recipient address.

The LFJ interface documents four removal routes: receive both tokens, receive token X, receive token Y or remove balances from specific bins. A complete exit selects Remove all; a partial exit specifies a percentage or selected prices. At contract level, removal supplies absolute bin IDs and LBToken amounts of equal array length, so active-ID slippage is not part of the burn. The wallet then signs the matched router call for that pair generation.

After settlement, confirm that the selected LBToken balances decreased by the requested fraction and that the returned ERC-20 assets reached the recipient. A full exit leaves zero balances for every removed bin. A partial exit preserves the untouched bin balances, which remain exposed to later active-bin movement. If a broad position exceeds one transaction's practical gas capacity, withdraw it in batches and verify each receipt before continuing.

Helpful answers