Ambient

Ambient dynamic fees change pool swap charges through authorized rate updates

Ambient dynamic fees change the liquidity charge a pool applies when its authorized policy updates the fee rate. That rate affects the token amounts exchanged at execution. Network gas remains a separate cost, so a swap budget needs both the quoted token amounts and the transaction cost.

Costs Triggered by the Selected Swap

A swap using wallet tokens may require approval gas alongside pool fees and execution gas. Existing authorization determines whether another approval transaction is necessary.

Pool Charges and Settlement

The pool charge enters the calculation of token amounts exchanged. Price impact also changes those amounts as trading moves along available liquidity, reflecting trade size relative to pool depth. Settlement can debit wallet tokens or an existing surplus balance held inside the exchange. Changing settlement changes transfer requirements; it does not by itself select a lower pool fee.

Authorization and Network Gas

An ERC-20 allowance authorizes the exchange contract to draw tokens up to the approved amount. If existing authorization covers the debit, another approval is unnecessary. A separate approval transaction consumes network gas when it executes. The swap itself also consumes gas, and its estimate depends on the contract path and network conditions. The same fee tier can therefore carry different transaction costs. For a directly submitted transaction, the wallet also needs the network's gas payment asset. Tokens recorded as surplus collateral do not automatically fund the network fee.

Route Fees and Available Liquidity

Direct and multihop routes can produce different net amounts because each pool has its own fee and liquidity. Extra hops introduce additional swap charges and execution work. They can still improve the overall quote when the direct pool has insufficient depth. Ambient avoids intermediate token transfers through net settlement. That reduces transfer overhead without eliminating each hop's pool fee. Route comparisons need the same input quantity or target output, with network costs accounted for separately.

Fixed-Input and Fixed-Output Budgets

Fixed-input and fixed-output swaps expose a fee increase on different sides of the budget: the quantity convention determines whether the variable amount is the tokens received or the tokens paid.

Fixed Input

A fixed-input swap specifies the input quantity and calculates the output after fees. A higher pool fee can reduce that output even when the requested quantity stays unchanged. A minimum-output limit expresses the lowest acceptable receipt. Pool price changes and differences in active liquidity also affect the quote, so a lower fee alone cannot establish a better output.

Fixed Output

A fixed-output swap targets the selected output quantity and calculates the input required. Higher fees can increase that debit when other conditions stay unchanged. Its maximum-input limit expresses the largest acceptable payment. Network gas remains outside this token limit. Available funds must cover the payment, with sufficient allowance for any ERC-20 tokens drawn from the wallet; a generous maximum-input setting does not supply either missing dependency.

Pool Rate Updates and Policy Inputs

A policy oracle can change a pool's stored fee through the administrative powers governance delegates. Governance can restrict a policy oracle to a defined set of protocol commands. A fee update changes a pool parameter without requiring a replacement liquidity position or an upgrade to the underlying exchange code.

The economic aim is to adjust charges as demand for liquidity changes. Lower charges can attract trades during calmer markets. Strong demand during volatile conditions can support higher charges. These relationships motivate a policy; they do not establish a fixed mapping from volatility to the fee every pool must charge.

One fee-selection model compares recent returns to in-range liquidity across fixed-fee Uniswap V3 pools for the same pair. It selects the fee tier with the strongest recent performance. Selecting a tier from past returns does not guarantee the income earned during subsequent trading. Deployment and pool configuration determine which policy actually adjusts the rate.

Pool-Specific Rates and Fee Units

An existing pool's own parameters establish its baseline swap fee rate. Pool identity includes the token addresses and pool type index, so a symbol or pair label alone does not identify the fee setting.

CrocQuery exposes queryPoolParams for the specified pair and index, with the stored coefficient in its feeRate_ field. The query reads state without submitting a swap. It returns the baseline parameter without reserving the rate for a later transaction.

A raw fee-rate unit represents 0.0001% of the applicable fee calculation basis. For a raw coefficient F, the fractional rate is F / 1,000,000. Each pool stores its own coefficient, which can change independently of this encoding.

The exchange calculates fees from estimated counter-token flow over each locally stable segment of the curve. Counter-token means the side opposite the specified swap quantity. Fees therefore need not equal the displayed input amount multiplied by the rate. Integer arithmetic and changes along the curve also affect exact amounts.

A rate read describes one state snapshot. Later execution can encounter a different rate, price or active liquidity.

Can a Fee Change Push a Swap Past Its Budget?

