Yellow Paper
Last updated
Last updated
In the TenderSwap section, the marginal fee function, called the base fee function in the paper, is introduced to calculate the fee. It was then noted that the base fee function presented a problem where splitting the swap into multiple smaller swaps would reduce the total amount of fees paid by a user. This necessitated the formulation of the partitioned fee function.
The partitioned fee function is a reconstruction of the base fee function that represents the lowest possible fee that could be paid by a user, regardless of how the swap is partitioned by the user. The partitioned fee function is found to be
where
denotes the amount swapped.
denotes the utilisation of the token that is currently being swapped.
denotes the sum of the utilisations of all the tokens that are participating in the protocol.
denotes the supply of the token that is currently being swapped.
denotes the sum of the supplies of all the tokens that are participating in the protocol.
denotes the liabilities of the protocol.
, also known as the k-factor in the whitepaper, is a fixed variable that influences the shape of the graph.
, also known as the alpha-factor, is a multiplier of the fee. In the absence of a multiplier, may be set to one.
The proof that the mentioned function is indeed the lowest possible fee a user is not trivial. In this page, we describe the problem in more details. We also give an intuition on why the formula is correct. However, the rigorous proofs are longer and more complicated. That is why we have a whole paper dedicated to that, which can be found at the bottom of this page in the Full paper section.
In the tenderswap section of the whitepaper of Tenderize, it is discussed that when a user wants to use Tenderswap to swap their liquid staking tokens for the underlying tokens, a fee is charged. The system has assets that can be used for this. The amount of assets that the system has if no swaps have happened are called the liabilities. Because the assets used for Tenderswap are limited and using Tenderswap removes from the amount of assets, this operation temporarily makes the system less solvent. To compensate for this, a swap fee is charged. In the whitepaper, a marginal fee function is given. As discussed in the whitepaper, the marginal fee functions takes different properties of the system into account to calculate the amount of fee. In this paper, we refer to the marginal fee function as the base fee function. In the whitepaper, it was motivated that the base fee function had to be
Here, the parameters represent different things:
Before we delve deeper into the problem, we first have to agree on some conventions that are going to be assumed later on in this paper. When calculating fees, several parameters are taken into account. However, these parameters have certain constraints. In this subsection, we discuss what the constraints are and what the motivations are for each of these constraints.
Every validator could potentially have their own LST-token. However, this does not necessarily mean that every validator uses the protocol. We will shortly discuss the total supply and the total utilisation, which are the sums of the supplies and utilisations of the different type of tokens. However, only the validators that use the protocol are taken into account when talking about the total supply and total utilisation.
This knowledge will be used shortly in the next subsection.
Definition 2 (Temporary fee function). The temporary fee function is defined as
First, we will be investigating some important properties about the partitioned fee functions. Two important properties will be proven in lemmas:
Fees are always strictly positive, no matter how a fee is partitioned. This concept is proven in the positive fee lemma.
If one wishes to read the rigorous proofs on the correctness of the partition fee function, they can read the full paper about it, which can be found here:
is the amount swapped.
is the utilisation of the token that is currently being swapped.
U is the sum of the utilisations of all the tokens that are participating in the protocol.
is the supply of the token that is currently being swapped.
is the sum of the supplies of all the tokens that are participating in the protocol.
are the liabilities of the protocol.
, also known as the k-factor in the whitepaper, is a fixed variable that influences the shape of the graph. In this paper we use the greek letter (kappa), as the letter will be used often for indexes in sums.
As said earlier, this function has an important shortcoming. If a user comes in and wants to swap an amount of , let us say for example , then he would need to pay a certain amount of fees. However, assume if he would split the amount swapped in two parts such that the two parts sum up his initial swap. For example he first swaps an amount of after which he swaps an amount of such that . It turns out that sum of the amounts of fee he would pay for the two swaps is less than what he would have payed if he were to swap in one go. The full example can be found in the Tenderswap section in the whitepaper. Conceptually, the reason for this problem is that after a swap, the values of the token supply and token utilisation, and hence the total supply and total utilisation, are changed. This paper examines the base fee function and investigates how a user can split and rearrange a swap, and how this affects the total fees paid. We will come up with the partitioned fee function, a formula that represents what the least amount of fee would be payed by a user if he were to split and rearrange the swap, no matter how the splitting and rearrangement are done.
The liabilities, denoted by , is the amount of assets the liquidity providers have made available for the protocol to use in Tenderswap. If no liquidity has ever been provided, then Tenderswap can not be used, as there is no liquidity available for the users that want to swap, which theoretically is equivalent to Tenderswap not even existing. The system only makes sense if liquidity has been provided. This motivates us to make the convention that it always holds that .
When a user swaps LSTs for the underlying token, a part of the assets, which was provided by the liquidity providers, becomes temporarily unavailable. It becomes available again when someone buys the unlock NFT or if a relayer eventually processes the unlock when it has reached it's maturity date. However, until then, the assets are unavailable. We then say that an LST is utilising the liquidity in Tenderswap. The amount of assets that are not available, because an LST is utilising them, is called a token's utilisation and is denoted by . The sum of the utilisation of all the tokens that are using the protocol is denoted by . Because it is not possible for a token to utilise in a negative way, as this would mean that the system is getting more available assets when a swap happens, we always assume that . However, this also implicates that , as is the sum of non-negative terms. However, there is one final constriction on . There can never be more total utilisation than the amount of assets the liquidity providers have made available in the first place, as otherwise a swapper would need to use non-existing assets to complete their swap. This hence means that . We could abbreviate all of this by stating that .
Every LST has a finite amount circulating. An LST is either using the system or not. If it is not using the system, we disregard it, until it possibly joins the system. As there can not be a negative amount of token circulating, we know for a fact that it always holds that . However, practically, if someone wants to swap LSTs, it also means that there were tokens circulating in the first place. If , then no swap could have happened. That is why we go a step further and always assume that . Again, as is the sum of the circulating supplies of the LSTs that are using the system, it also holds that .
When a user comes in to swap an amount, this amount is commonly represented by the variable . The amount is always assumed to be between and the minimum of and , excluding . Or more formally, it always holds that . The motivation behind the lower bound is that practically, it does not make sense to swap an amount of , as this would be equivalent to no swap having happened at all. The upper bound is bounded by the minimum of , the token supply, and , the liabilities minus the total utilisation. The reason why can never be bigger than was just discussed. To understand why can never be bigger than , we first have to understand what means in practice. Remember, denotes the amount of assets made available by the liquidity providers and denotes the amount of those assets that are being used. This means that represent the amount of assets that are yet available for the swaps. If , this would mean that the user is swapping more than there is available. Hence, it always holds that .
The kappa factor, also known as the k-value or k-factor, is a fixed and predetermined parameter in the system that might vary from LST to LST. The kappa factor changes the shape of the graph in a specific way. If plenty of assets are available, the protocol should not be asking for a lot of fees. However, if the system is starting to get a high utilisation or if there were not a lot of assets made available by the liquidity providers in the first place, we want the fees to become higher. More simply said, the higher the utilisation rate or in other words, the higher , the more harsh the fees should become. Conceptually, if the system is solvent, we want the fee function to be behaving like an almost flat function. However, at a certain point, we want the fees to grow rapidly. The kappa factor influences this. A low kappa factor means that the fee starts to grow rapidly early on. However, the rate of growth does not change a lot. In the most extreme case, when , then the function is even linear. A high kappa factor means that the fee function first almost behaves like a flat function. However, at a certain point, the fee grows very rapidly, even more rapidly than if the function were to have a low kappa factor. Because letting makes the fee grow less and less the more is swapped, it does not make sense to let . This motivates us to always assume that
The alpha factor will only appear again at the end of this paper. We will eventually see that the partitioned fee function can become significantly less than the base fee function. If we somehow want to make this effect less severe, we can multiply the final fee result by a factor . However, if this is not needed, one can just assume that . Furthermore, as does not dominate the theorems and can be easily added afterwards, we will not be discussing until the end.
We are now going to focus more in-depth on what the problem with the base fee function is and how we can formally address it. First, let us assume someone comes in and wants to swap tokens. As the parameters will change after the swap, we are going to subscript the parameters that change after the swap, which are and . We thus obtain . However, let us assume that the user wants to pay fewer fees and decides to split the swap into two parts. First, he swaps an amount of . The second time, he swaps an amount of . The first swap, he pays for fees: Now an important fact comes up. When the user wants to swap an amount of afterward, the function is no longer the same. This is also why we subscripted the function. When the user swaps an amount of , it results in changes to some parameters. Consequently, the fee paid for the second swap is calculated using a different function: It would be beneficial to eliminate , and so we can more easily investigate the issue. Let us examine each one of these in turn:
After swapping an amount of , the LST utilises an amount of more. This means that .
As is the sum of the utilisation of every token, it holds that .
When the user swapped an amount of , an amount of vanishes from the circulating supply. That is, .
As is the sum of all the circulating supply of the token that are using the protocol, it holds that .
We can hence write the second swap as Let us formalize this concept. Let there be a user that first wants to swap an amount of . Instead, he decides to try to reduce the fees and splits up the amount in . The amount of fee that is paid in the second case can then be written as
This equation could be cumbersome to work with. That is why we instead use a slightly different approach. Conceptually, we were looking at the ordered set and performing the base fee function on every element with the updated parameters. What we will do now is consider the cumulative values. To illustrate, we define as . We first note that . Furthermore,
As previously discussed, when a user partitions a swap amount into the amounts , we can also use the numbers . As in the first term, we multiply by , and is not defined, we have a problem here. However, based on the earlier formula, it should be noted that which implies that . Hence, the above number can also be seen as the interval being cut into pieces. This brings us to the first definition of the paper:
Definition 1 (Swap partition). Let be given. A set is called a swap partition if it is in the form where . The set of all possible partitions for a given is denoted by
Because, as we have seen, and do not change using the new approach to calculating the fee when being partitioned, we can leave the subscript away. Given a swap of an amount of and a possible partition of the swap , we can thus calculate the total amount of fee with the partition function defined as
It will turn out that we will encounter this form a lot during this paper. That is why we introduce the temporary fee function , which represent the terms, except for the term.
The reason for providing a different definition when may not be immediately apparent. However, later in the paper, we will encounter cases where we need to calculate . If , we get a term, which is problematic. However, if , then we get a term. Hence, giving a slightly different definition for when gives the same result but removes the propblems. Now, we can write the partition function very briefly as and we are finally able to define what the partitioned fee function must be. Conceptually, our goal is for the formula to return the minimum fee a user would pay for a swap, regardless of how it is split and rearranged. Or in other words, given an amount of , the function should return the greatest lower bound, or infimum, of all the possible values of the partitions that adhere to .
Definition 3 (The partitioned fee function). Let be given. The partitioned fee function is defined as
This paper is dedicated to finding a concrete formula for and proving why this formula is, in fact, the greatest lower bound.
We will discuss our approach to this problem. This subsection provides an overview of the lemmas, propositions, and theorems we will prove in the paper, and how they contribute to deriving a concrete formula for .
When a user refines the partition he uses to swap, the fees will always become lower. That is, if a user swaps an amount of and uses partitions such that , then .
These properties are important to know. Firstly, because it will be proven that refining a partition will always lower the fee, we know that we can never point to a concrete partition that would give us the value of the partitioned fee function immediately. Or in other words . This, however, raises the question of whether we can refine a partition indefinitely until we have a fee of zero or even negative. Fortunately, the positive fee lemma tells us that this will never be the case and we will always be left with a strictly positive fee.
This subsection introduces the concept of index shifting and power partitions. Power partitions are a special type of partitions. Conceptually, if one has an interval , and keeps splitting the intervals in half, we get power partitions. They are often denoted as , such that
It would be beneficial to investigate whether . However, how do we know this? Maybe we can find a partition . Here, one of the most important theorem in the paper, the power partition theorem, states that no matter which partition we have, we can find a power partition that results in a lower fee. Or in other words . This theorem is actually far from trivial. The reason is that if one would for example come with a partition , then now matter how much we refine the power partitions, they will never overlap. Fortunately, before proving this theorem, we prove the lemma that states that shifting elements in the partition is continuous. In a simplified form, it means that although we can never make a subset of some power set, we can shift their elements a little bit such that they do become elements of some power set. The lemma than states that although the value of then changes, it changes in a continuous and thus predictable way, a fact that we will use in the power partition theorem.
In the last part of the paper, the results are showcased. Again, we will simplify things quite a bit here, but we will have seen by this point that is a continuous function and also integrable. This means that for any partition , when we have a term , the Lagrange mean value theorem states that we can find a such that , where is the antiderivative of . Because of the increasing nature of , another fact we would have encountered by now, we know that . If we take the power partitions, we will see that conceptually taking the limit will result in . This conceptually means that the middle term gets squeezed between those two. However, we see that
As the first and last term are equal, and the last term is taken with the limit of the power set, of which the value is smaller than the value of any partition, it is equal to the partitioned fee function. That is the sketch of the proof that the partitioned fee function is equal to
The fee concat theorem states that if we were to partition a swap and use the partitioned fee function, than the sum of the fees would be equal to the fee that would be paid if the swap were to happen in one go. That was the whole purpose of this paper. The proof is quite simple, as it just involves showing that splitting a swap somewhere and performing the partitioned fee function on this new partition gives the same result. More complex refinements can then be achieved by repeatedly applying this operation. Finally, we end the paper with the remark that if the partitioned fee function returns too small values, then we can multiply the result easily with the factor.