Yellow Paper

Abstract

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

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.

Introduction

The base fee function and the shortcomings thereof

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:

Conventions about the parameters in the system

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.

Non active validators

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.

The liabilities

The token utilisation and the total utilisation

The token supply and total supply

Fee amount

Kappa factor

Alpha factor

Fee partitioning

This knowledge will be used shortly in the next subsection.

The partitioned fee function and the temporary fee function

Definition 2 (Temporary fee function). The temporary fee function is defined as

Plan of approach

Fee refinements

First, we will be investigating some important properties about the partitioned fee functions. Two important properties will be proven in lemmas:

  1. Fees are always strictly positive, no matter how a fee is partitioned. This concept is proven in the positive fee lemma.

Power partitions

Fundamental fee theorems

Fee concat theorem and alpha factor

Full paper

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:

Last updated