Stella estimated token output before swap transactions completed

Quoted Output in the Selected Token

Quoted output measured the expected quantity of the destination token for the specified input, giving the estimate a direction and a unit. The legacy SDK exposed this estimate through quote.result.amountOut. Its response also contained the trade path and execution data. Those fields described a proposed swap; they did not record tokens arriving in a wallet.

Token Identity and Direction

Token contract identity matters when reading an old amount. Moonbeam had differently bridged versions of similarly named assets, with separate contract addresses. A shared ticker could therefore hide a different output token. The quote's destination token and the completed transfer must identify the same asset before their quantities can be compared.

Raw Amounts and Display Precision

Token decimals convert raw integer quantities into displayed token units: divide the raw amount by 10^d, where d is that token's decimal precision. Apply this conversion only to a raw amount. A response or screenshot that already shows formatted token units needs no second division. Preserve the full available precision for arithmetic.

Pool Versions Behind the Estimate

Pool versions changed the pricing logic behind a quote, and the legacy SDK's trade path identified its proposed route. The hybrid router supported Stable, V2 and V3 automated market makers, or AMMs. Each pool type priced the trade within its own rules, so the routing generation mattered when interpreting archived output.

Intermediate Route Amounts

Intermediate amounts belonged to the tokens leaving individual parts of the route. The final output token supplied the unit for an end-to-end quote comparison. Adding intermediate amounts to final output would mix units and could count assets that moved within the same swap. A calculation for one pool type also could not recreate a path using different pricing logic.

Pulsar V3 Pricing

Pulsar V3 used dynamic swap fees. Its concentrated liquidity distributed available assets across price ranges. Fee calculations considered volatility, liquidity and trading volume. Both the liquidity available around the trade's price and the applicable fee affected the estimate. These properties belonged to that pool generation; other legacy pool types used their own fee rules.

Price Impact Within the Estimate

Price impact described the price change caused by the trade itself, which an AMM's output calculation accounted for at the quoted trade size. A pool's marginal price described a very small exchange at its existing state. A larger trade moved through that pricing curve, so multiplying the starting price by the full input could overstate output. Available liquidity determined how sharply that difference grew.

View full-size image

Price slippage described a change between expected and executed pricing. An estimate could already reflect substantial price impact before execution began. Comparing received output with that estimate therefore answered a different question from comparing the estimate with the starting market price. Combining both comparisons without keeping their baselines separate would count different effects as though they measured the same change.

A smaller input could improve the quoted unit rate in a V2-style pool by moving less far along its reserve curve.

Why Could Received Output Differ From the Quote?

Received output could differ when pool state changed after quotation or token transfer rules affected the amount that reached the recipient. Other trades or liquidity changes could alter the state used during execution. Token-level deductions, where applicable, introduced another distinction between pool output and the recipient's net increase. Those mechanisms require different explanations even when they reduce the same displayed balance.

A slippage setting expressed an execution tolerance. Where a router enforced a minimum-output amount, the transaction had to meet that router's check. The relevant bound came from the actual call and its implementation. A displayed quote alone did not reveal every encoded condition, and a percentage setting alone did not establish an exact token minimum. Rounding and the chosen calculation convention mattered when reconstructing that amount.

Swap Charges and Gas in Separate Units

Swap charges affected trade economics through the selected pool or route, while ordinary Moonbeam transaction gas used GLMR as its payment asset. Keeping those units separate prevents a token-output comparison from becoming an incorrect calculation of total spending.

The earlier xSTELLA-era fee model charged 0.25% of the traded amount per swap. That historical figure should not replace the applicable fee for a Pulsar V3 route with dynamic pricing. Fee distributions also formed part of the protocol's tokenomics; they described where revenue went, while output described the trader's exchange.

A fee that the output calculation already included should not be deducted again from the quoted amount.

Gas was a separate charge for executing the transaction. An included transaction that failed could still consume gas without completing the swap. When the output asset differed from GLMR, subtracting a GLMR gas amount directly from output-token units would mix assets. A monetary comparison required prices for both assets at an appropriate time.

Transfers Within a Completed Swap

Recipient Transfers

Recipient transfers identified the destination token delivered by a completed swap, while intermediate movements described activity inside its route. Routing could produce several transfers within one transaction. Summing every transfer could count the same economic movement repeatedly. A recipient's total balance also included earlier holdings, so that total was not automatically the amount received from the swap.

View full-size image

Transaction Status

A transaction hash identified a transaction; its receipt established execution status. Pending transactions had no execution receipt yet. For an included transaction, a successful receipt and the relevant transfer records supported the received-output reading. A failed receipt could not establish a completed exchange merely because a wallet had previously shown an estimated amount. Native-asset movements required their corresponding transaction records, rather than an assumption that every output appeared as an ERC-20 transfer.

What Did an Old Quote Establish After Closure?

An old quote preserved an earlier output estimate after closure, with its usefulness limited to the historical trade and conditions that it described. StellaSwap ended operations on 31 July 2026. Saved screens and quote responses do not establish current trading availability. Their amounts can still explain what the interface predicted before a historical transaction.

View full-size image

Completed blockchain transactions retain their own execution records. An archived estimate and a transaction receipt therefore answer separate historical questions. The estimate describes the proposed exchange at quotation; the receipt and transfers describe what happened during execution.

Historical Rates and Portfolio Values

Historical token output described an exchange quantity, while a portfolio value required a separate price in the chosen valuation currency. Dividing quoted output by input gives an average quoted rate in output tokens per input token. Dividing received output by the same input gives the corresponding realized rate. Both ratios need matching token identities and correctly formatted units.

These rates alone do not establish a profit or a present liquidation value. Profit calculations also require acquisition costs and relevant charges. A present valuation needs present prices and available liquidity. Using a small historical quote to value a larger holding would assume unchanged prices and enough liquidity for the larger sale.