Add Liquidity on Arc

Why both sides have to go in at the ratio the pool already holds

A constant-product pool holds two assets and prices them against each other with nothing but the ratio of the two reserves. If the pool holds 12,000 USDC and 400,000,000 tokens, the price is 0.00003 USDC per token, and that number is the pool. Depositing at a different ratio does not change the price you get — it changes what you receive.

Concretely: the pair mints LP in proportion to the reserves it already holds, so the leg you over-supply stays behind for everyone else. A pool holding 12,000 USDC and 400,000,000 tokens needs a 0.00003 USDC-per-token ratio. Turn up with twice as many tokens as that ratio implies and the surplus does not buy your token at your price — it is pooled, owned pro-rata by whoever already held LP, and arbitrage sells it out of the pool within seconds at a price you set by accident. That is why this form fills the second field for you from the live reserves, and why both fields stay editable rather than locked: you should be able to see and override exactly what you deposit.

The router enforces the same idea from the other direction. It takes the two amounts you asked for, recomputes the second one from the pool's reserves, and deposits whichever pair keeps the ratio intact — refunding the surplus back to your wallet in the same transaction. It also checks the adjusted leg against the minimum you set, so a pool that moves against you beyond your slippage tolerance reverts the call rather than depositing at a ratio you did not agree to.

One Arc-specific caveat: if the token charges a transfer tax, the manager measures what actually lands in its own balance and pools that, so the deposit is smaller than the number in the form rather than reverting. Check the token's tax settings — and make sure the pair is fee-exempt — before depositing into a taxed token's pool.

How liquidity providers actually earn on Arc

Every swap in a V2 pool pays a 0.30% fee, and the fee is not sent anywhere — it is left in the pool. A trader selling 1,000 USDC of tokens into the pool receives slightly less than the pure constant-product output because 0.30% of the input stays behind, growing both reserves. Since the LP tokens are a claim on those reserves, the fee belongs to liquidity providers in proportion to their share.

That gives an income estimate you can do in your head before depositing. If you hold 2% of a pool that turns over 1,000 USDC of volume a day, the fee pool generated that day is 3 USDC and your share of it is about 0.06 USDC — 0.30% of the volume, multiplied by your share. Two levers move that number: your share of the pool and the pool's volume. A large share of a quiet pool earns less than a small share of a busy one.

On Uniswap V2 there is no separate claim step. Fees accrue into the reserves, so they are already inside the amounts you see on this page, and you realise them by removing liquidity — partially, if you want to stay in the pool. On the same arithmetic, a position that has been in a pool through heavy volume is worth more per LP token than it was at deposit; a position in a pool that never traded is worth exactly what the price did to it, which is the subject of the next section.

Impermanent loss, honestly

Impermanent loss is the gap between providing liquidity and simply holding the two assets. It is not a fee, a bug or a scam — it is the mechanical consequence of a pool that is always willing to trade at the current ratio. As your token rises against USDC, arbitrageurs buy it out of the pool cheap and leave USDC behind; as it falls, they dump tokens into the pool and take USDC out. The pool always ends up holding more of whatever fell and less of whatever rose.

A worked example

Suppose you deposit 1,000 USDC and 2,000 tokens priced at 0.50 USDC each — the other 1,000 USDC of a 2,000 USDC position. The pool's invariant is 1,000 × 2,000 = 2,000,000. Now the token doubles to 1.00 USDC. The pool rebalances until the two reserves are equal in value again, which puts 1,414.21 tokens and 1,414.21 USDC in the pool: a position worth 2,828.43 USDC. Simply holding would have left you with 1,000 USDC plus 2,000 tokens worth 2,000 USDC — 3,000 USDC in total. The 171.57 USDC difference is impermanent loss: 5.72% of what holding would have paid.

Note what the pool did: it sold your best-performing asset the whole way up. You still profited in absolute terms — 2,828 USDC beats the 2,000 you deposited — but you underperformed the far simpler decision of doing nothing. The loss is symmetric in percentage terms for a move of the same size in the other direction, as the table shows.

Three things to take from the numbers. First, the loss is small for small moves — under 1% for a 25% move — and only becomes painful on the large, one-directional moves that happen around listings and news. Second, it is called impermanent because a round trip back to the original price erases it: the pool ends up holding the same quantities it started with. It becomes permanent the moment you withdraw at a different ratio. Third, the compensation is fees, and fees are a function of volume, not of how good the token is. A pool with no volume cannot pay for any divergence at all.

For a project depositing into its own pool the calculation has a second edge: the tokens you deposit are ones you created, so the USDC side is the only real capital at risk, and the depth you provide reduces price impact for buyers and realises your own supply into a market you control. Size the position against the fees you expect the pool to earn, not against how confident you feel about the token.

Slippage, minimums, and what a revert actually costs

Between the moment this page reads the reserves and the moment your transaction is included, someone can trade against the pool and change the ratio. The minimum amounts sent with the call are what cap that risk: they are derived from the reserves with the tolerance you selected, so a deposit that would settle more than your tolerance away from the quoted ratio simply fails.

Failing is cheap on Arc. Gas is charged in USDC at a 20 Gwei floor, so a few hundred thousand gas costs a fraction of a cent, and the flat service fee is only charged when the call succeeds. Repeated reverts are a signal that your tolerance is too tight for how busy the pool is, not that the tool is broken. Setting a tolerance so loose that it always succeeds is the worse mistake: it converts a cheap failure into an expensive fill.

A note on Arc finality: transactions settle in under a second and one confirmation is final, so the window in which the pool can move under you is measured in milliseconds rather than the minutes you would expect elsewhere. That is the main reason a 1% tolerance is generous here.