# An intro to Ethervista Rethinking Decentralized Exchange Dynamics for Sustainable Blockchain Growth ## Abstract Automated Market Makers (AMMs) currently encounter a notable challenge – they struggle to effectively encourage the long-term success of blockchain projects. The problem arises because token creators are encouraged to prioritize profits by rapidly withdrawing liquidity and discreetly selling tokens. Liquidity providers tend to prefer short-term commitments, withdrawing and selling their liquidity as token value rises. This misalignment in structure hampers the growth of projects designed for long-term success. Addressing this challenge is vital, as the current AMM model lacks the necessary incentives to foster continuous growth and resilience in the blockchain ecosystem ## The Euler model and revenue sharing At the core of Ethervista's revolution is the **Euler Model**, a new mathematical model that enables fee distribution in **ETH**, eliminating the need for clunky, token-based rewards. This model precisely calculates ETH rewards using a user’s **Euler0 baseline**, drastically reducing the computational load and gas costs, making it scalable even for millions of users. For the first time, rewarding **liquidity providers** and **stakers** with ETH—not tokens that depreciate over time—becomes not only possible but the standard Each liquidity pool can implement customized fee structures for both l**iquidity providers (LPs)** and the **protocol** itself, facilitating a "pay to play" model where **u**sers must contribute to the ecosystem before benefiting from it. ### Protocol Fees Protocol fees on Ethervista creates new opportunities by directing fees straight to the protocol, allowing markets to benefit from the revenue they generate. Since these fees are paid in ETH, they do not threaten the projects they support. Instead, protocol fees enhance the ecosystem by automatically funding each protocol’s smart contract and treasury with every swap. This model establishes a sustainable revenue sharing stream that is not available with other Automated Market Makers. By focusing on long-term benefits rather than short-term gains, creators can rely on a steady income without needing to discreetly sell tokens to generate revenue. ### Implications The Euler Model introduces new possibilities for users and creators. For the first time, they can **burn their liquidity and continue to earn rewards.** In the past, creators had no reason to lock their liquidity, as it would use up their funds without any benefit. Now, they can earn rewards from their locked liquidity, which helps build user trust by reducing the risk of rug pulls. The **5-day enforced liquidity lock mechanism** provides a clear timeframe for projects to secure their liquidity, promoting transparency and giving users enough time to evaluate a project's legitimacy Beyond, The Euler Model allows game developers to create liquidity pools specifically for in-game assets without the need to tokenize them, thereby avoiding the issues of value depreciation and security risks associated with traditional tokens. By restricting these liquidity pools to in-game assets, developers can implement a flat fee structure paid in ETH. This approach ensures that the in-game assets retain their value and stability, providing a reliable framework for players and enhancing the overall gaming experience. ## VISTA: The first value-compounding deflationary token The $VISTA protocol’s smart contract employs an on-chain mechanism where each burn event not only reduces the circulating supply but also gradually increases the token's price floor. This process is sustained by the ongoing acquisition and destruction of tokens, funded by transaction fees generated within the protocol. As a result, VISTA's mechanics serve as a hedge against inflation, linking activity to supply reduction and price floor enhancement. This strengthens VISTA's value with each transaction, fostering sustained growth and scarcity ### Token Distribution At launch, 100% of the total supply (1 million VISTA) was allocated to the VISTA/WETH pool, with 36,000 tokens autobought and burned as of this writing (2024 October 20). Most VISTA tokens are held by the Hardlock and Hardstake contracts, which together represent the top holders at 20%. With Ethervista's implementation of an anti-sniper fair launch, no single holder possesses an excessive share of the total supply *Ethervista aims to be an all-in-one DeFi platform, with upcoming expansions to include feeless flashloans, lending, and futures trading* # The Euler Model This page is for anyone interested in understanding how the Euler model can be implemented to efficiently distribute rewards paid in ETH to millions of users with negligble gas costs ## Introduction *We explain the Euler model using the Ethervista LP pool as an example, but the model can be applied to any contract that implements staking or locking of assets and distributes ETH rewards based on the user's share of those assets* The Ethervista pair smart contract maintains a sequence of ascending numbers known as Euler amounts. These values are updated each time native ETH is transferred to the pair contract. Each Euler amount is determined by adding the previous Euler amount to the ratio of the fee to the current total supply of liquidity provider tokens (LP). **The initial Euler amount is set to zero**. Mathematically, this update can be represented as: $$ \text{Euler}*n = \text{Euler}*\text{n-1} + \frac{\text{fee}}{\text{LP supply}} $$ With the corresponding sequence of rising numbers: $$ {\text{ Euler}\_1, \text{ Euler}\_2, \text{ Euler}\_3, \text{ Euler}\_4 \ldots \text{ Euler}\_n } $$ This sequence is particularly of interest to liquidity providers. Each provider is represented by a struct which stores the LP holdings of each user and a variable called `euler0` which is suggestively named after the Euler amounts in our sequence. ```solidity struct Provider { uint256 lp; uint256 euler0; }; ``` This `uint256` number represents the latest Euler amount in our sequence at the time the user adds liquidity, in which case we would have $$ \text{ euler0} = \text{ Euler}\_n $$ Suppose the user decides to claim rewards a thousand swaps later. In that moment, the latest Euler amount is $$ \text{Euler}\_\text{n+1000} $$ The exact amount of rewards that this provider accumulated during these thousand swaps is: $$ \text{Reward} = \text{lp} \* (\text{Euler}\_\text{n+1000}-\text{euler0}) $$ This approach operates under the assumption that the LP balance remains constant throughout the period. Therefore, whenever a provider takes any action, such as adding/removing/transferring liquidity, the variable `euler0` will be refreshed to reflect the latest Euler amount in our sequence. This measure prevents a liquidity provider from manipulating their own share of rewards. As such, it is advisable for a liquidity provider to always claim rewards before adjusting their LP balance. **The Ethervista DEX uses the Euler model for:** * Rewarding l**iquidity providers** * **Hardstaking**: Users can stake their tokens and receive rewards paid in ETH from the protocol fees every transaction * **Hardlocking**: Creators/users can lock their LP tokens and still benefit from rewards, something which was not possible in other AMM standards ## Implementing the Euler model Three key components are needed to implement the Euler model in a smart contract * An `updateStaker` function which update the user baseline **Euler0** when there is a balance change (i.e a user stakes/un-stakes/transfers) or a reward claim * A `updateEuler` function which updates the Euler-array when ETH is received by the smart contract * A **payable function** which calls updateEuler when receiving ETH * A `viewShare` function which returns the reward share of each user ```solidity struct Staker { uint256 amountStaked; uint256 euler0; } uint256[] public euler; mapping(address => Staker) public stakers; function updateEuler(uint256 Fee) internal { if (euler.length == 0){ euler.push((Fee*bigNumber)/totalSupply); }else{ euler.push(euler[euler.length - 1] + (Fee*bigNumber)/totalSupply); } } //alternatively can be the receive() function if ETH is sent directly //to this contract function contributeETH() external payable nonReentrant { updateEuler(msg.value); } function updateStaker(address user) external { if (euler.length == 0){ stakers[user] = Staker(balanceOf[user], 0); }else{ stakers[user] = Staker(balanceOf[user], euler[euler.length - 1]); } } //+ stake/unstake/claim functions function viewShare() public view returns (uint256 share) { if (euler.length == 0){ return 0; }else{ return stakers[msg.sender].amountStaked * (euler[euler.length - 1] - stakers[msg.sender].euler0)/bigNumber; } } ``` # 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 ```solidity 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 ```solidity function swapExactETHForTokensSupportingFeeOnTransferTokens( uint amountOutMin, address[] calldata path, address to, uint deadline ) external virtual override payable ensure(deadline) { ``` and **sells** by ```solidity 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 a`receive`function** ```solidity 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: ```solidity 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: ```solidity 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 ```solidity function setMetadata(string calldata website, string calldata image, string calldata description, string calldata chat, string calldata social) ``` # Hardstake and Hardlock For the first time, users can lock/burn their liquidity and still earn rewards. Stakers receive payouts in ETH, not tokens, eliminating unnecessary selling pressure and inflation. ## Introduction To safely manage LPs and prevent exploits within the Euler model, the Ethervista Router introduces three key functions: `updateSelf`, `safeTransferLp`, and **`hardstake`**. ### safeTransferLp ```solidity function safeTransferLp(address _token, address to, uint256 _amount) public override ``` This function ensures secure transfer of LP tokens: * Updates the `msg.sender`'s provider struct in the pair contract when transferring LP tokens * Prevents liquidity providers from manipulating their reward share through balance duplication * **Requires all LP transfers to go through the router** ### hardstake ```solidity function hardstake(address _contract, address _token, uint256 _amount) public override ``` Enables staking/locking of any ERC20 and LP tokens in compliance with the Euler model: #### Process: 1. Transfers tokens to a contract implementing the external function: ```solidity stake(uint256 amount, address staker, address token) ``` 2. Verifies if the token is a VISTA-LP token 3. If verification passes, updates the `msg.sender`'s provider struct to reflect reduced balance and share 4. Calls the contract's custom stake implementation #### Important Notes: * `stake` ensures consistency between tokens/amounts passed to the external stake function and those transferred by the `hardstake` function * Developers must restrict stake calls to this router for guaranteed token receipt verification (**router is a variable stored in the factory's contrac**t) * Receivers (users/contracts) must call `updateSelf(address _pair)` to begin accruing rewards for received LP-tokens * This can be done directly inside the `stake` implementation * Liquidity staking contracts must accurately allocate and distribute rewards to stakers based on their contributions * Staking/locking contracts can use the Euler model to distribute rewards in paid in ETH. For example, Ethervista leverages the protocol fee alongside the Euler model to reward $VISTA stakers based on their share of the total staked amount. It also rewards liquidity providers who lock their liquidity for at least two weeks, ensuring more stable liquidity pools ## Templates We provide two templates for staking: 1. Standard ERC-20 tokens (**Hardstake**). This template allows users to stake their tokens and earn ETH rewards from the protocol fee or other ETH contribution using the Euler model {% embed url="" %} 2. LP tokens (**Hardlock**) : This is a specialized case of Hardstake for LP tokens that ensures proper allocation and distribution of rewards to liquidity stakers based on their contributions to the pair contract. This contract maintains its own Euler sequence, which is based on the liquidity fees accrued by the pair contract {% embed url="" %} **Note**: In these template contracts, staking or unstaking actions will reset the lock time. Additionally, staking or unstaking will reset the rewards balance to zero. Therefore, users are advised to claim any accumulated rewards *before* performing these actions to avoid losing unclaimed earnings. # Etherfun Etherfun is taking what Pump.fun started, improving it and merging it with Ethervista's innovations to create the best memecoin trading and launching experience, adapted to Ethereum high gas costs. ## TLDR; > ***ETHERFUN*** mainly incentivizes **completion** with high **incentives** > Creators can launch a token for a few bucks 1$-2$ it’s almost free > First buyers and last buyers cover the gas costs and are rewarded 0.03 ETH (\~$ 100) each well enough to compensate for gas costs and be rewarded extra. First buyer also gets the best price. (all other transactions are sub 1$) > Bonding occurs once \~1.5 ETH is raised. Bonding curve is reached much quicker than on pumpdotfun but yet the pools are stabler > Liquidity is then perma-locked on ethervista. Creators and LP-providers get 5$ each for every swap > How does VISTA benefit from all this ? Fees generated from LP-fees from the initial LP pool are sent to the vista treasury, part of which is used to auto-buy and burn more vista tokens, as well as support the ecosystem ## Etherfun: Advancing Memecoin Trading on Ethereum ### Introduction Etherfun represents the next evolution in memecoin trading and launching, building upon Pump.fun's foundation while incorporating Ethervista's innovations. The platform specifically addresses Ethereum's high gas cost environment through an optimized bonding curve model that creates lasting value for both creators and traders. ### Platform Mechanics #### Creator Experience Etherfun eliminates traditional barriers to token creation through an innovative launch system. Creators can initiate their projects by simply providing essential details - token name, ticker, image, and description - with optional social links and website integration to improve community engagement. The platform's distinctive feature is its minimal upfront cost structure. Token deployment costs are transferred to the first buyer, making launches almost free for creators. However, creators who choose to be first buyers gain significant advantages: they secure the lowest token price point and earn 2% of the ETH pool (0.03 ETH) upon successful bonding. The path to success is clearly defined: creators need to raise 1.5 ETH through the bonding curve. Upon reaching this milestone, the platform automatically establishes a liquidity pool on Ethervista. This brings a unique long-term benefit - creators earn 5$ in ETH for every subsequent trade on their token, providing continuous motivation for community building and project development. #### Trading Dynamics Traders benefit from a transparent and equitable trading environment. The platform features intuitive search functionality with comprehensive filters, allowing users to discover promising tokens efficiently. The bonding curve model ensures fair distribution - there are no presales or team allocations, giving every participant equal opportunity for early entry. First buyers play a crucial role in the ecosystem. When creators opt not to cover deployment costs, the first buyer can step in, earning 2% of the token's ETH pool (0.03 ETH) upon bonding, plus securing the lowest possible entry price. This creates a balanced risk-reward scenario for early participants. The platform maintains complete trading flexibility - users can sell their positions at any time, enabling proper risk management and profit-taking strategies. The final stages of the bonding curve include a unique graduation incentive: the buyer who triggers the curve exit receives 2% of the token's ETH pool, offsetting the higher gas costs associated with liquidity deployment on Ethervista. Upon exit, the smart contract automatically establishes a sustainable liquidity pool using the remaining 30% of tokens and 1.44 ETH raised. ### Advantages Over Existing Solutions #### Optimized Bonding Curve Etherfun's reduced bonding curve target of $4,000 (versus Pump.fun's $12,000) accelerates project development while minimizing the risk of tokens becoming stagnant. This structure creates a more dynamic and active trading environment where success is more achievable for quality projects. #### Aligned Incentives The platform creates a unified ecosystem where all participants benefit from project success. Creators are motivated to support graduation for the 2% pool reward and ongoing $5 per trade earnings. Traders compete for the first and final buyer bonus, driving projects toward successful **completion**. This alignment prevents the common issue of creator abandonment seen on other platforms. #### Ecosystem Support With a streamlined 2% fee structure, Etherfun maintains efficient trading mechanics while generating sustainable platform revenue. These fees support the continuous development of Ethervista, Etherfun and VISTA token buyburns, benefiting the entire ecosystem. #### Security and Professional Features The platform implements robust anti-bot measures through a ranked user system, ensuring authentic community interaction while maintaining accessibility for legitimate users. Creators can enhance their tokens' credibility through professional metadata options, including logos and social links, though these remain optional to maintain launching flexibility. #### Sustainable Liquidity Management Upon curve exit, initial liquidity is permanently locked on Ethervista through an innovative mechanism that continues generating LP fees instead of becoming dormant. The community benefits from partial fee redistribution, and any user can contribute additional liquidity to earn LP fees, creating a self-sustaining ecosystem. ### Future Vision Etherfun will continue to evolve based on community feedback and market demands, maintaining its core focus on creating sustainable trading environments while adapting to the dynamic requirements of the Ethereum ecosystem. The platform's commitment to balancing creator and trader interests while optimizing for gas efficiency positions it as a leading solution for memecoin trading and launching across all networks. # Official links **DEX:**[ ](https://ethervista.app/)[https://ethervista.app](https://ethervista.app/)\ ***ETHERFUN*****:** [https://etherfun.app/](https://etherfun.app/)\ **TWITTER:**[ ](https://x.com/ethervista)[https://x.com/ethervista](https://x.com/ethervista)\ **DISCORD:** [https://discord.com/invite/ethervista](https://discord.com/invite/ethervista)\ **TELEGRAM:** [https://t.me/etherfun\_trenches](https://t.me/etherfun_trenches)\ \ **DEPLOYED CONTRACTS:** [https://github.com/Ethervista/Deployed-Contracts/tree/main](https://github.com/Ethervista/Deployed-Contracts/tree/main)\ **HARDSTAKE TEMPLATES:** [https://github.com/Ethervista/HARDSTAKE](https://github.com/Ethervista/HARDSTAKE)