Stella liquidity in Pulsar supported swaps within each position's chosen price range

Pool Reserves and Active Trading Depth

Pulsar combined individual price ranges into pool liquidity, allowing swaps to use the positions that covered the traded price. Its automated market maker, or AMM, exchanged assets through smart contracts. Concentrating capital around trading prices could provide greater local depth than spreading that capital across the full price curve. That depth affected the price impact of trades passing through the range. Overlapping positions contributed together, and the active set changed as the pool price crossed their bounds. Total deposited value therefore described a different quantity from liquidity available at a particular price.

Standard V2 positions spread liquidity across the full pricing curve. StellaSwap also had stable-asset pools with a separate pool design. Full-range Pulsar positions offered broad price coverage within the concentrated-liquidity system. The narrower alternatives made capital available over a smaller interval, tying participation more closely to price movement. Pool design determined how those deposits entered trading and how the resulting position represented the supplied assets.

What Happened When a Pulsar Position Left Its Range?

An out-of-range Pulsar position stopped supplying liquidity at the prevailing pool price and earned no new swap fees. Trading through the entire interval converted its underlying liquidity into one of the pair's tokens. Which token remained depended on the boundary crossed and which token the quoted price measured. This described the assets backing the position; accumulated fees were a separate quantity. Range width and placement determined how much price movement would take the position outside its bounds.

Other positions could keep the pool trading while one provider's liquidity remained outside its selected bounds.

Returning inside the stored bounds made an unchanged position eligible to participate again while the exchange operated. Actual fee earnings still required trades that used its liquidity. Outside the interval, the position retained exposure to the token that it held, including that token's price changes. Its inactive status described participation in the AMM. It did not establish that the underlying balance had vanished or that the remaining asset would recover its previous value.

Fees and the Holding Comparison

Pulsar V3 used dynamic swap fees, so earnings reflected both trading conditions and a position's participation in the traded range. Its Algebra-based mechanism used volatility, volume and liquidity inputs. Pulsar V3 allocated position swap fees in proportion to the liquidity that each position supplied within the traded range. Choosing tighter bounds changed the concentration of a provider's capital. The pool's fee configuration governed the rate that applied to swaps.

Incentive Rewards

Liquidity incentives added a separate stream of reward tokens when a position met the applicable program's conditions. Earlier standard-pool farms paid STELLA rewards for staked LP tokens. Swap fees came from pool activity, while incentive allocations followed the reward arrangement. Those streams could have different eligibility rules and token denominations. A reward's token quantity also differed from its market value, which changed with the reward token's price.

Position Performance

Changing Token Composition

Impermanent loss measured the difference between the underlying liquidity's value and holding the originally supplied token quantities at the same ending prices. Price movement changed the position's asset mix through trading. Concentrating liquidity could increase this divergence when the relative token price moved substantially. A position could rise in currency value and still trail the holding comparison. Full-range provision spread exposure across a broader curve without removing this comparison.

View full-size image

Transaction Costs and Earned Tokens

Fees and incentive receipts contributed to total proceeds, while liquidity changes incurred Moonbeam transaction gas. Manual Pulsar transactions used GLMR for that gas cost. Comparing performance required a consistent valuation currency and period for the position, reward receipts and original holdings. Collected fees and still-pending fees were different amounts, so adding them required accounting for each once. A completed manual liquidity change incurred gas even if the replacement position later earned no swap fees.

Ticks and Position Ownership

Pulsar V3's legacy range grid used 60-tick spacing, restricting which lower and upper bounds a position could use. Ticks indexed proportional price changes along the pool's curve. A spacing of 60 ticks therefore did not mean a fixed distance in currency units. Broader positions could span many intervals on the grid.

Price Bounds

A position's lower and upper ticks identified its interval on that grid. Displayed bounds needed a consistent order for the pair's tokens to preserve their meaning. The pool's price relative to the bounds described trading participation. The quantity and value of deposited tokens described capital exposure. A narrow range label did not specify either a fixed deposit value or a fixed return.

Position Tokens

A manual Pulsar NFT represented an individual liquidity position with its own price bounds. Positions could retain different intervals even within the same pool. Standard-pool LP tokens instead represented shares of pooled liquidity. The NFT identified a particular position; its existence alone did not show whether its range covered the prevailing pool price.

View full-size image

Manual Ranges and Automated Vaults

StellaSwap's ICHI vaults accepted a single deposit asset and managed its allocation to concentrated liquidity through automated rebalancing. Single-asset entry described the deposit input; the managed position could contain both pool tokens. This differed from a manual position whose provider selected individual bounds. Automatic management changed who adjusted the allocation; it did not establish a fixed return from deposited capital.

View full-size image

V4 retained a concentrated-liquidity core and used an architecture that supported replaceable pool plugins. Plugin changes could occur within an existing pool without recreating it for each feature change. That flexibility concerned pool architecture. An ICHI vault's rebalancing concerned management of deposited capital. The mechanisms addressed different tasks, and a configurable pool did not automatically become a vault-managed position.

Manual range provision gave the provider direct control over the interval that the position covered. Vault participation delegated liquidity allocation to the strategy and represented the deposit with LP tokens. An intentionally out-of-range manual position could also support a limit-style token conversion once trading entered its band. That targeted conversion differed from a vault's ongoing allocation management, even though both used concentrated liquidity.