KyberSwap Docs
  • Introduction to KyberSwap
  • Getting Started
    • Quickstart
      • FAQ
    • Supported Exchanges And Networks
    • Foundational Topics
      • Decentralized Finance
        • Tokens
        • Stablecoins
        • DEX/DeFi Aggregator
        • Slippage
        • Price Impact
        • Zap
        • Maximal Extractable Value (MEV)
      • Decentralized Technologies
        • Wallets
        • Dapps
        • RPC
        • Oracles
        • On-Chain vs Off-Chain Data
      • Other Valuable Resources
  • KyberSwap Solutions
    • KyberSwap Interface
      • User Guides
        • Connect Your Wallet
        • Switching Networks
        • Instantly Swap At Superior Rates
        • Swap At Your Preferred Rates
        • Cross-chain Swap
        • Add Your Favourite Tokens
        • Get Crypto With Fiat
        • Bridge Your Assets Across Multiple Chains
      • Profiles
        • Profile Creation
        • Profile Customization
        • Sync Profile Across Devices
      • Notifications
        • Notification Center
    • KyberSwap Aggregator
      • Concepts
        • Dynamic Trade Routing
      • User Guides
        • Instantly Swap At Superior Rates
      • Developer Guides
        • Execute A Swap With The Aggregator API
        • Upgrading To APIv1
      • Aggregator API Specification
        • EVM Swaps
        • Permit
      • Contracts
        • Aggregator Contract Addresses
      • DEX IDs
      • Subgraphs
      • FAQ
    • KyberSwap Zap as a Service
      • KyberSwap Zap as a Service (ZaaS) API
        • ZaaS HTTP API
        • ZaaS GRPC API
      • KyberSwap Zap Liquidity Widget
      • Zap Fee Model
      • Zap's Supported Chains/Dexes
      • Zap's Deployed Contract Addresses
      • Zap's DEX IDs
    • KyberSwap Widget
      • Developer Guides
        • Integrating The KyberSwap Widget
        • Customizing The KyberSwap Widget
      • iFrame Alternative
      • Widget/iFrame Fee
    • KyberSwap Liquidity Widget
      • Integrating The KyberSwap Liquidity Widget
    • Limit Order
      • Concepts
        • Off-Chain Relay, On-Chain Settlement
        • Gasless Cancellation
      • User Guides
        • Swap At Your Preferred Rates
        • Update Limit Orders
        • Cancel Limit Orders
      • Developer Guides
        • Create Limit Order
        • Gasless Cancel
        • Hard Cancel
        • Fill Limit Order
      • Contracts
        • Limit Order Contract Addresses
      • Limit Order API Specification
        • General APIs
        • Maker APIs
        • Taker APIs
      • FAQ
    • KyberSwap OnChain Price Service
    • Fee Schedule
  • Governance
    • KyberDAO
      • User Guides
        • Participating in KyberDAO
        • Staking
        • Voting
        • Stake KNC And Enjoy Gas Savings
      • Fees to KyberDAO
      • KyberDAO Operator MultiSig
      • Contracts
        • KyberDAO Contract Repo
        • KyberDAO Contract Addresses
      • FAQ - Others
    • KNC Token
      • KNC Tokenomics & Utility
      • Gas Refund Program
      • KNC Contract Addresses
  • Security
    • Audits
  • Reference
    • Legacy
      • KyberSwap Classic
        • Concepts
          • Programmable Pricing Curves
          • Dynamic Auto-Adjusting Fees
          • Virtual Balances
          • Protocol Fees
        • Contracts
          • Classic Contract Repo
          • Classic Contract Addresses
          • Classic Contract Farming Addresses
      • KyberSwap Elastic
        • Concepts
          • Concentrated Liquidity
          • Reinvestment Curve
          • Tick-Range Mechanism
          • Pool Process Flows
          • Anti-Sniping Mechanism
          • Tick-Based Farming
          • Elastic Zap
          • TWAP Oracle
          • Elastic APR Calculations
        • Contracts
          • Elastic Contract Repo
          • Elastic Contract Addresses
          • Elastic Farming Contract Addresses
          • Elastic Zap Contract Addresses
          • Elastic Core Contracts
          • Elastic Core Libraries
          • Elastic Periphery Core Contracts
          • Elastic Peripheral Library Contracts
          • Elastic Peripheral Base Contracts
        • Subgraphs
      • Whitepapers
      • Audits
      • KyberAI
        • KyberScore
        • Concepts
        • On-Chain Indicators
          • Number Of Trades
          • Trading Volume
          • Netflow To Whale Wallets
          • Netflow To CEX
          • Number Of Transfers
          • Volume Of Transfers
          • Number Of Holders
          • Top Holders
        • Technical Indicators
          • Live Charts
          • Support & Resistance Levels
          • Live Trades
          • Funding Rate On CEX
          • Liquidations On CEX
        • Liquidity Analysis
      • Elastic Legacy
        • Elastic Legacy Contract Repo
        • Elastic Legacy Contract Addresses
        • Elastic Legacy Farming Contract Addresses
        • Remove Elastic Legacy Liquidity
      • Protocol
        • Overview
        • Smart Contract Architecture
        • Trust and Security Model
      • Integrations
        • Getting Started
        • Use Cases
        • Integration Types
        • Smart Contracts
        • Ethers JS
        • RESTful API
        • Slippage Rate Protection
        • Price Feed Security
        • Contract Events
        • Platform Fees
      • Reserves
        • Getting Started
          • Overview
          • Why Develop On Kyber
          • Create New Reserve
          • Existing Reserves
          • Customising Existing Reserves
        • Development Guides
          • Fed Price Reserve
          • Automated Price Reserve
          • Reserves with Ganache
          • Orderbook Reserve
        • Operations
          • Listing Policies
          • Reserve IDs
          • Reserve Rebates
          • Sanity Rates
      • Addresses
        • Introduction
        • Mainnet
        • Kovan
        • Rinkeby
        • Ropsten
      • API/ABI
        • Introduction
        • RESTful API
          • RESTful API Overview
          • RESTful API
        • Core Smart Contracts
          • IKyberNetworkProxy
          • KyberNetworkProxy
          • IKyberNetwork
          • ISimpleKyberProxy
          • IKyberMatchingEngine
          • KyberMatchingEngine
          • IKyberHint
          • KyberHintHandler
          • IKyberHintHandler
          • IKyberFeeHandler
          • IKyberStaking
          • KyberStaking
          • IKyberDao
          • KyberDao
          • IKyberStorage
          • KyberStorage
          • IKyberHistory
          • KyberHistory
          • IKyberReserve
          • KyberReserve
          • ConversionRates
          • LiquidityConversionRates
          • EpochUtils
          • IEpochUtils
          • KyberFeeHandler
        • Contract ABIs
          • ABIs
        • Code Snippets
          • Token Quantity Conversion
        • Misc Contracts
          • KyberNetwork
          • ConversionRatesInterface
          • PermissionGroups
          • SanityRates
          • Withdrawable
          • OrderbookReserveInterface
          • OrderbookReserveLister
    • KyberSwap Operator MultiSig
    • Permitable Tokens
    • Third-Party Integrations
    • KyberSwap Analytics
    • KyberSwap App
    • GitHub
    • KyberSwap Analytics
    • KyberSwap Blog
    • Kyber Network Press Kit
  • Socials
    • X
    • Discord
    • Telegram
    • LinkedIn
    • Reddit
    • Instagram
    • Tik Tok
  • Support
    • KyberSwap Help Center
    • Complaints Handling Process
