ICronV1Relayer

Provides a simplified interface to Cron-Finance Time Weighted Average Market Maker (TWAMM) pools impelemnted in the Balancer Vault, performing additional safety and usability checks along the way.

    IMPORTANT: pool addresses and ids for all calls are determined by the Cron-Finance TWAMM Factory contract,
               preventing access to other types of pools in the Balancer Vault for additional safety.

swap

function swap(address _tokenIn, address _tokenOut, uint256 _poolType, uint256 _amountIn, uint256 _minTokenOut, address _recipient) external returns (bytes swapResult)

Performs a short-term (atomic) swap of the specified amount of token in to token out on the Cron- Finance Time-Weighted Average Market Maker (TWAMM) pool uniquely identified from the addresses of token in, token out, and the pool type.

    The slippage specified in basis points is used to determine how much token out can be lost relative
    to a trade occuring at the current reserve ratio. If the amount of token out is more than the slippage
    percent different than the ideal amount calculated by the current reserve ratio, the trade reverts.

    A recipient can be specified if the proceeds of the trade are to be directed to an account different
    from the calling account, msg.sender.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    Checks performed on behalf of a user include:
      - Pool specified by token in and out addresses and pool type exists.
      - Pool has been funded and contains minimum liquidity amounts.
      - Swap amount specified is greater than zero and available in the calling account (msg.sender).
      - Trade results in amount of token out within specified slippage percent of the ideal amount
        calculated from the ratio of the pool's virtual reserves.

    Checks NOT performed for a user include:
      - Validity / sanity of the recipient address.

Parameters

Return Values

join

function join(address _tokenA, address _tokenB, uint256 _poolType, uint256 _liquidityA, uint256 _liquidityB, uint256 _minLiquidityA, uint256 _minLiquidityB, address _recipient) external returns (bytes joinResult)

Performs a join (mint) to the specified Cron-Fi Time-Weighted Average Market Maker (TWAMM) pool. The amount of token A and B provided to the pool is given in liquidity A and B, respectively. Specifiying the minimum nominal liquidity provided to the pool in min liquidity A and B for tokens A and B, respectively, protects against attacks intended to capture user liquidity from price manipulation.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed.

    A recipient can be specified if the pool tokens (liquitity provider tokens) are to be directed
    to an account different from the calling account, msg.sender.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    WARNING: The first time liquidity is provided to a Cron-Fi TWAMM pool, a minimum amount of
             liquidity is retained by the pool, with the corresponding pool tokens not provided to
             the calling account. (See miscellany/Constants.sol::MINIMUM_LIQUIDITY).

    Checks performed on behalf of a user include:
      - Specified pool exists.
      - Pool has been funded and contains minimum liquidity amounts.
      - Join liquidity amounts specified are greater than zero and available in the calling account
        (msg.sender).
      - The pro-rata liquidity providing algorithm collects at least both minimum specified liquidity
        amounts to protect against price manipulation attacks.

    Checks NOT performed for a user include:
      - Validity / sanity of the recipient address.

Parameters

Return Values

exit

function exit(address _tokenA, address _tokenB, uint256 _poolType, uint256 _numLPTokens, uint256 _minAmountOutA, uint256 _minAmountOutB, address _recipient) external returns (bytes exitResult)

Performs an exit (burn) from the specified Cron-Fi Time-Weighted Average Market Maker (TWAMM) pool. The amount of pool tokens (liquidity provider tokens) is specified by numLPTokens. Specifiying minimum amounts of token A and B to receive from the pool in exchange for pool tokens can be done with min amount out A and B, respectively. This protects against price manipulation and other attacks, reverting if the minimums aren't received.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed.

    A recipient can be specified if the tokens emitted are to be directed to an account different from the
    calling account, msg.sender.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    Checks performed on behalf of a user include:
      - Specified pool exists.
      - Pool token amount specified is greater than zero and available in the calling account
        (msg.sender).
      - The specified minimum amounts of token A and B are received in the exchange for pool tokens or
        the transaction reverts.

    Checks NOT performed for a user include:
      - Validity / sanity of the recipient address.

Parameters

Return Values

longTermSwap

function longTermSwap(address _tokenIn, address _tokenOut, uint256 _poolType, uint256 _amountIn, uint256 _intervals, address _delegate) external returns (bytes longTermSwapResult, uint256 orderId)