A fee increase can violate an output floor or an input ceiling, causing the swap to revert when the transaction enforces that bound. In a vanilla swap, minOut sets the bound on the non-fixed token side. Despite its name, that can mean maximum input for a fixed-output request. The contract checks final token flows, including fees, before settlement.

Price limits control a different part of execution: limitPrice bounds the pool's marginal price and can stop trading before the requested quantity finishes. A partial fill exchanges less than the requested quantity while its configured token bound still checks the final flows. A reverted, mined transaction reverses its swap changes but still consumes network gas. The token bound does not cap that separate expense.

Keeping a Cost Comparison Open Until Submission

For a swap using existing spending authorization, an unsigned request can remain editable while its quote and transaction costs are compared.

  • Keep the request unsigned while comparing fresh quotes for the same token pair and quantity. Include every pool charge along any multihop route.
  • Confirm the available funds cover the proposed debit and the existing allowance covers any ERC-20 tokens drawn from the wallet. An insufficient allowance introduces a separate authorization decision and possible transaction cost.
  • Compare the fee-inclusive quote with the chosen output floor or input ceiling, then account for gas separately. Revise an unaffordable request before signing.
  • Authorize submission only after the execution bounds and settlement destination match the request. A submitted transaction can execute; a pending identifier does not establish received tokens.
  • After successful execution, reconcile the paid and credited amounts with the selected wallet or surplus balance. Record actual network charges separately from the swap amounts.

A later trade has its own pool fee and network cost.

Settled Token Amounts and Network Charges

Settled token flows identify the actual debit and credit after pool charges. The settlement mode determines whether the credit appears in a wallet or surplus balance. An internal credit can therefore exist without an output-token transfer to the wallet. The net swap amount already includes the exchange charge. Adding that charge again overstates the spend. Actual network fees remain a separate entry, including gas consumed by a mined transaction that reverts.

Visual summary: Ambient dynamic fees: Settled Token Amounts and Network Charges
Settled Token Amounts and Network Charges, illustrated.

Open full-size image

Fee Income and Liquidity Exposure

Swap fees fund liquidity rewards, with any configured protocol share drawn from the same collected exchange fee. The pool's protocolTake_ parameter specifies the share of collected swap fees allocated to the protocol. That allocation is part of the overall feeRate_ charge. Its configured share can change, so gross swap charges and liquidity-provider income describe different amounts.

Active liquidity receives the liquidity-reward portion. Full-range ambient liquidity participates across prices, while concentrated principal participates inside its selected range. An increased pool rate cannot make out-of-range principal earn fees from trades it does not serve. Fees earned by concentrated liquidity reinvest as ambient liquidity, allowing those rewards to contribute to future trading.

Provider earnings depend on trading volume and the share of active liquidity as well as the rate. Changing token exposure can outweigh fee income relative to holding the same assets. Liquidity repositioning can also involve a swap and its applicable pool charge. Raising the tier alone establishes neither profitable liquidity provision nor cheaper trading.

Everyday questions about Ambient dynamic fees

Does the Swap Tip Parameter Cap the pool's Fee?

In a standard permissionless swap, the tip parameter raises the effective fee when it exceeds the pool rate. A lower nonzero tip does not force a cheaper rate or reject a higher pool fee. Setting tip to zero accepts the pool rate. Token-amount limits provide a separate constraint on the swap outcome.

Can a Permissioned Pool Apply a Discount to a Particular Swap?

A permissioned pool's permission oracle can authorize a swap and apply a fee discount for that call. This differs from a policy oracle changing the stored pool rate. The baseline parameter therefore may differ from the effective charge for an authorized transaction. The permission oracle can also reject a swap that fails its access conditions.

Will Changing a Pool Template Update Fees for Existing Pools?

A pool-template update changes the settings used for pools initialized from that template afterward. Existing pools retain their parameters until an authorized command updates them individually. A template's fee can therefore differ from the fee stored for an existing pair and pool index. The existing pool's parameters supply its baseline rate.

When Does Relayed Execution Add to an Ambient swap's Fee Budget?

Relayed execution adds a payment when the authorized relay request includes compensation for the relayer. That payment is separate from pool swap fees. The relayer submits the transaction and pays its network execution cost; any signed relay tip is debited from the user's surplus balance in the specified token. That balance must cover the tip when the call completes, or the transaction reverts. Available relay support depends on the integration.

Are Completed Swaps Repriced After a Fee Update?

A pool fee update affects later swap calculations without recalculating a completed swap's settled token flows. A pending transaction has not reached that boundary and may encounter changed parameters at execution. Past liquidity rewards reflect charges collected from earlier swaps; a subsequent rate change does not retroactively change those swap amounts.

Updated ·