Powered by GitBook
On this page
  • Overview
  • DEX slippage
  • AMM slippage
  • Order book slippage
  • Positive vs negative slippage
  • Slippage examples
  • Protecting our users

Was this helpful?

  1. Getting Started
  2. Foundational Topics
  3. Decentralized Finance

Slippage

Securing Your Trades Against Market Fluctuations

PreviousDEX/DeFi AggregatorNextPrice Impact

Last updated 10 months ago

Was this helpful?

Overview

Slippage refers to the difference between the expected and final price of a trade. As there is always a certain amount of time between order placement and order execution, there is a possibility that market conditions might have changed during this short interval. Consequently, time to execution is a significant factor when considering slippage risks. By extension, slippage risks are also higher during periods of relative market volatility whereby asset prices tend to change more rapidly.

It is important to note that slippage is an inherent characteristic of any active market. As such, it is important to be aware of how it can affect your trades and what are the steps you can take to mitigate its effects. Of note, slippage is not always negative as it could also result in more favorable trades which we will cover in more detail below.

Slippage vs price impact

Although closely related, slippage and price impact are separate concepts. Slippage occurs due to market factors external to the trader while price impact occurs due to the size of a trade relative to the available liquidity.

Please refer to the page for more details.

DEX slippage

Specific to DeFi, the majority of trades take place via DEXs hence slippage presents itself differently depending on the order matching mechanism.

Note that for public blockchains, transactions are always batched into their respective blocks to be appended to the chain. This means that the slippage window increases according to how your transaction is prioritized by the network. Moreover, even within the same block, it is possible that trades for the same token pair are ordered before yours. As such, DEXs have implemented various safety mechanisms in an effort to minimize any unexpected trading outcomes.

AMM slippage

For AMM DEXs, trades occur along a smooth price curve hence every trade against the pool will shift the market price according to the resulting token ratio changes in the pool. In the event that another transaction against the target pool is prioritized over yours, the actual price of the pool would have changed between the confirmation of your order and the final execution.

Due to how orders are prioritized on the blockchain (see above), it is not possible to guarantee the price at the point of order submission. As such, rather than failing the order which would result in an endless cascade of failed orders, most AMMs have implemented a slippage tolerance parameter for trades against their pools. By setting the slippage as a percentage of the expected price, transactions can still be executed as long as the final price is within the boundaries set. This makes transaction processing much more efficient at the application layer while also enabling traders to protect their trades.