Gets a multicall array argument to perform a long-term (non-atomic) swap of the specified amount of token in to token out on the Cron-Finance Time-Weighted Average Market Maker (TWAMM) pool uniquely identified from the addreses of token in, token out, and the pool type.

    The intervals specified is the duration over which to perform the long-term swap. An interval is a
    number of blocks, depending on the pool type specified (See miscellany/Constants.sol::{STABLE_OBI,
    LIQUID_OBI, VOLATILE_OBI}). The amount specified is divided by the number of blocks in the duration
    of the trade, known as the sales rate. The sales rate is used to compute the swap when virtual orders are
    executed (usually at block numbers divisible by the block interval, OBI, or at transactions against
    the pool). Any excess amount not divisible by the trade duration is not taken for the trade (i.e. the
    amount in specified is reduced to an amount wholely divisible by the trade duration).

    A delegate address may be specified. The delegate address has the ability to withdraw or cancel the
    long-term swap to the calling account's address at any time. The delegate cannot withdraw or cancel the
    long-term swap to any address but the calling account's address. The delegate address cannot be modified
    during the duration of the trade--the only mitigation is for the calling account to cancel the trade. If
    the delegate is unspecified or the NULL address, the delegate is considered undefined and there is no such
    role for the long-term swap.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    Checks performed on behalf of a user include:
      - Pool specified by token in and out addresses and pool type exists.
      - Pool has been funded and contains minimum liquidity amounts.
      - Swap amount specified is greater than zero and available in the calling account (msg.sender).
      - Intervals specified are greater than zero.
      - Reducing the swap amount specified to the amount wholely divisible by the trade duration to
        prevent losses due to fixed-precision limitations.

    Checks NOT performed for a user include:
      - Validity of the delegate address.

Parameters

Return Values

withdraw

function withdraw(address _tokenA, address _tokenB, uint256 _poolType, uint256 _orderId, address _recipient) external returns (bytes withdrawResult)

Performs a withdrawal of a long-term (non-atomic) swap, given the order id of the swap.

    Multiple withdrawals are possible througout the duration of a long-term swap, with a final withdrawal
    possible after the swap has expired.

    If a delegate has been specified in the long-term swap and is performing the withdrawal, the _recipient
    address must be the original long-term swap owner (calling account, msg.sender) or the withdrawal will
    revert.

    If the owner (calling account, msg.sender) is performing the withdrawal, the funds may be directed to
    another account, the address of which is specified in the recipient parameter.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed. Since
    this method need not specify any amounts of either asset token, the two assets are only used to correctly
    identify the pool, given the pool type.

    Checks performed on behalf of a user include:
      - Specified pool exists.

    Checks NOT performed for a user include:
      - Validity / sanity of the recipient address.

Parameters

Return Values

cancel

function cancel(address _tokenA, address _tokenB, uint256 _poolType, uint256 _orderId, address _recipient) external returns (bytes cancelResult)

Performs a cancel of a long-term (non-atomic) swap, given the order id of the swap.

    Cancellation is possible up until the swap order expiry. Already executed portions of the long-term
    swap are remitted along with any remaining unsold tokens.

    If a delegate has been specified in the long-term swap and is performing the cancellation, the _recipient
    address must be the original long-term swap owner (calling account, msg.sender) or the cancellation will
    revert.

    If the owner (calling account, msg.sender) is performing the cancellation, the funds may be directed to
    another account, the address of which is specified in the recipient parameter.

    IMPORTANT: Users must approve this contract on the Balancer Vault before any transactions can be used.
               This can be done by calling setRelayerApproval on the Balancer Vault contract and specifying
               this contract's address.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed. Since
    this method need not specify any amounts of either asset token, the two assets are only used to correctly
    identify the pool, given the pool type.

    Checks performed on behalf of a user include:
      - Specified pool exists.

    Checks NOT performed for a user include:
      - Validity / sanity of the recipient address.

Parameters

Return Values

getPoolAddress

function getPoolAddress(address _tokenA, address _tokenB, uint256 _poolType) external view returns (address pool)

Gets the Cron-Fi pool address, given the pool's asset token addresses and pool type. This method is useful for inspecting the pool that methods in this periphery relayer will be operating on by getting the target pool address from the provided parameters.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed. Since
    this method need not specify any amounts of either asset token, the two assets are only used to correctly
    identify the pool, given the pool type.

Parameters

Return Values

getOrder

function getOrder(address _tokenA, address _tokenB, uint256 _poolType, uint256 _orderId) external view returns (address pool, struct Order order)

A convenience for getting the order data for a given order id in a pool specified by the provided token addresses and pool type.

    If the pool cannot be identified or does not exist given the provided parameters, the call
    reverts with a non-existing pool error code.

    Tokens A and B referred to herein are an abstraction atop Balancer Vaults notion of the tokens in
    a two-token pool, tokens 0 and 1. Rather than have the user figure out the correct sort order of
    the tokens and specify token 0 and related values correctly, the user need only specify values for
    a given token address and this periphery relayer will correctly figure out the sort order and call
    the vault low level functions appropriately, matching token A and B to token 0 and 1 as needed. Since
    this method need not specify any amounts of either asset token, the two assets are only used to correctly
    identify the pool, given the pool type.

    NOTE: It is more gas efficient to call the method of the same name on the target Cron-Fi pool contract.
          This method is provided as a convenience for users of web interfaces like Etherscan or Gnosis Safe.

Parameters

Return Values

getLibrary

function getLibrary() external view returns (address)

Gets the library address that this periphery relayer delegate calls to perform Cron-Fi pool operations on behalf of the calling account.

Return Values

getVault

function getVault() external view returns (contract IVault)

Gets the Balancer Vault that this periphery relayer is serving.

Return Values

Last updated