⚙️Pool Configuration

This page is relevant for anyone looking to launch a token on the Ethervista DEX and seeking to understand how Ethervista's liquidity pools and swaps function

Creating a pool

When creating a pool on the Ethervista DEX the launch function is called

function launch(
    address token,
    uint amountTokenDesired,
    uint amountTokenMin,
    uint amountETHMin,
    uint8 buyLpFee,
    uint8 sellLpFee,
    uint8 buyProtocolFee,
    uint8 sellProtocolFee,
    address protocolAddress
) external virtual override payable returns (uint amountToken, uint amountETH, uint liquidity)

This function adds liquidity to the pool and sets the pool parameters

Fee structure in swap operations

Every swap operation collects a native ETH fee, which is then distributed between liquidity providers and the protocol. The fee structure is designed to be customizable for each pool.

Fee Variables

Four uint8 fee variables must be initialized for every pool:

1. buyLpFee: Fee for liquidity providers on buy transactions

2. sellLpFee: Fee for liquidity providers on sell transactions

3. buyProtocolFee: Fee for the protocol on buy transactions

4. sellProtocolFee: Fee for the protocol on sell transactions

These variables represent USD amounts, for which the corresponding ETH fee is calculated on every swap using an on-chain oracle.

Fee Calculation Example

Let's consider a buy transaction with the following setup:

• buyLpFee = 5 ($5)

• buyProtocolFee = 3 ($3)

The total fee for this transaction would be $9 ($8 for LP and protocol, plus an additional $1 for the treasury fee).

Swap Process

1. When executing a buy order, the router performs a USD to ETH conversion.

2. The router ensures that sufficient ETH has been provided to cover the calculated fee.

3. The fee is then distributed:

   • The liquidity provider fee is sent to the pair contract which utilizes the Euler model to distribute rewards

   • The protocol fee is sent to the address specified by protocolAddress

Buys are identified by

function swapExactETHForTokensSupportingFeeOnTransferTokens(
        uint amountOutMin,
        address[] calldata path,
        address to,
        uint deadline
    )
        external
        virtual
        override
        payable
        ensure(deadline)
    {

and sells by

function swapExactTokensForETHSupportingFeeOnTransferTokens(
        uint amountIn,
        uint amountOutMin,
        address[] calldata path,
        address to,
        uint deadline
    )
        external
        payable
        virtual
        override
        ensure(deadline)
    {

The Protocol address

The protocolAddress parameter is used to designate the recipient of the protocol's share of the fees. This address should be set carefully as it will receive a portion of every swap's fees. This address can either be a treasury wallet or a smart contract which implements areceivefunction

receive() external payable {
       IEtherVistaRouter router = IEtherVistaRouter(IEtherVistaFactory(factory).router());
       uint256 threshold = router.usdcToEth(100); 

        if (address(this).balance >= threshold) {
         //arbitrary logic
    }
}

We recommend that protocol implementations perform operations only after a certain threshold has been reached to minimize gas costs. For instance, Ethervista uses a $100 threshold. When the smart contract accumulates the equivalent of $100 in ETH, a portion is automatically used to buy and burn tokens, while another portion is sent to the Hardlock and Hardstake contracts to reward users who lock their VISTA liquidity or VISTA tokens

Configuring a pool

The individual who initiates liquidity provision is designated as the Creator.

• The Creator has write access to configure pool settings.

• Configurable parameters include all fees, protocol address, and metadata.

• This role can be renounced at any time, after which the creator will no longer be able to update the pool parameters

Updating Pool Parameters

To ensure transparency and prevent potential misuse, updates to pool parameters follow a two-step process with a mandatory 3 day waiting period.

Updating fees

1. Step 1: Initiate Fee Update The Creator must first call the updateFees function:

   function updateFees(
       uint8 buyLpFuture,
       uint8 sellLpFuture,
       uint8 buyProtocolFuture,
       uint8 sellProtocolFuture
   ) external

2. Step 2: Implement Fee Update After a 3-day waiting period, the Creator must call the setFees function to apply the changes:

   function setFees() external

Updating the protocol address

A similar two-step process applies for updating the protocol address:

1. Call updateProtocol(address protocol) to initiate the change.

2. After 3 days, call setProtocol to implement the change.

Security Measures

This two-step update process with a mandatory waiting period serves several important purposes:

1. Transparency: It provides a window of time for all stakeholders to become aware of pending changes.

2. Security: It prevents a potentially malicious Creator from suddenly increasing fees or altering critical parameters.

3. User Protection: Users have a 3-day notice to verify the legitimacy of any change initiated by the Creator.

4. Opportunity to Exit: If users disagree with proposed changes, they have time to exit their positions before the changes take effect.

Metadata

Finally the creator can set an on-chain metadata which can be used by external parties

function setMetadata(string calldata website, string calldata image, string calldata description, string calldata chat, string calldata social)