While it is always recommended to keep the slippage setting as low as possible to ensure trades are executed at the best rates, such transactions might face a higher failure rate in times of extreme market volatility. Setting a higher slippage increases the likelihood of transaction success but comes with greater risks of worse rates due to market volatility as well as the presence of front-running opportunities.

Slippage tolerance for liquidity provision

Note that slippage also applies whenever liquidity is added or removed from an AMM pool due to the way transactions are ordered into blocks. Whenever a position is added to a liquidity pool, the protocol will try to match the token ratio required for liquidity additions to the current ratio of the pool. This also applies in the other direction whenever a position is removed from the pool.

Order book slippage

For order book DEXs, trades are executed when a pending order is filled by a counterparty with a matching order. In the case of limit orders where trades are only executed if the market price matches the expected price, hence slippage only happens in the direction favouring the trader. As such, limit orders are a great way to ensure that there are no negative trade outcomes based on the predefined parameters of the trade.

As limit orders can be valid for an indefinite amount of time, order book DEXs have also implemented an expiry and cancellation mechanism for limit orders. This acts as a safety mechanism so that traders are able to act according to the changing market conditions and not be caught with unfavorable orders which they had committed to under different market conditions.

Positive vs negative slippage

Slippage examples

Scenario

Assumptions

  • The current pool price is 2,000 (i.e. 1ETH = 2,000USDT) which is in line with the wider market price for ETH

  • USDT maintains it's peg with the US dollar

  • Alice confirms the 1ETH swap with an estimated output 2,000USDT

  • Based on the above, the minimum received for the transaction is 1,980USDT. Below this threshold, the transaction is reverted (i.e. cancelled).

Negative slippage

Between confirming the swap and the execution of the swap, the market moves against Alice's trade and the swap was executed at 1,990.

Slippage=actualOutput−estimatedOutputestimatedOutput∗100%Slippage=\frac{actualOutput-estimatedOutput}{estimatedOutput}*100\%Slippage=estimatedOutputactualOutput−estimatedOutput​∗100%
Slippage=1990−20002000∗100%=−0.5%Slippage=\frac{1990-2000}{2000}*100\%=-0.5\%Slippage=20001990−2000​∗100%=−0.5%

No slippage

Between confirming the swap and the execution of the swap, no other trades are executed before Alice's trade hence the executed price is as per the estimated 2,000.

Slippage=2000−20002000∗100%=0%Slippage=\frac{2000-2000}{2000}*100\%=0\%Slippage=20002000−2000​∗100%=0%

Alice expected 2,000USDT and got 2,000USDT. Hence, there is no difference between the expected amount and the final executed amount resulting in no slippage incurred for this transaction.

Positive slippage

Between confirming the swap and the execution of the swap, the market moves in favor of Alice's trade and the swap was executed at 2,010.

Slippage=2010−20002000∗100%=0.5%Slippage=\frac{2010-2000}{2000}*100\%=0.5\%Slippage=20002010−2000​∗100%=0.5%

Alice expected 2,000USDT and managed to get 2,010USDT for a net surplus of 10USDT. This equates to a positive slippage of 0.5%.

Protecting our users

KyberSwap's highest priority is the safety of our users. As such, we have implemented multiple safeguards to ensure that traders using our platform do not receive any unwelcome surprises.

  • Customizing Trade Parameters

  • Instantly Swap At Superior Rates

  • Place A Limit Order

  • Fill A Limit Order

As hinted above, slippage can be either negative or positive as its definition does not specify a particular direction in terms of expected and executed price. As a user in the DeFi space, it is usually harder to realize positive slippage due to the presence of bots which are always on the lookout for front-running opportunities. This is especially the case for larger trades where the gas costs required for a successful MEV strategy becomes progressively more insignificant as the trade size increases.

Alice got into ETH early and is planning to cash out her profits by selling her ETH for USDT. Alice wants to execute the swap immediately and decides to swap via the for the best rates.

Alice wants to sell 1ETH and sets a of 1% (higher value chosen for illustrative purposes)

Alice expected 2,000USDT but only got 1,990USDT for a net shortfall of 10USDT. This equates to a negative slippage of 0.5%. Note that the negative slippage is capped at the 1% max slippage setting hence if output amount from the trade falls below 1,980USDT, the trade will not be executed. As such, it is always recommended that you for your trades.

By splitting and rerouting trades across multiple liquidity sources, the minimizes the potential slippage incurred from any single source. Moreover, the enables traders to set a Max Slippage to guarantee that trades are only executed if the final price is within the expected price range.

Lastly, allows traders predefine the prices at which their trades will be executed. This sidesteps any negative slippage risks and provides traders much greater price guarantees for their trades.

Price Impact
MEV
KyberSwap Aggregator
max slippage
configure a max slippage
KyberSwap Aggregator
KyberSwap Aggregator
KyberSwap Limit Order
Swap At Your Preferred Rates
Execute A Swap With The Aggregator API