A simple framework for simulations of the ve(3,3) model for decentralized exchanges
Author:DrSimplex
Stabl Research, stabl.fi
July 2023
Abstract
In this article, I detail the main components of a ve(3,3)-type decentralized exchange on the level of very basic tokenomics. From there, I construct a recursive scheme that allows to simulate the price action of such an exchange based on a very limited number of parameters as shown in one concrete example. The results shown are preliminary and more extensive analysis is needed in the future. In the longer run, this will provide a starting point for more realistic simulations that have two main goals: (i) try to model user behavior as accurately as possible; (ii) study the effects of basic changes to tokenomics on the level of a simulation and not in-field.
1 Introduction
A decentralized exchange (DEX) is an exchange for cryptocurrencies operating in a decentralized manner. It does not rely on a central authority or intermediary to facilitate the exchange of digital assets. Unlike traditional centralized exchanges (CEXs), which require users to deposit their funds with the exchange and trade through the exchange’s order book, DEXs allow users to trade directly with each other on a peer-to-peer basis.
DEXs leverage blockchain technology to enable direct asset transfer between users, typically utilizing smart contracts on a blockchain such as Ethereum or the Binance Smart Chain for two of the most popular ones. Smart contracts are self-executing contracts with predefined rules that facilitate and automate the exchange process. They act as the intermediary, holding the funds of the users involved in the trade and releasing them once the mutual transaction conditions are met.
While DEXs offer advantages such as increased security and user control, they also have limitations. These include lower liquidity compared to centralized exchanges, potential delays in transaction execution due to blockchain confirmation times, and the limited range of trading pairs available. However, the popularity and development of DEXs continue to grow, with ongoing efforts to address these limitations and improve the overall user experience.
Finding deep liquidity for many trading pairs is a key challenge for a DEX to attract users (often via aggregators) and facilitate efficient trading. There are a number of strategies to accomplish that, usually involving the inflationary emission of reward tokens. A very popular one in the recent past was the ve(3,3) model which was employed to jumpstart a large number of DEXs on layer 1 and layer 2 blockchains.
The name ve(3,3) DEX refers to a voting-based escrow model. The term ”ve” stands for ”vote escrow,” which is a mechanism used to align the incen- tives of token holders and encourage long-term participation and governance involvement.
In a ve(3,3) DEX, there are typically two types of tokens involved: the governance token and the voting escrow token. The governance token represents ownership and voting rights in the DEX’s ecosystem, while the voting escrow token is obtained by locking or ”escrowing” the governance token for a specified period. The ve(3,3) notation indicates the specific parameters of the voting escrow mechanism related to a notion in game theory. The purpose of the voting escrow mechanism is to incentivize long-term commitment and discourage short-term speculation. By locking up the governance tokens for an extended period, token holders gain voting power and/or rewards in the governance of the DEX. This encourages holders to make informed decisions and actively participate in voting processes that shape the future direction of the DEX. The exact implementation and features of a ve(3,3) DEX can vary depending on the specific platform or protocol. It is important to refer to the documentation or official resources of the DEX in question to understand the specific rules, benefits, and implications of the voting escrow mechanism within that particular ecosystem.
The big question in all types of inflationary models is the long-term sus- tainability. A standard approach in the field is trial-and-error with twists and tweaks on the fly. While this approach allows to learn from past mistakes, it has no predictive power. In this paper I set up a mathematical model that allows to study the effects of those twist-and-tweaks in a lab environment on a computer. Potentially, this allows to avoid major mistakes in the future and it might also help users of the platform to make better decisions, both for themselves and the DEX.
2 Mechanics of a ve(3,3) DEX
2.1 The tokens
A ve(3,3) DEX has two types of tokens, which are not independent of each other. There is the native token, henceforth called $DEX, and a token which is a locked version of the native token, called $veDEX. The $DEX token is a token which can be earned in return for providing liquidity at the DEX.
Figure 1: Flowchart of the tokens on the platform and the actions that can be carried out with the tokens.
This allows the DEX to offer swaps and earn fees from it. Alternatively, it can be bought on the DEX or other platforms directly. The $veDEX is the locked version of the $DEX token and has at least one $DEX underlying. Eventually, this depends on the locking time. Locking one $DEX for the maximal locking time (this depends on the platform and is anywhere between 1 and 4 years) gives rise to one $veDEX. Shorter locking times, give less $veDEX. After the maximum locking time, the underlying $DEX becomes available again and can be claimed. During this time, the value of $veDEX decays to zero at unlocking time (usually linearly) unless the lock is renewed. The main purpose of this locked token is to gain voting power. This voting power allows to participate in two main functions: (i) one can direct emissions to liquidity pools and (ii) one can earn bribes and fees from it. The flow of tokens is shown pictorially in Fig. 1
2.2 The starting condition and emission schedule
In the early stages of a ve(3,3) DEX there is a typical distribution of free, locked, and otherwise vested tokens which play distinct roles in the life of the DEX (l.h.s of Fig. 2). There are a couple of vital points in this. It needs to contain an allocation to make LPs of the own native token. This requires that this token be paired with a typical coin of the chain. To achieve this, some type of presale has to be performed which ensures liquidity of the protocol. Furthermore, the protocol will have initial partners and also needs to attract first users, which is often done via airdrops. Furthermore, the protocol needs to reserve some funds
Figure 2: l.h.s.: Typical initial distribution of tokens; r.h.s: Total emissions of the platform as a function of time
for promotional activities as well as for the team itself.
The protocol rewards liquidity providers with the native $DEX token which
is emitted according to a specific schedule. This leads to a characteristic func- tion that describes the total emitted tokens as a function of time (r.h.s. of Fig. 2). The natural time scale is the epoch or week and the emission through- out this time frame is fixed before by the tokenomics. Conventionally, there is an emission schedule that reduces the weekly emissions over time to limit the inflation. An additional component is that, usually, part of the emissions is directed towards $veDEX holders in the form of a rebase. This is meant as an anti-dilution measure for lockers. The relative ration between free emissions and rebase differs between platforms.
2.3 The structure of the platform
The mechanics of a ve(3,3) DEX are relatively complex and an attempt to explain is shown in Fig. 3. Obviously, the primary goal of the DEX is to provide liquidity and facilitate swaps. In return for that, the DEX receives the swapping fees. The main problem is to incentivize users to provide liquidity. The way is done is by means of emission of a native token $DEX. This token is paid to users that provide liquidity for an LP as a reward. There are two types of typical liquidity providers on the platform, retail users, and protocols. Usually, the emission schedule of the $DEX token is decaying over time.
After receiving the tokens, the users have 4 options: sell them (of course they can also buy them), deposit them in the LP to get more emissions, just hold them, or lock them up as $veDEX to gain voting power. The locking-up procedure works such that with every $DEX token I can choose to convert it into a $veDEX token. The voting power can be used for several things. The most basic usage, however, is to direct the emissions to specific LPs via voting. There are two ways in which the voting process gives revenues to the voters: fees and bribes. Fees are assigned to the pools that produce them, whereas bribes are provided for by protocols and directed to their own LP. Voting directs emissions to those pools and gives access to both bribes and fees of the respective pool. The reason that protocols bribe is that they compete for emissions towards their own native LPs. This serves a twofold process: it gives them access to the emissions by providing liquidity themselves. Furthermore, it attracts retail liquidity providers that also compete for the emissions. In total this leads to an intricate interplay between protocols competing for their own bribes, emissions, but also maximal liquidity, whereas retail users compete for bribes, fees, and emissions. One of the key requirements for this to work is that it has to be advantageous to lock the emitted $DEX token into a $veDEX token in order to get access to bribes and fees. This serves the purpose to discourage selling the $DEX token leading to price stability which is important as incentive to provide liquidity.
There is also a temporal aspect to this. The voting procedure and with that the bribing is repeated every week, conventionally referred to as epoch.
3 Mathematical formulation of tokenomics and price action
In the following we use the natural time scale of the setup, the epoch, to define recursion relations. Therefore, it is justified to assume a discretized version of time denoting the epoch number. Henceforth, we define ti = T i for i = 0, …, N with T being the length of an epoch, a week. We now discuss all the necessary ingredients to be able to model the price action of the $DEX token. This includes the emission schedule (free and rebase), the locking behavior, as well as the native LP.
3.1 Dynamics of the token distribution
We first discuss a standard setup for a DEX in its initial stages. In the following, we do not specify whether the protocol has a maximum token supply or not. The only important parts are that the protocol has an initial supply, n(t0), and an emission schedule e(ti). The sum of all emitted tokens in epoch i + 1, etot(ti+1), can be determined in recursive manner according to
A typical distribution of tokens is shown in Fig. ?? as well as a typical emission schedule etot(ti). At any given time, the total supply of tokens is given by n(ti) = n(t0) + etot(ti) or alternatively
Assuming the token is traded at a price p(ti) during epoch i (we measure prices in US Dollar $ from now on), the total market cap is given by Mc(ti) = n(ti)p(ti). Also, the total $value emission during one epoch is E(ti) = e(ti)p(ti).
In a typical DEX of the ve(3,3)-type, the total supply splits up into a number of components. We like to distinguish four types of tokens at any point in time ti: free tokens f(ti), vote escrowed tokens ve(ti), liquidity pool tokens lp(ti), and protocol tokens pr(ti). In total, they also make up the total number of tokens at given time ti according to
In the following discussion we disregard the protocol owned tokens and their time-dependence (often justified through a cliff in the vesting schedule), i.e., pr(ti) ≈ pr(t0). The weekly emission e(ti) comes in two flavors: (a) emission of free tokens ef(ti) and (b) rebases eve(ti) changing the number of locked tokens
Furthermore, per epoch the free tokens undergo several changes leading to a recursion relation
where b(ti) corresponds to purchases of tokens from the liquidity pool, whereas s(ti) corresponds to sales. Holders of free tokens can always choose to deposit them into the liquidity pool flp(ti) or lock them fve(ti). We can determine a similar rate for locked tokens according to
To remind the reader, eve(ti) corresponds to the rebase whereas fve(ti) accounts for locking of formerly free tokens. If we allow for negative fve(ti) we can also take into account the fact that tokens are liberated from expiring locking contracts, usually a negligible effect. Similarly, there is a set of tokens in the liquidity pool of the DEX, lp(ti), which changes according to
This concludes the set of recursion relations that determines the token supply and dynamics of the DEX. It is straightforward to convert these equations into differential equations upon taking the limit of short epochs but this is not the idea here.
3.2 The native liquidity pool
Being a DEX, an crucial quantity is the liquidity pool (LP) of the protocol. For simplicity, we assume the simplest form of an automated market maker, which is a constant function market maker and we assume there is only one pair. The initial LP has lp(t = 0) tokens in it paired with the corresponding number of reference tokens. For simplicity, we assume the main pairing to be with a stablecoin like USDC with reference value one $. For the initial LP, we need lp(t0)p(t0) USDC-type tokens to pair with where p(t0) is the launch price. A constant function LP means that we have
where c is usually called constant whereas in reality it also is a function of time in the sense that if new LP-tokens are deposited, it has to be adapted. Over time, there are two ways in which the LP changes, there are buys (b(ti)) and sells (s(ti)) of the governance token as well as people depositing and withdrawing LP tokens (flp(ti)). While buys and sells leave c untouched, and only affect the price, the deposition of LP tokens changes c but leaves the price untouched. We first investigate the effect of buys and sells on the price. We find that
As before, we could convert the resulting equations into coupled differential equations if necessary. It is interesting to note that the set of differential equa- tions governing price action and the LP contain severe non-linearities, even for the most basic automated market maker that is conceivable. For a setup using concentrated liquidity, the above rules have to be adapted accordingly.
The knowledge of all the quantities defined above allows to fully model the price action of the native token $DEX.
3.3 Revenues
The most important component in the setup are the revenues and their distribution model. There are two more important quantities that are in principle independent of the tokenomics but ultimately important: the total value locked, T V L(ti), meaning the depth of the liquidity pools on the platform and the rev- enue R(t) consisting of bribes B(ti) and fees F(ti).
In principle, we now have enough information to determine the price action of the token and the DEX as a whole.
4 First results and proof of principle
In a first step we try to check whether the setup we created is able to mimic some real world data. To that end, I used some representative data of a ve(3,3) style DEX. I took the initial conditions of the launch as well as the series of fees F (ti) and bribes B(ti) which combine to the revenue R(ti = F (ti) + B(ti)) per
Figure 4: l.h.s.: A typical price action for the first couple of epochs; r.h.s.: Simulation of the price action for the first couple of epochs using the above specified parameters.
epoch (note that this is all that this is required for this analysis). The other key quantity is the free emission per epoch, EF(ti) = ef(ti)p(ti).
I introduce the parameter x(ti) = EF (ti)/(R(ti)) − 1 which is x > 0 for free emissions greater than revenue, and x < 0 for revenue greater than free emission which is a good measure for the inflation of the platform.
To model the behavior of the participants in the platform. I make an overly crude and a priori unjustified assumption which is that there is only one average type of player, who buys, sells, locks, and provides tokens for the LPs. Further- more, I assume that all LPs are the same. I adopt a simple model for buying, selling, locking, and lping. To that end I introduce a decision function
where T is an optimization parameter. The model I used to produce the price action shown in Fig. 4 is very simple. I choose T = 0.5 meaning the decision function is almost binary with a small window. Furthermore, I use the following
It is important to note at this point that the parameters are chosen such that they model a typical behavior of a ve(3,3) after a couple of epochs. They are not born out by any deeper type of analysis. An important challenge for the future is to better understand and analyze these fitting parameters.
5 Conclusion
In this article, I detailed the main components of a ve(3,3)-type decentralized exchange on the level of very basic tokenomics. From there, I constructed a recursive scheme that allows to simulate the price action of such an exchange based on a very limited number of parameters. The analysis was overly crude and made many simplifying assumptions that are, a priori, unjustified. For instance, not all LPs and players are equal. There are high and low volume LPs that play a very different role. There are different types of players, such as the protocols and retail users whos interest are not always aligned.
There are a number of obvious follow-up questions that I intend to explore in the future. Can we model the different players on the platform more accurately without sacrificing simplicity of the analysis? Is it possible to construct a model with predictive power? Both questions require to analyse a large number of platforms and use the key metrics required by the introduced model. In the longer run, this will hopefully lead to two main achievments: (i) a more accurate model for user behavior and (ii) a lab-style study of the effects of basic changes to tokenomics that avoids tweak-as-you-go-and-see-what-happens approaches.
