LogoLogo
  • Introduction
    • Overview
    • Concepts
      • Decentralised Exchange (DEX)
      • Liquidity Pools
      • Swaps
      • Automated Market Maker (AMM)
      • Fees
  • Developers
    • Smart Contracts
      • Error Codes
      • Flash Loans
      • Internal User Balances
      • Pool Interface
    • Joins and Exits
      • Pool Joins
      • Pool Exits
    • Maths
      • Weighted Maths
    • Arbitrage System
      • Arbitrage Functions
    • Swaps
      • Single Swap
      • Batch Swaps
    • Arbitrage Profit Distributor
  • Resources
    • Code Licensing
    • Change Log
    • Glossary
    • Web3
    • Security & Audits
Powered by GitBook
On this page
  1. Developers
  2. Joins and Exits

Pool Exits

Calls to joinPool() are made on the Vault, not directly on the pool. To identify the pool targeted for deposit you must pass the poolId as a parameter on the JoinPool Function

API

exitPool(
    bytes32 poolId,
    address sender,
    address recipient,
    ExitPoolRequest request
)

struct ExitPoolRequest {
    address[] assets,
    uint256[] minAmountsOut,
    bytes userData,
    bool toInternalBalance
}

Arguments Explained

  • poolId - ID of the pool you're interacting with

  • sender - Address sending BPT

  • recipient - Address receiving tokens (usually the same as sender)

  • request - ExitPoolRequest tuple made up of the following:

    • assets - List of your tokens, ordered (see below)

    • minAmountsOut - Minimum token receive amounts (see below)

    • userData - Custom bytes field (see below)

    • toInternalBalance - True if you receiving tokens as internal token balances. False if receiving as ERC20.

Token Ordering

When providing your assets, you must ensure that the tokens are sorted numerically by token address. It's also important to note that the values in minAmountsOut correspond to the same index value in assets, so these arrays must be made in parallel after sorting.

minAmountsOut

In the exitPool call, you have to provide minAmountsOut, this represents the minimum amount of tokens you're willing to receive upon exits

Let's say that you want to allow a 1% slippage. After computing how many tokens you expect for a given amount of BPT, you'd apply a factor of 0.99 to all the amounts.

userData

userData is a highly versatile field; as such, it needs to be encoded for its specific use case. For exits, userData encodes a ExitKind to tell the pool what style of exit you're performing. Since pool types are customizable, not every pool necessarily uses the same ExitKind, so it's important to keep track of what each pool type can handle.

When encoding userData for pools that include their own BPT as part of the pool's tokens, the BPT are not included in the userData.

WeightedPool ExitKinds

enum ExitKind {
    EXACT_BPT_IN_FOR_ONE_TOKEN_OUT,
    EXACT_BPT_IN_FOR_TOKENS_OUT,
    BPT_IN_FOR_EXACT_TOKENS_OUT
}

Exit Types Explained

  • Single Asset Exit (EXACT_BPT_IN_FOR_ONE_TOKEN_OUT)

    • User sends a precise quantity of BPT, and receives an estimated but unknown (computed at run time) quantity of a single token.

  • Proportional Exit (EXACT_BPT_IN_FOR_TOKENS_OUT)

    • User sends a precise quantity of BPT, and receives an estimated but unknown (computed at run time) quantities of all tokens.

  • Custom Exit (BPT_IN_FOR_EXACT_TOKENS_OUT)

    • User sends an estimated but unknown (computed at run time) quantity of BPT, and receives precise quantities of specified tokens.

Encoding

  • Single Asset Exit

    • userData ABI

      • ['uint256', 'uint256', 'uint256']

    • userData

      • [EXACT_BPT_IN_FOR_ONE_TOKEN_OUT, bptAmountIn, exitTokenIndex]

  • Proportional Exit

    • userData ABI

      • ['uint256', 'uint256']

    • userData

      • [EXACT_BPT_IN_FOR_TOKENS_OUT, bptAmountIn]

  • Custom Exit

    • userData ABI

      • ['uint256', 'uint256[]', 'uint256']

    • userData

      • [BPT_IN_FOR_EXACT_TOKENS_OUT, amountsOut, maxBPTAmountIn]

PreviousPool JoinsNextMaths

Last updated 2 months ago