Stargate is a Cross-Chain Liquidity Transfer Protocol for Single-Asset Pools

Choose the pool by asset, chain, and exit route

The correct Stargate pool matches three facts: the exact asset contract, the connected network, and the chain where you expect to redeem.

Pool deposits use one asset rather than a two-token trading pair. Stargate implements 2 relevant pool forms: StargatePool for ERC-20 assets and StargatePoolNative for a chain's native coin. USDC, USDT, and ETH therefore appear as separate positions, even when the interface groups them under one pool screen.

Network identity settles the choice because pool contracts are chain-specific. Ethereum uses chain ID 1, BNB Chain uses 56, Avalanche C-Chain uses 43114, Polygon uses 137, Arbitrum One uses 42161, OP Mainnet uses 10, and Base uses 8453. These identifiers remain distinct even when several networks display USDC with the same ticker. Match the wallet network to the pool contract, and keep the pool version with your record because V1 and V2 LP contracts represent different positions. That chain-specific match determines where the later local redemption executes.

Position boundaries before the first signature

A Stargate position starts with sufficient underlying tokens, native gas, an exact pool address, and a plan to read source-chain credit again at exit.

On Ethereum, USDC and USDT each use 6 decimal places, so 1 token equals 1 000 000 base units. Native ETH uses 18 decimals, and 1 ETH equals 10^18 wei. The pool converts these local units through shared decimals. Keep a residual native balance outside the deposit because it funds approval, deposit, and redemption transactions.

Both wallet accounts and EVM contracts occupy 20-byte addresses, displayed as 42 characters: a 2-character 0x prefix plus 40 hexadecimal characters. Compare the complete underlying-token address and pool address on the connected chain. MetaMask and Rabby can show the same ticker for assets held by different contracts, while Stargate accepts only the asset configured for that pool.

Deposit approval and the pool transaction

A Stargate ERC-20 deposit requires an allowance and a deposit call; a native pool supplies the asset as transaction value.

The wallet-action sequence

The asset type determines whether the first deposit uses 2 state-changing calls or 1.

The ERC-20 pool path

With a zero allowance, the direct ERC-20 path produces 2 transactions: approve the pool's spending limit, then submit the deposit. An existing sufficient allowance removes the first call. Read the wallet prompt for the token, amount, chain, and spending contract before signing each state change.

The native-asset pool path

A StargatePoolNative deposit needs 1 pool transaction and no ERC-20 approval. Its value carries ETH, while the wallet retains separate ETH for network gas. Setting the deposit equal to the full balance prevents that gas payment.

The deposit receipt

The successful deposit receipt records the payer, LP receiver, and accepted local-unit amount. The pool then mints LP tokens to the receiver address, which can differ from the payer. Save the transaction hash because it connects the underlying outflow, deposit event, and LP mint in one record.

How does Stargate mint the LP position?

Stargate mints LP tokens equal to the accepted local-unit deposit after converting the entered amount through the pool's shared-decimal precision.

The Stargate V2 pool contract mints LP supply 1:1 with the accepted local-unit deposit. The LP token also uses the underlying asset's local decimals, giving a USDC-based LP token 6 decimals and a native ETH LP token 18 decimals. This accounting makes the minted quantity directly comparable with the accepted deposit.

Conversion can remove a residual amount that falls below shared-decimal precision. The contract reports the amount actually accepted, mints that same LP amount, and uses the same conversion during redemption. Compare the receipt amount rather than assuming every final base unit entered became LP balance.

Confirmation across the wallet and block explorer

A confirmed Stargate deposit should reconcile the underlying-token decrease, LP-token increase, pool event, and successful transaction receipt on one chain.

Four records describe the same state change from different angles. The wallet shows the underlying outflow and gas payment. The LP contract shows the minted balance. The pool emits a deposit event with payer, receiver, and amount. Finally, the transaction receipt proves that the chain included the call. If the interface refreshes slowly, these on-chain records establish the position without requiring another transaction or repeating the deposit.

The wallet record

MetaMask or Rabby may hide an unfamiliar LP token until its contract is added to the asset list. A hidden token still exists on-chain. Use the LP contract tied to the selected pool, then confirm that the connected account matches the receiver recorded by the deposit.

The explorer record

An EVM transaction hash contains 32 bytes and appears as 66 characters, including the 0x prefix. The receipt status is 1 for success and 0 for failure. Etherscan, Arbiscan, and BaseScan display these fields for their respective networks, alongside the pool event and LP-token transfer.

Reading the position while it remains deposited

A Stargate position has three relevant balances: wallet-held LP tokens, staked LP tokens, and the amount that local pool credit permits you to redeem.

The wallet-held balance is immediately available to the pool's local redemption call. A staked balance sits in Stargate's staking contract and must return to the wallet before that call. The redeemable figure is the smaller of the holder's LP balance and the pool's local credit, so it can sit below the total LP position without changing ownership. Record all three readings against the same network and LP contract. Mixing a Base wallet balance with an Arbitrum pool view creates an apparent mismatch even though both records remain internally correct.

The LP token is the position record, not the underlying asset itself. Its location therefore matters. A zero wallet balance can coexist with a positive staked balance, and the unstaking receipt restores the units needed for a local exit.

The worked deposit-to-exit example

This Stargate example follows one USDC position from an accepted deposit through a partial local redemption on the same network.

All changing inputs are hypothetical: the wallet begins with 1 250.000000 USDC and 0.010 ETH, an existing allowance covers the deposit, the pool accepts 1 000.000000 USDC, local credit exceeds 400.000000 USDC, rewards equal 0, and network gas is excluded from the token arithmetic.

After deposit, the wallet holds 250.000000 USDC and 1 000.000000 LP units. The user then redeems 400.000000 LP units locally. Stargate burns those 400.000000 units and returns 400.000000 USDC, leaving 600.000000 LP units and 650.000000 USDC in the wallet.

The concrete end state is a partially open position of 600.000000 LP units. The arithmetic stays on one chain, and the ETH balance changes only through network gas.

How do you make a clean local exit?

A clean local Stargate exit first recovers any staked LP tokens, then redeems the available LP balance into the source-chain asset.

An unstaked position needs 1 redemption transaction. A staked position needs 2 state changes: withdraw the required LP units from staking, then redeem them through the pool. The local redemption call burns the signer's LP tokens directly, so it does not need a new ERC-20 allowance.

Enter an amount no greater than the interface's local redeemable figure. The pool contract calculates that cap as the smaller of the address's LP balance and local path credit. A request above the available credit does not complete; reducing the amount to the displayed cap aligns the burn with source-chain liquidity.

After confirmation, verify three movements in the same receipt set: LP units decrease, the underlying asset increases, and native gas decreases. A completed local exit ends with the source-chain token back at the designated receiver address, which is covered in Stargate guide.

The position type that fits this workflow

The source-chain Stargate pool path fits a user who already holds a supported asset and wants a chain-specific, single-asset liquidity position.

The workflow is clearest when the same wallet, network, underlying contract, and LP contract remain linked from entry through exit. It also suits partial withdrawals because the contract burns only the selected LP amount and leaves the remaining units intact. Anyone planning to stake the LP token should add the staking balance to the record, since the wallet alone no longer shows the complete position. A complete position record contains the deposit hash, chain ID, pool contract, LP contract, and receiver address. Those fields preserve a direct trail from the first signature to the final source-chain asset.